Agent Harness Engineering: A Survey(译)

智能体执行框架工程：一项综述

Junjie Li¹˒⁶,，Xi Xiao⁶,，Yunbei Zhang⁵,，Chen Liu²,，
Lin Zhao⁴，Xiaoying Liao³，Yingrui Ji⁶，Janet Wang⁶，
Jianyang Gu⁷，Yingqiang Ge⁹，Weijie Xu⁹，Xi Fang⁹，Xiang Xu⁹，
Tianchen Zhao⁹，Youngeun Kim⁹，Tianyang Wang⁶，Jihun Hamm⁵，
Smita Krishnaswamy²，Jun Huan⁹，Chandan K Reddy⁸˒⁹

¹CMU，²Yale，³JHU，⁴NEU，⁵Tulane，⁶UAB，⁷OSU，⁸Virginia Tech，⁹Amazon

项目页面：Awesome-Agent-Harness

摘要

大语言模型（LLM）智能体在生产环境中的快速部署揭示出一个反复出现的模式：任务执行的可靠性，与其说取决于底层模型，不如说更取决于包裹该模型的基础设施层，即智能体执行框架。本文提供了一项基于实践、系统化的智能体执行框架工程研究，并围绕三个主张展开。

第一，智能体执行框架是一个独立的系统层，其工程质量决定了现实世界可靠性的很大一部分。我们通过从提示词到上下文再到执行框架工程的三阶段工程演进、一个覆盖成本—质量—速度三难困境、能力—控制权衡以及执行框架耦合问题的跨层综合分析，以及一个同时扎根于研究空白和生产痛点的开放问题议程来阐述这一立场。

第二，我们提出 ETCLOVG，一个七层分类体系：执行环境（Execution environment）、工具接口（Tool interface）、上下文管理（Context management）、生命周期/编排（Lifecycle/Orchestration）、可观测性（Observability）、验证（Verification）、治理（Governance）。该分类体系扩展了此前的六组件框架，将可观测性和治理视为独立的架构关注点。

第三，我们将 170 多个开源项目映射到这一分类体系上，以揭示生态系统模式、覆盖空白和新兴设计原则；同时，我们还提炼了来自 OpenAI、Anthropic 和 LangChain 生产部署中的工程原则，用以弥合实践者知识与研究术语之间的差距。 图 1： 提示词工程、上下文工程与执行框架工程的简要比较。

---

目录

1 引言 4

1.1 约束瓶颈：执行框架而非模型 4

1.2 实践者—研究差距 4

1.3 范围与贡献 4

2 背景与分类体系 5

2.1 智能体系统的演进 5

2.2 三个工程阶段 6

2.3 ETCLOVG 七层分类体系 7

2.4 范围 9

2.5 项目收集流程 9

2.6 纳入与排除标准 10

2.7 编码协议 10

2.8 语料库的局限性 10

2.9 聚合分析 10

3 执行环境与沙箱（E）11

3.1 范围与概念 11

3.2 智能体沙箱的类别 12

3.3 威胁模型与沙箱逃逸 15

3.4 部署模式 15

3.5 小结 16

4 工具接口与协议层（T）16

4.1 协议与接口标准 17

4.2 工具描述、发现与选择 17

4.3 工具增强训练与集成 18

4.4 可扩展性与会话管理 18

5 上下文与记忆管理（C）18

5.1 为什么必须工程化上下文 19

5.2 从提示词工程到上下文工程 20

5.3 短期：管理活跃上下文窗口 20

5.4 中期：会话状态与跨运行持久化 21

5.5 长期：持久化记忆系统 22

5.6 长周期技术：让智能体在 100 多轮交互中保持连贯 24

5.7 上下文漂移与当前方法的局限 24

6 生命周期与编排（L）25

6.1 生命周期状态管理 26

6.2 单智能体内部循环 27

6.3 多智能体编排模式 27

6.4 从 Issue 到 Pull Request 的完整生命周期流水线 27

7 可观测性与运维（O）28

7.1 追踪与监控平台 28

7.2 智能体专用运维平台 29

7.3 成本追踪与优化 30

7.4 可靠性工程 30

7.5 讨论：迈向统一可观测性 31

8 验证与评估（V）32

8.1 作为任务到反馈生命周期的执行框架评估 32

8.2 阶段 1：任务与基准定位 33

8.3 阶段 2：执行前就绪性验证 34

8.4 阶段 3：受控执行与轨迹捕获 35

8.5 阶段 4：多层级判断与失败归因 36

8.6 阶段 5：持续回归与部署反馈 38

8.7 小结 39

9 治理与安全（G）39

9.1 权限模型与身份管理 39

9.2 生命周期钩子 41

9.3 组件加固 42

9.4 声明式宪章 43

9.5 审计基础设施 44

9.6 将治理置于智能体安全图景之中 45

9.7 研究方向 46

10 跨领域关注点 47

11 跨层综合 48

11.1 成本—质量—速度三难困境 48

11.2 能力—控制权衡 48

11.3 执行框架耦合问题 48

11.4 从智能体框架到智能体平台 48

11.5 开放研究议程 49

12 开放问题与未来方向 49

12.1 加固与扩展执行环境 49

12.2 维护长时间运行智能体中的可靠状态 49

12.3 从智能体轨迹中诊断失败 50

12.4 智能体、工具与人类之间的标准交接 50

12.5 随着模型改进，保持执行框架的有用性 51

13 结论 51

1 引言

1.1 约束瓶颈：执行框架而非模型

总体而言，基于 LLM 的智能体研究，在很大程度上一直是对模型的研究。研究议程围绕模型能够做什么展开：它是否能够进行多步骤规划，是否能够可靠地调用工具，是否能够检索并压缩相关记忆，或者是否能够与其他智能体协作。其隐含假设是：智能体能力主要是模型能力的函数，即一个足够强大的模型配合一个足够好的提示词，就会产生足够可靠的行为。

近期的经验证据挑战了“更好的模型本身就会产生更可靠智能体”这一假设。三项近期结果确立了这一模式。Bölük（2026a）仅修改了编辑工具格式及其周边工具执行框架，并未修改模型，却报告称在 15 个模型的代码基准测试上取得了最高 10 倍的提升。Trivedy（2026）通过系统提示词重构、中间件上下文注入以及自验证钩子，将一个固定的 GPT-5.2-Codex 智能体在 Terminal-Bench 2.0 上的表现从 52.8% 提升到 66.5%，提升了 13.7 个百分点，而这一提升完全由基础设施变更实现。Meta-Harness（Lee et al., 2026）通过自动化执行框架优化，在 Terminal-Bench-2 上达到 76.4%，在不修改模型权重的情况下超过了所有人工工程化方法。在每个案例中，变量都是执行框架，也就是治理上下文构建、工具交互、编排、反馈和执行约束的基础设施层；模型则保持固定。这些仅由执行框架带来的收益，都超过了同一基准测试中通常被认为有意义的模型进步所带来的 2 到 4 个百分点提升。该模式并非偶然：驱动结果的是执行框架，而不是模型。

我们将这一模式称为约束瓶颈论（binding-constraint thesis）（Bölük, 2026b）：对于在可比较前沿模型之间评估的长周期任务，基准差异可能同样多地由执行框架驱动，而不是由模型本身驱动。我们用这一论点作为本文余下部分的框架。

第 2 节中的图 3 从历史角度展示了同样的转变：早期系统将能力集中在单一模型循环中，而后来的系统越来越多地将可靠性暴露为一个跨层基础设施问题。

1.2 实践者—研究差距

实践者的紧迫需求与研究界的术语体系之间存在一种张力。OpenAI 明确将“执行框架工程”（harness engineering）界定为一种围绕 Codex 智能体来设计环境、约束、文档和反馈循环的学科，并在 2026 年 2 月报告称，一个小团队在五个月内产出了一个约一百万行代码的内部产品，期间并未手写生产代码（OpenAI, 2026a）。Anthropic 关于智能体工程的文章则从相邻方向得出了同一原则：有效的智能体应当使用简单且可检查的架构；工具接口应当面向智能体使用来设计，而不是照搬面向人类的 API；上下文应当渐进式披露，而不是一次性急切加载；长时间运行的工作需要持久化的交接工件和可恢复的执行基础设施（Anthropic, 2024a; Aizawa, 2025; Anthropic Applied AI Team, 2025; Anthropic, 2025d; 2026b）。Martin Fowler 网站上的一篇文章将执行框架工程描述为“AI 智能体的控制论调节器”，由前馈指南和反馈传感器构成，并围绕 LLM 形成控制循环（Böckeler, 2026）。

与此同时，研究界已经越来越精确地研究智能体系统的各个组成部分：记忆、工具使用、规划和安全。然而，尚未被系统研究的是将这些组件整合为可靠运行状态的系统。其结果就是一种实践者—研究差距：实践者知道执行框架基础设施很重要，但缺少正式术语来描述其重要性的原因，也就难以用能够支持系统化改进的方式来表达这一问题。本文试图弥合这一差距。

1.3 范围与贡献

本文聚焦于包裹语言模型的基础设施层，该层用于管理长时间运行的、多步骤任务执行。我们不将智能体框架作为开发工具、智能体平台作为产品类别，或模型能力本身作为综述对象，尽管这三者都会影响我们的分析。图 4 总结了支撑本文余下部分的七层分类体系。

我们的贡献围绕三个主张组织。

1. 主张 1（概念性）： 基于约束瓶颈论（Bölük, 2026b），我们认为，制约现实世界智能体可靠性的瓶颈是执行框架，而不是模型本身。三项近期结果显示，仅由执行框架带来的收益包括：代码基准测试上最高 10 倍的提升、Terminal-Bench 2.0 上提升 13.7 个百分点，以及 Terminal-Bench-2 上达到 76.4%（第 1 节）；每一项都超过了同一基准测试中典型的模型驱动收益。我们通过三个工程阶段的演进（第 2 节）、覆盖成本—质量—速度三难困境、能力—控制权衡以及执行框架耦合问题的跨层综合分析（第 11 节），以及一个开放问题议程（第 12 节）来展开这一论点。

2. 主张 2（分类性）： ETCLOVG 七层分类体系将可观测性和治理视为一等层，而不是生命周期钩子的副作用。二者各自拥有独立的生产工具栈：可观测性一侧包括 Langfuse 和 OpenTelemetry；治理一侧包括权限引擎、网关和审计流水线；在生产部署中，它们也通常由不同团队负责。我们还将状态管理置于生命周期与编排之中，因为状态天然存在于读取和写入它的执行流旁边（第 2.3 节）。

3. 主张 3（经验性）： 将 148 多个开源项目映射到 ETCLOVG，可以显示生态系统中哪些位置密集、哪些位置稀疏，以及早期语料库遗漏了哪些类别。该映射是迄今最大的开源智能体执行框架语料库。执行、工具、生命周期和验证覆盖密集；可观测性和治理覆盖较稀疏，并且更常存在于商业平台中；早期语料库中缺失的三个类别，包括任务运行器、多智能体编排器和规范驱动开发工具，如今已成为一等类别。方法论小节（第 2.4–2.9 节，附录 A）使编码过程可复现，而该映射也支撑了第 3–9 节逐层展开的观察。

2 背景与分类体系

2.1 智能体系统的演进

从早期的思维链提示到自主智能体的发展轨迹，可以理解为实践者必须管理的工程表面逐步扩展的过程。

ReAct 时代（2022–2023）。 Yao 等人（2023）将观察—思考—行动循环确立为一种基础原语。早期系统以最少的基础设施运行：一个 while 循环、一个提示词模板，以及一张小型工具分发表。AutoGPT 和 BabyAGI 通过用任务队列、记忆和工具分发来包裹语言模型调用，展示了完全自主运行的雄心；同时，它们也让执行失控、上下文膨胀、状态丢失和未受监控的副作用等失败模式暴露出来，使这些问题显现为基础设施问题，而不仅仅是提示词问题（Significant Gravitas, 2023; Nakajima, 2023）。

工具集成与多智能体协作（2023–2024）。 Gorilla、ToolLLM 和 Toolformer 证明，工具使用能力可以被学习或诱导出来，而不是硬编码到固定的 API 包装器中（Patil et al., 2024b; Qin et al., 2024; Schick et al., 2023）。CAMEL、ChatDev、MetaGPT 和 Mixture-of-Agents 引入了多智能体协作模式，范围从角色扮演式对话，到软件开发组织，再到分层智能体聚合（Li et al., 2023a; Qian et al., 2023a; Hong et al., 2023; Wang et al., 2024）。评估基础设施随着 SWE-bench、AgentBench、WebArena 和 GAIA 的出现而成熟（Jimenez et al., 2024; Liu et al., 2023a; Zhou et al., 2024; Mialon et al., 2023），而协议标准化则从 Anthropic 的 MCP 和 Google 的 A2A 开始（Anthropic, 2024c; Surapaneni et al., 2025）。

执行框架转向（2025–2026）。 到 2025 年，已经积累了足够多的部署经验，足以清楚地说明：智能体可靠性的约束瓶颈是基础设施质量，而不是模型质量。2026 年初的三项独立进展验证了这一转变：OpenAI 明确采用“执行框架工程”作为一门学科；Stanford/MIT 的 Meta-Harness 表明自动化执行框架优化能够超过人工工程化；LangChain 的 DeepAgents 仅通过执行框架层变更，就在 Terminal-Bench 2.0 上从 52.8% 提升到 66.5%，对应 13.7 个百分点的提升和约 26% 的相对改进（OpenAI, 2026a; Lee et al., 2026; Trivedy, 2026）。

2.2 三个工程阶段

2022–2026 年期间显示出一种连贯的三阶段演进，即该领域选择工程化的对象发生了变化。

提示词工程（2022–2024）。 主要杠杆是输入提示文本。实践者通过构造更好的指令、少样本示例和推理模板来进行优化。工程范围很窄：优化传给单次模型调用的单个文本输入。

上下文工程（2025）。 随着智能体变得更长时间运行，约束瓶颈从“输入是什么？”转向“模型在每一步应该看到什么信息？”这一阶段聚焦于上下文管理：每一轮注入什么内容，如何检索和压缩记忆，如何按相关性对工具结果排序，以及如何处理上下文窗口饱和。其范围从单个输入扩展为管理流入上下文窗口的多个信息流（Anthropic Applied AI Team, 2025）。

执行框架工程（2026）。 随着模型变得足够强大，可以处理长时间运行的任务，可靠性越来越取决于维护状态、调解工具、注入反馈、执行约束并验证进展的基础设施包装层。这一观察与约束瓶颈视角一致，即长周期智能体性能是由耦合的模型—执行框架系统产生的，而不是由模型单独产生的（Bölük, 2026b）。因此，执行框架工程所追问的是：为了使智能体系统可靠，必须围绕模型设计怎样的治理、约束、反馈循环和执行控制。在我们的分类体系中，这一阶段将 ETCLOVG 的全部七层视为一个整体来处理（OpenAI, 2026a; Böckeler, 2026; LangChain, 2026b）。

每个阶段都包含前一个阶段：执行框架工程包括上下文工程，而上下文工程包括提示词工程。这三个阶段在时间和概念上也存在重叠，而不是以清晰边界依次替代。提示词工程至今仍是执行框架实践中的活跃组成部分，而上下文工程也在与本文所综述的执行框架层关注点并行成熟。因此，我们的阶段划分最好被理解为边际工程投入方向的转移，而不是一系列替换。 图 2： 基于 LLM 的智能体系统执行框架工程分类体系示意图。E、T、C 和 L 四层构成系统的结构性支柱。O 层提供全系统监控，V 层跨组件提供评估和反馈。G 层在整个系统之上执行治理与安全约束。配色方案对应第 2.3 节中提出的 ETCLOVG 各层。 图 3： 2022 年至 2026 年代表性智能体执行框架系统的时间线。该时间线展示了从早期单循环智能体，到更丰富的执行框架基础设施的转变；后者跨越执行环境、工具接口、上下文与记忆管理、生命周期编排、可观测性、验证和治理。配色方案对应第 2.3 节中提出的 ETCLOVG 各层。

2.3 ETCLOVG 七层分类体系

我们提出一个用于智能体执行框架工程的七层分类体系。我们用缩写 ETCLOVG 指代它，分别代表执行（Execution）、工具（Tooling）、上下文（Context）、生命周期（Lifecycle）、可观测性（Observability）、验证（Verification）和治理（Governance）。图 4 给出了紧凑的视觉化地图；本小节则确定本文其余部分所使用的解释方式。

前四层描述执行框架的结构性核心。执行（E）决定智能体代码在哪里运行，以及由什么沙箱约束来限制它；工具（T）规定外部能力如何被描述、发现和调用；上下文（C）控制模型在短期、会话级和持久化时间尺度上能够看到什么；生命周期（L）组织读取和写入这些状态的控制流，从单智能体循环，到多智能体工作流，再到从 issue 到 pull request 的工作流。后三层描述围绕该核心的控制平面。可观测性（O）捕获轨迹、成本、失败和可靠性信号；验证（V）将任务和轨迹转化为评估、失败归因和回归反馈；治理（G）通过权限、身份、策略、加固、审计和人类监督机制约束行为。第 3–9 节将依次展开这七层，而第 10–12 节将综合那些不属于任何单一层的跨层权衡和开放问题。

有两个设计选择将这一分类体系与其他体系区分开来。第一，我们将可观测性（O）提升为一个独立层，而不是将其视为生命周期钩子的副作用。在生产系统中，可观测性拥有专门的工具生态系统（Langfuse、Arize Phoenix、OpenLLMetry）和独特的工程实践（OpenTelemetry 插桩、成本归因、异常检测），因此值得被独立处理。第二，我们引入治理（G）作为一等层，用以覆盖跨三个子层的完整安全与合规问题谱系：模型层（护栏、内容过滤器）、系统层（网关、代理、权限模型）和组织层（审计、合规、人类在环监督）。

图 4(下方列表)： 智能体执行框架工程分类体系的细节。每个分支对应一个 ETCLOVG 层及其主要子类别；代表性系统和论文将在后续章节讨论。

智能体执行框架工程

执行环境与沙箱（E）（第 3 节）

• 通用型托管沙箱
• 计算机使用智能体基础设施
• 代码专用沙箱
• 框架集成式运行时
• 浏览器评估环境
• 操作系统级权限沙箱
• 沙箱抽象层

工具接口与协议（T）（第 4 节）

• 协议与接口标准
• 工具描述、发现与选择
• 工具增强训练与集成
• 可扩展性与会话管理

上下文与记忆管理（C）（第 5 节）

• 短期活跃上下文窗口
• 中期会话状态与跨运行持久化
• 长期持久化记忆系统
• 长周期上下文技术
• 上下文漂移与局限

生命周期与编排（L）（第 6 节）

• 单智能体内部循环
• 多智能体编排模式
• 完整生命周期任务流水线

可观测性与运维（O）（第 7 节）

• 追踪与监控平台
• 智能体专用运维平台
• 成本追踪与优化
• 可靠性工程
• 统一可观测性

验证与评估（V）（第 8 节）

• 任务与基准定位
• 执行前就绪性验证
• 受控执行与轨迹捕获
• 多层级判断与失败归因
• 持续回归与部署反馈

治理与安全（G）（第 9 节）

• 权限模型与身份管理
• 生命周期钩子
• 组件加固
• 声明式宪章
• 审计基础设施
• 智能体安全图景

状态管理天然属于生命周期与编排（L），并与读取和写入状态的执行流处于同一位置；生命周期钩子和策略执行则属于治理（G），在那里它们与其他约束机制保持一致。

2.4 范围

我们使用“智能体执行框架”这一概念时，其含义比“LLM 周围的任何软件”更窄：执行框架是一个工程化包装层，它通过执行基底、工具接口、上下文控制、编排、可观测性、评估反馈和治理约束，将模型调用转化为有边界、有状态、由工具中介的任务执行（OpenAI, 2026a; Anthropic, 2025d; LangChain, 2026b）。因此，分析单位是使长时间运行的智能体行为变得可控、可检查和可恢复的基础设施，而不是基础模型或提示词本身。我们按功能而不是产品类别来划定边界：当一个智能体框架暴露出可复用机制，例如有状态编排、工具路由、运行时策略钩子或轨迹捕获时，它就在本文范围内；而一个薄的模型 API 包装器、提示词库、静态数据集、通用容器运行时、向量数据库、APM 仪表盘或内容过滤器则不在范围内，除非它被明确适配到智能体执行、状态、评估或工具使用治理中。

2.5 项目收集流程

我们将语料库构建为对公开记录的智能体执行框架工件的系统化映射，并使用系统综述的报告规范来明确源流、搜索策略和选择流程（Page et al., 2021）。如图 5 所示，候选项来自四类来源：既有综述和基准论文；围绕名称、描述、README 文本、主题、星标数、近期性和归档状态进行的可复现 GitHub 搜索；精选项目列表和包注册表；以及介绍执行框架层机制的公司工程博客或发布说明（Meng et al., 2026; Jimenez et al., 2024; Liu et al., 2023a; Zhou et al., 2024; GitHub, 2026; OpenAI, 2026a; Anthropic, 2025d; LangChain, 2026b）。

代表性查询结合了诸如 agent harness、coding agent、LLM agent sandbox、MCP server、agent observability、agent memory、agent evaluation 和 agent governance 等术语。对于每个保留候选项，我们记录项目名称、URL、工件类型、来源类型、可用状态、可识别的发布年份、可用的 GitHub 元数据，以及用于后续 ETCLOVG 编码的公开证据；本版本报告的元数据快照冻结于 2026 年 5 月 08 日。 图 5： 语料库构建协议。候选工件从 GitHub、论文、精选列表、包注册表和公司工程来源中收集，然后进行去重，根据纳入标准检查，并使用公开文档映射到 ETCLOVG 各层。

2.6 纳入与排除标准

一个项目若满足三个条件则会被纳入：它有公开文档；它实现或规定了一个具体的执行框架层机制；可用证据足以为其分配至少一个 ETCLOVG 层。这包括具有可复用编排或工具路由逻辑的智能体框架、实例化可执行智能体环境的基准、为智能体执行打包的沙箱，以及作用于智能体状态、轨迹、动作或策略的记忆、可观测性、评估或治理系统。我们排除了简单聊天机器人 demo、提示词包、薄模型客户端包装器、没有智能体运行时的静态数据集或排行榜、并非面向智能体的通用基础设施组件，以及无法从公开文档中检查其技术行为的产品页面。边界案例根据机制而不是标签来解决：一个仓库被命名为“agent”并不足以被纳入，而一个评估或沙箱项目如果提供了可复用的执行框架机制，则会被纳入。

2.7 编码协议

每个保留项目都会根据七个 ETCLOVG 层进行编码，依据是公开工件本身：README 文件、文档页面、论文、示例、发布说明，以及在必要时参考仓库结构。编码是多标签的，因为许多系统跨越多个层；主层标记该工件最核心的机制，而次级层只有在文档展示出一种独立能力、而不仅仅是偶然依赖时才会被分配。当前快照使用单一主编码者协议并由作者审计，而不是正式的多编码者一致性研究，因此我们不报告 Cohen’s kappa 或类似的标注者间统计指标。模糊案例会在完整集合被编码后重新审视，并采用保守规则：如果公开证据没有清楚显示一个面向智能体的机制，则不分配该层。

2.8 语料库的局限性

该语料库应被理解为对可见智能体执行框架生态系统的地图，而不是对所有已部署智能体基础设施的普查。它偏向英语来源、GitHub 可见项目、开源工件，以及维护者发布了足够实现细节以供外部编码的系统。商业生产系统代表性不足，除非其工程博客、文档或 SDK 暴露了相关机制；而代码智能体基础设施则代表性过高，因为它拥有异常丰富的公开轨迹：仓库、基准、沙箱、从 issue 到 pull request 的工作流，以及发布说明。层分配也反映公开文档而不是私有架构，因此某一层的缺失意味着“没有公开证据”，而不是“未被实现”。

2.9 聚合分析

170 多个项目的映射显示出一个广泛但不均衡的生态系统。执行、工具接口、生命周期编排和验证拥有最密集的可见覆盖，因为代码、网页、终端和计算机使用智能体在变得有用之前，都需要可运行环境、工具契约、控制循环和可重复评估。上下文与记忆出现在许多项目中，但通常嵌入在更大的框架之内，而不是作为独立的执行框架组件发布。可观测性和治理在开源覆盖中更稀疏，并且更常以商业平台、SDK 功能或工程文章的形式出现，这表明运行控制比运行时和基准基础设施成熟得更晚。跨层项目正变得越来越常见：最完整的系统结合了沙箱、工具协议、编排、追踪、评估和权限控制，这支持了本文的核心主张，即执行框架工程是一个集成系统问题，而不是一组孤立附加组件的集合。

你说“继续”后，我会翻译第 3 章 Execution Environment and Sandbox（执行环境与沙箱）。

3 执行环境与沙箱（E）

我们从执行环境与沙箱（E）层开始进行逐层讨论，它是 ETCLOVG 七大支柱中的第一层（见第 1 节中的主张 2）。我们讨论的系统来自支撑主张 3 的 170 多个项目语料库。

图 6：面向 LLM 智能体的执行环境与沙箱代表性工作

执行环境与沙箱

通用型托管沙箱

Daytona（Daytona Platforms, Inc., 2024）、E2B（E2B, 2024）、Modal（Modal Labs, 2024）、Northflank（Northflank, 2024）、OpenSandbox（Alibaba, 2026）、Docker Sandboxes（Docker, Inc., 2025）

计算机使用智能体基础设施

Anthropic Computer Use（Anthropic, 2024b）、CUA（Cua, 2024）、OSWorld（Xie et al., 2024）

代码与仓库执行沙箱

Judge0（Došilović, 2024）、OpenAI Code Interpreter（OpenAI, 2023）、sandboxed.sh（Th0rgal, 2026）、langchain-sandbox（LangChain, 2025c）、Repo2Run（Hu et al., 2025a）

框架集成式运行时

OpenHands（Wang et al., 2025b）、GoEX（Patil et al., 2024a）、agent-infra sandbox（Agent Infra, 2024）、smolagents executors（Roucher et al., 2025）

浏览器评估环境

WebArena（Zhou et al., 2024）、VisualWebArena（Koh et al., 2024）、BrowserGym（Chezelles et al., 2024）、WorkArena（Drouin et al., 2024）

操作系统级权限与运行时安全

Anthropic sandbox-runtime（Anthropic, 2025g）、Claude Code sandboxing（Anthropic, 2025b）、IsolateGPT（Wu et al., 2025）、AgentBound（Bühler et al., 2025）、transactional sandboxing（Yan, 2025）

沙箱抽象、训练与评估

SWE-ReX（SWE-agent Team, 2024）、SWE-agent（Yang et al., 2024）、K8s Agent Sandbox（Kubernetes SIG Apps, 2025）、R2E-Gym（Jain et al., 2025）、EnvScaler（Song et al., 2026）、SandMLE（Zhou et al., 2026）、SandboxEscapeBench（Marchand et al., 2026）、CIBER（Ba et al., 2026） 图 6： 面向 LLM 智能体的执行环境与沙箱代表性工作，按照本章的沙箱类别组织。

3.1 范围与概念

3.1.1 定义

智能体的执行环境指的是智能体动作被物理执行的基础设施层。在 LLM 智能体语境中，执行环境与沙箱是紧密耦合的概念。因此，生产级智能体系统几乎总是在沙箱化环境中执行动作。

3.1.2 为什么沙箱化在智能体时代居于中心位置

智能体时代的沙箱化并不仅仅是从传统多租户代码执行中继承下来的安全措施。它同时服务于三个彼此不同的目的，而正是这三者的结合，使沙箱化从一个运维细节上升为智能体执行框架设计中的一等关注点。

第一个目的是安全。智能体沙箱化面临的挑战超出了传统多租户代码执行。LLM 生成的代码在规模化场景下既不可审计，也不可预测，因此无法将静态审查作为主要防御手段。智能体会在多个步骤中自主执行，因此在人类介入动作执行时机方面并不可靠。提示注入攻击可以将一个原本无害的智能体重新利用为面向沙箱攻击的载体，从而模糊可信用户意图与恶意输入之间的边界。近期关于沙箱逃逸的经验证据表明，这些担忧并非假设性的；我们将在第 3.3 节中讨论其量化证据。

第二个目的是可复现性。长周期智能体任务以及衡量这些任务的评估执行框架（第 8 节）需要能够将执行状态重置为已知基线。Docker 容器或 microVM 可以按需销毁并重建，而开发者的工作站不行；正是这一属性使基于沙箱的评估标准，例如 SWE-bench（Jimenez et al., 2024）和 OSWorld（Xie et al., 2024），变得可行。在训练阶段，当一个单一任务可能会在并行轨迹中被重放数百次时，缺少廉价重置机制本身就是一个可扩展性瓶颈。

第三个目的是活性，而它是智能体时代最具特异性的目的。没有沙箱时，智能体想要执行的每一个潜在高风险动作，例如文件写入、包安装或出站网络调用，都必须由人类显式授权。在规模化场景中，这会造成两种失败模式：用户因为受挫而放弃使用智能体，或者用户机械地批准所有请求，从而破坏权限提示本身的安全理由。沙箱通过定义一个有边界的区域来打破这一僵局，在该区域内，智能体被授权自由行动，从而将权限问题从“某个动作是否允许”转移为“某个会话如何配置”。Anthropic 报告称，在 Claude Code 中引入沙箱化后，权限提示减少了 84%，同时保留了安全性（Anthropic, 2025b）。在这一框架下，沙箱既是笼子，也是许可证；而许可证这一侧，正是自主长周期执行能够成立的前提。

在这三个目的中，安全性与传统沙箱化共享；可复现性在智能体环境中被放大；而活性则基本上是新的。三者结合在一起，正是将智能体沙箱化视为一个独立研究对象、而不只是容器技术下游应用的理由。

3.2 智能体沙箱的类别

从 2024 年到 2026 年，智能体沙箱基础设施已经从一小组通用运行时，分化为若干不同的产品类别，每一类都针对不同的智能体任务类型进行了优化。我们沿着工作负载和使用场景这一轴线，将该领域组织为七个类别；对于正在选择系统的执行框架设计者而言，我们认为这是最有信息量的分类方式。另一条正交轴线是隔离技术，包括容器、用户空间内核（如 gVisor（Google, 2018））、microVM（如 Firecracker（Agache et al., 2020）和 Kata Containers（Kata Containers Project, 2017））、WebAssembly，以及操作系统级原语（如 bubblewrap 和 Seatbelt）。这些内容将作为各小节中的设计属性讨论，而不是作为顶层类别，因为同一种隔离原语会被不同工作负载重复使用。七个类别分别是通用型托管沙箱（第 3.2.1 节）、计算机使用智能体基础设施（第 3.2.2 节）、代码专用沙箱（第 3.2.3 节）、框架集成式运行时（第 3.2.4 节）、浏览器评估环境（第 3.2.5 节）、操作系统级权限沙箱（第 3.2.6 节）和沙箱抽象层（第 3.2.7 节）。以下小节将分别介绍这些类别。

3.2.1 通用型托管沙箱

通用型托管沙箱提供商业或开源的“沙箱即服务”平台，通过 API 接口暴露任意 OCI 容器镜像，并支持 shell、文件系统、网络和解释器，以适配未被预先限定的工作负载。代表性系统包括 Daytona（Daytona Platforms, Inc., 2024），它从开发者环境转向智能体沙箱，并提供低于 90 毫秒的冷启动配置能力；E2B（E2B, 2024），一个构建在 Firecracker microVM（Agache et al., 2020）之上的智能体沙箱；Modal（Modal Labs, 2024），一个使用 gVisor（Google, 2018）并支持大规模自动扩展的 Python 平台；Northflank（Northflank, 2024），一个同时支持 Kata Containers（Kata Containers Project, 2017）、Firecracker 和 gVisor 的平台；来自 Alibaba 的 OpenSandbox（Alibaba, 2026），一个开源通用沙箱；以及 Docker Sandboxes（Docker, Inc., 2025），即 Docker 于 2025 年发布的官方基于 microVM 的产品。

这一类别中的设计决策收敛到若干模式：默认临时性的语义，同时提供可选的持久会话；以 Python 和 TypeScript SDK 形式暴露的 API 接口；以及对任意 OCI 镜像的支持。不同系统在隔离强度和运维模型上存在差异。Daytona 默认使用容器隔离，并可选支持 Kata Containers；而 E2B、Modal 和 Docker Sandboxes 默认提供 microVM 或 gVisor 隔离。Northflank 的独特之处在于，它允许每个工作负载在不同后端之间进行选择，这反映出行业已经认识到：没有任何单一隔离原语适用于所有威胁模型。我们观察到一个更广泛的趋势：从内核容器隔离转向专用内核 microVM 隔离；其驱动力在于，LLM 生成代码的系统调用模式不可预测，无法预先刻画。

3.2.2 计算机使用智能体基础设施

计算机使用智能体基础设施代表了一种独特的执行模型：智能体不是通过 API 或 shell 命令进行交互，而是通过模拟鼠标、键盘和屏幕观察来与图形界面交互。代表性系统包括 Anthropic 的 Computer Use（Anthropic, 2024b），这是一个旗舰级商业实现，使 Claude 能够直接操作桌面环境；CUA（Cua, 2024），一个开源计算机使用智能体基础设施；以及 OSWorld（Xie et al., 2024）提供的基于虚拟机的环境，它同时作为评估执行框架（第 8 节）和参考计算机使用沙箱。

这些系统将完整或近乎完整的桌面环境打包进沙箱中，通常通过 Xvfb 加窗口管理器，或通过完整虚拟机实现，并向智能体暴露像素坐标和键盘动作。其动作空间明显大于基于 API 的类别，但可靠性依赖视觉 grounding，而完整操作系统攻击面也要求更强的隔离，通常是 microVM 或完整虚拟机。与第 3.2.1 节的托管沙箱相比，计算机使用沙箱以密度和启动延迟为代价换取保真度：完整桌面环境启动更重，且比无头 shell 沙箱更难复用，但它是唯一一种能够让智能体操作无 API 应用程序的执行模型。

3.2.3 代码专用沙箱

代码专用沙箱是轻量级环境，针对代码生成、评估和数据分析进行了优化，而不是针对通用 shell 访问进行优化。代表性系统包括 Judge0（Došilović, 2024），这是一个最初为判题设计、后来被广泛复用为代码智能体评估流水线组件的代码评估沙箱；OpenAI Code Interpreter（OpenAI, 2023），即支撑 ChatGPT Advanced Data Analysis 的生产级沙箱化 Python 环境；sandboxed.sh（Th0rgal, 2026），一个面向代码智能体的 shell 沙箱；以及 langchain-sandbox（LangChain, 2025c），它使用编译为 WebAssembly 的 Pyodide（Pyodide Contributors, 2018），并在 Deno 运行时下执行，从而在本地无容器条件下沙箱化智能体生成的 Python；NVIDIA 也为客户端智能体工作流倡导了这一设计（NVIDIA, 2024）。

不同于第 3.2.1 节中的通用型沙箱，这些系统会预装编译器和解释器，默认采用请求级无状态执行，并针对高并发并行能力进行优化。这一设计选择牺牲了工作负载通用性，换取启动速度、评估吞吐量和更简单的威胁模型。一个值得注意的子趋势是：代码沙箱正在从基于容器的设计转向基于 WebAssembly 的设计。WebAssembly 提供基于能力的安全性、确定性执行以及微秒级实例化，但代价是受限的 Python 标准库和较弱的原生扩展支持。

3.2.4 框架集成式运行时

框架集成式运行时是绑定在更大智能体框架内部的执行环境，而不是作为独立沙箱产品暴露。它们与框架的编排循环、工具注册表和提示词约定一起发布，如果不采用周边框架，就无法独立使用。代表性系统包括 OpenHands runtime（Wang et al., 2025b），一个 Docker 沙箱化环境，将 bash、IPython、Chromium 浏览器和 API 服务器集成到单一镜像中；agent infra sandbox（Agent Infra, 2024），一个明确的一体化设计，将浏览器、shell、文件系统、MCP 和 VSCode 打包到同一个环境中；以及 smolagents（Roucher et al., 2025）的执行器层，它在框架内部提供 local、Docker、E2B、Modal 和 WebAssembly 执行实现。

这一类别的核心权衡在于“打包”与“组合”：框架集成式运行时优先考虑开箱即用的能力覆盖，其代价是更大的镜像体积、更慢的启动速度，以及与某个框架抽象之间的紧耦合。相较之下，第 3.2.1 节中的通用型沙箱采取了相反方法，即通过外部抽象来组合最小环境。长期来看，组合方法是否会取代打包运行时，取决于 MCP 等标准是否能够降低运行时组装能力而非构建时组装能力的成本。

3.2.5 浏览器评估环境

浏览器评估环境同时扮演沙箱和评估执行框架的双重角色。代表性系统包括 WebArena（Zhou et al., 2024），一个自托管的真实 Web 应用集群，并配套基于 Playwright 的交互；VisualWebArena（Koh et al., 2024），在 WebArena 基础上扩展了多模态视觉 grounding 任务；以及 BrowserGym（Chezelles et al., 2024），它与 WorkArena（Drouin et al., 2024）一起，为基于浏览器的智能体执行和基准测试提供标准化的 gym 风格接口。

这些系统提供隔离的 Web 执行环境，承担沙箱角色；同时又提供可复现的任务定义和自动化评估，承担执行框架角色。这种双重功能使其不同于第 3.2.2 节中的计算机使用类别，后者是在桌面层而不是浏览器层运行；它也在本节讨论的执行环境与第 8 节讨论的评估基础设施之间建立了直接接口。浏览器环境还暴露出一种独特威胁面：由于浏览器会摄入不可信的网页内容，它自然成为研究针对智能体的间接提示注入和多模态红队攻击的基础载体（Debenedetti et al., 2024; Greshake et al., 2023; Zhang et al., 2026a; Wei et al., 2026）。

3.2.6 操作系统级权限沙箱

操作系统级权限沙箱使用操作系统原语实现细粒度文件系统和网络隔离，例如 Linux 上的 bubblewrap、macOS 上的 Seatbelt，或用于系统调用过滤的 seccomp-bpf，而不是使用容器、虚拟机或用户空间内核。它们比容器沙箱轻得多，同时提供目录和域名访问控制。代表性系统包括 Anthropic 的 sandbox-runtime（Anthropic, 2025g），一个开源 npm 包，它通过 bubblewrap 和本地 HTTP/SOCKS5 代理，以文件系统和网络允许列表来包装任意命令；Claude Code 自身内置的沙箱化功能（Anthropic, 2025b），它使用该运行时将 bash 工具的文件系统和网络访问限制在配置边界之内；以及 IsolateGPT（Wu et al., 2025），一个研究系统，使用 seccomp 和 setrlimit 在工具调用型 LLM 应用之间执行隔离。

这一类别的设计哲学是“权限”，而不是“分区”：其目标不是为每个会话提供全新的操作系统镜像，而是为智能体提供一个缩小后的主机视图，使被提示注入诱导或幻觉产生的命令无法修改敏感文件或外泄数据。Anthropic 报告称，这类边界在 Claude Code 中将权限提示减少了 84%，同时保留了安全性（Anthropic, 2025b）；这说明了操作系统级沙箱化的生产力动机：在长周期智能体执行中，权限提示本身就是一种活性失败。由于共享主机内核，操作系统级权限沙箱在面对对抗性代码时，比基于 microVM 的托管沙箱（第 3.2.1 节）隔离强度更弱；当威胁模型是提示注入，而不是完全对抗性代码时，它们是适用的。

3.2.7 沙箱抽象层

沙箱抽象层本身不是沙箱，而是在单一 API 背后统一多个沙箱后端的接口，使执行框架能够在不重写智能体代码的情况下切换执行基底。代表性系统包括 SWE-ReX（SWE-agent Team, 2024），这是由 SWE-agent 团队（Yang et al., 2024）开发的运行时接口，将 Docker、AWS Fargate、Modal 和 Daytona 统一为可互换后端；smolagents（Roucher et al., 2025）的执行器接口，它将 local、e2b、modal、docker、blaxel 和 wasm 暴露为单一参数化的 executor_type；以及 Kubernetes SIG Apps 下的 Agent Sandbox（Kubernetes SIG Apps, 2025）项目，它引入了 Sandbox CRD 和控制器，通过声明式 API 将 gVisor 和 Kata Containers 作为可插拔隔离后端暴露出来。

这一类别的出现反映了一种日益成熟的理解：执行基础设施应当是可替换的。一个将某个特定沙箱 API 硬编码进去的执行框架，会将其编排逻辑耦合到某个供应商的临时性产品之上；而抽象层则将“智能体运行什么”与“智能体在哪里运行”解耦。我们观察到研究项目（SWE-ReX）、框架内嵌接口（smolagents executors）和新兴基础设施标准（Kubernetes agent-sandbox CRD）之间正在发生收敛，这表明沙箱抽象正在成为智能体执行框架栈中的一个独立层，而不只是个别系统的功能。

综合。 在七个类别中，可以看到三个跨领域趋势。第一，该领域正在沿着隔离强度分化，而不是走向收敛：托管沙箱（第 3.2.1 节）正在从共享内核容器迁移到专用内核 microVM，而操作系统级权限沙箱（第 3.2.6 节）则完全放弃独立环境，转而缩小主机视图。普通 Docker 容器这一中间地带正受到两端挤压，而两种极端之间的选择取决于威胁模型，即面对的是完全对抗性代码，还是被提示注入但在其他方面仍然合作的代码，而不是某种普遍适用的技术偏好。第二，评估鲁棒性正在成为一等关注点：容器逃逸基准 SandboxEscapeBench（Marchand et al., 2026）以及面向代码解释器智能体的安全基准 CIBER（Ba et al., 2026）显示，目前部署在生产环境中的沙箱配置，可以被前沿模型部分绕过。第三，该领域正在区分基础设施级隔离和工具调用层的语义或能力级隔离。CaMeL 的控制流完整性设计（Debenedetti et al., 2025）和 Progent 的可编程权限控制（Shi et al., 2025a）是后者的代表，属于工具使用章节（第 4 节），而不是严格意义上的沙箱基础设施。这两条线是互补的：基础设施沙箱限制动作一旦执行后的影响半径，而语义隔离限制哪些动作首先被允许执行。一个完整的智能体执行框架同时需要二者。

3.3 威胁模型与沙箱逃逸

沙箱化智能体执行同时面对传统容器级威胁，例如容器逃逸、侧信道和资源耗尽，以及会放大经典问题的智能体特定威胁类别。第一，提示注入攻击允许外部输入，例如检索到的网页、工具响应或文件内容，劫持智能体行为并发起恶意沙箱操作。第二，目标错位可能导致智能体本身主动将沙箱逃逸作为工具性子目标。第三，组合式放大发生在拥有多个工具访问权限的智能体中，一个沙箱弱点可能沿着集成能力级联扩散。

关于智能体环境中的沙箱逃逸，经验证据有限但令人担忧。SandboxEscapeBench（Marchand et al., 2026）在嵌套沙箱夺旗设置中评估前沿 LLM，并报告称，面对基于 Docker 的容器，根据容器配置不同，逃逸成功率为 15% 到 35%。该基准覆盖了一系列逃逸机制，包括错误配置、权限分配错误、内核缺陷，以及运行时或编排弱点；其结果表明，即便在当前模型能力下，该威胁也已经实现，而不只是理论上的。防御研究仍处于早期阶段。IsolateGPT（Wu et al., 2025）提出了一种面向基于 LLM 的智能体系统的执行隔离架构，并报告称，在防止跨应用数据泄漏的同时，对四分之三的测试查询带来的性能开销低于 30%。事务性沙箱化方法（Yan, 2025）提供基于回滚的保护，报告约 14.5% 的开销，并对风险命令具有较高拦截率。LLM-in-Sandbox（Cheng et al., 2026）提供了一个互补视角，它认为，最小化而非最大化能力的沙箱环境，可以同时降低攻击面和不必要的智能体复杂性。

综合来看，这些结果暴露出攻击与防御进展之间的差距。攻击性评估已经产生了一个具体且可复现的基准，而防御工作仍分散在若干孤立原型之间，这些原型在威胁模型、评估协议和基线假设上各不相同。一个智能体原生的运行时安全框架，如果能够在统一评估方法下系统性处理提示注入、目标错位和组合式放大，将是一个开放研究方向，我们将在第 12.1 节中再次讨论。

3.4 部署模式

智能体沙箱基础设施已经发展出不同于最初自托管 Docker 模式的多种部署模式。当前实践中共存着三种模式。在自托管模式中，开发者直接管理沙箱基础设施，这是 OpenHands 和 SWE-agent 的默认模式。在云端（SaaS）模式中，沙箱即服务提供商负责处理基础设施，典型例子包括 E2B、Modal 和 Daytona Cloud。在混合或自带云（BYOC）模式中，智能体逻辑和沙箱执行被解耦到不同环境中；例子包括 OpenHands SDK 的 Local 与 Remote Workspace 抽象（Wang et al., 2025c），以及 E2B 和 Northflank 的 BYOC 产品。

这些模式之间的演进受两种互补力量推动。一方面，实践者报告将部署选择放在延迟、安全性和可扩展性三条轴线上理解（Anthropic, 2025b; f）。自托管沙箱提供最低延迟和最紧密的迭代循环，但承担全部运维负担；云端沙箱则反转这一权衡，提供弹性扩展和托管安全，但代价是网络往返；混合模式则试图在保持敏感数据本地化的同时，将执行容量委托出去。另一方面，数据驻留、合规和可审计性等组织约束，会推动部署走向混合架构，即便从延迟和可扩展性角度看，单一模式方案可能更有利。

在已观察到的实践中，自托管沙箱在交互式开发和单租户场景中占主导，而云端沙箱在多租户和大规模部署中更常见。混合模式正在专门针对这样一些场景出现：合规或数据本地性要求与对大规模临时执行容量的需求同时存在。当前仍缺少在真实智能体工作负载下对这些模式进行系统性经验比较的研究；我们将其视为第 12.1 节中更广泛运行时议程的一部分。

3.5 小结

执行环境是智能体执行框架的物理基底：它们提供安全边界，为可复现评估和训练提供重置机制，并为长周期智能体提供一个有边界的行动区域，使其无需对每条命令进行人工批准。本节综述的七个类别表明，设计空间如今并不是由某一种隔离原语主导，而是由工作负载保真度、威胁模型和运维模式共同塑造。托管沙箱和计算机使用环境强调强隔离与真实执行；代码专用环境和浏览器环境强调吞吐量和评估结构；框架集成式运行时为了便利而打包能力；操作系统级权限沙箱缩小本地权限；抽象层则使底层基底变得可替换。

这一设计空间产生了能力、控制与成本之间反复出现的张力。高风险工作负载会推动系统走向 microVM 和托管云；交互式本地工作流会推动系统走向轻量级权限边界；大规模训练或评估则会推动系统走向快速、可重置的基底。因此，关于运行时防御、经济性、可移植性、打包与组合设计，以及跨层耦合的未解决问题，并不是执行层中的孤立脚注；它们将在第 12.1 节中作为贯穿全文的开放问题再次出现。

4 工具接口与协议层（T）

工具接口与协议层（T）是 ETCLOVG 的第二大支柱（见第 1 节中的主张 2）。我们讨论的协议、描述和注册表，来自支撑主张 3 的 148 多个项目语料库。

图 7：面向 LLM 智能体的工具接口与协议代表性工作

工具接口与协议

协议与接口标准

MCP（Model Context Protocol, 2025b; c）、A2A（A2A Project, 2025）、Function Calling（OpenAI, 2026c）、OpenAPI（OpenAPI Initiative, 2025）、AGENTS.md（agentsmd, 2025）、互操作性综述（Ehtesham et al., 2025）

工具描述、发现与选择

EasyTool（Yuan et al., 2025）、MCP-Zero（Fei et al., 2025）、AnyTool（Du et al., 2024）、CRAFT（Yuan et al., 2023）、MetaTool（Huang et al., 2023）、ToolRegistry（Ding, 2025）、ToolRet（Shi et al., 2025b）

工具增强训练与集成

Toolformer（Schick et al., 2023）、Gorilla（Patil et al., 2024b）、ToolLLM/ToolBench（Qin et al., 2024）、ToolkenGPT（Hao et al., 2023）、CREATOR（Qian et al., 2023b）、Agentic Code Reasoning（Ugare & Chandra, 2026）、LangChain（LangChain, 2026c）、Semantic Kernel（Microsoft, 2026）、smolagents（Hugging Face, 2026）

可扩展性与会话管理

ReAct（Yao et al., 2023）、LLMCompiler（Kim et al., 2024）、E2B（E2B, 2024）、MCP Code Execution（Anthropic, 2025f）、BFCL（Patil et al., 2025）、StableToolBench（Guo et al., 2024）、API-Bank（Li et al., 2023b）、TaskBench（Shen et al., 2024） 图 7： 面向 LLM 智能体的工具接口与协议代表性工作，按照本章的工具层类别组织。

工具接口与协议层定义了智能体如何发现能力、如何表示可调用的行动可能性，以及如何跨异构运行时边界执行动作。在实践中，这一层位于两个相互竞争目标之间的断裂带上：一方面，通过暴露更多工具来增加能力覆盖；另一方面，通过保持动作空间和提示词占用较小来维持决策质量。来自生产级智能体系统的近期工程指南反复指出，过大的工具菜单会降低可靠性、增加 token 开销，并放大规划错误（Anthropic, 2025d; OpenAI, 2026c）。

我们将这一层组织为四个互补方向：协议与接口标准；工具描述、发现与选择；工具增强模型训练与集成；以及可扩展性与会话管理。

4.1 协议与接口标准

MCP 已经成为面向代码智能体和企业智能体最可见的工具集成基底，它具有明确的 host-client-server 架构，并基于 JSON-RPC 对工具、资源和提示词进行类型化交换（Model Context Protocol, 2025b; c; a）。MCP 的实践价值不仅在于 schema 层面的互操作性，也在于生态流动性：智能体构建者可以复用不断扩展的服务器目录，而不必为每一次部署实现自定义连接器。

A2A 面向的是一个不同但相邻的边界。它不是将工具暴露给单个智能体进程，而是标准化不透明智能体应用之间的通信，包括通过 Agent Cards 进行发现，支持同步与流式交互，以及支持长时间运行的任务协作（A2A Project, 2025）。近期协议综述将 MCP 和 A2A 置于互补角色中：MCP 主要用于工具/上下文访问，A2A 用于智能体间委派与协作（Ehtesham et al., 2025）。在我们看来，一个更有用的组织原则，是按照工具/接口标准跨越的集成边界对它们进行分类，而不是按照厂商谱系或发布时间线来分类。从这一视角看，会出现四类边界：模型 ↔ 函数（结构化调用）、智能体 ↔ 外部能力（运行时到工具的解耦）、智能体 ↔ 智能体（跨进程委派），以及智能体 ↔ 仓库/环境（版本控制下的策略）。表 1 总结了这一视角，并明确说明了为什么若干经常被比较的标准，例如 MCP 与 A2A，或 Function calling 与 OpenAPI，在单一执行框架中实际上扮演的是不重叠的角色。

函数调用 schema 和 API 描述标准仍然是这一层的基础构件。OpenAI 风格的函数调用通过 JSON schema 和显式的调用/返回轮次来操作化工具调用（OpenAI, 2026c）；OpenAPI 提供一种语言无关、机器可读的 API 契约，许多智能体框架会将其作为工具生成和验证的来源（OpenAPI Initiative, 2025）。此外，AGENTS.md 和 AGENT.md 等仓库级指令文件，提供了一种轻量替代方案，可以将工具使用和工作流约束直接编码到版本控制中，从而降低代码智能体的设置摩擦（agentsmd, 2025; agentmd, 2025）。

表 1： 按照工具/接口标准所跨越的集成边界（行）以及四个与执行框架相关的能力轴（列）来组织的工具/接口标准。● = 一等支持；◐ = 部分支持或约定层面支持；○ = 不在范围内。参考文献见正文周边内容。

边界	标准	传输/线协议	类型化	运行时发现	长时间运行
模型 ↔ 函数	Function calling	JSON	●	○	○
智能体 ↔ 能力	MCP	JSON-RPC	●	●	◐
智能体 ↔ 能力	OpenAPI	HTTP	●	◐	○
智能体 ↔ 智能体	A2A	JSON-RPC	●	●	●
智能体 ↔ 智能体	ACP / ANP	HTTP	●	●	●
智能体 ↔ 仓库/环境	AGENTS.md / AGENT.md	Markdown	○	◐	○

4.2 工具描述、发现与选择

一旦协议定义了调用如何发生，下一个瓶颈就是每一步应该暴露并选择哪些工具。越来越多的工作开始研究工具文档质量、检索以及动态候选集裁剪。EASYTOOL 分析了从大型工具清单中选择合适工具的挑战（Yuan et al., 2025）。AnyTool 和 CRAFT 关注通过自动构造或优化工具使用流水线来降低人工规格说明负担（Du et al., 2024; Yuan et al., 2023）。MetaTool 这类基准式评估表明，工具检索质量和调用质量会在不同领域和查询形式之间显著分化（Huang et al., 2023）。更近期的 MCP-Zero、ToolRet 和 ToolRegistry 等工作强调，具备检索意识的编排和注册表质量，是决定下游智能体成功的一阶因素（Fei et al., 2025; Shi et al., 2025b; Ding, 2025）。一个密切相关的方向，将工具选择扩展到可复用技能：在这种场景下，智能体必须识别相关的程序性模块，而不只是紧凑的 API schema。SkillRouter（Zheng et al., 2026）和 SkillRet（Cho et al., 2026）都在大规模场景下研究了这一技能选择问题，并凸显了从大型且彼此重叠的技能库中检索正确技能的必要性。

在系统层面，这些结果强化了两个设计原则。第一，“更少但更好的工具”通常优于暴力式工具暴露，因为它同时降低了提示词熵和规划器分支。第二，发现流水线必须是自适应的：静态的全局工具列表无法扩展到快速演化的代码仓库或多租户企业部署中。

4.3 工具增强训练与集成

第三个方向从运行时编排转向模型能力获取。Toolformer 展示了通过自监督增强来学习在生成过程中何时以及如何插入 API 调用（Schick et al., 2023）。Gorilla 和 ToolLLM/ToolBench 将这一方向扩展到更大的工具语料、指令微调流水线，以及以执行为中心的 API 使用监督（Patil et al., 2024b; Qin et al., 2024）。ToolkenGPT 和 CREATOR 则探索 token 级或控制器式集成，以提高调用格式的保真度和规划稳定性（Hao et al., 2023; Qian et al., 2023b）。

在生产级执行框架中，这些模型侧进展通常会与框架级运行时栈搭配使用，例如 LangChain、Semantic Kernel 和 smolagents；这些栈提供记忆抽象、路由中间件和工具适配器（LangChain, 2026c; Microsoft, 2026; Hugging Face, 2026）。代码智能体场景还暴露出第二类更语义化的工具：静态分析器、类型检查器、基于求解器的验证器、证明助手，以及补丁等价性或故障定位检查器。Ugare 与 Chandra（2026）将这一空间称为智能体式代码推理：智能体探索一个代码仓库，并在不一定执行代码的情况下推理代码行为。他们的半形式化推理方法介于非结构化思维链和完全形式化验证之间，它要求智能体陈述前提、追踪程序路径并推导出显式结论，从而改进补丁等价性验证、故障定位和代码问答。对于工具层来说，其含义是：自动化推理工具应该返回承载证据的工件，例如轨迹、证明义务、反例或结构化证书，而不应只返回黑盒式的是/否答案。综合证据表明，工具能力是由预训练与微调信号、接口 schema 质量以及运行时选择策略共同决定的；只改进其中一个组件，收益有限。

4.4 可扩展性与会话管理

一个反复出现的运维挑战，是长周期场景下的会话管理。有状态工具会话能够改善连续性，但会增加记账复杂度，尤其是在调用被并行化，或被委派给多个智能体时。失败模式包括陈旧句柄、重试期间工具状态不一致，以及冗长工具轨迹造成的上下文窗口饱和。因此，有效的执行框架设计需要针对工具会话的显式生命周期控制、有边界的工具上下文注入，以及能够将错误归因于规划器逻辑或接口/协议故障的可观测性钩子。

最后，生态系统层面的版图梳理可以帮助实践者快速映射可用的协议和工具选项，但在决定某个部署中应该采用哪种协议和工具路由策略时，基于基准的比较仍然至关重要。

5 上下文与记忆管理（C）

上下文与记忆管理（C）是提示词工程、上下文工程与执行框架工程相交的层。我们将其视为 ETCLOVG 的第三大支柱（见第 1 节中的主张 2），示例来自支撑主张 3 的 148 多个项目语料库。

图 8：面向 LLM 智能体的上下文与记忆管理代表性工作

上下文与记忆管理

短期活跃上下文窗口

Effective Context Engineering（Anthropic Applied AI Team, 2025）、Manus Context Engineering（Manus Team, 2025）、Context Management（Anthropic, 2025c）、Agent Skills（Koylan, 2025）、Context-Space（context-space, 2025）

中期会话状态与跨运行持久化

Structured Note-Taking（Anthropic Applied AI Team, 2025）、Planning-with-Files（OthmanAdi, 2025）、Trellis（mindfold-ai, 2025）、Claude-Mem（thedotmack, 2025）、Everything-Claude-Code（affaan-m, 2025）

长期持久化记忆系统

MemGPT（Packer et al., 2023）、Generative Agents（Park et al., 2023）、MemoryBank（Zhong et al., 2024）、Mem0（Chhikara et al., 2025）、A-MEM（Xu et al., 2025）、Hindsight（Vectorize.io, 2025）、Honcho（Plastic Labs, 2025）、CQ（Mozilla AI, 2025）

长周期上下文技术

Context Compaction（Anthropic Applied AI Team, 2025）、Sub-Agent Context Isolation（Anthropic, 2025e）、Manus Context Sharing（Manus Team, 2025）、Harness Design（Anthropic, 2026c）、Effective Harnesses（Anthropic, 2025d）

上下文漂移与局限

Lost in the Middle（Liu et al., 2024）、Context Rot（Hong et al., 2025）、Harness Boundary（Bowne-Anderson & Huber, 2026）、MemBench（Tan et al., 2025）、MemoryArena（He et al., 2026）、Incremental Memory Evaluation（Hu et al., 2025b） 图 8： 面向 LLM 智能体的上下文与记忆管理代表性工作，按照本章的上下文层类别组织。

这一层治理模型在执行的每一步看到什么信息，以及知识如何跨轮次和会话持久化。其核心工程问题很容易表述：在每一步给模型恰好正确的信息，不多也不少。上下文太少，智能体缺少正确行动所需的状态；上下文太多，性能会以可测量、跨模型一致且尚未被完全理解的方式退化。

我们按照时间跨度组织本节。第 5.1 节说明为什么上下文需要主动管理，而不是被动累积。第 5.2 节将上下文工程定义为一个不同于提示词工程的学科。第 5.3 节到第 5.5 节覆盖生产实践中已经出现的三层记忆：活跃上下文窗口（短期）、会话级持久化（中期）和跨会话存储（长期）。第 5.6 节讨论智能体运行数百轮时出现的协调问题。第 5.7 节以尚未解决的问题收尾。

5.1 为什么必须工程化上下文

更大的上下文窗口并不能解决记忆问题。要理解原因，需要先看架构。

二次注意力成本。 Transformer 的自注意力机制会计算上下文中每个 token 之间的成对关系（Vaswani et al., 2017）。对于 n 个 token，这会产生 n² 个成对权重；计算和内存都会随上下文长度呈二次增长。FlashAttention 和位置编码插值等工程技术可以降低常数因子，但二次结构本身是架构性的。上下文翻倍并不会让成本翻倍，而是让成本变为四倍。这使上下文窗口成为一种稀缺资源。

U 型注意力曲线。 仅有架构成本还不足以解释为什么即便在计算资源足够时，模型仍会在长上下文上失败。Liu 等人（2024）给出了关键经验证据：在包含 20 个输入文档的多文档问答任务中，如果相关文档位于上下文中部，相比将其放在开头或结尾，准确率会下降超过 30%。这种 U 型性能曲线在不同模型、任务和上下文长度中都成立，包括专门针对长上下文训练的模型。其实践含义很直接：信息的位置与信息是否存在同样重要。一个智能体即使检索到了正确内容，但如果放置位置很差，也几乎无法从检索中获益。

规模化上下文腐化。 Hong 等人（2025）在受控条件下评估了 18 个前沿模型，包括 GPT-4.1、Claude Opus 4、Gemini 2.5 和 Qwen3，其设计目的是将输入长度与任务难度隔离开来。随着输入增长，每个模型都会退化。退化不是均匀的，而是具有任务特异性。语义上存在歧义的查询，也就是相关段落与问题并不在词面上匹配的查询，比精确匹配查询表现出更陡峭的退化；这指向一种复合失败：模型无法定位相关信息，即使定位到了也无法对其进行推理。退化还会在窗口填满之前很早就开始出现。一个标称支持 200K token 的模型，可能在 50K 时就已经表现出显著性能损失。Hong 等人（2025）将这一现象称为上下文腐化，而它并不是边缘案例。对于任何会在多个步骤中累积工具结果、中间推理和文件内容的智能体来说，这是正常运行条件。

综合来看，这些结果表明，上下文管理不能是事后才考虑的问题。关于包含什么、放在什么位置、何时移除的每一个决策，都会对智能体可靠性产生直接影响。

5.2 从提示词工程到上下文工程

从提示词工程到上下文工程的转变，反映的是范围的转变（Karpathy, 2025）。提示词工程优化的是传给单次模型调用的、基本静态的文本输入。在视觉领域，相同框架也扩展到了连续可学习 token：视觉提示调优会在冻结视觉 Transformer 的 patch 序列前添加一小组可训练向量，使其适配下游任务，同时更新不到 1% 的模型参数（Jia et al., 2022; Xiao et al., 2025）。文本和视觉两种变体共享提示词工程的核心特征：针对一种输入模态，进行固定的、单次调用级优化。上下文工程则优化多步骤任务中每个推理步骤可供模型使用的完整信息状态。

Anthropic 的 Applied AI 团队将其定义为：“在 LLM 推理期间整理和维护最优 token 集合的一组策略，包括所有可能进入上下文、但位于提示词之外的其他信息”（Anthropic Applied AI Team, 2025）。由此产生的指导原则是：在每一步找到最小的高信号 token 集合，使期望结果的概率最大化。该原则驱动了本节中的每一种技术。渐进式披露是在需要时即时加载信息，而不是预先加载所有信息。压缩会移除已经完成使命的 token。记忆检索只拉取与当前任务最相关的记录。

上下文包含什么。 在已部署的智能体中，推理时上下文包括系统提示词和行为指令、工具定义和 schema、先前轮次历史、当前轨迹中的工具调用结果、检索到的文档或记忆记录，以及任何动态注入的工作状态。所有这些都会争夺同一个有限注意力预算。上下文工程意味着在每一步对每个组成部分做出显式选择，而不是任由它们不受控制地累积。

这一实践的成熟也体现在生态系统中。第一性原理手册（Kimai, 2025）和精选综述（Meirtz, 2025）如今已经将上下文工程视为一门独立学科。三层记忆架构已经成为主导性组织框架，覆盖活跃上下文窗口、会话级状态和跨会话存储。它直接映射到操作系统的经典记忆层次结构，后者既提供有用直觉，也提供了将正确技术匹配到正确时间跨度上的术语体系。

5.3 短期：管理活跃上下文窗口

短期上下文管理治理模型在一次推理步骤或一个会话内短序列步骤中看到什么。这些决策对模型行为有最直接的影响，一旦做得不好，也会带来最高成本。

系统提示词校准。 系统提示词建立智能体的行为边界，并在每次调用中消耗固定预算。Anthropic Applied AI Team（2025）将这一设计挑战描述为寻找合适的“高度”：过于具体的提示词会引入脆弱且维护负担很重的逻辑；过于模糊的提示词则无法给模型提供具体指导。在实践中，有效的系统提示词会被组织为边界清晰的几个部分，例如背景、指令、工具指导和输出格式，并使用 XML 标签或 Markdown 标题将它们分开。推荐工作流是从最好的可用模型上的最小提示词开始，经验性识别失败模式，然后添加有针对性的指令来处理特定缺口。预先枚举每个边缘情况，往往只会让提示词膨胀，而不会提升可靠性。

token 高效的工具设计。 工具定义是主要的上下文消费者。每个 schema、名称、描述和参数类型都会在每次调用中被注入。一个大型工具集可能在智能体读取用户请求之前，就消耗数万个 token。从生产部署中出现的原则是：相比大量狭窄工具，应优先选择更少但表达能力更强的工具。如果一个人类工程师无法说清某种情况下该用哪个工具，就不能期待模型做得更好。工具应当自包含、对错误鲁棒，并且在预期用途上无歧义；其参数名称也应具有描述性，以发挥模型的优势。

即时检索与渐进式披露。 有效智能体不是预先加载所有潜在相关信息，而是维护轻量标识符，例如文件路径、已保存查询和网页链接，并在任务展开时按需加载数据。Anthropic Applied AI Team（2025）将这种方法称为渐进式披露。它类似人类专家的工作方式：我们并不会记住语料库，而是构建外部索引系统并按需检索。在实践中，Claude Code 使用混合策略。CLAUDE.md 文件会在会话开始时加载，以提供项目上下文；而 glob 和 grep 命令则让智能体能够即时导航并加载特定文件内容。这同时绕开了陈旧索引问题和大规模预填充成本。环境元数据也携带隐式信号。文件大小暗示复杂度；命名约定暗示用途；时间戳则可以代理相关性。智能体可以逐层构建理解，只将当前必要内容保留在活跃窗口中。

KV-cache 感知的上下文设计。 提示缓存是生产级智能体部署中最具成本效益的优化，而其收益完全取决于上下文如何被结构化。在其生产智能体经历五次架构迭代后，Manus 团队将 KV-cache 命中率识别为“生产阶段 AI 智能体唯一最重要的指标”，并指出 Claude Sonnet 上缓存 token 的成本是 0.30 美元/MTok，而未缓存 token 是 3.00 美元/MTok（Manus Team, 2025）。缓存模型带来三条设计规则。第一，保持提示词前缀稳定：系统提示词开头的单个 token 差异，都会让后续所有缓存失效。第二，将上下文视为只能追加：修改过去的动作或观察，会通过创建不同的前缀序列破坏缓存复用。第三，使用确定性序列化：JSON 序列化中不稳定的 key 顺序，会在原本相同的请求之间悄悄使缓存失效。由于工具定义通常位于序列化上下文靠前的位置，添加或移除工具会让所有后续轮次的缓存内容失效。Manus 的处理方式是使用一个上下文感知状态机，在解码期间屏蔽 token logits，以阻止选择不可用动作，而不是在运行时修改工具定义列表（Manus Team, 2025）。Anthropic 的上下文管理发布则通过显式的 cache_control 断点，在产品层面操作化缓存（Anthropic, 2025c）。

短期管理的工具生态已经发展到包括生产级技能库，这些技能库覆盖智能体调用之间的 KV-cache 压缩模式（Koylan, 2025），以及为动态上下文组装提供 MCP 中心化原语的基础设施项目（context-space, 2025）。

5.4 中期：会话状态与跨运行持久化

中期上下文管理处理的是活跃上下文窗口与完整长期记忆系统之间的缺口。其具体问题是：智能体如何在一个会话内跨轮次，或在同一任务的多次运行之间保存和恢复状态。其工程价值很高：只需几百个 token 的结构化工作状态，就可以跨越上下文重置，否则智能体会失去所有累积进展。

结构化记笔记。 最简单的中期技术，是让智能体维护一个持久笔记文件，通常是 NOTES.md 或 todo.md，在每次运行开始时读取它，并在上下文被清除之前更新它。Anthropic Applied AI Team（2025）通过 Claude 玩 Pokémon、跨越数千个游戏步骤的案例说明了这一点。在没有任何关于记忆结构的显式指令的情况下，该智能体发展出了已探索区域的地图，维护了针对特定对手的战斗策略及其结果统计，并跨上下文重置追踪目标。每次压缩步骤清除主对话历史后，智能体都会读取自己的笔记，并在不丧失连贯性的情况下继续数小时训练序列。关键洞察是，记笔记将工作记忆外部化。智能体不是依赖对话历史来承载任务状态，而是将重要内容写入外部存储，并按需读回。

基于文件的规划与任务外部化。 结构化记笔记的一个扩展，是将完整规划表示外部化到磁盘。planning-with-files（OthmanAdi, 2025）等工具提供技能包，用于代码智能体工作流中的持久文件式规划。任务状态、规格说明、中间结果和依赖图会在每个里程碑写入文件系统，并在下一次运行开始时选择性加载，从而让当前并不立即相关的内容完全绕过上下文窗口。Trellis（mindfold-ai, 2025）等框架将这一模式扩展到项目记忆和规格注入，管理结构化项目状态，并根据当前步骤需要选择性注入。

跨运行注入。 一个互补模式会捕获前一次运行中的显著输出，并在下一次运行开始时注入它。claude-mem（thedotmack, 2025）等工具作为插件式记忆层运行：它们捕获会话历史，提取未来运行中最有用的信息，并将其前置到下一次会话的上下文中。这不需要向量数据库，也不需要图存储，却能提供相当强的跨运行连续性。社区仓库 everything-claude-code（affaan-m, 2025）拥有超过 150K GitHub stars，代表了这些模式最大的开放集合，并展示了中层记忆实践在生产级代码智能体部署中被采用的规模。

中层权衡。 相比仅靠窗口内管理，中期技术提供了显著更强的连续性，同时基础设施成本只是完整长期记忆系统的一小部分。其局限在于，信息是从一次运行向下一次运行前向流动的，但并不是从索引存储中检索出来的，而且这些技术无法很好扩展到大量历史。当跨运行历史变得很大，或当智能体需要检索某个具体先前观察而不是注入摘要时，中期技术就必须由下一节描述的长期系统补充。

5.5 长期：持久化记忆系统

长期记忆系统提供跨会话、跨任务、跨智能体实例持久存在的、可索引且可检索的存储。中期技术依赖摘要的前向注入，而长期系统支持任意回忆：给定一个查询，系统会检索最相关的已存储记忆，不论这些记忆创建于何时。这一层是智能体经验随时间累积的地方。

5.5.1 基础架构

受操作系统启发的分层记忆。 Packer 等人（2023）提出了关键抽象：将 LLM 的上下文窗口视为 RAM，将外部存储视为磁盘，并赋予模型函数调用能力，使其能够显式地将信息换入和换出。与虚拟内存的类比是精确的：正如操作系统通过透明分页为应用程序提供更大内存的幻觉一样，MemGPT 通过透明记忆管理为 LLM 提供更长上下文的幻觉。智能体能够在远超物理窗口限制的上下文上运行，并按需从外部存储检索相关历史。该论文明确建立了智能体记忆与操作系统记忆之间的联系，而这一联系支撑了后来大多数长期记忆系统。

观察、反思与检索。 Park 等人（2023）在社会模拟智能体语境中引入了 Memory Stream 架构。Memory Stream 将智能体的所有观察存储为带有时间戳和重要性分数的自然语言记录。在每一步，检索模型会结合三个信号来浮现最相关记忆：新近性、重要性（由智能体在写入时评分）以及与当前查询的相关性。第二个机制是反思，它会周期性地将已存储观察综合为更高层洞察。智能体会询问自己近期经验中最突出的哪些问题，检索相关记录，并生成结论再存回 Memory Stream。消融实验表明，观察、反思和检索这三个组件各自都独立贡献行为质量；移除任意一个都会产生可测量的退化。观察—反思—检索三元组仍然是智能体记忆设计的标准模板。

动态遗忘与人格建模。 Zhong 等人（2024）在检索架构之上构建了 MemoryBank，并增加了两点。第一是受艾宾浩斯遗忘曲线启发的动态遗忘机制：记忆会随时间按照指数模型衰减，频繁访问会强化记忆，而相互矛盾的记忆会被解决。第二是分层用户人格摘要，它会随着新交互的累积每天更新。这些思想，即自适应记忆强度和用户建模，后来在 Mem0 和 Honcho 中被大规模操作化。

5.5.2 生产级记忆系统

混合存储与行业采用。 Mem0（Chhikara et al., 2025）是目前生产智能体中部署最广泛的长期记忆层，拥有超过 1400 万次 Python 包下载、41K GitHub stars，并原生集成于 CrewAI、Flowise 和 Langflow。其架构结合了三种存储后端：用于语义相似性搜索的向量数据库、用于关系建模的图数据库，以及用于快速事实检索的键值存储。一个基于 LLM 的抽取层会处理新交互，识别事实和偏好，并将记录路由到合适的存储。在 LOCOMO 基准上，Mem0 相比 OpenAI 原生记忆准确率高 26%，同时比完整上下文方法少用 90% token（Chhikara et al., 2025）。Amazon Web Services 在 2025 年选择 Mem0 作为其 Agent SDK 的独家记忆提供方，这反映出它已经从研究原型转向生产基础设施。

动态知识网络。 A-MEM（Xu et al., 2025）借鉴了 Zettelkasten 知识管理系统。它不是将记忆存储为扁平记录，而是为每条新记忆生成结构化笔记，其中包括关键词、标签、上下文描述，以及一组动态链接，指向语义相关记忆。当新记忆被添加时，A-MEM 不仅存储它，也会回溯性更新现有相关笔记的上下文和属性，使记忆图能够随着知识累积而演化。这解决了检索式系统的一个根本局限：一条已存储记忆的相关性在写入时可能并不明显，其重要性只能相对于后来信息进行评估。

从经验中学习。 Hindsight（Vectorize.io, 2025）采取的立场是，大多数记忆系统关注的是“记住”，而真正需要的是“学习”。其 API 暴露三个操作：retain 用于存储新信息，recall 用于检索相关记忆，reflect 用于生成一种结合记忆与当前上下文的、带有倾向感知的响应。在内部，retain 操作会抽取时间实体，去重重叠事实，并构建有证据支撑的合并知识记录。Hindsight 在 LongMemEval 基准上达到最先进性能，并由 Virginia Tech Sanghani Center 的研究人员独立复现。

推理驱动的个性化。 Honcho（Plastic Labs, 2025）由 Plastic Labs 开发，它构建的是用户模型，而不是关于用户的事实存储。一个名为 “dreaming” 的异步推理流水线会在后台持续处理过去交互，不仅抽取显式事实，还会推断关于偏好、沟通风格和演化目标的结论。以实体为中心的数据模型支持多智能体环境，在这种环境中，多个智能体与同一个用户交互：每个智能体维护自己的观察视角，防止交叉污染，而共享用户模型则从所有交互中累积理解。

集体记忆。 Mozilla AI 的 cq（Mozilla AI, 2025）处理的是其他系统留下的空白：智能体实例之间的共享记忆。大多数长期记忆系统是按智能体或按用户划分的；当多个智能体处理相关任务时，每个实例都会独立重新发现其他实例已经学到的内容。cq 是一种面向共享智能体学习的开放标准，在这种标准中，智能体可以在一个群体中持久化、查询并确认集体知识。其架构原生支持 MCP，并在三个层级运行：存储在开发者机器上的本地知识、团队可访问的组织共享知识，以及跨团队知识。错误后钩子模式是一种具体机制：当智能体遇到错误时，cq 会自动查询集体知识库，从而防止一个组织部署中的多个智能体重复独立解决同样的失败。

5.5.3 学术综述与分类体系

Zhang 等人（2025）关于记忆机制的综述为这一层提供了标准学术分类。它区分了短期工作记忆和长期记忆，并将后者细分为语义、程序性和情景性类别。它所形式化的写入—读取—管理循环，已经成为描述记忆系统行为的标准术语。更新的一项综述（Du, 2026）在此基础上，将该循环形式化到一种 POMDP 风格的智能体循环中，并提出一个三维分类体系，覆盖记忆范围、存储格式和组合结构。它刻画了三种工程模式：模式 A（整体式上下文）、模式 B（上下文窗口加检索存储）、模式 C（具有学习控制策略的分层记忆）。这些模式大致对应本节描述的短期、中期和长期三层。Gao 等人（2023）的 RAG 综述则提供了检索增强生成的背景，这构成了上述生产记忆系统中检索层的基础。

5.6 长周期技术：让智能体在 100 多轮交互中保持连贯

前面每个小节都处理单一时间跨度。长周期任务，包括大型代码库迁移、多会话研究项目和扩展自主工作流，需要同时协调三层记忆，并实时决定在每个时间点应用哪种技术。本节覆盖这种规模下出现的集成级技术。

上下文压缩。 压缩会总结一个接近容量上限的上下文窗口，并使用累积状态的压缩表示重新启动执行。Anthropic Applied AI Team（2025）详细描述了校准挑战。摘要必须保留架构决策、未解决 bug 和实现细节，同时丢弃冗余工具输出，以及已经被后续步骤吸收的中间推理。推荐调优工作流从最大化召回开始，捕获轨迹中每一条潜在相关信息，然后迭代提高精确率，移除多余内容。不能从相反方向开始。过早移除太多内容会导致智能体失去后续需要的上下文，而这种损失无法恢复。工具结果清除是最轻量的压缩形式：一旦智能体已经使用过完整工具输出，就用紧凑的路径引用替换它们。这可以持续应用，如今也已经成为 Anthropic 开发者平台上的产品级功能（Anthropic, 2025c）。

子智能体上下文隔离。 当任务需要对某个子主题进行深入探索时，探索本身会生成大量中间上下文，这些内容在子任务内部有用，但会污染编排器对整体任务的视图。子智能体架构通过将子任务分配给专用智能体来处理这一问题，每个子智能体都有新的上下文窗口，并只向编排器返回 1000 到 2000 token 的发现摘要（Anthropic, 2025e）。详细探索上下文会隔离在子智能体内部；编排器只接收提炼后的结果。Manus Team（2025）描述了该模式的一个细化版本。对于编排器只需要输出的简单子任务，不共享上下文。对于需要共享状态的复杂子任务，则将编排器的完整上下文传给子智能体。智能体之间共享上下文成本很高：它会产生更大的预填充，并消除不同系统提示词之间的 KV-cache 复用。必须针对每种任务类型显式权衡隔离成本与协作收益。

混合决策框架。 生产部署不会统一应用单一技术；它们会根据任务结构，在执行的不同位置选择不同技术。Anthropic（2026c）将这一框架描述为：预加载始终需要的内容；即时检索条件性需要的内容；当窗口接近饱和时压缩历史；当子任务需要探索且这种探索会污染编排器上下文时，生成子智能体。Anthropic（2025d）补充了执行框架层视角：检查点与恢复模式允许智能体在不丢失任务状态的情况下从瞬时故障中幸存，而生命周期钩子可以在可配置阈值处自动触发压缩或记忆整合。这是正确的职责划分。上下文管理应当是基础设施的工作，而不是智能体的工作。当执行框架自动处理压缩和整合时，模型就可以专注于任务推理。

5.7 上下文漂移与当前方法的局限

约束瓶颈视角将上下文漂移定义为控制器侧失败模式：因为模型只能看到执行框架暴露出的状态投影，任务相关上下文的丢失或扭曲是一种执行框架属性，而不只是模型属性（Bölük, 2026b）。上文描述的所有技术，在不同程度和不同条件下都有效。但它们都没有解决底层问题。上下文漂移，即智能体行为在扩展交互中的渐进式退化，仍然是这一层最困难的开放挑战。

问题的性质。 上下文漂移不同于上下文腐化，尽管二者都源自相同的架构约束。上下文腐化（第 5.1 节）是单次推理步骤的属性：向固定上下文中加入更多 token，会降低检索和推理质量。上下文漂移则是扩展轨迹的属性。随着智能体累积轮次，其行为会以压缩和检索步骤只能减缓、却无法阻止的方式偏离原始意图。在 100 轮或更多轮之后，智能体经常会重复已经完成的工作，在没有意识到的情况下违背早先决策，并失去对驱动目标的追踪（Bowne-Anderson & Huber, 2026）。根本原因并不只是窗口饱和。即使采用激进压缩，每次压缩步骤中保留下来的摘要也会携带细微不准确性，而这些不准确性会随时间复合。智能体累积的假设可能会偏离真实任务环境，而当前架构中没有任何机制检测这种偏离。

评估缺口。 第二个问题是，上下文漂移很难衡量。标准基准评估的是能在几十步内完成的任务；100 轮或更多轮之后出现的失败模式没有被捕获。近期工作已经开始弥合这一缺口。Tan 等人（2025）提出 MemBench，用于评估多会话场景中的记忆质量，包括时间推理、知识更新和跨会话聚合。He 等人（2026）提出 MemoryArena，专门用于相互依赖的多会话任务，而这正是上下文漂移最具破坏性的条件。Hu 等人（2025b）提出一种增量式多轮评估方法，用于将记忆质量与生成质量隔离开来。这些基准是必要的，但还不够。它们表明漂移会发生，但尚未提供防止漂移所需的机制性理解。

为什么当前技术仍然不足。 压缩降低了 token 数量，但无法保证压缩表示准确捕获所有相关状态。每次压缩步骤中丢失的信息都会永久丢失。检索系统可以浮现相关先前记忆，但查询本身必须构造良好。一个正在漂移的智能体，可能并不知道自己需要检索什么才能纠正路线。子智能体隔离可以防止子任务上下文污染编排器，但编排器自身的上下文仍会随时间积累漂移。Bowne-Anderson 与 Huber（2026）认为，这些局限指向一个边界：单靠上下文工程无法解决长周期可靠性。还需要一个完整的执行框架层，其中包含验证循环、战略性间隔处的人类在环检查点，以及能够识别行为偏离的异常检测。这也说明，第 7 节和第 9 节讨论的治理层与可观测性层，是上下文工程的必要补充，而不是彼此分离的关注点。

6 生命周期与编排（L）

图 9：面向 LLM 智能体的生命周期与编排代表性工作

生命周期与编排

单智能体内部循环

ReAct（Yao et al., 2023）、Codex Agent Loop（OpenAI, 2026b）、OpenCode（Anomaly, 2025）、Claude Code（Anthropic, 2025）、Gemini CLI（Google, 2025）、Codex CLI（OpenAI, 2025）、Aider（Aider-AI, 2025）、SWE-Agent（SWE-agent, 2025）

多智能体编排模式

Anthropic Multi-Agent Research System（Anthropic, 2025e）、Harness Design（Anthropic, 2026c）、AutoGen（Microsoft, 2025）、DeerFlow（Bytedance, 2026）、LangGraph（LangChain, 2026a）、Semantic Kernel（Microsoft, 2026）、OpenAI Agents SDK（OpenAI, 2026a）、DeepAgents（LangChain, 2026b）、Hive（Aden, 2026）、Emdash（Action, 2026）

从 Issue 到 Pull Request 的完整生命周期流水线

Task Runners（OpenAI, 2026a; LangChain, 2026b）、Effective Harnesses（Anthropic, 2025d）、Vibe Kanban（Bloop-AI, 2026）、Symphony（OpenAI, 2026b）、GitHub Agentic Workflows（GitHub, 2026） 图 9： 面向 LLM 智能体的生命周期与编排代表性工作，按照本章的编排类别组织。

生命周期与编排（L）关注智能体系统如何在重复的模型调用、工具调用、失败、修订和交接中推进一项任务。这一层结合了两个在早期框架中经常被分开处理的关注点：智能体的执行流，以及该执行流读取和写入的运行状态。在长时间运行的任务中，可靠性不仅取决于模型能否产生一个好的下一步动作，还取决于执行框架能否记住已经发生了什么、决定接下来应该发生什么、从错误中恢复、协调子任务，并在任务完成时停止（OpenAI, 2026b; Anthropic, 2025d; 2026c）。因此，我们将生命周期与编排视为 ETCLOVG 的第四大支柱（见第 1 节中的主张 2），示例来自支撑第 1 节主张 3 的 100 多个项目语料库。

表 2： 代表性编排系统，按照编排层级组织：单智能体（第 6.2 节）、多智能体（第 6.3 节）、完整生命周期流水线（第 6.4 节），并列出主要编排模式和执行模型。GitHub stars 四舍五入到最接近的千位，并记录于 2026 年 5 月 12 日。

系统或框架	GitHub URL	GitHub Stars（千）	章节	主要模式	执行模型
单智能体内部循环
OpenCode（Anomaly, 2025）	anomalyco/opencode	159	6.2	单循环	混合
Claude Code（Anthropic, 2025）	anthropics/claude-code	123	6.2	单循环	混合
Gemini CLI（Google, 2025）	google-gemini/gemini-cli	104	6.2	单循环	混合
Codex CLI（OpenAI, 2025）	openai/codex	82	6.2	单循环	无状态重放
Aider（Aider-AI, 2025）	aider-ai/aider	45	6.2	单循环	混合
SWE-agent（SWE-agent, 2025）	swe-agent/swe-agent	19	6.2	单循环	混合
多智能体编排模式
DeerFlow（Bytedance, 2026）	bytedance/deer-flow	67	6.3	层级式编排	有状态
AutoGen（Microsoft, 2025）	microsoft/autogen	58	6.3	层级式编排	有状态
oh-my-claudecode（Heo, 2026）	yeachan-heo/oh-my-claudecode	34	6.3	团队式编排	有状态
LangGraph（LangChain, 2026a）	langchain-ai/langgraph	32	6.3	图组合	有状态
Semantic Kernel（Microsoft, 2026）	microsoft/semantic-kernel	28	6.3	工作流编排	有状态
OpenAI Agents SDK（OpenAI, 2026a）	openai/openai-agents-python	26	6.3	层级式编排	混合
DeepAgents（LangChain, 2026b）	langchain-ai/deepagents	23	6.3	层级式编排	有状态
Hive（Aden, 2026）	aden-hive/hive	10	6.3	图组合	有状态
Emdash（Action, 2026）	generalaction/emdash	4	6.3	扇出	混合
从 Issue 到 Pull Request 的完整生命周期流水线
Vibe Kanban（Bloop-AI, 2026）	BloopAI/vibe-kanban	26	6.4	完整生命周期流水线	有状态
Symphony（OpenAI, 2026b）	openai/symphony	24	6.4	完整生命周期流水线	有状态
GitHub Agentic Workflows（GitHub, 2026）	github/gh-aw	5	6.4	完整生命周期流水线	混合

这一层横跨三个组织层级。单智能体内部循环是一个重复周期：一个智能体观察当前情况、决定一个动作、调用工具或产出结果，并使用该结果继续推进。多智能体编排会协调多个这样的循环，通常是为不同智能体分配不同角色，或在它们之间路由工作。完整生命周期流水线则将这些智能体循环置于更广泛的软件或任务工作流中，例如从 issue 推进到代码修改、测试、评审和 pull request。在这些层级中，系统在维护状态的方式上也存在差异。无状态重放会根据已记录的交互历史重构运行过程。有状态执行则会将运行状态存储在提示词之外，例如文件、仓库、数据库、任务图或服务中。许多实践系统都是混合型：它们既保留可重放历史，也依赖持久化工件。

6.1 生命周期状态管理

生命周期状态管理关注的是智能体运行在跨轮次、会话、失败和交接时继续推进所需的运行状态。这包括待处理子任务、工具结果、中间工件、仓库变更、协调元数据、会话持久化，以及检查点恢复机制。这些机制让编排变得持久，而不是瞬时的：智能体可以从此前工作继续推进，而不是把每一步都当成一次孤立的模型调用。

一个核心权衡存在于无状态执行和有状态执行之间。无状态设计会从此前的交互历史中重构执行过程，这提升了可复现性和可审计性，但随着轨迹增长会变得昂贵。有状态设计会将执行状态持久化到文件、数据库、仓库、任务图或外部服务中，这提升了连续性和恢复能力，但也引入了一致性和调试方面的挑战（OpenAI, 2026b; Anthropic, 2026c）。因此，许多实践型执行框架会采用混合设计，将可重放的交互历史与持久化工件结合起来。

这里的状态不同于第 5 节中的上下文与记忆层。上下文与记忆层关注的是提供给模型用于推理的信息，例如检索到的文档、记忆或对话历史。它也不同于第 7 节中的可观测性，后者关注日志、追踪和系统行为监控。这里的重点是执行框架自身用于继续和协调执行的运行状态，例如待处理子任务、检查点、重试、共享工件或执行状态。

6.2 单智能体内部循环

单智能体内部循环是智能体系统中的基本执行单元。一个单一智能体会通过工具使用和反馈反复与环境交互，而不需要在多个智能体之间进行显式协调。交互式编码、调试和问题求解都建立在这一抽象之上。

从概念上看，单智能体循环遵循 ReAct 范式（Yao et al., 2023），将推理、动作和观察交织在一起。正如 OpenAI 对 Codex 智能体循环的分析所强调的那样（OpenAI, 2026b），这类系统的行为不仅由模型决定，也由执行框架决定：执行框架负责构造提示词、调用工具、管理控制流，并将工具输出反馈到后续步骤中。

在这一层级，主要的执行区别在于无状态重放和混合执行。Codex CLI（OpenAI, 2025）是基于重放执行的最清晰例子，而实践中的代码智能体通常会将可重放历史与文件、仓库或会话状态等持久化工件结合起来。因此，在表 2 中，OpenCode（Anomaly, 2025）、Claude Code（Anthropic, 2025）、Gemini CLI（Google, 2025）、Codex CLI（OpenAI, 2025）、Aider（Aider-AI, 2025）和 SWE-agent（SWE-agent, 2025）都被归入“单循环”这一主要模式。尽管这些系统具有灵活性，但这类系统中的长周期执行可能遭遇上下文碎片化、错误累积和分解结构薄弱等问题（Anthropic, 2025d），这也推动了更结构化编排方式的发展。

6.3 多智能体编排模式

多智能体编排通过组合多个具有专门角色的智能体，扩展了单智能体循环。它不是让一个智能体独自完成规划、执行、检查和修订，而是让多智能体执行框架在多个智能体或子智能体之间分离这些职责。这种结构支持任务分解、并行探索、批判、验证和聚合，因此相比孤立循环，更适合复杂任务。

这一设计空间中出现了若干反复出现的模式。层级式编排使用一个更高层控制器，将工作分配给智能体或子智能体，并整合它们的输出。团队式编排将一组专门智能体暴露为一个协同团队，通常让它们承担不同的命名职责。工作流编排将智能体和工具组织为显式阶段或控制逻辑。扇出会并行运行多个智能体，以探索多样化解决方案。图组合则将智能体、工具或状态表示为交互图中的节点，从而允许多种协调模式共存。这些标签对应表 2 中使用的主要模式类别。

在这一层级，执行通常是有状态或混合的，因为多智能体系统必须维护协调状态、角色分配、任务图、共享工件或中间结果。Anthropic 的 planner-generator-evaluator 架构（Anthropic, 2025e）展示了更广泛的原则：规划、执行和验证可以被分离为显式角色，从而改善分解和鲁棒性，但也会增加协调开销（Anthropic, 2026c）。

表 2 中的系统以不同方式实例化了这些模式。DeerFlow（Bytedance, 2026）、AutoGen（Microsoft, 2025）、OpenAI Agents SDK（OpenAI, 2026a）和 DeepAgents（LangChain, 2026b）被归类为层级式编排。oh-my-claudecode（Heo, 2026）被归类为团队式编排。LangGraph（LangChain, 2026a）和 Hive（Aden, 2026）体现了图组合，Semantic Kernel（Microsoft, 2026）体现了工作流编排，而 Emdash（Action, 2026）体现了扇出。

6.4 从 Issue 到 Pull Request 的完整生命周期流水线

完整生命周期编排管理的是从规格说明到经过验证的输出的整个任务工作流。在这一层级，重点不仅是智能体如何交互，也包括执行框架如何支持跨规划、实现、验证、评审和交付的长周期执行。

其核心抽象是任务运行器：一种执行框架，能够在完整任务生命周期中管理调度、状态持久化、重试、验证和迭代式优化（OpenAI, 2026a; LangChain, 2026b）。执行被锚定在持久化工件中，例如仓库、issue、分支、文件、测试和 pull request。一个典型工作流会从 issue 或任务规格说明开始，经过智能体规划、代码或工件生成、验证、人类评审，最终到 pull request 被接受。

由于这些系统运行在持久化仓库和外部工作流之上，主导性的执行模型通常是有状态的。一些系统会将持久化基础设施状态与子组件中的类重放式或会话本地执行结合起来，因此在表 2 中被标记为混合。Vibe Kanban（Bloop-AI, 2026）、Symphony（OpenAI, 2026b）和 GitHub Agentic Workflows（GitHub, 2026）被归类为完整生命周期流水线。从概念上看，这些系统组合了前面的抽象：单智能体循环提供执行原语，多智能体模式提供协调能力，而任务运行器则将它们整合进一个端到端工作流，在这个工作流中，人类负责引导方向，智能体负责执行。

7 可观测性与运维（O）

可观测性与运维（O）是 ETCLOVG 的第五层，也是我们的分类体系从生命周期钩子中提升为一等地位的两个层之一（见第 1 节中的主张 2）。支撑本节的系统来自支持主张 3 的 148 多个项目语料库。

图 10：面向 LLM 智能体的可观测性与运维代表性工作

可观测性与运维

追踪与监控平台

Langfuse（Langfuse, 2026）、Opik（Comet ML, 2026）、Phoenix（Arize AI, 2026b）、MLflow（MLflow, 2026）、OpenTelemetry（OpenTelemetry, 2026）、OpenLLMetry（Traceloop, 2026）、OpenInference（Arize AI, 2026a）、AgentSight（Zheng et al., 2025）、AgentTrace（AlSayyad et al., 2026）

智能体专用运维平台

AgentOps（AgentOps AI, 2026）、RagaAI Catalyst（RagaAI, 2026）、Laminar（Laminar AI, 2026）、Watson（Rombaut et al., 2025）、AgentLens（Lu et al., 2024）、Claude-Code-Reverse（Yu, 2026）

成本追踪与优化

TensorZero（TensorZero, 2026）、Helicone（Helicone, 2026）、FrugalGPT（Chen et al., 2023）、GPTCache（Bang, 2023）、QC-Opt（Shekhar et al., 2024）、TALE（Han et al., 2025）、Dual-Pool Routing（Liu et al., 2026b）

可靠性工程

Effective Harnesses（Anthropic, 2025d）、Harness Design（Anthropic, 2026c）、Managed Agents（Anthropic, 2026b）、MAST（Cemri et al., 2025）、AgentErrorTaxonomy（Zhu et al., 2025）、SentinelAgent（He et al., 2025）、AgentFixer（Mulian et al., 2026）、QSAF（Atta et al., 2025）

统一可观测性

Taming Uncertainty（Moshkovich & Zeltyn, 2025）、Beyond Black-Box Benchmarking（Moshkovich et al., 2025）、Mind the Metrics（Koc et al., 2025）、NLAH（Pan et al., 2026）、Deep-Agent Evaluation（LangChain, 2025a）、Infrastructure Noise（Anthropic, 2026a） 图 10： 面向 LLM 智能体的可观测性与运维代表性工作，按照本章的运维类别组织。

这一层处理如何在生产中监控、调试智能体行为，并使其可靠。我们认为，可观测性应当被独立处理，而不是被归入生命周期钩子，因为它已经催生出一套专门的平台、规范和工程实践生态。

7.1 追踪与监控平台

智能体可观测性的基础是结构化轨迹收集：将每一次 LLM 调用、工具调用、检索步骤和上下文组装操作记录为一棵 span 树，使其可以被检查、过滤和重放。Langfuse、Opik、Arize Phoenix 和 MLflow 都提供交互式轨迹树，其中包括延迟火焰图、token 使用量拆解、成本归因仪表盘和提示词版本管理（Langfuse, 2026; Comet ML, 2026; Arize AI, 2026b; MLflow, 2026）。这些平台通常通过轻量级 SDK 包装器摄入轨迹，例如 @traceable 装饰器，以最小的代码改动为智能体函数调用加入插桩。

在这些平台之下，OpenTelemetry（OTel）已经成为事实上的插桩标准。OTel 社区发布了面向生成式 AI 的语义约定，用于定义模型名称、temperature、token 数量和延迟等 span 属性（OpenTelemetry, 2026）。两个开源项目将这些约定操作化：OpenLLMetry 为 LLM 提供商（OpenAI、Anthropic、Cohere）和向量数据库（Pinecone、Chroma、Weaviate）提供自动插桩库，并发出标准 OTel span 和指标（Traceloop, 2026）；由 Arize AI 维护的 OpenInference 则提供了一套互补规范，包含与 OTel 对齐的语义约定和自动插桩，并被设计为 Phoenix 的配套组件（Arize AI, 2026a）。通过建立在 OTel 之上，这些库使智能体轨迹能够流入团队已经用于传统微服务监控的同一套可观测性后端，例如 Prometheus、Jaeger、Grafana 和 Datadog，从而降低采用智能体专用工具的运维开销。

在更深层的插桩层面，学术研究探索了超越应用层装饰器的技术。AgentSight（Zheng et al., 2025）使用 eBPF 从应用进程外部监控智能体，在 SSL 边界拦截 TLS 加密的 LLM 流量以捕获意图，并监控内核事件，例如进程创建、文件 I/O 和网络调用，以捕获动作。一个实时相关引擎会将 LLM 响应与它们触发的系统行为关联起来，而第二个“观察者”LLM 会执行语义分析以识别风险。该方法与框架无关，不需要修改代码，并且 CPU 开销低于 3%。作者指出，与应用层工具相比，它具有结构性优势：系统级监控无法被被攻陷或配置错误的智能体绕过，因此对安全关键型部署尤其相关。

AgentTrace（AlSayyad et al., 2026）提出了一种互补的基于 schema 的日志框架，它跨三个“表面”捕获结构化日志：认知推理步骤、计划和反思；操作层面的工具调用与 API 交互；以及上下文环境状态与用户输入。这些表面被组织在一个统一 envelope 之下，并可与 OTel 集成以进行导出。认知表面对执行框架工程尤其相关，因为它捕获显式推理工件、计划、反思和自我修正。这些记录为调试由错误推理而非系统错误引发的失败提供了原材料。

7.2 智能体专用运维平台

通用追踪平台通常将抽象集中在 LLM 调用、工具调用和检索步骤上，并将它们视为 span 级事件。智能体专用平台则增加了一层抽象，用来捕获智能体层面的关注点：多步骤会话追踪、智能体身份与角色管理、工具选择策略，以及跨会话状态交接。AgentOps SDK 引入了一种层级式 span 模型，它围绕智能体生命周期来组织会话、智能体、操作或任务、工作流、工具调用和 LLM 调用，而不是把它们视为孤立的 API 调用（AgentOps AI, 2026）。RagaAI Catalyst 面向 RAG 与多智能体工作负载，提供质量与安全仪表盘，用于暴露检索层和智能体层异常（RagaAI, 2026）。Laminar 提供一个 OSS 优先的智能体可观测性平台，将轨迹、评估和提示词管理结合在一起（Laminar AI, 2026）。

学术界已经开始形式化这些关注点。Moshkovich 与 Zeltyn（2025）提出了一个六阶段 AgentOps 自动化流水线：观察、收集指标、检测异常、执行根因分析、推荐修复，以及自动化补救。他们进一步将利益相关者空间分解为四种角色：开发者、测试人员、SRE 和业务用户；每种角色都会在不同生命周期节点上与该流水线交互。他们的配套实证研究（Moshkovich et al., 2025）将任务流发现引入为一种可观测性原语，并通过用户研究证明，79% 的实践者认为非确定性执行流是智能体系统中最显著的挑战。

Natural-Language Agent Harnesses（NLAH）框架（Pan et al., 2026）及其配套开源实现，则采取了一个互补步骤：将执行框架本身视为一等研究对象。通过系统化消融实验，作者量化了单个执行框架模块对下游智能体性能的贡献。这些模块包括工具注册表、权限系统、钩子、技能和上下文折叠。对可观测性的含义是：执行框架不仅是被监控的对象，也是干预的来源；每个被消融的模块，都是可观测性流水线可以标记和调优的旋钮。

认知可观测性将智能体层监控扩展为不仅询问智能体做了什么，还询问为什么这么做。Watson（Rombaut et al., 2025）正式引入了这一概念，部署了一个“代理智能体”，它会复现主智能体的输出，同时通过提示词归因生成逐步推理轨迹。在 MMLU 和 SWE-bench-lite 上，结合 AutoCodeRover 和 OpenHands 进行评估后，Watson 表明恢复出的推理轨迹既有助于人工调试，也有助于自动纠正，并能带来可测量的任务成功率提升。AgentLens（Lu et al., 2024）通过一个三窗格可视分析系统闭合了可视化循环：Outline View 用于智能体轨迹，Agent View 用于带有因果弧的事件栈，Monitor View 用于同步环境重放。该系统将原始执行日志转化为层级化结构的行为叙事。一项包含 14 名参与者的用户研究表明，在复杂分析任务上，它相较于仅重放的基线有显著改进。更专门化的可视化工具，例如 claude-code-reverse，会对特定代码智能体的交互链进行逆向工程，作为理解执行框架层行为的研究工件（Yu, 2026）。

7.3 成本追踪与优化

LLM 推理按 token 计价，而智能体执行框架会放大成本暴露，因为一个面向用户的单一任务可能触发数十次 LLM 调用，每次调用都有自己的提示词组装、工具结果注入和响应生成。可观测性需求由两部分组成：追踪，即知道 token 花在了哪里；优化，即用更少 token 达成同样结果。

在追踪方面，TensorZero 提供一个统一的 LLMOps 栈，将网关、可观测性、实验和优化打包到一个服务中，从而支持按调用和按任务进行成本归因（TensorZero, 2026）。Helicone 则采取一种极简方式，作为一个可直接替换接入的代理，在不改代码的情况下增加成本和延迟监控，因此特别适合那些希望获得成本可见性、但不想承诺采用完整可观测性平台的团队（Helicone, 2026）。

在优化方面，FrugalGPT（Chen et al., 2023）提出了基础性表述，给出了三种降本策略：提示词适配、LLM 近似和 LLM 级联。它表明，自适应级联可以通过将更简单查询路由到更便宜的模型，在最高降低 98% 成本的同时匹配 GPT-4 的性能。GPTCache（Bang, 2023）用一个语义缓存层补充了这一方法：它在重复或改写查询抵达 LLM 之前进行拦截，并使用嵌入相似性检索缓存响应。路由与缓存一起，已经成为生产级成本优化栈中反复出现的构件，并且可以直接应用于执行框架层插桩，在那里，每个工具调用和上下文组装步骤都可以被独立计量和路由。

QC-Opt（Shekhar et al., 2024）通过一个质量感知框架扩展了路由范式，在预算约束下联合优化模型选择、token 数量和延迟，并使用 BertScore 预测器在不调用目标模型的情况下估计输出质量。TALE（Han et al., 2025）发现的 token 弹性现象揭示了一个重要细节：对于思维链推理来说，将 token 预算设得过低，反而可能增加 token 消耗，因为模型会超出预算，生成的 token 比中等预算提示词更多。在基础设施层面，Dual-Pool Token-Budget Routing（Liu et al., 2026b）从服务侧处理成本问题，将一个同构 vLLM 集群划分为短上下文池和长上下文池，并根据估计 token 预算路由请求。该方法在 Azure LLM Inference 轨迹和 LMSYS-Chat-1M 上评估后，将 GPU 小时数减少了 31–42%，按 A100 集群规模推算，相当于每年节省 286 万美元。

对于执行框架工程师而言，其含义是成本可观测性必须跨越多个层次：API 层面的 token 追踪（Helicone、TensorZero）、应用层面的路由决策（FrugalGPT、QC-Opt），以及基础设施层面的资源利用率（Dual-Pool、KV-cache 占用）。Anthropic 关于智能体式代码评估中基础设施噪声的研究（Anthropic, 2026a）提供了一个警示性补充：仅基础设施配置就可以让基准得分移动 6 个百分点（p < 0.01）。这一发现表明，成本优化和评估保真度紧密交织，因为为了节省成本而削减资源，可能会以没有细粒度可观测性就不可见的方式，悄悄降低智能体性能。

7.4 可靠性工程

失败恢复、检查点/恢复、重试策略和会话恢复都是执行框架层关注点，它们决定长时间运行的智能体是否能够在瞬时故障后存活下来。当智能体跨多个上下文窗口运行时，这些关注点会变得尤其尖锐，因为每个新会话开始时都不记得此前发生了什么（Anthropic, 2025d）。Anthropic 的执行框架工程工作识别了长时间运行代码智能体中的四种反复出现的失败模式：智能体试图一次性完成整个任务；智能体过早宣布项目完成；智能体在会话之间让环境处于损坏状态；以及智能体在没有正确测试的情况下将功能标记为完成。他们的两部分解决方案通过执行框架设计而不是模型改进来直接处理这些可靠性问题（Anthropic, 2025d）。它使用一个初始化智能体将任务分解为结构化功能列表，并设置进度追踪工件，包括 git 仓库、进度文件和 init 脚本；随后，一个编码智能体会一次只增量处理一个功能，并留下干净的交接状态。

后续工作扩展了这一模式。Anthropic 受 GAN 启发的三智能体架构，即规划器、生成器和评估器，引入了 sprint 契约和分离式自我评估，以处理智能体倾向于过度赞美自己工作的现象（Anthropic, 2026c）。值得注意的是，作者展示了执行框架复杂度应当跟随模型能力变化：当从 Opus 4.5 升级到 Opus 4.6 时，他们完全移除了 sprint 构造和上下文重置，使成本从 200 美元降到 125 美元，同时保持输出质量。这说明了一个一般原则：每个执行框架组件都编码了一个关于“模型自己不能做什么”的假设，而随着模型改进，这些假设会过时。

在基础设施层面，Anthropic 的 Managed Agents 架构（Anthropic, 2026b）将“大脑”（执行框架 + LLM）与“手”（沙箱和工具）以及“会话”（持久事件日志）解耦，使每个部分都可以独立恢复。如果执行框架崩溃，可以通过 wake(sessionId) 重启一个新实例，并从会话日志中的最后一个事件恢复。如果沙箱失败，执行框架会将该错误捕获为工具调用失败，并配置一个新的沙箱。凭证存储在外部保险库中，永远不会进入沙箱。这一架构将所有组件从“宠物”（不可替换、需要手工照料的实例）转化为“牲畜”（可互换、可自动重新配置的实例），这是大规模可靠运行智能体的前提。

学术文献提供了可靠性工程必须处理的失败模式分类体系。MAST（Cemri et al., 2025）识别了多智能体系统中的 14 种失败模式，并将它们聚类为系统设计问题、智能体间错位和任务验证问题（κ = 0.88）。AgentErrorTaxonomy（Zhu et al., 2025）按模块分解失败，包括记忆、反思、规划、动作和系统，并表明错误传播，即单个根因失败通过后续决策级联扩散，是核心可靠性瓶颈。他们的 AgentDebug 框架通过隔离根因而不是处理表层症状，使任务成功率最高获得 26% 的相对提升。与此同时，Vinay（2025）贡献了一个系统级分类体系，涵盖生产 LLM 部署特有的 15 种隐藏失败模式，包括版本漂移（模型更新悄悄改变行为）、成本驱动的性能崩塌（激进优化降低质量），以及多步骤推理漂移（长序列中的渐进式连贯性丧失）。QSAF（Atta et al., 2025）将认知退化形式化为一个六阶段生命周期，并在五个 LLM 平台上进行验证，揭示出幻觉输出可能被存入持久记忆，并在未来会话中被复用，从而形成跨会话的自我强化退化循环。

对于运行时检测，SentinelAgent（He et al., 2025）将多智能体交互建模为图，并使用 LLM-as-judge 结合人类在环策略优化，在三个层级对异常进行分类：全局异常、单点异常和多点异常。AgentFixer（Mulian et al., 2026）在 IBM 的 CUGA 生产系统上部署了 15 个验证工具，达到 64–88% 的问题检测率，并发现 38% 的任务失败可以追溯到解析错误；这是一类完全可以通过确定性检查解决的失败模式。实践含义是，智能体可靠性需要一种分层检测策略：用轻量级规则检查结构性失败，例如格式错误的工具调用和 schema 违规；用统计监控检查性能漂移，例如延迟、token 使用量和成本趋势；用基于 LLM 的语义分析检查推理失败，例如幻觉、计划—动作错位和过早停止。

7.5 讨论：迈向统一可观测性

可观测性—评估缺口。 LangChain 调查中的 89%/52% 分裂反映了一种结构性脱节：轨迹收集工具和评估框架大多由不同社区开发，并拥有不同接口。弥合这一缺口需要更紧密的集成，例如从生产失败轨迹中自动生成回归测试用例，或将在线评估分数用作告警信号。LangChain 自己对深度智能体评估的分析（LangChain, 2025a）以及 Anthropic 对基础设施噪声的量化（Anthropic, 2026a）都主张，应当将评估和可观测性视为一个单一反馈循环，而不是彼此分离的关注点。

统一 LLMOps 栈。 TensorZero 和 Langfuse 等工具正在转向将网关、可观测性、评估和优化打包到单一平台中，以降低集成开销。NLAH 框架则进一步推动这一方向，使执行框架本身模块化且可内省，并通过消融实验量化每个组件的贡献。Anthropic 的 Managed Agents 架构采用基础设施层视角，将执行框架组件虚拟化为可替换接口，例如 execute()、emitEvent() 和 getEvents()，从而能够在不改变周边系统的情况下容纳未来的执行框架设计。

执行框架即假设原则。 每个执行框架组件都编码了一个关于模型无法自行完成什么的假设（Anthropic, 2026c）。随着模型改进，可观测性系统不仅必须检测智能体何时失败，也必须检测哪些执行框架组件已经变成不必要的开销。理想的可观测性系统应当包含一个元监控层，用于追踪哪些干预仍然是承重性的，例如上下文重置、评估器反馈循环和工具限制，从而在模型升级的同时持续简化执行框架。

8 验证与评估（V）

验证与评估（V）是 ETCLOVG 的第六大支柱（见第 1 节中的主张 2）。我们讨论的系统和基准来自支撑主张 3 的 148 多个项目语料库。

图 11：面向 LLM 智能体的验证与评估代表性工作

验证与评估

任务与基准定位

SWE-bench（Jimenez et al., 2024）、Terminal-Bench（Merrill et al., 2026）、WebArena（Zhou et al., 2024）、VisualWebArena（Koh et al., 2024）、BrowserGym（Chezelles et al., 2024）、WorkArena（Drouin et al., 2024）、OSWorld（Xie et al., 2024）、AgentBench（Liu et al., 2023a）、GAIA（Mialon et al., 2023）、TheAgentCompany（Xu et al., 2024）、WorkArena++（Boisvert et al., 2024）

执行前就绪性验证

Repo2Run（Hu et al., 2025a）、HAL（Kapoor et al., 2025）、SWE-agent（Yang et al., 2024）、SWE-ReX（SWE-agent Team, 2024）、OpenHands（Wang et al., 2025b）、LLM-as-Judge Survey（Gu et al., 2024）

受控执行与轨迹捕获

SWE-agent（Yang et al., 2024）、OpenHands（Wang et al., 2025b）、SWE-ReX（SWE-agent Team, 2024）、HAL（Kapoor et al., 2025）、R2E-Gym（Jain et al., 2025）、LangChain Deep-Agent Evaluation（LangChain, 2025b）

多层级判断与失败归因

ReAct（Yao et al., 2023）、G-Eval（Liu et al., 2023b）、MT-Bench and Chatbot Arena（Zheng et al., 2023）、LLM-as-Judge Survey（Gu et al., 2024）、SWE-bench（Jimenez et al., 2024）、OSWorld（Xie et al., 2024）、Terminal-Bench（Merrill et al., 2026）、HAL（Kapoor et al., 2025）

持续回归与部署反馈

Anthropic Evals（Anthropic, 2026b）、LangChain Deep-Agent Evaluation（LangChain, 2025b）、promptfoo（promptfoo contributors, 2026）、DeepEval（Confident AI, 2026）、RAGAS（Es et al., 2024）、lm-evaluation-harness（Gao et al., 2021）、Reproducible LM Evaluation（Biderman et al., 2024）、verifiers（Prime Intellect, 2026）、R2E-Gym（Jain et al., 2025）、Meta-Harness（Lee et al., 2026） 图 11： 面向 LLM 智能体的验证与评估代表性工作，按照本章的任务到反馈生命周期组织。

8.1 作为任务到反馈生命周期的执行框架评估

一种具备执行框架意识的评估，应当将报告出来的分数视为模型—执行框架组合的属性，而不是模型单独的属性。这促使评估协议要么在不同模型之间锁定执行框架，要么将执行框架配置作为一个显式实验因素进行变化（Bölük, 2026b）。我们将执行框架评估组织为一个任务到反馈生命周期：这是一个结构化过程，从定义智能体被要求完成什么开始，到将评估结果反馈进执行框架改进为止。图 12 总结了这一五阶段任务到反馈生命周期。该生命周期建立在传统 LLM 评估与智能体评估之间的一个关键差异之上。传统 LLM 评估主要是在固定输入上为输出打分，而执行框架评估衡量的是一个执行片段：任务被定位到一个环境中，智能体随时间与工具和状态交互，轨迹被捕获，评估器同时判断最终结果以及达到该结果所经过的路径（Kapoor et al., 2025; Anthropic, 2026b; LangChain, 2025b）。

这一生命周期的核心动机是，评估基础设施噪声可能会伪装成模型失败：失败运行不仅可能反映模型局限，也可能反映工具损坏、上下文陈旧、沙箱未重置、测试不稳定、基准模糊或评审器不稳定（Kapoor et al., 2025; Hu et al., 2025a; Jimenez et al., 2024）。因此，评估不应只是报告最终分数，而应当将智能体行为转化为结构化判断、失败归因和回归反馈。 图 12： 执行框架评估的任务到反馈生命周期。第 V 节将验证与评估组织为一个五阶段质量控制循环：任务与基准定位、执行前就绪性验证、受控执行与轨迹捕获、多层级判断与失败归因，以及持续回归与部署反馈。该图强调，执行框架评估不应只报告最终成功率，还应诊断失败来源，并将由此产生的证据反馈到系统化执行框架改进中。

五阶段分解遵循智能体评估运行的因果路径。在智能体能够被评估之前，基准必须规定任务、环境、工具、约束和成功标准。在执行之前，必须验证设置是否正确，以免将环境或评分器失败误认为模型失败。在执行过程中，执行框架必须捕获能让运行过程可诊断的轨迹。执行之后，系统必须判断结果、轨迹和评估器可靠性，然后将失败归因到可能的执行框架组件。最后，生成的诊断应反馈到回归测试和未来执行框架修订中。在这一视角下，评估不是一个终点式打分步骤，而是覆盖完整智能体执行框架的质量控制循环。

我们围绕五个阶段展开讨论。

• 任务与基准定位定义正在评估什么、在哪个环境中评估、使用哪些工具、约束和成功标准（第 8.2 节）。

• 执行前就绪性验证检查沙箱、依赖项、工具、上下文状态、权限策略、预算和评分器是否在智能体运行之前被正确初始化（第 8.3 节）。

• 受控执行与轨迹捕获在可复现条件下运行智能体，同时记录模型输出、工具调用、状态变化、错误、重试、成本和延迟（第 8.4 节）。

• 多层级判断与失败归因在结果、轨迹和评估器层级上评估运行，然后在执行框架栈中定位可能的失败来源（第 8.5 节）。

• 持续回归与部署反馈将评估结果转化为回归测试、监控信号，以及后续执行框架修订的工程反馈（第 8.6 节）。

8.2 阶段 1：任务与基准定位

第一阶段询问正在评估什么。对于 LLM 智能体而言，任务并不只是一个自然语言提示，而是一个由环境状态、可用工具、允许动作、约束、终止条件和成功标准共同定义的嵌入式问题。因此，任务定位是执行框架评估的基础：如果没有明确规定环境和成功条件，后续分数就无法被可靠解释。

8.2.1 软件工程与终端任务

软件工程基准是最成熟的智能体评估形式之一，因为它们将真实任务与可执行结果验证结合在一起。SWE-bench 将每个任务定位到一个真实 GitHub issue 和仓库快照中，然后通过运行测试来评估生成的补丁是否解决了该 issue（Jimenez et al., 2024）。Terminal-Bench 将这一思想扩展到命令行工作流中，在这些工作流里，智能体通过编辑文件、运行命令、设置依赖项和解释失败，与终端环境交互（Merrill et al., 2026）。这一类别的关键洞察是：强结果验证器需要强任务定位。只有当仓库状态、依赖项和预期成功标准被精确规定时，测试才能作为可靠评估器。否则，一次测试失败可能反映无效补丁，但也可能反映环境不一致或基准实例规定不足。

8.2.2 Web、浏览器与计算机使用任务

Web 和计算机使用基准将任务定位到交互式环境中，其中成功由浏览器、桌面或应用状态变化来定义。WebArena 为自主智能体引入了真实 Web 环境（Zhou et al., 2024）；VisualWebArena 增加了多模态 Web 任务（Koh et al., 2024）；BrowserGym 提供了通用浏览器智能体研究基底（Chezelles et al., 2024）；WorkArena 聚焦于基于 ServiceNow 的知识工作（Drouin et al., 2024）。OSWorld 进一步将评估扩展到真实计算机环境，涉及桌面应用、文件和多应用工作流（Xie et al., 2024）。这些基准表明，浏览器和计算机使用评估同时是一个评估问题和一个环境设计问题。基准必须提供真实接口、隔离任务状态、暴露适当观察，并定义可测量的成功谓词。这在执行环境层与评估层之间建立了直接桥梁。

8.2.3 跨领域与企业工作流任务

第三类基准测试的是跨异构工具、环境和工作流的更广泛智能体能力。AgentBench 在操作系统、数据库、网页浏览和游戏等场景中评估 LLM 智能体（Liu et al., 2023a）；GAIA 面向需要推理、工具使用和多模态信息访问的一般助手任务（Mialon et al., 2023）；TheAgentCompany 模拟工作场所风格的数字劳动（Xu et al., 2024）。WorkArena 和 WorkArena++ 进一步强调企业工作流，在这些工作流中，成功取决于对复杂软件的导航，而不是回答孤立问题（Drouin et al., 2024; Boisvert et al., 2024）。这一基准家族的主要贡献是覆盖范围：它测试一个执行框架能否跨任务类型、工具接口、状态表示、工作流和成功条件进行泛化。

8.3 阶段 2：执行前就绪性验证

第二阶段询问评估是否能够公平且可复现地运行。这个阶段在基准排行榜中通常不可见，但对执行框架评估至关重要。在智能体开始之前，执行框架必须验证环境、工具、上下文状态、权限边界、预算约束和评估器是否被正确初始化。没有这一就绪性层，下游失败将难以归因：一次失败运行可能由智能体造成，也可能由评估设置造成。

8.3.1 环境与沙箱就绪性

环境就绪性检查沙箱、仓库、浏览器、终端或虚拟机是否从已知基线开始。在软件工程中，这包括仓库快照、依赖项、任务设置和测试可执行性；在浏览器和计算机使用场景中，这包括网站重置、浏览器配置文件、桌面状态和服务可用性。

若干系统明确暴露了这一问题。SWE-bench 依赖可执行仓库状态和基于测试的验证（Jimenez et al., 2024）；Terminal-Bench 将终端任务与受控环境和验证逻辑打包在一起（Merrill et al., 2026）；OSWorld 使用真实计算机环境以及基于执行的评估脚本（Xie et al., 2024）。Repo2Run 通过为仓库自动化可执行 Docker 环境来处理依赖和环境设置问题（Hu et al., 2025a），而 HAL 强调面向智能体的标准化、成本感知评估基础设施（Kapoor et al., 2025）。这些系统共同表明，环境重置和依赖验证是测量工具的一部分。

8.3.2 工具、上下文与权限就绪性

就绪性验证是跨层的。工具就绪性检查 API、MCP 服务器、浏览器控制、shell 命令和文件操作是否可用，并且描述是否一致。上下文就绪性检查历史、记忆存储、草稿区和检索文档是否被重置，或是否按意图初始化。权限就绪性检查文件访问、凭证、网络访问和审批闸门是否匹配基准规格说明。

这一阶段将评估与工具层、上下文层和治理层连接起来。如果工具描述在运行之间发生变化，那么基准测量的就不再是同一个动作空间。如果记忆或上下文未被重置，智能体可能会受益于泄漏状态。如果权限过于严格，一个有能力的智能体可能因为治理原因失败；如果权限过于宽松，不安全行为或利用基准漏洞的行为可能不会被检测到。SWE-agent、SWE-ReX 和 OpenHands 等系统表明，工具暴露、shell 访问、浏览器访问、执行后端和运行时接口不能与评估设计分离：智能体—计算机接口决定了哪些动作是可能的，因此也决定了基准实际测量的内容（Yang et al., 2024; SWE-agent Team, 2024; Wang et al., 2025b）。因此，一个严格的评估执行框架应当将这些配置记录为评估元数据，包括工具注册表、上下文策略、权限策略、预算、超时、模型配置和运行时接口。

8.3.3 评估器与评分器就绪性

评估器本身也必须在执行前被验证。确定性评分器应当检查不稳定性、缺失依赖项以及与环境状态的兼容性；LLM-as-Judge 的提示词、评分标准和评审模型应当进行版本管理；人工审计协议则应当预先定义。

在 SWE-bench 等基准中，可执行测试提供了可扩展的结果验证，但分数有效性仍然取决于正确的环境设置、任务规格说明和测试可靠性（Jimenez et al., 2024）。对于开放式任务，LLM-as-Judge 系统需要校准、偏差缓解和一致性检查，而不是盲目复用一个强模型作为评分器（Zheng et al., 2023; Gu et al., 2024）。因此，评估器就绪性是有意义失败归因的前提。

8.4 阶段 3：受控执行与轨迹捕获

第三阶段询问执行期间发生了什么。在传统 LLM 评估中，证据可能只包含一个输入—输出对。在智能体评估中，轨迹是一条多步骤路径：模型观察状态、推理、调用工具、接收工具输出、修改环境、处理错误，并最终终止。因此，受控执行和轨迹捕获对于将基准运行转化为可诊断证据是必要的。

8.4.1 受控 rollout 与可复现执行

rollout 是智能体评估的基本单位。它包括任务、模型配置、执行框架配置、动作序列、中间观察、最终状态和评分结果。一次受控 rollout 会固定偶然变化的关键来源，包括环境状态、工具可用性、超时、预算、权限策略和评估器版本。当仍然存在非确定性时，重复 rollout 可以暴露方差，而不是用单个分数掩盖方差。

若干系统说明了这种可复现执行需求。SWE-agent 将仓库导航、文件编辑和测试执行作为交互循环的一部分暴露给智能体（Yang et al., 2024）。OpenHands 将代码编辑、命令行执行、浏览器交互、沙箱化执行和基准集成结合在一起（Wang et al., 2025b）。SWE-ReX 对本地和远程沙箱化 shell 环境进行抽象，使执行后端可以在不改变智能体逻辑的情况下发生变化（SWE-agent Team, 2024）。LangChain 进一步将深度智能体评估分解为单步验证、完整轮次评估和多轮模拟（LangChain, 2025b）。这些系统共同表明，可复现性要求重放完整的模型—工具—环境交互，而不仅仅是重新运行一次模型调用。

8.4.2 轨迹原生评估

轨迹捕获将二元评分转化为因果诊断。一个轨迹原生的执行框架应当记录模型输出、工具调用、工具结果、环境状态变化、上下文快照、错误、重试、恢复动作、token 使用量、延迟和成本。这些轨迹能够区分表面相似的失败：一个智能体可能从未找到相关文件，而另一个智能体可能找到了文件却生成了无效补丁。它们还可以揭示不理想的成功，例如利用基准漏洞、过度工具调用或权限违规。

HAL 将日志和轨迹视为标准化智能体评估的一等工件，使用大规模智能体日志来检查最终分数可能隐藏的行为（Kapoor et al., 2025）。R2E-Gym 同样将可执行轨迹和混合验证器连接到测试时评估与训练时反馈（Jain et al., 2025）。因此，对于执行框架工程而言，轨迹并不是辅助调试工件，而是主要评估数据。

8.4.3 成本、延迟与资源追踪

智能体评估不仅应报告质量，还应报告达到该质量所需的成本。长周期智能体可能通过消耗更多 token、调用更多工具、更多次重试或使用更强模型来提高成功率。因此，执行框架层评估应当追踪 token 使用量、模型成本、墙钟延迟、工具调用次数、重试次数和资源消耗。

评估不应只按成功率对智能体排序，而应暴露成功率—成本—延迟前沿。HAL 明确将智能体评估框定为标准化且成本感知的评估（Kapoor et al., 2025），而 LangChain 的深度智能体评估指南强调可复现环境和多粒度评估，用于比较成本—质量权衡（LangChain, 2025b）。这对于已部署的智能体服务尤其重要，因为优化单位是在预算和延迟约束下反复发生的工作负载。

8.5 阶段 4：多层级判断与失败归因

在受控执行与轨迹捕获之后，核心问题是如何判断该次运行，以及如果运行失败，如何定位失败。我们将阶段 4 定义为多层级判断与失败归因的组合过程。多层级判断会在三个层级上评估运行：最终结果是否正确，轨迹是否高效且符合策略，评估器本身是否可靠。随后，失败归因会使用这些信号诊断失败最可能源自何处，例如模型、工具接口、上下文管理器、执行环境、编排循环、基准规格说明或评估器。这个阶段正是执行框架评估区别于普通基准评估之处：其目标不只是分配分数，而是将执行证据转化为可执行的工程诊断。

8.5.1 结果级评估

结果级评估衡量最终任务目标是否实现。在软件工程中，这通常通过单元测试、回归测试或 issue 特定验证来操作化，如 SWE-bench 所示（Jimenez et al., 2024）。在终端任务中，结果评估可能依赖最终文件、命令输出或任务特定检查器（Merrill et al., 2026）。在浏览器和企业工作流基准中，它通常依赖最终环境状态，例如表单是否已提交、工单是否已更新，或者配置是否已更改（Zhou et al., 2024; Drouin et al., 2024）。在 GAIA 等一般助手基准中，结果可能是答案字符串或结构化响应（Mialon et al., 2023）。

结果级评估的优势是可扩展性和可解释性：它提供清晰的任务级成功信号，并支持排行榜比较。它的局限是压缩。一个完整执行片段被压缩成一个值，掩盖了智能体是否以鲁棒、安全或高效的方式成功。因此，结果评估是必要的，但并不充分。它回答的是任务是否完成，而不是执行框架是否产生了可信执行。

8.5.2 轨迹级评估

轨迹级评估衡量智能体所走路径的质量。它询问智能体是否选择了合适工具，是否以合理顺序安排动作，是否避免冗余调用，是否遵守权限边界，是否从错误中恢复，以及是否随时间保持上下文一致性。这一层级是智能体评估最明显不同于传统输出评估的地方：最终答案可能正确，但轨迹仍然不可接受，例如智能体浪费了过多 token、反复调用无关工具、违反权限，或依赖脆弱的基准特定行为。

ReAct 通过将智能体行为表示为交错的推理、行动和观察步骤，为轨迹级分析提供了概念基础（Yao et al., 2023）。现代智能体基准将这一视角扩展到更丰富的环境中，其中每个动作都会改变未来步骤可获得的状态。WebArena、WorkArena、OSWorld 和 Terminal-Bench 都会产生轨迹，而其中间动作是有意义的评估对象，不再是隐藏的实现细节（Zhou et al., 2024; Drouin et al., 2024; Xie et al., 2024; Merrill et al., 2026）。LangChain 的评估模式同样强调单步评估和完整轮次评估，因为它们允许开发者在一次完整运行成功或失败之前，就检查决策质量（LangChain, 2025b）。

轨迹级判断对执行框架工程尤其有价值，因为它提供了一条从失败走向修复的路径。如果智能体因为选择错误工具而失败，那么可能需要改进工具接口。如果它忘记了先前约束，那么可能需要调整上下文层。如果它陷入循环且无法恢复，那么可能需要为编排层增加生命周期控制。因此，轨迹评估会将基准结果转化为面向具体层的工程反馈。

8.5.3 评估器级评估

评估器级评估询问评估器本身是否可信。确定性验证器，例如单元测试或基于状态的检查器，具有可复现、便宜且易于跨系统比较的优点，但它们范围狭窄，并且很难为开放式任务设计。LLM-as-Judge 系统对自然语言输出和轨迹评估很灵活，但会引入偏差、非确定性和额外成本。人工审计对于模糊或安全关键案例仍然重要，但它无法扩展到持续评估。

G-Eval 表明，基于 LLM 的评估器可以在自然语言生成评估任务上更好地对齐人类判断，同时也揭示了其对 LLM 生成文本的偏差（Liu et al., 2023b）。MT-Bench 和 Chatbot Arena 系统研究了 LLM-as-Judge，并识别出位置偏差、冗长偏差、自我增强偏差和有限推理能力（Zheng et al., 2023）。近期综述进一步指出，可靠的 LLM-as-Judge 系统需要标准化、偏差缓解、一致性检查和元评估（Gu et al., 2024）。

对于智能体执行框架来说，评估器级评估不是可选项。如果评分器不稳定、测试具有非确定性，或 LLM judge 存在偏差，那么评估噪声可能会被错误归因到智能体或模型。因此，一个鲁棒执行框架应优先采用分层评分器：用确定性检查评估客观状态变化，用 LLM judge 进行语义或轨迹级评估，用人工审计处理模糊或高风险案例。评估器应被视为一个待测试组件，而不是系统之外的神谕。

8.5.4 跨执行框架层的失败归因

失败归因识别一次运行被判断之后应当修复什么。一次失败 rollout 可能源自模型推理、工具接口设计、陈旧或压缩过度的上下文、沙箱不稳定、编排循环、基准模糊性或评估器不可靠（Kapoor et al., 2025; Hu et al., 2025a; Jimenez et al., 2024; LangChain, 2025b）。结果级信号指示目标是否实现；轨迹级信号揭示动作序列是否连贯、高效且符合策略；评估器级信号指示分数本身是否可信。综合这些信号，可以支持诊断，而不只是评分（Kapoor et al., 2025; LangChain, 2025b）。

在实践中，归因很少是一个单标签分类问题。模糊的任务规格说明可能导致智能体选择错误工具；过度压缩的上下文可能导致它忘记约束；沙箱依赖问题可能触发增加成本的恢复行为；不稳定的 judge 可能掩盖一个有效解。因此，失败归因应被理解为围绕完整轨迹进行的诊断过程，而不是附加在最终分数之后的事后标签。阶段 4 的输出因此不只是一个判断，而是一份结构化诊断，可由阶段 5 反馈进回归测试和执行框架改进中。

8.6 阶段 5：持续回归与部署反馈

最后阶段询问评估结果如何驱动下一轮执行框架修订。智能体执行框架会持续演化：提示词、工具 schema、MCP 服务器、上下文策略、沙箱镜像、编排循环、治理规则和 judge 提示词都可能随时间变化。持续评估会将基准结果和生产失败转化为面向执行框架本身的回归系统。

8.6.1 面向执行框架变更的回归评估

回归评估不仅应由模型变更触发，也应由执行框架变更触发。工具描述、上下文压缩策略、沙箱镜像、权限规则或 judge 提示词的变化，都可能改变智能体行为或评估分数。由于执行框架组件之间存在交互，局部改进可能制造全局回归。

实践中的模式是维护一个分层评估套件：面向工具 schema 和确定性验证器的类单元测试；面向局部决策的单步测试；面向端到端完成的完整 rollout 测试；以及面向长周期连贯性的多轮模拟。LangChain 的深度智能体评估指南体现了这一分层视角（LangChain, 2025b），而 Anthropic 将 evals 框定为具有显式评分逻辑、可在开发期间运行的自动化测试（Anthropic, 2026b）。

8.6.2 评估框架与 LLMOps 集成

通用评估框架为持续测试提供可复用基础设施。Promptfoo 支持提示词和 LLM 应用回归测试；DeepEval 提供类似单元测试的抽象；RAGAS 聚焦于检索增强生成评估；lm-evaluation-harness 支持标准化语言模型评估（promptfoo contributors, 2026; Confident AI, 2026; Es et al., 2024; Biderman et al., 2024; Gao et al., 2021）。尽管这些工具并非全都为长时间运行的智能体设计，但它们为面向回归的执行框架评估提供了构件。

评估还应与可观测性连接。生产轨迹可以变成回归测试，评估失败可以变成可观测性信号。这个连接闭合了监控“发生了什么”与构建受控测试来复现和诊断它之间的循环。

8.6.3 基于验证器与训练时评估

一个更新的方向是，不仅将评估器用作离线指标，还将其用作训练信号和优化目标。基于验证器的环境和 RL 风格智能体 gym，包括 R2E-Gym 和 verifiers，会将环境反馈用作奖励或验证信号，以改进智能体策略和脚手架（Jain et al., 2025; Prime Intellect, 2026）。这将评估从事后测量步骤转变为智能体训练、测试时适配和脚手架选择中的主动组件。

Meta-Harness 通过将执行框架设计本身视为自动化搜索对象，扩展了这一方向（Lee et al., 2026）。这种视角不是只评估哪个模型在固定执行框架下表现最好，而是询问哪种执行框架结构、提示策略、工具接口或控制循环能够产生更可靠的智能体行为。在这一框架下，评估不是流水线的终点；它是让执行框架得以改进的信号。

8.7 小结

验证与评估是将智能体行为转化为工程证据的一层。我们将这一层组织为任务到反馈生命周期。阶段 1 将任务定位在真实环境和成功标准中。阶段 2 验证评估设置是否就绪、公平且可复现。阶段 3 运行受控 rollout 并捕获轨迹。阶段 4 在结果、轨迹和评估器层级上判断每次运行。阶段 5 将结果反馈进持续回归测试和执行框架改进。

这一生命周期将评估从排行榜机制重新框定为面向智能体执行框架的质量控制循环。最终成功率仍然有用，但已经不再充分。对于长时间运行的智能体，核心评估问题不仅是智能体是否成功，还包括它为什么成功或失败、路径是否可接受、评估器是否可信，以及下一步应该改进哪个执行框架组件。

9 治理与安全（G）

图 13：面向 LLM 智能体的治理与安全代表性工作

治理与安全

权限模型与身份管理

Progent（Shi et al., 2025a）、Contextual Agent Security（Tsai & Bagdasarian, 2025）、Authenticated Delegation（South et al., 2025）、SAGA（Syros et al., 2025）、IsolateGPT（Wu et al., 2025）、Permission Manifests（Marro et al., 2025）

生命周期钩子

PromptShield（Jacob et al., 2024）、DataSentinel（Liu et al., 2025）、ShieldAgent（Chen et al., 2025b）、ControlValve（Jha et al., 2025）、CaMeL（Debenedetti et al., 2025）、AgentSpec（Wang et al., 2026）、AgentDoG（Liu et al., 2026a）

组件加固

Instruction Hierarchy（Wallace et al., 2024）、SecAlign（Chen et al., 2025a）、Llama Guard（Inan et al., 2023）、MCP Safety Audit（Radosevich & Halloran, 2025）、Jumping the Line（Trail of Bits, 2025）、ETDI（Bhatt et al., 2025）、SAFEFLOW（Li et al., 2025）

声明式宪章

Claude’s Constitution（Anthropic, 2026a）、AutoHarness（AIMing Lab, 2026）、Progent Policies（Shi et al., 2025a）、Formal-LLM（Li et al., 2024）、VeriSafeAgent（Lee et al., 2025）、AgentSpec（Wang et al., 2026）

审计基础设施

AutoHarness（AIMing Lab, 2026）、SAGA（Syros et al., 2025）、AgentMonitor（Naihin et al., 2023）、AgentAuditor（Luo et al., 2025）、SentinelAgent（He et al., 2025）、OWASP LLM Top 10（OWASP Foundation, 2025）、Agentic Governance Practices（Shavit et al., 2023）

智能体安全图景

Attack and Defense Landscape（Kim et al., 2026）、Clawed and Dangerous（Chen et al., 2026）、AgentDojo（Debenedetti et al., 2024）、Jailbreaking LLMs（Andriushchenko et al., 2024）、Adaptive Attacks（Nasr et al., 2025）、Slopsquatting（Spracklen et al., 2025） 图 13： 面向 LLM 智能体的治理与安全代表性工作，按照本章的安全类别组织。

这一层处理如何约束智能体行为、使其安全，并让其承担可问责性。LLM 智能体如今会执行 shell 命令、发送电子邮件、提交代码，并调用第三方 API；对于生产部署而言，一个核心问题是：它们应当在什么约束下行动，以及当这些约束失效时由谁承担责任。在生产系统中，治理拥有自己的工具生态，包括权限引擎、策略语言、审计流水线和网关控制。该生态不同于第 6 节和第 7 节所涵盖的生命周期钩子与可观测性基础设施，因此有理由在 ETCLOVG 分类体系中将其作为独立层处理。我们围绕五种机制组织讨论：权限模型与身份管理（第 9.1 节）、生命周期钩子（第 9.2 节）、组件加固（第 9.3 节）、声明式宪章（第 9.4 节）和审计基础设施（第 9.5 节）。随后，我们将这些机制置于更广泛的智能体安全图景之中（第 9.6 节），并以开放研究方向收尾（第 9.7 节）。

9.1 权限模型与身份管理

任何智能体执行框架面对的第一个治理问题都是访问控制：智能体能够访问哪些工具、文件、网络端点和系统资源？智能体工作负载使这一问题比传统 RBAC 或 ABAC 更困难，因为所需工具集往往取决于一个部署时尚未知的自然语言任务。因此，相关文献沿着一条粒度轴线演进：部署时固定的静态边界、按每次工具调用评估的上下文策略，以及用于本地执行框架之外交互的跨边界权限。

静态权限边界。 生产级代码智能体通常会预先定义一个权限范围，并要求对范围外动作进行升级授权。Codex（OpenAI, 2025）在具有受限文件系统和网络访问的沙箱中运行 shell 命令，而 Gemini CLI（Mullen & Salva, 2025）则将工作区范围内的文件访问与命令允许/拒绝列表结合起来。这些边界易于检查，但无法表达任务特定意图。

要超越固定规则，就需要表达依赖每次工具调用运行时上下文的约束。

上下文相关的权限控制。 Progent（Shi et al., 2025a）引入了一种领域专用语言（DSL），其谓词覆盖工具名称、参数和环境状态。运行时会在每次调用前评估这些谓词，使最小权限策略能够随角色、用户或会话变化。Conseca（Tsai & Bagdasarian, 2025）进一步推进这一思想：它从可信上下文生成一个任务特定策略，并用一个独立的确定性检查器来执行它。策略生成与策略执行之间的分离很重要：生成组件可以适配任务，而执行器仍然保持可审计。

前述方法都在单个智能体边界内运行。多智能体设置会围绕访问控制和智能体身份引入额外挑战。

身份管理与智能体间访问控制。 在授予访问权限之前，系统必须确定是谁在请求访问。South 等人（2025）认为智能体需要认证委托：一个扩展 OAuth 2.0 和 OpenID Connect 的框架，其中包含用户 ID Token、智能体 ID Token 和带作用域的委托 Token，用于将用户意图绑定到智能体特定权限上。这条 token 链可以从人类主体到智能体动作创建一条可验证的问责轨迹。SAGA（Syros et al., 2025）基于这一原则，通过一种由提供方中介的架构将其扩展到多智能体设置中。智能体使用加密一次性密钥注册，短期访问 token 则执行用户定义的智能体间联系策略。IsolateGPT（Wu et al., 2025）采用架构性方法，使用 hub-and-spoke 模型：每个第三方应用都在一个隔离的 spoke 中执行，并拥有自己的 LLM、记忆和工具访问。spoke 之间的通信通过可信 hub 进行，因此跨应用数据交换成为一个显式治理决策，而不是共享上下文窗口带来的偶然副作用。

凭证管理。 智能体经常处理 API key、会话 token 和一次性密码。将这些凭证暴露到 LLM 上下文中会带来外泄风险。Skyvern（Skyvern-AI, 2025）展示了一种常见模式：将密钥存储在保险库中，只向 LLM 暴露占位符，并且只在执行认证动作的自动化层替换为原始值。未解决的问题是长周期会话中的密钥生命周期管理：token 可能在轨迹中途过期或被撤销，而更新后的凭证仍然必须保持在模型上下文之外。

Web 级权限协调。 上述机制在单个执行框架的信任边界内运行，并治理一个部署实例。跨组织交互则不同：当智能体访问第三方网站或调用其他方拥有的服务时，需要一种任何单个执行框架都无法独立强制执行的协调机制。Marro 等人（2025）提出 agent-permissions.json，这是一个类似 robots.txt 的轻量级清单文件。网站所有者可以声明智能体可以使用哪些 UI 元素、速率限制、并发约束，以及哪些动作需要人类确认。这样的清单并不能解决身份认证问题，但它展示了治理如何开始跨越组织边界。

开放挑战。 设计既有表达能力又易用的权限模型仍是一个未解决问题。过度限制的策略会降低智能体效用；过度宽松的策略则会否定治理本身的意义。社区尚未收敛到一种可在不同执行框架实现之间移植的标准权限规范语言。关于动作应当归因于人类操作者、智能体实例，还是临时任务身份的问题，也仍然存在开放争议（South et al., 2025）。

9.2 生命周期钩子

权限模型定义什么被允许。生命周期钩子定义策略检查在何时触发。许多执行框架会在智能体循环的每个阶段暴露钩子点：规划之前、工具调用之前、工具执行之后，以及响应交付之前。这些钩子允许在不修改智能体核心推理逻辑的情况下插入治理逻辑。图 14 将四个钩子点放置在一个单一工具使用周期中。 图 14： 一个工具使用周期中的四个钩子点。实线框是智能体组件；虚线框是治理钩子。H1 在输入到达 LLM 之前验证输入；H2 在工具执行之前验证拟议动作；H3 调解工具输出重新进入上下文的信息流；H4 对具有后果影响的动作设置用户批准闸门。

执行前钩子：输入护栏。 输入护栏会在数据到达 LLM 之前验证它。PromptShield（Jacob et al., 2024）和 DataSentinel（Liu et al., 2025）训练专门分类器，用于检测用户输入和检索内容中的提示注入载荷。基于规则的检测器严格但脆弱。基于模型的检测器泛化能力更好，但速度更慢，并且容易受到自适应攻击（Andriushchenko et al., 2024; Nasr et al., 2025）。

下一个执行点发生在 LLM 拟议动作和执行框架工具执行之间。

调用前钩子：输出护栏与动作验证。 在执行工具调用之前，输出护栏会检查 LLM 的拟议动作。ShieldAgent（Chen et al., 2025b）将安全约束形式化为可验证谓词，并根据这些谓词检查每个动作。在多智能体系统中，ControlValve（Jha et al., 2025）约束智能体之间的控制流图，并防止未授权的智能体跳转，从而处理控制流劫持攻击：在这种攻击中，一个智能体会将执行重定向到另一个智能体。

工具执行之后，返回数据在重新进入 LLM 上下文之前也必须被检查。

执行后钩子：信息流控制与污点追踪。 CaMeL（Debenedetti et al., 2025）实现了基于能力的信息流控制。每个数据值都携带追踪其来源的元数据标签，从而区分可信用户输入和不可信网页检索。一个自定义解释器会强制规定，不可信数据不能影响控制流决策。CaMeL 将基于可信上下文的规划，与基于不可信内容的处理分离开来，在 AgentDojo（Debenedetti et al., 2024）上以牺牲部分灵活性为代价，换取更强的控制/数据流边界。

一种互补的执行机制是将人类用户置于循环之中。

人类在环钩子。 包括 Codex、Gemini CLI、Cursor 和 OpenHands（Wang et al., 2025a）在内的若干广泛使用的代码智能体，会对破坏性动作或范围外动作设置显式用户批准闸门。三个设计维度塑造了这些钩子：验证范围（哪些动作需要批准）、警报丰富度（用户能看到多少上下文）和复发策略（只允许一次还是始终允许）。Felt 等人（2012）表明，只有 17% 的 Android 用户会在应用安装期间关注权限对话框，且只有 3% 能够正确回答关于已授予权限的理解问题；智能体批准对话框可能面临类似的习惯化和理解风险。频繁请求会导致用户反射性地批准危险动作，而过少请求则会留下覆盖缺口。

一些系统将钩子视为可编程执行基底，而不是孤立分类器。AgentSpec（Wang et al., 2026）在计划、工具调用和响应阶段定义带触发器、谓词和执行动作的规则。AgentDoG（Liu et al., 2026a）则从单动作分类转向轨迹级诊断，并按来源、失败模式和后果来组织风险。

开放挑战。 当前系统中的钩子 API 仍然异质化。我们尚未看到一个被广泛采用的标准，用于为第三方治理模块定义通用钩子接口。钩子还会引入延迟，而堆叠钩子之间的交互效应基本仍未被研究。一个可能的失败模式是：上游净化器改变了下游检测器所依赖的信号，使组合后的流水线比单独考虑任一组件时都更弱。

9.3 组件加固

生命周期钩子在执行框架层执行治理。组件加固则增强单个智能体组件，尤其是 LLM 及其调用的工具，使它们能够抵抗自身特定漏洞。执行框架会从被加固的组件中受益，因为更少恶意输入会首先存活到触发治理钩子的阶段。

模型加固。 提示注入的根本原因之一是，LLM 会以相同优先级处理所有输入文本，使其无法区分系统指令和不可信数据。Wallace 等人（2024）提出了一种指令层级，训练模型优先服从高权限指令（系统提示词），而不是低权限指令（用户消息、工具输出）。模型学习在低层指令与高层约束一致时遵循低层指令，而在二者冲突时忽略或拒绝它们。SecAlign（Chen et al., 2025a）将同一防御目标表述为针对被提示注入的输入、期望响应和不期望响应进行偏好优化。

这些模型层防御与执行框架层钩子互补。被加固的模型会在推理时拒绝更多注入，从而降低下游护栏负载。然而，仅靠模型加固是不够的：它处理的是 Kim 等人分类体系中的错误指令跟随，但不能防止无约束数据流或未授权动作；后两者需要系统级执行（Kim et al., 2026; Wei et al., 2026）。

基于分类器的运行时加固。 另一条互补路线不修改智能体 LLM 本身，而是在运行时部署小型辅助分类器来筛查输入和输出，从而加固模型边界。Llama Guard（Inan et al., 2023）微调了一个独立模型，用于根据可配置安全分类体系对用户提示和助手响应进行分类，并返回每个类别的标签，执行框架可以据此路由到允许、阻止或升级决策。这类分类器提供了训练时加固不具备的两个实践属性：分类体系可以在不重新训练智能体模型的情况下被编辑；同一个检测器可以跨异构 LLM 后端复用。代价是第 9.2 节讨论的延迟预算：每增加一个分类器，就会为每个工具使用周期增加一次前向传播。

模型和分类器防御加固的是 LLM 边界；工具边界则需要自己的协议级处理。

工具加固与 MCP 安全。 Model Context Protocol（MCP）（Anthropic, 2024c）已经成为智能体与工具之间的常见接口，但其初始规范缺少原生安全原语。这一缺口吸引了攻击和防御研究，也促成了官方规范层面的回应。Radosevich 与 Halloran（2025）表明，广泛使用的商业 LLM 可以被诱导使用 MCP 工具来执行恶意代码、建立远程访问并窃取凭证。他们的 McpSafetyScanner 使用三智能体架构（黑客、审计员、监督者）系统性发现这类漏洞。Trail of Bits（Trail of Bits, 2025）表明，MCP 服务器甚至可以在用户调用工具之前攻击客户端，方式是通过有毒工具描述，在注册阶段影响 LLM 行为。

在防御侧，ETDI（Bhatt et al., 2025）使用带加密签名和版本化的工具定义扩展 MCP，确保任何对工具代码、schema 或权限的修改都需要一个新的签名版本。这可以防止“rug-pull”攻击，即一个此前已经被批准的工具被悄悄更新为执行恶意动作。

协议级加固。 除了单个组件之外，SAFEFLOW（Li et al., 2025）为多智能体系统引入协议级执行。它将细粒度信息流控制与事务性执行语义结合起来，因此一条违规工具调用或智能体间消息可以被回滚，而不是继续通过共享状态传播。

供应链风险。 智能体治理还必须处理智能体所调用的工具和包。Spracklen 等人（2025）分析了 16 个 LLM 生成的 576,000 个代码样本，并发现开源模型以 21.7% 的比例幻觉出不存在的包名。攻击者可以在公开仓库中注册这些被幻觉出的名称并注入恶意代码，这种技术被称为“slopsquatting”。ETDI 的加密签名为 MCP 工具解决了该问题的一部分，但包管理器和检索来源仍然处于大多数智能体治理栈之外。

开放挑战。 模型加固和工具加固处理互补的威胁面，但目前没有统一框架将二者连接起来。一个被加固的模型仍然可能调用一个被攻陷的工具，而一个带签名的工具定义也不能阻止被越狱模型对它的误用。如何将这些防御组合成一个连贯栈，并具有可量化的剩余风险，仍是开放问题。随着 MCP 采用率增长，其安全扩展自然会成为标准化目标，但互操作性和认证仍基本未定。

9.4 声明式宪章

将治理逻辑直接嵌入应用代码，会使策略变得不透明、难以审计且难以更新。越来越多执行框架将治理规则外部化为声明式配置文件，最常见的是 YAML 格式。这些文件充当智能体的机器可读宪章。

训练时宪章：Anthropic 的 Constitutional AI。 Anthropic（Anthropic, 2026a）发布了一部按照四层优先级组织的宪章：安全性（保留人类监督）、伦理性（诚实、避免伤害）、合规性（Anthropic 的指南），以及有用性（用户请求）。该宪章区分硬约束与软编码默认值：硬约束包括对化学、生物、放射性和核（CBRN）协助的绝对禁止；软编码默认值则允许操作者在定义好的边界内进行调整。在智能体场景中，这一结构暗示了一种主体层级：Anthropic 的策略优先于操作者配置，而操作者配置又优先于终端用户偏好。

训练时宪章通过在对齐和后训练期间塑造模型行为而起作用。它们在训练时塑造模型行为，但在部署后难以修改，也无法被执行框架独立审计。另一种不同方法是，将治理规则外部化为部署时配置，使执行框架可以读取、验证并执行这些规则。

部署时宪章：基于 YAML 的治理。 AutoHarness 仓库（AIMing Lab, 2026）在 YAML 文件中编码治理规则，其中规定了流水线模式（core、standard 或 enhanced）、风险分类模式、允许和拒绝的工具模式、token 预算限制，以及审计日志目的地。这种声明式风格将治理意图与执行逻辑分离。安全团队和合规官等非开发者利益相关方，可以在不接触智能体代码的情况下审查并修改策略。不同于训练时宪章，YAML 文件可以使用标准工具更新、版本化和查看 diff，从而在不重新训练或重新部署模型的情况下完成策略更新。

这两个层次在操作上不同。训练时宪章修改成本高，并且必须通过行为探针推断；部署时 YAML 则可直接阅读，并可进行 diff 审查。训练时对齐以概率方式塑造默认行为，并可能被对抗性提示覆盖（Andriushchenko et al., 2024）；部署时规则则作为执行框架检查来执行。

当策略可还原为字面触发条件时，基于模式的 YAML 规则就足够了，但真实部署往往需要围绕运行时状态的条件逻辑。当前 YAML schema 并未标准化关于权限升级、基于主机的出站访问、会话级速率限制或未来动作的谓词。在自由形式 YAML 和硬编码规则之间，存在第三种设计点：结构化策略 DSL。

可编程策略语言。 Progent 的策略语言（Shi et al., 2025a）支持布尔谓词、量词和环境引用。它既提供形式表达能力，又保持可读性。Formal-LLM（Li et al., 2024）进一步将计划约束编码为下推自动机。这一形式体系可以表达顺序约束、被禁止的工具组合，以及特定步骤所需的批准闸门。VeriSafeAgent（Lee et al., 2025）将用户意图形式化为一个关于 UI 状态转换的 DSL，用于在执行前验证拟议 GUI 动作是否与用户任务一致。YAML 宪章允许模糊性；形式化规格则要求专业知识。

开放挑战。 目前尚不存在被广泛采用的智能体宪章标准 schema。每个执行框架往往定义自己的 YAML 结构，使策略无法移植。用于验证宪章内部一致性（例如没有矛盾的允许/拒绝规则）和完整性（例如没有未处理的工具类别）的工具，在当前生态中似乎很有限。训练时宪章与部署时宪章之间的交互尤其缺乏研究。YAML 拒绝规则能否可靠覆盖一个 RLHF 已经强化过的行为，以及两层何时会冲突，仍是具有实际安全影响的开放问题。

9.5 审计基础设施

治理需要问责性。审计基础设施记录智能体做了什么、为什么这样做，以及治理策略是否被遵守。这些记录支持事后调查、监管合规和持续策略优化。

结构化审计轨迹。 AutoHarness（AIMing Lab, 2026）会为每次工具调用输出 JSONL 记录，包括工具名称、参数、风险分类、权限决策、执行结果、token 成本和墙钟延迟。这些结构化日志同时支持实时仪表盘和离线取证分析。SAGA（Syros et al., 2025）通过记录智能体之间交换的加密 token，将审计轨迹扩展到多智能体交互，从而支持跨信任边界的来源追踪。跨这些系统来看，一条可重放审计记录至少需要包含 trace 标识符、主体身份、工具调用、策略决策及其版本、执行结果、资源成本，以及覆盖相关输入输出的完整性哈希。当前大多数系统只记录这些字段的子集，很少对记录签名或哈希，因此一旦智能体进程被攻陷，审计轨迹可能遭受日志篡改。

除了记录之外，检测长时间运行智能体中的治理违规还需要自动化分析。

异常检测：逐动作层级与轨迹层级。 检测机制会按照评估证据的粒度而分化。逐动作检测器会根据一种学习得到或指定的风险概念，对每次工具调用进行孤立分类：输入和输出护栏（第 9.2 节）就属于这一机制，而 AgentMonitor（Naihin et al., 2023）提供了一个轻量级记录与标记实现。该机制便宜且易于审计，但无法识别分布在许多单独看似良性的动作之中的攻击，例如每分钟读取一个文件的缓慢外泄。轨迹级检测器则联合评估动作序列。AgentAuditor（Luo et al., 2025）将行为模式匹配与基于 LLM 的完整轨迹推理结合起来。SentinelAgent（He et al., 2025）将多智能体通信建模为时间图，并标记异常交互模式。轨迹级检测能捕获多步攻击，但代价是更高延迟，以及更难定位究竟是哪一个动作触发了告警，这会同时增加实时干预和事后解释的复杂度。在本文所综述的系统中，逐动作检查通常以内联方式部署，而轨迹级分析则异步运行在审计日志之上。

除了安全之外，长时间运行的智能体还需要成本与资源治理。

成本与资源审计。 在循环密集型工作负载中，失控的智能体循环可能很快耗尽 API 预算。2025 OWASP LLM Top 10（OWASP Foundation, 2025）将资源耗尽列为一个独立风险类别。AutoHarness（AIMing Lab, 2026）追踪每次调用的 token 消耗，并通过其宪章以声明方式执行会话级预算。成本感知治理在多智能体架构中尤其重要，因为扇出模式可能以指数方式放大 API 调用。

分层治理流水线。 一种新兴设计模式会将前述机制（权限、钩子、宪章和审计）整合到单一可配置流水线中。AutoHarness（AIMing Lab, 2026）用三个层级体现了这一模式。这些层级逐步增加更深入的检查，从 parse–risk–permission–execute–audit 循环，到上下文增强、输出验证、异常评分、人类升级，以及形式化约束验证。层级通过 YAML 宪章以声明方式选择，因此治理开销会随部署风险扩展。其他生产指南将类似职责暴露为功能级控制，而不是具名层级（Shavit et al., 2023）。哪种抽象更易用仍是一个开放的经验问题。

开放挑战。 审计日志会在长时间运行的智能体中快速积累，从而带来存储、隐私和信噪比方面的挑战。日志可能包含敏感用户数据、API key 或对话内容，这在审计完整性和数据保护要求之间制造张力。社区也缺少标准化审计 schema，使跨系统分析和监管报告变得困难。

9.6 将治理置于智能体安全图景之中

治理机制回应的是一个具体威胁图景。来自开放式智能体到智能体平台的近期证据（Zhang et al., 2026b; Kim et al., 2026; Chen et al., 2026; Wei et al., 2026）进一步表明，智能体安全并不局限于提示注入或单智能体越狱：社会工程、协同智能体集群、凭证泄漏，以及平台级参与度放大，都可能共同塑造威胁图景。Kim 等人（2026）综述了 128 篇论文，并编目了智能体栈中的 51 种攻击方法和 60 种防御方法。Chen 等人（2026）则以软件工程视角补充这一研究，通过六维分类体系综合了 50 篇论文，并提出了面向“安全即构建”的智能体平台参考原则。我们使用这些框架，将治理机制连接到具体安全风险，并识别覆盖缺口。

从设计维度到治理机制。 Kim 等人识别出七个设计维度：输入可信度（Input Trust）、访问敏感度（Access Sensitivity）、工作流（Workflow）、动作（Action）、记忆（Memory）、工具（Tool）和用户界面（User Interface），每个维度都代表一个灵活性谱系。更大的灵活性会扩大攻击面，而治理会在运行时约束这种灵活性。权限模型约束工具与动作；生命周期钩子将检查点注入工作流；宪章外部化约束；审计基础设施则提供反馈循环，用于揭示约束过松还是过紧。表 3 将治理机制映射到 Kim 等人分类体系中的七类风险（R1–R7）。

表 3： 治理机制到 Kim 等人（2026）风险分类体系的映射。

治理机制	缓解或检测的风险
权限模型与身份管理	R1（不可信接口）、R5（数据泄漏）、R6（未授权动作）
输入护栏	R1、R2（错误指令跟随）
输出护栏	R2、R4（幻觉）、R5、R6
信息流控制	R3（无约束数据流）、R5、R6
组件加固	R1、R2、R4
监控与审计	R5、R6、R7（资源耗尽）
人类在环	R2、R6
权限分离	R2、R3
形式化验证	R2、R6
声明式宪章	跨领域：配置上述全部机制

现实智能体中的防御缺口。 Kim 等人对六个智能体系统（Codex、Gemini CLI、OpenHands、Browser Use、Nanobrowser、Skyvern）的案例研究显示，没有任何智能体完整实现了所有防御类别。信息流控制、身份管理和形式化验证在所有被调查系统中都不存在。在全部六个案例中，监控也只是部分实现：智能体会记录工具调用，但缺少自动化异常检测。AutoGPT 案例研究说明了其后果：下游补丁可以解决单个表面症状，却仍然让上游输入验证、信息流控制和策略组合规定不足。

纵深防御及其局限。 Kim 等人认为，智能体安全需要彼此互补的分层防御：输入护栏作为第一道保护，输出护栏作为最后一道防线，信息流控制和监控作为持续运行时保护，访问控制用于认证和授权，人类在环用于关键决策。然而，分层并不是免费的；正如第 9.2 节所讨论的，协调不当的层可能彼此干扰，而独立治理钩子的可组合性基本尚未被测试。在这一框架中，治理可以充当编排层，帮助防御机制相互协作，而不是相互冲突。

作为拟议扩展的上下文安全。 Kim 等人（2026）提出，上下文安全可以作为智能体系统的候选第四安全目标，与经典的机密性—完整性—可用性（CIA）三元组并列。该提议较新，并且特定于他们的综述；它尚未被美国国家标准与技术研究院（NIST）等标准机构或主流安全教材采纳，因此我们在此将其视为一种有用框架，而不是一个已定定义。Conseca（Tsai & Bagdasarian, 2025）和 CaMeL（Debenedetti et al., 2025）展示了这一工程方向：上下文必须被视为受治理的状态，而不是被动的提示材料。它是否应当被提升为独立安全目标，仍未有定论。

9.7 研究方向

表 4 总结了本节讨论的系统在治理方面的状态。

表 4： 治理特性覆盖情况。● = 完整支持，◐ = 部分支持，○ = 缺失。

系统	权限	钩子	加固	宪章	审计	多智能体
Codex	●	◐	○	○	◐	○
Gemini CLI	●	◐	○	○	◐	○
OpenHands	◐	●	○	○	◐	◐
AutoHarness	●	●	◐	●	●	◐
Progent	●	●	○	◐	○	○
CaMeL	◐	●	○	○	○	○
SAGA	●	◐	○	○	●	●
IsolateGPT	●	◐	○	○	○	●
AgentSpec	◐	●	○	●	○	○
SAFEFLOW	◐	●	◐	○	●	●

表 4 中可见的稀疏性表明，除模型局限外，治理基础设施往往也是安全部署的现实瓶颈。我们识别出八个开放研究方向，这里仅限于治理特定缺口，并与第 12 节中更广泛的开放问题相互参照。

（1）标准化策略与审计语言。 每个执行框架都定义自己的 YAML schema 和专有 DSL，导致治理生态碎片化。一个由社区驱动的规范，类似 MCP（Anthropic, 2024c）正在为工具接口所追求的规范，将支持可移植策略、可组合治理模块，以及跨执行框架审计互操作性。

（2）形式化治理保证。 当前治理机制在形式化保证方面仍然有限。智能体行为的形式化验证仍处于早期阶段（Li et al., 2024; Chen et al., 2025b; Lee et al., 2025）。将这些技术扩展到验证治理流水线正确性，例如证明一部宪章内部一致且覆盖所有工具类别，仍然研究不足。

（3）自适应治理。 静态策略无法预见每一种任务上下文。Conseca（Tsai & Bagdasarian, 2025）表明，LLM 生成的策略可以弥补这一缺口。机器生成治理规则的可信性，以及此类策略生成器本身应当如何被治理，仍是开放问题。

（4）面向长周期智能体的治理。 执行多小时或多天任务的智能体会引入上下文漂移、跨会话状态和不断演化的信任假设。许多当前治理流水线是为单轮或短会话智能体设计的。要将其扩展到长周期自主性，就需要治理规则的有效性能够在演化会话中被续期、撤销和审计。

（5）可用的治理界面。 可用的治理界面是部署所必需的。该领域需要关于权限 UI、审计仪表盘和宪章编辑器的人机交互（HCI）研究，使非专业用户也能使用这些界面。关于移动端权限的既有研究表明，批准对话框可能无法很好迁移到智能体设置中（Felt et al., 2012），但仍需要面向智能体的专门研究。

（6）跨层治理一致性。 训练时对齐（constitutional AI）、部署时配置（YAML 宪章）和运行时执行（生命周期钩子）处在不同层级，并具有不同保真度。这些层如何组合，以及运行时治理能否可靠覆盖训练时倾向，仍是开放问题。

（7）端到端供应链治理。 ETDI（Bhatt et al., 2025）等 MCP 安全扩展处理的是单一执行框架内的工具完整性。然而，智能体还依赖外部包、数据集和检索来源，而这些对象的来源很难验证。包幻觉攻击（Spracklen et al., 2025）表明，LLM 可能无意间引入供应链妥协。覆盖完整工具和数据供应链、从包仓库到智能体执行的治理框架，目前仍然有限。

（8）面向治理栈的统一对抗性基准。 现有基准针对狭窄威胁类别，例如提示注入、轨迹诊断或 MCP 服务器漏洞（Debenedetti et al., 2024; Liu et al., 2026a; Radosevich & Halloran, 2025）。没有基准在统一攻击者模型下，以可复现攻击轨迹评估完整治理栈。一个社区基准需要联合报告防御有效性、误报率和开销，而不是将它们孤立报告。

10 跨领域关注点

本节收集的关注点跨越多个 ETCLOVG 层，并通过展示分层推理在何处失效来展开主张 1，即智能体执行框架是一个独立系统层（第 1 节）。各分层章节分别隔离执行、工具、上下文、生命周期、可观测性、评估和治理，使每个设计表面都能被精确描述。然而，生产级执行框架最常失败的地方，是这些表面之间的接口。

层间交互模式。 七个层并不是彼此独立的。执行环境（E）约束哪些生命周期与编排策略（L）是可行的；上下文管理（C）会影响评估可复现性（V）；治理（G）则施加身份、权限和审计约束，而这些约束横跨所有其他层。因此，一个执行框架设计应当被理解为一种依赖结构，而不是一份可分离组件的检查清单。

成本—质量—速度三难困境。 更强的评估（V）、更严格的治理（G）、更丰富的可观测性（O）以及更高保真的执行环境（E），通常都会增加成本和延迟。优化速度往往会降低诊断深度或安全裕度，而优化质量则可能让日常迭代变得过于昂贵。真实系统必须决定哪些检查需要同步执行，哪些检查可以离线运行，以及哪些失败值得触发高成本恢复路径。

标准化与生态系统动态。 MCP、ACP 和 A2A 等协议反映出一种压力：为工具、智能体和编排状态建立共享接口。这种压力有利于面向智能体无关的基础设施，而不是单一智能体集成；但它也将责任转移给治理和可观测性：标准化工具调用只有在周边执行框架能够跨系统保留来源、权限、成本和失败证据时，才是有用的。

持久性生态缺口。 在整个语料库中，五个缺口反复出现在层边界处：跨工具互操作性、成本归因、失败恢复、多仓库编排，以及人类—智能体交接。这些缺口引出了第 11 节的综合分析：核心问题不再是每一层是否都有可用工具，而是组合后的执行框架是否表现为一个可靠的控制系统。

11 跨层综合

本节将第 10 节中的跨领域关注点整合为五个系统级效应，并构成对主张 1（第 1 节）的核心支撑。其目的在于将讨论从组件覆盖转向执行框架行为：一旦执行、工具、上下文、编排、可观测性、评估和治理被组合起来，它们之间的交互就会产生任何单一层都无法独自解决的约束。

11.1 成本—质量—速度三难困境

执行框架可靠性受成本、质量和速度之间三方权衡的约束。更强的沙箱和更高保真的环境可以提升安全性和可复现性，但会增加启动延迟和基础设施成本；更丰富的上下文与记忆策略可以改善任务连续性，但会消耗 token 并引入检索开销；更深入的评估和可观测性可以改进诊断，但会减慢迭代，并增加存储、标注和轨迹处理成本。因此，生产系统不能将质量视为一个标量目标。它们必须决定哪些风险值得使用昂贵控制措施，哪些检查可以异步运行或放在回归套件中，以及在智能体生命周期的每个阶段，哪些遥测信息值得捕获。

11.2 能力—控制权衡

能力更强的执行框架会向智能体暴露更多权限，但权限每增加一次，控制问题也会随之扩大。更大的工具菜单可以拓宽任务覆盖范围，但同时会增加选择错误和提示注入攻击面；持久化记忆有助于长时间运行任务，但会带来来源、陈旧性和隐私风险；宽松的沙箱让自主执行变得有用，但也扩大了错位或被攻陷动作的影响半径。因此，能力—控制权衡并不是附加在一个原本正常运行系统之上的安全补丁。它是一条设计轴线，将工具 schema、上下文策略、运行时权限、身份、可审计性和人类批准连接在一起。

11.3 执行框架耦合问题

执行框架各层之间以某种方式耦合，使局部优化变得脆弱。执行环境会通过影响包可用性、重置语义、延迟和失败模式来改变评估结果；工具描述会消耗上下文预算并塑造模型行为；可观测性轨迹只有在以相同粒度捕获身份和权限状态时，才能成为治理证据；评估设计会通过奖励某些恢复循环、惩罚另一些恢复循环，反向影响编排。这些耦合意味着，执行框架变更应当作为系统变更来测试。一个提示词、工具、记忆、沙箱、验证器或监控器，单独看可能有益，但与控制循环的其余部分组合后，却可能降低整个 rollout 的表现。

耦合问题也解释了为什么在不说明周边控制器的情况下，无法将智能体分数干净地归因于模型。在闭环框架下，对上下文策略、工具 schema、验证器或恢复循环的改变，都会改变控制器 CH，因此也会改变同一个模型被测得的行为（Bölük, 2026b）。

11.4 从智能体框架到智能体平台

生态系统正在从智能体框架走向智能体平台。框架会打包本地抽象，例如智能体、工具、记忆存储和执行循环；平台则加入持久工作区、托管沙箱、身份、计费、可观测性、评估、治理，以及跨多次运行和多用户的人类交接。这个转变之所以重要，是因为长时间运行的智能体不再只是调用模型的程序。它们是需要租户管理、合规、故障恢复、轨迹保留和组织所有权的运维系统。因此，核心设计问题从“我如何构建一个智能体？”转向“我如何运营一组智能体，并让它们的动作在时间中始终可检查、可逆转？”

11.5 开放研究议程

上述综合指向一个以执行框架作为自适应控制系统为中心的研究议程。该领域需要一些基准，它们变化的是执行框架干预，而不仅仅是模型权重；需要轨迹原生的方法，用于跨层归因失败；需要协议来在智能体、工具、沙箱、评估器和人类之间转移状态与责任；也需要随着模型改进而简化执行框架的优化方法。

下一节会将这些跨层效应转化为五个开放问题：如何加固并扩展执行环境，如何维护可靠状态，如何从轨迹中诊断失败，如何标准化交接，以及如何在模型能力变化时保持执行框架有用。

12 开放问题与未来方向

这里收集的开放问题来自约束瓶颈论和跨层综合，并构成对主张 1（第 1 节）的前瞻性证据。与其将七个 ETCLOVG 层视为彼此独立的组件列表，本节追问的是：整个执行框架在哪些方面仍然缺乏科学层面的充分规定。核心模式是，智能体执行框架正在成为长时间运行的控制系统，但该领域在加固执行基底、保存状态、诊断失败、转移责任，以及随着模型能力变化更新执行框架方面，仍然缺少成熟答案。我们将这些缺口组织为五个跨越分类体系的问题。

12.1 加固与扩展执行环境

执行环境正在成为安全性、可扩展性和可移植性交汇的控制边界。SandboxEscapeBench 记录了前沿模型能够在真实配置下利用沙箱弱点（Marchand et al., 2026），但防御工作仍然分散在威胁模型和评估协议各不相同的系统中（Wu et al., 2025; Yan, 2025）。与此同时，每个任务一个容器的模式会对大规模训练和评估造成压力，因为数万条并行轨迹需要廉价的重置和重放；SWE-World 指向了无 Docker 的替代环境，但学习到的状态转移相对于真实执行的保真度仍未解决（Sun et al., 2026）。甚至部署可移植性也不是一个已经解决的工程细节：基于 Docker 的沙箱继承了 Linux 内核假设，而 macOS、Windows、浏览器、桌面和混合云设置则暴露出不同的隔离和可复现性约束。

开放问题是让运行时基底既可测量又可组合。未来的执行框架需要用于提示注入、目标错位和组合式放大的通用安全评估；需要能够决定何时使用容器、microVM、操作系统级权限边界、完整桌面虚拟机、浏览器环境或学习型替代环境的成本模型；还需要能在自托管、云端和混合部署之间保留语义的可移植层。框架集成式运行时（第 3.2.4 节）与沙箱抽象（第 3.2.7 节）之间的打包与组合之分，应当被视为一个经验性设计问题，而不是产品偏好。MCP 等标准可能降低组合成本，但前提是工具、治理和可观测性层暴露足够状态，使运行时选择保持可审计、可恢复和安全。

12.2 维护长时间运行智能体中的可靠状态

最深层的上下文问题，不只是如何把更多 token 放进提示词，而是如何让智能体的工作状态在长周期中与真实任务状态保持一致。长时间运行的代码、研究和运维智能体会反复总结、检索、压缩并外部化信息；每一次这类操作都可能删除约束、扭曲优先级，或保留陈旧假设。近期上下文工程工作将压缩、工具结果清除、检索和提示缓存感知排序视为管理有限上下文窗口的实践机制（Anthropic Applied AI Team, 2025; Anthropic, 2025c; OpenAI, 2026b）。然而，上下文腐化和记忆基准表明，更长输入和更丰富的记忆存储，并不自动意味着更好的任务状态追踪（Hong et al., 2025; Tan et al., 2025; He et al., 2026）。

因此，一个有原则的研究议程，应当将上下文管理重新表述为状态估计。开放问题是：我们是否能够刻画每一次压缩、检索或遗忘步骤中损失了多少与任务相关的信息，以及我们是否能够界定智能体内部状态与任务真实状态之间的偏差边界。近期综述将智能体记忆形式化为一个写入—管理—读取循环，并将策略学习型管理识别为一个新兴机制族（Zhang et al., 2025; Du, 2026）。未来系统需要具备不确定性感知的摘要、被记住事实的来源记录、矛盾处理、显式陈旧性标记，以及恢复流程，使智能体能够从持久工件中重建缺失状态，而不是信任自己的压缩历史。这也意味着记忆与评估之间应建立更紧密联系：记忆策略不应只根据召回准确率来判断，还应根据它们是否能够防止多会话任务中的下游动作错误来判断。

12.3 从智能体轨迹中诊断失败

智能体评估仍然过于经常以最终分数为中心：一次运行通过或失败，然后最终数字被当作关于模型质量的证据。对于执行框架工程而言，这并不充分，因为一次失败 rollout 可能源自模型推理、误导性的工具 schema、沙箱配置错误、陈旧上下文、不稳定测试、基准模糊性、评审器不稳定，或编排循环。Anthropic 对智能体式代码评估的分析显示，基础设施设置会以可测量方式改变基准分数（Anthropic, 2026a），而近期关于智能体评估随机性的工作认为，单次运行通过率可能隐藏显著方差（Bjarnason et al., 2026）。因此，评估层必须被作为一种测量仪器来研究，而不能仅仅被用作排行榜生成器。

下一步是轨迹原生评估：轨迹应成为系统计算结果分数、轨迹质量、失败归因和回归测试的主要对象。可观测性系统已经能够捕获 span、工具调用、成本、重试、异常和中间消息（OpenTelemetry, 2026; AlSayyad et al., 2026; Koc et al., 2025），但这些轨迹往往与评估流水线脱节。LangChain 2026 年调查报告称，89% 的团队使用可观测性，而只有 52.4% 运行离线评估（LangChain, 2026a）；这一缺口意味着团队可以看到智能体做了什么，却没有系统性判断其行为是否正确。未来工作应通过将异常生产轨迹转化为回归用例、直接在 span 上计算轨迹指标，并将诊断信号反馈到提示词、工具、上下文和编排变更中，来闭合这一循环。Reflexion 已经表明，智能体可以在短周期场景中从自己的轨迹中学习（Shinn et al., 2023）；将这一思想扩展到长时间运行、多会话执行框架，仍然是开放问题。

12.4 智能体、工具与人类之间的标准交接

现代执行框架越来越多地将工作分布在规划器、子智能体、工具、沙箱、评估器和人类之间，但这些参与者之间的接口仍然是临时性的。局部标准正在出现：MCP 标准化工具访问，A2A 面向智能体间通信，OpenTelemetry 则为轨迹提供通用基底（Model Context Protocol, 2025b; A2A Project, 2025; OpenTelemetry, 2026; Ehtesham et al., 2025）。缺失的是一种跨层交接契约。当规划器将工作交给执行器、智能体调用工具、子智能体交回控制权，或系统升级到人类处理时，交接不应只传递文本摘要，还应传递意图、约束、权限、工件、来源、预算状态、风险等级、轨迹历史和未解决决策。

这个问题部分是技术性的，部分是制度性的。OpenAI 的 Symphony 将 issue tracker 和仓库视为智能体工作的控制平面，而 Anthropic 的长时间运行智能体执行框架强调持久化进展工件和干净的交接状态（Kotliarskyi et al., 2026; Anthropic, 2025d; 2026b）。治理工作从相反方向得出了同样结论：在智能体能够跨系统安全地代表用户行动之前，需要智能体身份、委托、权限清单和可审计性（South et al., 2025; Marro et al., 2025; Syros et al., 2025）。开放问题是定义既足够丰富以支持安全和恢复，又足够简单以支持广泛采用的交接协议。这样的协议应当使责任显式化：谁授权了该动作，哪些状态被转移，哪些证据支持当前计划，接收方被允许做什么，以及何时必须将控制权交还给另一个智能体或人类。

12.5 随着模型改进，保持执行框架的有用性

不应假设执行框架设计会单调地走向更多脚手架。每一个包装器、重置、验证器、规划器、记忆规则和权限闸门，都编码了一个关于模型无法独立可靠完成什么的假设。随着模型能力变化，执行框架干预应当被重新估计，而不是被假设为仍然有益。一个模型 × 执行框架的因子式评估，可以揭示某个干预何时能改进所有模型、何时只帮助特定模型家族，或何时会反转模型排名（Bölük, 2026b）。Anthropic 在长时间运行应用开发中报告了这一模式的一个具体版本：对某个模型有用的上下文重置，对更强模型而言变得可以省去；移除它们降低了成本，同时没有降低质量（Anthropic, 2026c）。OpenAI 也同样将执行框架工程界定为一门让人类注意力、仓库状态和智能体执行保持对齐的学科，而不仅仅是添加更多脚手架（OpenAI, 2026a; b）。

这创造了一个元工程议程：执行框架需要用于优化和简化自身的机制。Meta-Harness 表明，提示词、工具和控制循环可以作为优化目标的一部分被搜索，而不是只能由人工固定（Lee et al., 2026）；Natural-Language Agent Harnesses 则使执行框架模块显式化并可被消融（Pan et al., 2026）。TensorZero、Axon 和 AgentOps 等生产级可观测性与成本系统，指向了预算感知的执行框架运行方式（TensorZero, 2026; harshkedia177, 2026; AgentOps AI, 2026），但研究问题比成本最小化更广。未来系统应识别哪些干预对质量、安全性或可靠性具有因果作用；跨执行框架变体运行 shadow-mode 或 A/B 测试；并在质量—延迟—成本—风险联合约束下进行优化。一个核心风险是基准过拟合：如果一个执行框架只针对狭窄评估套件优化自身，它可能变得脆弱。更持久的目标是自适应简化，也就是执行框架持续追问：随着任务、工具和模型能力变化，哪些控制仍然是必要的。

13 结论

本文将智能体执行框架视为一个独立工程表面，并认为设定现实世界智能体可靠性上限的，是基础设施质量，而不只是模型能力。围绕这一约束瓶颈论，我们提出了三个主张。七层 ETCLOVG 分类体系将可观测性和治理从生命周期钩子中分离出来，并反映了生产团队已经如何组织其工具和所有权。将 148 多个开源项目映射到该分类体系，给出了迄今最广泛的生态系统快照，并呈现出采用模式、覆盖空白和新兴设计原则。从提示词到上下文再到执行框架工程的三阶段工程演进，连同覆盖成本—质量—速度三难困境、能力—控制权衡和执行框架耦合问题的跨层综合，将执行框架置于更广泛的工程轨迹之中。我们的分析也存在局限。语料库偏向英语、GitHub 可见、开源项目，并偏向代码智能体生态；将其扩展到闭源生产系统和非代码智能体生态，将使经验图景更加清晰。该分类体系本身是描述性的：将 ETCLOVG 转化为一个能够指导执行框架设计决策、而不只是进行分类的规范性框架，是我们希望本文能够鼓励的自然下一步。