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

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

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

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

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

贯穿本文的例子

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

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

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

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

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

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

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

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

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

借鉴成熟的交互组件

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

方案	可以借鉴的能力	对 Exobrain 的取舍
assistant-ui	React 聊天组件、消息状态适配与按能力启用的操作	优先考察适配现有消息流，保留项目数据模型
CopilotKit / AG-UI	应用、运行时与 agent 之间的事件和状态协作	需要更深的应用协同时再评估协议接入
Vercel AI Elements	基于 shadcn/ui 的可组合 AI 界面组件	适合选择性借鉴，需匹配现有样式与消息格式

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

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

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

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

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

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

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

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

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 分享案例

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

四类证据，四种边界

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

Exobrain 希望做深的部分

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

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

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

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

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

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

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

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

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

工具参考：SymPy、LangGraph。具体云服务与隔离方案将随需求评估，不把某个供应商写进科研项目格式。

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

三个层次，明确共享边界

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

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

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

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

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

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

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

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

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

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

我们明确保留的四个边界

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

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

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

打开 Exobrain · 产品说明