# 科研智能体，如何让每一步都有据可查？

Exobrain 的产品设计与工程取舍

面向使用 AI 的科研教育工作者，以及构建科研智能体的开发者与创业者。本文以一段泊松分布推导为线索，讨论工作流、验证、计算和研究产物如何组成一个可检查的工作空间。

我们的方向是：以版本化的代码、数据、假设与执行记录作为可审计依据，让自然语言论文和报告解释这些依据。代码也可能出错，数据也可能失真；保存它们的目的，是让结论能够被检查、修正和继续研究。

> 一个值得交接的研究项目，应当让另一位研究者看懂、重跑，并在此基础上继续工作。

## 01 / 先选择能闭环的研究任务 {#tasks}

Exobrain 希望成为科研工作的统一入口，连接知识、工具和计算资源。起点是边界清楚的数字研究任务：输入可获得，步骤可执行，结果可检查，计算成本可承受，错误可恢复。

### 学科决定背景，任务决定能力需求

| 任务类型 | 智能体需要理解什么 | 结果需要怎样检查 |
| --- | --- | --- |
| 数学与符号推导 | 定义域、量词、假设、逻辑依赖 | 等式检查、反例、证明义务与适用条件 |
| 理论物理与数值模拟 | 单位、边界条件、近似、模型假设 | 量纲、守恒关系、收敛性与数值误差 |
| 数据科学与统计分析 | 数据来源、抽样、缺失值、实验设计 | 数据泄漏、统计假设、稳健性与复现 |
| 计算生物与材料分析 | 领域数据、专业模型、工具适用范围 | 数据质量、模型适用域与外部证据 |
| 湿实验与仪器操作 | 实验协议、设备状态、物理反馈 | 实验结果、现场约束与人工审核 |

数学、理论物理和数据科学中的部分任务适合作为起点，但“不需要仪器”不代表任务简单。计算生物和材料数据分析也可能在数字环境中闭环；对自然世界的科学结论，仍可能需要实验支持。

### 贯穿本文的例子

研究者想从二项分布推导泊松分布，并检查其中的计算。任务开始前就应写清：λ 为固定正数，k 为固定非负整数，令 p = λ/n，考察 n 趋于无穷时的极限，并在足够大的 n 下满足概率与阶乘的定义要求。

“帮我检查这段推导”只有变成明确的命题、假设和检查范围，才适合交给工具执行。

## 02 / 对话、编辑与研究产物 {#artifacts}

对话适合描述目标、询问原因和请求修改。研究项目还需要让用户直接编辑 Markdown、Python 与参数，并查看图表、运行结果和检查记录。这些入口应指向同一组文件和版本。

### 让研究产物成为工作的中心

| 对象 | 保存的内容 | 在泊松推导例子中的作用 |
| --- | --- | --- |
| 研究说明 | 目标、假设、推导、解释 | 明确固定 k 与 λ 的条件 |
| 计算脚本 | 可执行的工具调用与断言 | 保存 SymPy 检查的真实范围 |
| 数据与 metadata | 来源、参数、单位、版本、许可 | 记录数值比较采用的参数 |
| 运行记录 | 输入版本、环境、输出、错误 | 说明哪份脚本产生了哪份结果 |
| 检查报告 | 通过项、未检查项、条件与证据 | 区分有限样例与一般性结论 |

自然语言文档中的研究动机、定义与假设同样重要。它们需要与代码和数据建立对应关系，不能只把一篇论文转换成几个文件名。

### 修改可以先从整个文档开始

**设计方向，尚未实现：** 用户与 agent 编辑同一份 artifact。agent 先生成候选版本，用户查看差异，再按文档接受或拒绝；接受后仍可恢复此前版本。

逐行接受涉及更复杂的修改冲突、依赖关系和撤销顺序。初期可以采用文档级修改；跨文件操作则作为一次完整变更预览，避免只接受脚本、却遗漏配套参数。若原文件在候选版本生成后发生变化，应提示冲突，不能直接覆盖。

### 借鉴成熟的交互组件

开源生态已经提供聊天与工具调用界面的基础设施。外观相似并不能证明两个产品使用了相同框架；组件也不会自动解决科研项目的版本与权限问题。

| 方案 | 可以借鉴的能力 | 对 Exobrain 的取舍 |
| --- | --- | --- |
| [assistant-ui](https://www.assistant-ui.com/docs/runtimes/custom/external-store) | React 聊天组件、消息状态适配与按能力启用的操作 | 优先考察适配现有消息流，保留项目数据模型 |
| [CopilotKit / AG-UI](https://docs.copilotkit.ai/langgraph-python/concepts/architecture) | 应用、运行时与 agent 之间的事件和状态协作 | 需要更深的应用协同时再评估协议接入 |
| [Vercel AI Elements](https://github.com/vercel/ai-elements) | 基于 shadcn/ui 的可组合 AI 界面组件 | 适合选择性借鉴，需匹配现有样式与消息格式 |

这些是选型候选，本文不表示 Exobrain 已经集成。当前优先明确文件和运行状态，再决定哪些 UI 值得复用。

## 03 / 工作流：把确定的事交给程序 {#routing}

智能体的 harness，是模型之外管理状态、工具、权限、执行与结果的系统。一个工作流框架可以帮助表达这些关系，但不会自动赋予系统科学可靠性。

### 从一个小分支开始：本轮是否需要 RAG？

Exobrain 当前知识库范围集中在《自动控制》教材。通用线性代数或概率问题，不应因为系统“有 RAG”就检索无关教材。明确要求依据某本未收录资料的问题，也不应假装已查询该资料。

<div class="flow" aria-label="按需检索的工作流示意"><span>识别问题与来源要求</span><b>↓</b><div><span>需要控制教材<br>检索 → 带来源回答</span><span>无需资料检索<br>直接回答或调用工具</span><span>指定来源未收录<br>说明缺口与回答依据</span></div></div>

这是产品行为示意。LangGraph 开发分支已实现 direct、control_rag、unsupported_source 路由；直接路径本身不意味着通用工具执行已接入。路由错误仍然可能发生，需要保留明确的来源边界。

### 什么时候选择哪种工作流？

- **普通程序：** 输入输出明确的计算、校验、保存与权限检查。
- **固定工作流：** 已知步骤和分支，例如识别来源需求、检索、生成回答。
- **动态 agent：** 工具选择随任务变化，但仍设定时间、步数和资源边界。
- **可恢复编排：** 长任务、人工确认或异步计算需要保存状态、恢复执行；重试时避免重复产生副作用。

LangGraph 是 Exobrain 当前探索条件路由的工具。仅仅引入 graph，不等于已经拥有持久化运行、完整追踪或故障恢复。

## 04 / 验证：每个“通过”都应有范围 {#truth}

RAG 可以补充来源，执行工具可以检查计算，证明器可以核验形式命题。这些能力分别覆盖不同问题，不能互相替代。

### 一个真实例子：代码运行，证明了多少？

在 SciencePro 生成的泊松分布推导 Markdown 中，附带了 SymPy 代码：部分 A 对 k = 0、1、2、3、5 求极限，合并结果对 k = 0、1、2、3 检查，完整表达式的直接极限对 k = 0、1、2 检查，另有一组数值误差断言。

这些检查具有价值，却不能单凭有限取值推出对所有固定非负整数 k 的结论。一般性论证还需要说明：对每个固定 k，有限乘积中的各因子趋于 1。代码的成功退出，也不能直接认证文档里未编码检查的其他性质。

本文依据研究者提供的 Markdown 检查代码范围，未独立复跑该脚本，也未独立核验分享页中的执行日志。这是一个验证范围的案例，不构成平台效果排名。[SciencePro 分享案例](https://www.scienceone.ai/lit/#/share/2101667393291497473)

> “检查通过”应当补全为：在这些假设下，这个版本的工具，对这些对象完成了这些检查。

### 四类证据，四种边界

| 证据 | 可以支持什么 | 不能直接推出什么 |
| --- | --- | --- |
| 执行成功 | 程序完成，已执行的断言未失败 | 程序与断言完整表达了研究命题 |
| 数值检查 | 指定参数与容差下的结果 | 所有参数上的恒等式或一般性证明 |
| 符号检查 | 在求解器处理范围和假设下的代数关系 | 自然语言语义、物理模型与整篇论文正确 |
| 形式化证明 | 在给定公理与定义下通过内核检查的命题 | 形式命题准确表达了原文全部意图 |

### Exobrain 希望做深的部分

把原文位置、抽取公式、用户确认的假设、工具输入和检查结果连接起来。结果应能表达“通过、发现问题、条件不足、暂不支持”；上游假设或文件改变后，旧结果应标记为过期。

当前论文步骤切割和语义判断仍存在不准确的情况。分段正确、逻辑步骤识别正确、公式翻译正确、工具检查正确，是不同层次。不能通过一个笼统的绿色勾号掩盖它们。

[SciencePro 官方页面](https://www.scienceone.ai/portal/)也展示形式化证明相关案例。因此，这里的目标是把检查范围和证据做清楚，而不宣称“验证”这一大类能力独有。

## 05 / 计算工具与执行环境 {#isolation}

先选择适合任务的计算方法，再决定它在哪里运行。符号计算、数值模拟与形式化证明分别服务于不同问题。

| 任务 | 工具类别 | 需要保存的关键条件 |
| --- | --- | --- |
| 公式与极限 | SymPy 等符号计算工具 | 变量假设、定义域、软件版本 |
| 数据分析与模拟 | Python 科学计算与统计工具 | 数据版本、随机种子、容差与参数 |
| 形式命题 | Lean 等证明工具 | 定义、公理、依赖库与证明对象 |
| 大规模训练或模拟 | GPU、批处理与专业计算服务 | 资源配置、环境、检查点与成本边界 |

### 隔离与正确性是两条独立的要求

沙箱用于限制执行对宿主、数据和其他任务的影响。microVM 也不会让错误的数学变正确。环境隔离之外，仍需要任务权限、网络与密钥管理、资源限制和生命周期控制。

Exobrain 正在探索独立执行环境；本文不宣称已经实现多租户安全隔离。设计上，运行器接收选定输入，返回产物和日志，不应默认持有应用数据库的完整权限。

任务应有绝对时长、CPU／内存／输出限制和清理机制。空闲超时与绝对运行期限不同；正常结束、失败和调用方断开，都需要考虑资源回收。

工具参考：[SymPy](https://docs.sympy.org/latest/index.html)、[LangGraph](https://docs.langchain.com/oss/python/langgraph/overview)。具体云服务与隔离方案将随需求评估，不把某个供应商写进科研项目格式。

## 06 / 版本、证据与共享 {#versions}

研究项目的版本，应把代码、数据、假设和执行结果连接起来。只给聊天记录编号，或只备份一份 Markdown，都不足以说明结论来自哪里。

### 三个层次，明确共享边界

| 层次 | 内容 | 建议默认行为 |
| --- | --- | --- |
| 个人探索 | 临时聊天、个人偏好、未整理的想法 | 私有；可以主动分享选定内容 |
| 项目知识 | 目标、假设、决策、代码、数据说明 | 按项目权限共享 |
| 发布快照 | 明确版本的文件、环境与检查证据 | 经确认后发布，不携带个人密钥 |

聊天可以分享，但不应成为复现的必要依赖。影响结论的决定要整理进项目文件，让人确认。自动保存、可回滚版本和正式发布，是不同动作。

<div class="flow" aria-label="研究项目的版本关系"><span>输入版本 + 假设 + 环境</span><b>↓</b><span>一次运行 → 产物 + 检查证据</span><b>↓</b><span>人工审阅 → 可共享的发布快照</span></div>

### 一个可移植项目的最小形态

以下是设计示意，并非已经上线的导出格式。

```text
research-project/
  README.md           # 目标、入口、重跑方法
  assumptions.md      # 定义、假设与检查范围
  analysis.py         # 可执行计算
  environment.lock    # 依赖版本
  manifest.json       # 文件哈希、来源、许可与版本引用
  runs/               # 输入快照、参数、输出与检查记录
```

代码与文本可用 Git；大数据和模型可存入对象存储，并在 manifest 中记录版本与内容哈希。分享前检查数据许可、访问权限与敏感内容。哈希能帮助识别文件是否改变，不能证明文件里的事实正确。

同事可以在托管环境中重跑，也可以导出到本地，不必被迫重新安装。重跑保存的计算与让 agent 重新生成一次是两件事；模型、外部服务和数值环境的变化都可能影响结果。

团队协作和这种发布模式属于设计方向，目前尚未提供。长期希望推动开放的研究产物交换方式：即使离开 Exobrain，项目仍然可理解、可执行、可延续。

## 07 / 当前能力与明确边界 {#status}

**状态截至 2026-09-20。** 本文同时介绍已有基础、开发分支和设计方向，不把路线图视为上线承诺。

| 状态 | 范围 |
| --- | --- |
| 已有基础 | 对话与文档工作空间、控制教材检索、部分公式与推导检查能力；检查仍有适用范围与识别误差 |
| 开发分支 | LangGraph 按需 RAG 路由、本地 Studio 与图导出探索；不据此推断生产部署状态 |
| 设计方向 | Markdown／Python 统一编辑体验、文档级改动审阅、独立执行环境、版本化产物与共享快照 |
| 当前不支持 | 团队协作与完整的多人版本审查 |

### 我们明确保留的四个边界

1. **不认证整篇论文。** 不承诺把任意自然语言论文完整、正确地形式化；支持范围内的检查也需要明确假设。
2. **团队能力尚未提供。** 为未来协作保留项目和权限边界，当前以个人工作为主。
3. **未来一年聚焦数字任务。** 不建设湿实验执行、设备控制与实验室调度；已有实验数据的分析不因此排除。
4. **由人承担研究判断。** 人设定目标、确认关键假设、批准重要行动。边界明确的子任务可以自动化，产品不以全自动科研为目标。

## 结语 / 让研究能够被继续 {#close}

Exobrain 的方向，是把问题、假设、工具、产物与证据放进同一个可理解的工作空间。对话帮助我们开始；可检查、可版本化的研究产物，让工作能够继续。

**当另一位研究者可以看懂、重跑并修正一个项目时，智能体的工作才真正成为可交接的研究资产。**

[打开 Exobrain](https://emergence.science/exobrain) · [产品说明](/zh/docs/exobrain)