Agent Harness 与 AI 自我改进的讨论（四）：总结与反思篇 ——读 Lilian Weng《Harness Engineering for Self-Improvement》

本系列前三篇主要围绕 RSI 与 Harness Engineering 的改进来展开。第一篇讨论了 Harness 为什么可能成为 RSI 的近期入口。第二篇从上下文和工作流出发，分析一次任务中的调整怎样被保留下来，继续影响后续任务。第三篇又把范围扩大到完整 Harness 和模型权重，讨论当前系统怎样参与生成下一版本，以及递归在这些过程中进入了哪里。

这条路线中，进入改进循环的对象不断增加，但“改变”和“改进”之间还有区别。当前系统能够参与生成下一版本，只能说明它具备了根据当前的表现进行闭环反馈的能力，关键要看改变之后，系统在任务上的表现是否真的变好了，为此我们还需要继续分析。

作为这个系列的最后一篇，本文回到 Self-Improvement 中的 Improvement。我们将从任务结果出发，讨论为什么自我修改未必带来自我改进，改变需要经过哪些检查才能被称为改进，以及评价、长期收益和权限边界为什么会决定这种改进能否持续。

上一篇在Harness整体自我改进的时候提到过 STOP，主要在讲把优化器也参与优化。我们回想在优化问题的数学模型中，优化器是把当前的一些参数朝着更优的方向进行一次调整，STOP则是把Harness的优化规则也纳入了优化的范畴里，就类似从梯度下降法改成牛顿法。但论文里其实提到一个不寻常的现象，同一套循环换一个基础模型，最后的表现可能完全相反。使用 GPT-4 时，多轮修改让留出任务上的平均表现逐步提高；换成 GPT-3.5 和 Mixtral，表现反而下降。文章对此的解释是，较弱模型确实也能提出合理的改进思路，但写出的代码过于简单，甚至带有错误，下一轮还会以这些代码为起点继续修改，导致缺陷会累积，表现下降。这个问题可以归纳成，模型想到了可行的改法，却没有把它正确实现。

还有一种情况也容易被忽略，系统生成了有用的 Skill 或运行规则，执行任务的 Agent 却不知道何时调用，或者无法在长任务中一直遵循。论文《Harness Updating Is Not Harness Benefit》把“生成修改”和“从修改中获益”分开研究。Harness updating 关注模型能否根据执行证据提出有用的修改，Harness benefit 则看任务 Agent 使用修改后的 Harness 后，表现有没有提高。

研究者在软件修复、MCP 工具使用和 Skill 执行三类任务上交叉组合了不同模型。他们先固定任务 Agent，只替换负责修改 Harness 的 Evolver。七个模型产生的收益很接近，每项评测中，最好与最差 Evolver 的差距都没有超过 3.1 个百分点。接着固定 Evolver，让不同的任务 Agent 使用同一套更新结果，差异才明显拉开。较弱模型经常没有加载相关 Skill，即使加载了，也很难在较长的执行过程中一直遵循；强模型原本已经解决了不少任务，继续提高的空间有限；中间能力层的模型反而获得了更明显的收益。

这两篇文章说明了，能生成优化方案还不够，要看这个方案能不能正确执行。模型写出了新的 Memory、Skill、Prompt 或 Harness 代码，只能说明更新已经发生。这些内容能不能在后续任务中被正确调用，又能不能带来更好的结果，还要单独验证。判断一次变化是否构成改进，也就要继续追问它为什么发生、改了什么，以及改完以后怎样证明结果更好。

前面我们提到，修改后原有任务做得更好，这次变化才算带来了改进。改进的过程大致可以分成三步：找到问题，有针对性地修改，再回到任务结果上验证。

博客里提到，Self-Harness 和 Agentic Harness Engineering（AHE）都涉及了这三个步骤的划分：系统因为什么失败而改，具体改了哪部分 Harness，改完以后任务结果如何。正因为这条过程保存得比较完整，它们可以作为参照，帮助我们判断一次系统变化有没有成为改进。

1. 从失败中归纳原因

同样是一次任务超时，模型可能在反复运行失败命令，也可能长时间浏览文件，或者在工具报错后找不到恢复路径。所以失败原因分析很重要，只有找到了当前失败的原因才能知道系统的哪些部分是需要调整的，也避免了一察觉到失败就立刻追加规则造成的规则熵增。

Self-Harness 文章明确提到了根因分析这个步骤，遇到问题会分析失败轨迹，找到根因，再决定应该修改哪部分 Harness。

AHE 文章则进一步要求系统把失败分析写进运行记录。每次提出修改，系统都要写明它对应哪项失败、怎样判断根因、准备修复什么，还要预测哪些任务可能因此退步。下一轮任务结束后，这些判断可以和实际结果逐项核对。每次修改 Harness 时，Evolver 都会列出它预计能够修复的任务，以及可能因此退步的任务；下一轮运行结束后，再将两组预测与实际结果对照。九轮评测中，修复预测的精确率和召回率分别为 33.7% 和 51.4%，相应的随机预测基线为 6.5% 和 10.6%，说明 Evolver 对哪些任务可能改善已经有了一定判断。退步预测的精确率和召回率分别为 11.8% 和 11.1%，相应的随机基线为 5.6% 和 5.4%。这两个指标同样高于随机预测，但大多数回归仍未被提前发现。AHE 目前更容易判断一项修改可能解决哪些任务，还很难判断它会破坏哪些任务。

2. 修改范围精确到组件和版本

找到失败原因以后，修改还要落到明确的组件和版本。如果新版本同时换了模型、增加了推理预算、开放了更多工具，任务表现提高以后，我们很难知道是哪项变化起了作用。Self-Harness 会先限定哪些 Harness 部分可以编辑，再让模型围绕具体失败提出较小的候选修改。AHE 则固定模型配置、运行记录和验证器，只允许 Evolver 修改 Harness Workspace。所以在修改前后也需要像“控制变量法”一样，以版本控制的形式固定一些配置不变，然后针对性地修改Harness中的组件，再去判断修改是否有效。

3. 回到任务中验证结果

找到了问题，也知道具体改了哪里，最后就要看任务表现。Self-Harness 中，模型根据前面的失败分析提出修改后，不会立即替换当前 Harness。这些修改会先形成候选版本，再分别接受两组任务的测试。第一组任务是 held-in tasks，用于检查候选的修改是否解决了已经暴露的问题；第二组任务是是 held-out tasks，检查这个候选修改是否会使其他能力发生退步。候选版本只有在至少一组任务上有所提高，同时没有让另一组退步时，才会被合并进下一版 Harness；没有通过的修改只留下记录，不会影响当前版本。

不过，held-out tasks 的执行轨迹虽然没有进入失败分析，它们的评测结果仍然会在每一轮用于候选选择，实际作用更接近验证集。系统结束更新以后，还需要换一批新任务再测一次，继续检查修改有没有过度适应当前的评价环境。

有了这些判断依据，我们就可以客观评价网上越来越多的“自进化”。一些项目，让 Agent 生成新的 Memory、Skill 或 Harness，这些内容只能说明系统发生了变化。自我改进的证据在于修改来自真实任务中的问题，改完后的任务表现也得到提高。

如果讨论只停在一次 Harness 更新，我们面对的仍然是一次普通优化。RSI 真正困难的地方，在于系统要根据当前版本的结果继续产生下一版本，并让多轮修改逐渐积累成长期收益。Lilian Weng 博客的 Future Challenges 这部分就在讨论这个问题。

1. 评价器可能给出错误方向

博客把这类问题称为 Weak and fuzzy evaluators。目前 Harness 优化在代码、数学和可执行环境中进展较快，主要因为这些任务通常能获得较明确的反馈，例如程序能否运行、测试是否通过、答案是否正确。但在此之外的大多数领域，例如科研的品味、创新性、长期商业价值以及大量企业任务，很难获得同样清晰的评价。

即使这类问题中的评价指标确实存在，它衡量的内容也可能比真实目标窄。单元测试只能检查已经写进测试的行为，Judge Model 带有自己的判断偏好，Benchmark 也可能留下可以利用的模式。系统会“想尽一切办法”寻找提高当前分数的方法，最后可能越来越适应评价器，而没有改善我们真正关心的任务，这就是 Reward hacking。回归集可以检查旧能力有没有下降，却不能证明评价目标本身选对了。

2. 当前收益未必能积累成长期收益

短期任务适合在隔离环境中反复执行和比较，长期影响往往要过一段时间才会显现博客里的 Long-term success 讨论的就是这个差距。Lilian Weng 用 Coding Agent 举了一个很实际的例子。智能体完成眼前的 Issue、通过仓库测试，通常可以在隔离环境中评价；这次修改对代码维护性、兼容性、迁移成本和未来调试负担的影响，要经过更长时间才会出现。每一轮都选择当前得分更高的 Harness，整个系统仍可能逐渐积累技术债或丢失原有能力。

长期结果还取决于系统怎样处理搜索路线和历史经验。失败尝试如果没有被保存下来，系统就很难知道哪些方向已经走不通，这对应原文的 Negative results。系统如果总沿着当前高分的版本修改，候选会逐渐收敛成相似的方案，这又会造成 Diversity collapse。随着记忆不断增加，Context and memory lifecycle 还要求系统处理过期、冲突和重复的内容。一次修改的通过率提高了，并不能替这些长期选择提供答案。

3. 改进循环需要相对稳定的边界

修改范围扩大以后，系统获得了更多优化空间，也更容易改到支撑评价与安全的基础设施。Lilian Weng 在 Reward hacking 中提出，评价器和权限控制应该放在 Harness 的演化循环之外。程序如果可以同时修改 Harness、验证器和底层运行环境，我们很难判断新版本提高了任务能力，还是改写了评价方式。AHE 对此给出了一个现实参照。Evolve Agent 只能写入 Harness Workspace，运行目录、Tracer、Verifier 和模型配置保持只读，初始系统提示词也不能删除。这样一来，系统可以修改工具、记忆和运行逻辑，却不能通过更换模型、扩大预算或绕过验证来获得表面上的提升。

评价器和权限控制留在循环之外，不意味着它们永远不变。任务目标会调整，旧评价也会失效，只是这些变化需要另一套受控流程，并保留独立测试、轨迹审计和人工审核。博客最后一项挑战 The role of humans（https://lilianweng.github.io/posts/2026-07-04-harness/#future-challenges） 讨论的正是人的位置。人的工作会从逐次修改 Prompt 或规则，逐渐上移到设定目标、选择评价标准、划定权限范围和审核高风险更新。Lilian 所说的“move up the stack”，在这里才有具体含义。

到这里，如果直接要求企业建设一套自动改进的 Harness、甚至更新模型权重的系统，可能还是无从下手。我们还是应该把目标收窄一些，企业要先建立一套能够判断 Agent 有没有变好的基础。

一套 Agent 系统至少应该回答五个问题。

1. 最近哪些任务做得不好？
2. 这些失败来自什么原因？
3. 哪一部分 Harness 值得修改？
4. 修改后，相关任务表现提高了吗？
5. 原有能力有没有退化？

Trace 和可观测性提供第一手执行证据，失败分析把表面错误还原到具体行为和组件，Eval 与 Regression 比较修改前后的差异，版本管理和 Rollback 则让无效修改可以退出 active harness。缺少这条链路时，自动生成更多 Skill 或反复重写 Prompt，只会扩大系统中的可变部分，团队仍然不知道哪个版本更可靠。

这套基础可以先以人工改进的形式投入使用。工程师查看失败轨迹，提出小范围修改，在离线任务和回归集上验证，再通过审批或灰度发布进入生产。等证据记录、候选比较和回滚机制稳定下来，Agent 才适合接管其中一部分重复工作。自动化程度提高以后，每一项修改仍应留下同样的证据和版本记录。企业近期值得建设的，正是这套能够观察、验证和回退的改进基础。

回看整个系列，前三篇沿着 Lilian Weng 的路线，讨论了 Harness 为什么成为 RSI 的近期入口，运行机制怎样开始变化，以及递归如何进入下一版本的生成过程。最后一篇增加了另一个判断维度。系统能够生成下一版本，说明它具备自我修改能力；下一版本能否在新的任务中取得更稳定的结果，决定这套系统是否真的在自我改进。

Lilian 的博客文章题目 Harness Engineering for Self-Improvement，真正重要的是 Improvement。修改要来自真实失败，能够落实到具体组件，并经过回归、迁移和长期运行的检验。评价与权限边界也要保持相对稳定，让收益可以被归因，偏离目标的修改能够及时停止。

做到这些以后，“自我改进”才有了可以检查的工程含义。在此之前，“自进化”可以描述系统正在发生变化，还不能替代任务表现的证据。

参考文献

1. Lilian Weng, “Harness Engineering for Self-Improvement”（https://lilianweng.github.io/posts/2026-07-04-harness/）, 2026.
2. Eric Zelikman et al., “Self-Taught Optimizer (STOP): Recursively Self-Improving Code Generation”（https://arxiv.org/abs/2310.02304）, COLM 2024.
3. Minhua Lin et al., “Harness Updating Is Not Harness Benefit: Disentangling Evolution Capabilities in Self-Evolving LLM Agents”（https://arxiv.org/abs/2605.30621）, 2026.
4. Hangfan Zhang et al., “Self-Harness: Harnesses That Improve Themselves”（https://arxiv.org/abs/2606.09498）, 2026.
5. Jiahang Lin et al., “Agentic Harness Engineering: Observability-Driven Automatic Evolution of Coding-Agent Harnesses”（https://arxiv.org/abs/2604.25850）, 2026.