124
2026 年 5 月，CMU、Yale、JHU、Virginia Tech、Amazon 等九家机构联合发布了一篇 71 页的综述论文《Agent Harness Engineering: A Survey》。19 位作者对 170 余个开源 Agent Harness 项目做了系统编码，提出了 ETCLOVG 七层分类框架，并给出了一个在业界讨论中反复出现但缺少严格证据支撑的判断：制约 Agent 可靠性的瓶颈不在模型，而在模型外面那层工程系统。

Harness 改一改，性能翻几倍

论文引用了一组对比实验：把 GPT-5.2-Codex 固定不动，只修改 Harness 层——重写系统提示词、加入中间件上下文注入、增设自验证钩子——Terminal-Bench 2.0 得分从 52.8% 升到 66.5%。进一步用自动化 Meta-Harness 优化器调参，分数到了 76.4%，超过人工调优的最好成绩。

另一组实验更激进：仅修改 edit-tool 的格式协议和工具调用规范，编码基准测试的改善幅度达到 10 倍。

这些数字说明的事情很简单：很多团队在抱怨"模型不够强"的时候，真正的短板是工具设计、上下文策略、沙箱配置、验证机制和权限控制。模型是引擎，Harness 是底盘和变速箱——引擎马力再大，底盘松散一样跑不稳。

三个时代：从 Prompt 到 Harness

综述梳理了 2022—2026 年 Agent 工程的演进脉络，划出三个阶段。这三个阶段在时间上重叠，区分的是边际工程投入落在哪一层。

flowchart LR
    subgraph era1["2022—2024"]
        PE["Prompt Engineering<br/>解决一次请求怎么说"]
    end
    subgraph era2["2025"]
        CE["Context Engineering<br/>解决一次请求里放什么"]
    end
    subgraph era3["2026—"]
        HE["Harness Engineering<br/>解决任务生命周期怎么被系统托住"]
    end
    PE --> CE --> HE

    style era1 fill:#e8eaf6,stroke:#5c6bc0
    style era2 fill:#e0f2f1,stroke:#26a69a
    style era3 fill:#fff3e0,stroke:#ff9800

Prompt Engineering（2022—2024） 的工程对象是一段输入文本。few-shot 示例、CoT 推理模板、系统提示词优化，都围绕"怎么跟模型说话"展开。这一阶段的标志性项目是 AutoGPT 和 BabyAGI，它们暴露了单靠提示词驱动长程任务会出现的四个失败模式：执行失控、上下文爆炸、状态丢失、副作用不可监控。

Context Engineering（2025） 把注意力从"说什么"转向"让模型看到什么"。检索增强、上下文压缩、工具输出排序、窗口饱和管理，解决的是每一步应该把哪些信息送进上下文窗口。这一阶段对应的是 MCP 协议定稿、tool-augmented training 出现、RAG 系统成熟。

Harness Engineering（2026—） 处理的问题更底层也更广：谁维护状态，谁调用工具，谁限制权限，谁注入反馈，谁验证进度，谁记录轨迹，谁在失败时恢复。当模型能力足够处理复杂任务，瓶颈就移到了模型外面的那套基础设施上。

之前的文章从 OpenAI 和 Anthropic 的工程实践出发讨论过这个转变。这篇综述把行业共识推进了一步：它不只是判断，还有 170 个项目的生态数据和定量实验做支撑。

ETCLOVG 七层框架

综述的核心贡献是 ETCLOVG 七层分类体系。前四层构成结构核心，后三层构成控制面。

block-beta
    columns 1
    block:control["控制面 Control Plane"]
        G["G — 治理 Governance<br/>权限 · 身份 · 审计 · 人工兜底"]
        V["V — 验证 Verification<br/>基准 · 失败归因 · 回归反馈"]
        O["O — 可观测性 Observability<br/>轨迹 · 成本 · 故障 · 可靠性信号"]
    end
    block:core["结构核心 Structural Core"]
        L["L — 生命周期 / 编排 Lifecycle<br/>单 Agent 循环 · 多 Agent 工作流"]
        C["C — 上下文管理 Context<br/>短期 · 会话级 · 持久化记忆"]
        T["T — 工具接口 Tool Interface<br/>描述 · 发现 · 调用 · 协议"]
        E["E — 执行环境 Execution<br/>沙箱 · 容器 · 浏览器 · 桌面"]
    end

    style control fill:#fff3e0,stroke:#ff9800
    style core fill:#e3f2fd,stroke:#1976d2

E — 执行环境

定义 Agent 代码在哪里运行、边界是什么。覆盖通用沙箱（Daytona、E2B）、代码专用运行时、浏览器环境（WebArena）、桌面级 computer-use 基础设施（Anthropic Computer Use）。

一个容易被忽略的细节：容器逃逸基准测试显示，当前模型在特定配置下的逃逸成功率在 15%—35% 之间。沙箱安全远未解决。

T — 工具接口与协议

规定外部能力如何被描述、发现和调用。MCP 和 A2A 是当前的两个主要协议标准。这一层还包括工具描述质量（模型选错工具的概率与描述设计直接相关）、工具增强训练、会话管理。

仅修改工具格式和调用协议就能带来 10 倍基准改善，说明这一层的工程投入回报极高。

C — 上下文管理

控制模型在短期、会话级和持久化三个时间尺度上能访问哪些信息。短期上下文靠窗口管理和压缩，会话级靠状态持久化和恢复，持久化记忆靠检索和索引。

论文验证了混合存储和集体学习架构在记忆系统中的有效性。上下文换入换出和环境可供性两篇文章讨论过这个层面的设计原则。

L — 生命周期与编排

管理控制流和状态读写，从单 Agent 的内循环到多 Agent 的工作流编排。这是开源生态里项目密度最高的一层（47 个项目），也是大多数 Agent 框架的核心卖点——LangGraph、CrewAI、AutoGen 都主要在这一层竞争。

O — 可观测性

捕获轨迹、成本、故障和可靠性信号。综述把它从生命周期钩子里提升为独立层，理由是：在生产环境中，可观测性有自己的工具栈（LangSmith、Arize、Braintrust）和自己的负责团队。Agent 会执行 shell 命令、修改代码、读写数据库、调用外部 API——"它到底做了什么"这个问题的回答复杂度已经超出了日志打印能覆盖的范围。

V — 验证

把任务和执行轨迹转化为评估、失败归因和回归反馈。论文把验证重新定义为一个五阶段的生命周期：

flowchart LR
    T1["任务与基准<br/>锚定"] --> T2["执行前<br/>就绪检查"]
    T2 --> T3["受控执行<br/>与轨迹捕获"]
    T3 --> T4["多层判定<br/>与失败归因"]
    T4 --> T5["持续回归<br/>与部署反馈"]
    T5 -.->|"闭环"| T1

    style T1 fill:#e8eaf6,stroke:#5c6bc0
    style T2 fill:#e0f2f1,stroke:#26a69a
    style T3 fill:#fff3e0,stroke:#ff9800
    style T4 fill:#fce4ec,stroke:#e91e63
    style T5 fill:#f3e5f5,stroke:#9c27b0

这个框架的关键洞察是：单一通过率隐藏了太多变量。相同的通过率背后可能是完全不同的系统质量——一个 Agent 可能靠暴力重试（高成本），另一个可能走了不安全路径碰巧对了（不合规），还有一个可能钻了测试环境的漏洞而不是真的解决了问题。

论文提出的替代方案是轨迹原生评估（trace-native evaluation）：记录完整执行轨迹（模型输出、工具调用、工具返回、环境状态变化、上下文快照、错误、重试、恢复动作、token 用量、延迟、成本），然后从三个维度评估——结果正确性、路径合理性、评估器可信度。

G — 治理

通过权限、身份、策略、加固、审计和人工监督约束 Agent 行为。治理通过生命周期钩子注入，不修改 Agent 的核心推理逻辑：

钩子类型 作用
执行前钩子（pre-execution） 在输入到达 LLM 之前验证
调用前钩子（pre-invocation） 在工具调用执行前检查
执行后钩子（post-execution） 在工具输出回注上下文前过滤
人工介入钩子（human-in-the-loop） 对高风险动作要求人工审批

Agent 能发邮件、改代码、调 API、读隐私数据。"它被允许做什么"这个问题和"它做了什么"同样重要。没有可观测性，无法诊断故障；没有治理，无法信任成功。

开源生态的分布不均

综述对 138 个项目按主要层做了编码。分布很不均匀：

xychart-beta
    title "ETCLOVG 各层开源项目数量"
    x-axis ["E 执行", "T 工具", "C 上下文", "L 编排", "O 观测", "V 验证", "G 治理"]
    y-axis "项目数" 0 --> 55
    bar [20, 12, 9, 47, 15, 21, 14]

几个值得注意的信号：

编排层（L）密度最高，47 个项目。这不意外——Agent 框架竞争的主战场就是"怎么编排调用循环"。但编排层的高密度也意味着它正在快速商品化。

上下文层（C）项目最少（9 个），但这不意味着上下文管理不重要。恰恰相反，上下文管理通常嵌入更大的框架内部，而不是作为独立项目存在。这反映的是架构耦合，不是需求缺失。

可观测性（O）和治理（G）在开源中偏薄，更多出现在商业平台和 SDK 中。论文认为这说明"运维控制的成熟度晚于运行时和基准设施"。对于正在构建生产 Agent 的团队，这两层恰恰是最容易被低估的短板。

三个跨层张力

ETCLOVG 的七层不是独立的，它们之间存在三个系统性张力。

成本—质量—速度三角

更强的沙箱隔离、更细的权限控制、更完整的执行轨迹、更深的验证，都提升质量和安全性，但代价是更多 token、更高延迟、更重的基础设施。质量不是一个可以独立最大化的标量。

能力—控制权衡

更多工具扩大 Agent 能力边界，同时增大工具选错和提示注入的攻击面。持久化记忆支持跨会话工作，同时引入隐私、过期信息和来源追溯问题。更开放的执行环境提高任务覆盖率，也放大失败的爆炸半径。

这不是"开放还是封闭"的二选一，而是一条连续的设计轴——每个团队需要在上面找到自己的位置。

Harness 耦合问题

各层之间的耦合使得局部优化很脆弱。工具描述占用上下文窗口空间，影响模型行为。执行环境通过包版本、重置机制和延迟差异影响验证结果。没有身份和权限状态的可观测性轨迹，不能作为治理证据。任何单层的变更都可能改变整体系统行为。

flowchart TD
    T_desc["工具描述"] -->|"占用窗口空间"| C_window["上下文窗口"]
    E_env["执行环境"] -->|"包版本 / 重置机制"| V_eval["验证结果"]
    O_trace["可观测轨迹"] -->|"需要身份信息"| G_audit["治理审计"]
    C_window -->|"信息密度影响"| L_loop["编排决策"]
    G_audit -->|"权限约束"| T_desc

    style T_desc fill:#e3f2fd,stroke:#1976d2
    style C_window fill:#e3f2fd,stroke:#1976d2
    style E_env fill:#e3f2fd,stroke:#1976d2
    style V_eval fill:#fff3e0,stroke:#ff9800
    style O_trace fill:#fff3e0,stroke:#ff9800
    style G_audit fill:#fff3e0,stroke:#ff9800
    style L_loop fill:#e3f2fd,stroke:#1976d2

这意味着变更应该当作系统级变更来测试，而不是在单层内做 A/B。

五个开放问题

综述列出了五个当前未解决的工程问题。

执行环境的加固与扩展。容器、microVM、桌面虚拟机、云端沙箱之间的安全性-成本-便携性权衡缺少统一模型。15%—35% 的容器逃逸成功率说明沙箱安全不是解决了的问题。

长程 Agent 的可靠状态管理。上下文管理需要从"字符串拼接"重新定义为状态估计问题，带来源追溯、矛盾检测、过期标记和从持久化制品恢复的能力。

轨迹原生的故障诊断。团队有了可观测性工具，但很少用轨迹来自动归因故障：到底是模型错了，工具错了，上下文错了，还是测试环境错了。

跨 Agent、工具和人类的标准交接协议。Agent 之间、Agent 与工具之间、Agent 与人之间的交接需要传递意图、约束、权限、制品、来源、预算状态、风险等级和轨迹历史。当前各框架的交接协议不互通。

模型变强之后的自适应简化。Harness 的每一个组件都编码了对模型局限性的假设。模型能力提升后，部分组件从"承重结构"变成"多余开销"。

论文引用了 Anthropic 的案例作为例证：某些上下文重置策略在弱模型上能提升稳定性，换到强模型后反而成了多余开销，移除后成本降低且质量不变。

从框架到平台

综述识别出一个趋势：Agent 生态正在从框架向平台演进。

框架提供本地抽象——Agent、工具、记忆、循环。平台需要提供完整的生产系统——持久化工作空间、托管沙箱、身份管理、计费、可观测性、评估、治理和人工交接。

早期竞争围绕"谁能最快搭出 Agent 循环"。当前竞争围绕"谁能让循环长期稳定运行"。平台竞争将覆盖完整的 Harness 能力栈。

这篇综述对实际工程的意义

ETCLOVG 最直接的用法是当诊断清单。对照七层给自己的 Agent 系统打分，空白层就是短板——这比凭直觉猜"哪里有问题"要可靠得多。

几个实操建议：

工具层回报最高。10 倍改善来自工具格式和调用协议的优化，这是投入产出比最大的改进点。在抱怨模型能力之前，先检查工具描述是否清晰、调用格式是否一致、错误处理是否完备。

可观测性和治理不能等到出事再补。开源项目在这两层最薄，但生产环境恰恰最需要。Agent 不只是生成文本，它执行动作——执行动作的系统必须可审计、可约束。

验证不是跑一遍测试。从"通过率"升级到"轨迹评估"，区分"对了但路径不合理"和"真的解决了问题"。这需要完整的执行轨迹记录作为基础设施，不是事后加一层断言能解决的。

警惕 Harness 耦合。改了工具层不要只测工具——上下文窗口占用变了，模型行为可能跟着变。改了沙箱不要只测安全——包版本差异可能让验证结果不可比。系统级变更需要系统级测试。

参考资料