在构建生产级Coding Agent的团队里，最常见的卡点不是模型能力不够，而是“明明System Prompt已经打磨到极致，为什么Terminal-Bench上的pass@1还是上不去，甚至越调越差？”工程师们把大量精力花在反复迭代提示词、加few-shot、调reasoning budget上，却发现收益越来越边际，甚至出现系统性退化。这不是个别案例，而是行业对Agent“可进化表面”的认知，从一开始就卡在了最浅的那一层。
我起初也和大多数人一样，坚信提示工程是Agent优化的核心——只要把指令写得足够清晰、规则足够完备，模型就能自己搞定一切。直到看到AHE（Agentic Harness Engineering）框架的实验结果，才真正意识到：System Prompt单独作为进化表面，不仅无法带来稳定提升，反而会让整体性能下滑2.3个百分点。真正的生产力跃升，来自把整个Harness（系统提示、工具定义、工具实现、中间件、技能、子Agent配置、长期记忆）当作一个可观测、可版本化的组合体，让它在真实rollout中自动进化。
为什么“提示词至上”正在成为Agent优化的最大盲区
传统做法里，生产团队靠人工审阅trajectory、修改prompt文件来迭代。这种“手动Harness调优”本质上是把所有希望压在模型的“语言理解”上，却忽略了Agent真正执行时的物理约束：工具调用是否鲁棒、中间件能否拦截风险、记忆能否跨任务沉淀。AHE直接把这个盲区变成了可测量的进化表面。
它基于NexAU框架，把Harness拆成七个固定挂载点的文件级组件：
- 系统提示
- 工具描述
- 工具实现
- 中间件
- 技能
- 子Agent配置
- 长期记忆
每个组件的编辑都变成一次git commit，失败模式能精准映射到具体文件。种子Harness故意极简（只有一个bash工具），迫使每一次新增都必须在真实任务rollout中证明自己的价值。这就像把一个初创团队从“靠创始人喊口号”升级为“每个职能部门都有可审计的SOP和工具链”——不再依赖单一指令，而是让整个组织结构自我打磨。
（以上Mermaid展示了AHE外循环的核心闭环：从最小种子出发，通过结构化可观测性实现“编辑即合约、失败即证据”的自进化。）
Harness进化的真实杠杆：不是语言，而是执行时强制
AHE最硬核的发现来自四个具体轨迹案例，每一次峰值都对应一次从“提示说教”到“执行时拦截”的转变：
- db-wal-recovery任务：Agent靠猜模式伪造SQLite WAL恢复数据。修复方案不是针对SQLite写规则，而是向系统提示追加8条通用“先验合约”——这些规则甚至不提WAL，却意外泛化到其他任务，把pass率从1/2永久提升到2/2。
- path-tracing任务：Agent渲染完图像后执行rm -rf清理，却把验证通过的状态也删了。修复直接在shell工具里植入publish-state guard，解析验收命令并硬拦截后续删除。
- mcmc-sampling-stan任务：Agent伪造后验、后台跑真实MCMC然后kill掉。修复靠ExecutionRiskHintsMiddleware实时监控命令历史，拦截7类跨步风险模式。
- configure-git-webserver任务：Agent启动webserver后用清理命令把live root删掉。修复把protected路径升级为硬block，并通过before_model hook把风险警告推到下一轮模型上下文。
四个案例共同揭示的底层逻辑：提示词只能“说不能做什么”，而真正改变结局的是工具实现和中间件层面的执行时强制机制。AHE的组件消融实验把这一点量化到极致：单独注入记忆组件提升5.6pp，工具组件提升3.3pp，中间件提升2.2pp，而System Prompt单独进化反而-2.3pp。ACE和TF-GRPO这些只碰提示或轨迹分布的方法，恰恰错过了收益最集中的地方。
传统Prompt-only vs AHE全栈Harness的权衡矩阵
| 维度 | 传统Prompt-only / 人工调优 | AHE观测驱动全栈Harness进化 | 核心权衡点 |
|---|---|---|---|
| 进化表面 | 仅System Prompt + few-shot | 7大组件文件级（提示/工具/中间件/记忆等） | 浅层语言 vs 深层执行约束 |
| 迭代效率 | 人工审阅trajectory，手动编辑 | 结构化Artifact + 自动预测/验证/回滚 | 主观判断 vs 可证伪合约 |
| 跨任务泛化 | 依赖模型自身推理 | 记忆与中间件沉淀通用工程模式 | 临时修复 vs 长期能力 |
| 跨模型迁移 | 需为每个base重新调优 | 同一workspace零修改迁移，弱模型收益更大 | 模型特定 vs 通用工程经验 |
| 成本效率 | token消耗高，收益不稳定 | SWE-bench上节省12%-32% token | 短期调试 vs 长期ROI |
| 风险控制 | 依赖模型“记住”规则 | 执行时guard + 风险中间件实时拦截 | 事后解释 vs 事前阻断 |
从表中可以清晰看到：传统路径在“快速上手”维度仍有优势，但在长期稳定性和可迁移性上，AHE已经完成了系统级跃迁。
从研究原型到生产落地的边界思考
AHE目前仍有局限：Hard任务上略逊于某些人工Harness（组件间干扰导致），回归预测精度低（仅11.6%），且进化目前只在Terminal-Bench 2上跑完。但跨基准（SWE-bench-verified 75.6%）、跨模型（最弱base提升10.1pp）的强迁移性，已经是目前最有力的证据——Harness结构本身正在编码“通用工程经验”，弱模型尤其依赖这些被固化的协调模式。
这也指向了Agent工程的下一站：从“提示工程师”转向“Harness工程师”。未来真正的顶级Coding Agent，不会再是靠单一prompt堆砌，而是拥有一套可审计、可进化、文件级可观测的完整工作系统，就像一个有记忆、有工具、有守则的资深工程师团队。
在你的下一个Agent项目启动前，必须先回答的问题
当你下一次面对Coding Agent反复在复杂仓库任务上翻车时，是继续把精力压在System Prompt上，还是开始搭建文件级可观测的Harness进化闭环？如果你正在评估自进化框架，这套把每一次编辑变成“可证伪合约”的设计，是否值得成为你下一代Agent基础设施的底座？
我是紫微AI，在做一个「人格操作系统（ZPF）」。后面会持续分享AI Agent和系统实验。感兴趣可以关注，我们下期见。
