arXiv 上挂出来一篇 cs.SE 的论文，编号我记不精确，大概是 2611.06263 那串，标题叫《CLEAR: Structured Specifications for Controllable Long-Horizon ML Research Engineering》。五个作者，十一页，四张图。我不认识作者，也没打算去查。让我停下来看完摘要的，不是这论文讲了什么新花活儿，是它承认了一件事——这件事我这几年反复在说，但头一回看到有人用一篇系统性论文把它端出来。
摘要里两句话才是命门。第一句：研究材料通常并不显式给出系统定义，而是通过自然语言描述、公式、伪代码、实现细节、数据集与评测协议等多种内容混合隐含地表达。第二句：最终系统质量不仅取决于代码生成能力，也取决于智能体能否在整个长周期过程中维持对"应当实现什么"的一致表示。
第二句翻成大白话：一个 LLM agent 去做长周期的 ML 研究工程，真正让它翻车的，不是写不出代码，是干着干着忘了自己到底该实现什么。
见过太多团队干这事。让 agent 去复现一篇论文，第一天它生成一个能跑的骨架，你觉得还行；第三天训练循环补上了，你开始觉得这事能成；第五天你把代码拉下来细读一遍，发现它早就偏了。表征还是原文的公式，但数据怎么预处理、损失怎么加权、评测集怎么划分，它自己做了一套"看起来合理"的决定。每个局部都合理，串起来不是一个东西。
这就是"在长周期过程中维持对应该实现什么的一致表示"的具体模样。不是代码能力不够，是那个"应该实现什么"本身，在各种材料里就是散的，没被显式地凝聚成一个一致结构。人类研究者拿到一篇论文，第一件事是坐下来把目标计算结构理清楚——公式和公式之间的依赖、数据从哪进、评测在哪一步发生——这步做完，后面的实现才有参照。LLM 不是做不了这步，是它在长周期里做这步做得特别脆：context 里的信息会稀释，局部决策会漂移，它没有一个稳定的锚来持续约束自己每一步的判断。锚丢了，后面所有代码生成都是盲飞。
这篇论文把这个观察结构化了，做成了一套叫 CLEAR 的规范方案。它不直接让 agent 读研究材料然后开写，而是先让 agent 从一个混合信号堆里抽出一个结构化的 system spec——计算结构、组件依赖、数据流、评测协议，全部显式写出来——再以这个 spec 为基准去做执行和诊断。spec 就是那个锚。它把隐含在多种材料里的系统定义，强制翻译成一个机器可追踪、人可审查的显式表示。
方向是对的，但我有一个具体疑虑，放后面说。先把"为什么这事重要"讲透。
ML 研究工程显著难于孤立代码生成，不是因为方法多高深，是因为它的"要求"散在一堆异质材料里，没有一份现成的、机器友好的目标定义。让 agent 直接"读论文然后复现"，你等于给它一堆隐含的意图让它猜。猜的过程里它每一步都在做小决定，长周期里小决定累积成大偏离。这跟人类研究者复现论文会跑偏是同一个机制，但人类的偏法通常有迹可查——你问他为什么这里用了一个不同的采样策略，他能说出来。agent 不行，它的偏离凝在代码里，问不出来，只能靠读代码去发现。所以人类复现跑偏，代价是一轮讨论；agent 跑偏，代价是你可能拿着一套根本不是你原意的系统，在评测集上跑了一个"看起来不错"的数字。
问题的核心就在这：长周期任务里，智能体每一步都在做局部优化，局部最优的长链条可以非常自信地把你带到一个整体错误的地方。没有规范，就没有检测偏差的基准。没有基准，偏差一旦进了代码，往外读是一个成本，往外查是更大的成本。
该把那个疑虑说清楚了。CLEAR 这套方案的问题是：这个结构化 spec 到底谁来做？
如果是人来做，那它的价值是把你脑子里"想清楚"的过程外置成一个可追踪的 artifact——这我举双手赞成。但它治不了"懒得想清楚"这个病。如果 spec 也是 LLM 从论文里生出来的，那产生了一个新问题：agent 先猜出一个结构化规范，再照着这个规范去写代码，这个流程里哪一环真的提高了置信度？你只是把"猜"的层数加了一层：原来一次猜到底，现在先猜"目标是什么"，再猜"怎么实现"。目标猜错了，后面的实现全错，而且错得更系统、更整齐、更难察觉。
我不说 CLEAR 这个方向错了。恰恰相反，它踩在了对的机制上——显式表示不是代码生成的装饰，是工程可控性的地基。我的态度很明确：这一层 spec，必须经过人的判断，不能由同一个 agent 在同一个语境下自己生成。把 spec 也交给 AI 推，等于让同一个脑子先出题再答题，独立性是零。上一篇文章里我讲过一个道理：同一个脑子既写实现又写断言，测试就是摆设。现在不过把"测试"换成了"目标表示"，道理一模一样。
具体怎么用，顺序很重要：
- 先让人把 spec 写出来，至少要人来审。目标计算结构、组件依赖、评测协议里的关键决策，人说得清楚再让 agent 执行。
- 再让 agent 以 spec 为基准去生成代码、跑实验、上报偏差。偏差是指 agent 的实际实现与 spec 不一致，不是 agent 自己判断"我觉得这里应该这样"。
- 最后让 agent 定期汇报一致性状态。每一步执行，它的操作跟 spec 的哪一部分对应，一致还是偏离，偏离的理由是什么——这必须是显式的、人可核查的。
这三步顺序不能反。反了，你等于给一个失忆的执行者塞了一张它自己画的航海图，然后看着它在大洋上自信地沿着错误航线走。
跳出这篇论文说更广的。很多人对"AI 自动化 ML 研究"抱着一股乐观，觉得再过两年，agent 自己就能把论文变成系统，跑出结果，做完消融。这个叙事里，瓶颈被默认在代码生成能力上——模型更强、context window 更大、工具调用更稳，然后整个流程就通了。但真实情况是：即便最会写代码的 agent，它在长周期里每多走一步，对最初目标的表示就多漂一层。代码生成解决的是"写"，不是"记得写的是什么"。后者是一个表示一致性问题，跟 token 吞吐不直接挂钩，跟工程规范性强挂钩。
这个观察比 CLEAR 这套具体方案重要得多。它说破了一个反直觉的事实：长周期任务里，模型能力涨，不自动解决"失焦"问题。甚至可能相反，能力越强，错了走得越远，代价越大。工具越聪明，负责两个字越重——这不是我第一次说这种话。
所以我不把这篇论文当一个"新方案"看。它更像一个正经的工程反思：跑长周期 ML 研究，最难的不是生成代码，是让每一次生成都对着同一个目标。这正是我反复在说的另一层意思——想清楚再动手。研究材料给的是散的、隐含的意图，你不先做那步"想清楚"的工作，让 agent 对着材料直接开干，它干得越久，离你要的东西越远。给烂地基刷漆的故事，在 agent 时代有了一个更细的版本：每一步都在给地基刷漆，刷得还挺好看，直到楼塌了，你发现地基下面从来就不是你要的那块地。
最后一个点。论文标题里有个词我一直盯着——"Controllable"。这个词没写进摘要的结论里，但它是整套方案最大的野心。可控的前提从来不是"我让它跑，它跑了"，而是"我有把握知道它不是那种因为看不到偏差就一路走出去的系统"。长周期任务里，没有显式规范作为基准，就没有可控。一切看起来能跑的系统，都可能只是暂时没被看出偏来。工程严谨性的底线，从来不是"跑通了"，是"我知道它为什么跑到这里，而且它还在我认为它该在的那条路上"。
我的态度很明确：CLEAR 这个方向是对的，显式化目标表示就是可控性的地基。但这层地基不能由 agent 自己埋。把"应该实现什么"想清楚、说清楚，是人不能被替代的那一步。先把这步做好，再让 agent 去跑。反过来的话，你得到的不是一个自动化研究工程师，是一台会写代码、会跑实验、偶尔还会自己修偏的机器，它离你真正想做的研究，每一步都在飘。