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）智能体在生产环境中的快速部署揭示了一个反复出现的规律：任务执行的可靠性在很大程度上并不取决于底层模型本身，而是取决于对模型进行封装的基础设施层，即智能体执行 harness（agent execution harness）。本综述以实践为导向，对智能体 harness 工程进行了系统性梳理，全文围绕三个核心论断展开。第一，智能体 harness 是一个独立的系统层，其工程质量在很大程度上决定了现实世界的可靠性；本文通过提示工程到上下文工程再到 harness 工程的三阶段演化历程阐明这一观点，并在跨层综合分析中涵盖成本—质量—速度三难权衡（trilemma）、能力—控制权衡（capability–control tradeoff）以及 harness 耦合问题，同时给出根植于研究空白与生产痛点的开放问题议程。第二，本文提出 ETCLOVG 七层分类法，涵盖执行环境（Execution environment）、工具接口（Tool interface）、上下文管理（Context management）、生命周期/编排（Lifecycle/Orchestration）、可观测性（Observability）、验证（Verification）、治理（Governance）七个层次，相较于已有的六组件框架，本分类法将可观测性与治理作为独立的架构关注点加以处理。第三，本文将 170 余个开源项目映射至该分类法，以揭示生态系统规律、覆盖空白及新兴设计原则，并结合来自 OpenAI、Anthropic 和 LangChain 生产部署的工程原则，弥合从业者知识与研究词汇之间的鸿沟。
图 1：提示工程、上下文工程与 harness 工程的简要对比（原文图见 PDF 第 1 页）
目录
- 1 引言
- 1.1 约束瓶颈：harness 优先于模型
- 1.2 从业者与研究界的鸿沟
- 1.3 范围与贡献
- 2 背景与分类
- 2.1 智能体系统的演化
- 2.2 三个工程阶段
- 2.3 ETCLOVG 七层分类法
- 2.4 范围界定
- 2.5 项目收集流程
- 2.6 纳入与排除标准
- 2.7 编码规范
- 2.8 语料库局限性
- 2.9 聚合分析
- 3 执行环境与沙箱（E）
- 3.1 范围与概念
- 3.2 智能体沙箱的类别
- 3.3 威胁模型与沙箱逃逸
- 3.4 部署模式
- 3.5 小结
- 4 工具接口与协议层（T）
- 4.1 协议与接口标准
- 4.2 工具描述、发现与选择
- 4.3 工具增强训练与集成
- 4.4 可扩展性与会话管理
- 5 上下文与记忆管理（C）
- 5.1 为何必须对上下文进行工程化
- 5.2 从提示工程到上下文工程
- 5.3 短期：管理活跃上下文窗口
- 5.4 中期：会话状态与跨轮次持久化
- 5.5 长期：持久记忆系统
- 5.6 长时程技术：保持智能体在 100+ 轮次中的连贯性
- 5.7 上下文漂移与当前方法的局限
- 6 生命周期与编排（L）
- 6.1 生命周期状态管理
- 6.2 单智能体内循环
- 6.3 多智能体编排模式
- 6.4 从问题到拉取请求的完整生命周期流水线
- 7 可观测性与运营（O）
- 7.1 追踪与监控平台
- 7.2 智能体专用运营平台
- 7.3 成本追踪与优化
- 7.4 可靠性工程
- 7.5 讨论：走向统一可观测性
- 8 验证与评估（V）
- 8.1 将 harness 评估视为任务到反馈的生命周期
- 8.2 阶段一：任务与基准定基
- 8.3 阶段二：执行前就绪性验证
- 8.4 阶段三：受控执行与追踪捕获
- 8.5 阶段四：多层次判断与失败归因
- 8.6 阶段五：持续回归与部署反馈
- 8.7 小结
- 9 治理与安全（G）
- 9.1 权限模型与身份管理
- 9.2 生命周期钩子
- 9.3 组件加固
- 9.4 声明式章程
- 9.5 审计基础设施
- 9.6 智能体安全格局中的治理定位
- 9.7 研究方向
- 10 跨层横切关注点
- 11 跨层综合
- 11.1 成本—质量—速度三难权衡
- 11.2 能力—控制权衡
- 11.3 harness 耦合问题
- 11.4 从智能体框架到智能体平台
- 11.5 开放研究议程
- 12 开放问题与未来方向
- 12.1 加固与扩展执行环境
- 12.2 在长期运行智能体中维护可靠状态
- 12.3 从智能体追踪中诊断故障
- 12.4 跨智能体、工具与人类的标准交接
- 12.5 随模型改进保持 harness 的实用性
- 13 结论
1 引言
1.1 约束瓶颈（binding constraint）：harness 优先于模型
基于大语言模型（LLM）的智能体学术研究，从整体上看一直是对模型本身的研究。研究议程围绕模型能做什么展开：能否跨多个步骤进行规划、可靠地调用工具、检索并压缩相关记忆，或与其他智能体协调。其隐含假设是，智能体的能力主要是模型能力的函数——一个足够强大的模型配合足够好的提示就能产生足够可靠的行为。
然而，近期的实证证据对”更好的模型单独能产出更可靠的智能体”这一假设提出了挑战。以下三项最新研究树立了这一规律：Bölük (2026a) 仅修改了编辑工具格式及其周边工具 harness，未作任何模型改动，便在 15 个模型上的代码基准测试中报告了高达 10 倍的性能提升；Trivedy (2026) 仅通过系统提示重构、中间件上下文注入和自验证钩子，将固定的 GPT-5.2-Codex 智能体在 Terminal-Bench 2.0 上的得分从 52.8% 提升至 66.5%，实现了 13.7 个百分点的提升，完全来自基础设施改动；Meta-Harness (Lee et al., 2026) 通过自动化 harness 优化在 Terminal-Bench-2 上达到 76.4%，在不修改模型权重的情况下超越了所有人工设计方案。在这三个案例中，变量均是执行 harness（execution harness，即负责管理上下文构建、工具交互、编排、反馈与执行约束的基础设施层）；模型保持固定。这些仅靠 harness 获得的提升幅度，每次都超过了同一基准上”有意义的模型进步”所对应的典型 2 至 4 个百分点的提升。这一规律并非偶然：驱动结果的是 harness，而非模型。
我们将这一规律称为约束瓶颈论题（binding-constraint thesis，Bölük, 2026b）：对于在可比前沿模型上评估的长时程任务，基准测试的方差可能在很大程度上由执行 harness 驱动，其影响不亚于模型本身。我们以此论题作为本综述其余部分的分析框架。
§2 中的图 3 从历史维度呈现了同样的转变：早期系统将能力集中于单一的模型循环，而后来的系统则越来越多地将可靠性视为一个跨层基础设施问题。
1.2 从业者与研究界的鸿沟
从业者的紧迫性与研究界的词汇之间存在张力。OpenAI 明确将”harness 工程”定义为一门学科，专门用于设计 Codex 智能体的环境、约束、文档和反馈循环，并于 2026 年 2 月报告，一支小型团队在五个月内无需手动编写生产代码便完成了约百万行代码的内部产品 (OpenAI, 2026a)。Anthropic 的智能体工程博文从相邻方向得出了相同原则：有效的智能体应使用简单且可检查的架构；工具接口应为智能体使用而设计，而非照搬面向人类的 API；上下文应逐步披露而非急于全部加载；长期运行的工作需要持久的交接制品和可恢复的执行基础设施 (Anthropic, 2024a; Aizawa, 2025; Anthropic Applied AI Team, 2025; Anthropic, 2025d; 2026b)。Martin Fowler 网站上的一篇文章将 harness 工程表征为 AI 智能体的”控制论调速器（cybernetic governors）”，由前馈引导、反馈传感器构成围绕大语言模型（LLM）的控制回路 (Böckeler, 2026)。
与此同时，研究界对智能体系统各组件的研究日益精细：记忆、工具使用、规划与安全。然而，将这些组件整合为可靠运行的系统本身，却尚未得到系统性研究。由此产生了一个从业者—研究界的鸿沟：从业者知道 harness 基础设施至关重要，却缺乏形式化词汇来描述”为何如此”，进而无法实现系统性改进。本综述旨在弥合这一鸿沟。
1.3 范围与贡献
本综述聚焦于封装语言模型、管理长期运行多步骤任务执行的基础设施层。我们不将智能体框架作为开发工具、智能体平台作为产品类别或模型能力本身纳入调查范围，尽管三者均对本文分析有所启发。图 4 总结了构建本综述其余内容的七层分类法。
我们的贡献围绕三个论断组织：
论断一（概念层面）：基于约束瓶颈论题 (Bölük, 2026b)，我们主张 harness 而非单独的模型才是现实世界智能体可靠性的约束瓶颈。 三项最新结果表明，仅靠 harness 即可在代码基准上实现高达 10 倍的提升、在 Terminal-Bench-2 上实现 +13.7 个百分点以及在 Terminal-Bench-2 上达到 76.4%（§1），每项均超过同一基准上典型的模型驱动提升。我们通过三阶段工程演化（§2）推导此论题，并在跨层综合中涵盖成本—质量—速度三难权衡（trilemma）、能力—控制权衡以及 harness 耦合问题（§11），同时给出开放问题议程（§12）。
论断二（分类层面）：ETCLOVG 七层分类法将可观测性与治理作为一级层次，而非生命周期钩子的副产品。 二者各自拥有独立的生产工具栈——可观测性侧有 Langfuse、OpenTelemetry；治理侧有权限引擎、网关和审计流水线——并在生产部署中由不同团队负责。我们同样将状态管理置于生命周期与编排层内，因为状态与读写它的执行流程紧密共存（§2.3）。
论断三（实证层面）：将 148 余个开源项目映射至 ETCLOVG，揭示了生态系统在哪些方面稠密、哪些方面稀疏，以及早期语料库遗漏了哪些类别。 此映射是迄今规模最大的开源智能体 harness 语料库。执行、工具、生命周期和验证层覆盖密集；可观测性与治理层较为稀疏，且更多地存在于商业平台中；三类在早期语料库中缺席的项目——任务运行器、多智能体编排器以及规格驱动的开发工具——现已成为一级类别。方法论小节（§2.4–§2.9，附录 A）使编码可复现，映射结果支撑了§3–§9 中各层的观察。
2 背景与分类
2.1 智能体系统的演化
从早期的思维链（chain-of-thought）提示到自主智能体，这一轨迹可理解为从业者必须管理的工程表面的持续扩张。
ReAct 时代（2022—2023）。 Yao et al. (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、ChatGPT、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)。
harness 转折点（2025—2026）。 到 2025 年，生产部署经验已积累到足以明确表明：智能体可靠性的约束瓶颈是基础设施质量，而非模型质量。2026 年初有三项独立进展验证了这一判断：OpenAI 明确采纳”harness 工程”作为一门学科；Stanford/MIT 的 Meta-Harness 表明自动化 harness 优化超越人工设计；LangChain 的 DeepAgents 在 Terminal-Bench 2.0 上将得分从 52.8% 提升至 66.5%，对应 13.7 个百分点的提升和约 26% 的相对改进，仅通过 harness 层改动实现 (OpenAI, 2026a; Lee et al., 2026; Trivedy, 2026)。
2.2 三个工程阶段
2022—2026 年揭示了该领域在工程重心上的一个连贯的三阶段演化。
提示工程（2022—2024）。 主要杠杆是输入提示文本。从业者通过精心设计指令、少样本示例和推理模板进行优化。工程范围较窄：优化单个文本输入对应单次模型调用。
上下文工程（2025）。 随着智能体运行时间的延长，约束瓶颈从”输入什么”转变为”每一步模型应该看到什么信息”。这一阶段聚焦于上下文管理：每轮注入什么、如何检索和压缩记忆、如何按相关性对工具结果排序、如何处理上下文窗口饱和。范围从单一输入扩展为流入上下文窗口的多路信息流 (Anthropic Applied AI Team, 2025)。
harness 工程（2026）。 随着模型能力足以处理长期运行任务，可靠性越来越依赖于维护状态、协调工具、注入反馈、施加约束并验证进度的基础设施封装层。这一观察与约束瓶颈论点相契合：长时程智能体的性能由模型—harness 耦合系统共同产生，而非仅由模型本身决定 (Bölük, 2026b)。因此，harness 工程需要追问：为使智能体系统可靠，需要设计哪些治理机制、约束、反馈循环和执行控制。在本分类法中，这一阶段将 ETCLOVG 七层视为一个集成整体 (OpenAI, 2026a; Böckeler, 2026; LangChain, 2026b)。
每个阶段都涵盖前一阶段：harness 工程包含上下文工程，上下文工程包含提示工程。三个阶段在时间和概念上均有重叠，而非截然替代。提示工程至今仍是 harness 实践的活跃组成部分，上下文工程也在与本文所综述的 harness 层关注点并行成熟中持续演进。因此，我们的分期应理解为增量工程投入重心的转移，而非一系列替代关系。
图 2：基于大语言模型（LLM）的智能体系统 harness 工程分类法示意图。E、T、C、L 四层构成系统的结构支柱。O 层提供全系统监控，V 层对各组件进行评估并反馈，G 层在整个系统上施加治理与安全约束。色彩方案对应§2.3 中展开的 ETCLOVG 各层（原文图见 PDF 第 6 页）
图 3：2022—2026 年代表性智能体 harness 系统时间线。该时间线呈现了从早期单循环智能体到覆盖执行环境、工具接口、上下文与记忆管理、生命周期编排、可观测性、验证和治理的丰富 harness 基础设施的演变历程。色彩方案对应§2.3 中展开的 ETCLOVG 各层（原文图见 PDF 第 7 页）
2.3 ETCLOVG 七层分类法
我们提出一套用于智能体 harness 工程的七层分类法，以首字母缩写 ETCLOVG 命名，代表 Execution, Tooling, Context, Lifecycle, Observability, Verification, Governance（执行环境、工具接口、上下文管理、生命周期/编排、可观测性、验证、治理）。图 4 给出了简洁的视觉导图；本小节确立贯穿全文的解释框架。
前四层描述 harness 的结构核心。执行环境（Execution，E） 决定智能体代码在何处运行以及何种沙箱（sandbox）约束对其生效；工具接口（Tooling，T） 规定外部能力如何被描述、发现和调用；上下文管理（Context，C） 控制模型在短期、会话级和持久时程上所能看到的内容；生命周期/编排（Lifecycle，L） 组织读写上述状态的控制流，从单智能体循环到多智能体工作流（workflow）乃至问题到拉取请求的完整流水线。其余三层描述围绕这一核心的控制平面。可观测性（Observability，O） 捕获追踪、成本、故障和可靠性信号；验证（Verification，V） 将任务与追踪转化为评估、失败归因和回归反馈；治理（Governance，G） 通过权限机制、身份认证、策略执行、加固、审计和人工监督手段约束智能体行为。§3–§9 依次展开七层内容，§10–§12 则综合分析不属于任何单一层次的跨层权衡与开放问题。
本分类法有两处设计选择值得特别说明。其一，我们将可观测性（O） 提升为独立层，而非作为生命周期钩子的副作用处理。在生产系统中，可观测性拥有专属的工具生态（Langfuse、Arize Phoenix、OpenLLMetry）和独特的工程实践（OpenTelemetry 插桩、成本归因、异常检测），足以单独处理。其二，我们引入治理（G） 作为独立的一级层，以捕获安全与合规关注点的完整谱系，涵盖三个子层：模型级（护栏、内容过滤器）、系统级（网关、代理、权限模型）和组织级（审计、合规、人在回路监督）。
图 4：智能体 harness 工程分类法详情。每个分支对应一个 ETCLOVG 层及其主要子类别；代表性系统与论文将在后续各节讨论（原文图见 PDF 第 8 页）
状态管理天然归属于生命周期与编排层（L），与执行流的读写操作并列；生命周期钩子和策略执行则归属于治理层（G），与其他约束机制对齐。
2.4 范围
本文以比”LLM 周边软件”更窄的含义使用 agent harness 一词：harness 是将模型调用转化为有界、有状态、工具中介式任务执行的工程化包装层，其手段包括执行基底、工具接口、上下文控制、编排（orchestration）、可观测性、评估反馈和治理约束 (OpenAI, 2026a; Anthropic, 2025d; LangChain, 2026b)。分析单元因此是使长周期智能体（agent）行为可控、可观测、可恢复的基础设施，而非基础模型或提示词本身。我们从功能而非产品类别来划定边界：一个智能体框架若暴露了有状态编排、工具路由、运行时策略钩子或追踪捕获等可复用机制，则纳入范围；而精简的 API 包装器、提示词库、静态数据集、通用容器运行时、向量数据库、APM 面板或内容过滤器，除非经过明确适配以服务于智能体执行、状态、评估或工具使用治理，否则均不在范围之内。
2.5 项目集构建流程
我们以系统化映射公开记录的 agent harness 制品为目标构建项目集（corpus），借鉴系统综述的报告规范，使数据来源、检索策略与筛选过程透明可溯 (Page et al., 2021)。如图 5 所示，候选项目从四路来源汇集：此前的综述与基准论文、可复现的 GitHub 搜索（覆盖名称、描述、README 文本、主题、星数、时效性和归档状态）、精选项目列表与包注册表，以及引入 harness 层机制的公司工程博客或发布说明 (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 月 8 日。
图 5：项目集构建流程。候选制品从 GitHub、论文、精选列表、包注册表及公司工程来源汇集，经去重后对照纳入标准（inclusion criteria）进行检验，再映射至 ETCLOVG 各层，证据来源均为公开文档。（原文图见 PDF 第 9 页）
2.6 纳入与排除标准
满足以下三个条件的项目方可纳入：公开记录、实现或规定了具体的 harness 层机制、且现有证据足以为其分配至少一个 ETCLOVG 层。符合条件的包括：具备可复用编排或工具路由逻辑的智能体框架、实例化可执行智能体环境的基准、为智能体执行打包的沙箱（sandbox），以及在智能体状态、追踪、动作或策略之上运行的记忆、可观测性、评估或治理系统。排除对象包括：简单的聊天机器人演示、提示词包、薄层模型客户端包装器、无智能体运行时的静态数据集或排行榜、并非面向智能体的通用基础设施组件、公开文档中无法检验其技术行为的产品页面。边界情形以机制而非标签为准：仅命名为”agent”的代码仓库不足以纳入，而提供了可复用 harness 机制的评估项目或沙箱项目则予以纳入。
2.7 编码协议
每个保留项目均依据七个 ETCLOVG 层进行编码，证据来源为制品本身：README 文件、文档页面、论文、示例、发布说明，必要时辅以代码仓库结构。编码采用多标签方式，因为许多系统横跨多个层；主层标记对该制品最核心的机制，次层仅在文档将其作为独立能力而非附带依赖加以阐述时才予以赋予。当前快照采用单一主编码员加作者审核的协议，而非正式的多编码员一致性研究，因此不报告 Cohen’s kappa 或类似的标注间一致性统计量。全部编码完成后，对歧义情形进行回溯复核，遵循保守规则：若公开证据未能清晰呈现面向智能体的机制，则层标记予以保留。
2.8 项目集的局限性
本项目集应被理解为可见的 agent harness 生态系统的映射，而非所有已部署智能体基础设施的普查。它偏向英语来源、GitHub 可见项目、开源制品，以及维护者发布了足够实现细节以供外部编码的系统。商业生产系统若无工程博客、文档或 SDK 披露相关机制，则代表性不足；编码智能体基础设施因拥有异常丰富的公开追踪（代码仓库、基准、沙箱、issue 到 pull request 的工作流（workflow）、发布说明）而代表性过高。层标记同样反映公开文档而非私有架构，因此某层缺失意味着”未见公开证据”而非”未曾实现”。
2.9 总体分析
170+ 项目的映射揭示了一个宽广但不均衡的生态系统。执行环境（E）、工具接口（T）、生命周期/编排（L）和验证（V）四层的可见覆盖度最高，因为编码、Web、终端和计算机使用智能体都需要可运行的环境、工具契约、控制循环以及在部署（deployment）前可重复的评估。上下文管理（C）和记忆机制广泛出现于多个项目，但往往内嵌于更大的框架中，而非作为独立 harness 组件发布。可观测性（O）和治理（G）在开源覆盖上较为稀薄，更多通过商业平台、SDK 功能或工程写作呈现，表明运营控制的成熟时间晚于运行时和基准基础设施。跨层项目日益普遍：最完整的系统将沙箱、工具协议、编排、追踪、评估与权限控制融为一体，这支持了本综述的核心主张：harness 工程（harness engineering）是一个集成系统问题，而非孤立插件的集合。
3 执行环境与沙箱（E）
我们以执行环境与沙箱（E）层开启逐层讨论，这是 ETCLOVG 七大支柱中的第一柱（§1 中的主张 2）。本章讨论的系统均来自支撑主张 3 的 170+ 项目集。
图 6：面向大语言模型（LLM）智能体的执行环境与沙箱代表性工作，按本章沙箱分类组织。（原文图见 PDF 第 11 页）
3.1 范围与概念
3.1.1 定义
智能体的执行环境（execution environment）是指智能体动作被实际执行所在的基础设施层。在 LLM 智能体的语境下，执行环境与沙箱（sandbox）是紧密耦合的概念。因此，生产级智能体系统几乎无一例外地在沙箱化环境中执行动作。
3.1.2 为什么沙箱化在智能体时代至关重要
智能体时代的沙箱化（sandboxing）并非单纯继承自传统多租户代码执行的安全措施，它同时服务于三个截然不同的目的，三者的结合正是沙箱化从操作细节跃升为 agent harness 设计中一等关切的根本原因。
第一个目的是安全性（security）。 智能体沙箱化面临超越传统多租户代码执行的挑战：LLM 生成的代码既不可审计，也无法大规模预测，静态审查作为主要防御手段因此失效。智能体跨多个步骤自主执行，动作执行时无法获得人工干预。提示注入攻击（prompt injection attacks）可将原本无害的智能体重定向为沙箱定向攻击的载体，模糊了可信用户意图与恶意输入之间的边界。关于沙箱逃逸（sandbox escape）的近期实证研究表明，上述顾虑并非假想，我们将在 §3.3 给出量化证据。
第二个目的是可复现性（reproducibility）。 长周期智能体任务及衡量其表现的评估 harness（§8）需要能够将执行状态重置到已知基线。Docker 容器或 microVM 可按需销毁和重建，而开发者工作站则无此特性；正是这一属性使 SWE-bench (Jimenez et al., 2024) 和 OSWorld (Xie et al., 2024) 等基于沙箱的评估标准具有实践可行性。在训练时，当单个任务需在并行轨迹上重放数百次时，廉价重置机制的缺失本身就成为可扩展性瓶颈。
第三个目的是活性（liveness），这是智能体时代最具独特性的需求。 若无沙箱，智能体每次希望执行的潜在高风险动作——例如文件写入、包安装或出站网络调用——都必须经由显式权限提示交由人工审批。在规模化场景下，这导致两种失效模式：用户因不堪其扰而放弃智能体，或反射性地批准一切，从而瓦解提示的安全意图。沙箱通过定义一个智能体被授权自由行动的有界区域来打破这一僵局，将权限从逐次动作询问转变为会话级配置。Anthropic 报告称，为 Claude Code 引入沙箱化后权限提示减少了 84%，同时保持了安全性 (Anthropic, 2025b)。在这一框架下，沙箱既是笼（cage），也是许可证（license），而许可证属性正是使自主长周期执行成为可能的根本所在。
在上述三个目的中，安全性与传统沙箱化共享，可复现性在智能体场景中得到放大，活性则本质上是全新需求。三者的结合是将智能体沙箱化作为独立研究对象而非容器技术下游应用加以处理的正当理由。
3.2 智能体沙箱的分类
智能体沙箱基础设施在 2024 年至 2026 年间从少数通用运行时演变为多个独立产品类别，每类均针对不同智能体任务类型加以优化。我们沿工作负载与使用场景（workload and use case）轴将这一格局组织为七个类别，认为这对 harness 设计者在系统间做选择最具参考价值。正交轴为隔离技术（isolation technology），包括容器、用户态内核（如 gVisor (Google, 2018)）、microVM（如 Firecracker (Agache et al., 2020) 和 Kata Containers (Kata Containers Project, 2017)）、WebAssembly，以及 OS 层原语（如 bubblewrap 和 Scaltbelt）；隔离原语作为各子节内部的设计属性进行讨论，而非作为顶层类别，因为同一隔离原语会跨不同工作负载复用。七个类别为：通用托管沙箱（§3.2.1）、计算机使用智能体基础设施（§3.2.2）、代码专用沙箱（§3.2.3）、框架集成运行时（§3.2.4）、浏览器评估环境（§3.2.5）、OS 层权限沙箱（§3.2.6）和沙箱抽象层（§3.2.7）。以下各子节逐一介绍。
3.2.1 通用托管沙箱
通用托管沙箱提供商业或开源的沙箱即服务（sandbox-as-a-service）平台，通过 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) 的平台；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 独特地允许用户在多个后端之间选择工作负载，体现了业界对单一隔离原语无法适配所有威胁模型（threat model）这一认识的接受。我们观察到一个更宏观的趋势：从内核共享容器隔离转向专用内核 microVM 隔离，驱动力在于 LLM 生成代码具有无法提前描述的不可预测系统调用模式。
3.2.2 计算机使用智能体基础设施
计算机使用智能体基础设施代表一种独特的执行模型：智能体通过模拟鼠标、键盘和屏幕观察与图形界面交互，而非通过 API 或 shell 命令。代表性系统包括：Anthropic 的 Computer Use (Anthropic, 2024b)，支持 Claude 直接操作桌面环境的旗舰商业实现；CUA (Cua, 2024)，一个开源计算机使用智能体基础设施；以及 OSWorld (Xie et al., 2024) 提供的基于 VM 的环境，同时兼任评估 harness（§8）和参考计算机使用沙箱的双重角色。
这些系统在沙箱内打包完整或近完整的桌面环境（通常通过 Xvfb 加窗口管理器或完整 VM 实现），并向智能体暴露像素坐标和按键动作。与基于 API 的类别相比，动作空间大幅扩展，但可靠性依赖于视觉定位，且完整的 OS 攻击面需要更强的隔离，通常采用 microVM 或完整 VM。与 §3.2.1 的托管沙箱相比，计算机使用沙箱在密度和启动延迟之间进行了折中以换取保真度：完整桌面环境启动更重、多路复用更难，但这是智能体能够操作不暴露任何 API 的应用程序的唯一执行模型。
3.2.3 代码专用沙箱
代码专用沙箱是针对代码生成、评估和数据分析而非通用文件系统访问优化的轻量级环境。代表性系统包括：Judge0 (Došilović, 2024)，最初为判题而设计、在编码智能体评估管线中被广泛复用的代码评估沙箱；OpenAI Code Interpreter (OpenAI, 2023)，ChatGPT 高级数据分析功能底层的生产级沙箱化 Python 环境；sandboxed.sh (Th0rgal, 2026)，面向编码智能体的 shell 沙箱；以及 langchain-sandbox (LangChain, 2025c)，使用 Pyodide (Pyodide Contributors, 2018) 编译为 WebAssembly 并在 Deno 运行时执行，在本地无容器地沙箱化智能体生成的 Python——这一设计同样被 NVIDIA 用于客户端智能体工作流 (NVIDIA, 2024)。
与 §3.2.1 的通用沙箱不同，这些系统预装编译器和解释器、默认采用无状态请求级执行，并针对高并发并行性进行优化。设计取舍牺牲工作负载通用性以换取启动速度、评估吞吐量和更简单的威胁模型。一个值得关注的子趋势是从基于容器的代码沙箱向基于 WebAssembly 的沙箱转变：WebAssembly 提供能力安全性（capability-based security）、确定性执行和微秒级实例化，代价是 Python 标准库受限和原生扩展支持削减。
3.2.4 框架集成运行时
框架集成运行时是捆绑在更大智能体框架内部、而非作为独立沙箱产品暴露的执行环境，与框架的编排循环、工具注册表和提示约定协同发布，不采用外围框架则无法独立使用。代表性系统包括：OpenHands 运行时 (Wang et al., 2025b)，一个将 bash、IPython、Chromium 浏览器和 API 服务器集成到单一镜像的 Docker 沙箱化环境；agent infra sandbox (Agent Infra, 2024)，将浏览器、shell、文件系统、MCP 和 VSCode 打包为一体的显式一体化设计；以及 smolagents 的执行器层 (Roucher et al., 2025)，在框架实现中提供 local、Docker、E2B、Modal 和 WebAssembly 执行的统一接口。
该类别的核心权衡在于捆绑（bundle）与组合（compose）之间：框架集成运行时优先提供开箱即用的能力覆盖，代价是镜像体积更大、启动更慢、与框架抽象紧耦合。相反，§3.2.1 的通用沙箱采取最小环境加外部抽象组合的对立路径。组合路径能否在长远中取代捆绑运行时，取决于 MCP 等标准能否降低在运行时而非构建时组装能力的代价。
3.2.5 浏览器评估环境
浏览器评估环境同时承担沙箱和评估 harness 的双重角色。代表性系统包括：WebArena (Zhou et al., 2024)，配套 Playwright 浏览器控制的自托管真实网页应用集群；VisualWebArena (Koh et al., 2024)，以多模态视觉定位任务扩展 WebArena；以及 BrowserGym (Chezelles et al., 2024)，与 WorkArena (Drouin et al., 2024) 共同为基于浏览器的智能体执行和基准测试提供标准化的 gym 风格接口。
这些系统提供隔离的网络执行环境（沙箱角色），同时提供带自动评估的可复现任务定义（harness 角色）。双重功能使其有别于 §3.2.2 的计算机使用类别（后者在桌面而非浏览器层运行），并在执行环境与 §8 所讨论的评估基础设施之间形成直接接口。浏览器环境还暴露出一种独特的威胁面：由于浏览器摄入不可信网络内容，它们天然是研究间接提示注入和针对智能体的多模态红队攻击的基底 (Debenedetti et al., 2024; Greshake et al., 2023; Zhang et al., 2026a; Wei et al., 2026)。
3.2.6 OS 层权限沙箱
OS 层权限沙箱使用操作系统原语——Linux 上的 bubblewrap、macOS 上的 Seatbelt，或用于系统调用过滤的 seccomp-bpf——而非容器、VM 或用户态内核，实现细粒度的文件系统和网络隔离。这类沙箱比容器沙箱轻量得多，同时提供目录和域访问控制。代表性系统包括：Anthropic 的 sandbox-runtime (Anthropic, 2025g)，一个开源 npm 包，通过 bubblewrap 和本地 HTTP/SOCKS5 代理对任意命令施加文件系统和网络允许列表；Claude Code 内置的沙箱化功能本身 (Anthropic, 2025b)，用于将 bash 工具的文件系统和网络访问限制在配置边界内；以及 IsolateGPT (Wu et al., 2025)，一个对工具调用 LLM 应用施加 seccomp 和 setrlimit 以执行执行隔离的研究系统。
该类别的设计哲学是权限而非分区（permission, not partition）：目标不是为每次会话提供全新的 OS 镜像，而是赋予智能体现有主机的一个缩窄视图，使提示注入或幻觉命令无法修改敏感文件或泄露数据。Anthropic 报告称，此类边界将 Claude Code 的权限提示减少了 84%，同时保持了安全性 (Anthropic, 2025b)，说明了 OS 层沙箱化的生产力动机：权限提示本身在长周期智能体执行中就是一种活性失效。由于宿主内核共享，OS 层权限沙箱对抗完全对抗性代码的隔离能力弱于 microVM 托管沙箱（§3.2.1）；当威胁模型为提示注入而非完全对抗性代码时，它们才是合适的选择。
3.2.7 沙箱抽象层
沙箱抽象层本身不是沙箱，而是将多个沙箱后端统一在单一 API 之后的接口层，使 harness 无需重写智能体代码即可切换执行基底。代表性系统包括：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 硬编码进 harness 会将编排逻辑与某家供应商的短暂产品绑定；抽象层将智能体运行什么与在哪里运行解耦。我们观察到研究项目（SWE-ReX）、框架内嵌接口（smolagents executors）和新兴基础设施标准（Kubernetes agent-sandbox CRD）三者之间的汇聚，表明沙箱抽象正在成为 agent harness 栈的独立层，而非各系统的个别功能。
综合。 纵观七个类别，三条横切趋势清晰可见。第一，领域正在沿隔离强度轴分叉而非收敛：托管沙箱（§3.2.1）正从共享内核容器向专用内核 microVM 迁移，而 OS 层权限沙箱（§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）。两条路线互为补充：基础设施沙箱约束动作执行后的爆炸半径，语义隔离约束首先允许执行哪些动作。完整的 agent harness 两者缺一不可。
3.3 威胁模型与沙箱逃逸
智能体执行的沙箱化既面临传统容器层威胁（容器逃逸、侧信道、资源耗尽），也面临放大经典问题的智能体特有威胁类别。首先，提示注入攻击允许外部输入——如检索到的网页、工具响应或文件内容——劫持智能体行为并发起恶意沙箱操作。其次，目标错位可导致智能体本身将沙箱逃逸作为工具性子目标主动尝试。第三，当拥有多工具访问权限的智能体将多项能力叠加以利用单一沙箱弱点时，组合放大效应会跨集成能力级联传播。
智能体场景下沙箱逃逸的实证证据有限但令人警觉。SandboxEscapeBench (Marchand et al., 2026) 在嵌套沙箱夺旗环境下评估前沿 LLM，报告成功率为 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 模式，演化出多种部署（deployment）模式，当前实践中三种模式并存。自托管（self-hosted）模式下，开发者直接管理沙箱基础设施，这是 OpenHands 和 SWE-agent 的默认模式。云 SaaS（cloud SaaS）模式下，沙箱即服务提供商处理基础设施，E2B、Modal 和 Daytona Cloud 即为典型。混合或自带云（hybrid/BYOC）模式下，智能体逻辑与沙箱执行跨环境解耦；例子包括 OpenHands SDK 的本地与远程工作区抽象 (Wang et al., 2025c) 以及 E2B 和 Northflank 的 BYOC 方案。
这些模式演化的驱动力来自两个互补方向。一方面，从业者报告沿延迟、安全性和可扩展性三轴权衡部署选择 (Anthropic, 2025b;f)：自托管沙箱延迟最低、迭代循环最紧，但承担全部运营负担；云沙箱反转这一取舍，以网络往返延迟为代价换取弹性扩展和托管安全；混合模式则尝试在将敏感数据保留本地的同时委托执行容量。另一方面，数据驻留、合规和可审计性等组织约束即便在延迟和可扩展性更倾向于单一模式方案时，也会将部署推向混合架构。
在实际观察中，自托管沙箱（sandbox）在交互式开发和单租户场景中占主导地位，而云端沙箱则更多见于多租户和大规模部署场景。混合模式正专门面向合规要求或数据本地化要求与大规模临时执行容量需求并存的场景而兴起。在真实智能体（agent）工作负载下对上述模式进行系统性实证比较的工作目前仍付之阙如，我们将其纳入 §12.1 中更宏观的运行时议题加以讨论。
3.5 小结
执行环境是智能体 harness 的物理基底：它提供安全边界、可复现评估与训练的重置机制，以及长时域（long-horizon）智能体可在无需人工审批的情况下自主运行的有界区域。本节综述的七个类别表明，当前的设计空间已不再主要受单一隔离原语的塑造，而更多地取决于工作负载保真度、威胁模型和运维模式的组合。托管沙箱与计算机使用环境强调强隔离与真实执行；代码专用和浏览器环境侧重吞吐量与评估结构；框架集成运行时将能力捆绑以提升便利性；操作系统级权限沙箱收窄本地授权范围；抽象层则使底层基底可替换。
这一设计空间在能力、控制与成本之间制造了反复出现的张力。高风险工作负载倾向于 microVM 和托管云；本地交互工作流倾向于轻量级权限边界；大规模训练或评估则推动系统走向可快速重置的基底。围绕运行时防御、经济性、可移植性、捆绑与组合设计以及跨层耦合等问题，尚存诸多未解之题——这些并非执行层的孤立注脚，而是作为全局性开放问题在 §12.1 中重现。
4 工具接口与协议层（T）
工具接口与协议层（T）是 ETCLOVG 框架的第二支柱（§1 中的论断 2）。本章所讨论的协议、描述规范与注册机制均来自支撑论断 3 的 148+ 项目语料库。
图 7：按本章工具层类别组织的、针对大语言模型（LLM）智能体工具接口与协议的代表性工作。（原文图见 PDF 第 16 页）
工具接口与协议层定义了智能体如何发现能力、表示可调用的功能可供性，以及如何跨异构运行时边界执行动作。在实践中，该层处于两个相互竞争目标的断层线上：通过暴露更多工具来扩大能力覆盖范围，与通过保持动作空间和提示占用空间的精简来维持决策质量。来自生产级智能体系统的近期工程经验反复表明，过大的工具菜单会降低可靠性、增加 token 开销并放大规划错误 (Anthropic, 2025d; OpenAI, 2026c)。
我们将该层组织为四个互补方向：协议与接口标准；工具描述、发现与选择；工具增强模型训练与集成；以及可扩展性与会话管理。
4.1 协议与接口标准
MCP（Model Context Protocol）已成为编码与企业智能体最具代表性的工具集成基底，采用显式的宿主-客户端-服务器架构和基于 JSON-RPC 的工具、资源及提示的类型化交换 (Model Context Protocol, 2025b;c;a)。MCP 的实用价值不仅在于模式级互操作性，还在于生态系统的流动性：智能体构建者可以复用不断扩充的服务器目录，而无需为每次部署实现定制连接器。
A2A（Agent-to-Agent）针对不同但相邻的边界。它不是向单个智能体进程暴露工具，而是在不透明的智能体应用之间标准化通信，包括通过 Agent Cards 实现发现、支持同步和流式交互，以及长时运行任务协作 (A2A Project, 2025)。近期的协议综述将 MCP 与 A2A 定位为互补角色：MCP 主要用于工具/上下文访问，A2A 用于智能体间委托与协作 (Ehtesham et al., 2025)。在我们看来，更有用的组织原则是按这些标准所跨越的集成边界对其分类，而非按厂商血统或发布时间线。在此视角下，四条边界浮现出来：模型↔函数（结构化调用）、智能体↔外部能力（运行时到工具的解耦）、智能体↔智能体（跨进程委托）以及智能体↔代码库/环境（版本控制策略）。表 1 概括了这一视角，并明确说明了为何若干被广泛比较的标准（如 MCP 与 A2A，或函数调用与 OpenAPI）在单一 harness 中占据不重叠的角色。
函数调用模式和 API 描述标准仍是该层的基础构建块。OpenAI 风格的函数调用通过 JSON 模式和显式调用/返回轮次将工具调用操作化 (OpenAI, 2026c)；OpenAPI 提供了一种语言无关、机器可读的 API 契约，许多智能体框架将其用作工具生成和验证的来源 (OpenAPI Initiative, 2025)。此外，仓库级指令文件（如 AGENTS.md 和 AGENT.md）提供了一种轻量级替代方案，可直接在版本控制中编码工具使用规范和工作流约束，降低代码智能体的配置摩擦 (agentsmd, 2025; agentmd, 2025)。
表 1：按所跨越的集成边界（行）和四个与 harness 相关的能力轴（列）排列的工具/接口标准。● = 一等支持；◑ = 部分支持或惯例级别；○ = 超出范围。引用见正文。
| Boundary | Standard | Wire | Typed | Runtime disc. | Long-running |
|---|---|---|---|---|---|
| Model ↔ Function | Function calling | JSON | ● | ○ | ○ |
| Agent ↔ Capability | MCP | JSON-RPC | ● | ● | ◑ |
| Agent ↔ Capability | OpenAPI | HTTP | ● | ◑ | ○ |
| Agent ↔ Agent | A2A | JSON-RPC | ● | ● | ● |
| Agent ↔ Agent | ACP / ANP | HTTP | ● | ● | ● |
| Agent ↔ Repo / env | AGENTS.md / AGENT.md | Markdown | ○ | ◑ | ○ |
4.2 工具描述、发现与选择
一旦协议（protocol）定义了如何发起调用，下一个瓶颈就是哪些工具应当在每一步被呈现和选择。一个不断壮大的研究方向专注于工具文档质量、检索以及动态候选剪枝。EASYTOOL 分析了从大型工具库中选择合适工具的挑战 (Yuan et al., 2025)。AnyTool 和 CRAFT 专注于通过自动构建或精化工具使用流水线来降低人工规格说明负担 (Du et al., 2024; Yuan et al., 2023)。MetaTool 基准风格的评估表明，工具检索和调用质量因领域和查询形式不同而差异显著 (Huang et al., 2023)。MCP-Zero、ToolRet 和 ToolRegistry 等更近期的工作将检索感知的编排（orchestration）和注册质量作为下游智能体成功的首要决定因素加以强调 (Fei et al., 2025; Shi et al., 2025b; Ding, 2025)。
一个密切相关的方向将工具选择延伸至可复用的技能（skills）：智能体必须从过程化模块库中识别相关模块，而不仅仅是选择紧凑的 API 模式。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)。
在生产级 harness 中，上述模型进展通常与框架级运行时栈配合使用，例如 LangChain、Semantic Kernel 和 smolagents——它们提供记忆（memory）抽象、路由中间件和工具适配器 (LangChain, 2026c; Microsoft, 2026; Hugging Face, 2026)。编码智能体场景还暴露出第二类更专门的工具：静态分析器、类型检查器、求解器支持的验证器、证明辅助工具以及补丁等价性或故障定位检查器。Ugare & Chandra (2026) 将这一空间定义为智能体代码推理（agentic code reasoning）：智能体探索代码库并对代码行为进行推理，而不一定执行代码。他们的半形式化推理方法介于非结构化思维链与完全形式化验证之间，通过强制智能体陈述前提、追踪程序路径并推导显式结论来改进补丁等价性验证、故障定位和代码问答。对工具层而言，这意味着自动化推理工具应返回携带证据的制品（如追踪、证明义务、反例或结构化证书），而不仅仅是黑盒式的是/否答案。综合证据表明，工具能力由预训练与微调信号、接口模式质量以及运行时选择策略共同决定；仅改进单一组件所带来的收益是有限的。
4.4 可扩展性与会话管理
长时域（long-horizon）下的会话管理是一个反复出现的运维挑战。有状态工具会话能够提升连贯性，但会增加簿记复杂度，尤其是当调用被并行化或跨多个智能体委托时。故障模式包括：陈旧的句柄、跨重试的工具状态不一致，以及来自冗长工具追踪的上下文窗口（context window）饱和。因此，有效的 harness 设计需要为工具会话提供显式的生命周期控制、有界的工具上下文注入，以及可将错误归因于规划器逻辑或接口/协议失败的可观测性钩子。
最后，生态系统层面的全景整理可以帮助从业者快速梳理可用的协议与工具选项，但基于基准的比较对于确定在特定部署中应采用哪种协议和工具路由策略仍不可或缺。
5 上下文与记忆管理（C）
上下文与记忆管理（C）是提示工程（prompt engineering）与 harness 工程相交汇的层次。我们将其视为 ETCLOVG 框架的第三支柱（§1 中的论断 2），示例来自支撑论断 3 的 148+ 项目语料库。
图 8：按本章上下文层类别组织的、针对大语言模型智能体上下文与记忆管理的代表性工作。（原文图见 PDF 第 19 页）
该层决定了模型在每一执行步骤所见的信息，以及知识如何跨轮次和会话持久化（persistence）。其核心工程问题可以简单陈述：在每一步骤向模型提供恰好正确的信息，不多不少。上下文过少，智能体就缺乏正确行动所需的状态；上下文过多，性能会以可测量、跨模型一致但尚未完全理解的方式下降。
本节围绕时间视野展开。§5.1 阐述为何上下文需要主动管理而非被动积累。§5.2 将上下文工程（context engineering）定义为有别于提示工程的独立学科。§5.3 至 §5.5 涵盖生产实践中涌现出的三个记忆层级：活跃上下文窗口（短期）、会话级持久化（中期）以及跨会话存储（长期）。§5.6 讨论智能体运行数百轮时出现的协调问题。§5.7 以尚未解决的问题作结。
5.1 为何上下文必须被工程化
更大的上下文窗口并不能解决记忆问题。理解其原因需要审视模型架构。
二次注意力开销。 Transformer 的自注意力机制计算上下文中每个 token 之间的两两关系 (Vaswani et al., 2017)。对于 $n$ 个 token，这产生 $n^2$ 个成对权重；计算量和内存占用随之二次增长。FlashAttention 和位置编码插值等工程技术能降低常数因子，但二次结构是架构性的。上下文翻倍并不使成本翻倍——而是使其翻四倍。这使上下文窗口成为一种稀缺资源。
U 形注意力曲线。 仅凭架构成本无法解释为何模型在长上下文上失败——即便计算可以负担。Lin et al. (2024) 提供了关键实证结果：在包含 20 份输入文档的多文档问答任务中，当相关文档位于上下文中间时，准确率相比位于开头或结尾时下降超过 30%。这一 U 形性能曲线在不同模型、任务和上下文长度下均成立，包括专门针对长上下文训练的模型。其实践含义是直接的：信息放置与信息存在同等重要。检索到正确内容但位置放置不佳的智能体，从检索中获益甚微。
规模下的上下文腐化。 Hong et al. (2025) 在受控条件下对 18 个前沿模型（包括 GPT-4.1、Claude Opus 4、Gemini 2.5 和 Qwen3）进行了评估，将输入长度与任务难度隔离。每个模型的性能都随输入增长而下降。这种下降是非均匀且任务特异性的。语义上模糊的查询（相关段落在词汇上与问题不匹配）比精确匹配查询显示出更陡峭的下降，指向一种复合失败：模型既无法定位相关信息，也无法在找到后对其进行推理。Hong et al. (2025) 将这一现象称为上下文腐化（context rot），它并非边缘案例——而是任何积累工具结果、中间推理和文件内容的智能体在多步骤运行中的正常运行条件。
综合来看，这些结果确立了上下文管理（context management）不能是事后考量。关于纳入哪些信息、放置在何处以及何时移除，每个决策都对智能体可靠性产生直接影响。
5.2 从提示工程到上下文工程
从提示工程（prompt engineering）到上下文工程（context engineering）的转变反映了范围的拓展 (Karpathy, 2025)。提示工程优化单个模型调用的主要静态文本输入。在视觉领域，同样的框架延伸至连续可学习 token：视觉提示微调在冻结视觉 Transformer 的补丁序列前面插入一组小的可训练向量，以适配下游任务，同时更新少于 1% 的模型参数 (Jia et al., 2022; Xiao et al., 2025)。文本与视觉两种变体共享提示工程的核心特征：针对单一输入模态的固定、单次调用优化。上下文工程则优化多步骤任务中每个推理步骤时模型可获得的完整信息状态。
Anthropic 应用 AI 团队将其定义为”在大语言模型推理期间，策划和维护最优 token 集合的一套策略，包括可能出现在提示之外的所有其他信息” (Anthropic Applied AI Team, 2025)。其指导原则如下：在每一步找到能最大化期望结果概率的最小高信噪比 token 集合。这一原则驱动了本节的每一项技术。渐进式披露（progressive disclosure）恰好在需要时加载信息而非预先全部注入。压缩（compaction）移除已完成使命的 token。记忆检索仅拉取与当前任务最相关的记录。
上下文包含什么。 在已部署智能体的推理时，上下文包括：系统提示和行为指令、工具定义及模式、先前历史记录、当前轨迹的工具调用结果、检索到的文档或记忆记录，以及任何动态注入的工作状态。上述所有内容都在竞争同一有限的注意力预算。上下文工程意味着在每一步对每个组件做出显式选择，而不是让它们无约束地积累。
这一实践的成熟化在生态系统中清晰可见。第一性原理手册 (Kimai, 2025) 和精选综述 (Meirtz, 2025) 现在将上下文工程作为独立学科加以处理。涵盖活跃上下文窗口、会话级状态和跨会话存储的三层记忆架构，已成为主导的组织框架。它直接映射至操作系统的经典记忆层次结构，为将正确技术匹配到正确时间视野提供了有用的直觉和词汇。
5.3 短期：管理活跃上下文窗口
短期上下文管理（short-term context management）决定了模型在单个推理步骤或会话内短序列步骤中所见的内容。这些决策对模型行为有最直接的影响，若处理不当代价也最高。
系统提示校准。 系统提示确立了智能体的行为范围，并在每次调用中消耗固定预算。Anthropic Applied AI Team (2025) 将设计挑战描述为寻找正确的姿态（attitude）：过于具体的提示引入脆性、维护负担重的逻辑；过于宽泛的提示则使模型缺乏指导。在实践中，有效的系统提示被组织为清晰分割的板块——背景、指令、工具指导和输出格式——使用 XML 标签或 Markdown 标题加以分隔。推荐的工作流是：从最佳可用模型上的最小提示出发，实证地识别失败模式，然后添加有针对性的指令来填补具体缺口。预先列举每一个边缘案例往往会使提示臃肿而不提升可靠性。
Token 高效工具设计。 工具定义是主要的上下文消耗者。每个模式、名称、描述和参数类型在每次调用时都被注入。一个大型工具集在智能体读取用户请求之前就可能消耗数万个 token。从生产部署中涌现的原则是：相比大量狭窄工具的菜单，更少但更具表达力的工具往往更优。若人类工程师无法判断某一工具在特定情境下适用，则不应期望模型能做到。工具应做到自包含、对错误鲁棒、在预期使用中无歧义，并配备能充分发挥模型优势的描述性参数名称。
即时检索与渐进式披露。 有效智能体并非预先加载所有可能相关的信息，而是维护文件路径、存储查询和网页链接等轻量级标识符，并在任务展开时按需加载数据。Anthropic Applied AI Team (2025) 将这种方式称为渐进式披露（progressive disclosure）。它镜像了人类专家的工作方式：我们不记忆语料库，而是构建外部索引系统并按需检索。Claude Code 在实践中使用混合策略：CLAUDE.md 文件在会话开始时加载以提供项目上下文，而 glob 和 grep 命令则让智能体按需导航并加载具体文件内容。这一做法规避了陈旧索引问题和大型预填充的代价。环境元数据也携带隐式信号：文件大小暗示复杂度；命名惯例提示目的；时间戳代理相关性。智能体可以逐层构建理解，在活跃窗口中仅保留当前必要的内容。
KV 缓存感知的上下文设计。 提示缓存（prompt caching）是生产智能体部署中最具成本效益的单项优化，而其收益完全取决于上下文的结构化方式。Manus 团队在对其生产智能体进行五次架构迭代后，将 KV 缓存命中率确定为”生产级阶段性 AI 智能体最重要的单一指标”，指出 Claude Sonnet 上缓存 token 的成本为 0.30 美元/百万 token，而未缓存 token 为 3.00 美元/百万 token (Manus Team, 2025)。由缓存模型衍生出三条设计规则：第一，保持提示前缀稳定——系统提示开头的单个 token 差异会使后续所有内容的缓存失效；第二，将上下文视为仅追加——修改过去的动作或观察会创建不同的前缀序列，破坏缓存复用；第三，使用确定性序列化——JSON 序列化中不稳定的键排序会静默地使跨本质相同调用的缓存失效。由于工具定义通常出现在序列化上下文的前部，添加或移除工具会使其后所有轮次的缓存内容失效。Manus 通过使用上下文感知状态机来解决这一问题，该状态机在解码时屏蔽不可用动作的 logit，而非在运行时修改工具定义列表 (Manus Team, 2025)。Anthropic 的上下文管理发布通过显式的 cache_control 断点在产品层面将缓存操作化 (Anthropic, 2025c)。
短期管理的工具生态系统已发展成熟，涵盖智能体调用间 KV 缓存压缩（compaction）模式的生产技能库 (Koylan, 2025)，以及提供动态上下文组装 MCP 中心原语的基础设施项目 (context-space, 2025)。
5.4 中期：会话状态与跨运行持久化
中期上下文管理（mid-term context management）填补了活跃上下文窗口与完整长期记忆系统之间的空缺。具体问题是：智能体如何在会话内跨轮次，或在同一任务的多次运行间保存和恢复状态。其工程价值不可小觑：数百个结构化工作状态 token 可以桥接上下文重置，而否则这些重置会导致智能体丢失所有累积进展。
结构化笔记记录。 最简单的中期技术是让智能体维护一个持久化笔记文件——通常是 NOTES.md 或 todo.md——在每次运行开始时读取，并在上下文被清空前更新。Anthropic Applied AI Team (2025) 通过 Claude 在数千个游戏步骤中玩宝可梦来说明这一做法。在没有任何关于记忆结构的明确指令的情况下，智能体自发地构建了已探索区域的地图、维护了针对特定对手的战斗策略及其结果的持续统计，并跨上下文重置追踪目标。在每个清空主要对话历史的 compaction 步骤之后，智能体读取自己的笔记并继续多小时的训练序列而不失去连贯性。其核心洞察是：笔记记录将工作记忆外化——智能体不依赖对话历史来承载任务状态，而是将重要内容写入外部存储并按需读回。
基于文件的规划与任务外化。 结构化笔记记录的一个延伸是将完整的规划表示外化到磁盘。规划文件工具（planning-with-files，OthmanAdi, 2025）等工具提供技能包，用于在编码智能体工作流中进行持久化的基于文件的规划。任务状态、规格说明、中间结果和依赖图在每个里程碑时被写入文件系统，并在下次运行开始时被选择性地加载——对非立即相关的内容完全绕过上下文窗口。Trellis 等框架 (mindfold-ai, 2025) 将这一模式扩展为包含项目记忆和规格注入，根据当前步骤需求选择性地注入结构化项目状态。
跨运行注入。 一种互补模式是捕获前一次运行的显著输出并在下次运行开始时注入。claude-mem 等工具 (thedotmack, 2025) 作为插件式记忆层运行：它们捕获会话历史，提取在未来运行中最有用的信息，并将其前置到下一会话的上下文中。这既不需要向量数据库，也不需要图存储，同时跨运行提供了可观的连续性。社区仓库 everything-claude-code (affaan-m, 2025) 拥有超过 150K GitHub star，是这些模式的最大开放集合，展示了中层记忆实践在生产编码智能体部署中的普及程度。
中层的权衡。 中层技术以远低于完整长期记忆系统基础设施成本的代价，提供了比纯窗口内管理显著更多的连续性。其局限性在于：信息从一次运行向前传递到下一次，但不是从索引存储中检索；这些技术也无法很好地扩展到大量历史数据。当跨运行历史变得庞大，或智能体需要检索特定的先前观察而非注入摘要时，中层技术必须辅以下面描述的长期系统。
5.5 长期：持久化记忆系统
长期记忆（long-term memory）系统提供跨会话、任务和智能体实例持久存在的索引、可检索存储。中层技术依赖前向注入摘要，而长期系统支持任意召回：给定查询，系统无论记忆何时创建，均能检索出最相关的存储记忆。这一层是智能体经验随时间积累的地方。
5.5.1 基础架构
受操作系统启发的分层记忆。 Packer et al. (2023) 通过将大语言模型的上下文窗口视为 RAM、外部存储视为磁盘，引入了关键抽象，赋予模型可显式换入换出信息的函数调用能力。与虚拟内存的类比是精确的：正如操作系统通过透明分页为应用程序提供更大内存的幻觉，MemGPT 通过透明记忆管理为大语言模型提供更长上下文的幻觉。智能体可以在远超物理窗口限制的上下文上运行，按需从外部存储检索相关历史。这篇论文明确了智能体记忆与操作系统记忆之间的联系，这一联系是此后大多数长期记忆系统的基础。
观察、反思与检索。 Park et al. (2023) 在社会仿真智能体的背景下引入了 Memory Stream 架构。Memory Stream 将智能体的所有观察以附带时间戳和重要性分数的自然语言记录形式存储。在每一步，检索模型通过结合三个信号来呈现最相关的记忆：近期性（由智能体在写入时打分）、重要性，以及与当前查询的相关性。第二个机制——反思——定期将存储的观察综合为更高层次的洞察。智能体询问自身当前最显著的问题是什么，检索相关记录，并生成被存储回 Memory Stream 的结论。消融实验表明，观察、反思和检索三个组件各自独立地贡献于行为质量；移除任意一个都会产生可测量的下降。观察-反思-检索三元组仍是智能体记忆设计的标准模板。
动态遗忘与人格建模。 Zhong et al. (2024) 在检索架构基础上增加了两个扩展，构建了 MemoryBank。第一个是受艾宾浩斯遗忘曲线启发的动态遗忘机制：记忆随时间按指数模型衰减，频繁访问会强化，相互矛盾的记忆会得到解决。第二个是层次化的用户人格摘要，随着交互积累每日更新。自适应记忆强度和用户建模这两个思路，后来在 Mem0 和 Honcho 中被大规模操作化。
5.5.2 生产级记忆系统
混合存储与行业采用。 Mem0 (Chhikara et al., 2025) 是目前部署最广泛的生产智能体长期记忆层，拥有超过 1400 万次 Python 包下载量、4.1 万个 GitHub Star，并原生集成于 CrewAI、Flowise 和 LangGraph。其架构融合三种存储后端：用于语义相似度检索的向量数据库、用于关系建模的图数据库，以及用于快速事实检索的键值存储。基于大语言模型（LLM）的提取层负责处理新交互，识别事实与偏好，并将记录路由至相应存储。在 LOCOMO 基准测试上，Mem0 的准确率比 OpenAI 原生记忆高出 26%，同时所用 token 数量比全上下文方法 (Chhikara et al., 2025) 少 90%。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 基准测试上达到最先进水平，该结果已由弗吉尼亚理工大学 Sanghani 中心的研究人员独立复现。
基于推理的个性化。 Honcho (Plastic Labs, 2025)（由 Plastic Labs 开发）为用户构建的是模型，而非关于用户的事实存储。一条名为”dreaming”的异步推理流水线（pipeline）在后台持续处理历史交互，提取的不仅是显式事实，更是关于偏好、沟通风格和演化目标的隐性推断。其以实体为中心的数据模型支持多智能体（multi-agent）环境，允许多个智能体与同一用户交互：每个智能体维护独立的观测视角，防止交叉污染，同时共享的用户模型从所有交互中积累理解。
集体记忆（Collective memory）。 Mozilla AI 的 cq (Mozilla AI, 2025) 填补了其他系统留下的空白：跨智能体实例共享记忆。大多数长期记忆系统以单智能体或单用户为粒度；当多个智能体协作处理相关任务时，每个实例会独立重新发现其他实例已经学到的内容。cq 是一个开放标准，用于智能体间共享学习——智能体可在其中持久化、查询并确认集体知识，覆盖整个智能体集群。其架构原生支持 MCP，分三个层级运行：存储在开发者本机的本地知识、可供团队访问的组织级知识，以及跨团队知识。”错误后钩子”（post-error hook）模式使 cq 在智能体遇到错误时自动查询集体知识库，为防止同一失败在组织的不同部署中被独立重复提供了具体机制。
5.5.3 学术综述与分类
Zhang et al. (2025) 的记忆机制综述为该层提供了标准学术分类框架。该综述将短期工作记忆与长期记忆加以区分，并将后者细分为语义记忆、程序记忆和情节记忆三类。其形式化的读-写-管理循环已成为描述记忆系统行为的标准词汇。Du (2026) 的一篇较新综述在此基础上进一步发展，将该循环纳入 POMDP 风格的智能体周期，并提出覆盖记忆范围、存储格式和组合结构的三维分类体系，归纳出三种工程模式：模式 A（单体上下文）、模式 B（上下文窗口加检索存储）和模式 C（带学习控制策略的分层记忆）。这三种模式大致对应本节所述的短期、中期和长期层级。Gao et al. (2023) 的 RAG 综述为上述生产记忆系统的检索层提供了背景知识基础。
5.6 长时域（Long-Horizon）技术：在 100+ 轮次中保持智能体的连贯性
前述各节分别针对单一时间尺度。而长时域（long-horizon）任务——包括大型代码库迁移、多会话研究项目和扩展自主工作流（workflow）——需要同时协调三个层级，并对每个时间点应采用哪种技术做出实时决策。本节聚焦于在这一规模下涌现出的集成层面技术。
上下文压缩（Context compaction）。 压缩（compaction）在上下文窗口逼近上限时，将其以压缩后的状态摘要表示并重新初始化。Anthropic Applied AI Team (2025) 详细描述了这一校准挑战。摘要必须保留架构决策、未解决的缺陷和实现细节，同时丢弃已被后续步骤吸收的冗余工具输出和中间推理。推荐的调优工作流从最大化召回率出发——捕获追踪记录中所有可能相关的信息——再通过移除冗余内容来提升精确率。不能从另一端出发：过度删减会导致智能体丢失后续所需的上下文，且这种丢失不可恢复。工具结果清除（Tool result clearing）是最轻量的压缩形式：一旦智能体已处理某工具结果，该结果的完整输出即被替换为简短的路径引用。该方法可持续应用，目前已成为 Anthropic 开发者平台上的产品级功能 (Anthropic, 2025c)。
子智能体上下文隔离（Sub-agent context isolation）。 当任务需要对某子主题进行深入探索时，探索本身会产生大量中间上下文——这些上下文在子任务内部有用，却会污染编排者对整体任务的视图。子智能体（subagent）架构通过将子任务分配给专用智能体来解决这一问题：每个专用智能体拥有独立的新鲜上下文窗口，仅向编排者返回 1,000 至 2,000 token 的精简摘要 (Anthropic, 2025e)。详细的探索上下文保留在子智能体内部；编排者只接收提炼后的结果。Manus Team (2025) 描述了该模式的一种细化：对于编排者只需要输出的简单子任务，上下文完全不共享；对于需要共享状态的复杂子任务，编排者的完整上下文会传递给子智能体。在智能体间共享上下文代价高昂：它会产生更大的前缀填充（prefill），并消除跨不同系统提示的 KV 缓存复用。隔离成本与协调收益之间的权衡必须针对每种任务类型显式做出。
混合决策框架（Hybrid decision frameworks）。 生产部署不会统一应用单一技术，而是根据任务结构在执行的不同节点选择不同技术。Anthropic (2026c) 将该框架表述为：预加载始终需要的内容，按需检索条件性需要的内容，在窗口趋于饱和时压缩历史记录，并在子任务需要深入探索且可能污染编排者上下文时衍生子智能体。Anthropic (2025d) 补充了 harness 层面的视角：检查点（checkpoint）和恢复模式使智能体能够从瞬时故障中恢复而不丢失任务状态，生命周期（lifecycle）钩子可在可配置的阈值下自动触发压缩或记忆整合。这是职责的正确划分：上下文管理应由 harness 负责，而非智能体本身。当 harness 自动处理压缩与整合时，模型便可专注于任务推理。
5.7 上下文漂移与现有方法的局限
约束性视角将上下文漂移（context drift）定义为控制器侧的失效模式：由于模型只能看到 harness 所暴露的状态投影，与任务相关上下文的丢失或失真是 harness 的属性，而非单纯的模型属性 (Bölük, 2026b)。上述所有技术在不同程度上、在不同条件下均有效，但没有一种能从根本上解决这一问题。上下文漂移——智能体行为在长时域交互中的渐进式退化——仍是该层最难攻克的开放性挑战。
问题的本质。 上下文漂移不同于上下文腐败（context rot），尽管两者源于相同的架构约束。上下文腐败（第 5.1 节）是单步推理的属性：向固定上下文中添加更多 token 会降低检索和推理质量。上下文漂移是扩展轨迹的属性。随着智能体积累轮次，其行为会以难以通过压缩和检索步骤阻止的方式偏离初始意图。经过 100 轮或更多轮次后，智能体频繁重复已完成的工作、在无感知的情况下推翻早期决策，并忘记驱动任务的核心目标 (Bowne-Anderson & Huber, 2026)。根本原因并非单纯的窗口饱和。即便使用积极的压缩，每个压缩步骤所生成的摘要也会携带微小误差，并随时间累积。智能体积累的假设可能与实际任务环境产生偏差，而现有架构对这种偏离毫无感知。
评估缺口。 第二个问题是上下文漂移难以度量。标准基准在数十步内完成的任务上评估智能体，100 轮或更多轮次中出现的失效模式无法被捕获。近期工作已开始弥合这一差距：Tan et al. (2025) 引入 MemBench，评估多会话场景下的记忆质量，涵盖时序推理、知识更新和跨会话聚合；He et al. (2026) 专门针对上下文漂移最具破坏性的相互依存多会话任务，推出 MemoryArena；Hu et al. (2025b) 提出增量式多轮评估方法，将记忆质量与生成质量相隔离。这些基准是必要的，但尚不充分。它们表明漂移确实发生，却未能提供防止漂移所需的机制性理解。
现有技术的不足。 压缩能减少 token 数量，但无法保证压缩后的表示准确捕获所有相关状态——每次压缩步骤丢失的信息都无法找回。检索系统可以浮现相关的历史记忆，但查询必须构造得当才能生效。发生漂移的智能体可能并不知道自己需要检索什么来纠正航向。子智能体隔离可以防止子任务上下文污染编排者，但编排者自身的上下文仍会随时间累积漂移。Bowne-Anderson & Huber (2026) 认为，这些局限指向一条边界：仅靠上下文工程无法保障长时域的可靠性。这一认识催生了对治理层和可观测性（observability）层的需求——即第 7 节和第 9 节所讨论的内容——它们是对上下文工程的必要补充，而非独立关切。
6 生命周期与编排（L）
图 9：大语言模型（LLM）智能体生命周期与编排（lifecycle and orchestration）的代表性工作，按章节编排类别组织（原文图见 PDF 第 25 页）
生命周期与编排（Lifecycle and Orchestration，L）关注的是智能体系统如何在反复的模型调用、工具调用、失败、修订和交接（handoff）中推进任务。该层将早期框架中通常分离的两个关切合二为一：智能体的执行流，以及执行流所读写的操作状态。在长时域任务中，可靠性不仅取决于模型能否生成良好的下一步动作，还取决于 harness 能否记住已完成的工作、决定下一步应发生什么、从错误中恢复、协调子任务，并在任务完成时停止 (OpenAI, 2026b; Anthropic, 2025d; 2026c)。因此，我们将生命周期与编排视为 ETCLOVG 的第四大支柱（主张 2，见第 1 节），并从支持主张 3（同样见第 1 节）的 100 余个项目语料库中援引实例。
该层涵盖三个组织层级。单智能体内循环（single-agent inner loop）是一个智能体反复观测当前情况、决定一个动作、调用工具或生成输出，并利用结果继续执行的循环。多智能体编排（multi-agent orchestration）通过为不同智能体分配不同角色、或在智能体间路由工作来协调多个此类循环。完整生命周期流水线（full lifecycle pipeline）将上述智能体循环嵌入更广泛的软件或任务工作流（workflow）中，例如从一个 issue 到代码变更、测试、审查和拉取请求（pull request）。在这些层级上，系统在状态维护方式上也有所不同。无状态重放（Stateless replay）通过重建已记录的交互历史来重构运行过程。有状态执行（Stateful execution）将操作状态保存在提示词之外——例如文件、代码库、数据库、任务图或服务。许多实际系统是混合型（hybrid）的：在保留可重放历史的同时，也依赖持久化制品。
| System or Framework | GitHub URL | GitHub Stars (k) | Section | Primary Pattern | Execution Model |
|---|---|---|---|---|---|
| Single-Agent Inner Loop | |||||
| OpenCode (Anomaly, 2025) | anomalyco/opencode | 159 | 6.2 | Single loop | Hybrid |
| Claude Code (Anthropic, 2025) | anthropics/claude-code | 123 | 6.2 | Single loop | Hybrid |
| Gemini CLI (Google, 2025) | google-gemini/gemini-cli | 104 | 6.2 | Single loop | Hybrid |
| Codex CLI (OpenAI, 2025) | openai/codex | 82 | 6.2 | Single loop | Stateless replay |
| Aider (Aider-AI, 2025) | aider-ai/aider | 45 | 6.2 | Single loop | Hybrid |
| SWE-agent (SWE-agent, 2025) | swe-agent/swe-agent | 19 | 6.2 | Single loop | Hybrid |
| Multi-Agent Orchestration Patterns | |||||
| DeerFlow (Bytedance, 2026) | bytedance/deer-flow | 67 | 6.3 | Hierarchical orchestration | Stateful |
| AutoGen (Microsoft, 2025) | microsoft/autogen | 58 | 6.3 | Hierarchical orchestration | Stateful |
| oh-my-claudecode (Heo, 2026) | yeachan-heo/oh-my-claudecode | 34 | 6.3 | Team orchestration | Stateful |
| LangGraph (LangChain, 2026a) | langchain-ai/langgraph | 32 | 6.3 | Graph composition | Stateful |
| Semantic Kernel (Microsoft, 2026) | microsoft/semantic-kernel | 28 | 6.3 | Workflow orchestration | Stateful |
| OpenAI Agents SDK (OpenAI, 2026a) | openai/openai-agents-python | 26 | 6.3 | Hierarchical orchestration | Hybrid |
| DeepAgents (LangChain, 2026b) | langchain-ai/deepagents | 23 | 6.3 | Hierarchical orchestration | Stateful |
| Hive (Aden, 2026) | aden-hive/hive | 10 | 6.3 | Graph composition | Stateful |
| Emdash (Action, 2026) | generalaction/emdash | 4 | 6.3 | Fan-out | Hybrid |
| Full Lifecycle Pipeline from Issue to Pull Request | |||||
| Vibe Kanban (Bloop-AI, 2026) | BloopAI/vibe-kanban | 26 | 6.4 | Full lifecycle pipeline | Stateful |
| Symphony (OpenAI, 2026b) | openai/symphony | 24 | 6.4 | Full lifecycle pipeline | Stateful |
| GitHub Agentic Workflows (GitHub, 2026) | github/gh-aw | 5 | 6.4 | Full lifecycle pipeline | Hybrid |
表 2：代表性编排系统，按编排层级（单智能体：§ 6.2；多智能体：§ 6.3；完整生命周期流水线：§ 6.4）、主要编排模式和执行模型组织。GitHub Star 数四舍五入至千位，记录截止 2026 年 5 月 12 日。
6.1 生命周期状态管理
生命周期状态管理（lifecycle state management）关注的是在轮次、会话、失败和交接（handoff）之间维持智能体运行所需的操作状态。这包括待处理的子任务、工具调用结果、中间制品、代码库变更、协调元数据、会话持久化以及检查点（checkpoint）恢复机制。这些机制使编排具有持久性而非瞬时性：智能体可以从先前工作中继续执行，而不必将每一步都视为孤立的模型调用。
无状态设计与有状态执行之间存在核心权衡。无状态设计通过重建先前的交互历史来重构执行，有利于可复现性和可审计性，但随着轨迹增长代价高昂。有状态设计在文件、数据库、代码库、任务图或外部服务中持久化执行状态，有利于连续性与恢复，但引入了一致性和调试方面的挑战 (OpenAI, 2026b; Anthropic, 2026c)。因此，许多实际 harness 采用混合设计，将可重放的交互历史与持久化制品相结合。
这一状态层有别于第 5 节所述的上下文与记忆层——后者关注的是提供给模型进行推理的信息，例如检索到的文档、记忆或对话历史。它也有别于第 7 节所述的可观测性（observability）层——后者关注的是对系统行为的日志记录、追踪（tracing）与监控（monitoring）。这里的重点
6.2 单智能体内循环
单智能体内循环（single-agent inner loop）是智能体系统中的基本执行单元。单个智能体通过工具使用和反馈反复与环境交互，无需多智能体之间的显式协调。这一抽象是交互式编程、调试和问题求解的基础。
从概念上看，单智能体内循环遵循 ReAct 范式 (Yao et al., 2023)，交替进行推理、动作和观测。正如 OpenAI 对 Codex 智能体循环的分析所强调的 (OpenAI, 2026b)，此类系统的行为不仅由模型决定，还由构建提示词、调用工具、管理控制流并将工具输出反馈到后续步骤的 harness 决定。
在这一层级，主要执行区别在于无状态重放与混合执行之间。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 多智能体编排模式
多智能体编排（multi-agent orchestration）通过组合具有专门角色的多个智能体，对单智能体循环进行扩展。与依赖单一智能体完成规划、执行、检验和修订不同，多智能体 harness 可以将这些职责分离到不同智能体或子智能体（subagent）之间。这种结构支持任务分解、并行探索、批评验证和聚合，使其比孤立循环更适合处理复杂任务。
在这一设计空间中，存在几种反复出现的模式。层级编排（Hierarchical orchestration）使用更高层级的控制器向智能体或子智能体分配工作，并整合其输出。团队编排（Team orchestration）将一组专业化智能体组织为协调团队，通常每个智能体具有不同的命名职责。工作流编排（Workflow orchestration）将智能体和工具组织为显式的阶段或控制逻辑。扇出（Fan-out）并行运行多个智能体以探索多样化方案。图组合（Graph composition）将智能体、工具或状态表示为交互图中的节点，允许多种协调模式共存。这些标签对应表 2 中使用的主要模式类别。
该层级的执行通常为有状态或混合，因为多智能体系统必须维护协调状态、角色分配、任务图、共享制品或中间结果。Anthropic 的规划器-生成器-评估器架构 (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 到拉取请求的完整生命周期流水线
完整生命周期编排（full lifecycle orchestration）管理从规格说明到经过验证的输出的完整任务工作流（workflow）。在这一层级，关注的焦点不仅在于智能体如何交互，还在于 harness 如何在规划、实现、验证、审查和交付的整个过程中支持长时域执行。
核心抽象是任务运行器（task runner）：一种管理完整任务生命周期（lifecycle）中的调度、状态持久化、重试、验证和迭代精化的 harness (OpenAI, 2026a; LangChain, 2026b)。执行依托于持久化制品，如代码库、分支、文件、测试和拉取请求（pull request）。标准化工作流（workflow）从 issue 或任务规格出发，经由智能体规划、代码或制品生成、验证、人工审查，最终完成拉取请求（pull request）接受。
由于这些系统依托持久化代码库和外部工作流（workflow）运行，主导的执行模型通常是有状态的。部分系统将持久化基础设施状态与会话本地的重放式执行相结合，这正是表 2 中混合标签的由来。从概念上看，这些系统将前述抽象层层组合：单智能体循环提供执行原语，多智能体模式提供协调，任务运行器将它们整合进端到端的工作流（workflow）——人类负责引导，智能体负责执行。
7 可观测性与运营（O）
可观测性与运营（Observability and Operations，O）是 ETCLOVG 的第五层，也是我们的分类体系将生命周期钩子晋升为一等地位（主张 2，见第 1 节）的两层中的第一层。支撑系统来自支持主张 3 的 148 余个项目语料库。
图 10：大语言模型（LLM）智能体可观测性与运营的代表性工作，按章节运营类别组织（原文图见 PDF 第 28 页）
该层关注智能体行为如何被监控（monitoring）、调试和在生产环境中确保可靠。我们认为可观测性值得独立处理，与生命周期钩子相分离，原因在于它已催生出一个专门的平台、规范和工程实践生态系统。
7.1 追踪与监控平台
智能体可观测性（observability）的基础是结构化追踪（trace）收集：将每次大语言模型（LLM）调用、工具调用、检索步骤和上下文组装操作记录为可供检查、过滤和重放的 span 树。
Langfuse、Opik、Arize Phoenix 和 MLflow 均提供具有延迟火焰图、token 使用分解、成本归因仪表板和提示词版本控制的交互式追踪树 Langfuse (2026); Comet ML (2026); Arize AI (2026b); MLflow (2026)。这些平台通常通过轻量级 SDK 包装器（例如 @traceable 装饰器）接入，以最少的代码改动对智能体的函数调用进行插桩。
在这些平台之下，OpenTelemetry（OTel）已成为事实上的插桩标准。OTel 社区发布了适用于生成式 AI 的语义约定，为模型名称、温度、token 数量和延迟定义了 span 属性 OpenTelemetry (2026)。两个开源项目将这些约定付诸实践：OpenLLMetry 为大语言模型（LLM）提供商（OpenAI、Anthropic、Cohere）和向量数据库（Pinecone、Chroma、Weaviate）提供自动插桩，输出标准 OTel span 和指标 Traceloop (2026)；OpenInference（由 Arize AI 维护）提供与 Phoenix 配套的、符合 OTel 规范的语义约定和自动插桩 Arize AI (2026a)。通过基于 OTel 构建，这些库允许智能体追踪（tracing）流入传统微服务监控（monitoring）所使用的相同可观测性后端（Prometheus、Jaeger、Grafana、Datadog），降低了采用智能体专用工具的运营开销。
在更深层的插桩层面，学术研究探索了超越应用层装饰器的技术。AgentSight Zheng et al. (2025) 使用 eBPF 从应用进程外部监控智能体，在 SSL 边界截取 TLS 加密的 LLM 流量以捕获意图，并监控内核事件（进程创建、文件 I/O、网络调用）以触发动作。实时关联引擎将大语言模型（LLM）响应与其触发的系统行为关联起来，辅助”观察者”大语言模型（LLM）执行语义分析以识别风险。该方法与框架无关，无需修改代码，CPU 开销低于 3%。作者指出了其相对于应用层工具的结构性优势：系统级监控（monitoring）不能被受损或配置错误的智能体绕过，这使其对安全关键部署尤为重要。AgentTrace AlSayyad et al. (2026) 提出了一种互补的基于 schema 的日志框架，跨三个”界面”捕获结构化日志：认知推理步骤、计划和反思；操作性工具调用和 API 交互；以及上下文环境状态和用户输入。这些界面被组织在一个统一信封下，并与 OTel 集成以供导出。认知界面对 harness 工程尤为重要，因为它捕获了显式的推理制品、计划、反思和自我修正。这些记录为调试因错误推理（而非系统错误）引发的失败提供了原始素材。
7.2 智能体专用运营平台
通用追踪（tracing）平台通常将其抽象聚焦于大语言模型（LLM）调用、工具调用和检索步骤等 span 级事件。智能体专用平台则增加了一层抽象，捕获智能体层面的关切：多轮会话追踪（tracing）、智能体身份与角色管理、工具选择策略，以及跨会话状态的交接（handoff）。AgentOps SDK 引入了一种层级 span 模型，以智能体生命周期（lifecycle）而非孤立 API 调用为中心，将会话、智能体、操作或任务、工作流（workflow）、工具调用和大语言模型（LLM）调用组织起来 AgentOps AI (2026)。RagAI Catalyst 针对 RAG 和多智能体工作负载，提供浮现检索层面和智能体层面异常的质量与安全仪表板 RagaAI (2026)。Laminar 提供一个开源优先的智能体可观测性（observability）平台，融合追踪（tracing）、评估和提示词管理 Laminar AI (2026)。
学术界已开始将这些关切形式化。Moshkovich & Zeltyn (2025) 提出了一个六阶段 AgentOps 自动化流水线（pipeline）：观测、收集指标、检测异常、执行根因分析、推荐修复并自动化修复。他们进一步将利益相关方空间分解为四类角色：开发者、测试者、SRE 和业务用户，每类角色在不同生命周期（lifecycle）节点与该流水线（pipeline）交互。其配套实证研究 Moshkovich et al. (2025) 将任务流发现（task-flow discovery）作为可观测性（observability）原语引入，并通过用户研究表明，79% 的从业者将非确定性执行流视为智能体系统中最重大的挑战。
自然语言智能体 harness（Natural-Language Agent Harnesses，NLAH）框架 Pan et al. (2026) 及其配套的开源实现，以将 harness 本身作为一等研究对象这一互补视角补充了上述工作。通过系统性消融实验，作者量化了各个 harness 模块对下游智能体性能的独立贡献。这些模块包括工具注册表、权限系统、钩子、技能（skill）和上下文折叠。其对可观测性（observability）的启示在于：harness 不仅仅是被监控（monitoring）的对象，更是干预的来源——每个被消融的模块都是可观测性流水线（pipeline）可以调节和优化的旋钮。
认知可观测性（Cognitive observability）将智能体层面的监控（monitoring）从询问智能体做了什么延伸至询问为何这样做。Watson Rombaut et al. (2025) 正式引入这一概念，部署一个”代理智能体（surrogate agent）”，通过提示词归因逐步生成推理追踪（tracing）来复现主智能体的输出。在 MMLU 和 SWE-bench-lite 上使用 AutoCodeRover 和 OpenHands 进行评估时，Watson 证明恢复的推理追踪（tracing）可用于人工调试和自动修正，从而带来任务成功率的可量化提升。AgentLens Lu et al. (2024) 通过三面板可视分析系统闭合了这一可视化循环：用于智能体轨迹的概要视图（Outline View）、带因果弧（causal arcs）的视图，以及用于同步环境回放的 Monitor View。该系统将原始执行日志转化为层次化结构的行为叙事。一项包含 14 名参与者的用户研究表明，在复杂分析任务上，该系统显著优于仅支持回放的基准方案。claude-code-reverse 等更专业的可视化工具能够对特定编码智能体的交互链进行逆向工程分析，可作为理解 harness 层行为的研究素材 Yu (2026)。
7.3 成本追踪与优化
大语言模型（LLM）推理按 token 计费，而智能体（agent）harness 会放大成本敞口——单个面向用户的任务可能触发数十次 LLM 调用，每次调用都有各自的提示词组装、工具结果注入和响应生成过程。可观测性（observability）需求由此分为两个维度：追踪（tracking，了解 token 消耗在何处）与优化（optimization，用更少的 token 达到同等效果）。
在追踪层面，TensorZero 提供了一个统一的 LLMOps 栈，将网关、可观测性、实验和优化集成为单一服务，支持按调用和按任务进行成本归因 TensorZero (2026)。Helicone 采用极简方案，以零代码改动的直通代理（drop-in proxy）形式添加成本与延迟监控（monitoring），尤其适合希望获得成本可见性而无需部署完整可观测性平台的团队 Helicone (2026)。
在优化层面，FrugalGPT Chen et al. (2023) 提出了基础性框架，归纳出三类降本策略：提示词自适应、LLM 近似和 LLM 级联。研究表明，自适应级联可在将较简单的查询路由至低价模型的同时，将成本降低高达 98%，同时保持 GPT-4 的性能水平。GPTCache Bang (2023) 以语义缓存层对上述方案形成补充——在请求到达 LLM 之前拦截重复或近似重复的查询，利用嵌入相似度检索缓存响应。路由与缓存已成为生产级成本优化栈中反复出现的基础模块，可直接应用于 harness 级插桩，对每次工具调用和上下文组装步骤独立计量与路由。
QC-Opt Shekhar et al. (2024) 以质量感知框架扩展了路由范式，在预算约束下联合优化模型选择、token 数量和延迟，使用 BertScore 预测器在不调用目标模型的情况下估算输出质量。TALE Han et al. (2025) 发现的 token 弹性（token elasticity）现象揭示了一个重要细节：对思维链（chain-of-thought）推理设置过低的 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 万美元的年度节省）。
对 harness 工程师而言，这意味着成本可观测性必须跨越多个层次：API 层面的 token 追踪（Helicone、TensorZero）、应用层面的路由决策（FrugalGPT、QC-Opt），以及基础设施层面的资源利用（Dual-Pool、KV 缓存占用率）。Anthropic 关于智能体编程评估中基础设施噪声的研究 Anthropic (2026a) 提供了一个警示性补充：仅凭基础设施配置即可使基准测试（benchmark）得分偏移 6 个百分点（$p < 0.01$）。这一发现表明，成本优化与评估（evaluation）保真度紧密交织——削减资源以降低成本，可能在细粒度可观测性缺失的情况下悄然降低智能体性能。
7.4 可靠性工程
故障恢复、检查点/恢复、重试策略和会话恢复是 harness 层面的核心关切，决定了一个长时运行的智能体能否在瞬态故障中存活。当智能体跨越多个上下文窗口运行时，这些问题尤为突出——每个新会话启动时对之前发生的事情毫无记忆 Anthropic (2025d)。Anthropic 的 harness 工程研究识别出长时运行编程智能体中四种反复出现的故障模式：智能体试图一次性完成整个任务、智能体过早宣告项目完成、智能体在会话间使环境处于损坏状态，以及智能体将功能标记为已完成但未经适当测试。其两段式解决方案直接从 harness 设计层面而非模型改进层面应对这些可靠性问题 Anthropic (2025d)：使用初始化智能体将任务分解为结构化的功能列表并建立进度追踪产出物（包括 git 仓库、进度文件和初始化脚本），再由编程智能体逐项增量推进，同时保持干净的交接状态。
后续工作在此模式上进一步延伸。Anthropic 受 GAN 启发的三智能体架构（规划者、生成者、评估者）引入了冲刺合约（sprint contracts）和分离式自我评估，以应对智能体过度赞扬自身工作的倾向 Anthropic (2026c)。值得注意的是，作者证明 harness 复杂度应随模型能力同步演进：从 Opus 4.5 升级到 Opus 4.6 后，他们完全移除了冲刺构造和上下文重置机制，在保持输出质量的同时将成本从 200 美元降至 125 美元。这阐明了一个普遍原则：每个 harness 组件都编码了一条关于模型无法独立完成之事的假设，而随着模型改进，这些假设会逐渐过时。
在基础设施层面，Anthropic 的 Managed Agents 架构 Anthropic (2026b) 将”大脑”（harness + LLM）与”双手”（沙箱和工具）以及”会话”（持久化事件日志）解耦，使各组件独立可恢复。若 harness 崩溃，可使用 wake(sessionId) 从会话日志中的最后一个事件处重新启动新实例。若沙箱失败，harness 将该错误作为工具调用失败捕获并重新分配新的沙箱。凭证存储在外部密钥库中，从不进入沙箱。这一架构将所有组件从”宠物”（不可替代、需手工维护的实例）转变为”牲畜”（可互换、可自动重新配置的实例），是大规模可靠运行智能体的前提条件。
学术文献为可靠性工程必须应对的故障模式提供了分类体系。MAST Cemri et al. (2025) 在多智能体系统中识别出 14 种故障模式，聚类为系统设计问题、智能体间错位问题和任务验证（verification）问题（$\kappa = 0.88$）。AgentErrorTaxonomy Zhu et al. (2025) 按模块（记忆、反思、规划、动作、系统）分解故障，并揭示错误传播——单一根因故障级联影响后续决策——是核心可靠性瓶颈。其 AgentDebug 框架通过隔离根因而非处理表面症状，实现了任务成功率高达 26% 的相对提升。与此同时，Vinay (2025) 贡献了一个涵盖 15 种生产 LLM 部署特有隐性故障模式的系统级分类，包括版本漂移（version drift，模型更新悄然改变行为）、成本驱动的性能崩塌（cost-driven performance collapse，激进优化降低质量）以及多步推理漂移（multi-step reasoning drift，长序列中连贯性逐渐丧失）。QSAF Atta et al. (2025) 将认知退化（cognitive degradation）形式化为跨五个 LLM 平台验证的六阶段生命周期，揭示幻觉输出可被存入持久化记忆并在未来会话中复用，形成跨越会话边界的自我强化退化循环。
在运行时检测层面，SentinelAgent He et al. (2025) 将多智能体交互建模为图，并在全局、单点、多点三个层级使用 LLM-as-judge 结合人在环路策略优化对异常进行分类。AgentFixer Mulian et al. (2026) 在 IBM 的 CUGA 生产系统上部署了 15 条验证规则，实现了 64–88% 的问题检测率，并发现 38% 的任务失败源于解析错误——一种完全可通过确定性检查解决的故障模式。其实践启示是：智能体可靠性需要分层检测策略：针对结构性故障（工具调用格式错误、模式违规）的轻量级规则检查、针对性能漂移（延迟、token 用量、成本趋势）的统计监控（monitoring），以及针对推理故障（幻觉、计划-动作错位、过早停止）的 LLM 语义分析。
7.5 讨论：迈向统一可观测性
可观测性与评估的鸿沟。 LangChain 调研呈现的 89%/52% 差距折射出一种结构性脱节：追踪收集工具与评估（evaluation）框架在很大程度上由不同社区以不同界面独立开发。弥合这一鸿沟需要更紧密的整合，例如从生产故障追踪中自动生成回归（regression）测试用例，或将在线评估得分用作告警信号。LangChain 对深度智能体评估的自有分析 LangChain (2025a) 与 Anthropic 对基础设施噪声的量化研究 Anthropic (2026a) 均主张，评估与可观测性应作为单一反馈回路而非独立关切来统筹处理。
统一 LLMOps 栈。 TensorZero 和 Langfuse 等工具正朝着将网关、可观测性、评估和优化整合至单一平台的方向演进，以降低集成开销。NLAH 框架通过使 harness 本身模块化且可内省，进一步推进了这一目标——每个组件的贡献可通过消融实验量化。Anthropic 的 Managed Agents 架构则从基础设施视角出发，将 harness 组件虚拟化为可替换接口（execute()、emitEvent()、getEvents()），从而在不改变周边系统的前提下容纳未来的 harness 设计。
harness 即假设原则。 每个 harness 组件都编码了一条关于模型无法独立完成之事的假设 Anthropic (2026c)。随着模型持续改进，可观测性系统不仅需要检测智能体何时失败，还需要检测 harness 组件何时已成为不必要的开销。理想的可观测性系统应包含一个元监控层，追踪哪些干预措施（上下文重置、评估反馈循环、工具限制）仍属必要负载，从而在模型升级的同时持续简化 harness。
8 验证与评估（Verification and Evaluation，V）
验证与评估（V）是 ETCLOVG 的第六支柱（第 §1 节论断 2）。本章讨论的系统与基准测试均来自支撑论断 3 的 148+ 项目语料库。
图 11：按本章任务至反馈生命周期组织的大语言模型智能体验证与评估代表性工作。（原文图见 PDF 第 32 页）
8.1 Harness 评估作为任务至反馈生命周期
具备 harness 感知能力的评估应将报告的得分视为模型-harness 组合的属性，而非单独模型的属性。这促使评估协议要么跨模型保持 harness 固定，要么将 harness 配置作为显式实验因子 (Bölük, 2026a; 2026b)。我们将 harness 评估组织为一个任务至反馈生命周期（task-to-feedback lifecycle）：一个结构化过程，始于定义智能体被要求完成的任务，终于将评估结果反馈回 harness 的改进。图 12 总结了这一五阶段任务至反馈生命周期。该生命周期建立在传统 LLM 评估与智能体评估之间的关键区别之上。传统 LLM 评估主要对固定输入上的输出进行评分，而 harness 评估衡量的是一个执行片段：任务在环境中接地，智能体随时间推移与工具和状态交互，追踪被捕获，评估者同时对最终结果和达成路径作出判断 (Kapoor et al., 2025; Anthropic, 2026b; LangChain, 2025b)。
该生命周期的核心动机在于：评估基础设施噪声可伪装成模型故障——运行失败可能不仅反映模型局限性，还可能反映工具损坏、上下文过时、沙箱未重置、评估者不稳定或基准测试歧义等问题 (Kapoor et al., 2025; Hu et al., 2025a; Jimenez et al., 2024)。因此，评估应将智能体行为转化为结构化判断、故障归因（failure attribution）和回归（regression）反馈，而不仅仅是报告最终得分。
图 12：harness 评估的任务至反馈生命周期。第 V 节将验证与评估组织为五阶段质量控制循环：任务与基准测试接地（task and benchmark grounding）、执行前就绪性校验（pre-execution readiness validation）、受控执行与轨迹捕获（controlled execution and trace capture）、多层次判断与故障归因（multi-level judgement and failure attribution），以及持续回归与部署反馈（continuous regression and deployment feedback）。该图强调 harness 评估不仅应报告最终成功率，还应诊断故障来源并将所得证据反馈至系统性 harness 改进。（原文图见 PDF 第 33 页）
五阶段分解遵循智能体评估运行的因果路径。在评估智能体之前，基准测试必须明确任务、环境、工具、约束和成功标准。在执行之前，必须验证（verify）配置，以确保环境或评分器故障不会被误判为模型失败。在执行期间，harness 必须捕获使运行可诊断的追踪（trace）。执行之后，系统必须判断结果、轨迹（trajectory）和评估者可靠性，然后将故障归因至可能的 harness 组件。最后，所得诊断应反馈至回归测试和未来的 harness 修订。在这一视角下，评估不是一个终止性的评分步骤，而是对完整智能体 harness 的质量控制循环。
以下围绕五个阶段展开讨论。
- 任务与基准测试接地（Task and Benchmark Grounding） 定义评估内容：在何种环境中、使用何种工具、受何种约束、依据何种成功标准（§8.2）。
- 执行前就绪性校验（Pre-execution Readiness Validation） 检查沙箱、依赖项、工具、上下文状态、权限策略、预算和评分器是否在智能体运行前正确初始化（§8.3）。
- 受控执行与轨迹捕获（Controlled Execution and Trace Capture） 在可复现条件下运行智能体，同时记录模型输出、工具调用、状态变化、错误、重试、成本和延迟（§8.4）。
- 多层次判断与故障归因（Multi-level Judgement and Failure Attribution） 在结果、轨迹和评估者层面对运行进行评估，然后将可能的故障来源定位至 harness 栈中（§8.5）。
- 持续回归与部署反馈（Continuous Regression and Deployment Feedback） 将评估结果转化为回归测试、监控（monitoring）信号和针对后续 harness 修订的工程反馈（§8.6）。
8.2 阶段一：任务与基准测试接地
第一阶段追问被评估的内容。对于大语言模型（LLM）智能体而言，任务不仅仅是一个自然语言提示词，而是一个由环境状态、可用工具、允许动作、约束条件和成功标准共同定义的嵌入式问题。因此，任务接地（task grounding）是 harness 评估的基础：若环境和成功条件规定不明，后续得分便无法可靠解读。
8.2.1 软件工程与终端任务
软件工程基准测试是智能体评估中最成熟的形式之一，因为它们将真实任务与可执行的结果验证相结合。SWE-bench 将每个任务接地于真实的 GitHub issue 和仓库快照，然后通过运行测试来评估生成的补丁是否解决了该 issue (Jimenez et al., 2024)。Terminal-Bench 将这一思路延伸至命令行工作流，智能体通过编辑文件、运行命令、设置依赖项和解析失败来与终端环境交互 (Merrill et al., 2026)。这类基准测试的关键洞见是：强大的结果验证器需要强大的任务接地。只有在仓库状态、依赖项和预期成功标准被精确规定时，测试才能充当可靠的评估器。否则，测试失败可能反映无效补丁，也可能反映环境不一致或基准测试实例规定不明确。
8.2.2 网页、浏览器与计算机使用任务
网页和计算机使用基准测试将任务接地于交互式环境，其中成功由浏览器、桌面或应用程序状态变化来界定。WebArena 为自主智能体引入了真实的网页环境 (Zhou et al., 2024)；VisualWebArena 在此基础上增加了多模态网页任务 (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)。这一基准测试族的主要贡献在于覆盖广度：它测试 harness 是否能在任务类型、工具接口、状态表示、工作流和成功条件方面实现泛化。
8.3 阶段二：执行前就绪性校验
第二阶段追问评估能否公平且可复现地运行。这一阶段在基准测试排行榜上往往不可见，但对 harness 评估至关重要。在智能体开始运行之前，harness 必须验证环境、工具、上下文状态、权限边界、预算约束和评估者均已正确初始化。若缺少这一就绪性层，下游故障将难以归因：运行失败可能由智能体引起，也可能由评估配置引起。
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 工具、上下文与权限就绪性
就绪性校验（readiness validation）具有跨层性。工具就绪性检查 API、MCP 服务器、浏览器控件、shell 命令和文件操作是否可用且描述一致。上下文就绪性检查历史记录、记忆存储、草稿本和检索文档是否已重置或有意初始化。权限就绪性检查文件访问、凭证、网络访问和审批门禁是否符合基准测试规范。
该阶段将评估连接至工具、上下文和治理层。若工具描述在不同运行间发生变化，基准测试衡量的就不再是同一动作空间。若记忆或上下文未重置，智能体可能从泄漏的状态中受益。若权限过于严格，有能力的智能体可能因治理原因而失败；若权限过于宽松，不安全或利用基准测试的行为可能不被察觉。SWE-agent、SWE-ReX 和 OpenHands 等系统表明，工具暴露、shell 访问、浏览器权限、执行后端和运行时接口与评估设计密不可分：智能体-计算机接口决定了何种动作可行，进而决定了基准测试实际衡量的内容 (Yang et al., 2024; SWE-agent Team, 2024; Wang et al., 2025b)。因此，严格的评估 harness 应将工具注册表、上下文策略、权限策略、预算、超时、模型配置和运行时接口作为评估元数据记录。
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 阶段三：受控执行与轨迹捕获
第三阶段追问执行期间发生了什么。在传统 LLM 评估中，证据可能仅由单个输入-输出对组成。而在智能体评估中，追踪（trace）是一个多步轨迹（trajectory）：模型观测状态、进行推理、调用工具、处理工具结果、修改环境、处理错误，最终终止。受控执行和轨迹捕获（trace capture）因此是将基准测试运行转化为可诊断证据的必要条件。
8.4.1 受控推演与可复现执行
推演（rollout）是智能体评估的基本单元。它包括任务、模型配置、harness 配置、动作序列、中间观测值、最终状态和评分结果。受控推演固定了偶然变异的关键来源，包括环境状态、工具可用性、超时、预算、权限策略和评估者版本。当不确定性依然存在时，重复推演可以暴露方差而非将其隐藏在单一得分背后。
多个系统阐明了对可复现执行的需求。SWE-agent 将智能体暴露于仓库导航、文件编辑和测试执行等作为交互循环的一部分 (Yang et al., 2024)。OpenHands 将代码编辑、命令行执行、浏览器交互、沙箱执行和基准测试集成组合在一起 (Wang et al., 2025b)。SWE-ReX 对本地和远程沙箱 shell 环境进行抽象，使执行后端在不改变智能体逻辑的情况下可替换 (SWE-agent Team, 2024)。LangChain 进一步将深度智能体评估分解为单步验证、全轮评估和多轮模拟 (LangChain, 2025b)。这些系统共同表明，可复现性需要回放完整的模型-工具-环境交互，而不仅仅是重新运行一次模型调用。
8.4.2 追踪原生评估
轨迹捕获（trace capture）将二元评分转化为因果诊断。追踪原生（trace-native）的 harness 应记录模型输出、工具调用、工具结果、环境状态变化、上下文快照、错误、重试、恢复动作、token 用量、延迟和成本。这些追踪能够区分表面相似的失败：一个智能体可能始终找不到相关文件，而另一个智能体可能找到了文件但生成了无效补丁。它们还能揭示不良成功，例如利用基准测试、过度工具调用或权限违规。
HAL 将日志和追踪视为标准化智能体评估的一等产出物，使用大规模智能体日志来审查最终得分可能掩盖的行为 (Kapoor et al., 2025)。R2E-Gym 类似地将可执行轨迹与混合验证器相链接，同时用于测试时评估和训练时反馈 (Jain et al., 2025)。对于 harness 工程来说，追踪因此不是辅助的调试产出物，而是主要的评估数据。
8.4.3 成本、延迟与资源追踪
智能体评估不仅应报告质量，还应报告实现质量的成本。长时运行智能体可能通过花费更多 token、调用更多工具、更频繁重试或使用更强模型来提高成功率。因此，harness 层面的评估应追踪 token 用量、模型成本、挂钟延迟（wall-clock latency）、工具调用次数、重试次数和资源消耗。
与其仅按成功率对智能体排名，评估应暴露一个成功-成本-延迟前沿（success-cost-latency frontier）。HAL 明确将智能体评估定位为标准化且成本感知的 (Kapoor et al., 2025)，而 LangChain 的深度智能体评估指南则强调可复现环境和多粒度评估，以便比较成本-质量权衡 (LangChain, 2025b)。这对于已部署的智能体服务尤为重要，其优化单元是预算和延迟约束下的循环工作负载。
8.5 阶段四：多层次判断与故障归因
在受控执行和轨迹捕获之后，核心问题是如何判断运行结果，以及如果失败，如何定位故障来源。我们将阶段四定义为多层次判断（multi-level judgement）与故障归因（failure attribution）的组合过程。多层次判断在三个层面评估运行：最终结果是否正确、轨迹是否高效且符合策略，以及评估者本身是否可靠。故障归因随后利用这些信号来诊断故障最可能的源头，可能是模型、工具接口、上下文管理器、执行环境、编排循环、基准测试规范或评估者。这一阶段正是将 harness 评估与普通基准测试评估区分开来的所在：目标不仅仅是分配一个得分，而是将执行证据转化为可操作的工程诊断。
8.5.1 结果层面评估
结果层面评估（outcome-level evaluation）衡量最终任务目标是否实现。在软件工程中，这通常通过单元测试、回归测试或 issue 特定验证来操作化，例如 SWE-bench (Jimenez et al., 2024)。在终端任务中，结果评估可能依赖于最终文件、命令输出或特定任务检查器 (Merrill et al., 2026)。在浏览器和企业工作流基准测试中，结果往往取决于最终环境状态，例如表单是否已提交、工单是否已更新，或配置是否已变更 (Zhou et al., 2024; Drouin et al., 2024)。在 GAIA 等通用助手基准测试中，结果可以是答案字符串或结构化响应 (Mialon et al., 2023)。
结果层面评估的优势在于可扩展性和可解释性：它提供清晰的任务级成功信号，支持排行榜比较。其局限在于信息压缩。一个完整的执行片段被归约为单一值，掩盖了智能体是稳健地、安全地还是高效地完成了任务。因此，结果评估是必要但不充分的条件。它只能回答任务是否完成，却无法回答 harness 是否产生了可信赖的执行过程。
8.5.2 轨迹级评估
轨迹级评估（trajectory-level evaluation）衡量智能体所走路径的质量。它关注的是：智能体是否选择了合适的工具、是否合理地排列了动作顺序、是否避免了冗余调用、是否尊重了权限边界，以及是否在整个过程中保持了上下文一致性。在智能体评估中，这一层级与传统输出评估的偏差最为显著——最终答案可以是正确的，但轨迹却可能因消耗了过多 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)。
轨迹级判断对 harness 工程尤为有价值，因为它提供了从失败到修复的路径。如果智能体失败是因为选择了错误工具，则工具接口可能需要改进；如果它遗忘了先前的约束，则上下文层可能需要调整；如果它陷入循环无法恢复，则编排层可能需要引入生命周期控制。由此，轨迹评估（trajectory evaluation）将基准测试结果转化为针对各层的工程反馈。
8.5.3 评估器级评估
评估器级评估（evaluator-level evaluation）关注评估器本身是否可信。确定性验证器（deterministic verifiers），如单元测试或基于状态的检查器，具有可复现性、成本低且便于跨系统比较，但其覆盖面较窄，且难以为开放式任务设计。LLM-as-Judge 系统对自然语言输出和轨迹评估更为灵活，但引入了偏差、不确定性以及额外的成本。对于模糊或安全关键场景，人工审计（human audits）仍然不可或缺，但它们无法扩展到持续评估的规模。
G-Eval 表明，基于大语言模型（LLM）的评估器能够在自然语言生成（NLG）评估任务上更好地与人类判断对齐，同时也揭示了对 LLM 生成文本的偏向 (Liu et al., 2023b)。MT-Bench 和 Chatbot Arena 系统性地研究了 LLM-as-Judge 并识别出位置偏差、冗长偏差、自我强化偏差以及推理能力有限等问题 (Zheng et al., 2023)。近期综述进一步指出，可靠的 LLM-as-Judge 系统需要标准化、偏差缓解、一致性检验和元评估 (Gu et al., 2024)。
对于智能体 harness 而言，评估器级评估并非可选项。若评分器不稳定、测试具有非确定性，或 LLM 评判者存在偏差，评估噪声就会被误归因于智能体或模型本身。因此，健壮的 harness 应优先采用分层评分器：针对客观状态变化的确定性检查、针对语义或轨迹级评估的 LLM 评判，以及针对模糊或高风险场景的人工审计。评估器应被视为系统中需要测试的组件，而非系统外部的神谕。
8.5.4 跨 Harness 层的失败归因
失败归因（failure attribution）确定在一次运行被判定失败后，应修复哪些内容。一次失败的推演（rollout）可能源于模型推理、工具接口设计、陈旧或压缩的上下文、沙箱（sandbox）不稳定性、编排循环、基准歧义或评估器不可靠 (Kapoor et al., 2025; Hu et al., 2025a; Jimenez et al., 2024; LangChain, 2025b)。结果级信号指示目标是否达成；轨迹级信号揭示动作序列是否连贯、高效且符合策略；评估器级信号则指示分数本身是否可信。这些信号共同支持诊断而非单纯评分 (Kapoor et al., 2025; LangChain, 2025b)。
在实践中，归因很少是单一标签的分类问题。模糊的任务规范可能导致智能体选择错误工具；过度压缩的上下文可能使其遗忘约束；沙箱依赖问题可能触发增加成本的恢复行为；而不可靠的评判器则可能遮蔽有效的解决方案。因此，失败归因应被理解为对完整轨迹的诊断过程，而非附加在最终分数上的事后标签。第 4 阶段的输出因此不仅是一个判断，而是一份结构化诊断，可供第 5 阶段反馈到回归测试（regression testing）和 harness 改进中。
8.6 第 5 阶段：持续回归与部署反馈
最终阶段关注评估结果如何驱动下一次 harness 修订。智能体 harness 持续演进：提示词、工具模式（tool schemas）、MCP 服务器、上下文策略、沙箱镜像、编排循环、治理（governance）规则以及评判提示词均可能随时间发生变化。持续评估将基准测试结果和生产故障转化为 harness 本身的回归系统。
8.6.1 针对 Harness 变更的回归评估
回归评估（regression evaluation）应由 harness 变更和模型变更共同触发。工具描述、上下文压缩策略、沙箱镜像、权限规则或评判提示词的修改，均可能改变智能体行为或评估分数。由于 harness 各组件之间相互影响，局部改进可能引发全局性的回归。
实践中的模式是维护一套分层评估套件：针对工具模式和确定性验证器的单元级测试、针对局部决策的单步测试、针对端到端完成度的全推演测试，以及针对长时连贯性的多轮模拟。LangChain 的深度智能体评估指导方针体现了这种分层视角 (LangChain, 2025b)，而 Anthropic 则将评估定义为可在开发过程中运行的自动化测试，并配有显式评分逻辑 (Anthropic, 2026b)。
8.6.2 评估框架与 LLMOps 集成
通用评估框架为持续测试提供了可复用的基础设施。Promptfoo 支持提示词和 LLM 应用的回归测试；DeepEval 提供类单元测试的抽象；RAGAS 聚焦于检索增强生成（retrieval-augmented generation）的评估；lm-evaluation-harness 支持标准化的语言模型评估 (promptfoo contributors, 2026; Confident AI, 2026; Es et al., 2024; Biderman et al., 2024; Gao et al., 2021)。尽管这些工具并非全部为长时运行的智能体而设计，但它们为面向回归的 harness 评估提供了构建模块。
评估还应与可观测性（observability）相结合。生产轨迹可以转化为回归测试，评估失败可以成为可观测性信号。这一链路形成了闭环：从监控实际发生的事情，到构建能够复现并诊断问题的受控测试。
8.6.3 基于验证器的训练时评估
一个新兴方向将评估器不仅用作离线指标，还用作训练信号和优化目标。基于验证器的环境和强化学习风格的智能体 gym，包括 R2E-Gym 及各类验证器，使用环境反馈作为奖励或验证信号，以改进智能体训练和脚手架 (Jain et al., 2025; Prime Intellect, 2026)。这将评估从事后度量步骤转变为智能体训练、测试时适应和脚手架选择的主动组成部分。
Meta-Harness 将这一方向进一步延伸，将 harness 设计本身视为自动化搜索的对象 (Lee et al., 2026)。这一视角不再仅仅评估哪个模型在固定 harness 下表现最好，而是追问哪种 harness 结构、提示策略、工具接口或控制循环能产生更可靠的智能体行为。在这一框架下，评估不是流水线的终点，而是驱动 harness 自我改进的信号。
8.7 小结
验证（verification）与评估（evaluation）是将智能体行为转化为工程证据的层。我们将该层组织为一个任务到反馈的生命周期：第 1 阶段在真实环境和成功准则中锚定任务；第 2 阶段验证评估设置的公平性、有效性和可复现性；第 3 阶段执行受控推演并捕获轨迹；第 4 阶段在结果、轨迹和评估器三个层级对每次运行进行判定；第 5 阶段将结果反馈至持续测试和 harness 改进中。
这一生命周期将评估从排行榜机制重新定位为智能体 harness 的质量控制循环。最终成功率仍有参考价值，但已不再充分。对于长时运行的智能体，核心评估问题不再是”智能体是否成功”，而是：智能体是否成功或失败、所走路径是否可接受、评估器是否可信，以及接下来应改进哪个 harness 组件。
9 治理与安全（G）
图 13：代表性工作按本章安全分类组织，涵盖大语言模型（LLM）智能体的治理（governance）与安全（security）（原文图见 PDF 第 39 页）
本层关注如何约束智能体行为、确保其安全性并追究责任。LLM 智能体现已能够执行 shell 命令、发送电子邮件、提交代码并调用第三方 API；在生产部署场景中，一个核心问题是：应对哪些约束采取行动，以及当这些约束失效时由谁承担责任。在生产系统中，治理拥有独立的工具生态，包括权限引擎、策略语言、审计（audit）流水线和网关控制器。这一生态系统有别于第 6 和第 7 节所涵盖的生命周期钩子（hooks）和可观测性基础设施，因此在 ETCLOVG 分类体系中被作为独立层来处理。我们围绕五种机制展开论述：权限模型（permission model）与身份管理（identity management）（§9.1）、生命周期钩子（lifecycle hooks）（§9.2）、组件加固（component hardening）（§9.3）、声明式宪章（declarative constitution）（§9.4）以及审计基础设施（§9.5）。随后，我们将这些机制置于更广泛的智能体安全景观中（§9.6），并以开放研究方向作结（§9.7）。
9.1 权限模型与身份管理
任何智能体 harness 的第一个治理问题是访问控制：智能体可以访问哪些工具、文件、网络端点和系统资源？智能体工作负载使这一问题比传统的基于角色的访问控制（RBAC）或基于属性的访问控制（ABAC）更为复杂，因为所需的工具集通常取决于部署时未知的自然语言任务。文献围绕一个粒度轴展开：部署时固定的静态边界、每次工具调用时评估的上下文策略，以及跨越本地 harness 边界进行交互的跨边界权限。
静态权限边界。 生产编码智能体通常预定义权限范围，并要求对范围外的动作进行升级。Codex (OpenAI, 2025) 在具有受限文件系统和网络访问权限的沙箱（sandbox）中运行 shell 命令，而 Gemini CLI (Mullen & Salva, 2025) 将工作区范围内的文件访问与命令允许和拒绝列表相结合。这些边界易于检查，但无法表达依赖任务的意图。
超越固定规则需要能够表达每次工具调用的运行时上下文约束。
上下文依赖的权限控制。 Progent (Shi et al., 2025a) 引入了一种领域特定语言（DSL），其谓词涵盖工具名称、参数和环境状态。运行时在每次调用前评估这些谓词，允许最小权限（least privilege）策略根据角色、用户或会话动态变化。Conseca (Tsai & Bagdasarian, 2025) 更进一步，从受信任上下文生成特定任务的策略，并通过独立的确定性检查器来执行。策略生成与执行的分离至关重要：生成组件可以适应任务，而执行器保持可审计性。
上述方法均在单一智能体边界内运行。多智能体场景引入了访问控制和智能体身份方面的额外挑战。
身份管理与智能体间访问控制。 在授予访问权限之前，系统必须确定是谁在发出请求。South et al. (2025) 认为智能体需要经过认证的委托（authenticated delegation）：一个扩展 OAuth 2.0 和 OpenID Connect 的框架，使用用户 ID 令牌、智能体 ID 令牌和范围限定的委托令牌，将用户意图绑定到智能体特定的权限。这一令牌链将从人类委托人到智能体的问责轨迹变得可验证。SAGA (Syros et al., 2025) 在此基础上构建了面向多智能体场景的提供商中介架构：智能体通过加密一次性密钥注册，短期访问令牌在智能体间执行用户定义的联系策略。IsolateGPT (Wu et al., 2025) 则采用了一种架构方法，实现辐射状（hub-and-spoke）模型，每个第三方应用程序在独立的分支（spoke）中运行，拥有各自的 LLM、内存和工具访问权限。分支间通信经过受信任枢纽（hub）传递，使跨分支数据交换成为显式的治理决策，而非共享上下文窗口的附带副作用。
凭证管理。 智能体常规处理 API 密钥、会话令牌和一次性密码。将这些凭证暴露给 LLM 上下文会带来数据泄露风险。Skyvern (Skyvern-AI, 2025) 说明了一种通用模式：将密钥存储在保险库中，仅向 LLM 暴露占位符，并在执行认证操作的自动化层替换为原始值。未解决的问题是长时会话的密钥生命周期管理——令牌可能在轨迹执行过程中过期或被吊销，而续期凭证仍必须保持在模型上下文之外。
Web 级权限协调。 上述机制在单一 harness 的信任边界内运行，治理单一部署。跨组织交互场景中，智能体需要遍历第三方网站或调用其他方拥有的服务，其协调需求无法由任何单一 harness 独立执行。Marro et al. (2025) 提出了 agent-permissions.json，一个类似 robots.txt 的轻量级清单文件。网站所有者可以声明智能体可使用哪些 UI 元素、速率限制、并发约束，以及需要人工确认的操作。此类清单无法解决认证问题，但展示了治理如何开始跨越组织边界延伸。
开放挑战。 设计既具表达力又具可用性的权限模型是一个尚未解决的问题。过于严格的策略会降低智能体效用；过于宽松的策略则使治理失去意义。社区尚未就可跨 harness 实现移植的标准权限规范语言达成共识。关于动作应归因于人类操作员、智能体实例还是瞬态任务身份，也仍存在开放性问题 (South et al., 2025)。
9.2 生命周期钩子
权限模型定义了什么是被允许的。生命周期钩子（lifecycle hooks）定义了策略检查何时触发。许多 harness 在智能体循环的每个阶段暴露钩子点：规划之前、工具调用之前、工具执行之后以及响应交付之前。这些钩子允许在不修改智能体核心推理的情况下注入治理逻辑。图 14 展示了单次工具使用周期中的四个钩子点。
图 14：单次工具使用周期中的四个钩子点。实线框为智能体组件；虚线框为治理钩子。H1 在输入到达 LLM 之前进行验证，H2 在工具执行前验证提议的动作，H3 调节工具输出返回上下文的信息流，H4 对重要动作进行用户审批的门控（原文图见 PDF 第 41 页）
预执行钩子：输入护栏（guardrails）。 输入护栏在数据到达 LLM 之前进行验证。PromptShield (Jacob et al., 2024) 和 DataSentinel (Liu et al., 2025) 训练专用分类器，用于检测用户输入和检索内容中的提示注入（prompt injection）载荷。基于规则的检测器严格但脆弱。基于模型的检测器泛化性更好，但速度较慢且易受自适应攻击 (Andriushchenko et al., 2024; Nasr et al., 2025)。
下一个执行点位于 LLM 提议的动作与 harness 的工具执行之间。
预调用钩子：输出护栏与动作验证。 在执行工具调用之前，输出护栏检查 LLM 提议的动作。ShieldAgent (Chen et al., 2025b) 将安全约束形式化为可验证谓词，并对每个动作进行核验。在多智能体系统中，ControlValve (Jha et al., 2025) 约束智能体间的控制流图，防止未经授权的智能体转换，从而应对一个智能体将执行重定向到另一个智能体的控制流劫持攻击。
工具执行完成后，返回的数据在重新进入 LLM 上下文前也必须经过检查。
后执行钩子：信息流控制与污点追踪。 CaMeL (Debenedetti et al., 2025) 实现了基于能力的信息流控制。每个数据值携带追踪其来源的元数据标签，将受信任的用户输入与不受信任的 Web 检索内容区分开来。自定义解释器强制要求不受信任的数据不能影响控制流决策。CaMeL 以牺牲部分灵活性为代价，在 AgentDojo (Debenedetti et al., 2024) 上实现了更强的控制/数据流边界，将规划置于受信任上下文之上，而非不受信任的内容之上。
一种互补的执行机制将人类用户纳入循环。
人在回路钩子（Human-in-the-loop hooks）。 多个广泛使用的编码智能体——包括 Codex、Gemini CLI、Cursor 和 OpenHands (Wang et al., 2025a)——在显式用户审批时对破坏性或超出范围的动作进行门控。三个设计维度决定了这些钩子的形态：验证范围（哪些动作需要审批）、警报丰富度（用户看到多少上下文）以及重复策略（允许一次还是允许始终）。Felt et al. (2012) 发现，只有 17% 的 Android 用户在应用安装期间关注了权限对话框，仅有 3% 的用户正确回答了关于所授权权限的理解问题；智能体审批对话框可能面临类似的习惯化和理解风险。频繁的请求会导致用户条件反射式地批准危险动作，而不频繁的请求则留下覆盖空白。
部分系统将钩子视为可编程的执行底层，而非孤立的分类器。AgentSpec (Wang et al., 2026) 定义了在规划、工具调用和响应阶段触发的规则，包含触发条件、谓词和执行动作。AgentDoG (Liu et al., 2026a) 则从单动作分类转向轨迹级诊断，按来源、失败模式和后果对风险进行组织。
开放挑战。 在现有系统中，钩子 API 仍然是异构的。据我们所知，目前尚不存在为第三方治理模块定义通用钩子接口的广泛采用标准。钩子还会引入延迟，而叠加钩子之间的交互效应在很大程度上未经研究。一种可能的失败模式是：上游净化器（sanitizer）改变了下游检测器所依赖的信号，使得组合后的流水线比单独考虑任一组件时都更加脆弱。
9.3 组件加固
生命周期钩子在 harness 层面执行治理。组件加固（component hardening）则针对各个智能体组件——具体而言是 LLM 及其调用的工具——的特定漏洞进行强化。经过加固的组件能使 harness 受益，因为更少的恶意输入能够在第一时间触发治理钩子。
模型加固。 提示注入（prompt injection）的根本原因在于，LLM 以同等优先级处理所有输入文本，使其无法区分系统指令与不受信任的数据。Wallace et al. (2024) 提出了一种指令层级（instruction hierarchy），训练模型优先遵循特权指令（系统提示词）而非低权限指令（用户消息、工具输出）。模型学会在高层约束与低层指令一致时遵从后者，在二者冲突时忽略或拒绝低层指令。SecAlign (Chen et al., 2025a) 将相同的防御目标表述为偏好优化问题，针对提示注入输入、不良响应和不期望响应进行优化。
这些模型层面的防御与 harness 层面的钩子相辅相成。经过加固的模型在推理时能拒绝更多注入，从而降低下游护栏的压力。然而，单靠模型加固是不够的：它解决了 Kim et al. 分类体系中的错误指令遵从问题，但无法阻止不受约束的数据流或未经授权的动作，这些问题需要系统级执行 (Kim et al., 2026; Wei et al., 2026)。
基于分类器的运行时加固。 一种互补的方法是在不修改智能体 LLM 本身的情况下加固模型边界，通过在运行时部署小型辅助分类器来筛查输入和输出。Llama Guard (Inan et al., 2023) 对一个独立模型进行微调，用于对用户提示词和助手响应进行分类，对照可配置的安全分类体系，返回 harness 可据此进行允许、阻止或升级决策的每类别标签。此类分类器提供了训练时加固所缺乏的两个实用特性：分类体系可在不重训练智能体模型的情况下编辑，且同一检测器可跨异构 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 扩展了加密签名和版本控制的工具定义，确保对工具代码、模式或权限的任何修改都需要新的签名版本。这可以防止”地毯式抽换”（rug-pull）攻击——即一个已获批准的工具被静默更新以执行恶意动作。
协议级加固。 超越单个组件，SAFEFLOW (Li et al., 2025) 为多智能体系统引入了协议级执行。它将细粒度信息流控制与事务性执行语义相结合，使得违规工具调用或智能体间消息可以回滚，而非通过共享状态传播。
供应链风险。 智能体治理还必须关注智能体调用的工具和软件包。Spracklen et al. (2025) 分析了 16 个 LLM 的 576,000 个代码样本，发现开源模型以 21.7% 的比率产生幻觉式的不存在软件包名称。攻击者可在公共仓库注册这些被幻觉出的名称并注入恶意代码——这种技术被称为”slopsquatting”。ETDI 的加密签名解决了 MCP 工具的部分问题，但软件包管理器和检索来源在大多数智能体治理栈中仍未受到保护。
开放挑战。 模型加固和工具加固处理互补的威胁面，但目前尚无统一框架将二者连接起来。一个经过加固的模型仍可能调用一个已被攻陷的工具，而一个已签名的工具定义并不能阻止一个被越狱的模型滥用它。如何将这些防御组合成具有可量化残余风险的连贯栈，仍是一个开放问题。随着 MCP 的采用规模扩大，其安全扩展成为标准化的自然目标，但互操作性和认证在很大程度上仍悬而未决。
9.4 声明式宪章
将治理逻辑直接嵌入应用代码会使策略变得不透明、难以审计且难以更新。越来越多的 harness 将治理规则外化到声明式配置文件中，最常见的格式是 YAML。这些文件充当智能体的机器可读宪章（declarative constitution）。
训练时宪章：Anthropic 的 Constitutional AI。 Anthropic (Anthropic, 2026a) 发布了一部按四级优先层级组织的宪章：安全性（保护人类监督）、伦理（诚实、避免伤害）、合规（Anthropic 指导方针）和有用性（用户请求）。该宪章区分硬约束——例如对化学、生物、放射性和核武器（CBRN）协助的绝对禁止——与软编码默认值（操作员可在规定范围内调整）。在智能体场景中，这一结构建议了一种委托人层级：Anthropic 的策略覆盖操作员配置，操作员配置进而覆盖终端用户偏好。
训练时宪章通过在对齐和后训练阶段塑造模型行为来发挥作用。它们在训练时塑造模型行为，但难以在部署后修改，且无法由 harness 独立审计。一种截然不同的方法将治理规则外化到可部署时配置中，供 harness 读取、验证和执行。
部署时宪章：基于 YAML 的治理。 AutoHarness 仓库 (AIMing Lab, 2026) 将治理规则编码在一个 YAML 文件中，该文件指定流水线模式（核心、标准或增强）、风险分类模式、允许和拒绝的工具调用模式、token 预算限制以及审计日志目标。这种声明式风格将治理意图与执行逻辑分离。非开发者利益相关者（如安全团队和合规官员）可以在不触碰智能体代码的情况下审查和修改策略。与训练时宪章不同，YAML 文件可以使用标准工具进行更新、版本控制和差异比较，从而在不重训练或重部署模型的情况下进行策略更新。
两层在操作上存在差异。训练时宪章修改成本高昂，必须通过行为探测来推断；而部署时 YAML 是直接可读且可差异审查的。训练时对齐以概率方式塑造默认行为，可被对抗性提示词覆盖 (Andriushchenko et al., 2024)；部署时规则则作为 harness 检查执行。
当策略可简化为字面触发器时，基于模式的 YAML 规则已足够，但真实部署往往需要基于运行时状态的条件逻辑。当前的 YAML 模式未能标准化针对权限升级、基于主机的外部访问、会话级速率限制或未来动作的谓词。在自由形式 YAML 与硬编码规则之间，存在第三种设计点：结构化策略 DSL。
可编程策略语言。 Progent 的策略语言 (Shi et al., 2025a) 支持布尔谓词、量词和环境引用。它在保持可读性的同时提供了形式化表达能力。Formal-LLM (Li et al., 2024) 更进一步，将计划约束编码为下推自动机（pushdown automata）。这种形式化可以表达顺序排序约束、禁止的工具组合以及特定步骤所需的审批门控。VeriSafeAgent (Lee et al., 2025) 将用户意图形式化为基于 UI 状态转换的 DSL，验证在执行前所提议的 GUI 操作是否与用户任务对齐。YAML 宪法存在歧义性；形式化规范则需要专业知识。
开放挑战（Open challenges）。 目前尚无被广泛采用的智能体宪法标准 schema。每个 harness 倾向于定义自己的 YAML 结构，导致策略不可移植。用于验证宪法内部一致性（例如，无矛盾的允许/拒绝规则）和完整性（例如，无未处理的工具类别）的工具在当前生态系统中十分有限。训练时宪法与部署时宪法之间的交互尤为缺乏探索。RLHF 所强化的行为能否被 YAML 拒绝规则可靠覆盖、两层在何种条件下产生冲突，仍是一个具有实际安全含义的开放问题。
9.5 审计（Audit）基础设施
治理（governance）需要问责机制。审计（audit）基础设施记录智能体做了什么、为何这样做，以及治理策略是否得到遵守。这些记录支持事后调查、合规性监管和持续策略优化。
结构化审计轨迹（Structured audit trails）。 AutoHarness (AIMing Lab, 2026) 为每次工具调用生成 JSONL 记录，包含工具名称、参数、风险分类、权限决策、执行结果、token 消耗及挂钟延迟。这些结构化日志同时支持实时仪表板和离线取证分析。SAGA (Syros et al., 2025) 将审计轨迹扩展至多智能体交互，通过在智能体间交换的加密令牌实现跨信任边界的来源追踪（provenance tracking）。在上述系统中，一条可重放的审计记录至少需要包含：追踪标识符（trace identifier）、主体身份（principal identity）、工具调用（tool invocation）、策略决策及版本、执行结果、资源消耗，以及对相关输入输出的完整性哈希。然而，大多数现有系统仅记录上述字段的子集，签名或哈希记录极少，使审计轨迹容易遭受已被攻陷的智能体进程的日志篡改。
在记录之外，对长时间运行（long-running）智能体中的治理违规进行检测还需要自动化分析。
异常检测：单动作级别与轨迹（trajectory）级别。 检测机制依据评估证据的粒度分为两类。单动作（Per-action）检测器在孤立情境下对每次工具调用进行分类，依据的是已学习或已规定的风险概念：输入输出护栏（§9.2）在此模式下运作，AgentMonitor (Naihin et al., 2023) 提供了一种轻量的日志-标记实现。该模式开销低、易于审计，但无法识别跨多个单独良性动作分布的攻击，例如每分钟读取一个文件的慢速数据渗漏。轨迹级别（Trajectory-level）检测器则对动作序列进行联合评估。AgentAuditor (Luo et al., 2025) 将行为模式匹配与基于大语言模型（LLM）的完整轨迹推理相结合；SentinelAgent (He et al., 2025) 将多智能体通信建模为时序图，并标记异常的交互模式。轨迹级别检测能够发现多步攻击，但代价是较高延迟，以及对触发警报的具体动作定位较为模糊，这使得实时干预和事后解释都更加困难。在本文调研的系统中，单动作检查通常以内联方式部署，而轨迹级别分析则以异步方式在审计日志上运行。
除安全之外，长时间运行的智能体还需要成本与资源治理。
成本与资源审计（Cost and resource auditing）。 失控的智能体循环可能在密集循环任务中迅速耗尽 API 预算。2025 年面向大语言模型的 OWASP Top 10 (OWASP Foundation, 2025) 将资源耗尽列为一个独立的风险类别。AutoHarness (AIMing Lab, 2026) 通过其宪法以声明式方式跟踪每次调用的 token 消耗，并强制执行会话级预算。在多智能体架构中，成本感知治理尤为重要，因为扇出（fan-out）模式可能使 API 调用量呈指数级增长。
分层治理流水线（Tiered governance pipelines）。 一种新兴设计模式将上述机制（权限、钩子、宪法和审计）整合到单一可配置流水线中。AutoHarness (AIMing Lab, 2026) 通过三层架构体现了这一模式。各层逐步加深检查力度，从解析-风险-权限-执行-审计循环，到上下文丰富化、输出验证、异常评分、人工升级，再到形式约束验证。层级通过 YAML 宪法以声明式方式选择，因此治理开销与部署风险挂钩。其他生产实践指导将类似职责作为特性级控件而非命名层级来呈现 (Shavit et al., 2023)。哪种抽象更具可用性仍是一个开放的实证问题。
开放挑战（Open challenges）。 在长时间运行的智能体中，审计日志快速积累，引发存储、隐私和信噪比方面的挑战。日志可能包含敏感的用户数据、API 密钥或对话内容，在审计完整性与数据保护要求之间形成张力。社区目前也缺乏标准化的审计 schema，导致跨系统分析和监管报告十分困难。
9.6 将治理置于智能体安全格局中
治理机制是对具体威胁格局的响应。来自开放智能体平台的最新证据 (Zhang et al., 2026b; Kim et al., 2026; Chen et al., 2026; Wei et al., 2026) 表明，智能体安全不仅限于提示注入（prompt injection）或单智能体越狱（jailbreak）：社会工程（social engineering）、协同智能体集群、凭证泄露和平台级参与放大可以共同塑造威胁格局。Kim et al. (2026) 调研了 128 篇论文，整理了 51 种攻击手段和 60 种覆盖整个智能体栈的防御方法。Chen et al. (2026) 从软件工程视角对此进行了补充，综合了 50 篇论文，提出了一个六维分类法，并为安全-by-construction（以安全为设计原则）的智能体平台提出了参考原则。我们借助这些框架将治理机制与具体安全风险关联，并识别覆盖空白。
从设计维度到治理机制。 Kim et al. 识别了七个设计维度（输入信任、访问敏感性、工作流、动作、记忆、工具、用户界面），每个维度代表一个灵活性谱系。更大的灵活性扩展了攻击面，治理机制则在运行时约束该灵活性。权限模型绑定工具和动作；生命周期钩子（lifecycle hooks）将检查点注入工作流；宪法将约束外化；审计基础设施则提供反馈循环，揭示约束过于宽松或过于严格的情况。表 3 将治理机制映射到 Kim et al. 分类法中的七个风险类别（R1–R7）。
表 3：治理机制与 Kim et al. (2026) 风险分类法的对应关系（原文表格见 PDF 第 45 页）
| Governance Mechanism | Risks Mitigated or Detected |
|---|---|
| Permission models and identity mgmt. | R1（不可信接口）、R5（数据泄露）、R6（未授权动作） |
| Input guardrails | R1、R2（错误指令遵循） |
| Output guardrails | R2、R4（幻觉）、R5、R6 |
| Information flow control | R3（无约束数据流）、R5、R6 |
| Component hardening | R1、R2、R4 |
| Monitoring and audit | R5、R6、R7（资源耗尽） |
| Human-in-the-loop | R2、R6 |
| Privilege separation | R2、R3 |
| Formal verification | R2、R6 |
| Declarative constitution | 横切关注点（Cross-cutting）：配置上述所有机制 |
真实智能体中的防御空白（Defense gaps in real-world agents）。 Kim et al. 对六个智能体系统（Codex、Gemini CLI、OpenHands、Browser Use、Nanobrowser、Skyvern）的案例研究表明，没有任何一个智能体完整实现了所有防御类别。信息流控制、身份管理和形式化验证（formal verification）在所有被调研的系统中均缺失。六个系统的监控均不完整：智能体记录工具调用，但缺乏自动化异常检测。AutoGPT 的案例研究说明了下游补丁的后果：可以解决个别症状，但上游的输入验证（input validation）、信息流控制和策略组合始终规格不足。
纵深防御及其局限性。 Kim et al. 认为，智能体安全需要相互补充的分层防御：输入护栏作为第一道防线，输出护栏作为最后防线，信息流控制和监控提供运行时保护，访问控制用于认证和授权，人在回路中（human-in-the-loop）用于关键决策。然而，分层并非没有代价：如 §9.2 所述，协调不当的层次可能相互干扰，独立治理钩子的可组合性在很大程度上尚未经过检验。在此框架下，治理可以作为编排层，帮助防御机制协作而非冲突。
情境安全作为拟议扩展（Contextual security as a proposed extension）。 Kim et al. (2026) 提议将情境安全（contextual security）作为智能体系统的第四个安全目标候选，与经典的保密性-完整性-可用性（CIA）三元组并列。该提议是近期且特定于其调研的；它尚未被 NIST 等标准机构或主流安全教材采纳，我们在此将其视为一种有用的框架，而非已定论的定义。Conseca (Tsai & Bagdasarian, 2025) 和 CaMeL (Debenedetti et al., 2025) 阐明了工程方向：上下文必须被视为受治理的状态，而非被动的提示材料。这是否值得提升为独立安全目标，仍有待定论。
9.7 研究方向
表 4 总结了本节所讨论系统中治理的现状。
表 4：治理特性覆盖情况。● = 完整支持，◑ = 部分支持，○ = 缺失（原文表格见 PDF 第 46 页）
| System | Perm. | Hooks | Harden. | Constit. | Audit | Multi-Ag. |
|---|---|---|---|---|---|---|
| Codex | ● | ◑ | ○ | ○ | ◑ | ○ |
| Gemini CLI | ● | ◑ | ○ | ○ | ◑ | ○ |
| OpenHands | ◑ | ● | ○ | ○ | ◑ | ◑ |
| AutoHarness | ● | ● | ◑ | ● | ● | ◑ |
| Progent | ● | ● | ○ | ◑ | ○ | ○ |
| CaMeL | ◑ | ○ | ○ | ○ | ○ | ○ |
| SAGA | ● | ◑ | ○ | ○ | ● | ● |
| IsolateGPT | ● | ◑ | ○ | ○ | ○ | ● |
| AgentSpec | ◑ | ○ | ○ | ● | ○ | ○ |
| SAFEFLOW | ◑ | ● | ◑ | ○ | ● | ● |
表 4 中显现的稀疏性表明，治理基础设施在安全部署中往往是实际瓶颈，与模型局限性并列。我们识别出八个开放研究方向，此处仅列举治理特有的空白，并与 §12 中更广泛的开放问题交叉引用。
(1) 标准化策略与审计语言（Standardized policy and audit languages）。 每个 harness 定义自己的 YAML schema 和私有 DSL，使治理生态系统碎片化。类似于 MCP (Anthropic, 2024c) 正在为工具接口所推动的社区驱动规范，将能够实现可移植策略、可组合治理模块和跨 harness 审计互操作性。
(2) 形式化治理保证（Formal governance guarantees）。 当前治理机制在形式保证方面仍十分有限。对智能体行为的形式化验证尚处于早期阶段 (Li et al., 2024; Chen et al., 2025b; Lee et al., 2025)。将这些技术扩展以验证治理流水线的正确性——例如，证明宪法内部一致且覆盖所有工具类别——仍缺乏充分探索。
(3) 自适应治理（Adaptive governance）。 静态策略无法预见每种任务上下文。Conseca (Tsai & Bagdasarian, 2025) 表明，大语言模型生成的策略可以弥补这一差距。机器生成治理规则的可信度，以及此类策略生成器本身应如何被治理，仍是开放问题。
(4) 面向长时间（long-horizon）智能体的治理。 执行多小时或多天任务的智能体会引入上下文漂移（context drift）、跨会话状态和不断演变的信任假设。许多现有治理流水线是为单轮或短会话智能体设计的。将其扩展至长时间自主运行，需要治理规则能够在不断演化的会话过程中被更新、撤销和审计。
(5) 可用治理界面（Usable governance interfaces）。 可用的治理界面对于实际部署不可或缺。该领域需要针对权限界面、审计仪表板和宪法编辑器的人机交互（HCI）研究，使其对非专业用户同样易于访问。移动权限领域的先期工作表明，审批对话框在智能体场景中的迁移效果不佳 (Felt et al., 2012)，但针对智能体的专项研究仍有待开展。
(6) 跨层治理一致性（Cross-layer governance coherence）。 训练时对齐（宪法 AI）、部署时配置（YAML 宪法）和运行时执行（生命周期钩子）在不同层次、以不同保真度运作。这些层如何组合，以及运行时治理能否可靠覆盖训练时的倾向，仍是开放问题。
(7) 端到端供应链治理（End-to-end supply chain governance）。 MCP 安全扩展（如 ETDI (Bhatt et al., 2025)）在单个 harness 内解决了工具完整性问题。然而，智能体还依赖于外部包、数据集和检索来源，其来源难以验证。包幻觉攻击（package hallucination attacks）(Spracklen et al., 2025) 表明，大语言模型可能无意中引入供应链妥协。覆盖完整工具和数据供应链（从包仓库到智能体执行）的治理框架仍十分有限。
(8) 治理栈的统一对抗性基准（Unified adversarial benchmarks for governance stacks）。 现有基准针对的是较窄的威胁类别，如提示注入、轨迹诊断或 MCP 服务器漏洞 (Debenedetti et al., 2024; Liu et al., 2026a; Radosevich & Halloran, 2025)。没有任何基准在共同对手模型下对完整治理栈进行统一评估，并具备可复现的攻击轨迹。社区基准需要联合报告防御有效性、误报率和开销，而非孤立地分别报告。
10 横切关注点（Cross-Cutting Concerns）
本节收录的关注点横跨 ETCLOVG 多个层次，通过展示层特定推理失效之处，发展了主张 1（智能体 harness 作为独立系统层，§1）。各章节将执行、工具、生命周期、可观测性（observability）、评估和治理分别隔离，以便每个设计面都能被精确描述。然而，生产 harness 最常在这些面的接口处出现失效。
层间交互模式（Inter-layer interaction patterns）。 七个层次并非相互独立。执行环境（E）约束着哪些生命周期和编排策略（L）是可行的；上下文管理（C）影响评估可复现性（V）；治理（G）施加身份、权限和审计约束，横跨所有其他层。因此，harness 设计应被理解为一个依赖结构，而非一份可分离组件的清单。
成本-质量-速度三难权衡（The cost–quality–speed trilemma）。 更强的沙箱、更忠实的执行环境（E）通常提高安全性和可复现性，但会增加启动延迟和基础设施成本；更丰富的上下文和记忆策略可以改善任务连续性，但消耗 token 并引入检索开销；更深入的评估和可观测性改善了诊断，但会减慢迭代速度并增加存储、标注和追踪处理成本。因此，生产系统不能将质量视为一个标量目标，必须决定哪些风险值得昂贵的控制措施、哪些检查可以异步运行、哪些失败需要代价高昂的恢复路径。
标准化与生态系统动态（Standardization and ecosystem dynamics）。 MCP、ACP 和 A2A 等协议反映了一种压力，即趋向于为工具、智能体和编排状态提供共享接口。这种压力有利于智能体无关的基础设施，而非单一智能体集成，但同时也将责任转移到治理和可观测性上：一次标准化工具调用只有在周围的 harness 能够保存来源、权限、成本和跨系统的失败证据时才有意义。
持续性生态系统空白（Persistent ecosystem gaps）。 在整个语料库中，有五类空白在层边界处反复出现：跨工具互操作性、成本归因、失败恢复、多仓库编排和人机交接（handoff）。这些空白推动了 §11 中的综合：核心问题不再是每个层是否有可用工具，而是组合后的 harness 是否作为可靠的控制系统运作。
11 跨层综合（Cross-Layer Synthesis）
本节将 §10 的横切关注点整合为五个系统级效应，是支持主张 1（§1）的核心论据。其目的是将讨论从组件覆盖转向 harness 行为：一旦执行、工具、上下文、编排、可观测性、评估和治理被组合在一起，它们的交互就会产生任何单一层都无法独自解决的约束。
11.1 成本-质量-速度三难权衡（Cost-Quality-Speed Trilemma）
Harness 可靠性受制于成本、质量和速度之间的三路权衡（tradeoff）。更强的沙箱和更忠实的执行环境提高了安全性和可复现性，但增加了启动延迟和基础设施成本；更丰富的上下文和记忆策略可以改善任务连续性，但消耗 token 并引入检索开销；更深入的评估和可观测性改善了诊断，但减慢了迭代速度，并增加了存储、标注和追踪处理成本。因此，生产系统不能将质量视为一个标量目标，必须决定哪些风险值得昂贵的控制措施、哪些检查可以异步或在回归测试套件中运行、以及在智能体生命周期的每个阶段值得捕获哪些遥测数据。
11.2 能力-控制权衡（Capability-Control Tradeoff）
更强大的 harness 赋予智能体更多权限，但每一次权限增加都扩大了控制问题。更大的工具菜单拓宽了任务覆盖范围，同时增加了选择错误和提示注入攻击面；持久化记忆有助于长时间运行任务，但带来了来源、过时性和隐私风险；宽松的沙箱使自主执行更为便利，但同时扩大了对齐偏差或被攻陷动作的爆炸半径（blast radius）。因此，能力-控制权衡并非功能性系统的安全附加项，而是一个设计轴心，将工具 schema、上下文策略、运行时权限、身份、可审计性和人工审批联系在一起。
11.3 Harness 耦合问题（Harness Coupling Problem）
Harness 各层以使局部优化变得脆弱的方式相互耦合。执行环境通过影响包可用性、重置语义、延迟和失败模式来改变评估结果；工具描述消耗上下文预算并塑造模型行为；可观测性追踪（traces）仅在身份和权限状态以相同粒度被捕获时才能成为治理证据；评估设计通过奖励某些恢复循环并惩罚另一些，反馈到编排中。这些耦合意味着，harness 变更应作为系统变更进行测试。一个提示、工具、记忆、沙箱、验证器（verifier）或监控器，在孤立情境下看起来可能有益，但与控制循环的其余部分组合时，可能会降低整体效果。耦合问题还解释了为何智能体得分无法干净地归因于模型，而不指定周围的控制器。在闭环框架下，对上下文策略、工具 schema、验证器或恢复循环的变更都会改变控制器 $C_H$，从而改变同一模型被测量到的行为 (Bölük, 2026b)。
11.4 从智能体框架到智能体平台（From Agent Frameworks to Agent Platforms）
生态系统正从智能体框架向智能体平台（agent platform）演进。框架封装了智能体、工具、记忆存储和执行循环等本地抽象；平台则增加了持久工作区（workspaces）、托管沙箱、身份、计费、可观测性、评估、治理和跨多次运行、多用户的人机交接（handoff）。这一转变意义重大，因为长时间运行的智能体不再只是调用模型的程序，而是需要租户管理、合规、故障恢复、追踪保留和组织所有权的运营系统。因此，核心设计问题从”我如何构建一个智能体？”转变为”我如何操作一个智能体舰队，使其动作在时间维度上保持可检视和可逆？”
11.5 开放研究议程（Open Research Agenda）
综合分析指向一个以 harness 作为自适应控制系统的研究议程。该领域需要：能够区分 harness 干预而非仅模型权重的基准；跨层归因失败、在智能体-工具-沙箱-评估器-人类之间转移状态和责任的追踪原生方法；以及随着模型改进而简化 harness 的优化方法。下一节将这些横切效应转化为五个开放问题：如何加固和扩展执行环境、维护可靠状态、从追踪中诊断失败、标准化交接，以及在模型能力变化时保持 harness 的有效性。
12 开放问题与未来方向（Open Problems and Future Directions）
本节收集的开放问题来源于约束性主张（binding-constraint thesis）和跨层综合，构成了主张 1（§1）前瞻性证据的组成部分。与将七个 ETCLOVG 层视为独立组件清单不同，本节追问整个 harness 在科学上仍有哪些不足。核心模式在于：智能体 harness 正在成为长时间运行的控制系统，但该领域仍缺乏用于加固执行基础、保存状态、诊断失败、转移责任以及随模型能力变化更新 harness 的成熟答案。我们将这些空白组织为横跨分类法的五个问题。
12.1 加固与扩展执行环境（Hardening and Scaling Execution Environments）
执行环境正在成为安全性、可扩展性和可移植性的交汇控制边界。SandboxEscapeBench 记录了前沿模型可在真实配置下利用沙箱弱点 (Marchand et al., 2026)，但防御工作仍分散在具有不同威胁模型和评估协议的系统之间 (Wu et al., 2025; Yan, 2025)。与此同时，每容器一任务（one-container-per-task）模式在并行轨迹数以万计时对大规模任务模式造成压力；SWE-World 指向无需 Docker 的代理执行环境，但已学习的状态转移与真实执行的保真度仍未解决 (Sun et al., 2026)。即便是部署可移植性也并非已解决的工程细节：基于 Docker 的沙箱继承了 Linux 内核假设，而 macOS、Windows、浏览器、桌面和混合云环境则暴露了不同的隔离性和可复现性约束。
开放问题在于，如何使运行时基底（runtime substrate）既可度量又可组合。未来的 harness 需要：用于提示注入、目标错位和组合放大的通用安全评估；决定何时使用容器、microVM、OS 级权限边界、完整桌面虚拟机、浏览器环境或已学习代理环境的成本模型；以及跨自托管、云和混合部署保留语义的可移植性层。框架集成运行时（§3.2.4）与沙箱抽象（§3.2.7）之间的捆绑-vs-组合分割，应被视为一个实证设计问题，而非产品偏好。MCP 等标准可能降低组合成本，但前提是工具、治理和可观测性层暴露足够的状态，以使运行时选择保持可审计、可恢复和安全。
12.2 在长时间运行的智能体中维护可靠状态（Maintaining Reliable State in Long-Running Agents）
最深层的上下文问题不仅仅是如何将更多 token 塞入提示，而是如何让智能体的工作状态在长时间运行中与真实任务状态保持对齐。长时间运行的编码、研究和运营智能体反复进行摘要、检索、压缩和外化信息；每一次此类操作都可能删除约束、扭曲优先级或保留过时的假设。近期的上下文工程工作将压缩、工具结果清除、检索和提示缓存感知排序视为管理有限上下文窗口的实用机制 (Anthropic Applied AI Team, 2025; Anthropic, 2025c; OpenAI, 2026b)。然而，上下文腐化（context rot）和记忆基准表明，更长的输入和更丰富的记忆存储并不自动意味着更好的任务状态追踪 (Hong et al., 2025; Tan et al., 2025; He et al., 2026)。
因此，一个有原则的研究议程应将上下文管理重新定义为状态估计（state estimation）。开放问题在于，我们是否能够量化在每次压缩、检索或遗忘步骤中丢失了多少与任务相关的信息，以及我们是否能够界定智能体内部状态与任务真实状态之间的散度。近期综述将智能体记忆形式化为写-管-读循环，并将策略学习（policy-learned management）识别为一种新兴机制族 (Zhang et al., 2025; Du, 2026)。未来系统需要不确定性感知的摘要、针对记忆事实的来源追踪、矛盾处理、显式过时性标记，以及允许智能体从持久工件（durable artifacts）而非其自身压缩历史重建丢失状态的恢复程序。这也暗示了记忆与评估之间更紧密的联系：记忆策略不应仅由召回准确性来评判，还应由其是否能在多会话任务中防止下游动作错误来评判。
12.3 从智能体追踪中诊断失败（Diagnosing Failures from Agent Traces）
智能体评估仍过于以最终分数为中心：一次运行通过或失败，最终数字被视为模型质量的证据。对于 harness 工程而言，这是不够的，因为一次失败的执行可能源于模型推理、误导性工具 schema、沙箱配置错误、过时上下文、不稳定测试、基准歧义、评判不稳定性或编排循环。Anthropic 对智能体编码评估的分析表明，基础设施设置可以显著影响基准分数 (Anthropic, 2026a)，而近期关于智能体评估中随机性的工作认为，单次运行通过率可能隐藏了相当大的方差 (Bjarnason et al., 2026)。因此，评估层必须被作为一种测量工具来研究，而不仅仅是一个排行榜生成器。
下一步是追踪原生评估（trace-native evaluation）：追踪应成为系统从中计算结果分数、轨迹质量、失败归因和回归测试的主要对象。可观测性系统已经捕获了 span、工具调用、成本、重试、异常和中间消息 (OpenTelemetry, 2026; AlSayyad et al., 2026; Koc et al., 2025)，但这些追踪往往与评估流水线脱节。LangChain 的 2026 年调研报告称，89% 的团队使用可观测性工具，而只有 52.4% 运行离线评估 (LangChain, 2026a)；这一差距意味着团队可以看到智能体做了什么，却不能系统地判断该行为是否正确。未来工作应通过以下方式弥合这一循环：将异常生产追踪转化为回归案例，直接在 span 上计算轨迹指标，并将诊断信号反馈到提示、工具、上下文和编排变更中。Reflexion 表明智能体可以在短时间运行场景中从自身追踪中学习 (Shinn et al., 2023)；将这一思路扩展到长时间运行的多会话 harness 仍是开放问题。
12.4 跨智能体、工具和人类的标准交接（Standard Handoffs Across Agents, Tools, and Humans）
现代 harness 越来越多地将工作分布到规划器、子智能体、工具、沙箱、评估器和人类之间，但这些参与者之间的接口仍是临时性的。已有一些新兴本地标准：MCP 标准化工具访问，A2A 针对智能体间通信，OpenTelemetry 提供追踪的通用基底 (Model Context Protocol, 2025b; A2A Project, 2025; OpenTelemetry, 2026; Ehtesham et al., 2025)。缺失的是一个跨层的交接（handoff）合约。当规划器将工作交给执行器、智能体调用工具、子智能体返回控制权，或系统将问题上报给人类时，交接不应只传递文本摘要，还应传递意图、约束、权限、工件、来源、预算状态、风险级别、追踪历史和未决定策略。
这一问题部分是技术性的，部分是制度性的。OpenAI 的 Symphony 将问题跟踪器和仓库定位为智能体工作的控制平面，而 Anthropic 的长时间运行智能体 harness 则强调持久进度工件和干净的交接状态 (Kotliarskyi et al., 2026; Anthropic, 2025d; 2026b)。治理工作从相反方向得出了相同结论：在智能体代表用户跨系统安全行动之前，需要身份、委托、权限清单和可审计性 (South et al., 2025; Marro et al., 2025; Syros et al., 2025)。开放问题在于，如何定义既足够丰富以保证安全和可恢复性、又足够简单以广泛采用的交接协议。此类协议应使责任明确：谁授权了该动作、传递了哪些状态、哪些证据支持当前计划、接收方被允许做什么，以及何时必须将控制权返回给另一个智能体或人类。
12.5 在模型改进时保持 Harness 的有效性（Keeping Harnesses Useful as Models Improve）
Harness 设计不应被假设为单调地趋向更多脚手架（scaffolding）。每一个封装器、重置机制、验证器（verifier）、规划器、记忆规则和权限门都编码了关于模型无法可靠自主完成某事的假设。随着模型能力的变化，harness 干预应该被重新评估，而非假设其持续有益。针对模型-by-harness 的因子评估可以揭示一项干预何时改善了所有模型、只帮助了特定模型族，或逆转了模型排名 (Bölük, 2026b)。Anthropic 在长时间运行的应用程序开发中报告了这一模式的具体案例：对某个模型有用的上下文重置，对更强的模型来说变成了多余的，移除它们在不降低质量的情况下降低了成本 (Anthropic, 2026c)。OpenAI 同样将 harness 工程定义为一门学科，核心在于保持人类注意力、仓库状态和智能体执行的对齐，而不仅仅是添加更多脚手架 (OpenAI, 2026a;b)。
这创造了一个元工程（meta-engineering）议程：harness 需要优化和简化自身的机制。Meta-Harness 表明提示、工具和控制循环可以被作为优化目标的一部分进行搜索，而非由手工固定 (Lee et al., 2026)，而自然语言智能体 harness 使 harness 模块显式且可消融 (Pan et al., 2026)。TensorZero、Axon 和 AgentOps 等生产可观测性和成本系统指向预算感知的 harness 运营 (TensorZero, 2026; harshkedia177, 2026; AgentOps AI, 2026)，但研究问题比成本最小化更宽泛。未来系统应识别哪些干预是质量、安全或可靠性的因果因素；在 harness 变体上运行影子模式（shadow-mode）或 A/B 测试；并在质量-延迟-成本-风险的联合约束下进行优化。一个核心风险是基准过拟合：仅针对狭窄测试套件进行自我优化的 harness 可能变得脆弱。更持久的目标是自适应简化（adaptive simplification），即 harness 随着任务、工具和模型能力的变化，持续追问哪些控制措施仍然必要。
13 结论（Conclusion）
本综述将智能体 harness 视为一个独立的工程面，并论证：基础设施质量而非模型能力本身，决定了真实世界智能体可靠性的上限。围绕这一约束性主张，我们提出三个主张。七层 ETCLOVG 分类法将可观测性（Observability）和治理（Governance）从生命周期钩子（Lifecycle Hooks）中分离出来，反映了生产团队实际组织其工具和所有权的方式。将 148 个以上开源项目映射到该分类法，提供了迄今最全面的生态系统快照，揭示了采用模式、覆盖空白和新兴设计原则。三阶段工程演进——从提示到上下文，再到 harness 工程——加上覆盖成本-质量-速度三难权衡、能力-控制权衡和 harness 耦合问题的跨层综合，将 harness 置于更宏观的工程轨迹中。本研究语料库存在局限性，偏向于英语、GitHub 可见的开源项目，以及面向编程智能体的生态系统；将其扩展到闭源生产系统和非编程智能体生态系统将深化实证图景。分类法本身是描述性的：将 ETCLOVG 转化为规范性框架，以指导 harness 设计决策（而不仅仅是对其分类），是我们希望本综述能够推动的自然下一步。
参考文献
(参考文献列表请参见原文 PDF 第 52–66 页,此处不再翻译。)
附录 A：完整生态系统映射（Full Ecosystem Mapping）
表 S1 给出了本综述所使用的技术生态系统映射。目录快照已于 2026-05-08 完成核实，共收录 171 个公开条目，其中 146 个来自 GitHub，142 个属于项目类别，0 个链接失效。在论文正文附录中，仅保留技术性制品（artifact）及七个 ETCLOVG 层（纯阅读资源、生态系统地图、通用列表仓库以及仅含教程或手册的资源均已排除）。原有参考实现条目已按其主导 ETCLOVG 层归并，目录标签和星标快照均来自上述核实版本。附录 B 对六个核心实现作进一步展开。
表 S1：精选技术生态系统目录，每个制品标注一个主要 ETCLOVG 层。
| 制品（Artifact） | 主层（Primary layer） | 目录标签（Catalog tags） | 星标数（Stars） |
|---|---|---|---|
| 执行基底与沙箱（Execution Substrates & Sandboxing） | 20 个条目；主层：E — 执行与沙箱（Execution & Sandboxing） | ||
| 协议、工具接口与智能体契约（Protocols, Tool Interfaces & Agent Contracts） | 12 个条目；主层：T — 工具接口与协议（Tool Interface & Protocol） | ||
| 上下文与工作状态工程（Context & Working-State Engineering） | 9 个条目；主层：C — 上下文与工作状态（Context & Working State） | ||
| Harness 架构与编排（Harness Architecture & Orchestration） | 47 个条目；主层：L — 生命周期与编排（Lifecycle & Orchestration） | ||
| 可观测性与可靠性运营（Observability & Reliability Operations） | 15 个条目；主层：O — 可观测性与运营（Observability & Operations） | ||
| 评估 Harness 与基准测试（Evaluation Harnesses & Benchmarks） | 21 个条目；主层：V — 验证与评估（Verification & Evaluation） | ||
| 护栏、安全与治理（Guardrails, Security & Governance） | 14 个条目；主层：G — 治理与安全（Governance & Security） |
(表中具体条目为英文项目名与标签，请参见原文 PDF 第 67–70 页。)
附录 B：参考 Harness 实现（Reference Harness Implementations）
表 S2 对六个被请求作重点比较的参考实现进行了梳理。各条目以机制为导向，而非产品营销摘要：每行仅列出可由所引公开仓库、论文、文档或工程博文所支撑的声明。
表 S2：参考 harness 实现及其经文档记录的 ETCLOVG 覆盖情况。
| 实现及来源（Implementation and source） | Harness 模式与层（Harness pattern and layers） | 对本综述的设计启示（Design signal for this survey） |
|---|---|---|
| Claude Code (Anthropic, 2025a;b) | 终端编码智能体；单智能体编辑、调试与 Git 循环。层：E, T, C, L, G | 高自主本地编码工作流的生产级参考：代码库感知提示、shell/工具执行、仓库编辑，以及显式权限或沙箱边界均被视为 harness 职责。 |
| OpenCode (Anomaly, 2025) | 开源终端编码智能体，支持规划/构建角色、子智能体委托、LSP 集成与客户端-服务器运行时。层：E, T, L | 现代终端智能体循环的可检视实现，尤其在角色分离、子智能体委托及编辑器/工具集成方面对外公开，适合参考。 |
| Codex CLI (OpenAI, 2025; 2026b;a) | 终端原生编码智能体；无状态重放导向的单智能体循环。层：E, T, L, V | OpenAI 的 Codex 文档使 harness 循环清晰可见：结构化提示、工具调用重放、本地命令执行，以及测试或验证反馈共同决定智能体行为。 |
| OpenHands (Wang et al., 2025b;c) | 开放式软件工程智能体平台与可组合智能体 SDK。层：E, T, C, L, V | 仓库级软件智能体的研究级参考：平台将沙箱执行、shell/浏览器/工具交互、任务状态与基准导向评估整合于一个开放系统之中。 |
| SWE-agent (Yang et al., 2024; SWE-agent, 2025; SWE-agent Team, 2024) | 以智能体-计算机接口与 SWE-ReX 执行后端为核心的问题修复编码智能体。层：E, T, L, V | 核心贡献在于智能体-计算机接口：命令、观测、编辑动作、测试以及远程执行后端成为被测量 harness 的组成部分，而非附属基础设施。 |
| Symphony (OpenAI, 2026b; Kotliarskyi et al., 2026) | Codex 编排规范与任务运行器工作流，实现从问题到执行的全流程控制。层：C, L, V, G | Symphony 将问题跟踪器与任务运行器视为持久控制平面，使分配、进度状态、验证门控与评审边界成为 Codex 编排的显式组成部分。 |