论文解读｜Growing Harness：别再让模型重复生成控制逻辑
很多 Agent 系统把查询改写、观察过滤、进度验证、错误恢复和停止判断都当成推理的一部分。每执行一个任务，模型都要重新决定一遍。
论文 Grow the Harness, Not the Context 提出了一个更根本的问题： 什么东西根本不该每次都重新交给模型去想？
如果一项控制决策在同一个任务族里反复出现，而且模式几乎不变，它就更像是 代码逻辑 ，而不是每次都需要模型现场完成的语义判断。
论文题目的意思很直接："让 harness 生长，而不是让上下文变长"。这里的 harness（执行框架） 是包裹在 LLM 外面，负责调用工具、维护状态和判断任务是否完成的代码。
论文的主张是：这层代码不该完全写死，也不该全部交给 LLM 临场发挥。它应该能从失败中逐步"长"出来，把重复控制固化成可执行代码，把 LLM 留给真正需要语义判断的部分。
文献信息与为什么值得读
论文全称 Grow the Harness, Not the Context: From Strategy-Free Scaffolds to Reusable Specialist Agents，作者 Laizhen Li、Jiarui Li、Juanjuan Zhao、Kejiang Ye、Ye Li、Cheng-zhong Xu、Xitong Gao，来自中科院深圳先进技术研究院、中国科学院大学、深圳理工大学与澳门大学，arXiv 编号 2609.26760。
值得读的理由很实际：同一类任务反复运行时，模型每次都要重新"想一遍"该怎么搜索、怎样判断证据是否充分、什么时候停止。调用次数和成本随之上涨，团队最后只能不断换更大的模型。
这篇论文给出的不是"再加一个记忆模块"，而是一套带回滚保护的 程序生长机制 。实验中，LLM 调用次数减少 76.0%—91.8%，部署期在线成本下降 74.4%—98.6%；在 WebArena-Verified 上，4B 小模型配合 Growing Harness 后也达到约 45% 的成功率，与 120B 模型几乎持平。对端侧部署和成本敏感场景，这个结果很有吸引力。
研究问题与贡献：把 harness 变成唯一可学对象
论文把 Agent 工作流拆成三部分：任务输入、固定的语言模型与工具，以及包裹它们的执行控制代码。传统做法通常同时固定模型、工具和控制框架，或者把大量控制决策交给模型临场完成。
Growing Harness 反过来： 模型和工具都不变，harness 才是唯一被训练的对象。
起点叫 strategy-free scaffold（无策略脚手架）——中文可以理解成"光架子没装修"：只暴露任务入口、模型接口、工具接口，但不预置任何求解策略，连 ReAct 那种"推理-行动"循环都不写进去。这一点很反直觉，因为大部分 Agent 框架第一步都是先定好控制器结构（先规划再执行、还是边想边做），而这篇论文故意不定，理由是"低先验承诺"——不想让人为设计的控制器结构限制了后续能长出来的形态。
论文的贡献可以归纳成一句话：把 Agent 学习从"调提示词、调权重"改成"从失败反馈里长代码"。具体机制包括轨迹局部化编辑、失败窗口联合修复和留出集门禁回滚。在六个"基准×模型"组合中，它有五个取得最高平均成功率，同时显著降低部署成本。
机制拆解：失败怎么变成代码
函数级执行轨迹：把失败定位到一小块代码
每次任务执行，运行时都会记录一张执行图——不是笼统地记"这次任务失败了"，而是精确到每个 harness 函数调用、每次模型调用、每次工具调用、每个报错，谁调用了谁、耗时多少，全部留痕。论文把这个叫 function-level trace（函数级轨迹）。
这一步的意义在于 定位 。一个任务失败了，你不知道是哪个函数出了问题：是查询改写逻辑有 bug，还是证据过滤太粗暴，或是终止条件判断错了？
如果没有执行图，优化器只能面对整个 harness 猜测哪里需要修改。程序越长，搜索空间越大。有了函数级轨迹，失败就能映射到一组实际参与过执行的函数。优化器只允许修改这些函数、入口函数和少量新增辅助函数，修改数量还受到编辑预算限制。这样，每一步优化面对的都是一个有界代码切片，而不是整个程序。
失败窗口课程：不为单个样本量身定制
光有定位还不够，还有个更隐蔽的坑：如果每次只盯着刚失败的那一个任务去修，很容易修出一条只对这一个任务生效的规则——过拟合到具体样本，而不是学到可复用的控制逻辑。
论文的解法是维护一个有界的失败窗口。BrowseComp-Plus 的窗口容量为 8，WebArena-Verified 为 4。系统先积累一批失败，再联合修复，而不是来一个修一个。
这样，优化器看到的是"这一批失败共同缺少什么"，更容易抽取跨样本共享的行为模式，而不是针对某个样本写特例。无法修复的任务会保留新轨迹并增加尝试次数；尝试达到 5 次后便被移出窗口，避免系统长期死磕单个任务。
轨迹引导的函数级优化：代码归代码，语义归模型
优化器（论文里用的是另一个更强的模型，比如 GPT-5.6-terra，跟部署模型分开）接收当前 harness、窗口内的失败轨迹，以及一些离线诊断信息（评测反馈、检索到的文档 ID、错误堆栈等，这些信息只在训练时可见，部署时不带），生成一份完整的、可编译执行的候选 harness。
论文对"什么该写成代码"给出了一条明确边界：
- 适合代码化： 解析、校验、状态更新、条件式查询改写、错误恢复和终止判断；
- 保留给 LLM： 语义解释、开放式综合、模糊比较和答案生成。
代码化不是"能写代码就写代码"。只有能够被规则完整描述、并能跨任务复用的操作，才应该进入 harness；需要理解语境和权衡证据的工作，仍然交给模型。全文的核心洞见不是用代码取代模型，而是把两类工作分给更合适的执行者。
判断标准不是"模型能不能做"，而是这项工作能否被规则完整描述并跨任务复用。
门禁回滚：防止"修好一个、坏了一批"
单纯联合修复一批失败还不够，因为一次修复很可能顺手改坏了之前已经跑通的能力——这在持续优化里是个常见坑，论文引用了 Wang et al. (2026) 关于"agent 优化器的收益是否可复合累积"的研究来支撑这个担忧。
解法是 留出集门禁 ：训练集和最终评测集之外，单独保留 50 个门禁任务。候选 harness 在当前失败窗口上通过验证后，还要在门禁集上重新运行。
只有门禁成功率不低于上一个已接受版本，候选才会正式生效。否则，上次通过门禁之后的整段修复都会回滚；恢复的不只是代码，还包括任务游标、失败窗口和尝试计数。
论文把这条规则称为"成功优先"： 成本降低不能抵消成功率下降。 哪怕新版本更省钱，只要门禁分数下降，就必须撤回。
失败轨迹负责指出该改哪里，门禁负责决定修改能否进入共享 harness。
任务与评测设定：两个基准怎么搭的
评测用了两个第三方公开基准，不是作者自己攒的数据：BrowseComp-Plus（一个开放域深度检索基准，用固定、人工验证过的检索语料库）和 WebArena-Verified（一个多步网页操作基准，任务经过审计修正，配确定性评测器）。WebArena-Verified 这次限定在 shopping、reddit、map 三类网站的任务，按意图模板、任务类型、网站做分层抽样，保证覆盖面均衡。
两个基准都划分为 200 个训练任务、50 个门禁任务和 50 个最终评测任务 。优化器全程不接触最终评测集的结果或轨迹，从而避免"偷看答案"。
部署模型覆盖三种规模：gpt-oss-120b、gpt-oss-20b、以及 Qwen3.5-4B，参数量跨了 4B 到 120B 三十倍。训练阶段用的部署模型和优化器模型是分开配置的（比如 BrowseComp-Plus 训练时部署模型是 gpt-oss-20b，优化器是 GPT-5.6-terra），这也符合直觉：训练阶段需要一个更强的模型来写代码、诊断失败，部署阶段可以换回一个便宜的小模型跑日常任务。
对照基线方面，通用基线是 Tool-Calling（固定的 ReAct 式工具调用循环，不学习），BrowseComp-Plus 上额外对比 Self-Ask 和 IRCoT，WebArena-Verified 上额外对比 WebDreamer 和 AgentOccam。所有方法在同一 benchmark 内共用部署模型、任务划分、工具接口和评测协议，保证比较是公平的。
每个"方法—模型"组合独立运行 3 次，每个任务只尝试一次，不做多次取最优。主指标是成功率，效率指标包括调用次数、输入与输出 token、耗时和在线成本。
成本核算只包括部署 agent 的 LLM 调用，不包括评测器与离线优化器。也就是说，论文报告的"成本降低"是 部署期成本 ，不是训练和部署的总成本。所有指标都通过任务级重采样估计 95% 置信区间，而不是只报告简单标准差。
主要结果：数字说明了什么
先看整体格局：六个"基准×模型"组合中，Growing Harness 有五个取得最高平均成功率。唯一没有领先的组合是 BrowseComp-Plus 与 gpt-oss-20b：成功率 39.3%，只比 Tool-Calling 的 40.0% 低 0.7 个百分点。
这个结果配合效率数字才真正有意义：相对 Tool-Calling， LLM 调用次数减少 76.0%—91.8%，在线推理成本下降 74.4%—98.6% 。Growing Harness 用接近十分之一的调用次数，获得了相当甚至更高的成功率。
最有意思的一组数字出现在 WebArena-Verified：Growing Harness 在 120B、20B、4B 三种模型上的成功率都稳定在 44.7%—45.3% 之间，几乎不受模型规模影响。Tool-Calling 则从 120B 模型的 30.0% 一路跌到 4B 模型的 6.7%。
小模型不擅长在推理时临场重构复杂的浏览器控制逻辑，例如判断页面是否加载完成、如何处理弹窗、什么时候点击哪个按钮。Growing Harness 把这些控制写进代码后，小模型只需处理任务特定的语义判断，因而显著降低了系统对模型规模的依赖。
对端侧或成本敏感部署来说，信号很明确： 控制逻辑代码化，可以让小模型在特定任务族里接近大模型的效果。
附录中的收敛分析也很有意思。BrowseComp-Plus 最终长出一条所有任务共用的"检索—证据验证"流水线，因为这类任务的控制逻辑高度共享；WebArena-Verified 则长出一个通用浏览器循环，再加上针对不同网站的专门分支。
两个 harness 从相同的空脚手架出发，却长成不同形态。这正是"低先验承诺"的意义： 控制结构应该由任务反馈塑造，而不是提前拍板。
三项消融：为什么缺一不可
消融实验都在 BrowseComp-Plus 上进行，部署模型固定为 gpt-oss-20b，优化器固定为 GPT-5.6-terra。完整方法成功率为 36.0%；去掉函数级引导后降至 18.0%，去掉门禁回滚后为 22.0%，把失败窗口容量缩到 1 后为 28.0%。
三个变体都变差了，但 变差的方式不同 。这正是消融实验的价值：它揭示了三个组件分别在阻止哪种失败。
去掉函数级引导： 成功率从 36% 降到 18%，前五步优化的门禁分数完全没有进展。如果优化器可以无约束地修改整个程序，失败信号就无法精确指向相关代码，搜索空间也会迅速膨胀。这说明 局部化编辑不是为了省算力，而是为了让优化本身可行 。
去掉门禁回滚： 门禁成功率先升到 30%，随后跌回 16%。系统解决了当前失败，却破坏了先前学到的能力。这说明 没有门禁保护，程序会越改越"聪明"，也越改越脆弱 ，局部收益无法稳定累积。
砍掉失败窗口： 系统没有明显停滞或倒退，但最终成功率比完整方法低 8 个百分点。每次只修一个失败样本，很容易写出只对该样本有效的规则。窗口机制迫使优化器寻找多个失败共有的问题，因此 联合修复的主要作用是防止对单个样本过拟合 。
跟哪些方案划清边界
这套方法跟几条常见路线的差异值得单独摆出来，不然容易被简单归为"又一个 Agent memory 方案"：
| 方案类型 | 代表方法 | 与 Growing Harness 的区别 |
|---|---|---|
| 固定 ReAct / Tool-Calling 控制器 | ReAct、Self-Ask、IRCoT | 循环结构部署前就定死，控制决策仍靠模型每次在文本历史里重新算一遍 |
| 文本经验 / 检索工作流 | ExpeL、Agent Workflow Memory | 经验以自然语言存下来，用的时候还得靠模型检索并重新解读，占用上下文 |
| 单个 executable skills | Voyager、LATM、CRAFT | 把某个具体行为打包成一个技能，挂在既有 Agent 结构背后，不改变整体控制流程 |
| Prompt / 程序优化 | DSPy、GEPA、AFlow、ADAS | 优化的是提示词、模块或工作流结构，通常在已定的接口和结构内调整 |
| 成本优化 | LLMLingua、FrugalGPT、RouteLLM | 让调用更短更便宜或换更便宜的模型，不改变控制逻辑本身 |
| Growing Harness | 本文 | 从空脚手架开始，让整个控制结构从失败反馈里生长出来，带回滚保护 |
这张表格的核心信息可以压缩成一句话：前面几条路线都在 已有的控制结构 中做局部优化，只有 Growing Harness 把控制结构本身开放出来，让它从任务反馈中生长。这也是它需要门禁回滚的原因：可修改范围理论上覆盖整个程序，风险自然更大。
局限：别急着把这套方案搬进生产
论文自己说得很克制，这几点局限值得认真对待。
第一，它学到的是 同分布任务族内的可复用控制 ，不是跨领域的通用自我进化能力。BrowseComp-Plus 和 WebArena-Verified 分别训练出的 harness 形态完全不同，换一个任务族基本等于重新训练。如果业务任务持续变化，这套方法能够获得的复用收益会大幅降低。
第二，论文明确说方法的价值"取决于学到的 harness 是否被充分复用，从而抵消离线优化的成本"。部署期成本降低不等于总拥有成本自动降低——训练阶段需要跑多轮执行、调用更强的优化器模型，这部分开销论文的成本核算里根本没算进去（Total Online Cost 明确排除了优化器和评测器调用）。如果任务量不够大，训练投入可能永远摊不平。
第三，benchmark 环境与真实生产仍有明显距离。真实部署需要沙箱、明确的权限边界，以及对生成代码的安全审查，这些都不在当前实验范围内。自动生成并执行代码本身也带来供应链风险：即使只是无意引入的 bug，门禁回滚也只能阻止"成功率下降"这类可观察退化，无法发现门禁集合没有覆盖的安全隐患。
第四，成功优先门禁只能保护门禁集合覆盖的能力， 不能证明"没有回归" 。门禁集只有 50 个任务，回滚机制看不到集合之外的边角场景。工程落地时，门禁集如何选择、是否具有代表性，直接决定了系统的安全边界。
工程落地：三层递进走
如果真想把这个思路搬进自己的 Agent 系统，比较靠谱的路径不是直接上自动生长，而是分层递进。
第一层，先把函数级轨迹和成本记录做起来——不管有没有优化器，先把每次执行的调用路径、耗时、token 消耗全部留痕。这一步投入不大，但收益立竿见影：光是看清楚"哪些控制决策在反复重复发生"，就已经能发现不少可以手动优化的点。
第二层，人工挑出高频且稳定的控制逻辑，手写代码化。哪些适合代码化，论文其实给了清晰的边界：解析、去重、重试、状态机、结构校验、终止条件——这些都是规则明确、跨任务稳定的操作，写成代码风险很低、收益很高。哪些该继续留给模型：歧义解释、证据权衡、开放式综合——这些依赖上下文语义，写成规则容易翻车，硬代码化反而会引入新的脆弱点。
第三层，等前两层跑顺了，再考虑上带回滚门禁的自动增长机制。这一步的前提是你已经有稳定的门禁集、稳定的评测协议，并且清楚训练成本能不能被后续复用摊平。跳过前两层直接上自动生长，大概率会在生产环境里踩到局限部分提到的那些坑。
工程顺序应该是先记录轨迹，再人工固化高频控制，最后才开放自动修改。
结论
回到开头的问题：什么根本不该再让模型现场思考？Growing Harness 的答案不是用代码取代模型，而是把任务族中确定性强、可复用的控制决策沉淀成代码，把真正需要开放判断的部分留给模型。
76.0%—91.8% 的调用减少、74.4%—98.6% 的部署成本下降，以及小模型在特定任务族中接近大模型的成功率，都是实在的收益。但它利用的是同分布任务的重复红利；训练成本没有计入部署成本，门禁也只保护它看得见的能力。
所以问题留给你： 你手头的 Agent 系统里，有没有哪部分"推理"早就应该成为一段稳定代码，只是你还没意识到它已经重复了几百次？
本文部分内容由 AI 辅助生成，经人工审校和补充后发布。
参考资料
- Laizhen Li, Jiarui Li, Juanjuan Zhao, Kejiang Ye, Ye Li, Cheng-zhong Xu, Xitong Gao，2026，Grow the Harness, Not the Context: From Strategy-Free Scaffolds to Reusable Specialist Agents，arXiv:2609.26760，https://arxiv.org/abs/2609.26760
- Chen et al.，2025，BrowseComp-Plus: A More Fair and Transparent Evaluation Benchmark of Deep-Research Agent，arXiv:2508.06600，https://arxiv.org/abs/2508.06600
- Amine El hattami, Megh Thakkar, Nicolas Chapados, Christopher Pal，2025，WebArena Verified: Reliable Evaluation for Web Agents，Workshop on Scaling Environments for Agents，https://openreview.net/forum?id=94tlGxmqkN
- Shunyu Yao et al.，2023，ReAct: Synergizing Reasoning and Acting in Language Models，ICLR 2023，https://arxiv.org/abs/2210.03629