---
title: "最全Agent Harness综述来了！七层框架拆解工程外壳"
date: 2026-06-11
tags:
  - auto_ingested
language: zh
source_url: "https://mp.weixin.qq.com/s/pG39PRnZFjSIxwYcPKD47A"
key_points:
  - "CMU、Yale、JHU、Virginia Tech、Amazon等联合发布71页Agent Harness综述，提出ETCLOVG七层框架"
  - "Agent工程经历三次迁移：Prompt Engineering → Context Engineering → Harness Engineering"
  - "同一模型换一套执行外壳，benchmark提升可达10倍（不改模型本身）"
  - "GPT-5.2-Codex通过重构系统prompt和加入验证hooks，Terminal-Bench 2.0从52.8%→66.5%"
  - "评估要trace-native：记录完整执行轨迹，而非只看最终成功率"
  - "能力和控制存在矛盾：更多工具带来更强能力，也扩大了prompt injection和失控半径"
  - "Harness正在从framework走向platform，平台竞争核心转向执行环境、工具协议、上下文管理、验证和治理"
ingested_at: 2026-06-11T08:35:00+08:00
---

## Summary

CMU、Yale、JHU 等多所顶级学术机构与 Amazon 联合发布了目前最系统的 Agent Harness 综述（71页），提出 ETCLOVG 七层框架——执行环境、工具接口、上下文管理、生命周期、可观测性、验证评估和安全治理。论文核心判断：Agent 的下一场竞争不在模型本身，而在工程外壳。同一模型配合不同 harness，benchmark 提升最高可达 10 倍，而评估方式也需要从「排行榜」走向「trace-native 质量控制」。

## Content

CMU、Yale、JHU、Virginia Tech、Amazon 等联合发布了一篇名为《Agent Harness Engineering: A Survey》的综述，系统性地拆解了把 Agent 真正跑起来时包在模型外面的那层工程系统。

**核心框架：ETCLOVG 七层**

- **Execution（执行环境）**：Agent 在本地、容器、浏览器、远程沙箱里跑，边界在哪？
- **Tooling（工具接口）**：工具如何描述、发现、调用，如何防止模型乱选工具？
- **Context（上下文）**：短期上下文、会话状态、长期记忆怎么管理？
- **Lifecycle（生命周期）**：单轮还是多轮循环？planner/executor/reviewer 如何分工？
- **Observability（可观测性）**：每次模型调用、工具调用、重试、token 成本、延迟都要能追踪。
- **Verification（验证评估）**：结果对不对？失败原因是模型、工具、上下文还是环境？
- **Governance（治理安全）**：Agent 有什么权限？谁来审批？谁来审计？

**三次工程迁移**

1. **Prompt Engineering**（2022-）：解决「怎么跟模型说话」
2. **Context Engineering**：解决「模型该看见什么」——窗口管理、检索、压缩
3. **Harness Engineering**：解决「怎么让模型在真实世界可靠干活」

**关键实验数据**

- 只改工具格式和周边 harness，不改模型，编码 benchmark 最高带来 **10 倍**提升
- 固定 GPT-5.2-Codex Agent，重构系统 prompt + 中间件上下文注入 + 自验证 hooks，Terminal-Bench 2.0 从 **52.8% → 66.5%**
- Meta-Harness 自动优化 harness，Terminal-Bench-2 做到 **76.4%**，超过手工设计

**能力和控制的矛盾**

论文指出了三大跨层矛盾：
- **成本-质量-速度三角**：更安全、更可靠 = 更高成本和延迟
- **能力和控制**：更多工具 = 更多能力 + 更高 prompt injection 风险
- **Harness Coupling**：修改任何一层（prompt/工具/memory/sandbox/verifier）都会影响整体系统行为

**评估新范式**

论文主张评估要「trace-native」：记录完整执行轨迹（模型输出、工具调用、环境状态、错误恢复、token 使用），判断三件事：结果是否正确、路径是否合理、评估器本身是否可信。

**Framework → Platform 趋势**

Agent 正在从 framework（局部抽象：agent、tool、memory、loop）走向 platform（完整生产系统：durable workspace、managed sandbox、identity、billing、observability、governance、human handoff）。

## 结论

这篇综述最核心的观点可能不是某个具体技术结论，而是对整个行业方向的重新校准：**当大家还在讨论「哪个模型更强」的时候，真正拉开差距的已经是「哪个执行外壳更稳」**。

10 倍这个数字极具冲击力——不改模型本身，单靠工程系统就能带来数量级提升。这对当前行业里「模型至上」的叙事是一个有力纠正。很多团队把问题归因于模型不够强，但真实瓶颈可能在于工具接口、上下文管理、沙箱隔离、验证机制这些「外壳」层面。

三条跨层矛盾的描述（成本三角、能力控制矛盾、外壳耦合）说出了生产 Agent 的核心困境：**强化每一层都会产生意想不到的副作用**。这意味着 Agent 工程没有银弹，每一次加控制都要问「这个假设还成立吗」——尤其是当模型能力快速提升时，原本有效的 wrapper、verifier、memory rule 可能从必要变冗余，甚至成为拖累。

Anthropic 那个例子（context reset 对强模型不再必要）是个重要的逆向信号：Harness Engineering 的最高境界可能不是「加更多控制」，而是「知道什么时候删控制」。好系统不是越复杂越好，而是刚好够用且能随模型进化自动简化。

从竞争格局看，这篇论文暗示平台层的机会可能大于模型层本身——谁能提供最稳的执行环境、最清晰的工具协议、最不容易漂的上下文、最可追溯的 trace，谁就能把 Agent 送进真实生产流程。这一层的能力正在成为新的护城河。