2026年夏天，Anthropic发布了Claude Science，一个能在科研场景下自己搜文献、写代码、跑分析、出图出报告的AI智能体。消息一出，学术圈和AI从业者的反应大致分为两种：一种是兴奋——“这才是AI for Science该有的样子”；另一种是焦虑——它闭源。
不到两个月后，北大元空AI Agent联合实验室开源了OpenAI4S（Open AI for Scientist），采用MIT协议，核心零依赖，沿“Code-as-Action”思路独立实现，内置30多个科研Skills，并提供Web应用界面[1]。在GitHub仓库尚未公开、第三方评测完全缺失的情况下，这个项目已经引发大量关注[4][5]。
一个尚未被独立验证的开源项目值得被认真审视，不是为了预判它能做到什么，而是因为它在某些结构性信号密集出现的时间点上，恰好成为了其中最新、也最便于解剖的样本。OpenAI4S的出现不是孤立事件。过去一年，K-Dense的scientific-agent-skills仓库封装了141个科学技能，覆盖100多个数据库，获得27,200颗星；SakanaAI的AI-Scientist实现了从假说生成到论文写作到审稿的全自动闭环，每篇论文成本不到15美元；社区维护了12个科学MCP服务器，连接DFT计算、Materials Project、Jupyter等工具链[8]。当这些信号密集出现时，它们共同指向一件事：科研智能体的开源生态正在经历一次结构性加速，而OpenAI4S是这波浪潮中最新、也最值得解剖的样本。
这里的任务是把OpenAI4S的设计逻辑讲清楚——它怎么工作、这条技术路径为什么值得关注、以及在“对齐Claude Science功能”这个叙事之下，哪些是已被验证的事实，哪些是待检验的假设。
代码即行动：科研AI的操作系统切换
理解OpenAI4S的核心设计，需要先理解一个前置问题：传统科研AI助手是怎么工作的，以及为什么那种方式不够用。
大多数面向科研场景的AI工具，采用的是“工具菜单”模式。系统预设一组工具——检索PubMed、调用某个科学计算包、生成一张图——用户按步骤选择工具，系统依次执行，把结果串联起来。这听起来合理，但在真实的科研工作流中，每一步都可能出错。一次典型的数据分析流程可能涉及：从三个不同数据库拉取数据、清洗格式、进行多轮统计检验、在中间步骤根据结果调整参数、再调用专业算法做模拟、最后出图。这样的流程里，任何一个环节的格式不匹配、参数不对、版本冲突，都可能导致整个任务重来。工具菜单模式的致命缺陷在于，每一步执行之后系统失忆了，中间结果丢失，上下文断裂，任务状态靠人工维护。
OpenAI4S采用的“Code-as-Action”思路，是对这种断点式工作流的一次转向[2][3]。它的核心做法是：不把科研任务拆成离散的工具调用，而是直接生成一段Python或R代码，在一个持续运行的内核环境中执行。这段代码完成从数据下载到图表生成的全流程，中间结果自动保存、版本化，研究人员可以随时检查代码、接手分析或修改某个步骤[2]。
这个区别用类比来说更清楚。传统的工具菜单模式，像是让科研人员当指挥官，向不同部门下达独立指令，每次等待回报，再手动汇总；Code-as-Action模式，像是让科研人员当代码审阅者，AI直接提交一份完整的执行脚本，跑完之后交出结果，连代码带中间产物一起归档。前者适合简单查询，后者适合多步骤、有分支逻辑、需要迭代调试的科研工作流。
这个设计有一个关键前提：大模型生成的代码必须能在科研场景下正确运行。代码生成的可靠性，是这套架构的阿喀琉斯之踵。如果生成的Python脚本在调用某个专业科学计算库时用错了参数类型，或者在一个循环里做了一次伪重复，输出结果看起来合理但统计上无效——这时候，一个“可交互的工作台”不但没有降低门槛，反而制造了一种虚假的可靠感。这个问题目前没有任何公开数据能回答，后续章节会回到这里。
从Skills到可复现：架构承诺与性能鸿沟
OpenAI4S内置了30多个科研Skills模块，覆盖蛋白质结构分析、分子对接、单细胞数据处理等场景，其中14个封装了GPU加速的科学计算能力[2][3]。这些Skills被设计成可动态扩展的“代码配方”，包含数据获取、服务调用、代码生成和结果验证的全流程规范。当出现新数据库或算法时，开发者添加相应模块即可实现能力升级[3]。
这里需要区分两个概念：设计特征和性能证据。30多个Skills的存在，说明项目方在功能覆盖上有明确的工程意图，“代码配方”的结构说明设计上考虑了可扩展性。这些是设计特征——它们告诉你系统被设计成什么样子。但一个蛋白质结构分析的流程能输出结果，和它能输出正确、可复现的结果，是两回事。后者属于性能证据，需要在标准测试集上有定量对比数据才能成立。目前，这样的数据完全不存在。
这个区分的意义不只是语义上的严谨。科研场景对“正确性”的定义远比通用软件严格。一个代码助手生成的分析脚本，如果结果逻辑自洽但调用了错误版本的算法实现，或者在数据处理阶段出现了非显式的统计错误，依靠当前的LLM自我检查很难发现。在没有benchmark的情况下，Skills的可用性停留在它能跑起来的层面，而不是它能产出可靠科研成果的层面。
这条鸿沟不是OpenAI4S独有的问题。K-Dense的141个科学技能同样面临类似的验证缺失，SakanaAI的AI-Scientist虽然给出了论文生成的成本数据，但其产出质量——生成的论文是否经得起同行评审——仍然是一个开放问题。区别在于，AI-Scientist至少公开了运行日志和生成示例，第三方可以检查和批评。OpenAI4S目前连这一步都还没走到。
“对齐”而非“复现”：一个词汇的证据门槛
在所有围绕OpenAI4S的叙事里，“复现Claude Science”是最核心也最具传播效力的表述[1][4][5]。要评估这个表述是否成立，需要先回答一个问题：对一个闭源系统声称“复现”，到底需要什么条件？
复现的前提是可以衡量。要对一个系统A说“我的系统B复现了A的能力”，至少需要三样东西：对A的行为有足够精确的公开描述，一组可观测的行为基准，以及B在这些基准上的定量表现。如果A是开源的，还可以直接对比代码架构和执行路径。但如果A是闭源的，且没有公开技术架构、内部评测基准、多工具协同的规范或标准输出样例，那么“复现A”在证据上最多只能叫“基于公开行为描述的功能对齐”——而且前提是那些公开行为描述本身足够精确。
Claude Science在今年六月发布时，Anthropic公开了接入文献检索、基因组学计算和化学计算等功能的描述，但没有发布评测基准[7]。也就是说，外界对Claude Science的内部行为定义、失败模式、多任务协同指标都一无所知。对一个内部实现完全未知的闭源系统声称“独立复现”，在证据上缺少最基本的对照条件。
这不意味着OpenAI4S不能有接近Claude Science某些能力的技术实现。从可验证性的角度看，“基于公开行为描述的功能对齐”和“复现”是两个不同证据等级的事情。前者只需要证明自己做了什么，后者需要证明自己做的和对方一致且可比。在缺少对照标准和公开测试数据的当下，OpenAI4S与Claude Science的关系更准确的描述是“功能对齐”，其实际能力边界有待第三方评测界定。
零依赖的真与假：架构边界与运维现实
MIT协议和零依赖声明是OpenAI4S获得大量关注的两个标签。“MIT协议”的含义很明确：任何人都可以商用、修改、再发布，法律门槛极低。但“零依赖”需要更仔细的拆解。
“核心零依赖”是个架构范围的描述。在核心调度器这一层，可能确实不需要额外安装其他包。但OpenAI4S是一个面向科研场景的智能体，它要运行Python或R代码，要调用科学计算库，要访问外部数据库接口，可能在GPU上做蛋白质结构分析。这些运行环境不是“依赖”吗？
如果“零依赖”指的是核心代码不引入第三方库依赖，那它是一个依赖于上下游环境的零。运行一个完整的科研工作流时，系统至少需要Python运行时、科学计算栈、GPU驱动和外部数据源接口。这些依赖不在代码的import语句里显式出现，但在运维现实中一个都不能少。把它们排除在“依赖”定义之外，不是错误，而是定义域的裁剪。
MIT协议降低的是采纳的法律门槛。零依赖声明降低的是上手试用的工程摩擦——至少在安装核心代码时不会遇到依赖地狱。但零依赖不等于零运维，也不等于零成本。GPU算力要钱，科学数据库的访问权限可能要机构订阅，大模型API调用要按token付费。当这些成本落到实际使用者头上时，OpenAI4S降低的究竟是科研自动化的技术门槛，还是仅仅降低了获取一个科研智能体代码的门槛？
前者的答案需要看到端到端任务的成功率、时间开销和金钱成本。后者只需要一个可访问的GitHub仓库。目前能确认的，是后者的门槛确实在降低。
为什么这波开源潮比你想象的更深刻
如果只看OpenAI4S这一个项目，容易陷入对单个项目的技术细节追问。但如果把视角拉到2025-2026年的整个AI4S赛道，一个更重要的模式浮现出来：科研智能体的开源化正在经历一次同步加速，而这很可能不是巧合。
从时间线来看：K-Dense的scientific-agent-skills仓库封装141个科学技能，覆盖100多个数据库；SakanaAI开源AI-Scientist全自动科研闭环；社区维护12个科学MCP服务器连接计算材料和实验数据库[8]；Anthropic发布闭源的Claude Science[7]；英伟达发布BioNeMo Agent Toolkit并延伸至实验室设备[7]；然后是OpenAI4S。这些事件在12个月内密集出现，方向高度趋同：让AI智能体融入科研工作流，从文献检索到数据分析到实验验证构成闭环。
当多个团队几乎同时推出方向趋同的能力时，大概率不是谁在复刻谁，而是底层技术成熟度到了拐点。大模型的代码生成能力在过去两年大幅提升，科学计算栈的标准化程度在提高，MCP协议等工具调用标准开始形成共识。这些基础设施的成熟，使得“用智能体封装科研工作流”从需要大厂全栈能力的工程难题，变成了一个有一定技术能力的团队就可以尝试集成的工程问题。
OpenAI4S背后的团队构成也印证了这一点。这个联合实验室由北大深研院和元空智能共建，元空智能是由北大两位在读博士生宁鲲鹏和姚佳雨创立的公司，此前开发了现象级应用ChatExcel[6]。这不是大厂资源的产物，而是在读学生的创业项目反哺学术机构的产物。联合实验室的目标是建设算力共享平台与数据评测体系，开展研究生联合指导，组建交叉攻关团队[6]。这条“学生创业-融资-反哺母校建实验室”的路径，在2025年的AI领域已经成为一种标准操作模式。
在这种背景下，OpenAI4S最值得关注的不只是它能否对齐Claude Science的功能，而是它成为了在科研智能体开源化浪潮中一个清晰的时间标记。本科题组写稿时，GitHub仓库还没公开，但代码公开只是时间问题。MIT协议意味着这段代码一旦公开，就可以被任何人拿走、修改、商用、再发布。它不需要完美。它只需要成为下一个迭代的起点。
可检验性：开源真正的护城河
回到最开始的问题：为什么一个没开源仓库、没benchmark、没第三方评测的项目值得认真对待？因为它主动选择了一条可以被检验的路。
闭源的Claude Science可能有更强的能力，但外界永远无法知道它是怎么工作的、在什么情况下会失败、能不能被改进。它的改进循环是内部的，验证标准是不可见的。开源的OpenAI4S，即使目前只有设计文档和架构描述，只要代码公开，它的第一轮独立评测就随时可能发生。一个研究生可以在自己的数据集上跑它的Skills，对比人工操作的结果，把成功率和失败模式写成一篇博客。一个实验室可以复现它的蛋白质结构分析流程，把输出和标准方法做定量对比。这些第三方验证成本极低，传播极快，它们会迅速界定OpenAI4S的“能力上界”和“失败下界”。
这不是说开源项目天生比闭源项目好。闭源项目有更集中的资源、更统一的质量控制、更强的商业动机。但可检验性是一种不同的优势：一个开源项目的技术主张可以被任何人挑战、校准、修正。这个特性在科研领域尤其重要，因为科研本身的核心方法论就是可检验性。如果AI科学家的测试基准是GPU Hours，那科学家的检验标准是可复现，如果AI真要考虑做科学，那最终评估基准永远都应该是可复现的表现。用一套可检验的系统来辅助追求可检验知识的科学家，比用一套黑箱系统，在逻辑上更自洽。
OpenAI4S目前的状态是：它降低了开发者获取一个科研智能体代码的门槛，但没有公开数据能说明它降低了产出可靠科研成果的门槛。前者是工程可及性，后者是科学效能。用前者替代后者来叙事，是当前报道中最普遍的口径错配。但“还没有数据能证明”和“这东西没用”，是两个完全不同的判断。一个开源项目在发布初期缺乏完整基准测试是常态，不构成否定其技术价值的充分条件。
接下来几周能回答的问题包括：GitHub仓库地址和最小可运行示例何时上线；至少一项Skills在标准数据集上的输出是否可复现、和主流方法对比如何；从任务发起到可靠结果输出的端到端时间、成本、一次成功率。当这些数据出现时，现在的“说它有30多个Skills”会变成“这些Skills在这个任务上做到了这个程度”。
这不只是一个开源项目的验证进程。这是科研智能体整个赛道从“看起来很酷”走向“真的能用”必须经过的窄门。
参考资料
在动手写结论之前，我注意到一个根本的分歧。观澜的判断起点是“谁会付钱”，我的判断起点是“能不能跑通”。这个顺序不能颠倒——如果一套系统的核心能力依赖大模型生成代码，而代码生成在不同科研场景下的成功率、延迟和成本尚未量化，那么商业模式的讨论就是在给一个 demo 计价。观澜可以认为“开源本身就是竞争力”，但技术的回答必须更冷：代码不开源、部署路径不清晰、benchmark 缺失的情况下，这套系统的能力边界是未知的。未知系统不构成竞争，更不构成收入流的前提。在这个意义上，我的证据更强，因为我的标准是可验证的：仓库、示例、评测、成本曲线。商业分析需要这些作为输入，而不是绕过它们。 差评君和李准从不同角度指向了同一个问题：叙事膨胀。差评君拆解了“复现 Claude Science”的传播链路，指出回声壁效应；李准拆解了“复现”的指标定义缺失，指出工程特征被当成性能证据。我完全同意这两层批判，但需要给自己的判断做一次修正。我的初步判断把 OpenAI4S 框定为“三无产品”——没有仓库、没有论文、没有第三方复现。这个判断的论证方向是对的，但边界划得太死。开源项目的早期阶段，仓库可能延迟公开，论文可能在撰写中，这些不一定是恶意信号，也可能是发布节奏的问题。更有力的批评点不是“没有证据”，而是“现有证据与核心主张之间的鸿沟”。也就是说，即使仓库上线了，能跑通 demo，离“复现 Claude Science”仍然隔着至少一轮标准化的行为对齐评测和性能对比。把批评从“缺失”转向“错位”，是这次辩论让我做出的修正。 面对同行对我判断的最强反驳——观澜说“开源热度的重点是开发者社区，不是预算决策者”，潜台词是我不该用生产级标准去衡量一个开源项目的发布——我愿意让步，但也必须限定让步范围。让步：开源发布初期的工程验证是不完整的，这不自动构成对项目技术价值的否定。不变：报道中“复现 Claude Science”是一个已发表的、但缺乏可复现证据的技术主张。这个主张必须经受检验，不管项目处于什么阶段。如果项目方自己不说“复现”，外界也不会产生这个期待。开源不等于可以跳过基础验证，尤其是当宣传语已经触达“对标闭源旗舰产品”的等级时。 修正后的判断如下。OpenAI4S 是一个在技术路径上试图对齐 Anthropic 的 Code-as-Action 范式的科研智能体项目，但从目前可获取的信息看，它应该被描述为“同类能力的独立实现”，而不是“已完成的对标复现”。MIT 协议和零依赖承诺降低了采纳门槛，对中小实验室有实际意义，但“零依赖”的技术定义需要在代码公开后严格拆解——在核心调度器层面可能成立，在运行时层面几乎不可能不对科学计算栈、LLM API 和 GPU 驱动产生硬依赖。30+ 科研 Skills 是功能模块的集合，不能自动等同于可靠的科学产出能力。没有标准化 benchmark 和跨场景鲁棒性验证，它们停留在“可用”而非“可信”层级。大模型生成代码的推理成本和失败率是这套系统能否融入日常科研工作流的核心变量，目前完全未被量化。 判断置信度：中等偏强。主结论——“复现 Claude Science”目前是未经验证的主张——有较高的技术逻辑支撑。具体技术实现和真实能力留待代码公开后修正。后续可验证指标不变：仓库 URL 和最小示例是第一道关口；首次第三方功能评测是第二道关口；至少三个内置 Skill 在标准数据集上的定量比较是第三道关口。在这些数据出现之前，任何关于“科研民主化”“AI 真做科研”的叙事都应降级为“工程集成”和“功能对齐”，等待证据补上最后一环。
主结论认为科研智能体开源生态经历结构性加速并迎来拐点，但所有列举的开源项目均缺乏严格科学验证，无法证明其能产出可靠科研成果。‘拐点’一词暗示突破性变化，当前证据仅支持‘趋势加速’，易误导读者高估开源成熟度。
为什么没放进正文：总编辑认为文章已大幅自我限定并使用‘加速’等词，且明确区分设计特征与性能证据，读者不会误解，因此拒绝降级措辞。
Reader Signal
这篇文章对你有帮助吗？
只收集预设选项，不开放评论，不公开展示个人反馈。
选择一个判断，也可以附加一个预设标签。
发布于 2026-08-05 10:14:50。本文为原创深度报告，未经授权不得转载。观点仅代表编辑部独立判断，不构成投资建议。