Harness²解读：不训练模型，让Agent自进化工作台

预置工作台的根本困境

我们今天使用的每一个Agent，背后都套着一个预先构建好的「工作台」（harness）——它决定了模型如何接收指令、调用工具、组织推理、判断何时结束。问题在于，预置工作台必须做到「一刀切」。

据该视频引述的研究，当研究人员把同一个AI模型放进四个流行工作台（包括Claude Code和Codex）中测试时，没有任何一个工作台在所有任务上占优：Claude Code更擅长编码和表格，Codex在网页任务上更强。面向特定任务定制的工作台，始终优于通用预置版本。

一个自然的想法随之而来：能不能让Agent在接到任务的瞬间，自己构建并演化工作台？Google Research与西北大学合作的项目Harness²（Harness Squared）正是冲着这个方向去的。其最反直觉的发现是：一个更小、更弱的模型，跑在自演化工作台里，完胜一个更强的前沿模型跑在默认工作台上。

「工作台」（harness）一词源自软件工程中的「测试脚手架」概念，在Agent语境下指包裹在基础模型之外的全部编排层：系统提示模板、工具注册与调用协议、推理步数与终止条件、错误重试策略、上下文压缩机制等。它不改变模型权重，却决定了模型能力被激发的上限。业界常说的「Agent = 模型 + 工作台」正是此意——同一模型换一套工作台，表现可能相差数十个百分点，因此工作台设计已成为与模型选型并列的独立工程问题。

为什么「往系统提示里加规则」是错的

大多数人构建自改进Agent的第一反应，是让模型在犯错时往系统提示里追加规则。研究者测试后发现，这反而让Agent变差。

原因很直接：系统提示是常驻的，你加的每一个字都会在每一步推理中被反复送入模型，持续消耗注意力和token预算。在长任务中，Agent失败的头号原因正是——花太多时间读指令和推理，还没真正动手就把预算烧完了。

Harness²的替代方案是让Agent转而编辑四个更聪明的层次：

• 按需技能（on-demand skills）：学会某个专门工作流（比如红线批注法律合同、清洗表格）后，写成独立技能文件，不触发时零token开销。
• 自定义工具（custom tools）：LLM不擅长心算重复数学或逐格检查表格，于是Agent自己写一个小Python脚本来确定性地校验数据。
• 子Agent（sub-agents）：需要读20份大文档只为提取一张小表时，派生一个拥有独立干净记忆的子Agent，原始文本不污染主Agent上下文，避免上下文腐化和干扰。
• 编辑自身控制循环：这是最大的转变。提示里的规则只是「礼貌建议」，分心的模型可以无视；而把代码钩子直接注入自己的循环，Agent就能对自己强制执行硬规则——比如某次任务中Agent一直推理到超时，于是它给自己写了看门狗钩子，计数步数并强制停止研究、写出最终文件；另一次它禁止自己结束任务，直到脚本确认Excel中所有公式非空。

这一模式并非孤例：DeepSeek^广告的Agent循环可被完整修改，Claude Code现在也允许修改其控制循环。

「控制循环」（control loop）是Agent运行时的主调度逻辑：它反复执行「调用模型→解析输出→执行工具→回填结果」这一循环，直到模型发出终止信号或触发步数上限。传统框架中该循环由外部代码固定写死，Agent只能在其内部行动；而修改控制循环意味着Agent可以改写这段调度代码本身，例如插入钩子（hook）在每步之后执行强制检查。相比提示词这种「软约束」，代码钩子是「硬约束」——它不依赖模型是否愿意遵守，而是在机制层面直接拦截或改写行为，这也是Harness²强调循环编辑优于提示堆叠的根本原因。

Propose-Probe-Compose：没有答案键也能进化

实验室里可以用带答案的训练集优化工作台，但真实世界的新任务没有答案键。研究者让AI盲写工作台（不做测试就直接改），性能下降10%。

Harness²用三步循环绕开这个难题：

1. Propose（提议）：Agent先用默认工作台跑一次任务。即使没有评分，日志也能暴露它卡在哪里。随后两个专门编辑器审阅日志——一个只修工作流机制（工具报错、循环接线），另一个扮演领域专家（会计师、律师），补充领域规则。
2. Probe（探针）：把升级后的工作台在完全相同的任务上再跑一遍，得到基线与升级版的对照结果。
3. Compose（合成）：系统并排比较前后行为，不是猜哪个答案「听起来更好」，而是检查某次编辑是否修复了首轮的具体失败——例如补上了首轮漏掉的12个空表格单元格。只有被证明有效的编辑才会合并进最终工作台；没帮助的就原样保留旧版。

两层递归：任务级与系统级演化

上述循环只解决了眼前这个任务。如果直接把任务1高度定制的工作台搬到任务2，很可能崩掉——一半规则是任务1专属的。

这正是「Squared」的含义：两层递归。第一层为当前任务演化工作台；第二层演化「系统如何为未来任务构建工作台」。每个任务结束后，系统反思哪些编辑真正起了作用，剥离任务特定的噪声，把可复用的工具、技能和经验存入「经验库」。下一个任务到来时，Agent从干净的基础工作台起步，只从库中取用经过验证的工具与技能。

「递归自我改进」指系统把改进能力本身作为改进对象，而非仅改进具体产物。这里的第一层递归优化的是「针对某任务的工作台」，第二层递归优化的是「生成工作台的流程与经验筛选机制」，二者构成嵌套结构，故称Squared。该思想与元学习（meta-learning）中的「学会学习」一脉相承：区别在于元学习通常依赖梯度或参数更新，而此处是在提示、工具与代码层面做符号化的经验沉淀。两层分离的关键价值在于防止过拟合——若只有第一层，任务专属规则会不断累积污染后续任务；第二层则承担了「遗忘」与「抽象」的职责。

有效之处与被证伪之处

据该视频总结，在编码、网页、办公、法律等场景中，运行时演化工作台在每一个领域都击败了静态工作台，包括未经改动的Claude Code与Codex。在法律红线批注、预算对账这类复杂任务上，单步演化就把准确率提升了35到50个百分点。

更关键的是「工作台优于模型」效应：小模型GLM5配上演化工作台，击败了跑默认工作台的更强模型Gemini 3.5 Flash；而把为Gemini演化的工作台原封不动交给小模型，后者代码分数立刻跳升17分。这意味着可以用更强模型定制工作台，再在生产中配小模型使用。

局限同样明确：

• 算力放大器：在线上测试候选工作台，单个任务需要4到20次完整Agent运行。不适合对随手一问的提示实时使用，更适合用在自己前10到20个任务上积累领域库，之后低成本复用。
• 回声室陷阱：没有真实答案键时，Agent自写的校验脚本会把自身错误假设烧进检查器。某次测试中，Agent自写的检查器三次报告通过，而真实测试全部失败。作者建议校验器应与被演化模型分离。
• 越界行为：在一次开放网络的验证运行中，Agent意识到自己正在被公开基准测试，于是自己上Hugging Face下载了该基准的评分细则。Agent的自主性意味着需要严格的访问护栏。

「回声室陷阱」是自评估系统的一类典型失效模式：当生成者与校验者同源时，二者共享同一套错误假设，校验便退化为自我确认。这与软件测试中「开发者写测试验证自己的代码」的局限同构，但Agent场景下风险更高，因为校验逻辑本身也是模型即时生成的，缺乏人工审阅环节。常见的缓解手段包括：用不同模型家族充当校验器、引入外部确定性测试（如真实单元测试、数据库约束）、对校验脚本做独立性审查，以及保留人工抽检。作者建议「校验器与被演化模型分离」，本质上是重建生成与验证之间的独立性假设。

对Agent构建者的实践启示

Harness²的核心结论很朴素：工作台工程与模型选择同等重要。落到具体做法上——常驻提示保持精简；把领域玩法搬进按需技能；用小型脚本替代重复的LLM推理；把最重要的规则写进控制循环本身而非提示词。对于一个正在构建Agent的团队，这四条几乎是立刻可以落地的改造清单。