这次我们来看一个从命名开始就非常“大”的项目OmniScientist: An Omni-Modal Omni-Discipline AI Scientist。翻译过来是“全模态、全学科的 AI 科学家”。它不像是某个单点工具更像是一个要把科研过程中多项能力整合进同一个 Agent 框架的方向性项目。名字里有两个关键词值得先拆清楚Omni-Modal决定它能接收什么类型的输入论文、图片、表格、代码、实验数据都在覆盖范围内Omni-Discipline决定它面向什么类型的任务数学推导、代码实验、材料分析、图像识别等跨学科科研内容都算它的目标场景。先说一句实话。目前能拿到的公开资料非常有限核心信息基本都在项目标题上。所以这篇文章不会假装“我已经跑通 OmniScientist 并贴出显存占用”那是编数据。更合适的做法是把这个标题当成一条研究路线图拆开讲它背后的 AI Scientist 技术栈同时给出一套任何自动科研 Agent 项目都能直接套用的部署验证、功能测试和排查方法。等你拿到官方仓库或论文后可以更快上手验证也更容易判断它适不适合进入你的技术选型。谁会关心这类项目如果你正在做自动科研、论文复现、文献综述、实验数据分析或者想给大模型接一套“能写代码、能看图、能理解论文”的 Agent 工具链那 OmniScientist 的方向就和你直接相关。下面先把标题信息整理成可核对的规格表再逐层展开Omni-Modal与Omni-Discipline在实际系统里到底意味着什么。1. OmniScientist 核心信息速览在拿到官方仓库之前先给一张“当前信息可确认程度”的表格。这样做的原因是很多 AI 方向性项目在 README 不完整时容易被人按标题脑补出一堆并不存在的能力。先明确哪些是标题直述、哪些是行业推断、哪些完全是未知后面验证时就有依据。维度从项目标题得到的信息确认程度项目定位自动科研 AI AgentAI Scientist高标题直述输入模态Omni-Modal覆盖文本、图像、表格、代码等多类科研数据中取决于实际实现学科范围Omni-Discipline面向跨学科科研场景中取决于实际实现核心能力可能覆盖选题、实验设计、代码执行、结果分析、论文生成推断未确认推荐硬件未知取决于基座模型与推理方式待确认启动方式未知可能是 CLI、WebUI 或 API 服务待确认是否支持 API未知待确认是否支持批量任务未知待确认是否开源以项目官方发布页为准待确认适合场景科研自动化、文献分析、实验数据解读、辅助论文写作推断为什么这些参数必须验证因为“全模态全学科”更像一个目标函数而不是一个可运行的规格参数。真正决定一个自动科研 Agent 能不能用的是它的调用链里有没有实验工具、底层模型能不能稳定完成任务、输出结果能不能被人工复核。名字再完整也不代表代码仓库里已经实现了完整闭环。2. AI Scientist 自动科研 AgentOmniScientist 想解决的问题“AI Scientist”这个方向在学术界已经热了一段时间。简单说它想让大模型像人类研究者一样完成一个从“提出问题”到“给出结果”的科研循环。这个方向上已经有一些代表性工作它们通常采用“语言模型 Python 代码执行 论文模板”的组合先让模型根据一个研究方向生成若干候选实验方案再用脚本自动跑实验最后把结果整理成图表和论文段落。大多数这类系统是在数据和代码层面做“干实验”而不是真的在实验室操作仪器跑通一套能够自动产生可复现结果的科研闭环是核心目标。相比之下OmniScientist 从命名上能看到两个更大的切入点。第一个切入点是 Omni-Modal。科研过程中遇到的输入从来不只是纯文本。论文里的结论经常藏在实验图里显微镜照片、光谱图、折线图、热力图、表格都是信息密度很高的载体。一个只能读文字的科研 Agent实际上丢掉了很多可验证的信息。如果一个系统能直接看图、读表格、解析 PDF并且把图里的数值和上下文中的描述对齐它在文献理解和实验分析上会有明显优势。第二个切入点是 Omni-Discipline。不同学科的实验验证方式差异很大。计算机视觉领域里的“实验”是跑 benchmark材料科学要分析的是结构和相变生物信息学则要处理测序数据和各类组学表格。一个全学科定位的系统至少要做到能切换数据集格式、调用不同学科的工具并理解不同评价指标的含义。所以 OmniScientist 更准确的定位是“跨领域通用科研助手”和只在一两个 benchmark 上做论文复现的 Agent 不一样。如果这两点都能落地这类系统的价值就不只是“帮你写一段论文”而是成为科研工作流里的实验副驾驶负责读文献、找数据、跑代码、整理结果人类研究员做最终判断和实验设计把关。3. Omni-Modal 与 Omni-Discipline能力边界拆解先说 Omni-Modal。把它落到系统验收层面至少要回答几个问题能不能接收图像并准确提取图里的数据点能不能把图表和正文中的描述做交叉验证能不能解析 PDF 里的公式和表格能不能在生成论文时同时输出图片、表格和参考文献。这里不是简单接一个多模态大模型 API 就完事而是要把这些输入统一到 Agent 的上下文里并让后续的代码执行和结果分析都能引用它们。我整理了一个多模态科研输入的常见场景表可以用来对照 OmniScientist 或同类系统的实际能力。模态类型科研场景中的典型形态Agent 需要做到什么文本论文段落、摘要、审稿意见总结、抽取观点、提出反驳问题代码Python、Shell 实验脚本生成、执行、调试、记录运行结果图像显微镜图、曲线图、热力图读取坐标、提取数据点、判断异常表格CSV、Excel 实验结果清洗、统计、生成可视化文档PDF 论文版面解析、公式理解、引用追踪运行日志训练日志、错误输出提取指标、定位失败原因再看 Omni-Discipline。这个目标更难验证因为它需要一套跨学科的任务评测标准。同样是“实验成功”代码领域的评判标准是数值指标有没有提升材料科学关心结构和性能是否匹配医学图像分析则要看敏感性和特异性。如果一个科研 Agent 真的要跨学科工作它至少需要两套能力一是对不同领域数据格式的适配能力二是对领域知识正确性的判断能力。对实际使用来说“全学科”不必一开始就全覆盖。更务实的路线是先在一个学科里打通闭环再通过增加工具和数据集扩展领域。看到 OmniScientist 这类项目时建议先确认它目前支持哪几个学科场景而不是默认它所有学科都能达到同样水平。如果官方文档没有给出完善的领域覆盖说明就用最小数据集做一次冒烟测试看看它能否理解该领域的术语和评价指标。4. 自动科研 Agent 的通用工作流程虽然 OmniScientist 的官方流程还没有公开但 AI Scientist 类项目通常不会脱离下面这个科研循环。把它拆开的好处是你可以拿着这个流程去对照实际项目的每一步快速定位它在哪个环节是完整的、哪个环节是坏的。阶段主要动作关键风险选题检索文献、提出研究假设假设无意义或重复已有工作实验设计写实验计划和步骤步骤不可执行、缺少对照组实验执行运行代码、调用外部工具脚本报错、污染运行环境结果分析统计、画图、解读数据选择性汇报、过度解读噪声论文生成写摘要、正文、图表、参考文献内容幻觉、引用不真实这五个环节里最值得先验证的是“实验执行”。对自动科研 Agent 来说能够围绕一个研究问题输出可运行的代码并且代码跑出来的结果是客观可复现的这个闭环通了后面的论文生成才有价值。如果代码生成这一步不稳定Agent 生成的结论越流畅反而越危险因为用户很难判断哪些结论有实验支撑、哪些只是模型在自由发挥。另一个值得注意的点是“结果分析”中的幻觉风险。让大模型描述一张图表很容易但它完全可能编造一个并不存在的趋势。自动科研 Agent 如果直接把图表扔给多模态模型去“看图说话”而没有额外程序去抽取图里的真实数据点那最后的科研结论站不住脚。所以判断这类系统好坏不能只看演示效果要看它生成的结果能不能对照原始数据验证。这里也顺便解释一下为什么我在本文中反复强调“先看官方文档”和“先做最小验证”在自动化科研领域Agent 的输出天然看起来很像结论如果项目没有提供足够透明的中间结果和日志使用者很难判断它到底是在认真做实验还是只是生成了一段看起来很专业的文本。5. OmniScientist 这类系统的部署环境准备因为没有官方部署文档这一节只能给出“接住一个开源自动科研 Agent”的通用环境准备清单。等到你拿到 OmniScientist 仓库后先对照官方 README 修正再用下面的步骤做基础环境检查。先说系统层面。建议优先准备一台 Linux 服务器如果只有 Windows 电脑优先用 WSL2macOS 可以跑轻量模型或 CPU 推理但要在本机跑大尺寸模型效果会受限。Python 环境建议使用 3.10 或 3.11 版本因为主流 Agent 框架和深度学习库兼容性最好。是否必须用 GPU取决于系统内部使用什么基座模型如果它默认调用云端大模型 API本机对 GPU 的要求很低如果要本地加载开源模型做推理就需要一张显存足够大的显卡具体多大要看模型参数规模。建议在动手前执行一遍下面的检查命令把环境底数摸清楚。# 查看操作系统版本 cat /etc/os-release # 查看显卡、驱动和显存 nvidia-smi # 查看 Python 版本 python3 --version # 查看内存 free -h # 查看磁盘剩余空间 df -h .另一个容易被忽视的准备是磁盘空间。自动科研 Agent 在运行过程中会产生大量中间文件尤其是多模态输入场景下的图片、日志、实验结果和模型缓存。如果输入数据包含高分辨率图片或视频千万不能把目录结构设计得太随意。建议在第一次运行前就把目录规划好项目代码放一个目录模型权重放一个目录输入数据放一个目录输出结果单独放一个目录。这样即使某个任务写坏了文件也不会影响其他部分。依赖管理方面建议使用虚拟环境不要直接把项目依赖装到全局 Python 环境里。自动科研项目往往依赖大量科学计算库版本冲突非常常见。用虚拟环境隔离出问题后删掉重建就行不用反复清理全局环境。6. 安装部署与启动的通用步骤不同 AI Scientist 项目的入口差异很大但开源仓库的启动流程通常可以归纳为几大步拉取代码、创建虚拟环境、安装依赖、准备模型权重或 API Key、修改配置文件、启动任务。下面给的是一套通用模板实际路径和命令一定要以官方 README 为准。# 1. 拉取代码地址替换为项目真实仓库地址 git clone https://your-host/your-org/OmniScientist.git cd OmniScientist # 2. 创建并激活虚拟环境 python -m venv .venv source .venv/bin/activate # 3. 安装依赖 pip install --upgrade pip pip install -r requirements.txt # 4. 如果项目提供一键启动脚本优先查看脚本内容 # cat run.sh依赖装完后下一步是配置模型后端。自动科研 Agent 的核心是调用大模型做推理常见的配置项包括模型服务商、模型名称、API 地址和密钥如果使用本地模型则要配置模型权重路径、量化方式和设备参数。因为 OmniScientist 官方配置格式未知下面给出一份通用 YAML 配置模板实际字段需要按项目文档改。# configs/demo.yaml # 注意这是通用模板不是 OmniScientist 官方配置格式 model: backend: api # api 或 local model_name: gpt-4o # 按服务商实际可用型号填写 base_url: https://api.example.com/v1 api_key: sk-xxx agent: max_turns: 50 # 单个科研任务的最大 Agent 循环次数 work_dir: ./workspaces/demo # 每个任务独立工作目录 sandbox: true # 是否开启代码沙箱 timeout_seconds: 300 # 单步操作超时时间 task: input_dir: ./inputs # 输入数据目录 output_dir: ./outputs # 输出报告目录 save_intermediate: true # 是否保存中间过程启动后如果项目提供了 WebUI 或客户端能看到当前科研任务的执行进度、每一步的日志、生成的图表和论文段落。判断服务是否正常运行不需要盯着界面先确认进程没有退出再观察日志目录是否开始产生新文件基本就能判断运行链路是否通。7. 拿到 OmniScientist 之后功能测试矩阵与验证方法没有官方文档时最稳的做法是设计一套最小功能测试矩阵用最小代价验证核心链路。下面的表格可以直接复制到本地笔记里拿到真实项目后逐项打勾。测试编号测试目标输入素材预期结果成功标准T1文本科研闭环一个研究问题 CSV 数据Agent 输出结论和代码限定步数内返回结果日志完整T2多模态读图一张科研曲线图Agent 提取图中数值或趋势提取结果能与原图人工核对T3代码执行能力让 Agent 实现线性回归自动写代码并跑出指标脚本无报错输出指标可复现T4PDF 文献理解上传一篇论文 PDFAgent 输出摘要与关键方法摘要与原文一致引用页码正确T5多任务稳定性连续提交多个实验任务多个任务互不干扰每个任务有独立日志与输出T6中断恢复任务运行中手动杀掉进程重启后能恢复或明确报错不应出现静默丢数据下面挑三个最关键的测试展开说。先说 T1 文本科研闭环。输入不要一开始就上复杂任务选一个非常明确的小问题比如“用给定 CSV 训练一个线性回归模型输出 R^2”。这个测试主要验证 Agent 能不能把研究问题转成可执行代码并且能读取结果。如果这类基础任务都跑不通就不要急着测更高阶的多学科能力。再说 T2 多模态读图。这是验证 Omni-Modal 能力最直接的方法。准备一张带坐标轴的科研曲线图让 Agent 输出图中某个峰值点的数值然后人工对照原图坐标轴看看它读的数字是否准确。这一步最容易暴露多模态模型的幻觉它很可能给出一个流畅但错误的数值。测试时建议用带明显刻度的简单图像避免使用高噪点、多曲线的复杂图作为第一轮验证否则分不清是模型的问题还是输入图像质量的问题。最后是 T5 多任务稳定性。科研 Agent 与普通聊天应用不同单个任务运行时间可能很长还会写大量中间文件。如果项目支持并发任务建议先用两个任务同时跑分别指定不同的输出目录观察是否出现文件互相覆盖、临时目录冲突或显存不够导致的失败。自动科研场景里稳定的任务编排比单次生成质量更重要。8. AI Scientist 接口 API 与批量科研任务改造很多科研 Agent 项目会同时提供 API 服务便于把自动科研能力接入到现有工具链。由于 OmniScientist 的具体接口格式未知下面给出一个通用的任务提交轮询模板实际使用时需要把 URL、请求字段和鉴权方式替换成项目真实接口。import time import requests # 替换为项目真实 API 地址与鉴权方式 api_base http://127.0.0.1:8000/api headers {Authorization: Bearer sk-xxx} payload { task_type: scientific_experiment, research_goal: 分析 data.csv 中两个变量之间的关系并输出报告, input_files: [ ./inputs/data.csv, ./inputs/figure1.png ], output_format: markdown } # 提交任务 resp requests.post( f{api_base}/tasks, jsonpayload, headersheaders, timeout30 ) print(create task:, resp.status_code, resp.json()) task_id resp.json().get(task_id) status_url f{api_base}/tasks/{task_id} # 轮询任务状态 for _ in range(120): result requests.get(status_url, headersheaders, timeout10).json() status result.get(status) print(current status:, status) if status in (success, failed): break time.sleep(5)如果项目没有提供 API就说明只能通过 CLI 或 WebUI 使用此时不要硬接。对于批量科研任务我有几个工程化建议。第一每个子任务独立目录。任务提交前先为每个实验创建独立工作目录输入、输出、日志都放进同一个目录这样任务失败后可以快速定位也可以避免并行任务互相污染。第二失败重试要区分情况。自动科研任务失败原因很多可能是代码执行超时、Agent 上下文溢出、模型服务不可用也可能是数据本身有问题。不要写一个“失败就自动重试”的循环否则当 API Key 过期或磁盘满时系统会陷入无效重试。比较稳妥的做法是记录失败日志并根据日志中的异常类型决定是否重试。第三控制并发数。科研 Agent 的每一步都可能调用大模型 API本地运行时还会占用显存。并发一高API 限流和显存溢出都会出现。刚开始部署时不要一次性提交 10 个任务先用 1 到 2 个任务测稳定性和资源占用确认没问题再把并发数往上加。批量任务的价值在于提高吞吐而不是制造不稳定。9. 资源占用与性能观察方法自动科研 Agent 的资源占用比普通大模型对话要高不少。它的工作机制不是“一次生成结束”而是循环执行多条推理同时伴随代码运行、文件读写和上下文累积。如果你要长期跑科研任务不能只看某一个时刻的显存要观察整个任务生命周期内的资源变化。重点观察四个位置。第一是基座模型推理。如果后端使用云端 API本机 GPU 占用可以忽略如果本地加载开源模型显存占用会非常明显。同一个 Agent 框架后端模型从 7B 级换到 70B 级显存需求可能相差数倍。因此不要问“OmniScientist 要多少显存”要先问“你选的基座模型要多少显存”。第二是上下文累积。科研任务会让模型反复阅读论文、图表、提醒词和中间结果上下文长度会越来越长。这些 token 不只是占显存在本地推理时还会显著拖慢生成速度。如果任务跑到后期明显变慢先看看上下文长度是否已经接近模型上限再决定是否需要做关键信息压缩或历史记录裁剪。第三是代码执行开销。Agent 在做实验时会调用 Python、Shell 或其它工具这部分消耗的是 CPU 和内存与模型推理不同。如果任务内容是 CNN 训练或者大规模数据处理实际的计算压力可能不在大模型上而在实验脚本自己身上。第四是磁盘占用。每次实验都会产生大量中间文件多模态输入更是如此。建议定期清理不需要的临时目录或者写一个归档脚本把已完成任务的产物压缩存储。观察显存和内存可以用下面的命令实时查看。# 每 2 秒刷新显存信息 watch -n 2 nvidia-smi # 查看系统整体内存占用 htop如果资源不够有几个降载手段。一是把大尺寸本地模型换成量化版本或小尺寸模型二是降低并发任务数三是给 Agent 设置最大循环轮数和超时时间防止任务卡死四是把不常用的实验数据从内存中释放让 Agent 只在需要时才读取文件。不要指望一个万能参数能解决所有问题自动科研任务的不确定性决定了它需要一套完整的资源治理策略。10. 技术难点多模态多学科 Agent 最容易翻车的位置看完资源占用再回到 OmniScientist 这类系统的技术本质。它在架构上确实“看起来很美”但有几个翻车点非常值得注意。10.1 多模态读图不等于数值理解很多多模态大模型能准确描述图里的物体比如“图中有一条上升的曲线”但在需要精确定位数据点时会出现偏差。科研场景对数值准确性要求极高图里峰值是 0.87 还是 0.89可能直接影响结论。如果 OmniScientist 输出的图表分析和原始数值不一致整条科研链路就失去了可信度。这里的工程化补救方案是不要只让模型“看图说话”而是让模型在读到图后额外调用图像处理脚本去提取精确坐标值再把提取结果给模型做分析。图像理解模型负责定位数值提取脚本负责准确。10.2 跨学科工具链差异巨大每个学科的科研工具完全不同。代码实验可以用 Python 包完成但材料科学可能需要调用专业的晶体结构分析库医学影像需要处理 DICOM 格式。一个宣称 Omni-Discipline 的 Agent如果只是把文本和图像统一接入大模型而没有接入各领域的专业工具它在深入任务上会比较吃力。因此看这类项目时要注意它是否提供了“工具注册”或“插件系统”。没有工具扩展机制的科研 Agent很难真正跨学科因为任何单一模型都无法内置所有学科的分析工具。10.3 科研可复现性难以保证自动科研 Agent 每次运行都会先采样生成不同的中间步骤结果可能每次都不同。同一个研究问题第一次跑出一个结论第二次可能因为采样参数不同而得到另一个结论这种不稳定性在科研场景是不可接受的。验证系统时不要只跑一次就相信输出至少用相同输入重复运行两到三次对比结果的一致程度。如果项目没有固定随机种子或复现机制这对你的应用场景可能是个硬伤。10.4 长任务状态管理容易失控科研任务通常很长涉及大量中间步骤。Agent 可能在执行到第 20 步时发现第 3 步的假设是错误的需要回溯也可能在某次工具调用后失去对上下文的控制。如果项目没有良好的任务状态管理机制长任务跑到一半就会产出不可预知的结果。这也是为什么前面测试矩阵里要专门加“中断恢复”测试。10.5 Agent 幻觉被科研场景放大大模型幻觉在任何场景都有但在自动科研里危害更大。普通聊天里说错一个事实用户可能注意到科研报告里出现一条不存在的引用或一个伪造的实验数据非专业人士很难发现。使用任何 AI Scientist 系统都必须保留日志并设计人工复核节点这是合规要求也是科研伦理底线。11. 使用边界与合规提醒AI Scientist 方向很容易让人误以为“只要跑一个脚本就能自动完成科研”但实际远不是这样。这里专门把使用边界和合规问题列出来。学术诚信边界。自动科研 Agent 产出的段落、图表、引用可以被用作初稿参考但在投稿前必须由作者逐项核对。很多期刊对 AI 辅助写作有明确的披露要求直接在论文中放入模型生成的未知内容而不加声明属于学术不端风险。任何时候都要保留完整的实验日志和代码确保结果经过人工复核。数据授权与隐私。自动科研 Agent 可能需要读取论文 PDF、数据集、医学影像或用户上传的图片。使用前必须确认这些数据你有合法使用权公开数据是否允许下载和重分发医学数据是否做了脱敏用户上传图片是否包含人脸或其它敏感信息。涉及人物图像、声音或可识别身份的数据必须获得明确授权。代码沙箱安全。自动科研 Agent 要执行大模型生成的代码而大模型生成的代码不一定安全。它可能误删文件、访问网络、或者执行未被预期的操作。最稳妥的方式是在容器或虚拟化沙箱中运行实验代码限制文件访问范围和网络权限。不要让 Agent 在无隔离的服务器上拥有完全权限。结论可信度。即使 Agent 输出了看起来非常专业的分析报告也不能把它当成权威结论。自动科研工具的价值在于扩展研究者的效率而不是替代研究者的判断。发布任何基于 Agent 结果的结论前都需要在真实数据上做一次人工验证。敏感研究领域。使用自动科研工具时要注意研究方向的合规性。涉及生物安全、数据安全或其它可能产生风险的研究必须在符合法律法规和伦理审查要求的前提下进行不能因为工具自动化就绕过必要审核。12. 常见问题与排查方法无论跑的是 OmniScientist 还是其它自动科研 Agent你都会遇到一些共性问题。下面是常见的排查表按“先看现象再查日志最后定位组件”的顺序排查。问题现象可能原因排查方式解决方案启动后页面打不开服务未启动或端口被占用查看进程与端口监听更换端口或重启服务pip 安装依赖失败版本冲突或网络问题查看 pip 错误日志使用虚拟环境锁定版本或换镜像源启动时找不到模型权重权重目录配置错误检查环境变量与配置下载权重到指定目录并核对路径CUDA 不可用驱动版本与 PyTorch 不匹配运行 torch.cuda.is_available()按官方要求安装匹配的 CUDA 和 PyTorch显存不足模型太大或并发过高查看 nvidia-smi使用量化模型、降低并发或换 API 后端Agent 生成的代码一直报错沙箱缺少科学计算依赖查看运行日志在沙箱中预装常用包任务跑到一半退出上下文超限或超时查看最后 30 行日志限制最大轮次并启用断点恢复输出结果与人工分析不一致Agent 幻觉或上下文丢失用最小输入复现人工复核并提供更明确的评价标准批量任务卡住某个子任务异常未处理查看各任务日志设置单任务超时并加入失败重试机制磁盘空间增长过快中间文件和日志未清理查看输出目录大小定期归档或设置自动清理策略排查时可以按这个顺序做。第一步看日志的最后 30 行大多数问题在报错信息里已经写清楚了。第二步用最小输入复现把研究问题缩小到最简单版本排除输入数据过于复杂导致的干扰。第三步逐步关闭能力模块来定位问题例如先只测纯文本任务再叠加多模态输入先只测代码执行再叠加批量并发。这种“由简到繁”的二分定位法在 Agent 系统里比直接看完整日志更有效。另外特别注意进程残留问题。自动科研任务运行时间长很容易出现上次进程没杀干净、端口被占用或 GPU 显存没有释放的情况。如果重启服务后仍然报“显存不足”或“端口被占用”先查进程再启动。# 查看残留 Python 进程 ps aux | grep python # 查看端口占用 lsof -i :8000 # 强制结束指定进程PID 以实际查询结果为准 kill -9 PID13. 总结与下一步回到 OmniScientist 这个项目本身。最值得关注的点是它把“多模态理解”和“跨学科科研自动化”放进了同一个目标里这对自动科研 Agent 来说是一个自然但难度很高的演进方向。真正拿到代码后最先要验证的是最基础的文本科研闭环给一个明确研究问题它能不能生成可运行代码并给出可核对的结果。这个闭环通了再往上加多模态读图、跨学科工具和批量任务才有意义。最容易踩的坑有两个。第一个是“把标题当规格”看到 Omni-Modal、Omni-Discipline 就默认所有模态和学科都做到了同样水平实际验证时必须拆开单个能力逐项测试。第二个是“把 Agent 输出当事实”自动科研 Agent 生成的结论非常流畅但流畅不代表正确特别是多模态读图和论文引用这些环节必须有程序化校验和人工复核。如果 OmniScientist 后续公布了官方仓库、论文或 API 文档建议先检查三件事它默认调用什么基座模型、每个模态的输入格式是什么、任务运行日志是否足够透明。这三个信息能直接决定你能不能把它接入现有科研工作流。对自动科研这个方向我的总体判断是单点模型拼不出一个靠谱的 AI Scientist真正拉开差距的是实验编排、工具调用、数据校验和人工复核机制。OmniScientist 的 Omni-Modal 与 Omni-Discipline 定位代表了大方向但对使用者来说把它先当作“实验设计与结果分析 Copilot”来验证投入产出比最高。建议收藏这篇评估框架等官方资料出来后按第六节的测试矩阵逐项跑一遍再决定是否进入正式技术选型。