2026年，AI Agent 的生产部署出现了一个反直觉的发现：决定 Agent 任务可靠性的不是模型本身，而是包裹模型的那层基础设施——即 Agent Harness（执行器）。Bölük 仅修改工具格式和执行系统就实现了跨15个模型的高达10倍性能提升；Trivedy 仅通过系统提示重组和中间件上下文注入就将固定模型的 Terminal-Bench 得分从52.8%提升到66.5%；Meta-Harness 通过自动化执行器优化达到76.4%，超越所有手工工程方法且未修改模型权重。本文基于2026年5月发表的《Agent Harness Engineering: A Survey》综述论文，系统拆解 ETCLOVG 七层工程框架，为正在构建代码智能体、浏览器智能体或多智能体系统的团队提供从沙箱到治理的完整操作指南。

目录

1. 概述
   1.1 什么是 Agent Harness
   1.2 从提示工程到执行器工程的三阶段演进
   1.3 核心论点：执行器才是瓶颈约束
   1.4 ETCLOVG 七层分类法总览
2. 第一层：执行环境与沙箱（E）
   2.1 沙箱的三重目的
   2.2 七类沙箱选型指南
   2.3 沙箱部署模式
   2.4 操作清单
3. 第二层：工具接口与协议（T）
   3.1 协议标准选型：MCP vs A2A
   3.2 工具设计原则
   3.3 工具发现与选择机制
   3.4 操作清单
4. 第三层：上下文与记忆管理（C）
   4.1 三层记忆架构
   4.2 长时域上下文技术
   4.3 上下文漂移问题
   4.4 操作清单
5. 第四层：生命周期与编排（L）
   5.1 单智能体内部循环
   5.2 多智能体编排模式
   5.3 完整生命周期管道
   5.4 操作清单
6. 第五层：可观测性与运营（O）
   6.1 追踪与监控平台选型
   6.2 成本跟踪与优化
   6.3 可靠性工程指标
   6.4 操作清单
7. 第六层：验证与评估（V）
   7.1 评估生命周期五阶段
   7.2 基准测试选型
   7.3 失败归因方法
   7.4 操作清单
8. 第七层：治理与安全（G）
   8.1 权限模型设计
   8.2 声明式宪法与审计
   8.3 生命周期钩子
   8.4 操作清单
9. 跨层综合与权衡
   9.1 成本-质量-速度三元悖论
   9.2 能力-控制权衡
   9.3 执行器耦合问题
10. 实战案例
    10.1 案例一：构建代码智能体的执行器
    10.2 案例二：多智能体客服系统的架构检查
11. 总结
    参考文献

1. 概述

1.1 什么是 Agent Harness

Agent Harness（智能体执行器）是将大语言模型调用转化为有边界、有状态、工具中介式任务执行的基础设施层。它不是模型本身，也不是简单的 API 包装器，而是管理上下文构建、工具交互、编排、反馈和执行约束的完整工程系统。

简单来说：模型负责"想"，执行器负责"管"——管环境、管工具、管记忆、管流程、管监控、管评估、管安全。

1.2 从提示工程到执行器工程的三阶段演进

AI Agent 工程实践经历了三个清晰阶段，每个阶段都包含前一阶段：

• 提示工程（2022-2024）：主要杠杆是输入提示文本。实践者通过编写更好的指令、少样本示例和推理模板进行优化。工程范围很窄——优化单个模型调用的单个文本输入。
• 上下文工程（2025）：瓶颈从"输入是什么"转变为"模型在每一步应看到什么信息"。聚焦于上下文管理：每轮注入什么、如何检索和压缩记忆、如何处理上下文窗口饱和。
• 执行器工程（2026）：可靠性越来越依赖于维护状态、中介工具、注入反馈、强制执行约束和验证进度的基础设施包装器。执行器工程询问的是：必须在模型周围设计怎样的治理、约束、反馈循环和执行控制，才能使智能体系统可靠。

这种演进反映了一个基本趋势：AI Agent 的可靠性正从模型能力驱动转向基础设施质量驱动。

1.3 核心论点：执行器才是瓶颈约束

论文提出"瓶颈约束论点"：对于跨可比前沿模型评估的长时域任务，基准测试方差可能由执行器本身驱动，其程度与模型相当。三项独立研究支持这一论点：

• Bölük（2026a）：仅修改工具格式和执行系统，跨15个模型报告高达10倍增益
• Trivedy（2026）：仅通过基础设施变更，将固定模型从52.8%提升至66.5%（+13.7个百分点）
• Meta-Harness（Lee等，2026）：通过自动化执行器优化达到76.4%，超越所有手工工程方法

在每种情况下，执行器是变量，模型是固定的。这些仅通过执行器获得的增益均超过了同一基准测试上典型模型进步（通常2-4个百分点）。

1.4 ETCLOVG 七层分类法总览

论文提出 ETCLOVG 七层分类法，将可观测性和治理提升为独立层：

前四层（E/T/C/L）是结构核心，后三层（O/V/G）是控制平面。这七层构成了评估任何 Agent 系统工程完整性的检查清单。

流程执行说明：

• 执行器启动后按 E→T→C→G 顺序初始化各层基础设施
• 进入执行循环后，每轮迭代依次通过上下文组装、工具暴露、推理执行、沙箱操作、可观测记录五个环节
• 任务完成后，验证层对完整轨迹进行评估，治理层生成审计日志
• 七层各司其职：E 提供安全边界，T 管理能力暴露，C 控制信息流，L 编排控制流，O 记录一切，V 衡量结果，G 约束行为

2. 第一层：执行环境与沙箱（E）

2.1 沙箱的三重目的

沙箱在 Agent 时代同时服务于三个目的，这三者的组合使沙箱从操作细节提升为执行器设计的一等关注点：

• 安全：LLM 生成的代码在大规模下既不可审计也不可预测，静态审查无法作为主要防线。Agent 多步骤自主执行时无法进行人工干预。提示注入攻击可将良性 Agent 转化为沙箱定向攻击的向量。
• 可复现性：长时域任务及其评估需要能将执行状态重置到已知基线。Docker 容器或微型虚拟机可按需销毁和重建。在训练时，单个任务可能在并行轨迹中重复数百次，缺乏廉价重置机制本身就是可扩展性瓶颈。
• 活性（Liveness）：这是 Agent 时代特有的目的。没有沙箱，每个可能有风险的动作都必须通过显式权限提示向人工门控。大规模下这导致用户因挫败而放弃或反射性地批准一切。沙箱定义了 Agent 可自由行动的有界区域，将权限从逐动作问题转变为会话配置问题。Anthropic 报告称，向 Claude Code 引入沙箱后"权限提示减少了84%，同时保持了安全性"。

2.2 七类沙箱选型指南

沙箱基础设施在 2024-2026 年从通用运行时多样化到七个产品类别：

选型原则：

• 代码智能体优先选代码专用沙箱或通用托管沙箱
• 浏览器智能体必须使用浏览器评估环境
• 多智能体系统优先选沙箱抽象层以统一管理
• 企业部署建议混合模式：交互式开发用自主托管，多租户用云沙箱，合规场景用混合/自带云

2.3 沙箱部署模式

三种共存模式：

• 自主托管：开发者直接管理沙箱基础设施，在交互式开发和单租户场景中占主导
• 云（SaaS）：沙箱即服务，在多租户和大规模部署中更常见
• 混合/自带云：Agent 逻辑和沙箱执行跨环境解耦，适用于合规或数据驻留需求

2.4 操作清单

• 确认沙箱类型与工作负载匹配（代码执行 vs GUI 交互 vs 浏览器）
• 评估沙箱逃逸风险——SandboxEscapeBench 报告基于 Docker 的容器有 15%-35% 逃逸成功率
• 对不可信输入启用提示注入防护
• 配置会话级别的权限边界，避免逐动作人工审批
• 设置沙箱生命周期策略（最大运行时间、资源限制）
• 为评估场景确保沙箱可快速重置

3. 第二层：工具接口与协议（T）

3.1 协议标准选型：MCP vs A2A

当前两大协议标准占据不同边界：

选型建议：

• 构建工具集成层时优先选 MCP，生态最成熟
• 多 Agent 协作场景考虑 A2A
• 简单场景可直接用 AGENTS.md 文件在版本控制中编码工具约束
• API 描述标准（OpenAPI）仍为基础构建块

3.2 工具设计原则

来自 OpenAI、Anthropic 和 LangChain 生产部署的核心原则：

• 更少但更好的工具：过多工具菜单降低可靠性、增加令牌开销、放大规划错误。如果一个人类工程师无法判断哪个工具适用，就别指望模型能做到
• 为 Agent 设计而非复制人类 API：工具接口应为 Agent 使用而优化，参数命名要描述性强以发挥模型优势
• 渐进式披露：不一次性加载所有信息。维护轻量标识符（文件路径、查询、链接），按需加载数据
• 自包含且鲁棒：每个工具应自包含、容错且用途明确

3.3 工具发现与选择机制

当工具数量增长时，发现管道成为一阶决定因素：

• 检索感知编排：通过语义搜索动态选择相关工具子集
• 工具注册表质量直接影响下游 Agent 成功率
• EASYTOOL、AnyTool、CRAFT 等项目通过自动构建工具管道减少手动说明负担

3.4 操作清单

• 审视现有工具集成方式，评估从薄包装迁移到 MCP 的价值
• 用"更少但更好"原则审查工具菜单，移除低价值工具
• 为每个工具编写清晰的描述和参数文档，站在模型视角而非人类视角
• 实现渐进式披露：工具定义精简，详情按需加载
• 工具超过 20 个时引入检索感知编排
• 确保工具结果可被序列化和缓存

4. 第三层：上下文与记忆管理（C）

4.1 三层记忆架构

上下文管理是执行器工程中最直接影响 Agent 行为质量的一层。三个时间尺度的技术栈：

短期（主动上下文窗口）：

• 窗口策略：滑动窗口和基于令牌的预算管理
• 结构化组织：分块、RAG 检索增强
• 动态压缩：上下文优先化、选择性信息丢弃
• KV-cache 感知设计：Manus 团队将 KV-cache 命中率称为"生产级 AI Agent 最重要的单一指标"——Claude Sonnet 上缓存令牌 3.00/MTok

中期（会话状态与跨运行持久性）：

• 结构化笔记：Agent 维护 NOTES.md 或 todo.md，每次运行开始时读取，上下文清除前更新
• 跨运行注入：捕获上一轮运行的关键输出，注入到下一轮开头
• claude-mem 等工具实现插件式记忆层，无需向量数据库

长期（持久化记忆系统）：

• 向量数据库（Pinecone、Weaviate、Chroma）用于语义检索
• Mem0 混合架构（向量+图+键值存储）已达 1400 万次 Python 下载，在 LOCOMO 基准上比 OpenAI 原生记忆高 26% 准确率，令牌用量减少 90%
• A-MEM 借鉴 Zettelkasten 方法，记忆随知识积累动态演化
• Honcho 构建用户模型而非事实存储，异步推理管道持续处理历史交互

4.2 长时域上下文技术

超过 100 轮交互保持连贯性的关键技术：

• 上下文压缩（Compaction）：窗口接近限制时摘要并压缩状态后重新初始化。推荐工作流：先最大化召回（捕获所有潜在相关信息），再迭代提高精度（移除冗余）
• 子 Agent 上下文隔离：将子任务委派给独立 Agent，每个有全新上下文窗口，仅返回 1000-2000 令牌摘要给编排者
• 混合决策框架：预加载始终需要的内容 → 即时检索条件性需要的内容 → 窗口饱和时压缩历史 → 子任务需要深度探索时派生子 Agent

4.3 上下文漂移问题

上下文漂移是当前方法的根本性限制——Agent 随着轮次增加逐渐偏离原始任务目标或丢失关键信息。漂移形式包括主题迁移、信息稀释和任务退化。

当前局限：摘要丢失细粒度信息，检索可能返回无关结果，分层记忆增加管理开销。所有方法都无法完全解决模型在长窗口末端的注意力稀释问题。

4.4 操作清单

• 为系统提示、工具定义建立稳定的前缀结构以最大化 KV-cache 命中率
• 上下文设计遵循追加模式，避免修改历史消息
• 实现三级记忆架构：窗口内→跨运行→持久存储
• 配置自动化压缩策略：在上下文达到阈值时触发，基础设施负责压缩而非依赖 Agent
• 对深度探索性子任务使用子 Agent 隔离，避免污染编排者上下文
• 评估你的 Agent 在 50+ 轮后的行为漂移程度

5. 第四层：生命周期与编排（L）

5.1 单智能体内部循环

ReAct 范式仍是基础：模型接收上下文→生成思维→确定动作→执行动作→观察结果→重复。循环中的工程决策直接影响 Agent 质量和可靠性：

• 预算限制：最大步数、每步令牌预算
• 重试策略：失败时的回退和重试逻辑
• 失败处理：工具调用失败时的降级路径
• 人类反馈循环：关键决策点的人机交互

5.2 多智能体编排模式

流程执行说明：

• 编排 Agent 接收复杂任务后先分解为独立子任务
• 子 Agent 并行执行，各自拥有独立上下文窗口，避免上下文污染
• 每个子 Agent 仅返回 1K-2K 令牌摘要给编排者，详细探索上下文留在子 Agent 内部
• 编排者整合所有子任务结果后返回最终输出
• 复杂子任务可共享编排者上下文，但会付出 KV-cache 代价

四种主流编排模式：

• 主从模式：一个主导 Agent 分配任务给下属，适合层级清晰的任务
• 团队模式：平等 Agent 协作，适合创造性任务
• 市场模式：Agent 竞标任务，适合资源优化场景
• 层次模式：多层组织，每层不同抽象级别，适合大型复杂系统

5.3 完整生命周期管道

在软件工程 Agent 中，执行器将端到端工作流建模为可管理管道：

问题解析 → 分支创建 → 代码生成 → 测试执行 → 评审反馈 → PR 创建。每个步骤由不同工具或 Agent 角色处理，执行器编排整个生命周期。

5.4 操作清单

• 明确单智能体循环的终止条件，避免无限循环
• 为工具调用失败设计降级路径
• 根据任务结构选择编排模式：简单任务用单 Agent，可分解任务用主从，创造性任务用团队
• 子 Agent 间上下文共享需权衡隔离成本和协调收益
• 实现检查点和恢复机制，允许 Agent 在瞬时故障后恢复而不丢失任务状态
• 配置生命周期钩子自动触发压缩或记忆整合

6. 第五层：可观测性与运营（O）

6.1 追踪与监控平台选型

可观测性层拥有独立工具生态系统：

6.2 成本跟踪与优化

Agent 执行产生可变令牌和计算成本。可观测性平台应提供：

• 成本归因：按任务、按动作、按会话分解
• 预算管理：设定上限和告警
• 缓存命中率监控：KV-cache 命中率是成本优化的核心指标
• 成本优化建议：识别重复调用、低效工具使用

6.3 可靠性工程指标

关键 SLO/SLI 指标：

• 任务完成率（按任务类型分解）
• 平均执行时间（P50/P95/P99）
• 重试率：哪些步骤最常需要重试
• 错误率（按错误类型分类）
• 人工干预率：多少步骤触发了人类审批
• 沙箱逃逸检测

6.4 操作清单

• 从第一天就集成追踪平台，不要等出了问题再加
• 建立按任务类型的成本基线，设置预算告警
• 监控 KV-cache 命中率作为核心性能指标
• 定义 Agent 系统的 SLO（完成率、延迟、错误率）
• 配置异常检测规则，特别是工具调用超时和成本飙升
• 轨迹数据保留策略与隐私合规对齐

7. 第六层：验证与评估（V）

7.1 评估生命周期五阶段

流程执行说明：

• 阶段1选定基准测试并定义任务规范
• 阶段2验证沙箱配置、工具可用性、上下文准备就绪
• 阶段3在受控环境中执行并捕获完整轨迹（模型调用、工具调用、时间戳）
• 阶段4通过多级判断管道：语法正确性→功能正确性→性能→安全→行为约束，并将失败追溯到具体动作
• 阶段5将评估结果反馈到持续改进循环中

7.2 基准测试选型

7.3 失败归因方法

多级判断管道将失败追溯到具体动作或决策点：

• 语法正确性：输出是否可解析
• 功能正确性：是否解决了定义的问题
• 性能：执行效率是否可接受
• 安全性：是否有注入或逃逸
• 行为约束：是否遵循了定义的规则

失败归因的关键价值在于区分"模型能力不足"和"执行器配置不当"——这直接决定了改进方向。

7.4 操作清单

• 为你的 Agent 场景选择合适的基准测试
• 建立评估流水线：从任务定义到持续回归的完整五阶段
• 区分"模型问题"和"执行器问题"的失败归因——这决定了优化方向
• 每次执行器变更都进行回归测试
• 设置 CI 中的评估门禁：关键指标不下降才允许部署
• 收集生产轨迹用于离线分析和执行器改进

8. 第七层：治理与安全（G）

8.1 权限模型设计

治理层通过权限模型控制 Agent 行为：

• 基于角色的访问控制（RBAC）：按 Agent 角色分配权限
• 基于属性的访问控制（ABAC）：按上下文属性动态授权
• 能力系统：显式授予最小必要能力
• 身份联合：与企业 IAM 集成

关键设计原则：安全约束和操作可用性之间的平衡。Anthropic 沙箱经验证明：正确的设计可以同时提升两者。

8.2 声明式宪法与审计

声明式宪法将 Agent 行为约束定义为可验证规则而非隐式提示指令：

• 策略检查可审计且不可绕过
• 提示指令可以被注入覆盖，声明式规则不会
• 策略与执行分离，便于独立审计

审计基础设施需记录：

• 所有动作和决策点
• 所有策略检查结果
• 所有人员干预记录
• 完整的调用链和上下文状态

8.3 生命周期钩子

在 Agent 执行关键点插入安全策略：

• 动作前验证：在执行前检查工具调用是否符合策略
• 动作后审计：执行后记录和评估
• 失败处理：安全失败降级路径
• 人机交互门控：高风险操作需人工确认

8.4 操作清单

• 定义 Agent 的最小必要权限集，默认拒绝
• 实现声明式行为约束而非纯提示约束
• 部署完整的审计日志基础设施
• 在关键生命周期点插入安全钩子
• 定期进行沙箱逃逸测试和提示注入测试
• 将治理层与可观测层集成，实现实时安全告警

9. 跨层综合与权衡

9.1 成本-质量-速度三元悖论

Agent 执行器设计面对三方权衡：更高质量的 Agent 通常需要更多计算和推理时间，更快的执行可能牺牲质量或增加成本。没有普适最优解，必须根据场景选择：

• 面向用户的交互场景：速度优先，质量可接受即可
• 后台批处理任务：质量和成本优先，速度可放宽
• 安全关键场景：质量不可妥协，成本和速度让位

9.2 能力-控制权衡

增加 Agent 能力通常需要放宽控制约束，加强控制可能限制可执行操作。治理层（G）和工具层（T）之间的交互是关键设计点：

• 更多工具 = 更多能力但也 = 更大攻击面
• 更严格的权限 = 更安全但也 = 更多人工干预
• 沙箱平衡：定义足够大的自由区域同时确保安全边界

9.3 执行器耦合问题

各层之间的耦合程度是设计选择：

• 紧密耦合：可能提供优化机会但降低可替换性
• 解耦：增加灵活性但可能引入性能开销
• 实践中：大多数生产系统采用渐进式耦合——核心层（E-T-C-L）较紧密，控制层（O-V-G）较松散

10. 实战案例

10.1 案例一：构建代码智能体的执行器

假设你要为团队构建一个自动化代码修复 Agent，以下是用 ETCLOVG 框架进行架构检查的过程：

E（执行环境）：选择代码专用沙箱（E2B 或 sandboxed.sh），配置 Docker 容器，设置 30 分钟超时和 4GB 内存限制。

T（工具接口）：通过 MCP 暴露文件读写、Git 操作、Shell 执行三个工具。每个工具参数命名清晰（用 file_path 而非 fp），错误信息结构化。

C（上下文管理）：

• 短期：项目 CLAUDE.md 在会话开始时加载，具体文件内容通过 glob/grep 按需检索
• 中期：维护 WORKING_NOTES.md 记录当前修复进展
• 长期：Mem0 存储用户代码风格偏好和历史修复模式

L（生命周期编排）：

• 单 Agent 循环：理解 Issue → 定位代码 → 生成修复 → 运行测试 → 创建 PR
• 终止条件：最多 20 步或测试通过
• 失败恢复：3 次重试后退化为请求人工协助

O（可观测性）：Langfuse 追踪每个修复的完整轨迹，按 Issue 归因成本，P95 延迟 < 5 分钟。

V（验证）：SWE-bench 作为离线评估基准，CI 中设置修复成功率 > 60% 的门禁。

G（治理）：沙箱内可自由操作，PR 创建需人工确认。声明式规则："不得修改 LICENSE 文件"、"不得访问网络"。

10.2 案例二：多智能体客服系统的架构检查

假设你要为一个电商平台构建多智能体客服系统，以下是用 ETCLOVG 框架进行架构检查的过程：

E（执行环境）：K8s Agent Sandbox 抽象层统一管理多个沙箱后端，每个会话独立沙箱。

T（工具接口）：

• 内部工具通过 MCP 暴露（知识库查询、工单创建、订单查询）
• Agent 间通过 A2A 协议协作
• 工具从 50 个精简到 12 个后成功率提升 15%

C（上下文管理）：

• 用户身份和对话历史注入到每个会话
• A-MEM 风格的动态知识网络连接相关历史案例
• 超过 30 轮自动触发压缩

L（生命周期编排）：主从模式——一个路由 Agent 将查询分类后分配给专业子 Agent（技术支持/订单/投诉），复杂问题多 Agent 协作。

O（可观测性）：OpenLLMetry + Grafana 仪表板，按查询类型分解完成率和客户满意度。

V（验证）：每周 A/B 评估执行器变更对客户满意度的影响。

G（治理）：PII 数据自动脱敏，高风险操作（退款、账号变更）需人工确认，完整审计轨迹保留 90 天。

11. 总结

Agent Harness Engineering 代表 AI 工程实践的下一个前沿。核心要点：

• 执行器而非模型是长时域 Agent 可靠性的瓶颈约束——仅基础设施优化就能带来 10 倍以上的性能差异
• ETCLOVG 七层框架提供系统性的架构检查清单：E（环境）、T（工具）、C（上下文）、L（编排）、O（可观测）、V（验证）、G（治理）
• 每一层都有成熟的开源和商业工具生态，团队无需从头构建
• 可观测性和治理是常被忽视但至关重要的控制平面层
• 三层记忆架构（短期窗口→中期会话→长期存储）是避免上下文漂移的基础
• 上下文管理应作为基础设施职责而非 Agent 职责——执行器自动处理压缩和整合，模型专注任务推理

Agent 执行器工程不是一个可选的附加项，而是决定生产部署成败的核心系统层。那些只关注模型能力而忽视执行器质量的团队，最终会发现他们的 Agent 在演示中表现出色，在生产中却不可靠。而认真对待这一层的团队，将获得模型本身无法提供的可靠性增益。

参考文献

[1] Agent Harness Engineering: A Survey（原始综述论文）: https://picrew.github.io/LLM-Harness/main.pdf

[2] Awesome-Agent-Harness（项目页面与开源项目列表）: https://github.com/picrew/Awesome-Agent-Harness

[10] 专知 VIP 中文解读: https://www.zhuanzhiai.com/vip/7482a834879338e10bb186a672582084