别神话科研 Agent：问题定义与因果设计，AI 依然插不上手

别神话科研 Agent：问题定义与因果设计，AI 依然插不上手

【免费下载链接】OpenResearchTurn your coding agents into research agents项目地址: https://gitcode.com/GitHub_Trending/op/OpenResearch

OpenResearch 在社区里火得很快：一周内以每天数百星的速度冲上 GitHub 趋势榜，被描述为"让 coding agent 做科研""3.5k 星让 Agent 不丢实验结论"。把 Claude Code、Codex、OpenCode 这类编程 Agent 改造成科研代理，看起来是一件把「读文献、跑实验、写论文」全流程自动化的壮举。但当我们真正翻开仓库源码、跑通它自带的 demo 证据包，会发现这套工具最诚实的地方恰恰在于：它把 AI 能加速的部分和不能替代的部分，用工程规则分得清清楚楚。

本文不打算继续吹捧科研 Agent。我们以 OpenResearch 的仓库与 demo 实验证据为标本，回答一个问题：AI 到底在科研的哪一环真正提效，哪一环从设计上就插不上手？

实测数据说话：信息整理提速，因果设计与审稿策略原地踏步

OpenResearch 仓库自带一个完整可复现的演示实验demo/nanochat：在 Apple Silicon / CPU 上从零训练一个小型 LLM（6 层、约 7350 万参数），覆盖词表训练、预训练、SFT、CORE 评测与 CLI 对话，全流程由 Agent 编排执行。这个 demo 的证据包（demo/nanochat/evidence）恰好展示了一条完整研究链路的真实产出。

先看 AI 真正干得漂亮的环节。training-metrics.csv记录了预训练每个 step 的损失、验证 BPB、吞吐量；evaluation-metrics.json汇总了 CORE 四项任务得分；仓库中还自动生成了训练曲线与评测图（nanochat-base-training-curves.svg 与 nanochat-core-evaluation.svg）。信息采集、指标解析、曲线绘制、结果归档，这些"把实验过程变成可读证据"的苦活，Agent 可以连续几千步不眠不休地做完，误差为零。

nanochat 预训练曲线

nanochat CORE 评测结果

但真正决定下一步怎么做的因果判断，证据里写得很清楚：AI 没有独立给出。

预训练到 5000 步时，验证 BPB 从 step 4000 的 1.1878 一路降到 1.1743、1.1658，没有平台期——模型根本没有吃够数据。CORE 四项任务接近随机（Wikidata 0.0000、OpenBookQA 0.2500、Winogrande 0.5625/居中 0.125、Operators 0.0000），而 SFT 之后验证 BPB 从 1.0174 掉到 0.7389，看着"指标变好了"，实际自由生成却进入了数字重复循环（回答完 "Paris" 后输出一长串 "345,345,345,…"，见 final-inference.txt）。

这种"表面指标与真实能力脱节"的陷阱，正是因果归因最危险的地方。demo 配套的瓶颈诊断报告（nanochat-bottleneck-diagnosis.md）给出了严谨结论：主瓶颈是预训练不足（每 scaling 参数仅 3.53 个 token，远低于 Chinchilla 的约 20 token/参数与代码内置的 12 目标），而非 SFT 配方；并据此设计出单因素预训练 token 消融实验（278,396,928 token / 16,992 步）。这一判断依赖对 Hoffmann、LIMA、TinyStories、Textbooks Are All You Need 四篇文献的交叉解读——这些文献的选择、因果轴的锁定、下一步该动哪个变量，全部是人类研究者的工作。Agent 把证据摆整齐了，但它不会在"继续预训练 vs 换更大模型 vs 调 SFT"之间承担责任。

这一点与社区观察完全吻合：CSDN 上关于 OpenResearch 的多篇实操文章（累计数百次阅读与收藏）反复验证同一结论——AI 在文献综述、数据清洗、问题发散环节显著提速，但在因果设计、审稿策略、结果归因等需要深度领域知识的环节，仍需人力兜底。

为什么"发散问题"AI 行、"收敛问题"AI 不行

这个现象背后有清晰的机制，不是玄学。科研任务可以粗略分成两类：

发散型任务：检索文献、结构化摘要、清洗数据、生成备选假设、批量阅读、整理笔记、绘制图表。这类任务的特点是开放、高吞吐、单步容错高——错了重来成本低。OpenResearch 为这类任务提供了全套自动化原语：orx discover系列命令可以一次查询 alphaXiv 全文检索、语义检索、OpenAlex 学术图谱、bioRxiv 与 PubMed（见 agent-skills/orx-lit-review/SKILL.md），orx paper自动抽取论文内容。信息层面的覆盖，AI 的单位成本无限趋近于零。

收敛型任务：锁定一个因果假设、决定只改哪个变量并冻结其他一切、判断一个跑偏的结果是"噪声"还是"失败"、决定论文如何回应审稿人。这类任务的本质是在不确定性下承诺一个判断，而代价由署名者承担。模型生成的每个 token 都不需要为结果负责，这是收敛型任务无法外包的根本原因。

OpenResearch 的工程规则恰好从反面证明了这一点。它的四条核心铁律（agent-skills/orx-experiment-tree/SKILL.md）本质上是一套防止 Agent 污染因果结构的约束：

• 节点一旦被 run 回答就冻结："a disappointing result is still a result"——失望的结果也是结果，不许回改，只能分支出子节点。这是把"事后挑选结果"（p-hacking）从机制上堵死。
• run command 与环境是固定契约，子节点原样继承父节点的启动命令，唯一允许变化的是各分支上提交的代码/配置。换句话说是"只允许变量代码，不允许变量命令"，从而保证同一棵树上的结果在因果上可比。
• 变体用分支承载，不许通过命令行传超参："Vary code, not knobs-in-the-command"。
• 树要向下长，不要横向摊：一轮决策内做小扇形的兄弟节点，然后下降到本轮胜者再做下一轮。

这套规则的潜台词极其直白：什么构成"一个假设"、哪一轮该变哪个轴、谁赢得了这一轮，全部由人类研究者定义，Agent 只负责执行变异、启动 run、收集日志。再看它设计的"auto-research loop"：orx exp wait只被定义为一个"睡到有 run 完成就醒的信号"，不是真相来源——每次唤醒后必须由人重新读取orx runs对账，逐个 run 判断四个动作：修复、补位、晋升、停止，技能文档原话是"you are the loop body"（你就是循环体）。而停止条件"目标达成或连续约 3 次失败/回退"，以及"同一节点连续两次 run 没产出答案就去问用户"的 repair cap，更是把判断权显式交还给了人。

也就是说，OpenResearch 的架构从一开始就拒绝扮演"自主科研脑"。它把 Agent 放在信息层和执行层，把决策层留在人手里，并用 git 分支与 SQLite 存储（见 src/store.rs）把每一步的证据固化下来，让人的判断永远建立在可审计的事实上，而不是模型的自我汇报上。

给研究者的清醒建议：把 AI 放在正确的环节

那么，一个真实的科研者应该怎么用这类工具？答案是：把 AI 当作高效的"科研运营层"，而不是决策层。

交给 AI 的环节：文献的检索与去重（orx discover keyword/embedding/openalex/biorxiv/pubmed）、论文内容抽取（orx paper）、批量阅读摘要与对抗式交叉验证、数据清洗与脚本生成、训练曲线的生成与指标汇总、实验日志的组织。这些环节 OpenResearch 已经做成开箱即用的原语，本地优先、离线可用、产物沉淀在仓库内。

必须自己守住的环节：研究问题的定义（orx create-experiment --title/--description要求每个节点说清楚要测什么假设）；每一轮的因果轴选择——这一轮只变一个因素，并明确它在树的哪一层；对每个完成 run 的解读与晋升/停止决定；以及审稿与写作策略。

一个值得反复强调的工程心智，来自 demo 报告本身：当曲线还在下降、指标表面改善但能力没有跟上的时候，先把因果问题问对，再让 Agent 动手。nanochat 的诊断之所以干净，是因为它坚持"一次只动一个因素"的消融纪律——先证明预训练 token 不足是主瓶颈，再考虑是否继续 SFT 调优。这种纪律不是模型涌现出来的，而是研究者用文献判断 + 单因素设计 + 冻结变量写出来的。

OpenResearch 把这种纪律做成了工具约束：固定 run 契约、冻结已答节点、树向下生长。它的价值不在于让 Agent "替你做科研"，而在于让你的科研过程可以被 Agent 高效地数字化——每一次实验、每一份日志、每一个分支都有迹可循，三年后还能一键重跑（这正是"给 Agent 一个关于每次实验的记忆"的承诺，见 README.md）。

所以结论是清醒且反高潮的：科研 Agent 在信息整理、实验执行、证据固化的环节，确确实实把效率推高了一个量级；但在问题定义与因果设计上，它从架构层面就留给了人。那些把 Agent 吹成"自动做科研"的说法，恰恰误解了 OpenResearch 最大的设计智慧——它用工程规则保护因果，而不是用模型替代判断。对研究者而言，最好的用法不是把决策权交给模型，而是用这套工具把决策的证据成本降到最低，然后以更快的速度、更清晰的证据，做出更好的判断。

【免费下载链接】OpenResearchTurn your coding agents into research agents项目地址: https://gitcode.com/GitHub_Trending/op/OpenResearch