AHE：让Coding Agent的「外层骨架」自己长出来
一、问题的提出：模型在变强，Harness在靠手工
2026年的共识已经清晰：模型能力释放，依赖于一套精密的外部框架。这个框架就是Harness——系统提示词、工具集、中间件、记忆机制、技能包的统称。它决定了模型如何感知环境、调用工具、管理上下文、从失败中恢复。
但一个尖锐的矛盾正在形成：基础模型以月为单位迭代，Harness工程却仍高度依赖人工经验。Prompt工程师手写system prompt，DevOps工程师配置middleware，工程师团队反复调试tool schema——这是一个"模型能力快速进化，Harness实现缓慢人工追赶"的结构性落差。
复旦团队提出的Agentic Harness Engineering（AHE）试图回答一个核心问题：如何让进化代理联合且稳定地进化Coding Agent Harness的所有可编辑组件？
这个问题的难点不在"能不能让AI改prompt"，而在三个结构性障碍：
异构动作空间——可编辑组件横跨prompt、tools、middleware、memory等七种类型，每种类型有不同的编辑语法和约束；信号淹没——一次基准测试产生的原始轨迹可达数百万token，可行动的信号被埋在噪声里；效果归因难——改了一个middleware后成功率变了，但究竟是middleware的功劳，还是碰巧那轮任务的难度分布变了？
现有自动优化方法的局限性在于：Reflexion和Self-Refine只修订代理自身输出，不触及Harness结构；ACE和DSPy仅优化prompt单一表面；Voyager和AlphaEvolve编辑skill库但不触及完整Harness。AHE的突破在于 将完整Harness作为组合整体进行联合进化。
二、Harness不只是Prompt：七种组件的解耦设计
AHE建立在NexAU框架之上，将Harness解耦为七种正交组件，每种组件作为显式文件暴露于固定挂载点：
workspace/
├── code_agent.yaml # 代理配置（tools, middleware, params, sub-agents）
├── systemprompt.md # 系统提示词（Jinja模板）
├── LongTermMEMORY.md # 长期记忆（持久跨会话知识，可修改）
├── ShortTermMEMORY.md # 短期记忆（运行时管理，不可修改）
├── tool_descriptions/*.tool.yaml # 工具YAML定义
├── tools/ # 工具Python实现
├── middleware/ # 中间件Python实现
├── skills/ # 技能包
└── sub_agents/ # 子代理配置
解耦是关键设计。添加middleware无需编辑system prompt；添加skill无需触碰任何tool。每个失败模式可以cleanly映射到单一组件类，给进化代理提供了清晰的action space。每个逻辑编辑对应git历史中的一个commit，天然获得文件级diff和回滚粒度。
AHE的种子Harness H₀被 故意最小化：仅单个shell执行工具，无middleware、无skills、无sub-agents。这是一个反直觉但关键的设计——如果种子已经针对目标基准调优，后续编辑的归因就会被污染。最小化种子强迫AHE添加的每个组件都必须通过实测rolloutearn its place。
三、三个可观测支柱：从黑盒到白盒
AHE的核心洞察是：Harness自动进化的瓶颈不是agent能力，而是observability。一旦进化代理获得结构化上下文和清晰动作空间，它就能可靠收敛到更好的Harness设计。三个可观测支柱分别对应工程循环的三个阶段：
3.1 组件可观测性：文件级显式表示
将Harness组件从黑盒内部状态转化为workspace中的显式文件。进化代理的action space不再是"往某个内部buffer里写文本"，而是"增删改某个具体文件"。这种显式化带来三个收益：action space可枚举、编辑效果可追踪、失败可回滚到文件粒度。
3.2 经验可观测性：从10M tokens到10K tokens
一次基准测试的原始轨迹可达1000万token，进化代理不可能消费。AHE设计了三层渐进式披露结构：
原始轨迹（raw trace）——完整消息日志，仅用于验证分析报告中的声明；任务级分析报告（per-task analysis）——每个任务的根因分析、通过/失败状态，为进化代理提供具体失败证据；基准级概览（benchmark-level overview）——从所有报告聚合的单一文档，作为每轮迭代的入口点。
Agent Debugger以并发度16、每任务600秒超时的配置执行分层蒸馏。原始轨迹被压缩约1000:1，进化代理先读overview.md，再读detail/{task_name}.md，最后才回退到原始轨迹——这种设计节省token，同时实现更好的代理决策。
3.3 决策可观测性：把每次编辑变成可证伪的合同
这是AHE最有工程智慧的设计。每次编辑附带一个Change Manifest条目，记录：失败证据（具体任务ID、失败模式）、推断根因、针对性修复措施、预测影响（预期修复的任务列表 + 可能回归的任务列表）。
下一轮迭代中，系统计算predicted-fix集合与实际任务级delta的交集，产生per-edit verdict。如果预测修复没有发生，或者预测回归发生了，编辑被回滚。这意味着 每次编辑都从一个自声明的预测开始，以可验证的结果结束——进化不再是trial-and-error，而是falsifiable contract。
两个约束保证决策可观测性不被破坏：可控性（进化代理仅在workspace内写入，runs目录、tracer、verifier、LLM配置只读，种子system prompt不可删除）阻止禁用verifier、更换模型等捷径；证据驱动+记录预测将每个编辑转化为可证伪的合同。
四、实验：从69.7%到77.0%，以及超越手工设计
4.1 Terminal-Bench 2主结果
| 方法 | All (89) | Easy (4) | Medium (55) | Hard (30) |
|---|---|---|---|---|
| OpenCode | 47.2% | 75.0% | 52.7% | 33.3% |
| Terminus-2 | 62.9% | 75.0% | 74.5% | 40.0% |
| Codex | 71.9% | 75.0% | 80.0% | 56.7% |
| NexAU₀ (种子) | 69.7% | 87.5% | 78.2% | 51.7% |
| ACE | 68.9% | 91.7% | 78.2% | 48.9% |
| TF-GRPO | 72.3% | 100.0% | 79.4% | 55.6% |
| AHE | 77.0% | 100.0% | 88.2% | 53.3% |
10次迭代，约32小时完成。AHE绝对提升+7.3pp，超越所有人工设计基线（Codex 71.9%）和所有自进化基线（TF-GRPO 72.3%）。Medium任务提升最大（+10.0pp），Hard任务唯一例外（53.3% < Codex 56.7%）——后文归因于组件间的冗余验证消耗了长horizon任务的turn budget。
4.2 消融实验： gain住在哪
| 组件单独替换 | All | Easy | Medium | Hard |
|---|---|---|---|---|
| + 长期记忆 | +5.6pp | - | - | 超越全量AHE |
| + 工具集 | +3.3pp | - | ≈全量AHE | - |
| + 中间件 | +2.2pp | 100% | - | - |
| + 系统提示 | -2.3pp | - | - | - |
三个正组件增益之和+11.1pp，大于全量AHE的+7.3pp——说明组件间存在非加性交互，冗余验证在Hard任务上相互抵消。消融还揭示了一个反直觉结论：系统prompt单独替换反而回归，说明AHE的system prompt编码的是通用discipline，其可执行性依赖于其他三个组件的存在。
4.3 SWE-bench-verified迁移
AHE evolved harness在不重新进化的情况下直接迁移到SWE-bench-verified：
| 仓库 | 任务数 | NexAU₀ | ACE | TF-GRPO | AHE |
|---|---|---|---|---|---|
| All | 500 | 75.2% | 74.6% | 74.2% | 75.6% |
| django | 231 | 79.2% | 79.2% | 78.8% | 81.0% |
| sympy | 75 | 70.7% | 69.3% | 68.0% | 70.7% |
| sphinx-doc | 44 | 68.2% | 61.4% | 65.9% | 70.5% |
ACE和TF-GRPO在SWE-bench上均低于种子基线，因为它们playbook/trajectory分布是terminal-bench上蒸馏的，跨任务surface时只增加成本不重塑策略。AHE却实现最高总成功率，且token消耗比ACE少32%，比TF-GRPO少21%，比种子少12%。
4.4 跨模型迁移：+5.1到+10.1pp
AHE evolved workspace在不重新进化的情况下迁移到多个替代模型家族：GPT-5.4 medium reasoning、GPT-5.4 xhigh reasoning、qwen-3.6-plus、gemini-3.1-flash-lite-preview、deepseek-v4-flash。最大增益出现在较弱模型上 ——说明AHE编码的协调模式（coordination patterns）对能力较弱的模型帮助更大，因为它们更依赖结构化的Harness支撑。
五、战略审视：Harness Engineering的范式转移
5.1 从"手写Prompt"到"可进化架构"
AHE的真正贡献不是某个具体的prompt或tool设计，而是 证明了Harness可以作为可进化架构来自动优化。这类似于从"手写汇编"到"编译器优化"的范式转移——工程师不再逐行调优，而是设计优化框架和约束条件，让系统自动搜索更优解。
5.2 可观测性作为设计第一性原理
AHE的框架设计可以作为其他agent系统自动优化的参考模板：组件可观测性要求action space显式化和解耦；经验可观测性要求原始信号的结构化蒸馏；决策可观测性要求预测-验证的闭环机制。这三条原则不限于Coding Agent，可推广到任何需要长期迭代的agent系统。
5.3 局限与开放问题
Hard任务的组件干扰：消融显示memory-only在Hard上超越全量AHE，说明当前进化算法缺乏组件间交互感知。未来的进化agent需要理解"memory和middleware都push向closure-style verification，stacking它们会 redundant re-check"，从而做出更智能的trade-off。
回归预测的盲区：进化曲线非单调，存在波动。AHE的predicted-regression集合与实际回归的交集并不完美——即进化agent对"什么会坏"的预测弱于对"什么会好"的预测。
种子最小化的代价：虽然最小化种子保证了归因纯净，但也意味着早期迭代的探索成本更高。如果允许一个"半优化"种子，是否能在更短时间内收敛？这是一个工程trade-off。
可扩展性：Terminal-Bench 2仅89个任务，SWE-bench-verified 500个任务。当基准规模扩大到数千甚至数万任务时，每轮rollout的成本和Agent Debugger的蒸馏延迟是否仍可控？
六、结论
AHE的定位不是"另一个prompt优化工具"，而是 Harness Engineering的自动化基础设施。它用可观测性三支柱将Harness进化从手工艺术转化为可审计、可回滚、可验证的工程流程。
实验数据支持一个核心结论：Harness的结构组件（tools、middleware、memory）比prose-level strategy（system prompt）更具迁移价值。这意味着Coding Agent的竞争力将逐渐从"谁写的prompt更漂亮"转向"谁的Harness架构更进化"——而后者可以被自动化。
当模型能力以月为单位跃进时，Harness的自动化进化能力将成为决定Coding Agent实际性能的关键变量。AHE提供了一个起点：不是让模型变得更强，而是让模型周围的骨架变得更聪明。
参考与延伸
- AHE 论文（arXiv:2604.25850）
- 代码仓库：https://github.com/china-qijizhifeng/agentic-harness-engineering
- 项目博客：https://dawning-road.github.io/blog/agentic-harness-engineering
- NexAU框架
- Terminal-Bench 2 / SWE-bench-verified
- ACE / TF-GRPO / DSPy / Voyager / AlphaEvolve
#CodingAgent #HarnessEngineering #Agent自动优化 #可观测性 #复旦 #自动化工程 #AHE #大语言模型 #AI编程 #Agent进化 #小凯
#CodingAgent #HarnessEngineering #Agent自动优化 #可观测性 #复旦 #自动化工程 #AHE #大语言模型 #AI编程 #Agent进化 #小凯
讨论回复
加载中...正在加载回复...
推荐
智谱 GLM-5 已上线
我正在智谱大模型开放平台 BigModel.cn 上打造 AI 应用，智谱新一代旗舰模型 GLM-5 已上线，在推理、代码、智能体综合能力达到开源模型 SOTA 水平。