Agent Harness Engineering: A Survey（CMU/Yale/Amazon 等联合综述）
来源：Datawhale 公众号 2026-05-27 推送 原文：https://mp.weixin.qq.com/s/pG39PRnZFjSIxwYcPKD47A 归档：
~/obsidian/05-Archives/2026-Q2/2026-05-28-Agent-Harness综述-Datawhale/论文主页：https://picrew.github.io/LLM-Harness/ 作者：CMU、Yale、JHU、Virginia Tech、Amazon 联合出品
核心观点
同一个模型，换一套执行外壳，表现可以完全不一样。
光换模型不是 Agent 最有效的升级路径。改编辑工具格式和周边 harness，不改模型本身，编码 benchmark 上最高带来 10 倍提升。Meta-Harness 通过自动优化 harness 在 Terminal-Bench-2 上做到 76.4%，超过手工设计方案。
ETCLOVG 七层框架
论文提出的 Agent Harness 分类体系：
| 层 | 英文 | 含义 | 核心问题 | |---|------|------|---------| | E | Execution | 执行环境 | Agent 在哪里跑？本地/容器/浏览器/沙箱？ | | T | Tooling | 工具接口 | 工具怎么描述、发现、调用？怎么防止乱选？ | | C | Context | 上下文和记忆 | 短期上下文、会话状态、长期记忆怎么管理？ | | L | Lifecycle | 生命周期和编排 | 单轮还是多轮？planner/executor/reviewer 分工？ | | O | Observability | 可观测性 | 每次调用、报错、重试、token 成本能否追踪？ | | V | Verification | 验证和评估 | 结果对不对？失败是模型/工具/上下文/环境的错？ | | G | Governance | 治理和安全 | Agent 有什么权限？谁能审批？谁来审计？ |
工具调用只是其中一层。真正的 Agent 产品要有执行环境、上下文、编排、监控、验证和治理。否则只是会动的 demo。
Agent 工程三次迁移
- Prompt Engineering — 怎么跟模型说话
- Context Engineering — 模型该看见什么
- Harness Engineering — 怎么让模型在真实世界里可靠干活
关键洞察
1. 可观测性和治理不是附属功能
Agent 会调用工具、执行 shell、改代码、读写数据库、发邮件。它在行动。
- 没有可观测性 → 失败了不知道为什么
- 没有治理 → 成功了也不敢用
2. Agent 评估要 trace-native
不只看最终成功率，要把完整执行轨迹作为评估对象：模型输出、工具调用、环境状态变化、错误、重试、token 使用、延迟和成本。
3. 三大跨层矛盾
- 成本-质量-速度三角：更安全 = 更强沙箱 + 更细权限 + 更完整 trace = 更高成本
- 能力-控制矛盾：工具越多能力越强，选错工具和 prompt injection 面也越大
- 外壳耦合：工具描述占上下文、执行环境影响评估、trace 缺身份状态就不是治理证据
4. 好 Harness 不只加控制，还要知道什么时候删控制
随着模型变强，某些 context reset、wrapper、verifier 可能不再必要，去掉后成本下降质量不变。
5. 从 Framework 到 Platform
- Framework：agent、tool、memory、loop 的局部抽象
- Platform：durable workspace、managed sandbox、identity、billing、observability、evaluation、governance、human handoff 的完整生产系统
金句
"Prompt Engineering 是把模型叫醒。Context Engineering 是让模型看见正确的信息。Harness Engineering 是让模型在真实世界里可靠行动。"
"能演示，不等于能上线。能跑一次，不等于能长期稳定跑。"