AHE解读：让Coding Agent的工具、记忆与中间件自动进化
AHE解读：让Coding Agent的工具、记忆与中间件自动进化
摘要
提升 Coding Agent，常见做法是更换模型或继续修改系统提示词。但 Agent 的真实能力还取决于外层 Harness：工具接口、中间件、长期记忆、技能和执行约束。论文 Agentic Harness Engineering（AHE）提出一个可审计的自动演进闭环：固定基础模型，让另一个 Agent 根据任务轨迹修改 Harness，并用下一轮结果验证每次改动。实验中，AHE 经过 10 轮、约 32 小时演进，将 Terminal-Bench 2 的 pass@1 从 69.7% 提升到 77.0%，超过人工设计的 Codex Harness 71.9%。更关键的结论是，收益主要来自工具、中间件和长期记忆，而不是系统提示词。
背景：模型之外还有一个决定性能的系统
Coding Agent 并不是“模型加一个 Shell”。模型通过工具观察仓库、执行命令、编辑文件；中间件负责上下文、超时、恢复和结束条件；长期记忆保存跨任务经验；系统提示词规定行为边界。这些可编辑组件共同构成 Harness。
目前 Harness 优化主要靠人工：工程师阅读失败轨迹，归纳模式，再修改 Prompt 或工具。问题是，单次运行可能产生几十万 Token，失败原因分散在多轮操作中；多个组件相互耦合，又很难判断一次提升到底来自哪里。
AHE 的核心判断是：自动演进的瓶颈不是 Agent 不够聪明，而是缺少可观察、可归因、可回滚的工程表面。
技术要点一：把 Harness 拆成可版本化组件
AHE 基于 NexAU，将七类组件暴露成独立文件：系统提示词、工具描述、工具实现、中间件、技能、子 Agent 配置和长期记忆。组件放在固定工作区，修改形成 Git 提交，因此每个变化都有文件级 Diff 和回滚点。
这种拆分解决了两个问题。第一，失败模式可以映射到明确组件，例如命令执行缺少保护应修改工具或中间件，而不是继续堆 Prompt。第二，演进 Agent 的写权限被限制在 Harness 工作区，运行目录、验证器、模型配置保持只读，避免通过关闭测试、替换模型或增加推理预算“刷分”。
初始 Harness 刻意保持最小化：只有 Shell 工具，没有中间件、技能和子 Agent。新增组件必须通过后续实验证明价值。
技术要点二：把海量轨迹压缩成分层证据
直接把全部运行日志塞给演进 Agent，不仅成本高，也容易淹没真正的根因。AHE 使用 Agent Debugger 将每条消息保存为文件，对每个任务生成成功或失败分析，再汇总成基准级概览。
演进 Agent 先读总览，需要时逐层下钻到单任务报告和原始轨迹。这种渐进披露保留了可核验性，同时避免每轮重复消费数百万 Token。
这里的工程重点不是“让模型总结日志”，而是建立证据链：任务结果、根因分析、原始轨迹和组件改动能够相互追溯。没有这层结构，自动优化很容易变成基于印象的试错。
技术要点三：每次修改都必须提出可证伪预测
AHE 要求每项改动写入 Change Manifest，至少包含：
- 失败证据和推断根因；
- 修改的目标组件；
- 预计修复的任务集合；
- 可能回归的任务集合；
- 下一轮的实际验证结果。
下一轮完成后，系统将预测与任务级变化对照，对无效改动进行文件级回滚。这样，“这项修改应该有效”不再是自然语言理由，而是可以被下一轮数据否定的合同。
论文统计显示，修复预测的精确率为 33.7%、召回率为 51.4%，约为随机预测的 5 倍，说明改动并非完全盲试。但系统预测回归的能力明显较弱：精确率 11.8%、召回率 11.1%，多数副作用仍无法提前识别。
实验结果：真正有效的层不在 Prompt
AHE 在 Terminal-Bench 2 的 89 个任务上演进 10 轮，整体 pass@1 从 69.7% 提升到 77.0%。人工设计的 Codex Harness 为 71.9%，另外两种自演进基线 ACE 和 TF-GRPO 分别为 68.9% 和 72.3%。
组件消融更有启发性：
- 只加入长期记忆：75.3%；
- 只加入演进后的工具：73.0%；
- 只加入中间件：71.9%；
- 只替换系统提示词：67.4%，低于初始 Harness；
- 全量 AHE：77.0%。
长期记忆记录了边界条件、结束检查和打包布局等可执行经验；工具会主动暴露邻近文件中的契约提示；中间件在结束前强制执行与验证器一致的检查。相比之下，孤立的 Prompt 纪律缺少工具和流程支撑，无法稳定落地。
演进后的 Harness 未重新训练，直接迁移到 SWE-bench Verified，整体成功率由 75.2% 小幅提升到 75.6%，Token 使用量从 526K 降至 461K。结果说明部分结构化经验可以跨任务迁移，但提升并不均匀，个别仓库存在退化。
研发视角：如何建立企业内部演进闭环
第一，将 Prompt、工具、权限策略、结束条件、记忆和技能分开版本化，不要把所有规则塞进一个超长系统提示词。
第二，为每个任务保存可重放轨迹，包括输入、工具调用、输出、资源消耗、最终产物和验证结果。缺少任务级结果，就无法判断改动是修复还是偶然波动。
第三，要求每个变更附带影响预测。评审时必须说明它针对哪些失败、可能破坏哪些场景，以及如何回滚。
第四，使用固定回归集与留出集。优化集用于演进，跨仓库、跨语言和极端长任务用于检查过拟合。
第五，权限必须单向收缩。演进 Agent 可以修改 Harness，但不能修改验证器、放宽沙箱、替换模型或增加预算。
风险与限制
AHE 仍是受控研究原型。演进只在 Terminal-Bench 2 上进行，迁移测试集中于 SWE-bench Verified；更多语言、真实仓库部署和人机协作流程尚未验证。实验的步数和超时预算针对特定模型设定，跨模型收益混合了 Harness 迁移与运行参数适配。
组件还会非线性交互。论文中长期记忆单独用于困难任务时优于全量 AHE，因为记忆、中间件和 Prompt 都推动重复的结束检查，叠加后反而消耗长任务预算。自动演进系统能够解释“为什么可能修好”，却仍不擅长预测“会破坏什么”。
因此，生产环境不应允许 Harness 无审批地持续自改。更合理的流程是自动提出变更、隔离运行、回归验证、人工审批后分阶段发布。
结语
AHE 的价值不是证明 Agent 可以无限自我进化，而是把 Harness 优化改造成可观察、可归因、可回滚的软件工程流程。对研发团队而言，最直接的启示是：下一次 Coding Agent 表现不佳时，先检查工具接口、执行保护、记忆和验证闭环，而不是默认继续改 Prompt 或升级模型。
参考来源
- arXiv 论文摘要：https://arxiv.org/abs/2604.25850
- arXiv HTML 全文：https://arxiv.org/html/2604.25850