OmniScientist 是一个把 Omni-Modal 与 Omni-Discipline 组合到 AI Scientist 研究代理中的技术方向。它要处理的不只是文字问答而是一套完整科研闭环从论文 PDF、实验图像、数值表格、音频记录和代码脚本中读取信息再跨物理、化学、生物、材料等学科调用工具验证假设并生成带证据链的结论。如果把这个理念落地为工程原型起手的第一步往往不是接入大模型而是把科研任务拆成一条可审计、可复现、可排错的观察-假设-实验-分析链路。下面会先拆解两个核心关键词再给出参考架构、最小任务示例和配置骨架最后说明常见报错、排查路径与工程落地建议。无论是做科研自动化产品还是只想在自己的研究组里减少重复劳动都可以按这套思路来设计系统边界。1. 先拆解 Omni-Modal 与 Omni-Discipline 两个关键词1.1 Omni-Modal 不只是多模态而是研究链路上的全模态感知多模态通常指系统能同时接受文本、图片、音频、视频等输入。Omni-Modal 的要求要更高一些研究过程中出现的每一种数据都要尽量保留它的原始结构而不是先粗暴统一转成文字。例如从论文 PDF 中抽取实验参数如果把图表全部原样交给视觉模型把表格单独抽取成 CSV再让 Agent 在回答中引用“图 2 显示颗粒尺寸变小”那么系统必须知道“图 2”对应哪张图像、它出现了几次、和哪段文字结论绑定。常见的错误做法是把 PDF 用 OCR 转成纯文本后直接塞给大模型这样看似省事却会丢失公式结构、图例顺序、图像主体位置和表格行列语义。一个 Omni-Modal 系统需要为不同数据源保留不同表示并在底层统一对齐到事件和证据。下面的表格说明了典型科研数据在“直接转文字”和“保留模态结构”之间的差异。数据来源模态类型直接转成纯文本会丢失的内容建议保留的结构论文 PDF版式、文本、公式、图图表位置、公式层级、段落与图表引用关系分页文档对象每段文本记录引用到的图表 IDSEM/TEM 图像图像颗粒边界、尺度标尺、亮度分布图像元数据分辨率、拍摄条件、标尺对应像素实验数据表格/信号数据类型、单位、缺失值规则CSV/Parquet 加列类型说明和单位字典实验声音/视频音频/视频时间戳、事件起点、操作顺序分段事件日志带起止时间与文本摘要代码脚本代码执行顺序、依赖版本、输出变量可执行工作流脚本记录运行输出与参数这里的一个设计判断是底层模型不一定只有一个。视觉描述可以用视觉语言模型完成表格抽取可以用结构化数据模型完成最终由一个研究调度模型把这些中间结果组织成可执行的计划。1.2 Omni-Discipline 指学科知识的调度而不是把所有学科灌进一个模型如果只是把物理、化学、生物、材料、计算机的论文摘要丢进向量数据库然后让大模型检索这不叫 Omni-Discipline。跨学科研究代理面对的困难不只是“知识多少”而是不同学科使用不同形式化语言、计算工具和验证标准。材料科学关心晶体结构、相图、弹性模量、形成能化学关心分子图、反应条件、官能团、选择性生物学关心序列、通路、实验批间差异计算机科学关心模型复杂度、数据集划分、指标置信区间。一个真正跨学科的系统必须理解这些学科的单位换算、公开数据库、验证工具和不确定性来源。所以 Omni-Discipline 更合适的理解是“学科知识路由 工具注册 验证标准隔离”。系统不必背诵所有论文但必须知道这个假设属于哪个学科验证它需要调用哪个工具结果回到统一上下文后如何被下一个步骤消费。1.3 AI Scientist 的研究闭环和普通问答系统差异很大普通问答系统的成功标准是“回答是否与用户预期一致”。AI Scientist 的成功标准是“在有限预算内能否从观察出发完成一个可靠的研究步骤并将每一步结论溯源到原始证据”。一个 AI Scientist 需要经历的链路包括阅读文献并抽取问题与实验条件。识别可用数据源、计算工具和约束条件。提出可检验假设并拆成多个可并行实验。执行实验或仿真记录输入、输出、环境参数。汇总结果并判断假设是否成立。如果结果异常回到假设或实验参数进行修正。最终输出结构化实验报告而不是自然语言“结论”。OmniScientist 之所以强调 Omni-Discipline是因为很多研究问题并不只在一个学科内闭环。比如“某材料在高温下的相稳定性”需要材料学建相图需要化学判断反应路径需要热力学软件计算自由能还需要数值方法处理误差。任何一个环节的知识缺失后面都可能产生错误结论。2. 核心运行机制与总体架构2.1 核心循环感知、假设、实验、验证、记忆设计 OmniScientist 时建议把运行时看作一个带记忆的研究循环而不是一连串大模型请求。每一次循环都要经历感知从多模态数据中生成结构化描述。规划判断当前需要回答什么子问题形成下一步动作。执行调用一个学科工具或外部脚本。观察拿到工具输出转成统一上下文。反思比较当前状态和目标决定继续、回退或终止。这个循环必须持久化。实际项目中Agent 可能运行几分钟甚至几小时中间会调用多个工具。一旦进程重启或内存丢失就无法复现当时为什么调用某工具、为什么得出某结论。所以早期设计要把“状态”显式建模而不是只记聊天记录。2.2 模块清单规划器、感知层、执行器、记忆、审计器一个最小可运行的 OmniScientist 至少需要五个模块模块职责典型的工程落点Planner决定下一步做什么生成行动计划基于大模型推理配合状态机和任务队列Perception解析 PDF、图片、音频、表格生成结构化元数据OCR、图表解析、语音识别、表格抽取Executor在受控环境中执行代码、调用科学计算工具Docker、沙箱、子进程、消息队列Memory保存事实、中间结论、图片引用、错误原因向量数据库 关系表 实验日志Auditor检查结论是否可溯源是否出现前后矛盾证据链校验、字段一致性检查、人工审核接口如果你的目标只是验证概念可以先用少量脚本代替完整模块。例如 Perception 先只支持文本文档和 CSVPlanner 用一个开源对话模型接入Executer 只允许运行白名单命令Auditor 先输出“可疑引用”“无证据结论”等提示。2.3 一个配置骨架示例下面的 YAML 描述了一个原型系统的配置重点是让不同模块都能看到同一个任务事件流并且所有外部调用都被记录planner: model: 本地模型服务地址或OpenAI兼容接口 max_iterations: 20 temperature: 0.2 stop_conditions: - assumption validated - budget exhausted perception: text: enabled: true libraries: [pypdf, pdfplumber] table: enabled: true accepted_extensions: [.csv, .xlsx, .parquet] image: enabled: true image_model: 多模态视觉模型 metadata_fields: [resolution, scale_bar_pixels, description] executor: workspace: ./workspace sandbox: docker allowed_tools: - parse_paper - query_database - calculate_thermodynamics - fit_curve timeouts: default: 30 long_running: 600 memory: context_window: 8000 session_store: ./runs retrieval_top_k: 10 evidence_table: evidence audit: required_fields: - tool_name - input_snapshot - output_snapshot - source_reference这里的关键点有两个。第一max_iterations不是越大越好。研究代理容易出现重复尝试相同失败的步骤显式限制循环次数有助于停止无效费用。第二executor.allowed_tools应该写死白名单不要让 Agent 直接执行任意 SQL 或 shell 命令。科研自动化同样需要权限边界生产环境还要考虑文件系统隔离和资源配额。3. 用最小实验任务看清全模态状态流3.1 一个能验证闭环的最小任务场景设定一个最小任务给定一篇材料合成论文系统需要从 PDF 中抽取反应温度、溶剂比例、保温时间。从论文图片中识别“晶粒尺寸变化趋势”。将参数代入一个外部热力学计算脚本。输出两个候选实验参数并给出判断依据。这样任务虽然只覆盖文本、图片、表格和代码四种数据但已经能暴露全模态系统最容易出的问题文字说 A图片指向 B代码计算又得到 C最终谁来决定结论。3.2 用统一任务对象保存输入、约束和期望输出建议不要直接把大段 PDF 文本塞给模型而是先构造一个任务对象{ task_id: demo-001, research_goal: 调整溶剂比例使晶粒尺寸落入 5nm 到 10nm, source_inputs: [ { type: pdf, path: ./papers/sample-001.pdf, pages: [1, 2, 3] }, { type: image, path: ./figures/grain-size.png, caption: 不同温度下的晶粒尺寸 SEM 图 }, { type: table, path: ./data/experiment-raw.csv, schema_version: csvs-1.0 } ], constraints: [ { name: temperature, min: 200, max: 500, unit: celsius }, { name: solvent_ratio, min: 0.05, max: 0.4 } ], target_output: { type: experiment_plan, format: json } }这个对象有两个作用。一是让输入阶段与规划阶段解耦先做数据解析再让 Planner 决定下一步二是让后续审计能回到“任务最初想解决什么问题”避免大模型在长上下文里把用户目标带偏。3.3 研究循环的最小伪代码规划循环写成伪代码很容易被误解为“必须这么做”实际上它也适用于大多数 Agent 系统。核心是让每个动作都有输入、输出和执行记录class OmniScientistRuntime: def __init__(self, config, memory, executor, auditor): self.config config self.memory memory self.executor executor self.auditor auditor def run(self, task): state {task: task, step: 0, status: planning} while state[step] self.config.planner.max_iterations: state[step] 1 next_action self.planner_next_action(state) self.memory.record(action, next_action) if next_action[type] terminate: break if next_action[type] perceive: observation self.perceive(next_action[source]) self.memory.record(observation, observation) elif next_action[type] execute_tool: output self.executor.call( toolnext_action[tool], argumentsnext_action[arguments], snapshot_inputstate ) self.memory.record(tool_result, { tool: next_action[tool], output: output }) else: self.memory.record(error, { step: state[step], unknown_action: next_action }) state[step_log] list(self.memory.recent_steps()) state self.reflect_and_update_state(state, next_action) report self.generate_report_with_evidence(state) self.auditor.check_evidence_chain(report) return report这段伪代码最重要的设计是memory.record。无论感知结果还是工具输出都进入记忆层后续 Planner 重新决策时可以从记忆里召回“哪一步发生了意外”而不是只听模型生成一个看起来很合理的回答。3.4 如何验证最小任务已经跑通最小任务跑通的判断条件不是“模型说了结论”而是输出的候选参数是否来源于解析后的真实字段。每一步工具调用的输入参数是否有日志。最终报告中的每一个量化数字是否都能对应到 source_inputs 或工具输出。如果撤掉某一张图片或某一段文本结论是否仍然成立。可以把验证分成自动化检查和人工抽查两层。自动化检查主要看字段类型、单位、范围、是否存在空引用人工抽查则随机挑几篇论文或几个实验批次核对 Agent 中间记录和最终结论是否一致。4. 全学科工具的路由、调用与证据管理4.1 学科路由先判断学科再决定工具和验证标准一个模型直接面对所有学科时很容易把所有问题都按“自然语言推理”处理。更可靠的方法是先做一层学科路由再进入对应工具链。学科常见问题类型典型验证动作工具示例材料晶体结构稳定性结构优化、能量计算ASE、Pymatgen、Open Quantum Materials Database化学分子性质预测分子描述符计算、反应可能性筛选RDKit、psi4、化学数据库 API生物序列与表达量分析差异分析、通路富集Biopython、Scanpy、统计检验数值函数拟合与误差分析优化、交叉验证、置信区间scipy、statsmodels、emcee这里的工具名只用于说明思路具体版本和可用性取决于你的研究环境。Omni-Scientist 的调度层不需要知道工具内部算法但必须知道每个工具的输入输出 schema这样工具返回结果后才不会出现“数字单位不一致”等低级冲突。4.2 工具注册表与 function calling 参数 schema现实中可以让 Planner 调用工具常见方式是大模型 function calling。为减小解析错误建议把每个工具的参数定义成显式 JSON Schema{ type: function, function: { name: query_material_database, description: 查询材料数据库中的晶体结构信息, parameters: { type: object, properties: { formula: { type: string, example: LiFePO4 }, temperature_kelvin: { type: number } }, required: [formula] } } }实际调用时为了审计建议不要只记录模型生成的arguments字符串还要在工具真正执行前做一次 schema 校验并把校验后的规范化参数存下来。这里常见的问题是科学计算工具很多时候不接受 JSON只接受命令行参数或特定输入文件。因此 Executor 内部应该有适配层把 JSON arguments 转成命令行参数、输入文件或 Python 函数调用而不是让 Planner 直接拼 shell 命令。4.3 证据链让结论绑定到原文位置、图片 ID 或工具输出科研代理最容易被质疑的一点是结论没有来源。OmniScientist 在设计上就要让“证据”成为一等公民。可以在最终报告中为每条结论保存一个 evidence 列表{ claim: 晶粒尺寸随温度上升而增加, evidence: [ { type: image, source: figures/grain-size.png, region: figure_top_right, check: 人工核对该图第 2 个样本组 }, { type: table, source: experiment-raw.csv, rows: [12, 18, 24], fields: [temperature, grain_size] }, { type: tool_result, tool: calculate_crystal_growth, stdout_hash: sha256:/path/to/output.log, exit_code: 0 } ] }证据链的价值不大在于“好看”而在于失败时能回到现场。如果最终报告被审稿人或业务方质疑团队只需沿着 evidence 字段重新执行对应步骤就能判断是模型幻觉、工具问题还是原论文数据本身有错。5. 环境准备与依赖选型5.1 学习环境、开发环境和生产环境先分开OmniScientist 依赖的东西比较多大模型推理、文档解析、科学计算工具、数据库和容器。若一开始就追求全功能生产环境排错会非常痛苦。下表给出一套分层准备思路环境建议配置核心目标学习原型一台带 16GB 显存的 GPU跑小规模模型或 API快速验证闭环逻辑不追求效果开发环境接入本地推理服务启用 Docker 沙箱调试函数调用、工具参数、证据链测试环境固定模型版本固定依赖锁文件跑回归集验证输出稳定生产/科研批量运行多机任务队列、对象存储、监控报警支持长任务、并行实验、审计不要在学习阶段就依赖“当前最新模型版本”来完成一切。研究系统最怕无法复现模型版本一旦变更结果可能完全不可比。应在项目开始就锁定模型快照或 API 版本的记录字段。5.2 解析、科学计算与模型调用三层依赖要分开管理比较清晰的管理方式是创建不同 Python 环境# 注意包名和版本要根据真实项目锁定 conda create -n omni-agent python3.10 conda activate omni-agent pip install requests pydantic pyyaml # 解析 PDF/表格 的依赖可以放到 document 环境 conda create -n omni-doc python3.10 conda activate omni-doc pip install pdfplumber openpyxl pillow pandoc # 科学计算依赖放在 science 环境 conda create -n omni-science python3.10 conda activate omni-science pip install numpy scipy pandas matplotlib这样做有三个好处。一是避免文档处理包的底层依赖和深度学习计算库冲突。二是便于单独更新某一个科学工具版本而不影响 Agent 调度层。三是安全隔离如果 Executor 中某个科学计算脚本崩溃不会污染整个调度进程。5.3 模态接入的具体技术选择不要一次求全实际项目的切入顺序建议是先支持文本、表格和 JSON 工具调用。再加入普通图片并且要求图片必须带 caption。再加入 PDF 多页解析并保留图表引用。最后再处理音频、视频和动态信号。每加一种模态都要为它定义“统一字段结构”和“失败时的兜底策略”。比如某个 PDF 没有文本层系统应该报告“该页需要 OCR”而不是静默返回空内容让后续步骤猜。这个“失败时显式报错”的工程习惯比任何模型参数调优都重要。6. 常见异常和排查路径6.1 模型给出前后不一致的结论现象Agent 前面说“温度增加导致晶粒增大”后面又用低温度参数生成了增大方案两者矛盾。排查顺序检查是否在同一个状态上下文里更新了温度字段。检查memory.record中是否存在截断或覆盖。检查论文抽取数据中是否存在“摄氏度和开尔文同时使用”的单位问题。检查最终报告生成时的证据链是否属于不同实验条件。推荐做法是在状态更新时保留版本号。单位换算层必须在数据进入工具前统一比如温度一律存成内部统一单位再在展示时转回原单位。6.2 图片内容与文本结论对不上现象图像模型将该图描述为“晶粒尺寸随温度下降”但最终报告写“随温度上升”。常见原因是视觉模型读图时没有参考 scale bar或 Agent 只是“觉得”图像描述与文字一致没有真正把这些信息放入决策上下文。检查方式记录图像模型输入时的原始 prompt 是什么。确认图像中是否包含坐标轴、图例、单位刻度。让图像模型输出结构化描述至少包含“横轴/纵轴含义、趋势方向、异常点”。解决方案是让图片解析结果进入一个独立字段并在 Planner 决策前做一次字段冲突检查。例如temperature_trend同时存在于文本摘要和图像摘要时不同值要触发中断。6.3 工具调用参数非法导致长任务执行失败现象Planner 生成了一个结构合法但科学上无意义的参数例如温度为负数、溶剂比例大于 1工具崩溃或返回空结果。常见原因是工具函数定义里只检查了 required 字段没有检查取值范围和单位。推荐在 Executor 入口增加前置校验层def validate_arguments(tool_name, arguments, schema): # 示例只做最基础的范围检查真实项目还需要单位换算 for field, spec in schema.get(properties, {}).items(): if spec.get(minimum) is not None: value arguments.get(field) if value is not None and value spec[minimum]: raise ValueError( f{tool_name} 参数 {field} 小于最小值 {spec[minimum]} ) return arguments这类错误应该在工具执行前拦截而不是等科学计算脚本运行 10 分钟后报红。前置校验会让错误信息更容易定位。6.4 Agent 任务中断后丢失上下文现象运行了十几步的实验任务因为网络或内存重启而中断重跑后 Agent 不记得自己已经调用过哪些工具。这是研究代理最容易出现且最致命的错误。避免方案是每执行一步都写入日志或数据库。把“已运行步骤”作为下一次恢复的输入之一。长上下文超过窗口时优先压缩历史步骤摘要但保留完整证据文件路径。问题现象常见原因检查方式处理建议输出前后矛盾状态被覆盖或单位不统一检查状态版本、执行日志、单位字段统一内部单位保留状态版本号图片结论错误视觉模型未理解坐标和刻度查看图像模型 prompt、产物描述输出结构化趋势字段单独校验工具参数非法缺少范围和单位校验查看调用前 arguments 日志增加前置参数校验层长任务中断状态未持久化检查 session_store 是否有记录使用数据库或结构化文件持久化状态7. 评估指标、落地顺序和最佳实践7.1 评估科研代理不能只看“结论对错”在一两个样例上的人工判断很容易被模型用看似合理的解释误导。建议拆成多个维度并建立回归集指标计算方式说明数据抽取准确率被正确抽取的关键字段数 / 总字段数与论文原文人工标注对齐工具调用成功率成功执行的工具调用 / 总工具调用排除因网络、认证、参数引发的失败假设证据覆盖率有证据链支撑的关键结论 / 总关键结论找出“没有来源却写出来”的结论结论一致率Agent 前后步骤中一致结论数 / 总关键结论数防止单位换算和状态覆盖错误单任务成本平均 token 数 工具运行时长用于判断扩展规模是否可控7.2 从原型进入生产环境前要补齐的清单模型和依赖版本已经锁文件化运行环境可重复重建。输出报告有版本号证据文件使用只读对象存储保存。每个外部工具调用都有超时、重试上限和失败响应。数据库和日志包含 token 消耗、开始时间、结束时间、错误栈。存在人工审核入口禁止 AI 自动把报告发布为正式学术结论。权限模型明确Agent 不能读取与任务无关的数据不能执行未授权命令。7.3 工程上可以迁移到普通业务场景的经验即使不在科研环境这套架构的经验也能复用。比如金融场景的“行业研究报告 财务数据 模型脚本”本质上就是一个多模态多工具的研究代理工业场景的“设备说明 传感器曲线 维修记录”也可以抽象成证据链驱动的决策系统。共同的做法是不要信任一次生成要让每一步动作都有输入输出记录不要把所有知识塞进提示词要让系统知道去哪里查、查完怎么接不要把失败隐藏掉要把失败转换为可路由的状态帮助系统恢复或让人介入。8. 从原型到科研生产的扩展方向8.1 先选一个固定学科跑通再考虑 Omni-Discipline一旦开始做跨学科会被单位、数据格式、工具库和验证标准的差异淹没。比较现实的路线是先选一个你熟悉且数据完整的小学科例如“材料合成配方预测”或“化学分子性质预测”。在这个学科里积累 50 到 100 条带人工标注证据链的回归样本。跑通过 Planner-Executor-Memory-Audit 闭环。再抽离学科相关内容形成可接入新工具、新数据源的通配层。这个通配层才是 Omni-Discipline 的公共价值。它不是一个什么都会回答的模型而是一套知道“如何把一个学科问题翻译成可执行实验计划”的研究框架。8.2 长期需要关注的方向后续可以分别从机制、评测和运维三个方向做长期投入。机制上重点研究“假设生成”与“实验验证”之间的自动反馈。只靠模型自我反思容易固化在同一思想路径上可以考虑引入多候选假设、并行实验和评分函数让系统做有限探索。评测上需要持续构建覆盖多学科、多模态、多错误类型的回归集。AI Scientist 的价值会被“少数样例上的惊艳表现”高估也会被“不可复现的中间结果”拖累只有稳定可评测的基准集才能让改进可比较。运维上建议早一点把任务队列、GPU 调度、失败重试、证据日志集中管理。研究任务不是单次请求它是一次需要审计的流程流程如果没有平台支撑模型能力再好也难在产品环境中落地。最后想保留一条实践提醒Omni-Modal 和 Omni-Discipline 的目标不是造一个什么都能做的“全能大脑”而是建立一套能感知多种数据、调用多种工具、保留完整证据链的可扩展科研流程。先从一个学科、一个任务、一份带标注的数据开始把运行链路和审计机制做扎实再逐步增加模态和学科才是这个方向里更稳妥的工程路径。