：从 ACE 到 Self-Harness、Meta-Harness、AHE——把 prompt、上下文、工作流和 harness 代码依次送上优化台之后，我们到底在优化什么

为什么这个话题现在值得写

过去两年，我们对“怎么让 Agent 变强”的直觉，几乎全是围绕模型本身。但一个越来越难忽视的事实是：同一个基座模型，换一套 harness，分数可以差出几十个百分点。 而 harness 这一层——system prompt、工具定义与实现、中间件、技能、子 Agent 配置、长期记忆、验证规则、权限策略、运行时控制流——直到最近还几乎完全由人类工程师手工调。

这个范式有两个明显的天花板。第一，它不可扩展：不同模型的行为习惯、工具使用偏好、错误模式差异很大，一套对 A 模型好用的 harness 换到 B 模型身上可能反而有害；而模型迭代速度远快于人工重调 harness 的速度。第二，它的归因是模糊的：一个 rollout 失败了，到底是模型不行，还是 harness 少了某条恢复规则？人往往是靠经验猜。

于是“让 Agent 自己去改这层壳”成了一个自然的方向。有意思的是，这条线上真正扎实的工作并不是孤立的，它们恰好沿着一个被逐步下推的优化对象序列在走。这大概是这篇文章最想讲清楚的一件事。

一、一条主线：被优化的对象在逐级下推

把近几年和“自我改进”沾边的工作排一排，会发现它们优化的东西越来越“深”：

指令 prompt → 结构化上下文 → 工作流 → harness 代码 → 优化器本身

这个序列不是简单的“越来越大”，而是越来越通用、越来越少手工启发式。越往下，能触达的设计空间越大，同时也越难验证。

1. Prompt 之后是上下文：ACE 与 MCE

最朴素的做法是让模型改自己的提示词，但这很快撞上两个问题：上下文越滚越长、以及反复改写导致的“上下文坍塌”（信息在多次摘要中丢失）和简洁性偏置（模型倾向于越写越短、丢掉细节）。

Agentic Context Engineering（ACE） 的解法是把上下文当成一本持续演化的战术手册，而不是一段不断加长的 prompt。它拆成三个角色：Generator 按现有条目产出轨迹，Reflector 从成功和失败轨迹里提炼洞见，Curator 只产出结构化的、带标识符的条目（identifier + description），再由确定性逻辑合并进手册，定期去重精炼。关键设计是 Curator 从不整体重写 prompt blob——这一条直接掐住了上下文坍塌的根源。

但 ACE 的更新规则和工作流本身还是人写的。Meta Context Engineering（MCE） 往下走了一步：把“怎么管理上下文”的机制（skill）和“上下文里具体放什么”（内容）分层，做双层优化——内层在给定 skill 下找最优上下文函数，外层在验证集上搜索最优 skill，并用一个元级 Agent 对历史 skill 做 agentic crossover。上下文函数在实现上就是一个目录里的文件集合（skill.md 静态部分 + 动态 rollout 产物），元级和基座级都在标准 agentic coding 环境里跑。

2. 工作流本身成为搜索空间：ADAS 与 AFlow

再往下，工作流设计也可以交给算法。ADAS（Automated Design of Agentic Systems） 把 agent 设计本身表述成优化问题：维护一个工作流归档，让 meta-agent 参考归档里的现有方案去写代码造新 agent，每个草稿再过两轮 self-refine 检查新颖性，评估通过的回填归档，迭代。AFlow 把工作流表示成图（节点是 LLM 调用动作，边是代码里的逻辑操作），用 MCTS 在图上搜索，按分数与均匀探索的软混合选节点、扩展、执行、按改进回填。这类实验里，自动搜出来的工作流确实能超过人工设计。

这两条工作的共同信仰其实很朴素：代码是定义系统最通用的语言。既然 harness 本质就是一段编排 prompt、工具调用、子 Agent、控制流、记忆和工作流的程序，那么只要模型会改代码，它就能触达远超手写 prompt 的设计空间。

3. Harness 代码级优化：Meta-Harness 与 STOP

Meta-Harness 再往下钻一层，它优化的对象是决定“存什么、取什么、给模型看什么”的那段代码——名字里的“Meta”就是指“用来优化 harness 的 harness”。它的 proposer 本身就是个 coding agent，整个执行历史都挂在文件系统上，proposer 用 grep、cat 去翻，而不是把所有东西塞进一个 prompt；每个候选 harness 是文件系统里的一个字典，装着源码、分数、rollout 轨迹和状态更新；循环不断造新 harness，只保留合格的，最终输出 Pareto 前沿上的候选集合。

更早的 STOP（Self-Taught Optimizer） 则是递归脚手架改进的经典样本：优化对象不是解本身，而是那个“改进器”函数。实验里改进后的改进器自己发现了遗传算法、分解改进、多臂 prompt bandit、模拟退火、温度变化、beam/tree search 等策略。

但 STOP 有一个我觉得最值得反复引用的负面结果：迭代在 GPT-4 上带来均值提升，在 GPT-3.5、Mixtral 这类更弱的模型上反而退化。结论很硬——递归结构本身不等于改进，基座模型必须足够强，才配得上“改机制”这件事。

二、真正难的不是“改”，是“知道该改哪里、并且真的改对了”

如果只看到这里，会以为问题已经解决了。实际上，harness 自我优化的核心难点全在闭环的两端：证据从哪来，功劳怎么记。

Self-Harness：闭环内化 + 保守晋升

Self-Harness 问的是一个很收敛的问题：不借助更强的外部 agent、不依赖人类工程师，同一个固定模型能不能在自己当前的 harness 下，提出有界的修改，改善自己未来的行为？它跑三段循环：

  • Weakness Mining（弱点挖掘）：用当前 harness 跑任务、收轨迹，把失败按“验证器可判定的失败签名”聚类。签名是三元组：验证器的终端失败原因 + 相关 agent 行为的因果状态 + 轨迹暴露出的抽象 agent 机制。这一步的意义在于，超时和产物缺失这类表层症状可能共享同一个验证器结果，但因果机制完全不同——只有三元组一致才归为一类，保证聚出来的失败簇“确实可以被同一种 harness 干预解决”。
  • Harness Proposal（提议）：同一个模型换到 proposer 角色，输入是一份有边界的提议上下文——可编辑表面的定义、聚类后的失败模式、需要保留的通过行为记录、以及历史被拒提议的摘要。要求是分支之间尽量多样，单个分支内部尽量最小：一个提议只改解决该机制所需的那点表面，不动整体控制架构。而且有个很务实的筛选：只挑可归因于 harness的失败，任务本身太难、结果不稳定、模型能力上限导致的失败要明确排除，而不是硬打补丁。
  • Proposal Validation（验证）：候选必须在 held-in（检验弱点是否真的被解决）和 held-out（检验有没有引入未知回归）上都达标，规则是“至少一侧提升且另一侧不退化”——只做权衡交换的提议一律拒掉；随机性场景要重复评估取聚合通过数，避免单次好运被提拔。通过的合并进下一版，被拒的记档但不改变生效 harness。

在 Terminal-Bench-2.0 的 64 题子集上，从同一个极简 DeepAgent harness 出发，三个不同家族的模型 held-out 通过率分别是 40.5%→61.9%（MiniMax M2.5）、23.8%→38.1%（Qwen3.5-35B-A3B）、42.9%→57.1%（GLM-5），提升幅度最高 21.4 个百分点。

更有信息量的是改了什么：模型不同，学到的 harness 也明显不同。MiniMax M2.5 学到的是“更早创建要求的产物文件、更小心处理结构化工具输出、在无效工具循环变长前停手”；Qwen3.5-35B-A3B 学的是“提前检查依赖、避免重复执行失败命令、打断无限探索、工具报错后仍要记得产出产物”；GLM-5 学的是“跨 shell 命令保留环境设置、更快从探索转入实现与测试”。而且它还能造出超出局部补丁的结构性机制，比如基于子 Agent 的分解、新增中间件。

这其实是 Self-Harness 最有说服力的部分：它产出的不是更长更泛的 prompt，而是把模型特定的弱点翻译成了可执行的 harness 变更。

AHE：把“可观测性”当成瓶颈

Agentic Harness Engineering（AHE） 的假设不太一样：harness 演化的瓶颈不在提案能力，而在可观测性——失败时你得知道是哪个组件该负责，每一次编辑都得有证据落地。它立了三根柱子：

  • 组件可观测：harness 被拆成 7 个组件（system prompt、工具描述、工具实现、中间件、技能、子 Agent 配置、长期记忆），每个在文件系统里都有表示，动作空间显式可追踪；每种失败模式映射到具体组件，让编辑更有靶向性。
  • 经验可观测：不把海量原始轨迹直接喂给模型，而是分层——先用一个“Agent debugger”针对每份轨迹文件生成单任务根因报告，再把报告聚合成 benchmark 总览，需要时再回钻原始轨迹。这种分层访问结构在 token 效率上明显更优。
  • 决策可观测：每一次编辑都配一个对下一轮的可证伪预测。“Evolve agent”读仓库决定改哪个组件，产出编辑和理由，形式是文件级的、可证伪的主张。这里有条硬约束我觉得是全文最关键的设计：编辑只能作用于 harness workspace，runs 目录、tracer、verifier、LLM 配置全部只读——这一刀直接禁掉了一整类 reward hacking（关验证器、换模型、偷偷抬高 reasoning 预算），从而保证记录下来的收益确实可归因于 harness 编辑。

在 Terminal-Bench-2 上，AHE 超过了人工设计的 harness（OpenCode、Terminus-2、Codex），除了 Hard 档和少数几个自我演化基线。更值得注意的一点是：同一个演化出来的 harness 冻结之后，不做进一步演化直接迁移到 SWE-bench-verified 仍然有效——说明它把工程经验编码进了 harness 组件，而不是在做 benchmark 特化。

一个不同领域的佐证：AdaHVLA 的归因门

在长程视觉-语言-动作（VLA）任务里，有一篇 AdaHVLA 做了结构上高度相似的事：不动 VLA 参数，改的是那层可编辑的、基于代码的协调策略——决定 VLA 每次收到什么 observation 和 history、何时推进目标、纠偏指导何时开始与结束、何时算完成。

它的三个做法和上面互相印证：一是三个 agent 用隔离的工作上下文（证据分析、代码修改、行为评估各干各的，交换结构化记录而非共享对话历史），避免“改代码的人顺便当裁判”；二是先写下可检验的协调假设（机制、支撑证据、预期行为效果、可观察指标）再动手；三是 attribution gate——只有“改的那处机制确实被触发”且“两条轨迹在触发前尚未分叉”时，这次的对比才允许用来更新假设的支持度。因为任务成败还受感知和控制影响，只看成功率会把功劳记错账。

结果上，NaVILA-LH 上初始 harness 22.5%，适应后测试成功率到 31.7–57.5%；三个 VLA backbone 的 manipulation 相对初始 harness 最多提升 30.8 个百分点，真机也验证了跨阶段执行。还有一个细节很有意思：harness 的适应能力和 adaptation model 的通用 agentic/coding 分正相关——这跟 STOP 那个“弱模型上会退化”的老结论接上了：这条路线目前仍然受限于“由谁来当修改者”。

三、四个我认为会决定这条路能走多远的问题

写到这里，其实争议点已经浮现。我把它们列成四个，也算给想动手的人一份检查清单。

1. 谁来保证归因是真的？
Self-Harness 用 held-in/held-out 双门 + 失败签名三元组；AHE 用只读边界 + 每次编辑附可证伪预测；AdaHVLA 用 attribution gate。三者手段不同，但都在回答同一个问题：收益到底是 harness 带来的，还是运气、任务难度、或者悄悄换了预算带来的？ 我的判断是，未来这条线上真正的分水岭不在“提案有多聪明”，而在“验证有多难被骗”。

2. 可编辑表面要设计成什么样？
如果允许一个程序去改自己的“OS”，抽象边界就破了。可行的做法是把可编辑表面收窄成声明式配置点（Self-Harness 只允许改 harness 定义文件）、或者明确的组件边界（AHE 的 7 组件），而权限控制和安全层必须活在循环之外。reward hacking 的全部老问题，在这里一个都没消失。

3. 基线能力仍然是最先受到限制的因素。
STOP 在弱模型上退化，AdaHVLA 显示适应效果与修改者能力正相关，这两条证据方向一致。递归结构救不了弱基座；harness 改进能让部署更好，但智能仍然是核心。

4. 失败候选要不要留？
AdaHVLA 维护 revision graph，把代码版本、假设、rollout 证据、评估结论链起来，失败的候选和被搁置的分支都可召回，而不是只跟着最新版本走。理由很实在：否则未解决的问题会和后面几轮改动纠缠在一起。Self-Harness 也是被拒提议一律记档但不生效。“能回滚到别的分支”这件事，在自我修改系统里不是可选项。

四、我的一点预测

关于这条路和递归自我改进（RSI）的关系，我倾向于一个偏保守的判断：近期的 RSI 路径不太可能从“模型直接重写自己的权重”开始。

更可能的是这样一条路径：

  1. harness 工程朝元方法论演进——优化的对象从“答案”转向“得到答案的机器”，启发式规则变少、通用机制变多。ACE 的固定更新规则被 MCE 的技能演化取代、人工工作流被 ADAS/AFlow 搜索取代，就是这个方向。
  2. 成熟的 harness 反过来成为模型自我改进的底座，而更强的模型又阻止 harness 过度工程化、让系统保持可持续——两者互为前提。
  3. 最终，很多 harness 改进会被内化进模型本身的行为，但“与外部上下文和工具交互的接口”会留下来。

第 3 点其实已经在 prompt engineering 上演过一遍了：手工的提示技巧随着指令微调和推理能力提升逐渐不再中心，但定义目标、约束、上下文和评估标准的需求从未消失。harness 大概会走同样的路——被吃掉一部分，剩下的部分变得更本质。

结语

这个方向最迷人的地方，不是“Agent 会改自己代码了”这种叙事，而是它逼着我们回答一个工程问题：当你把一个系统变成它自己的优化目标时，你靠什么相信它真的变好了？

上面所有工作给出的答案都指向同一件事——闭环、证据、可证伪、可回滚。四个词听起来平平无奇，但每一个都比“让模型多想一会儿”难实现得多。也许这才是 harness 自我优化真正要教给我们的东西。