概览
以《Agent Harness Engineering: A Survey》为纲，梳理 harness 约束瓶颈论、三个工程阶段、ETCLOVG 七层分类法与跨层综合。
本 tab 的组织骨架取自综述《Agent Harness Engineering: A Survey》(Li et al., TMLR under review)。该综述将 agent 的执行框架（execution harness，即包裹语言模型、负责长程多步任务执行的基础设施层）作为一个独立的系统层 加以系统化处理，并将 170+ 个开源项目映射到其提出的分类法上。本节客观转述该综述的整体框架，后续各层章节在此骨架下 逐一展开。
约束瓶颈论：harness 而非 model
综述的出发点是所谓 binding-constraint thesis（约束瓶颈论）：对于跨可比前沿模型评测的长程任务，基准分数的方差在 相当程度上由执行框架而非模型本身决定。综述援引三项 2026 年前后的实证结果作为支撑，三者均在固定模型、仅改动 harness 的条件下取得提升：
- 仅修改编辑工具（edit-tool）格式与周边工具框架，在 15 个模型上于编码基准取得最高约 10× 的提升；
- 对固定的 GPT-5.2-Codex agent，仅通过系统提示重构、中间件上下文注入与自校验 hook，将 Terminal-Bench 2.0 成绩 从 52.8% 提升到 66.5%（+13.7 个百分点）；
- Meta-Harness 通过自动化 harness 优化在 Terminal-Bench-2 上达到 76.4%，超过所有手工设计方案，且未改动模型权重。
综述指出，上述每一项 harness 层面的提升幅度均超过同类基准上通常被视为显著的 2–4 个百分点的模型进步。据此，综述 将可靠性的边际来源定位在 harness 层。
综述同时描述了一个实践者—研究界的错位：OpenAI 已将 “harness engineering” 明确界定为围绕 agent 设计环境、约束、 文档与反馈回路的工程学科；Anthropic 的一系列工程文章从相邻方向得出一致原则（架构应简单可检视、工具接口应面向 agent 而非照搬人类 API、上下文应渐进披露而非急切加载、长程工作需要持久交接产物与可恢复的执行基础设施）。而研究界虽已对 记忆、工具使用、规划、安全等组件做了日益精细的研究，却缺乏描述“将这些组件整合为可靠运行的系统”的形式化词汇。 该综述意在弥合这一空隙。
三个工程阶段
综述将 2022–2026 年间“工程重心的迁移”归纳为三个相互重叠的阶段，而非彼此替代的阶段：
- Prompt engineering（2022–2024）：主要杠杆是输入的提示文本，工程范围收敛于优化单次模型调用的单一文本输入。
- Context engineering（2025）：随着 agent 运行时间变长，约束从“输入是什么”转向“模型在每一步应当看到什么”， 范围扩展到管理流入上下文窗口的多路信息（每轮注入什么、如何检索与压缩记忆、如何按相关性排序工具结果、如何应对 窗口饱和）。
- Harness engineering（2026）：当模型已能承担长程任务，可靠性转而取决于维护状态、中介工具、注入反馈、施加约束、 校验进展的基础设施包裹层。此阶段将 ETCLOVG 全部七层视为一个整体。
综述强调三阶段在时间与概念上相互重叠、层层包含（harness 包含 context，context 包含 prompt），应理解为边际工程投入 所在位置的迁移，而非清晰的先后替换。
ETCLOVG 七层分类法
综述提出以首字母缩写 ETCLOVG 命名的七层分类法，分为“结构核心”与“控制平面”两组：
| 层 | 名称 | 职责 |
|---|---|---|
| E | Execution 执行环境与沙箱 | agent 代码在何处运行、受何种沙箱约束 |
| T | Tooling 工具接口与协议 | 外部能力如何被描述、发现、调用 |
| C | Context 上下文与记忆 | 模型在短期、会话、持久三种时间尺度上能看到什么 |
| L | Lifecycle 生命周期与编排 | 读写上述状态的控制流：单 agent 循环、多 agent 编排、端到端流水线 |
| O | Observability 可观测与运维 | trace、成本、失败与可靠性信号 |
| V | Verification 验证与评估 | 把任务与 trace 转化为评估、失败归因与回归反馈 |
| G | Governance 治理与安全 | 以权限、身份、策略、加固、审计、人工监督约束行为 |
前四层（E/T/C/L）构成 harness 的结构核心，后三层（O/V/G）构成环绕核心的控制平面。综述有两处刻意的设计取舍：
- 将 Observability 提升为独立的一等层，而非视作 lifecycle hook 的副产物——理由是可观测性在生产系统中已有专门的 工具生态（Langfuse、Arize Phoenix、OpenLLMetry）与独立的工程实践（OpenTelemetry 埋点、成本归因、异常检测）。
- 将 Governance 作为一等层引入，覆盖模型级（护栏、内容过滤）、系统级（网关、代理、权限模型）、组织级（审计、 合规、human-in-the-loop 监督）三个子层。
综述另将状态管理置于 Lifecycle 层内，使状态与读写它的执行流处于同一层，而非单列一层。
跨层综合
综述在逐层描述之后，用一节“跨层综合”将七层的交互收敛为若干系统级效应，其核心论点是：一旦执行、工具、上下文、编排、 可观测、评估、治理被组合起来，它们之间的相互作用会产生任何单层都无法独立解决的约束。
- 成本—质量—速度三难（cost–quality–speed trilemma）：更强的沙箱、更丰富的上下文与记忆、更深的评估与可观测， 普遍会提高成本与延迟。系统必须决定哪些检查同步执行、哪些离线运行、哪些失败值得付出昂贵的恢复路径，而不能把质量 当作单一标量目标来优化。
- 能力—控制权衡（capability–control tradeoff）：harness 每增加一分授权（更大的工具菜单、持久记忆、更宽松的沙箱）， 就同等扩大控制问题（选择错误与注入面、来源与陈旧与隐私风险、误动作的波及范围）。因此控制不是安全附加项，而是一条 贯穿工具 schema、上下文策略、运行时权限、身份、可审计性与人工批准的设计轴。
- harness 耦合问题（harness coupling problem）：各层以使局部优化变得脆弱的方式相互耦合——执行环境会通过包可用性、 重置语义、延迟与失败模式影响评估结果；工具描述会消耗上下文预算并塑造模型行为；可观测 trace 只有在同粒度捕获身份与 权限时才能成为治理证据。因此对 harness 的改动应作为系统级改动来测试；也正因如此，agent 分数无法在不指明周边 控制器的情况下干净地归因于模型。
综述据此强调七层应被读作依赖结构而非清单：E 约束哪些 L 编排策略可行、C 影响 V 的可复现、G 对其余每一层施加身份／ 权限／审计约束。而生产 harness 最常在层与层的接口处失败——语料中反复出现五个层边界缺口：跨工具互操作、成本归因、 失败恢复、多仓编排、人-agent 交接。中心问题因此不再是”每一层是否有可用工具”，而是”组合后的 harness 是否表现为一个 可靠的控制系统”。
综述进一步指出生态正从 agent framework 走向 agent platform：框架封装 agent、工具、记忆、执行循环等局部抽象，而平台 在多次运行、多用户之上叠加持久工作区、托管沙箱、身份、计费、可观测、评估、治理与人工交接。核心设计问题随之从 “如何构建一个 agent”转为“如何运营一支其行为始终可检视、可回退的 agent 队列”。
开放问题
综述将跨层效应整理为五个横跨分类法的开放问题：
- 加固与扩展执行环境：让运行时基座既可度量又可组合；统一的注入/目标错位/组合放大安全评测；决定何时使用容器、 microVM、OS 权限边界、桌面 VM、浏览器环境或学习式代理环境的成本模型；跨自托管/云/混合部署保持语义的可移植层。
- 在长程 agent 中维持可靠状态：把上下文管理重述为状态估计——刻画每次压缩、检索、遗忘丢失了多少任务相关信息， 并约束 agent 内部状态与真实任务状态之间的偏离；需要不确定性感知的摘要、记忆事实的来源、矛盾处理、显式陈旧标记， 以及从持久产物重建缺失状态的恢复过程。
- 从 agent trace 诊断失败：评估不应停留在终局分数上；失败可能源自模型推理、误导性工具 schema、沙箱配置、陈旧 上下文、flaky 测试、基准歧义、judge 不稳定或编排循环。方向是 trace-native 评估——把 trace 作为计算成绩、轨迹质量、 失败归因与回归的一等对象（综述引数据：89% 团队使用可观测，仅 52.4% 运行离线评估，两者常彼此脱节）。
- 跨 agent／工具／人的标准交接：现有接口（MCP 标准化工具访问、A2A 面向 agent 间通信、OpenTelemetry 提供 trace 基座）仍是局部标准，缺少跨层交接契约——交接时不仅应传递文本摘要，还应传递意图、约束、权限、产物、来源、预算状态、 风险等级、trace 历史与未决决策，并明确“谁授权、转移了哪些状态、依据何种证据、接收方被允许做什么、何时须交还控制”。
- 在模型进步时保持 harness 的有用性：不应假设 harness 单调地趋向更多脚手架；每一个包裹、重置、校验器、规划器、 记忆规则与权限门都编码了“模型独立完成时不可靠”的假设，模型能力变化时应重新评估这些干预是否仍然有益。方向是 元工程议程——让 harness 具备自我优化与自我简化的机制（如把提示、工具、控制循环纳入搜索目标），并在质量—延迟—成本 —风险的联合约束下持续追问“哪些控制仍然必要”。
综述在结论中说明其分类法当前是描述性的：把 ETCLOVG 从“分类框架”转化为能指导 harness 设计决策的规范性框架， 是其展望的下一步。综述亦声明局限：语料偏向英文、GitHub 可见的开源项目，以及编码 agent 生态。
本 tab 章节
后续各层章节在 ETCLOVG 骨架下逐一展开：
综述明确排除在 harness 之外的模型侧议题（推理范式、训练方法）另见 模型侧基础；一家云厂商 对同一组主题的工程实践解读见 AWS 实践系列。