Harness?：当AI智能体学会给自己的工作手册打补丁

你有没有想过一件事：同一个人，在不同的工作环境里，表现可能天差地别。

把一个顶尖程序员扔进一个没有代码补全、没有文档、没有测试工具的裸机环境里，他可能连基本功能都写不利索。但给他配上IDE、版本控制、自动化测试和一份写得清清楚楚的团队规范，同一个人能爆发出完全不同的生产力。

人是这样，AI智能体也是这样。

这篇来自西北大学和谷歌云AI研究院的论文，讲的就是这件事：**大语言模型的能力上限，不只取决于模型本身有多聪明，还取决于围绕它搭建的那套"工作手册"**。

研究者们管这套工作手册叫

harness*：可以理解为智能体的执行脚手架，包括系统提示词、安全护栏、长期记忆、技能库、工具使用说明、脚本、子智能体和中间件插件。它不改变模型的参数，但决定了模型怎么被使用。

论文提出的框架叫Harness?（读作Harness的平方），这个命名本身就在暗示一件事：这不是一次性优化harness，而是让harness自己学会怎么优化harness，形成一种递归的自我改进。

一个尴尬的现实：没有标准答案的世界

在聊Harness?具体怎么做之前，得先搞清楚它要解决的问题有多棘手。

过去改进AI智能体的harness，通常走两条路。第一条路是离线优化：拿一堆训练任务和标准答案，不停地试错，找出表现最好的那套配置，然后部署上线，从此不再变化。第二条路是在线适应：面对新任务时现场调整harness。

问题出在哪里？

第一条路的致命伤是：**真实世界里涌现的新任务，往往和训练时见过的任务长得完全不一样**。

你可以把这想象成考前只做历年真题的学生。如果真题和正式考试的题型高度相似，刷题确实管用。但如果考试突然换了全新的题型,比如从选择题变成了开放式项目报告,那这个学生之前刷的所有真题经验都可能用不上，甚至可能带来错误的思维定式。开放世界里的任务就是这种"换题型"的情况：客服智能体今天处理的是退款纠纷，明天可能就是一个从没见过的产品咨询场景，你不可能提前把所有题型都练过。

第二条路呢？在线适应听起来很美好，能随机应变。但它撞上了另一面墙：**没有标准答案**。

离线训练时好歹有标注好的对错，现场遇到的新任务通常是开放式的，没有人告诉你这次做得对不对，更别说有一个客观的"验证器"能打分。你只能凭执行过程中观察到的蛛丝马迹去判断，这就很容易被噪声带偏，改出一个看起来合理、实际上更差的harness。

论文里举了个数据：在WorkBuddy-Bench这个基准测试上，一个叫ReasoningBank的对比方法，在代码任务上的表现甚至比什么都不改的基础harness还低了6.6个百分点。这说明"在线调整"这件事如果做不好，是真的会帮倒忙的。

还有第二层困境，比第一层更隐蔽。

就算你好不容易把某个任务的harness改好了，这次改进的经验，能不能帮到下一个任务？

现实往往是不能。因为任务A的修改往往是针对任务A的具体需求做的，换到任务B，需求变了，这些针对性修改可能完全不适用，甚至产生干扰。研究者管这个叫"任务特定的编辑往往在需求变化时失效"。

这就是论文标题里"Recursive"这个词真正想解决的核心矛盾：**怎么让"改进这一次任务的过程"本身，也能沉淀出对未来任务有用的经验**？

两层递归：既改眼前的活，也改改活的方法

Harness?的核心设计，是把"递归自我改进"拆成了两个互相嵌套的层次。

第一层叫

任务级递归*：专门针对当前这一个任务，打磨执行harness本身。

第二层叫

harness级递归*：从任务级递归产生的所有探索痕迹里提炼经验，更新一个叫"持续改进harness"的东西，让它在未来的任务中指导更好的编辑。

打个比方。任务级递归像是一个老师傅带徒弟干一次具体的活，这次活怎么干得又快又好。harness级递归则像是老师傅事后把这次带徒弟的经验记下来，写进师门的"带徒心得笔记"里,以后带别的徒弟时，这本笔记能派上用场。

如果没有第二层会怎样？论文的实验数据给出了清楚的答案：直接跳过经验积累、每次任务都从零开始改harness，代码类任务的分数会从73.4分掉到63.2分，网页类任务从69.9分掉到65.0分。这说明没有经验沉淀的"裸改"，反而可能比不改还糟,因为单次探索的信号噪声太大，缺乏历史参照来判断哪些改动是真正可靠的。

### 任务级递归：没有标准答案时，怎么判断改得好不好

既然没有标准答案，Harness?想出的办法是：不直接判断对错，而是看"行为上的差异"。

这个步骤叫

对比式改进步（Propose-Probe-Compose）*：提出候选修改、在相同条件下实际跑一遍测试效果、再根据观察到的行为差异决定是否采纳。整个过程分三步走。

第一步叫Propose（提出）。系统先让当前的harness在任务上跑一遍，得到一个参照执行记录,注意，这个参照只是用来观察harness的行为模式，不是用来判断对错的。然后基于这个参照，系统生成两类候选修改：一类叫"不变性候选"，针对的是跨领域都可能出现的通用问题，比如规划能力不足、工具用错了、上下文管理混乱；另一类叫"领域特定候选"，针对的是当前这个具体领域的专业知识和约束条件。

第二步叫Probe（探测）。把每个候选harness放到同一个任务上，在完全相同的模型和环境配置下跑一遍，然后把它的执行轨迹和产出，跟最初的参照执行做对比。这个对比产生的东西叫

行为对比*：通过比较候选修改前后的执行轨迹差异，判断某个改动到底是缓解了问题、没有影响、还是引入了新问题。

第三步叫Compose（组合）。系统读取参照执行、各个候选harness、它们相对于当前harness的差异，以及所有任务相关的执行证据，决定最终要采纳哪些修改：可能是把多个候选里支持度高的改动合并起来，可能是修正有冲突的编辑，也可能是直接整体采用某一个候选，或者干脆什么都不改。每一个决定都必须对应一个具体观察到的证据，而不是凭空猜测的分数提升。

这里有个细节值得多说一句。为什么要先"提出不同的候选"，再"分头测试"，最后才"合并决策"，而不是让模型一步到位直接改好？

这就像医生看病时的分诊和会诊流程。一个病人同时有好几个症状，直接让一个全科医生凭经验一次性开出所有的药方，风险是某个药方可能和另一个冲突，或者某个症状的诊断本身就是错的，一股脑开出去才发现药不对症,代价是病人真实承受了副作用。而分科会诊的做法是，先让专科医生针对各自擅长的症状提出诊断方案，每个方案单独做临床观察，看看实际效果如何，再由主治医生综合各科的观察证据，决定最终的治疗方案该怎么组合。如果不这么拆开做，一次性下猛药出了问题，你根本不知道是哪个药方的锅,这正是论文做"消融实验"时验证的结论：去掉这种"分工角色"的候选生成方式，JobBench上的分数从36.0掉到32.3，掉了3.7分。

在这个对比步骤的基础上，论文又进一步设计了两种"规模化"的探索方式：

并行递归*：同时生成多个候选方案，各自独立测试完之后，再分头进行多轮独立的组合决策，相当于多条探索路径并行展开。

*顺序递归：像接力赛一样，每一轮产出的新harness和积累的执行证据，都带入下一轮继续精修，层层递进。

两种方式都用一个预算参数k来控制探索的规模。实验数据显示，当k从1增加到5时，无论是并行还是顺序递归，在代码任务和办公任务上的分数都在持续上升,代码任务从76.5分一路爬到80.8分，办公任务从79.5分爬到83.4分。更有意思的是，这两种递归方式在k=2时，就已经超过了所有对比基线方法在k=5时的表现。这说明"怎么探索"比"探索多少次"更重要，蛮力堆算力不如设计一个更聪明的探索机制。

### harness级递归：把"改进的过程"本身变成可复用的资产

这是整篇论文我认为最值得琢磨的部分。

传统做法是，上一个任务改好的harness，直接原封不动地搬到下一个任务去用。这种做法的隐患在于，如果上一个任务的需求和下一个任务差异很大，那套"继承"来的harness可能根本不适配，甚至带着错误的假设误导下一轮的改进。

Harness?没有这么做。它维护了一个叫

harness改进库*的东西：里面存放的不是"上一次用的harness"，而是经过验证、被采纳的harness组件，外加一份记录了"为什么这样改、在什么条件下有效、有什么支持证据"的经验文档（EXPERIENCE.md）。

每次任务结束后，系统会回顾整个改进过程的完整记录,包括参照执行、候选方案和探测结果、最终的组合决策,然后提炼出"哪些改动在什么条件下解决了什么问题"这样的经验。注意，只有当这个经验有执行证据支撑的时候才会被记录下来，单纯因为某个输出被选中并不足以证明这个改动真的可以迁移到别的场景。

下一个任务开始时，起点依然是最初那个干净的通用harness，不是直接继承上一轮的高度定制化版本。但是，这一轮的改进过程会去查阅改进库里积累的经验和可复用组件，有选择性地复用或者改造它们。

这个设计思路让我想起了一个生活中的类比：一个连锁餐厅开新分店时，不会把隔壁那家老店的全套菜单和装修原封不动照搬过来（因为隔壁店可能是针对商务区客流设计的，新店开在居民区，客群完全不同），但也绝不会从零开始摸索一切。真正高效的做法是，总部有一本"开店手册"，里面记录的是经过多家分店验证的、可复用的标准流程（比如后厨动线怎么设计效率最高、哪些菜品在什么条件下受欢迎），新店在这本手册的基础上，结合自己片区的实际情况做调整。如果没有这本手册，每家新店都要把前面所有店踩过的坑重新踩一遍；但如果手册只会死板地复制粘贴而不做调整，新店也可能水土不服。

实验数据验证了这个设计的价值。论文做了一个很巧妙的对照：用k=1（探索量小）积累的改进库去指导新任务，和用k=5（探索量大）积累的改进库去指导同样的新任务，看看谁的效果更好。结果是，k=5积累的改进库能带来0.9、4.4、5.1个百分点的额外提升（分别对应代码、网页、办公三个领域），而且这个提升是在不需要额外探测的情况下获得的。这说明**更多的任务级探索，不仅让当前任务做得更好，还能沉淀出更有价值的经验，反哺未来的改进**。

论文还做了一个跨基准测试的迁移实验：把从JobBench任务流中积累的改进库，直接搬到WorkBuddy-Bench上用于一步式改进，结果三个领域分别提升了0.6、0.5、2.9个百分点。这证明了经验库里沉淀的不只是某个具体任务的答案，而是有一定跨领域迁移能力的通用模式。

实验结果：数字说话

论文在三个专业领域的基准测试上做了验证：WorkBuddy-Bench（覆盖代码、网页、办公三类office风格任务）、JobBench（端到端的专业工作任务）、LAB（哈维公司的法律智能体基准测试，覆盖24个执业领域）。测试用了两个执行模型（GLM-5和Gemini 3.5 Flash）搭配两套开源harness环境（OpenCode和Codex），一共四种组合。

先看一步改进（k=1）的效果。

| 测试场景 | 基础harness | Harness?（一步改进） | 提升 |

|---|---|---|---|

| WorkBuddy-Bench, GLM-5, OpenCode | 64.2 | **75.7** | +11.5 |

| JobBench, Gemini 3.5 Flash, OpenCode | 31.5 | **36.0** | +4.5 |

| LAB, GLM-5, OpenCode (Partial) | 59.6 | **71.4** | +11.8个百分点 |

仅仅一次对比式改进，就能在三个基准、四种模型组合上全部取得正向提升，这本身说明"用行为对比代替标准答案"这条路是走得通的。

再看加入并行递归（k=5）之后的叠加效果。在WorkBuddy-Bench上又能再提升2.9到3.9分，JobBench上再提升3.0到4.2分，LAB的Partial指标上再提升2.6到6.7个百分点。

有个现象我觉得特别值得琢磨：**较弱的执行模型，反而从这套改进框架里获益更多**。GLM-5原本在WorkBuddy-Bench上只有64.2分，经过一步改进后冲到75.7分，这个成绩甚至超过了Gemini 3.5 Flash用原始harness跑出来的72.4分。换句话说，一个配了好工作手册的"普通员工"，表现能超过一个没有工作手册的"优秀员工"。这也从侧面印证了论文开头的那个判断：模型能力和harness设计是两个独立的变量，harness设计得好，能在很大程度上补偿模型本身的能力短板。

论文还测试了计算效率的权衡。在JobBench和WorkBuddy-Bench上画出计算量和性能增益的关系图，Harness?在两个测试配置下都落在"帕累托前沿"上,也就是说，在相同计算预算下，它比其他对比方法（包括ReasoningBank、Harness Scaling、Meta-Harness）获得的收益更高。有意思的是，Meta-Harness这个离线搜索方法，花费的计算量比Harness?在k=5时还多，但最终性能反而更低，这说明离线搜索出来的"固定最优解"，面对开放世界里不断变化的新任务，确实存在水土不服的问题。

另外论文还做了一个"同一个模型既当执行者又当编辑者"的实验,用五种不同能力的模型（从GLM-5到Claude Opus 5）既执行任务又负责改进自己的harness。结果是全部五个模型在所有基准上都取得了提升，这说明**改进harness这件事，并不需要一个比执行模型更强的"外部大脑"来指导**，哪怕是同一个模型，自己审视自己的执行记录，也能找出改进空间。

一个具体的案例：从43.1分到77.8分

论文给出了一个JobBench上的真实案例，很能说明问题。

任务要求把排期表、场地信息、人工和预算这几份文件对账整合成制作交付文档。基础harness跑出来只有43.1分。研究者翻看执行轨迹发现，问题不是模型缺知识，而是流程出了问题：数据从来没有跨文件对账核实过，产出的文件写完之后也从没重新打开检查过。

针对这个问题，系统做了两处改动。第一处是流程级的护栏：强制模型先清点所有输入文件、把每个数字追溯到确切的来源，并且用一个验证脚本重新打开、核查产出的文件。第二处是领域知识层面的补充：加入了一个处理排期、场地、人工、预算文件对账细节的专业技能模块，以及处理特定数字格式的工具使用说明。

这两处改动被完整保留了下来，重新跑一遍，分数从43.1跳到77.8，提升了34.7分。这个案例特别直观地展示了论文反复强调的那个逻辑:很多失败不是模型"不会"，而是流程里缺了"检查"这一环。

它也会犯错：失败案例的诚实记录

值得一提的是，论文没有回避这套系统也会出错的事实，专门用了一节篇幅梳理了九个表现下降的案例。

一类问题出在最终选择环节：候选方案的评分器在"看不到harness来源"的盲选条件下，有时候会选中更差的候选。论文举了个例子，在一个代码移植任务上，候选池里有分数95、85、85、80和55的五个输出，评分器却选中了55分那个,理由是它看起来"最完整、最朴素"，但实际测试发现它的核心渲染逻辑是空的，9个测试用例全部失败。而那个95分的候选已经执行完毕，却因为评分器的误判被弃用了。

另一类问题出在改动本身带着错误前提。比如一个关于验证器缓存机制的任务，编辑者写下"用id()作为缓存键就够了，内容键控只是锦上添花"的假设，结果有4个测试用例因为这个假设没能命中缓存而失败，连用来自检的脚本都被编辑者自己写错了，没能发现这个问题。

论文把这些诚实地归类为三种模式:候选选择环节出偏差、编辑假设本身有误、执行结果存在随机性导致难以归因。这种不回避自身局限的态度，反而让整篇论文的可信度更高。

写在后面

读完这篇论文，我印象最深的不是某个具体的分数提升，而是论文反复强调的一句话：**"选中了某个输出"不等于"证明了某个改动有效"**。

这句话背后藏着一个很容易被忽略的陷阱。很多自动化改进系统，看到最终结果好了，就倒推说某个改动"立功了"。但Harness?的经验反思模块专门设计了一个"confounded"（混淆归因）的标签，明确承认：如果一次改动同时动了好几个组件，而执行结果又没法拆解出来是哪个组件起了作用，那就老老实实标记为"无法归因"，而不是瞎猜一个因果关系写进经验库里。论文原话是"一个混淆标注的条目是有用的记录，一个编造的归因则会污染后面每一个任务要读的经验库"。

这种对"虚假因果"的警惕，其实超出了AI智能体工程这个具体领域，它关乎任何一种"从结果反推原因"的学习方式。人类在复盘自己的成功经验时，也经常犯同样的错误:事情做成了，就把当时做的所有事都当成了"成功秘诀"，却从没认真拆解过到底哪一步才是真正的关键变量。

另外一个让我反复咂摸的细节是，论文发现更弱的模型从这套改进框架里获益更大。这其实暗示了一个更大的命题：在AI能力的竞赛里，除了拼模型参数量和训练数据，"给模型配一套好用的工作环境"这条路，可能是一条成本更低、见效更快的捷径。这对于那些没有能力训练顶尖大模型、但有机会优化系统工程的团队来说，也许是个值得认真考虑的方向。

那么下一个问题自然就浮现出来了：如果这套改进库会随着任务越积越多而不断膨胀，什么时候这个库本身也需要"被整理、被压缩、被淘汰过时经验"？论文在"未来方向"里也提到了这一点，但还没有给出答案。一本越写越厚的工作手册，到底要翻多久才能找到真正有用的那一页？

Q&A

Q1：Harness?是什么？

A：Harness?是谷歌云AI研究院和西北大学提出的一个框架，让AI智能体通过两层递归自动改进自己的"工作手册"（harness），既优化当前任务的执行方式，也把改进经验沉淀下来指导未来任务。

Q2：Harness?在没有标准答案的情况下怎么判断改得好不好？

A：它用一种叫"对比式改进步"的方法，不直接判断对错，而是让候选修改在相同条件下执行，对比执行前后的行为差异,比如轨迹和产出是否变好，再根据这些观察到的证据决定是否采纳修改。

Q3：Harness?的效果提升了多少？

A：在WorkBuddy-Bench上最高提升11.5分，JobBench最高提升4.5分，LAB基准上最高提升11.8个百分点，而且随着探索预算增加还能持续提升。