> For the complete documentation index, see [llms.txt](https://gists.lanlance.cn/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://gists.lanlance.cn/cssys/agent-harness-engineering-a-survey.md). # Agent-Harness-Engineering-A-Survey * 原文标题：Agent Harness Engineering: A Survey * 原始 PDF： * 项目页： ## 作者 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 ## 摘要 大语言模型（LLM）智能体在生产环境中的快速部署揭示出一种反复出现的模式：任务执行的可靠性，与其说取决于底层模型本身，不如说取决于包裹模型的那层基础设施，也就是智能体执行 harness。本文从实践出发，对 Harness Engineering 做出系统性综述，并围绕三项主张展开。第一，智能体执行 harness 是一个独立的系统层，它的工程质量在很大程度上决定了现实世界中的可靠性。作者用从 Prompt Engineering、Context Engineering 到 Harness Engineering 的三阶段演化来展开这一判断，并进一步给出围绕成本—质量—速度三难困境、能力—控制权衡与 harness 耦合问题的跨层综合分析，以及一套立足研究缺口与生产痛点的开放问题议程。第二，作者提出 ETCLOVG 七层分类体系，由 Execution environment、Tool interface、Context management、Lifecycle/Orchestration、Observability、Verification、Governance 七层组成，在既有六组件框架基础上，把可观测性与治理提升为独立的架构关注点。第三，作者将 170+ 个开源项目映射到这一分类体系上，以揭示生态模式、覆盖空白和新兴设计原则；同时总结 OpenAI、Anthropic 与 LangChain 在生产部署中沉淀出的工程经验，以弥合实践知识与研究词汇之间的鸿沟。 **图 1：** Prompt Engineering、Context Engineering 与 Harness Engineering 的简要对比。 ![](/files/DYyItFSt7yqNXiAkISPt) ## 1 引言 ### 1.1 绑定约束：Harness 重于模型 围绕基于 LLM 的智能体展开的学术研究，总体上一直在研究模型本身。研究议程聚焦于模型能做什么：它是否能够跨多个步骤进行规划、可靠地调用工具、检索并压缩相关记忆，或与其他智能体协作。其隐含假设是，智能体能力主要是模型能力的函数；只要模型足够强、提示足够好，就会产生足够可靠的行为。 近期的实证证据对“仅靠更好的模型就能产生更可靠的智能体”这一假设提出了挑战。最近三项结果共同呈现出同一种模式。Bölük (2026a) 仅修改了 edit-tool 的格式及其周边的 工具 harness，在没有任何模型改动的情况下，便报告称在 15 个模型上的编程基准中取得了最高 10× 的增益。Trivedy (2026) 仅通过重构 system prompt、注入中间件上下文以及加入自验证 hooks，就把一个固定的 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，也就是负责上下文构造、工具交互、编排、反馈与执行约束的基础设施层；模型则保持不变。这些仅由 harness 带来的增益，每一项都超过了在相同基准上通常被视为有意义模型进步的 2 到 4 个百分点提升。这不是偶然现象：决定结果的是 harness，而不是模型。 我们将这种模式称为 **binding-constraint thesis** (Bölük, 2026b)：对于在可比的前沿模型上评估的长时程任务，基准表现的方差，可能既由执行 harness 驱动，也由模型本身驱动。本文其余部分都以这一论点为论述框架。 §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 网站上的一篇文章则将 Harness Engineering 描述为“cybernetic governors for AI agents”，由前馈式指导和反馈式传感器构成，围绕 LLM 形成控制回路 (Böckeler, 2026)。 与此同时，研究共同体一直在以越来越精细的方式研究智能体系统的各个组成部分：记忆、工具使用、规划与安全性。但尚未被系统性研究的，是把这些组件整合成可靠运行系统的整套机制。由此产生了实践者—研究者鸿沟：实践者知道 harness 基础设施很重要，却缺乏解释“为什么重要”的形式化词汇，也就难以据此开展系统化改进。本文试图弥合这一鸿沟。 ### 1.3 范围与贡献 本文综述聚焦于这样一个基础设施层：它包裹语言模型，用来管理长时间运行、多步骤的任务执行。我们不综述作为开发工具的智能体框架，不综述作为产品类别的智能体平台，也不综述模型能力本身，尽管这三者都会为我们的分析提供信息。图 4 总结了支撑本文后续结构的七层分类体系。 本文的贡献可归结为三项主张。 1. **主张 1（概念层面）**：基于绑定约束论点 (Bölük, 2026b)，我们认为，在现实世界中真正限制智能体可靠性的，不只是模型本身，更是 harness。最近三项结果分别展示了：编程基准上最高 10× 的 harness-only 增益、Terminal-Bench 2.0 上 +13.7 个百分点的提升，以及 Terminal-Bench-2 上 76.4% 的成绩（§1）；这些结果都超过了相同基准上典型的模型驱动增益。我们主要通过三个方面展开这一论点：三阶段工程演化（§2）、围绕成本—质量—速度三难困境、能力—控制权衡以及 harness 耦合问题的跨层综合（§11），以及一套开放问题议程（§12）。 2. **主张 2（分类层面）**：七层 ETCLOVG 分类体系将可观测性和治理视为独立层，而不是 Lifecycle Hooks 的副作用。两者各自都拥有独立的生产工具栈——可观测性一侧有 Langfuse 和 OpenTelemetry，治理一侧有权限引擎、网关与审计流水线——并且在生产部署中通常由不同团队负责。我们还将状态管理放入 Lifecycle and Orchestration 之中，因为状态本就应与读取和写入它的执行流放在一起（§2.3）。 3. **主张 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、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)。 **harness 转向（2025–2026）**。到 2025 年，已经积累了足够多的部署经验，可以清楚地表明：决定智能体可靠性的绑定约束，是基础设施质量而不是模型质量。2026 年初的三个独立进展验证了这一转变：OpenAI 明确采用 “harness engineering” 作为一门学科；Stanford/MIT 的 Meta-Harness 表明自动化 harness 优化优于人工工程；LangChain 的 DeepAgents 则仅通过 harness 层的改动，就把 Terminal-Bench 2.0 上的成绩从 52.8% 提升到 66.5%，即提高了 13.7 个百分点，约合 26% 的相对提升 (OpenAI, 2026a; Lee et al., 2026; Trivedy, 2026)。 ### 2.2 三个工程阶段 2022–2026 年这一时期揭示出一个连贯的三阶段演化：该领域“选择去工程化什么”的对象发生了变化。 **Prompt Engineering（2022–2024）**。主要杠杆是输入提示文本。实践者通过构造更好的指令、few-shot 示例和推理模板来优化系统。其工程范围较窄：优化单次模型调用所接收的一段文本输入。 **Context Engineering（2025）**。随着智能体运行时间变长，绑定约束从“输入是什么？”转向“模型在每一步应当看到哪些信息？”这一阶段聚焦于上下文管理：每一轮注入什么、如何检索并压缩记忆、如何按相关性对工具结果排序，以及如何处理上下文窗口饱和。其范围从单一输入扩展为管理流入上下文窗口的多股信息流 (Anthropic Applied AI Team, 2025)。 **Harness Engineering（2026）**。当模型已经足够有能力处理长时间运行任务时，可靠性便越来越依赖于包裹其外的基础设施层：它负责维护状态、中介工具、注入反馈、强制执行约束并验证进展。这一观察与绑定约束视角一致：长时程智能体性能，是由一个耦合的“模型—harness 系统”产生的，而不是单独由模型产生 (Bölük, 2026b)。因此，Harness Engineering 所要回答的问题是：为了让智能体系统变得可靠，必须围绕模型设计哪些治理机制、约束、反馈回路与执行控制。在我们的分类体系中，这一阶段把 ETCLOVG 的全部七层视为一个集成整体 (OpenAI, 2026a; Böckeler, 2026; LangChain, 2026b)。 每一个阶段都包含前一个阶段：Harness Engineering 包含 Context Engineering，而 Context Engineering 又包含 Prompt Engineering。这三个阶段在时间上和概念上也彼此重叠，而不是以泾渭分明的边界彼此替代。Prompt Engineering 今天仍然是 harness 实践中的活跃组成部分，而 Context Engineering 也仍在与本文所综述的 harness 层问题并行成熟。因此，我们的分期更应被理解为“边际工程努力投向何处”的转移，而不是一系列替换关系。 **图 2：** 基于 LLM 的智能体系统之 Harness Engineering 分类体系示意图。E、T、C、L 四层构成系统的结构性支柱。O 层提供系统级监控，V 层为各组件提供评估与反馈，而 G 层则在整个系统之上施加治理与安全约束。配色方案对应于 §2.3 中构建的 ETCLOVG 各层。 ![](/files/XUcrNFGebMxKJ0hL9BAP) **图 3：** 2022 至 2026 年代表性智能体执行 harness 系统时间线。该时间线展示了系统如何从早期的单循环智能体，转向更丰富的 harness 基础设施；这些基础设施横跨执行环境、工具接口、上下文与记忆管理、生命周期编排、可观测性、验证与治理。配色方案对应于 §2.3 中构建的 ETCLOVG 各层。 ![](/files/Y0EJN0y06sNsnnCKYmmn) ### 2.3 ETCLOVG 七层分类体系 我们提出一个用于智能体执行 Harness Engineering 的七层分类体系，并以 ETCLOVG 这一缩写指代它，分别代表 Execution、Tooling、Context、Lifecycle、Observability、Verification、Governance。图 4 给出了紧凑的可视化地图；本小节则确定本文后续沿用的解释。 前四层描述的是 harness 的结构核心。执行（E）决定智能体代码在何处运行，以及有哪些沙箱约束界定其边界；工具（T）规定外部能力如何被描述、发现和调用；上下文（C）控制模型在短期、会话级与持久化时间尺度上能够看到什么；生命周期（L）则组织读取与写入这些状态的控制流，从单智能体循环一直延伸到多智能体以及从 Issue 到 Pull Request 的工作流。其余三层描述围绕这一核心的控制平面。可观测性（O）捕获轨迹、成本、失败与可靠性信号；验证（V）将任务与轨迹转化为评估、失败归因与回归反馈；治理（G）则通过权限、身份、策略、加固、审计与人工监督机制来约束系统行为。第 3–9 节将依次展开这七层，而第 10–12 节则综合讨论不属于任何单层的跨层权衡与开放问题。 这套分类体系有两个设计选择使其与众不同。第一，我们将可观测性提升为独立层，而不是把它视为 Lifecycle Hooks 的副作用。在生产系统中，可观测性拥有独立的工具生态（Langfuse、Arize Phoenix、OpenLLMetry）以及独立的工程实践（OpenTelemetry 埋点、成本归因、异常检测），因此值得单独处理。第二，我们将治理引入为一级层，用于覆盖安全与合规问题的完整谱系，这些问题分布在三个子层之中：模型层（guardrails、内容过滤器）、系统层（网关、代理、权限模型）以及组织层（审计、合规、human-in-the-loop 监督）。 **图 4：** 智能体执行 Harness Engineering 分类体系的细节。每个分支对应一个 ETCLOVG 层及其主要子类别；后续章节将讨论代表性系统与论文。 ![](/files/K4jxC6Pp84F5lYv1o2bz) 图 4 的分支可按如下方式整理： * **执行环境与沙箱（E，§3）** * 通用托管沙箱 * 面向 computer-use 智能体的基础设施 * 面向代码任务的专用沙箱 * 与框架集成的运行时 * 浏览器评测环境 * 操作系统级权限沙箱 * 沙箱抽象层 * **工具接口与协议（T，§4）** * 协议与接口标准 * 工具描述、发现与选择 * 工具增强训练与集成 * 可扩展性与会话管理 * **上下文与记忆管理（C，§5）** * 短期活跃上下文窗口 * 中期会话状态与跨运行持久化 * 长期持久记忆系统 * 长时程上下文技术 * 上下文漂移与极限 * **生命周期与编排（L，§6）** * 单智能体内循环 * 多智能体编排模式 * 全生命周期任务流水线 * **可观测性与运维（O，§7）** * 追踪与监控平台 * 面向智能体的专用运维平台 * 成本跟踪与优化 * 可靠性工程 * 统一可观测性 * **验证与评估（V，§8）** * 任务与基准锚定 * 执行前就绪性验证 * 受控执行与轨迹采集 * 多层级判断与失败归因 * 持续回归与部署反馈 * **治理与安全（G，§9）** * 权限模型与身份管理 * Lifecycle Hooks * 组件加固 * 声明式宪章 * 审计基础设施 * 智能体安全版图 状态管理天然应归入生命周期与编排（L）之内，因为它与读取和写入状态的执行流相伴而生；而生命周期 hooks 与策略强制执行则应归入治理（G），因为它们与其他约束机制处于同一层面。 ### 2.4 范围 我们使用 **agent harness** 一词的含义，比“围绕一个 LLM 的任何软件”更窄：harness 是一种经工程化设计的包装层，它通过执行基底、工具接口、上下文控制、编排、可观测性、评估反馈以及治理约束，把模型调用转化为有边界、有状态、由工具介导的任务执行 (OpenAI, 2026a; Anthropic, 2025d; LangChain, 2026b)。因此，本文的分析单位是让长时间运行的智能体行为变得可控、可检查、可恢复的基础设施，而不是基础模型或提示本身。我们划定边界的依据是功能，而非产品类别：如果一个智能体框架暴露出可复用的机制，例如有状态编排、工具路由、运行时策略 hooks 或轨迹捕获，那么它就在本文范围内；而薄薄一层模型 API 包装器、提示词库、静态数据集、通用容器运行时、向量数据库、APM 仪表板或内容过滤器，则不在范围内，除非它们被明确适配到智能体执行、状态、评估或工具使用治理之中。 ### 2.5 项目收集流程 我们将该语料集构建为一项对公开记录之智能体执行 harness 工件的系统性映射，并借用系统综述的报告规范，使来源流、搜索策略与筛选过程都保持明确 (Page et al., 2021)。如图 5 所示，候选项目来自四类来源：既有综述与基准论文；可复现的 GitHub 搜索——其搜索维度覆盖名称、描述、README 文本、topics、star 数、最近活跃度与归档状态；精选项目列表与包注册表；以及引入 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、论文、精选列表、包注册表以及公司工程资料中收集，然后去重、依据纳入标准进行检查，并根据公开文档映射到 ETCLOVG 各层。 ![](/files/SvJIapb2isFLMdP6D3A1) ### 2.6 纳入与排除标准 当一个项目同时满足三个条件时，它会被纳入：其一，它有公开文档；其二，它实现或规定了一个具体的 harness 层机制；其三，现有证据足以将其归入至少一个 ETCLOVG 层。这包括：具有可复用编排或工具路由逻辑的智能体框架；实例化了可执行智能体环境的基准；为智能体执行打包的沙箱；以及作用于智能体状态、轨迹、动作或策略之上的记忆、可观测性、评估或治理系统。我们排除了简单的聊天机器人演示、提示词包、薄模型客户端包装器、没有智能体运行时的静态数据集或排行榜、不面向智能体的通用基础设施组件，以及那些无法从公开文档中检查其技术行为的产品页面。边界案例的判断依据是其“机制”而非“标签”：一个仓库即便名为“agent”，也不足以纳入；而一个评估或沙箱项目，只要提供了可复用的 harness 机制，就会被纳入。 ### 2.7 编码规程 每个保留项目都依据七个 ETCLOVG 层进行编码，所依据的证据来自工件本身的公开材料：README、文档页面、论文、示例、发布说明，以及在必要时的仓库结构。由于许多系统跨越多个层面，编码采用多标签方式；主层标记的是对该工件最核心的机制，而次层仅在文档明确暴露出一种独立能力、而非偶然依赖时才会赋予。当前版本采用的是“单一主编码者 + 作者审计”协议，而不是正式的多编码者一致性研究，因此我们不报告 Cohen’s kappa 或类似的标注者间一致性统计量。对于模糊案例，我们在完整编码后进行了复核，并采用一条保守规则：如果公开证据没有清楚展示面向智能体的机制，则不进行层级归类。 ### 2.8 语料集的局限性 这一语料集应被理解为对“可见的”智能体执行 harness 生态的地图，而不是对所有已部署智能体基础设施的普查。它偏向英语来源、在 GitHub 上可见的项目、开源工件，以及那些维护者公开了足够实现细节、使外部编码成为可能的系统。商业生产系统在其中代表性不足，除非其工程博客、文档或 SDK 暴露了相关机制；而 coding agent 基础设施则被过度代表，因为它拥有异常丰富的公开痕迹：仓库、基准、沙箱、从 issue 到 pull request 的工作流以及发布说明。层级归类反映的也是公开文档而非私有架构，因此，一个项目未出现在某层中，意味着“没有公开证据”，而不是“没有实现”。 ### 2.9 汇总分析 对 170+ 个项目的映射揭示出一个广阔但不均衡的生态。执行、工具接口、生命周期编排与验证拥有最稠密的可见覆盖，因为 coding、web、terminal 与 computer-use 智能体若想真正有用，都必须具备可运行的环境、工具契约、控制回路以及可重复的评估。上下文与记忆出现在许多项目中，但往往嵌入于更大的框架内部，而不是以独立 harness 组件的形式发布。可观测性与治理在开源覆盖中则更薄，且更常通过商业平台、SDK 功能或工程文章出现，这表明运维控制成熟得晚于运行时与基准基础设施。跨层项目正在变得越来越普遍：最完整的系统会把沙箱、工具协议、编排、追踪、评估与权限控制结合在一起，这支持了本文的核心主张——Harness Engineering是一个集成的系统问题，而不是一组彼此孤立的附加组件。 ## 3 执行环境与沙箱 我们以执行环境与沙箱这一层开启逐层讨论，它是 ETCLOVG 的七大支柱中的第一项（§1 中的主张 2）。本节讨论的系统来自支持主张 3 的 170+ 项目语料。 **图 6：** 面向 LLM 智能体的执行环境与沙箱代表性工作，按本章的沙箱类别组织。 ![](/files/d9R83dtqRuDe1bZRRPlV) 图中按沙箱类别归纳了代表性系统，包括：通用托管式沙箱、计算机使用型智能体基础设施、代码与仓库执行沙箱、框架集成式运行时、浏览器评测环境、OS 级权限与运行时安全，以及沙箱抽象 / 训练 / 评测。 ### 3.1 范围与概念 #### 3.1.1 定义 智能体的执行环境，指的是智能体动作被实际执行的基础设施层。在 LLM 智能体的语境中，执行环境与沙箱是紧密耦合的概念。因此，生产级智能体系统几乎总是在沙箱化环境中执行动作。 #### 3.1.2 为什么沙箱在智能体时代居于核心地位 在智能体时代，沙箱并不只是从传统多租户代码执行继承而来的安全措施。它同时服务于三个不同目的，而这三者的组合，正是沙箱从一个运维细节上升为智能体执行 harness 设计中一等公民问题的原因。 第一个目的是安全性。智能体沙箱面临的挑战，超出了传统多租户代码执行的范围。LLM 生成的代码在大规模场景下既无法审计，也不可预测，因此静态审查不能作为首要防线。智能体会自主执行多步操作，所以在动作实际执行时无法依赖人工介入。提示注入攻击还会把原本无害的智能体重新利用为面向沙箱的攻击载体，从而模糊可信用户意图与恶意输入之间的边界。近期关于沙箱逃逸的实证工作表明，这些担忧并非假设，我们将定量证据留到 §3.3 再讨论。 第二个目的是可复现性。长时程智能体任务，以及衡量这些任务的评测 harness（§8），都要求能够将执行状态重置到一个已知基线。Docker 容器或 microVM 可以按需销毁并重建，而开发者工作站做不到这一点；正是这种性质，使得 SWE-bench 和 OSWorld 这类基于沙箱的评测标准变得可行。在训练阶段，当同一任务需要在并行轨迹上被重放数百次时，缺乏廉价的重置机制本身就会成为可扩展性的瓶颈。 第三个目的是 liveness，这也是最具有智能体时代特征的一点。没有沙箱时，智能体想执行的每个潜在高风险动作——例如写文件、安装依赖包或发起外部网络请求——都必须经过面向人工的显式权限提示。在规模化场景下，这会产生两种失败模式：要么用户因挫败感而放弃使用智能体，要么用户条件反射式地全部批准，从而破坏这些提示原本的安全意义。沙箱通过定义一个有边界的区域打破这一僵局：在该区域内，智能体被授权自由行动，权限控制从“逐个动作逐条发问”转变为“会话级配置”。Anthropic 报告称，在 Claude Code 中引入沙箱后，在保持安全性的同时，权限提示减少了 84%（Anthropic, 2025b）。在这个框架下，沙箱既是牢笼，也是许可证；而“许可证”这一面，正是长时程自主执行得以成立的前提。 在这三个目的中，安全性与传统沙箱共享，可复现性在智能体场景下被进一步放大，而活性则几乎是全新的需求。正是三者的结合，使我们有理由把智能体沙箱视为一个独立的研究对象，而不是容器技术的下游应用。 ### 3.2 智能体沙箱的类别 2024 到 2026 年间，智能体沙箱基础设施已经从少量通用运行时，分化为若干面向不同任务类型优化的独立产品类别。我们沿着“工作负载类型 / 使用场景”的轴线，将这一版图组织为七类；对于需要在不同系统间做选择的 harness 设计者而言，这是最有信息量的视角。另一条与之正交的轴线是隔离技术，包括容器、gVisor 等用户态内核、Firecracker 与 Kata Containers 等 microVM、WebAssembly，以及 bubblewrap、Seatbelt 等 OS 级原语。我们不将这条轴线作为顶层分类，而是在各小节中将其作为设计属性讨论，因为同一种隔离原语会在不同工作负载中复用。这七类分别是：通用托管式沙箱（§3.2.1）、计算机使用型智能体基础设施（§3.2.2）、面向代码的专用沙箱（§3.2.3）、框架集成式运行时（§3.2.4）、浏览器评测环境（§3.2.5）、操作系统级权限沙箱（§3.2.6）以及沙箱抽象层（§3.2.7）。下面依次展开。 #### 3.2.1 通用托管式沙箱 通用托管式沙箱提供商业化或开源的 sandbox-as-a-service 平台，通过 API 暴露任意 OCI 容器镜像，并为未预先限定的工作负载提供 shell、文件系统、网络和解释器支持。代表性系统包括：Daytona，它从开发者环境转向智能体沙箱，冷启动创建时间低于 90ms；E2B，一个构建在 Firecracker microVM 上的智能体沙箱；Modal，一个采用 gVisor 并支持大规模自动扩缩容的 Python 平台；Northflank，同时支持 Kata Containers、Firecracker 与 gVisor；阿里巴巴的开源通用沙箱 OpenSandbox；以及 Docker 于 2025 年发布的、基于 microVM 的官方产品 Docker Sandboxes。 这一类别中的设计决策呈现出若干收敛模式：默认采用 ephemeral-by-default 语义，同时允许可选的持久会话；API 接口通常以 Python 和 TypeScript SDK 的形式暴露；并支持任意 OCI 镜像。不同系统之间的分歧主要体现在隔离强度和运维模型上。Daytona 默认使用容器隔离，并可选 Kata Containers；E2B、Modal 和 Docker Sandboxes 则默认提供 microVM 或 gVisor 隔离。Northflank 的独特之处在于允许为每个工作负载单独选择后端，这反映出业界已经认识到：不存在一种可以适配所有威胁模型的隔离原语。我们观察到一个更广泛的趋势：系统正在从共享内核的容器隔离转向专用内核的 microVM 隔离，其驱动力在于 LLM 生成代码的系统调用模式无法预先刻画，因此更强的默认隔离更具现实意义。 #### 3.2.2 计算机使用型智能体基础设施 计算机使用型智能体基础设施代表了一种独特的执行模型：智能体不是通过 API 或 shell 命令交互，而是通过模拟鼠标、键盘和屏幕观察来操作图形界面。代表性系统包括 Anthropic 的 Computer Use，它是让 Claude 直接操作桌面环境的旗舰商业实现；开源的计算机使用型基础设施 CUA；以及 OSWorld 提供的基于 VM 的环境，后者同时兼作评测 harness（§8）与参考性的 computer-use 沙箱。 这些系统会在沙箱内部打包完整或近完整的桌面环境（通常是带窗口管理器的 Xvfb，或完整 VM），并向智能体暴露像素坐标级操作和按键动作。与基于 API 的类别相比，它们的动作空间要大得多；但系统可靠性依赖于视觉 grounding，而完整操作系统带来的攻击面又要求更强的隔离，通常是 microVM 或完整 VM。相较于 §3.2.1 的托管式沙箱，computer-use 沙箱是用部署密度和启动时延来换取真实度：完整桌面环境比无头 shell 沙箱更重、更难多路复用，但它也是唯一能让智能体操作那些完全不提供 API 的应用程序的执行模型。 #### 3.2.3 面向代码的专用沙箱 面向代码的专用沙箱是轻量级环境，优化目标是代码生成、评估与数据分析，而不是通用 shell 访问。代表性系统包括 Judge0，它原本是为在线判题设计的代码评测沙箱，后来被广泛复用于编码智能体评测流水线；OpenAI Code Interpreter，它是支撑 ChatGPT Advanced Data Analysis 的生产级沙箱化 Python 环境；面向编码智能体的 shell 沙箱 sandboxed.sh；以及 langchain-sandbox，它将 Pyodide 编译到 WebAssembly，并在 Deno 运行时中执行，从而在本地无容器地沙箱化智能体生成的 Python；NVIDIA 也为客户端 agentic workflow 倡导了类似设计。 与 §3.2.1 的通用沙箱不同，这类系统会预装编译器与解释器，默认采用无状态的请求级执行，并针对高并发并行进行优化。这种设计牺牲了工作负载通用性，换来了更快的启动速度、更高的评测吞吐，以及更简单的威胁模型。一个值得注意的子趋势是：代码沙箱正从基于容器的实现转向基于 WebAssembly 的实现。WebAssembly 提供基于 capability 的安全性、确定性执行以及微秒级实例化，但代价是 Python 标准库受限、原生扩展支持较弱。 #### 3.2.4 框架集成式运行时 框架集成式运行时是打包在更大智能体框架内部的执行环境，而不是作为独立沙箱产品暴露。它们与框架的编排循环、工具注册表和提示词约定一起交付；如果不采用周边框架，就无法独立消费这些运行时。代表性系统包括 OpenHands runtime，这是一个 Docker 沙箱化环境，把 bash、IPython、Chromium 浏览器和 API server 集成进单一镜像；agent infra sandbox，一个明确的 all-in-one 设计，将 browser、shell、filesystem、MCP 和 VSCode 打包到同一环境中；以及 smolagents 的 executor 层，它在框架内部提供 local、Docker、E2B、Modal 与 WebAssembly 等多种执行实现。 这一类别的核心权衡是 bundle 还是 compose：框架集成式运行时优先保证开箱即用的能力覆盖，但代价是镜像更大、启动更慢，并与单一框架的抽象深度耦合。相比之下，§3.2.1 的通用沙箱采取的是相反路径：提供最小环境，再通过外部抽象层进行组合。从长期看，组合式方案能否取代捆绑式运行时，取决于 MCP 等标准能否降低“在运行时组装能力”相对于“在构建时打包能力”的成本惩罚。 #### 3.2.5 浏览器评测环境 浏览器评测环境同时扮演沙箱与评测 harness 的双重角色。代表性系统包括 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 执行环境（沙箱角色），另一方面又同时给出可复现的任务定义与自动评估（harness 角色）。这种双重功能使其区别于 §3.2.2 的 computer-use 类别：后者作用于桌面层，而不是浏览器层。它也在本节讨论的执行环境与 §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——来实现细粒度的文件系统与网络隔离，而不是使用容器、VM 或用户态内核。与容器沙箱相比，它们要轻量得多，同时依然能够提供目录级与域名级访问控制。代表性系统包括 Anthropic 的 sandbox-runtime（Anthropic, 2025g），这是一个开源 npm 包，它通过 bubblewrap 与本地 HTTP/SOCKS5 代理施加文件系统和网络 allowlist，对任意命令进行包装；Claude Code 自带的沙箱功能（Anthropic, 2025b），它消费该运行时来把 bash 工具的文件系统与网络访问限制在已配置边界内；以及 IsolateGPT（Wu et al., 2025），这是一个研究系统，通过 seccomp 与 setrlimit 对基于工具调用的 LLM 应用施加执行隔离。 这一类别的设计哲学是“权限，而不是分区”：目标不是为每次会话提供一个全新的 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）的 executor 接口，它通过单一参数化的 `executor_type` 暴露 local、e2b、modal、docker、blaxel 和 wasm；以及 Kubernetes SIG Apps 下的 Agent Sandbox 项目（Kubernetes SIG Apps, 2025），它引入了 Sandbox CRD 与 controller，通过声明式 API 将 gVisor 与 Kata Containers 暴露为可插拔隔离后端。 这一类别的出现，反映出人们对执行基础设施的理解正在成熟：执行基础设施应当是可替换的。若 harness 将某个特定沙箱 API 硬编码进编排逻辑，就会把自身绑死在某家供应商易变的产品接口上；抽象层则把“智能体运行什么”与“它在哪里运行”解耦。我们观察到，研究项目（SWE-ReX）、框架内嵌接口（smolagents executors）与新兴基础设施标准（Kubernetes agent-sandbox CRD）正在趋同，这表明沙箱抽象正逐渐成为智能体执行 harness 栈中的独立层，而不再只是个别系统的一个功能。 **综合。** 在这七类系统中，可以看到三条横向趋势。第一，领域并没有收敛到单一方案，而是在隔离强度上发生分叉：托管式沙箱（§3.2.1）正在从共享内核容器迁移到专用内核 microVM，而 OS 级权限沙箱（§3.2.6）则完全放弃独立环境，转而缩窄宿主系统的可见视图。普通 Docker 容器所处的中间地带正被两端挤压；在两种极端之间做选择，反映的并不是某种普适技术偏好，而是威胁模型的差异——是要防御完全对抗性的代码，还是只需防御被提示注入劫持、但其他方面仍相对合作的代码。第二，评测稳健性正在成为一等问题：如 SandboxEscapeBench（Marchand et al., 2026）这样的容器逃逸基准，以及面向 code-interpreter 智能体的安全基准 CIBER（Ba et al., 2026），都表明当前生产环境部署的沙箱配置已经会被前沿模型部分绕过。第三，基础设施级隔离（本节讨论的内容）正在与工具调用层的语义级 / 能力级隔离分离开来。CaMeL 的控制流完整性设计（Debenedetti et al., 2025）与 Progent 的可编程权限控制（Shi et al., 2025a）就是后者的代表，它们应归入工具使用章节（§4），而不属于严格意义上的沙箱基础设施。这两条路线是互补的：基础设施沙箱约束的是动作一旦执行后的影响半径，而语义隔离约束的是哪些动作首先被允许执行。完整的智能体执行 harness 需要二者兼备。 ### 3.3 威胁模型与沙箱逃逸 对智能体执行进行沙箱化，既要面对传统容器层威胁（容器逃逸、旁路信道、资源耗尽），也要面对会放大这些经典问题的智能体特有威胁类别。第一，提示注入攻击允许外部输入——例如检索得到的网页、工具返回内容或文件内容——劫持智能体行为，并发起恶意的沙箱内操作。第二，目标失配（goal misalignment）会使智能体本身把“逃出沙箱”当作一种工具性子目标来主动追求。第三，组合放大（compositional amplification）会在智能体拥有多个工具访问权限时出现：单个沙箱弱点可以沿着已集成的多种能力发生级联扩散。 关于智能体场景下的沙箱逃逸，实证证据还很有限，但已有结果令人警惕。SandboxEscapeBench（Marchand et al., 2026）在嵌套沙箱夺旗（capture-the-flag）设定下评测前沿 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）模式下，由 sandbox-as-a-service 提供商负责基础设施，例如 E2B、Modal 与 Daytona Cloud。在混合或自带云（BYOC）模式下，智能体逻辑与沙箱执行被拆分到不同环境中；例如 OpenHands SDK 的 Local / Remote Workspace 抽象（Wang et al., 2025c），以及 E2B 与 Northflank 提供的 BYOC 方案。 这些模式的演化受两股互补力量驱动。一方面，实践者报告通常沿着时延、安全性与可扩展性三个维度来刻画部署选择（Anthropic, 2025b;f）。自托管沙箱拥有最低时延和最紧密的迭代回路，但必须承担全部运维负担；云端沙箱则在这一权衡上反向取舍，提供弹性扩展和托管安全能力，但代价是网络往返；混合模式试图在保持敏感数据本地化的同时，把执行能力委托给外部基础设施。另一方面，数据驻留、合规与可审计性等组织约束，又会推动部署走向混合架构，即便从时延与可扩展性的角度看，单一模式方案可能更优。 从目前观察到的实践来看，自托管沙箱在交互式开发与单租户场景中占主导，云端沙箱则更常见于多租户和大规模部署。混合模式正在那些“既有合规 / 数据本地化要求、又需要大规模临时执行容量”的场景中特别兴起。针对真实智能体工作负载，对这三种模式进行系统性经验比较的研究目前仍然缺失，我们将其视为 §12.1 更广义运行时议程的一部分。 ### 3.5 小结 执行环境是智能体执行 harness 的物理底座：它提供安全边界、为可复现评测与训练提供重置机制，并给出一个受限区域，使长时程智能体无需对每条命令都请求人工批准即可行动。本节考察的七类系统表明，如今的设计空间已不再主要由单一隔离原语所塑造，而更多由工作负载真实度、威胁模型和运维模式共同决定。托管式沙箱与计算机使用环境强调强隔离和真实执行；代码专用环境与浏览器环境强调吞吐与评测结构；框架集成式运行时为了便利而捆绑能力；OS 级权限沙箱收窄本地权限；抽象层则让底层执行基底变得可替换。 这一设计空间反复暴露出能力、控制与成本之间的张力。高风险工作负载推动系统走向 microVM 和托管云；交互式本地工作流推动系统走向轻量级权限边界；大规模训练或评测则推动系统选择能快速重置的执行基底。因此，关于运行时防御、经济性、可移植性、捆绑还是组合式设计，以及跨层耦合的未解问题，并不是执行层的边角注脚，而会在 §12.1 重新作为整个综述范围内的开放问题出现。 ## 4 工具接口与协议层（T） 工具接口与协议层（T）是 ETCLOVG 的第二根支柱（§1 中的 主张 2）。本节讨论的协议、描述方式与注册表，来自支持 主张 3 的 148+ 项目语料。 **图 7：** 面向 LLM 智能体的工具接口与协议代表性工作，按本章的工具层类别组织。 ![](/files/4k1IPPzdsrYdtrVUvGGu) 图中按四类工具层问题归纳代表性工作：协议与接口标准、工具描述 / 发现 / 选择、工具增强训练与集成，以及可扩展性与会话管理。 工具接口与协议层定义了：智能体如何发现能力、如何表示可调用能力，以及如何跨越异构运行时边界执行动作。在实践中，这一层正处在两个互相竞争目标的断层线上：一方面希望通过暴露更多工具来扩大能力覆盖，另一方面又要通过保持动作空间和提示词占用足够小来维持决策质量。近期来自生产级智能体系统的工程经验反复指出，过大的工具菜单会降低可靠性、增加 token 开销，并放大规划错误（Anthropic, 2025d; OpenAI, 2026c）。 我们将这一层组织为四个相互补充的方向：协议与接口标准；工具描述、发现与选择；工具增强训练与集成；以及可扩展性与会话管理。 ### 4.1 协议与接口标准 MCP 已成为编码智能体和企业智能体中最显眼的工具集成底座，它采用显式的 host-client-server 架构，并通过基于 JSON-RPC 的类型化交换来传递工具、资源和提示词（Model Context Protocol, 2025b;c;a）。MCP 的实际价值不只在于模式层面的互操作性，还在于其生态流动性：智能体构建者可以复用一个持续扩张的 server 目录，而不必为每个部署目标都实现定制连接器。 A2A 面向的是一个不同但相邻的边界。它不是把工具暴露给单个智能体进程，而是标准化黑盒化智能体应用之间的通信，包括通过 Agent Cards 进行发现、支持同步与流式交互，以及支持长时任务协作（A2A Project, 2025）。近期的协议综述通常把 MCP 与 A2A 视为互补角色：MCP 主要用于工具 / 上下文访问，A2A 则用于智能体之间的委派与协作（Ehtesham et al., 2025）。但在我们看来，更有用的组织原则并不是按供应商谱系或发布时间来分类，而是按它们跨越的“集成边界”来分类。在这个视角下，会出现四种边界：Model ↔ Function（结构化调用）、Agent ↔ External capability（运行时与工具解耦）、Agent ↔ Agent（跨进程委派），以及 Agent ↔ Repo/environment（版本控制下的策略约束）。表 1 对这一视角做了总结，也明确说明了为什么许多经常被并列比较的标准（例如 MCP vs. A2A，或 Function calling vs. OpenAPI）在同一个 harness 中其实承担的是不重叠的角色。 函数调用模式与 API 描述标准，仍然是这一层的基础构件。OpenAI 风格的 function calling 通过 JSON Schema 以及显式的调用 / 返回轮次，把工具调用操作化（OpenAI, 2026c）；OpenAPI 则提供语言无关、机器可读的 API 契约，许多智能体框架都把它作为工具生成与校验的来源（OpenAPI Initiative, 2025）。此外，像 AGENTS.md 和 AGENT.md 这样的仓库级指令文件，也为“直接在版本控制中编码工具使用方式和工作流约束”提供了轻量替代方案，从而降低了代码智能体的使用门槛（agentsmd, 2025; agentmd, 2025）。 **表 1：** 按跨越的集成边界（行）与四个与 harness 相关的能力轴（列）排列的工具 / 接口标准。✓ = 一等支持；△ = 部分支持或约定层支持；✗ = 超出范围。参考文献见周边正文。 | 边界 | 标准 | 传输协议（Wire） | 类型化 | 运行时发现 | 长时任务 | | ------------------ | -------------------- | ---------- | --- | ----- | ---- | | 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 工具描述、发现与选择 一旦协议定义了“如何发起调用”，下一个瓶颈就是“每一步应该暴露并选择哪些工具”。越来越多的工作开始研究工具文档质量、工具检索以及动态候选裁剪。EASYTOOL 研究了如何从大型工具库存中选择合适工具这一挑战（Yuan et al., 2025）。AnyTool 与 CRAFT 则致力于通过自动构建或自动改进工具使用流水线来减少人工规格说明负担（Du et al., 2024; Yuan et al., 2023）。MetaTool 这类 Benchmark 风格评估表明，不同领域、不同查询形式下，工具检索质量与调用质量之间可能存在显著分化（Huang et al., 2023）。更新近的工作，如 MCP-Zero、ToolRet 和 ToolRegistry，则更加强调“面向检索的编排能力”和“注册表质量”是决定下游智能体成功率的一等因素（Fei et al., 2025; Shi et al., 2025b; Ding, 2025）。一个密切相关的方向，是把工具选择扩展到可复用技能（skills）：此时智能体需要识别的，不再只是紧凑的 API Schema，而是相关的过程性模块。SkillRouter（Zheng et al., 2026）与 SkillRet（Cho et al., 2026）都在大规模条件下研究了这一技能选择问题，凸显出从庞大且彼此重叠的 skill 库中检索正确 skill 的必要性。 在系统层面，这些结果强化了两条设计原则。第一，“更少但更好的工具”往往优于蛮力式暴露全部工具，因为它同时降低了提示熵和规划器的分支数。第二，发现流水线必须具备自适应性：静态、全局性的工具列表无法扩展到快速演化的代码仓库，也无法适配多租户企业部署。 ### 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; HuggingFace, 2026）。编码智能体场景还暴露出第二类、更加语义化的工具：静态分析器、类型检查器、求解器支撑的验证器、证明助手，以及用于补丁等价性或故障定位的检查器。Ugare 与 Chandra（2026）把这类空间概括为 agentic code reasoning：智能体在不一定执行代码的前提下，探索仓库并推理代码行为。他们提出的半形式化推理方法位于“非结构化思维链”与“完全形式化验证”之间：它强制智能体陈述前提、追踪程序路径并导出显式结论，从而改进补丁等价性验证、故障定位与代码问答。对于工具层来说，这意味着自动化推理工具返回的应当是承载证据的工件——例如执行轨迹、证明义务、反例或结构化证书——而不应只是黑盒式的是 / 否答案。综合证据表明，工具能力是由预训练与微调信号、接口 schema 质量以及运行时选择策略共同决定的；只优化其中一个组件，收益将是有限的。 ### 4.4 可扩展性与会话管理 一个反复出现的运维挑战，是长时程任务下的会话管理。有状态的工具会话能够提升连续性，但也会显著增加状态维护复杂度，尤其是在调用被并行化或被多个智能体相互委派时。常见失败模式包括：陈旧句柄、重试后工具状态不一致，以及冗长工具轨迹导致的上下文窗口饱和。因此，有效的 harness 设计需要为工具会话提供显式的生命周期控制、对注入上下文的工具信息施加边界，并提供可观测性钩子，以便把错误归因到“规划器逻辑问题”还是“接口 / 协议故障”。 最后，生态层面的版图梳理固然有助于实践者快速映射可用的协议与工具选项，但真正决定某次部署应采用何种协议与工具路由策略的，仍然必须是以 Benchmark 为依据的对比评估。 ## 5 上下文与记忆管理（C） 上下文与记忆管理（C）是 Prompt Engineering、Context Engineering 与 Harness Engineering 相交汇的层面。我们将其视为 ETCLOVG 的第三个支柱（§1 中的主张 2），并从支撑主张 3 的 148+ 项目语料中抽取示例。 > **图 8：** 按本章上下文层类别组织的 LLM 智能体上下文与记忆管理代表性工作。 ![](/files/iEAeDpZZWQOGBpfl787q) 这一层决定模型在执行每一步时能看到什么信息，以及知识如何跨轮次、跨会话持续存在。其核心工程问题说起来很简单：在每一步，恰到好处地给模型正确的信息，除此之外不要再多。上下文太少，智能体就缺少正确行动所需的状态；上下文太多，性能就会下降，而且这种下降是可测量的、跨模型一致的，但其机制仍未被完全理解。 本节按时间跨度来组织。5.1 说明为什么上下文需要主动管理，而不能被动累积。5.2 将 Context Engineering 界定为一门不同于 Prompt Engineering 的独立学科。5.3 至 5.5 讨论生产实践中已经浮现出的三层记忆架构：活跃上下文窗口（短期）、会话级持久化（中期）以及跨会话存储（长期）。5.6 处理智能体运行数百轮时会出现的协调问题。5.7 以尚未解决的问题收尾。 ### 5.1 为什么必须对上下文做工程化处理 更大的上下文窗口并不能解决记忆问题。要理解这一点，必须先看架构。 **二次注意力成本。** Transformer 的自注意力机制会为上下文中的每一对 token 计算关系（Vaswani et al., 2017）。对于 n 个 token，就会产生 n² 个成对权重；计算与内存都随上下文长度呈二次增长。FlashAttention 和位置编码插值等工程技术可以降低常数项，但这种二次结构是架构性的。上下文长度翻倍，成本不是翻倍，而是四倍。这使得上下文窗口成为一种稀缺资源。 **U 形注意力曲线。** 即使计算资源负担得起，仅靠架构成本也无法解释模型为什么会在长上下文上失败。Liu et al. (2024) 给出了关键的实证结果：在包含 20 篇输入文档的多文档问答任务上，当相关文档位于上下文中间时，准确率比放在开头或结尾时下降 30% 以上。这种 U 形性能曲线跨模型、跨任务、跨上下文长度都成立，甚至包括专门针对长上下文训练的模型。其实际含义非常直接：信息放在哪里，与信息是否存在同样重要。一个智能体就算检索到了正确内容，但若摆放位置不佳，检索几乎没有收益。 **大规模场景下的上下文腐化（context rot）。** Hong et al. (2025) 在精心控制的条件下评估了 18 个前沿模型，包括 GPT-4.1、Claude Opus 4、Gemini 2.5 和 Qwen3，以便将输入长度的影响与任务难度区分开来。所有模型都会随着输入增长而退化。这种退化并不均匀，而且依任务而异。对于语义含混、相关段落与问题在词面上并不匹配的查询，其退化比精确匹配查询更陡峭，这指向一种复合失效：模型先是无法定位相关信息，之后即便定位到了，也无法在其上进行推理。更重要的是，这种退化在上下文窗口尚未被填满之前就已经开始。一个标称支持 200K token 的模型，可能在 50K 时就出现显著性能损失。Hong et al. (2025) 将这一现象称为上下文腐化（context rot），而它并不是边缘案例。对于任何会在多步执行中不断积累工具结果、中间推理和文件内容的智能体来说，这恰恰是其常态运行条件。 综合来看，这些结果表明，上下文管理绝不能被当成事后补救。关于纳入什么、放在哪里、何时移除的每一个决定，都会直接影响智能体的可靠性。 ### 5.2 从 Prompt Engineering 到 Context Engineering 从 Prompt Engineering 转向 Context Engineering，反映的是作用范围的变化（Karpathy, 2025）。Prompt Engineering 优化的是单次模型调用中的一段基本静态文本输入。在视觉领域，同一思路又扩展到连续可学习 token：视觉提示微调（visual prompt tuning）会在冻结的视觉 Transformer patch 序列前附加一小组可训练向量，从而适配下游任务，同时只更新不到 1% 的模型参数（Jia et al., 2022; Xiao et al., 2025）。无论是文本还是视觉变体，都共享 Prompt Engineering 的核心特征：面向单一输入模态，对一次固定单调用做优化。Context Engineering 则优化多步任务中，模型在每一个推理步骤可获得的完整信息状态。Anthropic 的 Applied AI 团队将其定义为：“在 LLM 推理期间，为整理与维持最优 token 集合而采用的一整套策略，其中还包括所有可能在提示词之外落入该集合的信息”（Anthropic Applied AI Team, 2025）。由此得出的指导原则是：在每一步找到最小但高信号的 token 集合，以最大化得到期望结果的概率。本节的所有技术都围绕这一原则展开。渐进式披露会按需、即时地加载信息，而不是一开始就全部塞入。压缩会移除已经完成使命的 token。记忆检索则只拉取与当前任务最相关的记录。 **上下文包含什么。** 在一个已部署的智能体中，推理时的上下文包括系统提示词和行为指令、工具定义与 schema、先前轮次的历史、当前执行轨迹中的工具调用结果、检索到的文档或记忆记录，以及任何动态注入的工作状态。所有这些内容都在竞争同一份有限的注意力预算。Context Engineering意味着在每一步都对这些组成部分做出明确选择，而不是任由它们无节制累积。 这一实践的成熟已经在生态中清晰可见。第一性原理手册（Kimai, 2025）和整理型综述（Meirtz, 2025）都已将Context Engineering视为一门独立学科。覆盖活跃上下文窗口、会话级状态与跨会话存储的三层记忆架构，已经成为主导性的组织框架。它与操作系统中的经典内存层次直接对应，既提供了直观类比，也提供了把正确技术匹配到正确时间尺度上的词汇体系。 ### 5.3 短期：管理活跃上下文窗口 短期上下文管理决定了模型在单个推理步骤中，或会话内一小段连续步骤中，究竟能看到什么。这些决定对模型行为的影响最直接，而一旦做错，代价也最高。 **系统提示词校准。** 系统提示词决定了智能体的行为边界，并且会在每次调用中占用一笔固定预算。Anthropic Applied AI Team (2025) 将这一设计挑战概括为寻找合适的“高度”：过于具体的提示词会引入脆弱、维护成本高的逻辑；过于模糊的提示词则无法为模型提供足够具体的指导。在实践中，有效的系统提示词通常会被组织成边界清晰的若干部分，例如背景、指令、工具指导和输出格式，并用 XML 标签或 Markdown 标题加以分隔。推荐工作流是：先在能力最强的可用模型上使用一个最小化提示词，通过实证识别失效模式，然后只针对这些具体缺口补充定向指令。预先罗列所有边界情况，往往只会让提示词膨胀，而不会提升可靠性。 **高 token 效率的工具设计。** 工具定义是上下文中的重要消耗项。每一个 schema、名称、描述和参数类型，都会在每次调用时被注入。一个庞大的工具集合，可能在智能体读到用户请求之前，就先吞掉数万 token。生产环境中沉淀出的原则是：优先使用更少、但表达力更强的工具，而不是提供一大串狭窄工具的菜单。如果一个人类工程师都说不清某种情况下该用哪个工具，就不能指望模型做得更好。工具应该是自包含的、稳健的、用途明确的，并拥有描述性强、能发挥模型理解优势的参数名。 **即时检索与渐进式披露。** 有效的智能体不会一开始就加载所有潜在相关信息，而是维护一些轻量级标识符，例如文件路径、已保存查询和网页链接，并在任务推进过程中按需加载数据。Anthropic Applied AI Team (2025) 将这种方法称为渐进式披露。它和人类专家的工作方式很相似：我们不会把整个语料都背下来，而是建立外部索引系统并按需检索。Claude Code 在实践中采用了一种混合策略。会话开始时加载 `CLAUDE.md` 文件以提供项目上下文，而 `glob` 与 `grep` 命令则使智能体能够在需要时再定位并读取具体文件内容。这同时避开了索引陈旧问题，以及大体量 prefill 的成本。环境元数据也带有隐式信号。文件大小暗示复杂度；命名约定透露用途；时间戳则可作为相关性的代理指标。智能体可以像搭积木一样分层构建理解，并只在活跃窗口中保留当前确实需要的内容。 **面向 KV-cache 的上下文设计。** 提示缓存是生产级智能体部署中性价比最高的一项优化，而它的收益完全取决于上下文的组织方式。Manus 团队在对其生产智能体做了五轮架构迭代后，将 KV-cache 命中率称为“生产阶段 AI agent 最重要的单一指标”，并指出在 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）。 围绕短期管理的工具生态也在迅速增长，其中既包括覆盖 agent 调用间 KV-cache 压缩模式的生产级 skill 库（Koylan, 2025），也包括提供以 MCP 为中心的动态上下文拼装原语的基础设施项目（context-space, 2025）。 ### 5.4 中期：会话状态与跨次运行持久化 中期上下文管理处理的是活跃上下文窗口与完整长期记忆系统之间的空缺地带。其具体问题是：智能体如何在一次会话的多轮之间，或者同一任务的多次运行之间，保存并恢复状态。它的工程价值很高：只要几百个 token 的结构化工作状态，就能跨越上下文重置，否则智能体会丢掉此前累积的全部进展。 **结构化记笔记。** 最简单的中期技术，是让智能体维护一个持久 notes 文件，通常是 `NOTES.md` 或 `todo.md`，在每次运行开始时读取，并在上下文被清空前更新。Anthropic Applied AI Team (2025) 用 Claude 连续数千步玩《Pokémon》的案例说明了这一点。即使没有任何关于记忆结构的明确指令，智能体也会自行绘制已探索区域的地图，维护战斗策略及其对特定对手效果的统计，并跨上下文重置追踪目标。每次清理主对话历史的压缩步骤结束后，智能体都会重新读取自己的笔记，并在不丧失连贯性的前提下，继续持续数小时的训练序列。这里的关键洞见是：记笔记把工作记忆外部化了。智能体不再依赖对话历史来承载任务状态，而是把重要内容写入外部存储，并在需要时再读回。 **基于文件的规划与任务外部化。** 结构化记笔记的一个扩展，是把完整的计划表示外部化到磁盘。像 planning-with-files（OthmanAdi, 2025）这样的工具，会为编码智能体工作流提供持久化的基于文件的规划 skill 包。任务状态、规格说明、中间结果和依赖图会在每个里程碑写入文件系统，并在下一次运行开始时按需选择性加载，从而让那些并非立即相关的内容完全绕过上下文窗口。像 Trellis（mindfold-ai, 2025）这样的框架，则把这种模式进一步扩展到项目记忆和规格说明注入：它们维护结构化项目状态，并根据当前步骤的需要选择性注入。 **跨次运行注入。** 另一种互补模式，是提炼上一次运行的关键信息，并在下一次运行开始时注入。像 claude-mem（thedotmack, 2025）这样的工具，作为插件式记忆层来工作：它们捕获会话历史，提取对未来运行最有用的信息，并把这些内容前置到下一次会话的上下文中。这样做既不需要向量数据库，也不需要图存储，却能在多次运行之间提供相当可观的连续性。社区仓库 everything-claude-code（affaan-m, 2025）在 GitHub 上拥有超过 150K stars，是这些模式最大的开放式集合，也展示了中层记忆实践在生产级编码智能体部署中的采用规模。 **中层的权衡。** 与仅依赖窗口内管理相比，中期技术能够提供明显更强的连续性，而基础设施成本却只占完整长期记忆系统的一小部分。它的局限在于：信息只是从一次运行向下一次运行前向流动，而不是从带索引的存储中按需检索；同时，这些技术对海量历史并不具备良好伸缩性。当跨次运行历史变得庞大，或者智能体需要检索的是某条特定的既往观察，而不是注入一段摘要时，中期技术就必须由接下来要讨论的长期系统来补充。 ### 5.5 长期：持久记忆系统 长期记忆系统提供的是跨会话、跨任务、跨智能体实例持续存在、且可被索引与检索的存储。中期技术依赖的是摘要的前向注入，而长期系统支持任意回忆：给定一个查询，系统都能取回最相关的已存记忆，而不管这些记忆是在什么时候创建的。正是在这一层，智能体的经验开始随时间沉淀。 #### 5.5.1 基础架构 **受操作系统启发的分层记忆。** Packer et al. (2023) 提出了这一领域的关键抽象：把 LLM 的上下文窗口视作 RAM，把外部存储视作磁盘，再赋予模型显式换入换出信息的函数调用能力。它与虚拟内存的类比是精确的：就像操作系统通过透明分页让应用获得“更大内存”的错觉一样，MemGPT 通过透明的记忆管理，让 LLM 获得“更长上下文”的错觉。智能体因此可以操作远远超出物理窗口限制的上下文，并在需要时从外部存储中取回相关历史。该论文明确建立了智能体记忆与操作系统内存之间的对应关系，而这恰恰构成了后续大多数长期记忆系统的底层直觉。 **观察、反思与检索。** Park et al. (2023) 在社会模拟智能体的语境中提出了 MemoryStream 架构。MemoryStream 会把智能体的所有观察都存成自然语言记录，并附上时间戳与重要性分数。每一步中，检索模型会结合三类信号来浮出最相关的记忆：新近性、重要性（由智能体在写入时打分）以及与当前查询的相关性。第二个机制是“反思”：系统会周期性地把已存观察综合成更高层次的洞见。智能体会追问自己：最近经历中最值得深挖的问题是什么；随后取回相关记录，并生成结论，再把这些结论存回 MemoryStream。消融实验表明，这三项组成——观察、反思和检索——都会独立提升行为质量；拿掉任何一项，性能都可测量地变差。观察—反思—检索这一三元组，如今仍是智能体记忆设计的标准模板。 **动态遗忘与人格建模。** Zhong et al. (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%，同时所用 token 比完整上下文方案少 90%（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 的研究人员独立复现。 **以推理驱动的个性化。** 由 Plastic Labs 开发的 Honcho（Plastic Labs, 2025）构建的不是“关于用户事实的存储”，而是“用户模型”。一个名为 “dreaming” 的异步推理流水线会在后台持续处理既往交互，不仅提取显式事实，还会推断用户的偏好、沟通风格与不断变化的目标。其以实体为中心的数据模型支持多智能体环境：多个智能体可以与同一用户交互，而每个智能体都保有自己的观察视角，从而避免交叉污染；与此同时，共享的用户模型会从所有交互中不断累积理解。 **集体记忆。** MozillaAI 的 `cq`（MozillaAI, 2025）填补了其他系统尚未覆盖的一个空白：跨智能体实例的共享记忆。大多数长期记忆系统都是“每个智能体一份”或“每个用户一份”；当多个智能体处理相关任务时，每个实例都会独立重新发现其他实例早已学到的内容。`cq` 是一个面向共享式智能体学习的开放标准，允许整支 agent fleet 持久化、查询并确认集体知识。它的架构原生兼容 MCP，并分为三层：开发者本机保存的本地知识、团队可访问的组织共享知识，以及跨团队知识。“出错后钩子（post-error hook）”模式尤其具体：当智能体遇到错误时，`cq` 会自动查询集体知识库，从而防止同一种失败在组织内部的多个部署中被重复、独立地解决。 #### 5.5.3 学术综述与分类法 Zhang et al. (2025) 对记忆机制的综述，为这一层提供了标准的学术分类法。它区分了短期工作记忆与长期记忆，并将后者进一步分为语义、程序和情景三类。其形式化的“写入—读取—管理”循环，已经成为描述记忆系统行为的标准词汇。更新的一篇综述（Du, 2026）则在此基础上，把这一循环放入 POMDP 风格的 agent 周期中加以形式化，并提出一个覆盖记忆范围、存储格式和组合结构三维度的分类法。它总结了三种工程模式：模式 A（单体上下文）、模式 B（上下文窗口 + 检索存储）、模式 C（带学习控制策略的分层记忆）。它们大致对应于本节讨论的短期、中期与长期三层。Gao et al. (2023) 关于 RAG 的综述，则为上文所述生产记忆系统的检索层提供了检索增强生成的背景。 ### 5.6 长时程技术：让智能体在 100+ 轮后仍保持连贯 前面各节分别处理单一时间尺度的问题。而长时程任务——包括大型代码库迁移、多会话研究项目和长时间自主工作流——要求系统同时协调三层记忆，并实时决定在每个时点该用哪种技术。本节讨论的，就是这种规模下浮现出的集成层技术。 **上下文压缩。** 压缩会在上下文窗口接近上限时，对其做摘要，并以累积状态的压缩表示重新启动执行。Anthropic Applied AI Team (2025) 详细描述了其中的校准挑战。摘要必须保留架构决策、尚未解决的 bug 以及实现细节，同时丢弃冗余工具输出和那些已经被后续步骤吸收的中间推理。推荐的调优流程，是先把召回做满，尽可能捕获轨迹中一切潜在相关信息，然后再通过迭代提高精确性，逐步剔除多余内容。不能反过来一开始就先追求精简。过早删掉太多信息，会让智能体失去后来真正需要的上下文，而这种损失是无法追回的。工具结果清理是最轻量的压缩形式：一旦智能体已经对某个工具输出采取了行动，完整工具输出就会被紧凑的路径引用所替换。这种做法可以持续应用，如今也已成为 Anthropic 开发者平台上的产品级特性（Anthropic, 2025c）。 **子代理上下文隔离。** 当一个任务要求对某个子主题做深入探索时，这种探索本身会产生大量中间上下文：对子任务本身很有用，但会污染编排器对整体任务的视野。子代理架构的解决办法，是把子任务分配给专用代理，每个代理都拥有一个全新的上下文窗口，然后只向编排器返回一份压缩到 1,000 到 2,000 token 的发现摘要（Anthropic, 2025e）。详细探索上下文会被隔离在子代理内部；编排器只接收蒸馏后的结果。Manus Team (2025) 描述了这一模式的进一步细化。对于只需要产出结果的简单子任务，根本不共享上下文。对于确实需要共享状态的复杂子任务，则把编排器的完整上下文传给子代理。智能体之间共享上下文成本很高：它会带来更大的 prefill，并且会消除不同系统提示词之间的 KV-cache 复用。因此，对每一种任务类型，都必须显式权衡隔离成本与协同收益。 **混合决策框架。** 生产部署不会把某一种技术一视同仁地用到所有场景，而是会根据任务结构，在执行过程的不同节点选择不同技术。Anthropic (2026c) 将这一框架概括为：预加载那些始终需要的内容；按需即时检索那些有条件才需要的内容；当窗口接近饱和时压缩历史；当某个子任务需要深入探索、而这种探索会污染编排器上下文时，生成子代理。Anthropic (2025d) 又补充了 harness 层的视角：检查点—恢复模式使智能体能够在不丢失任务状态的情况下跨过瞬时故障，而Lifecycle Hooks则可以在可配置阈值触发时自动执行压缩或记忆整合。这是正确的职责划分。上下文管理应当是基础设施的工作，而不是智能体自己的工作。当 harness 自动处理压缩与整合时，模型就能把精力集中在任务推理上。 ### 5.7 上下文漂移与当前方法的极限 “绑定约束”视角将上下文漂移视为一种控制器侧失效模式：由于模型只能看到 harness 暴露出的状态投影，任务相关上下文的丢失或扭曲，与其说只是模型自身的问题，不如说首先是 harness 的属性（Bölük, 2026b）。上文介绍的所有技术，都在不同条件下、不同程度上有效。但没有一种真正解决了底层问题。上下文漂移——即智能体行为在长时间交互中逐步退化——仍然是这一层最困难的开放挑战。 ## 6 生命周期与编排（L） > **图 9：** 按本章的编排类别组织的 LLM 智能体生命周期与编排代表性工作。 ![](/files/pq3A017vzb0sZ1DjsLzx) 生命周期与编排（L）关注智能体系统如何把一项任务贯穿于重复的模型调用、工具调用、失败、修订与交接之中。在这一层中，我们把早期框架里常被分开讨论的两类问题合并起来：一是智能体的执行流程，二是该流程所读取和写入的运维状态。对于长时间运行的任务，可靠性不仅取决于模型能否给出一个好的下一步动作，还取决于 harness 能否记住已经发生过什么、决定接下来该发生什么、从错误中恢复、协调子任务，以及在任务完成时及时停止（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（k） | 小节 | 主要模式 | 执行模型 | | --------------------------------------- | ---------------------------- | --------------: | --- | -------- | ----- | | 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 | 扇出 | 混合 | | 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 生命周期状态管理 生命周期状态管理关注的是：为了让一次智能体运行能够跨越轮次、会话、失败与交接继续推进，harness 需要维护哪些运维状态。这包括待处理子任务、工具结果、中间工件、仓库变更、协同元数据、会话持久化，以及 checkpoint / resume 机制。这些机制让编排从“瞬时的”变成“可持续的”：智能体能够在既有工作的基础上继续，而不是把每一步都当作彼此隔离的模型调用。 这里的核心权衡，在于无状态执行与有状态执行之间。无状态设计从既有交互历史中重建执行过程，可提升可复现性与可审计性，但随着轨迹增长，成本会越来越高。有状态设计则把执行状态持久化到文件、数据库、代码仓库、任务图或外部服务里，提升连续性与恢复能力，但同时引入一致性与调试挑战（OpenAI, 2026b; Anthropic, 2026c）。因此，许多实用 harness 会采用混合设计，将可回放的交互历史与持久化工件结合起来。 这种状态不同于 §5 的“上下文与记忆”层；后者关注的是提供给模型进行推理的信息，例如检索到的文档、记忆或对话历史。它也不同于 §7 的“可观测性”；后者关注的是日志、追踪和系统行为监控。这里的重点，是 harness 自身为了继续与协调执行而使用的运维状态，例如待处理子任务、检查点、重试、共享工件或执行状态。 ### 6.2 单智能体内循环 单智能体内循环是智能体系统中的基本执行单元。一个智能体通过工具使用与环境反馈反复交互，而不存在多个智能体之间的显式协同。这个抽象支撑了交互式编码、调试与问题求解等场景。 从概念上说，单智能体循环遵循 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 多智能体编排模式 多智能体编排通过组合具有专门角色的多个智能体，把单智能体循环扩展了出去。与其让一个智能体独自完成规划、执行、检查和修订，多智能体 harness 可以把这些职责分散到多个智能体或子智能体上。这种结构支持任务分解、并行探索、批评、验证与聚合，因此比孤立循环更适合复杂任务。 在这一设计空间里，出现了几种反复出现的模式。**分层编排**用一个高层控制器给智能体或子智能体分配工作，并整合它们的输出。**团队编排**则把一组具备不同命名职责的专门智能体，作为一支协同团队暴露出来。**工作流编排**把智能体和工具组织进显式阶段或控制逻辑。**扇出**会并行运行多个智能体，以探索多样化方案。**图式组合**则把智能体、工具或状态表示成交互图中的节点，使多种协调模式可以并存。这些标签与表 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 的全生命周期流水线 全生命周期编排管理的是从规格说明到经验证输出的整个任务工作流。在这一层里，焦点不只是“智能体如何相互交互”，更是“harness 如何在规划、实现、验证、审查与交付之间支撑长时程执行”。 这里的核心抽象是**任务运行器（task runner）**：一种负责调度、状态持久化、重试、验证，以及在完整任务生命周期内进行迭代式改进的 harness（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） > **图 10：** 按本章运维类别组织的 LLM 智能体可观测性与运维代表性工作。 ![](/files/bCQoopRA4Mgtsf4EcFIl) 可观测性与运维（O）是 ETCLOVG 的第五层，也是我们从“Lifecycle Hooks 的附属物”提升为独立层的两层之一（见 §1 中的主张 2）。支撑这一层的系统，来自支撑主张 3 的 148+ 项目语料。 这一层关注的是：在生产环境中，如何监控、调试并提升智能体行为的可靠性。我们认为，可观测性应被独立对待，而不应只是 Lifecycle Hooks 的附属物，因为它已经催生出一个专门的生态，包含平台、规范与工程实践。 ### 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 的语义约定，为模型名、温度、token 数量与延迟等定义了 span 属性（OpenTelemetry, 2026）。两个开源项目把这些约定真正落地：OpenLLMetry 为 LLM 提供方（OpenAI、Anthropic、Cohere）和向量数据库（Pinecone、Chroma、Weaviate）提供自动埋点库，输出标准 OTel spans 与指标（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 交互；以及情境层面的环境状态与用户输入。这三个表面被组织在统一封套之下，并可接入 OTel 进行导出。其中，认知表面与 Harness Engineering尤其相关，因为它记录了显式推理工件、计划、反思与自我修正。这些记录为调试“错误推理”而非“系统错误”导致的失败，提供了原始材料。 ### 7.2 智能体专用运维平台 通用追踪平台通常把自身抽象建立在 LLM 调用、工具调用与检索步骤之上，并把它们视作 span 级事件。智能体专用平台则在其上增加了一层抽象，用以表示智能体层面的关切：多步会话跟踪、智能体身份与角色管理、工具选择策略，以及跨会话状态交接。AgentOps SDK 引入了一个分层 span 模型，围绕智能体生命周期来组织会话、智能体、操作或任务、工作流、工具调用与 LLM 调用，而不是把这些视作相互孤立的 API 调用（AgentOps AI, 2026）。RagaAI Catalyst 面向 RAG 与多智能体工作负载，提供质量与安全仪表盘，以显露检索层与智能体层的异常（RagaAI, 2026）。Laminar 则提供一个以开源优先的智能体可观测性平台，结合了轨迹、评估与提示词管理（Laminar AI, 2026）。 学术界也开始将这些关切形式化。Moshkovich 与 Zeltyn（2025）提出了一条六阶段的 AgentOps 自动化流水线：观察、收集指标、检测异常、执行根因分析、推荐修复措施，以及自动化修复。他们还把利益相关者空间分解为四类角色：开发者、测试人员、SRE 与业务用户；每类角色都会在不同生命周期节点介入这条流水线。他们的配套实证研究（Moshkovich et al., 2025）又引入了“任务流发现（task-flow discovery）”这一可观测性原语，并通过用户研究表明：79% 的从业者认为，不确定性的执行流是智能体系统中最重要的挑战。 自然语言智能体 harness（NLAH）框架（Pan et al., 2026）及其配套开源实现，则朝另一个方向迈进：把 harness 本身视为一等研究对象。通过系统性的消融实验，作者量化了单个 harness 模块对下游智能体性能的贡献。这些模块包括工具注册表、权限系统、钩子、skills 与上下文折叠。对于可观测性的意义在于：harness 不仅是被监控的对象，也是干预的来源。每一个被消融的模块，都构成了可被可观测性流水线标记和调节的“旋钮”。 认知可观测性，则把智能体级监控进一步扩展为不仅追问“智能体做了什么”，还追问“它为什么这么做”。Watson（Rombaut et al., 2025）正式提出了这一概念：它部署一个“替身智能体（surrogate agent）”，在复现主智能体输出的同时，通过提示词归因生成逐步推理轨迹。在 MMLU 与 SWE-bench-lite 上，结合 AutoCodeRover 与 OpenHands 的评估表明，恢复出的推理轨迹既有助于人工调试，也有助于自动纠正，并能带来可测量的任务成功率提升。AgentLens（Lu et al., 2024）则通过一个三栏可视分析系统完成可视化闭环：Outline View 展示智能体轨迹，Agent View 展示带因果弧线的事件堆栈，Monitor View 则展示同步的环境回放。它把原始执行日志转化为分层结构化的行为叙事。一项有 14 名参与者的用户研究显示，在复杂分析任务上，它显著优于仅基于回放的基线。还有一些更专门化的可视化工具，例如 claude-code-reverse，会逆向分析特定编码智能体的交互链条，作为理解 harness 级行为的研究工件（Yu, 2026）。 ### 7.3 成本跟踪与优化 LLM 推理按 token 计费，而智能体 harness 会放大成本暴露，因为一次面向用户的任务可能触发数十次 LLM 调用，每次都有自己的提示词组装、工具结果注入与响应生成。因此，可观测性在这里有双重要求：**跟踪**（知道 token 花在了哪里）与**优化**（用更少 token 达到同样效果）。 在跟踪方面，TensorZero 提供了一套统一的 LLMOps 栈，把网关、可观测性、实验与优化打包进单一服务，从而实现按调用与按任务的成本归因（TensorZero, 2026）。Helicone 则采取了极简做法：作为一个可直接接入的代理，几乎无需改代码，就能增加成本和延迟监控，因此特别适合那些想先获得成本可见性、但暂时不想上完整可观测性平台的团队（Helicone, 2026）。 在优化方面，FrugalGPT（Chen et al., 2023）给出了基础性表述，提出了三种降本策略：提示词自适应、LLM 近似，以及 LLM 级联。它表明，一个自适应级联可以在保持 GPT-4 性能的同时，将成本最多降低 98%，方法是把更容易的查询路由给更便宜的模型。GPTCache（Bang, 2023）则提供了一个语义缓存层：在请求真正到达 LLM 之前，先拦截重复或转述的查询，并通过 embedding 相似度检索缓存响应。路由与缓存因此共同成为生产级成本优化栈中的反复出现的构件，并且可以直接应用到 harness 级埋点中：每一次工具调用与上下文组装步骤，都可以被独立计量与路由。 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 的评估表明，该方法可减少 31–42% 的 GPU 小时（在 A100 规模集群上折算成年节省 286 万美元）。 对于 Harness Engineering师而言，其含义是：成本可观测性必须跨越多个层次——API 级 token 跟踪（Helicone、TensorZero）、应用级路由决策（FrugalGPT、QC-Opt），以及基础设施级资源利用率（Dual-Pool、KV-cache 占用率）。Anthropic 关于智能体编码评估中基础设施噪声的研究（Anthropic, 2026a）提供了一个值得警惕的补充：仅仅是基础设施配置，就足以让 Benchmark 分数波动 6 个百分点（p < 0.01）。这一发现表明，成本优化与评估保真度紧密缠绕在一起，因为为了节省成本而削减资源，可能会以细粒度可观测性不可见的方式悄悄损害智能体性能。 ### 7.4 可靠性工程 失败恢复、checkpoint / resume、重试策略与会话恢复，都是 harness 层面的关切；它们决定了一个长时间运行的智能体能否经受住瞬时失败。对于跨越多个上下文窗口运行的智能体来说，这一点尤其尖锐，因为每一个新会话开始时，都不记得先前发生过什么（Anthropic, 2025d）。Anthropic 关于 Harness Engineering的工作识别了长时间运行编码智能体的四种反复出现的失败模式：智能体试图“一口气”完成整个任务；智能体过早宣称项目已完成；智能体在会话之间把环境留在损坏状态；以及智能体在没有充分测试的情况下，把特性标记为完成。其两段式解决方案，并不是改进模型，而是直接通过 harness 设计来应对这些可靠性问题（Anthropic, 2025d）。方案先用一个 initializer agent 把任务分解成结构化特性列表，并建立进度跟踪工件，包括 git 仓库、进度文件和初始化脚本；随后再由 coding agent 以增量方式逐项处理，每次只做一个特性，同时留下干净的交接状态。 后续工作扩展了这一模式。Anthropic 受 GAN 启发的三智能体架构（planner、generator、evaluator）引入了 sprint contracts 与分离式自我评估，以应对智能体过度称赞自身工作的倾向（Anthropic, 2026c）。值得注意的是，作者表明 harness 的复杂度应随模型能力变化：当从 Opus 4.5 升级到 Opus 4.6 时，他们完全移除了 sprint 结构和上下文重置，把成本从 200 美元降到 125 美元，同时保持输出质量。这说明了一个一般原则：harness 的每个组件，都编码了某种关于“模型单靠自己做不到什么”的假设；而随着模型进步，这些假设会过时。 在基础设施层，Anthropic 的 Managed Agents 架构（Anthropic, 2026b）把“脑”（harness + LLM）、“手”（沙箱与工具）以及“会话”（持久化事件日志）解耦，使它们都能够被独立恢复。如果 harness 崩溃，一个新实例可以通过 `wake(sessionId)` 被重新拉起，并从会话日志中的最后一个事件继续。如果沙箱失效，harness 会把错误作为工具调用失败捕获，并重新配置一个新的沙箱。凭证存储在外部 vault 中，从不进入沙箱。这个架构把所有组件都从“宠物”（不可替代、需要人工照料的实例）转变为“牲口”（可互换、可自动重配的实例），而这正是大规模可靠运行智能体的先决条件。 学术界则提供了可靠性工程必须面对的失效模式分类法。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 在三种层级上分类异常——全局、单点与多点，同时辅以 human-in-the-loop 的策略细化。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 框架则更进一步，把 harness 本身做成模块化、可内省的对象，并能够通过消融实验量化每个组件的贡献。Anthropic 的 Managed Agents 架构则采取基础设施级视角，把 harness 组件虚拟化为可替换接口（`execute()`、`emitEvent()`、`getEvents()`），从而在不改变周边系统的前提下容纳未来的 harness 设计。 **“harness 即假设”原则。** harness 的每一个组件，都编码着某种关于“模型无法单独完成什么”的假设（Anthropic, 2026c）。随着模型进步，可观测性系统不仅要检测“智能体何时失败”，还要检测“哪些 harness 组件已经变成不再必要的额外负担”。理想的可观测性系统，应当包含一层**元监控**：追踪哪些干预措施（上下文重置、evaluator 反馈循环、工具限制）仍然承担关键负载，从而在模型升级的同时，也能持续简化 harness。 ## 8 验证与评估（V） 验证与评估（V）是 ETCLOVG 的第六个支柱（见 §1 中的主张 2）。我们讨论的系统与 Benchmark，来自支撑主张 3 的 148+ 项目语料。 > **图 11：** 按本章“从任务到反馈”的生命周期组织的 LLM 智能体验证与评估代表性工作。 ![](/files/p8Bc9Swc7wvYl8r33I6L) ### 8.1 将 harness 评估视为“任务到反馈”生命周期 一种具备 harness 意识的评估，应当把最终得分视为**模型—harness 配对**的属性，而不是单独属于模型本身的属性。这推动了两种评估协议：要么在模型之间锁定同一 harness，要么把 harness 配置变化显式地作为实验因素（Bölük, 2026b）。我们把 harness 评估组织为一个“任务到反馈生命周期”：一个结构化过程，从定义智能体被要求做什么开始，以把评估结果反馈回 harness 改进为止。图 12 总结了这个五阶段的任务到反馈生命周期。该生命周期建立在传统 LLM 评估与智能体评估之间的一个关键区别之上：传统 LLM 评估主要是在固定输入上给输出打分；而 harness 评估衡量的是一个执行 episode——任务被锚定在某个环境中，智能体随着时间与工具和状态交互，轨迹被捕获，evaluator 不仅评判最终结果，也评判通往该结果的路径（Kapoor et al., 2025; Anthropic, 2026b; LangChain, 2025b）。 推动这一生命周期视角的一个核心动机是：评估基础设施噪声会伪装成模型失败。失败的运行不仅可能反映模型局限，也可能反映工具损坏、上下文陈旧、未重置的沙箱、脆弱测试、Benchmark 歧义，或不稳定的 judge（Kapoor et al., 2025; Hu et al., 2025a; Jimenez et al., 2024）。因此，评估不应只报告一个最终分数，而应当把智能体行为转化为结构化判定、失效归因与回归反馈。 > **图 12：** harness 评估的“任务到反馈”生命周期。第 V 节把验证与评估组织成一个五阶段的质量控制回路：任务与 Benchmark 锚定、执行前就绪性验证、受控执行与轨迹捕获、多层级判定与失效归因，以及持续回归与部署反馈。图中强调，harness 评估不应只报告最终成功率，还应诊断失败来源，并把由此得到的证据反馈回系统性的 harness 改进之中。 ![](/files/168ohWjxcP2itGf0LOxY) 这五阶段分解遵循了一次智能体评估运行的因果路径。在智能体能够被评估之前，Benchmark 必须规定任务、环境、工具、约束与成功标准。执行之前，必须验证设置，以免把环境或 grader 的失败误判为模型失败。执行期间，harness 必须捕获足以诊断运行的轨迹。执行之后，系统必须对结果、轨迹以及 evaluator 的可靠性做出判定，并把失败归因到可能的 harness 组件。最后，这些诊断又应反馈进回归测试与未来的 harness 修订之中。从这个视角看，评估不是终点式的打分步骤，而是围绕完整智能体 harness 的质量控制回路。 我们围绕五个阶段展开讨论： * **任务与 Benchmark 锚定**：定义评估的对象、环境、工具、约束与成功标准（§8.2）。 * **执行前就绪性验证**：在智能体运行前检查沙箱、依赖、工具、上下文状态、权限策略、预算与 graders 是否已被正确初始化（§8.3）。 * **受控执行与轨迹捕获**：在可复现条件下运行智能体，同时记录模型输出、工具调用、状态变化、错误、重试、成本与延迟（§8.4）。 * **多层级判定与失效归因**：在结果、轨迹和 evaluator 三个层面评估运行，并在 harness 栈中定位最可能的失败来源（§8.5）。 * **持续回归与部署反馈**：把评估结果转化为后续 harness 修订可用的回归测试、监控信号与工程反馈（§8.6）。 ### 8.2 阶段 1：任务与 Benchmark 锚定 第一阶段问的是：**我们在评估什么？** 对于 LLM 智能体而言，任务不只是自然语言提示词，而是一个被嵌入环境状态、可用工具、允许动作、约束、终止条件与成功标准共同定义的问题。因此，任务锚定是 harness 评估的基础：如果没有被明确规定的环境与成功条件，后续分数就无法被可靠解释。 #### 8.2.1 软件工程与终端任务 软件工程 Benchmark 是最成熟的智能体评估形式之一，因为它们把真实任务与可执行的结果验证结合了起来。SWE-bench 把每个任务锚定在真实的 GitHub issue 与代码仓库快照之中，再通过运行测试来评估生成的补丁是否解决了问题（Jimenez et al., 2024）。Terminal-Bench 则把这一思路扩展到命令行工作流：智能体通过编辑文件、运行命令、设置依赖并解释失败，与终端环境交互（Merrill et al., 2026）。这一类别的关键洞见是：强有力的结果验证器，依赖同样强有力的任务锚定。只有当仓库状态、依赖和目标成功标准被精确规定时，测试才能充当可靠的 evaluator。否则，测试失败既可能意味着补丁无效，也可能意味着环境不一致，或 Benchmark 实例定义不足。 #### 8.2.2 Web、浏览器与计算机使用任务 Web 与计算机使用 Benchmark，把任务锚定在交互式环境中，其中成功由浏览器、桌面或应用程序状态变化来定义。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）。这些 Benchmark 表明，浏览器与计算机使用评估同时是一个评估问题，也是一个环境设计问题。Benchmark 必须提供真实接口、隔离任务状态、暴露适当观察，并定义可度量的成功谓词。这就在执行环境层与评估层之间建立了直接桥梁。 #### 8.2.3 跨领域与企业工作流任务 第三组 Benchmark 测试的是更广泛的智能体能力，覆盖异构工具、环境与工作流。AgentBench 在操作系统、数据库、Web 浏览与游戏等多种场景中评估 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）。这一 Benchmark 家族的主要贡献，在于**覆盖面**：它测试 harness 能否跨越任务类型、工具接口、状态表示、工作流与成功条件进行泛化。 ### 8.3 阶段 2：执行前就绪性验证 第二阶段问的是：**这次评估能否被公平且可复现地运行？** 这一阶段在 Benchmark 排行榜中往往不可见，但对 harness 评估却至关重要。在智能体开始之前，harness 必须验证环境、工具、上下文状态、权限边界、预算约束与 evaluators 是否已正确初始化。如果缺少这一层就绪性检查，下游失败就会变得难以归因：一次失败的运行既可能由智能体导致，也可能由评估设置导致。 #### 8.3.1 环境与沙箱就绪性 环境就绪性检查的是：沙箱、代码仓库、浏览器、终端或虚拟机，是否都从一个已知基线启动。在软件工程场景中，这包括仓库快照、依赖、任务设置与测试可执行性；在浏览器与计算机使用场景中，则包括网站重置、浏览器 profile、桌面状态与服务可用性。 一些系统明确把这个问题摆到了台面上。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 命令与文件操作是否可用，并且描述一致。**上下文就绪性**检查历史、记忆存储、scratchpad 与检索文档是否已被重置，或被有意初始化。**权限就绪性**则检查文件访问、凭证、网络访问与审批闸门，是否与 Benchmark 规格一致。 这一阶段把评估与工具层、上下文层和治理层连接在一起。如果不同运行之间工具描述发生变化，那么 Benchmark 实际上就不再测量同一个动作空间；如果记忆或上下文未被重置，智能体就可能利用泄漏状态；如果权限过于严格，一个有能力的智能体可能会因为治理原因失败；如果权限过于宽松，不安全或 exploit Benchmark 的行为又可能不会被检测出来。SWE-agent、SWE-ReX 与 OpenHands 等系统都表明：工具暴露、shell 访问、浏览器访问、执行后端与运行时接口，都不能与评估设计分开来看——智能体—计算机接口决定了哪些动作是可能的，也就决定了 Benchmark 真正在测量什么（Yang et al., 2024; SWE-agent Team, 2024; Wang et al., 2025b）。因此，一个严谨的评估 harness 应当把这些配置——包括工具注册表、上下文策略、权限策略、预算、超时、模型配置与运行时接口——都记录为评估元数据。 #### 8.3.3 Evaluator 与 Grader 就绪性 在执行开始之前，evaluator 本身也必须被验证。确定性 grader 应检查脆弱性、缺失依赖以及与环境状态的兼容性；LLM-as-Judge 的提示词、rubric 与 judge 模型应当进行版本管理；人工审计协议也应当预先定义。 在 SWE-bench 这类 Benchmark 中，可执行测试提供了可扩展的结果验证，但分数的有效性仍然依赖正确的环境设置、任务规格与测试可靠性（Jimenez et al., 2024）。对于开放式任务，LLM-as-Judge 系统需要校准、偏差缓解与一致性检查，而不能只是盲目复用一个强模型作为 grader（Zheng et al., 2023; Gu et al., 2024）。因此，evaluator 就绪性是有意义的失效归因的前提。 ### 8.4 阶段 3：受控执行与轨迹捕获 第三阶段问的是：**执行过程中究竟发生了什么？** 在传统 LLM 评估中，证据可能只是一组输入—输出对；而在智能体评估中，轨迹是一条多步轨迹：模型观察状态、推理、调用工具、接收工具输出、修改环境、处理错误，并最终终止。因此，受控执行与轨迹捕获是把 Benchmark 运行转化为可诊断证据的必要条件。 #### 8.4.1 受控 Rollout 与可复现执行 一次 **Rollout** 是智能体评估的基本单元。它包括任务、模型配置、harness 配置、动作序列、中间观察、最终状态与评分结果。受控 Rollout 要固定住意外变异的关键来源，包括环境状态、工具可用性、超时、预算、权限策略与 evaluator 版本。当不可避免地仍有非确定性时，重复 Rollout 就能暴露方差，而不是把它隐藏在单一分数后面。 一些系统很好地说明了为何需要可复现执行。SWE-agent 把代码仓库导航、文件编辑与测试执行暴露为交互循环的一部分（Yang et al., 2024）。OpenHands 结合了代码编辑、命令行执行、浏览器交互、沙箱执行与 Benchmark 集成（Wang et al., 2025b）。SWE-ReX 则抽象出了本地与远程的沙箱化 shell 环境，使执行后端可以变化，而无需改变智能体逻辑（SWE-agent Team, 2024）。LangChain 进一步把深度智能体评估分解为单步验证、完整回合评估与多轮模拟（LangChain, 2025b）。这些系统共同表明，可复现性要求回放完整的“模型—工具—环境”交互，而不仅仅是重新运行一次模型调用。 #### 8.4.2 原生面向轨迹的评估 轨迹捕获把二元打分转换为因果诊断。一个原生面向轨迹的 harness 应当记录模型输出、工具调用、工具结果、环境状态变化、上下文快照、错误、重试、恢复动作、token 使用、延迟与成本。这些轨迹能够区分一些表面相似的失败：一个智能体可能根本没找到相关文件，另一个则可能找到了文件但生成了无效补丁。它们也能揭示“不理想的成功”，例如 Benchmark exploit、过量工具调用或权限违规。 HAL 把日志与轨迹视为标准化智能体评估中的一等工件，通过大规模智能体日志去检查那些最终分数可能掩盖的行为（Kapoor et al., 2025）。R2E-Gym 同样把可执行轨迹与混合验证器连接起来，既服务于测试期评估，也服务于训练期反馈（Jain et al., 2025）。对于 Harness Engineering来说，轨迹并不是附带的调试工件，而是主要的评估数据。 #### 8.4.3 成本、延迟与资源跟踪 智能体评估不应只报告质量，还应报告达成该质量的成本。长时程智能体可能通过花费更多 token、调用更多工具、更频繁重试或使用更强模型，来提升成功率。因此，harness 级评估应当跟踪 token 使用量、模型成本、墙钟延迟、工具调用次数、重试次数与资源消耗。 评估不应只按成功率给智能体排序，而应显式展示成功率—成本—延迟前沿。HAL 明确把智能体评估框定为一种标准化、成本感知的过程（Kapoor et al., 2025），而 LangChain 的深度智能体评估指南则强调，在可复现环境中进行多粒度评估，以便比较成本—质量权衡（LangChain, 2025b）。这对于已部署的智能体服务尤其重要，因为真正的优化单元是预算和延迟约束下反复出现的工作负载。 ### 8.5 阶段 4：多层级判定与失效归因 在完成受控执行与轨迹捕获之后，核心问题变成：**应该如何判定这次运行；如果它失败了，又该如何定位失败？** 我们把阶段 4 定义为一个由**多层级判定**与**失效归因**组成的联合过程。多层级判定会在三个层面评估运行：最终结果是否正确、轨迹是否高效且符合策略，以及 evaluator 本身是否可靠。随后，失效归因利用这些信号去诊断失败最可能源于哪里，例如模型、工具接口、上下文管理器、执行环境、编排循环、Benchmark 规格或 evaluator。正是这一阶段把 harness 评估与普通 Benchmark 评估区分开来：目标不只是给出一个分数，而是把执行证据转化为可执行的工程诊断。 #### 8.5.1 结果层评估 结果层评估衡量的是最终任务目标是否达成。在软件工程中，这通常通过单元测试、回归测试或面向 issue 的特定验证来实现，例如 SWE-bench（Jimenez et al., 2024）。在终端任务中，结果评估可能依赖最终文件、命令输出或任务特定检查器（Merrill et al., 2026）。在浏览器与企业工作流 Benchmark 中，它通常依赖最终环境状态，例如表单是否提交成功、工单是否更新、配置是否变更（Zhou et al., 2024; Drouin et al., 2024）。在 GAIA 这类通用助手 Benchmark 中，结果可能就是一个答案字符串或结构化响应（Mialon et al., 2023）。 结果层评估的优势，在于可扩展性与可解释性：它给出清晰的任务级成功信号，并支持排行榜比较。它的局限，则在于压缩。完整执行 episode 被压缩为一个值，从而掩盖了智能体是否以稳健、安全或高效的方式成功。因此，结果评估是必要的，但并不充分。它回答的是“任务是否完成”，而不是“harness 是否产生了一次值得信赖的执行”。 #### 8.5.2 轨迹层评估 轨迹层评估衡量的是智能体所走路径的质量。它追问的是：智能体是否选择了合适工具、是否以合理顺序组织动作、是否避免了冗余调用、是否遵守权限边界、是否能从错误中恢复、以及是否能在时间推移中保持上下文一致性。正是在这一层，智能体评估与传统输出评估最明显地分叉：即便最终答案正确，轨迹仍可能不可接受，例如智能体浪费过多 token、反复调用无关工具、违反权限，或依赖脆弱的、特定 Benchmark 的行为。 ReAct 通过把智能体行为表示为推理、行动与观察交错的步骤，为轨迹层分析提供了概念基础（Yao et al., 2023）。现代智能体 Benchmark 把这一视角延伸到了更丰富的环境中，其中每一步动作都会改变未来步骤可用的状态。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 Engineering尤其有价值，因为它提供了从失败走向修复的路径。如果智能体失败是因为选错工具，那么可能需要改进工具接口；如果它忘了先前约束，那么可能需要调整上下文层；如果它陷入循环而无法恢复，那么编排层就可能需要生命周期控制。因此，轨迹评估会把 Benchmark 结果转化为面向具体层的工程反馈。 #### 8.5.3 Evaluator 层评估 Evaluator 层评估问的是：**evaluator 本身能否被信任？** 确定性验证器，例如单元测试或基于状态的检查器，可复现、便宜，也易于跨系统比较，但它们比较狭窄，而且很难为开放式任务设计。LLM-as-Judge 系统在自然语言输出与轨迹评估方面很灵活，但它们引入了偏差、非确定性与额外成本。人工审计在含糊或安全关键的场景中仍然重要，但无法扩展到持续评估。 G-Eval 表明，基于 LLM 的 evaluator 在 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 来说，Evaluator 层评估并非可有可无。如果 grader 不稳定、测试具有非确定性，或 LLM judge 带有偏差，那么评估噪声就会被错误归因给智能体或模型。因此，一个稳健的 harness 应优先采用分层 grader：用确定性检查处理客观状态变化，用 LLM judge 处理语义或轨迹层评估，用人工审计处理歧义或高风险情况。Evaluator 应被视为一个待测组件，而不是系统外部不可质疑的神谕。 #### 8.5.4 跨 Harness 各层的失效归因 失效归因识别的是：在一次运行被判定之后，究竟应该修什么。一次失败的 Rollout 可能源于模型推理、工具接口设计、陈旧或过度压缩的上下文、沙箱不稳定、编排循环、Benchmark 歧义，或 evaluator 不可靠（Kapoor et al., 2025; Hu et al., 2025a; Jimenez et al., 2024; LangChain, 2025b）。结果层信号告诉我们目标是否达成；轨迹层信号揭示动作序列是否连贯、高效并符合策略；Evaluator 层信号则告诉我们这个分数本身是否可信。合在一起，这些信号支撑的是诊断，而不只是打分（Kapoor et al., 2025; LangChain, 2025b）。 在实践中，归因很少是一个单标签分类问题。模糊的任务规格可能导致智能体选错工具；过度压缩的上下文可能导致它遗忘约束；沙箱依赖问题可能触发恢复行为并增加成本；脆弱的 judge 又可能掩盖一个其实有效的解。因此，失效归因应被理解为针对完整轨迹的诊断过程，而不是附着在最终分数上的一个事后标签。阶段 4 的输出，不应只是一个判定结果，而应是一份结构化诊断，供阶段 5 反馈到回归测试与 harness 改进之中。 ### 8.6 阶段 5：持续回归与部署反馈 最后一个阶段问的是：**评估结果如何驱动下一轮 harness 修订？** 智能体 harness 会持续演化：提示词、工具 schema、MCP 服务器、上下文策略、沙箱镜像、编排循环、治理规则与 judge 提示词，都会随着时间变化。持续评估会把 Benchmark 结果与生产失败转化为作用于 harness 自身的回归系统。 #### 8.6.1 面向 Harness 变更的回归评估 回归评估不仅应由模型变更触发，也应由 harness 变更触发。工具描述、上下文压缩策略、沙箱镜像、权限规则或 judge 提示词的变动，都可能改变智能体行为或评估分数。由于 harness 各组件之间会相互作用，局部改进也可能引发全局回归。 实践中的模式，是维护一套分层评估集：面向工具 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）。尽管这些工具并不都是为长时间运行的智能体设计的，但它们为面向回归的 harness 评估提供了积木。 评估还应与可观测性打通。生产轨迹可以转化为回归测试，评估失败也可以转化为可观测性信号。这样，监控“发生了什么”与构造“能复现并诊断这些问题的受控测试”之间，就形成了闭环。 #### 8.6.3 基于验证器与训练期的评估 一个较新的方向，是不再只把 evaluator 当作离线指标，而是把它们用作训练信号与优化目标。基于验证器的环境与类 RL 的智能体 gym，包括 R2E-Gym 与 verifiers，会把环境反馈作为奖励或验证信号，用于改进智能体策略与 scaffold（Jain et al., 2025; Prime Intellect, 2026）。这使评估从一个事后测量步骤，转变为智能体训练、测试时自适应与 scaffold 选择的主动组成部分。 Meta-Harness 则更进一步，把 harness 设计本身视为自动搜索对象（Lee et al., 2026）。在这个视角里，问题不再只是“在固定 harness 下哪个模型表现最好”，而是“哪种 harness 结构、提示词策略、工具接口或控制循环，能产生更可靠的智能体行为”。由此，评估不再是流水线的终点，而是使 harness 得以持续改进的信号。 ### 8.7 总结 ## 9 治理与安全（G） > **图 13：** 按本章安全类别组织的 LLM 智能体治理与安全代表性工作。 ![](/files/vZndRuWjZpHjW5eFFfel) 这一层关注的是：如何约束智能体行为、如何让其更安全，以及如何追究责任。如今，LLM 智能体会执行 shell 命令、发送邮件、提交代码、调用第三方 API；对于生产部署而言，一个核心问题是：它们应该在什么约束下行动，以及当这些约束失效时，由谁承担责任。在生产系统中，治理已经拥有自己的工具生态，包括权限引擎、策略语言、审计流水线与网关控制。这个生态不同于第 6 节与第 7 节中讨论的 Lifecycle Hooks 与可观测性基础设施，因此值得在 ETCLOVG 分类法中被视为独立层。我们围绕五种机制组织讨论：权限模型与身份管理（§9.1）、Lifecycle Hooks（§9.2）、组件加固（§9.3）、声明式宪章（§9.4）与审计基础设施（§9.5）。随后，我们把这些机制放回更广阔的智能体安全版图中定位（§9.6），并以若干开放研究方向收尾（§9.7）。 ### 9.1 权限模型与身份管理 任何智能体 harness 面对的第一个治理问题，都是访问控制：智能体可以触达哪些工具、文件、网络端点与系统资源？ 与传统 RBAC 或 ABAC 相比，智能体工作负载使这个问题更困难，因为所需工具集往往依赖一项部署时尚未知的自然语言任务。因此，相关文献沿着一个粒度轴展开：部署时固定的静态边界、按每次工具调用在运行时评估的上下文策略，以及跨越本地 harness 边界的交互权限。 **静态权限边界。** 生产级编码智能体通常预先定义一个权限范围，并对范围外操作要求升级授权。Codex（OpenAI, 2025）会在带有限制文件系统与网络访问的沙箱中运行 shell 命令，而 Gemini CLI（Mullen & Salva, 2025）则把工作区范围内的文件访问与命令 allow / deny 列表结合起来。这类边界容易检查，但无法表达任务特定意图。 要超越固定规则，就必须表达依赖每次工具调用运行时上下文的约束。 **依赖上下文的权限控制。** Progent（Shi et al., 2025a）引入了一种 DSL，其谓词可作用于工具名、参数与环境状态。运行时会在每次调用前评估这些谓词，从而使最小权限策略能够随角色、用户或会话而变化。Conseca（Tsai & Bagdasarian, 2025）进一步推进了这一思路：它从可信上下文中生成一条任务特定策略，再用一个独立的确定性检查器来执行。策略生成与策略执行的分离非常关键：生成组件可以适应任务，而执行器仍然保持可审计。 前述方法都作用于单一智能体边界之内。多智能体环境又会在访问控制与智能体身份两方面带来额外挑战。 **身份管理与智能体间访问控制。** 在授予访问之前，系统必须先建立“是谁在请求”。South et al.（2025）主张智能体需要经过认证的委托：一种在 OAuth 2.0 与 OpenID Connect 之上扩展的框架，加入 User ID Tokens、Agent ID Tokens 与带作用域的 Delegation Tokens，把用户意图绑定到智能体特定权限上。这条 token 链会从人类主体一路延伸到智能体动作，形成一条可验证的责任轨迹。SAGA（Syros et al., 2025）则把这一原则扩展到多智能体场景中，采用 provider 中介架构。智能体使用加密一次性密钥注册，而短时效访问令牌会强制执行用户定义的智能体联络策略。IsolateGPT（Wu et al., 2025）采取了一种架构性方案，使用 hub-and-spoke 模型：每个第三方应用都在隔离的 spoke 中运行，拥有各自的 LLM、记忆与工具访问。spoke 之间的通信必须经过可信 hub，因此跨应用数据交换会成为显式治理决策，而不是共享上下文窗口的偶然副作用。 **凭证管理。** 智能体会经常处理 API keys、会话令牌与一次性密码。把这些凭证暴露给 LLM 上下文，会带来外泄风险。Skyvern（Skyvern-AI, 2025）体现了一种常见模式：把 secret 存在 vault 中，只向 LLM 暴露占位符，然后只在真正执行认证动作的自动化层里替换成原始值。尚未解决的问题，则是长时程会话中的 secret 生命周期管理：当 token 在轨迹中途过期或被吊销时，新凭证应如何更新，同时仍然不进入模型上下文。 **Web 层权限协同。** 上述机制作用于单个 harness 的信任边界内部，并治理单一部署。跨组织交互——例如智能体访问第三方网站，或调用由其他主体拥有的服务——则需要单一 harness 无法独立强制的协调。Marro et al.（2025）提出了 `agent-permissions.json`：一种类似 `robots.txt` 的轻量 manifest 文件。网站所有者可以声明：智能体可以操作哪些 UI 元素、速率限制、并发约束，以及哪些动作需要人工确认。这类 manifest 并没有解决认证问题，但它展示了治理如何开始跨越组织边界。 **开放挑战。** 如何设计既有表达力又易用的权限模型，仍是未解问题。策略过于严格会损害智能体效用；过于宽松又会抵消治理本身的意义。社区还没有收敛出一种可跨 harness 实现移植的标准权限规格语言。关于动作究竟应归因于人类操作员、智能体实例，还是临时任务身份，也仍存在开放问题（South et al., 2025）。 ### 9.2 Lifecycle Hooks 权限模型定义的是“什么被允许”；Lifecycle Hooks 定义的是“何时触发策略检查”。许多 harness 会在智能体循环的每个阶段暴露 hook：规划前、工具调用前、工具执行后，以及响应交付前。这些 hooks 允许在不修改智能体核心推理逻辑的情况下，注入治理逻辑。图 14 把这四个 hook 放回了一次单一工具使用周期之中。 > **图 14：** 单次工具使用周期中的四个钩子点。实线框是智能体组件，虚线框是治理钩子。H1 在输入到达 LLM 之前验证输入；H2 在工具执行前验证拟议动作；H3 调解工具输出重新进入上下文时的信息流；H4 则对后果重大的动作施加用户审批门控。 ![](/files/NWC3ZXejQo7UNEsdKpsR) 输入 → LLM → 工具 → 响应 * H1：输入护栏（Input GR） * H2：动作护栏（Action GR） * H3：执行后信息流控制（Post-exec IFC） * H4：人在回路（Human-in-the-Loop） **执行前钩子：输入护栏。** 输入护栏会在数据到达 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）上换取了更强的控制流 / 数据流边界。 还有一种互补的执行机制，是把人类用户纳入回路之中。 **人在回路钩子。** 包括 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）则把焦点从单次动作分类转向轨迹级诊断，按来源、失效模式与后果组织风险。 **开放挑战。** 在当前系统中，hook API 仍然高度异构。我们尚未见到一种被广泛采用的标准，能够为第三方治理模块定义通用 hook 接口。钩子还会引入延迟，而多层堆叠钩子之间的交互效应也几乎没有被系统研究。一种可信的失效模式是：上游清洗器改变了下游检测器赖以判断的信号，最终使组合起来的流水线比单独使用任一组件时都更弱。 ### 9.3 组件加固 Lifecycle Hooks是在 harness 层面执行治理；组件加固则针对单个智能体组件——尤其是 LLM 本身及其调用的工具——的特定脆弱性进行强化。加固后的组件，会让更少恶意输入存活下来并触发治理钩子，因此 harness 也会从中受益。 **模型加固。** prompt injection 的一个根因，是 LLM 把所有输入文本都看作同等优先级，因此无法区分系统指令与不可信数据。Wallace et al.（2024）提出了一种指令层级（instruction hierarchy），训练模型让其优先遵从高权限指令（系统提示词），而不是低权限指令（用户消息、工具输出）。当低层指令与高层约束一致时，模型会学习去遵从；当二者冲突时，模型会学习忽略或拒绝。SecAlign（Chen et al., 2025a）则把同样的防御目标表述为一种偏好优化问题：在被 prompt injection 的输入、理想响应与不理想响应之间进行优化。 这些模型层防御与 harness 层钩子互为补充。更强健的模型会在推理时直接拒绝更多 injection，从而减轻下游护栏的负担。然而，单靠模型加固并不足够：它处理的是 Kim 等人分类法中的“错误指令跟随”问题，但无法防止无约束数据流或未授权动作；后两者需要系统层强制执行（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 扩展了带加密签名与版本控制的工具定义，确保对工具代码、schema 或权限的任何修改，都必须生成一个新的已签名版本。这能够防止一种“rug-pull”攻击：一个先前被批准的工具被悄悄更新，转而执行恶意动作。 **协议层加固。** 除了单独组件外，SAFEFLOW（Li et al., 2025）还为多智能体系统引入了协议层执行机制。它把细粒度信息流控制与事务式执行语义结合起来，使得违规工具调用或智能体间消息能够被回滚，而不会传播到共享状态中。 **供应链风险。** 智能体治理还必须处理智能体所调用的工具与软件包。Spracklen et al.（2025）分析了 16 个 LLM 的 57.6 万段代码样本，发现开源模型会以 21.7% 的比例幻觉出并不存在的软件包名。攻击者可以把这些被幻觉出来的名字注册到公共仓库上，并注入恶意代码；这种技术被称为“slopsquatting”。ETDI 的密码学签名只覆盖了 MCP 工具这一部分问题，而包管理器与检索源仍然处于多数智能体治理栈之外。 **开放挑战。** 模型加固与工具加固面对的是互补的威胁面，但目前还没有统一框架把它们连接起来。一个加固过的模型仍可能调用被攻陷的工具；一个签名工具定义，也无法阻止被 jailbreak 的模型对其进行滥用。如何把这些防御组合成一套具有可量化残余风险的连贯栈，仍是开放问题。随着 MCP 采用率上升，其安全扩展自然会成为标准化目标，但互操作性与认证机制目前仍高度不确定。 ### 9.4 声明式宪章 把治理逻辑直接嵌入应用代码，会使策略变得不透明、难以审计，也难以更新。越来越多的 harness 开始把治理规则外置为声明式配置文件，最常见的是 YAML 格式。这些文件充当了智能体的机器可读宪章。 **训练期宪章：Anthropic 的 Constitutional AI。** Anthropic（Anthropic, 2026a）发布了一套按四层优先级层级组织的宪章：安全（保留人类监督）、伦理（诚实、避免伤害）、合规（Anthropic 的指导原则）与有帮助性（满足用户请求）。这套宪章区分了硬约束——例如绝对禁止提供化学、生物、放射与核（CBRN）辅助——以及操作员可以在规定边界内调整的软编码默认值。在智能体场景中，这种结构暗示了一种主体层级：Anthropic 的政策优先于操作员配置，而操作员配置又优先于终端用户偏好。 训练期宪章通过在对齐与后训练阶段塑造模型行为来发挥作用。它们在训练时影响模型行为，但部署后难以修改，也无法被 harness 独立审计。与之不同的一条路径，则是把治理规则外置为部署时配置，让 harness 能够读取、验证并执行。 **部署期宪章：基于 YAML 的治理。** AutoHarness 仓库（AIMing Lab, 2026）把治理规则编码进一个 YAML 文件，其中指定了流水线模式（core、standard 或 enhanced）、风险分类模式、允许与拒绝的工具模式、token 预算上限，以及审计日志目标位置。这种声明式风格把治理意图与执行逻辑分离开来。安全团队与合规官等非开发者利益相关者，可以在不触碰智能体代码的情况下审查并修改策略。与训练期宪章不同，YAML 文件可以用标准工具更新、版本化与 diff 审查，因此无需重新训练或重新部署模型，也能完成策略更新。 这两层在运维上有明显区别。训练期宪章修改成本高，而且往往只能通过行为探测去反推；部署期 YAML 则可被直接读取、直接 diff 审查。训练期对齐以概率方式塑造默认行为，也可能被对抗性提示词覆盖（Andriushchenko et al., 2024）；部署期规则则以 harness 检查的形式直接执行。 当策略可以归结为字面触发器时，基于模式的 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。每个 harness 往往都定义自己的 YAML 结构，导致策略缺乏可移植性。用于验证一份宪章是否内部一致（例如不存在互相矛盾的 allow / deny 规则）且足够完备（例如没有未处理的工具类别）的工具，在当前生态中仍然有限。训练期与部署期宪章之间的相互作用尤其缺乏研究。一个 YAML deny 规则是否能够可靠地覆盖 RLHF 已强化出的行为、以及两层在何种条件下会发生冲突，仍然是带有实际安全影响的开放问题。 ### 9.5 审计基础设施 治理要求可追责性。审计基础设施记录智能体做了什么、为什么这么做，以及治理策略是否得到了遵守。这些记录支撑事后调查、监管合规与持续策略改进。 **结构化审计轨迹。** AutoHarness（AIMing Lab, 2026）会为每次工具调用输出 JSONL 记录，其中包括工具名、参数、风险分类、权限决策、执行结果、token 成本与墙钟延迟。这类结构化日志既支持实时仪表盘，也支持离线取证分析。SAGA（Syros et al., 2025）则把审计轨迹扩展到多智能体交互，通过记录智能体之间交换的加密 token，使跨信任边界的来源追踪成为可能。综合这些系统，一条可回放的审计记录至少应当包含：轨迹标识符、主体身份、工具调用、策略决策及其版本、执行结果、资源成本，以及与相关输入输出对应的完整性哈希。当前大多数系统只记录了其中一部分字段，而且很少会对记录做签名或哈希，这使得在智能体进程被攻陷后，审计轨迹容易遭到日志篡改。 除了记录本身，要在长时间运行的智能体中检测治理违规，还需要自动化分析。 **异常检测：逐动作与轨迹级。** 检测机制会沿着评估证据的粒度分化。**逐动作检测器**会把每次工具调用单独拿出来，依据某种学习得来或人工规定的风险概念进行分类：输入与输出护栏（§9.2）就属于这一范式，AgentMonitor（Naihin et al., 2023）则提供了一个轻量级的“记录并标记”实现。这一范式便宜、易审计，但无法识别那种分散在多个单步良性动作中的攻击，例如每分钟只读取一个文件的慢速外泄。**轨迹级检测器**则会联合评估动作序列。AgentAuditor（Luo et al., 2025）把行为模式匹配与基于 LLM 的整条轨迹推理结合起来。SentinelAgent（He et al., 2025）把多智能体通信建模为时序图，并标记异常交互模式。轨迹级检测能抓住多步攻击，但代价是更高延迟，以及更难本地化“到底是哪一个动作触发了警报”，从而同时增加实时干预与事后解释的复杂度。在本文调研的系统里，逐动作检查通常以内联方式部署，而轨迹级分析则异步地运行在审计日志之上。 除了安全本身，长时间运行的智能体还需要成本与资源治理。 **成本与资源审计。** 在大量循环的工作负载中，一个失控的智能体循环会很快耗尽 API 预算。2025 年版《OWASP Top 10 for LLMs》（OWASP Foundation, 2025）已经把资源耗尽单列为一种风险类别。AutoHarness（AIMing Lab, 2026）会跟踪每次调用的 token 消耗，并通过其宪章以声明式方式执行会话级预算。在多智能体架构中，成本感知治理尤其重要，因为扇出模式可能让 API 调用数呈指数增长。 **分层治理流水线。** 一个正在出现的设计模式，是把前述机制（权限、钩子、宪章与审计）整合进一条可配置的统一流水线。AutoHarness（AIMing Lab, 2026）就是这种模式的代表，其包含三个层级。这些层级逐步增加更深的检查：从“解析—风险—权限—执行—审计”循环，一路增加上下文增强、输出验证、异常评分、人工升级与形式化约束验证。层级通过 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）进一步表明，智能体安全并不局限于 prompt injection 或单智能体 jailbreak：社会工程、协同智能体集群、凭证泄露与平台级参与度放大，都会共同塑造威胁版图。Kim et al.（2026）调研了 128 篇论文，并在智能体栈上编目出 51 种攻击方法与 60 种防御方法。Chen et al.（2026）则从软件工程视角做了补充：他们通过一个六维分类法综合了 50 篇论文，并提出了面向“安全即构造（secure-by-construction）”智能体平台的参考教义。我们借助这些框架，把治理机制与具体安全风险连接起来，并识别覆盖缺口。 **从设计维度到治理机制。** Kim et al. 提出了七个设计维度（Input Trust、Access Sensitivity、Workflow、Action、Memory、Tool、User Interface），每一个都代表着一种灵活性光谱。灵活性越大，攻击面越大；而治理的作用，就是在运行时约束这种灵活性。权限模型约束工具与动作；Lifecycle Hooks在工作流中注入检查点；宪章把约束外置化；审计基础设施则提供反馈回路，揭示约束究竟是过松还是过紧。表 3 把治理机制映射到 Kim et al. 分类法中的七类风险（R1–R7）。 **表 3：** 治理机制与 Kim et al.（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 et al. 针对六个智能体系统（Codex、Gemini CLI、OpenHands、Browser Use、Nanobrowser、Skyvern）的案例研究显示，没有任何一个智能体完整实现了全部防御类别。信息流控制、身份管理与形式化验证，在所有被调研系统中都缺席。六个案例中，监控都只有部分覆盖：智能体会记录工具调用，但缺少自动异常检测。AutoGPT 的案例研究则表明了后果：下游补丁也许可以修补个别症状，但上游输入验证、信息流控制与策略组合依然没有被充分规定。 **纵深防御及其局限。** Kim et al. 认为，智能体安全需要相互补充的分层防御：输入护栏作为第一道防线，输出护栏作为最后一道防线，信息流控制与监控作为持续性的运行时防护，访问控制承担认证与授权，而人在回路负责关键决策。然而，分层并非没有代价；正如 §9.2 所讨论的那样，协调不佳的多层机制可能相互干扰，而独立治理钩子的可组合性几乎还没有经过系统检验。在这个框架下，治理可以充当编排层，使不同防御机制彼此协作，而不是彼此冲突。 **作为拟议扩展的情境性安全。** Kim et al.（2026）提出了“情境性安全（contextual security）”，将其作为智能体系统中继经典 CIA 三元组（机密性、完整性、可用性）之后的候选第四安全目标。这个提法较新，而且只出现在他们的调研中；它尚未被 NIST 等标准机构或主流安全教材采纳。我们在这里将其视为一种有启发性的框架，而非既定定义。Conseca（Tsai & Bagdasarian, 2025）与 CaMeL（Debenedetti et al., 2025）都说明了一条工程方向：上下文必须被视为受治理的状态，而不是被动的提示词材料。它是否足以被提升为独立安全目标，仍未尘埃落定。 ### 9.7 研究方向 表 4 总结了本节所讨论系统中的治理现状。 **表 4：** 治理特性覆盖情况。= 完全支持，= 部分支持，= 缺失。 > 说明：输入源文件中，表 4 的支持度符号以及部分系统行在文本抽取时发生了编码损坏，无法无歧义地还原为标准 Markdown 表格。以下保留原表题注与后续分析结论，并按源文本可辨识内容转写关键信息。 * 表头可辨识为：System / Perm. / Hooks / Harden. / Constit. / Audit / Multi-Ag. * 可辨识系统包括：Codex、Gemini CLI、OpenHands、AutoHarness、Progent、CaMeL、SAGA、IsolateGPT、AgentSpec、SAFEFLOW。 * 原表呈现出的总体结论是：治理能力覆盖度整体稀疏，且不同系统在权限、钩子、组件加固、宪章、审计与多智能体治理上的支持程度明显不均衡。 表 4 中可见的这种稀疏性表明：与模型能力限制并列，治理基础设施本身往往也是安全部署的现实瓶颈。我们在此识别出八个开放研究方向；这里仅限于治理特定缺口，并与 §12 中更广泛的开放问题互相参照。 1. **标准化的策略与审计语言。** 每个 harness 都定义自己的 YAML schema 与私有 DSL，导致治理生态割裂。一个社区驱动的规范——类似 MCP（Anthropic, 2024c）对工具接口所追求的那种规范——将使可移植策略、可组合治理模块以及跨 harness 审计互操作成为可能。 2. **形式化治理保证。** 当前治理机制在形式化保证方面仍十分有限。对智能体行为的形式化验证本身还处于早期阶段（Li et al., 2024; Chen et al., 2025b; Lee et al., 2025）。将这些技术扩展到验证治理流水线的正确性，例如证明一份宪章在内部一致且覆盖了所有工具类别，仍然缺乏研究。 3. **自适应治理。** 静态策略无法预见每一种任务上下文。Conseca（Tsai & Bagdasarian, 2025）表明，LLM 生成的策略可以弥补这一缺口。机器生成治理规则的可信度，以及这些策略生成器本身又应当如何被治理，仍然是开放问题。 > **译者注：** 输入源文件在此处结束，因此 §9.7 的后续条目未出现在本次可翻译材料中。 ## 10 跨领域关注点 本节汇总的关注点横跨多个 ETCLOVG 层，并通过展示分层推理在哪些地方失效来展开主张 1（即“agent harness 是一个独立系统层”，见 §1）。前面的分层章节分别隔离了执行、工具、上下文、生命周期、可观测性、评估与治理，从而可以精确描述每个设计界面。然而，在生产环境中，harness 最常失效的地方，恰恰是这些界面之间的交叉处。 **层间交互模式。** 七个层并非彼此独立。执行环境（E）会限制哪些生命周期与编排策略（L）在实践中可行；上下文管理（C）会影响评估（V）的可复现性；治理（G）则施加跨越其余所有层的身份、权限与审计约束。因此，对 harness 设计的理解不应把它当作一张可拆分组件清单，而应把它视为一种依赖结构。 **成本–质量–速度三难困境。** 更强的评估（V）、更严格的治理（G）、更丰富的可观测性（O）以及更逼真的执行环境（E），通常都会提高成本与延迟。为速度做优化往往会削弱诊断深度或安全裕度；为质量做优化又可能让日常迭代成本过高。真实系统必须决定：哪些检查要同步执行，哪些应离线运行，以及哪些失败值得触发高成本恢复路径。 **标准化与生态系统动态。** MCP、ACP 和 A2A 等协议反映出一种朝向共享接口的压力，即为工具、agent 与编排状态建立通用接口。这种压力有利于构建与具体 agent 无关的基础设施，而不是单 agent 集成；但它也把责任转移到了治理与可观测性层：一个标准化的工具调用，只有在周边 harness 能跨系统保留来源、权限、成本与失败证据时，才真正有用。 **持续存在的生态缺口。** 在整个语料中，五类缺口反复出现在层边界处：跨工具互操作性、成本归因、失败恢复、多仓库编排，以及人类—agent 交接。这些缺口构成了 §11 综合分析的动机：核心问题已不再是每一层是否“都有可用工具”，而是组合后的 harness 能否表现得像一个可靠的控制系统。 ## 11 跨层综合分析 本节把 §10 的跨领域关注点收束为五种系统级效应，是主张 1（§1）的核心支撑。目的在于把讨论从“组件覆盖”转向“harness 行为”：一旦把执行、工具、上下文、编排、可观测性、评估与治理组合起来，它们之间的相互作用就会形成任何单层都无法独立解决的约束。 ### 11.1 成本–质量–速度三难困境 Harness 的可靠性受到成本、质量与速度三者之间权衡的约束。更强的沙箱和更逼真的环境会提升安全性与可复现性，但也会增加启动延迟与基础设施成本；更丰富的上下文与记忆策略能够提升任务连续性，但会消耗 token 并带来检索开销；更深入的评估与可观测性有助于诊断，却会减慢迭代速度，并增加存储、标注和 Trace 处理成本。因此，生产系统不能把质量当作单一标量目标。它们必须决定：哪些风险值得付出高成本控制，哪些检查可以异步执行或放进回归测试套件，以及在 agent 生命周期的各个阶段，哪些遥测数据值得采集。 ### 11.2 能力–控制权衡 能力更强的 harness 会向 agent 暴露更大的权力，但每一次权力提升都会扩大控制问题。更大的工具菜单能拓宽任务覆盖面，却也会增加选择错误与 prompt injection 的攻击面；持久化记忆有助于长时间运行的任务，但会引入来源、陈旧性与隐私风险；更宽松的沙箱使自主执行更有价值，同时也放大了未对齐或被攻陷操作的波及范围。因此，能力–控制权衡并不是附加在一个原本已经可用系统之上的安全“外挂”。它本身就是一条设计轴线，把工具 schema、上下文策略、运行时权限、身份、可审计性与人工审批连接在一起。 ### 11.3 Harness 耦合问题 Harness 各层之间存在耦合，使得局部优化变得脆弱。执行环境会通过影响包可用性、重置语义、延迟与失败模式来改变评估结果；工具描述会消耗上下文预算，并塑造模型行为；只有在以同等粒度记录身份与权限状态时，可观测性 Trace 才能成为治理证据；而评估设计又会反过来影响编排，因为它会奖励某些恢复循环、惩罚另一些恢复循环。这些耦合意味着：对 harness 的变更应按“系统变更”来测试。一个 prompt、工具、memory、sandbox、verifier 或 monitor，孤立看可能有益，但与控制回路其余部分组合后，反而可能削弱整体 Rollout。耦合问题也解释了：如果不说明周边控制器，就无法把 agent 分数干净地归因于模型本身。在闭环框架下，对上下文策略、工具 schema、verifier 或恢复循环的改变，会改变控制器 C，从而改变同一模型的测量行为（Bölük, 2026b）。 ### 11.4 从 Agent Frameworks 走向 Agent Platforms 生态系统正在从 Agent Framework 走向 Agent Platform。Framework 打包的是本地抽象，例如 agent、工具、memory store 和执行循环；Platform 则进一步提供跨多次运行、面向多用户的持久化工作空间、托管沙箱、身份、计费、可观测性、评估、治理以及人工交接。这一转变之所以重要，是因为长时运行的 agent 不再只是“会调用模型的程序”。它们是需要租户管理、合规、故障恢复、Trace 保留和组织归属的运营系统。因此，核心设计问题也从“我该如何构建一个 agent？”转变为“我该如何运营一整队 agent，并让它们的行为在时间尺度上始终可检查、可逆转？” ### 11.5 开放研究议程 上述跨层综合分析指向一个以 harness 作为自适应控制系统为中心的研究议程。这个领域需要：能够改变 harness 干预项而不只是改变模型权重的基准；能够跨层归因失败的 Trace 原生方法；能够在 agent、工具、沙箱、评估器与人类之间转移状态与责任的协议；以及随着模型能力提升而简化 harness 的优化方法。下一节将把这些跨层效应具体化为五个开放问题：如何加固并扩展执行环境、如何维持可靠状态、如何从 Trace 中诊断失败、如何标准化交接，以及在模型能力变化时如何让 harness 持续保持有用。 ## 12 开放问题与未来方向 这里汇总的开放问题，源自主导约束命题与跨层综合分析，也是主张 1（§1）面向未来的证据部分。本节不再把七个 ETCLOVG 层视为彼此独立的组件清单，而是追问：整个 harness 在哪些地方仍缺乏足够清晰的科学刻画。核心模式是，agent harness 正在变成长时运行的控制系统，但这个领域仍然缺少成熟答案，来应对执行基底的加固、状态保持、失败诊断、责任转移，以及随着模型能力变化而更新 harness 的问题。我们把这些缺口组织为五个横跨该分类法的问题。 ### 12.1 加固并扩展执行环境 执行环境正变成安全性、可扩展性与可移植性交汇的控制边界。SandboxEscapeBench 表明，前沿模型能够在现实配置下利用沙箱弱点（Marchand et al., 2026），但防御研究仍然分散在采用不同威胁模型与评估协议的系统之中（Wu et al., 2025; Yan, 2025）。与此同时，“每个任务一个容器”的模式在大规模训练与评估中面临压力：当需要并行运行数以万计的轨迹时，系统需要廉价的重置与回放；SWE-World 指向了无需 Docker 的代理环境，但其学习到的状态转移相对真实执行的保真度仍未解决（Sun et al., 2026）。即便是部署可移植性，也不是一个已经彻底解决的工程细节：基于 Docker 的沙箱继承了 Linux 内核假设，而 macOS、Windows、浏览器、桌面与混合云场景，则暴露出不同的隔离与可复现性约束。 开放问题在于，如何让运行时基底同时“可度量”且“可组合”。未来的 harness 需要：面向 prompt injection、目标错配与组合放大的通用安全评估；能够决定何时使用容器、microVM、操作系统级权限边界、完整桌面虚拟机、浏览器环境或学习型代理环境的成本模型；以及能在自托管、云端与混合部署之间保持语义一致的可移植层。将运行时“打包”进 framework（§3.2.4）还是“组合”独立沙箱抽象（§3.2.7），应被视为一个经验性的设计问题，而不是产品偏好。MCP 等标准也许能降低组合成本，但前提是工具、治理与可观测性层暴露出足够多的状态，使运行时选择保持可审计、可恢复且安全。 ### 12.2 在长时运行 Agent 中维持可靠状态 最深层的上下文问题，不只是如何把更多 token 塞进 prompt，而是如何在长时间范围内让 agent 的工作状态与真实任务状态保持一致。长时运行的编码、研究与运维 agent 会反复对信息进行摘要、检索、压缩与外化；每一次这样的操作，都可能删除约束、扭曲优先级，或保留陈旧假设。近期的 Context Engineering 工作把压缩、清除工具结果、检索，以及考虑 prompt cache 的排序，当作管理有限上下文窗口的实用机制（Anthropic Applied AI Team, 2025; Anthropic, 2025c; OpenAI, 2026b）。然而，context rot 与 memory 基准表明，更长的输入和更丰富的 memory store，并不自动意味着更好的任务状态跟踪（Hong et al., 2025; Tan et al., 2025; He et al., 2026）。 因此，一个更有原则的研究议程，应把上下文管理重新表述为状态估计问题。开放问题是：我们能否刻画在每一次压缩、检索或遗忘步骤中丢失了多少与任务相关的信息，并且能否为 agent 内部状态与任务真实状态之间的偏离建立上界。近期综述将 agent memory 形式化为“写入—管理—读取”循环，并指出由策略学习得到的管理机制正在成为一个新兴机制家族（Zhang et al., 2025; Du, 2026）。未来系统需要具备：具不确定性感知的摘要、被记住事实的来源信息、矛盾处理机制、显式的新鲜度/陈旧度标记，以及恢复程序，使 agent 能从持久化工件中重建缺失状态，而不是盲目信任其自身压缩后的历史。这也意味着 memory 与 evaluation 之间应建立更紧密的联系：memory 策略的评价标准，不应只看召回准确率，还应看它们是否能够阻止多会话任务中的下游行动错误。 ### 12.3 从 Agent Trace 中诊断失败 Agent 评估至今仍过于以最终分数为中心：一次运行通过或失败，最终数字就被当作模型质量的证据。对于 Harness Engineering 而言，这远远不够，因为一次失败的 Rollout 可能源自模型推理、误导性的工具 schema、沙箱配置错误、陈旧上下文、脆弱测试、基准歧义、评判器不稳定，或编排循环。Anthropic 对 agentic coding 评估的分析显示，基础设施设置能够显著改变基准分数（Anthropic, 2026a）；近期关于 agentic eval 随机性的研究则指出，单次运行的通过率可能掩盖大量方差（Bjarnason et al., 2026）。因此，评估层必须被当作一种测量仪器来研究，而不能只把它当作排行榜生成器。 下一步应是以 Trace 为原生对象的评估：Trace 应成为系统计算结果分数、轨迹质量、失败归因与回归测试的主要对象。可观测性系统已经能够捕获 span、工具调用、成本、重试、异常与中间消息（OpenTelemetry, 2026; AlSayyad et al., 2026; Koc et al., 2025），但这些 Trace 往往与评估流水线脱节。LangChain 在 2026 年的调查报告称，89% 的团队使用可观测性，而只有 52.4% 运行离线评估（LangChain, 2026a）；这一差距意味着，团队可以“看见” agent 做了什么，却没有系统性判断这些行为是否正确。未来工作应闭合这个回路：把生产环境中的异常 Trace 转换为回归用例，直接在 span 上计算轨迹指标，并把诊断信号回灌到 prompt、工具、上下文与编排的变更之中。Reflexion 已经表明，在短时任务设定下，agent 可以从自己的 Trace 中学习（Shinn et al., 2023）；如何把这一思想扩展到长时、跨多会话的 harness，仍是开放问题。 ### 12.4 在 Agents、工具与人类之间建立标准交接 现代 harness 越来越多地把工作分发给规划器、subagent、工具、沙箱、评估器和人类，但这些参与者之间的接口仍然非常临时化。局部标准已经出现：MCP 标准化了工具访问，A2A 面向 agent 间通信，而 OpenTelemetry 提供了通用的 Trace 基底（Model Context Protocol, 2025b; A2A Project, 2025; OpenTelemetry, 2026; Ehtesham et al., 2025）。缺失的是一种跨层交接契约。当规划器把工作交给执行器、agent 调用工具、subagent 归还控制权，或系统把任务升级给人类时，交接中传递的不应只是文本摘要，还应包括意图、约束、权限、工件、来源、预算状态、风险等级、Trace 历史以及尚未解决的决策。 这个问题一部分是技术性的，另一部分是制度性的。OpenAI 的 Symphony 把 issue tracker 和仓库视为 agent 工作的控制平面，而 Anthropic 的长时运行 agent harness 则强调持久化进度工件与干净的交接状态（Kotliarskyi et al., 2026; Anthropic, 2025d; 2026b）。治理研究从相反方向得出相同结论：在 agent 能够安全地跨系统代表用户行动之前，必须具备 agent 身份、委托、权限清单与可审计性（South et al., 2025; Marro et al., 2025; Syros et al., 2025）。开放问题在于，如何定义既足够丰富、能支持安全与恢复，又足够简单、能被广泛采用的交接协议。这类协议应使责任显式化：是谁授权了该操作、转移了哪些状态、当前计划由哪些证据支持、接收方被允许做什么，以及控制权何时必须返回给另一名 agent 或人类。 ### 12.5 随模型进步而保持 Harness 的有效性 不应默认 harness 设计会单调地走向“加更多脚手架”。每一层 wrapper、reset、verifier、planner、memory 规则与权限闸门，都编码了一种关于“模型本身无法可靠完成什么”的假设。随着模型能力变化，harness 干预项也应重新估计，而不是想当然地认为它们始终有益。按“模型 × harness”做析因评估，可以揭示某项干预是对所有模型都有帮助、只帮助特定模型家族，还是会反转模型排名（Bölük, 2026b）。Anthropic 在长时运行应用开发中报告了这一模式的一个具体版本：对某个模型有用的上下文重置，对更强模型变得不再必要，而移除这些重置可以在不降低质量的前提下降低成本（Anthropic, 2026c）。OpenAI 同样把 Harness Engineering 描述为一种“保持人类注意力、仓库状态与 agent 执行对齐”的学科，而不只是不断叠加更多脚手架（OpenAI, 2026a; 2026b）。 这又引出一个元工程议程：harness 需要具备优化并简化自身的机制。Meta-Harness 表明，prompt、工具与控制回路可以成为搜索优化目标的一部分，而不是固定由人工指定（Lee et al., 2026）；Natural-Language Agent Harnesses 则让 harness 模块显式化、可消融（Pan et al., 2026）。诸如 TensorZero、Axon 与 AgentOps 这样的生产级可观测性与成本系统，展示了预算感知 harness 运营的方向（TensorZero, 2026; harshkedia177, 2026; AgentOps AI, 2026），但研究问题并不只是成本最小化。未来系统应能识别哪些干预在因果上对质量、安全或可靠性负责；在不同 harness 变体之间运行影子模式或 A/B 测试；并在质量—延迟—成本—风险的联合约束下进行优化。一个核心风险是基准过拟合：如果 harness 只对一组狭窄基准做自我优化，它可能会变得脆弱。更持久的目标是“自适应简化”：让 harness 持续追问，在任务、工具与模型能力变化时，哪些控制仍然是必要的。 ## 13 结论 本综述将 agent harness 视为一个独立的工程界面，并主张：决定真实世界 agent 可靠性上限的，不只是模型能力，更是基础设施质量。围绕这一主导约束命题，我们提出了三项主张。七层 ETCLOVG 分类法把可观测性（Observability）与治理（Governance）从 Lifecycle Hooks 中分离出来，并反映了生产团队现实中组织工具与职责归属的方式。我们把 148+ 个开源项目映射到该分类法上，形成了迄今最广泛的生态系统快照，并由此揭示出采纳模式、覆盖缺口与正在浮现的设计原则。从 Prompt Engineering 到 Context Engineering，再到 Harness Engineering 的三阶段工程演化，再结合对成本–质量–速度三难困境、能力–控制权衡以及 harness 耦合问题的跨层综合分析，本文把 harness 放入了一条更广阔的工程演进轨迹之中。 当然，我们的分析也存在局限。语料偏向英文、GitHub 可见的开源项目，并且偏向编码 agent 生态；如果能扩展到闭源生产系统以及非编码型 agent 生态，经验图景会更完整。该分类法本身也是描述性的：下一步自然工作，是把 ETCLOVG 从“仅用于分类”的框架，发展为能够真正指导 harness 设计决策的规范性框架。我们希望这篇综述能推动这一进展。 ## 附录 A：完整生态系统映射 表 S1 给出了本综述使用的技术生态系统映射。该目录快照于 2026-05-08 完成核验，共包含 171 个公开条目、146 个 GitHub 条目、142 个位于项目类别中的 GitHub 条目，以及 0 个失效 URL。对于论文附录，我们只保留技术工件以及七个 ETCLOVG 层：纯阅读材料、生态地图、通用列表仓库，以及仅提供教程或手册的资源均被省略。此前单列为 reference harness implementations 的条目，依据目录标签与摘要并入其主导 ETCLOVG 层；标签与星标快照均直接复制自核验后的快照。附录 B 将进一步展开六个焦点实现。 **表 S1：** 经筛选的技术生态目录；每个工件只映射到一个主 ETCLOVG 层。 ### E — 执行与沙箱（20 项；主层：E） * `Daytona` — 目录标签：`sandbox, execution, infra`；星标：72.4k * `NanoClaw` — 目录标签：`containers, claude-sdk, scheduling`；星标：28.6k * `cmux` — 目录标签：`macos, workspace, browser`；星标：16.3k * `CUA` — 目录标签：`computer-use, sandbox, infra`；星标：15.7k * `E2B` — 目录标签：`cloud-sandbox, execution, enterprise`；星标：12.1k * `BrowserHarness` — 目录标签：`browser, cdp, self-healing`；星标：11.0k * `OpenSandbox` — 目录标签：`sandbox, security, runtime`；星标：10.5k * `agent-infrasandbox` — 目录标签：`all-in-one, browser, shell`；星标：4.5k * `Judge0` — 目录标签：`code-execution, sandbox, backend`；星标：4.2k * `AgentSandbox` — 目录标签：`kubernetes, sandbox, stateful`；星标：2.1k * `stakpak/agent` — 目录标签：`always-on, autonomous, ops`；星标：1.5k * `OSS-FuzzGen` — 目录标签：`fuzzing, security, execution`；星标：1.4k * `E2BDesktopSandbox` — 目录标签：`desktop, sandbox, computer-use`；星标：1.4k * `Tensorlake` — 目录标签：`microvm, sandbox, orchestration`；星标：911 * `Arrakis` — 目录标签：`sandbox, microvm, snapshots`；星标：808 * `AgentScopeRuntime` — 目录标签：`runtime, sandbox, deployment`；星标：766 * `SWE-ReX` — 目录标签：`sandbox, execution, coding-agent`；星标：490 * `sandboxed.sh` — 目录标签：`self-hosted, isolation, orchestrator`；星标：416 * `Capsule` — 目录标签：`wasm, sandbox, task-runtime`；星标：281 * `terminal-bench-env` — 目录标签：`terminal, benchmark-env, sandbox`；星标：80 ### T — 协议、工具接口与 Agent 契约（12 项；主层：T） * `GitHubSpecKit` — 目录标签：`spec-driven, workflows, tooling`；星标：92.9k * `MCPServers` — 目录标签：`mcp, servers, implementations`；星标：85.1k * `CLI-Anything` — 目录标签：`cli, tool-use, automation`；星标：33.7k * `AGENTS.md` — 目录标签：`spec, agent-file, instructions`；星标：21.0k * `ModelContextProtocol` — 目录标签：`mcp, protocol, interoperability`；星标：8.0k * `directories (rules and MCP indexes)` — 目录标签：`directories, mcp, rules`；星标：3.9k * `LangChainMCPAdapters` — 目录标签：`mcp, adapters, integration`；星标：3.5k * `MicrosoftMCPServers` — 目录标签：`mcp, enterprise, servers`；星标：3.1k * `ACPX` — 目录标签：`acp, client, sessions`；星标：2.6k * `MicrosoftLearnMCP` — 目录标签：`mcp, docs, grounding`；星标：1.6k * `IBMMCP` — 目录标签：`mcp, clients, tooling`；星标：374 * `AGENT.md` — 目录标签：`standard, agent-file, interoperability`；星标：77 ### C — 上下文与工作状态工程（9 项；主层：C） * `claude-mem` — 目录标签：`memory, context, session`；星标：72.8k * `SuperClaudeFramework` — 目录标签：`config, personas, workflow`；星标：22.6k * `planning-with-files` — 目录标签：`planning, skills, persistence`；星标：20.5k * `Agent Skills for Context Engineering` — 目录标签：`skills, context, production`；星标：15.5k * `CCPM` — 目录标签：`planning, github-issues, parallel-execution`；星标：8.1k * `Trellis` — 目录标签：`specs, memory, workflow`；星标：7.2k * `OSAURUS` — 目录标签：`macos, local-first, memory`；星标：5.2k * `holaOS` — 目录标签：`long-horizon, desktop, durable-state`；星标：4.9k * `context-space` — 目录标签：`context, infrastructure, mcp`；星标：809 ### L — Harness 架构与编排（47 项；主层：L） * `OpenCode` — 目录标签：`terminal, coding-agent, subagents`；星标：155.8k * `ClaudeCode` — 目录标签：`terminal, coding-agent, git-workflows`；星标：120.9k * `GeminiCLI` — 目录标签：`terminal, coding-agent, mcp`；星标：103.3k * `CodexCLI` — 目录标签：`terminal, coding-agent, local-execution`；星标：80.4k * `OpenHands` — 目录标签：`coding-agent, software-engineering, repo`；星标：72.7k * `DeerFlow` — 目录标签：`long-horizon, memory, subagents`；星标：65.4k * `AutoGen` — 目录标签：`multi-agent, orchestration, framework`；星标：57.8k * `OpenManus` — 目录标签：`general-agent, autonomy, workflows`；星标：56.0k * `pi` — 目录标签：`coding-agent, runtime, monorepo`；星标：46.5k * `aider` — 目录标签：`terminal, repo-map, testing`；星标：44.4k * `Agno` — 目录标签：`scale, runtime, management`；星标：39.9k * `Claude Code Plugins: Orchestration and Automation` — 目录标签：`claude-code, plugins, orchestration`；星标：34.9k * `LangGraph` — 目录标签：`graph, workflow, runtime`；星标：31.3k * `SemanticKernel` — 目录标签：`enterprise, orchestration, plugins`；星标：27.8k * `OpenAI Agents SDK (Python)` — 目录标签：`sdk, handoff, workflows`；星标：25.9k * `QwenCode` — 目录标签：`terminal, coding-agent, cli`；星标：24.2k * `deepagents` — 目录标签：`runtime, orchestration, long-running`；星标：22.3k * `Archon` — 目录标签：`workflow-engine, worktrees, validation`；星标：20.9k * `Devika` — 目录标签：`assistant, planning, coding`；星标：19.5k * `Google ADK (Python)` — 目录标签：`toolkit, deployment, evaluation`；星标：19.5k * `SWE-agent` — 目录标签：`swe, issue-fixing, tooling`；星标：19.1k * `PydanticAI` — 目录标签：`python, typing, schema`；星标：16.9k * `Aperant` — 目录标签：`coding-agent, parallel, memory`；星标：14.2k * `Eigent` — 目录标签：`desktop, cowork, productivity`；星标：13.9k * `OpenHarness` — 目录标签：`tool-use, memory, multi-agent`；星标：12.0k * `Superset` — 目录标签：`worktrees, desktop, parallel`；星标：10.4k * `GitHubCopilotCLI` — 目录标签：`terminal, coding-agent, mcp`；星标：10.4k * `Hive` — 目录标签：`harness, orchestration, runtime`；星标：10.2k * `MicrosoftAgentFramework` — 目录标签：`multi-agent, workflows, observability`；星标：10.2k * `OpenSWE` — 目录标签：`async, coding-agent, swe`；星标：9.7k * `VoltAgent` — 目录标签：`typescript, platform, runtime`；星标：8.7k * `mcp-agent` — 目录标签：`mcp, runtime, workflow`；星标：8.3k * `Yao` — 目录标签：`single-binary, runtime, autonomous`；星标：7.5k * `Paseo` — 目录标签：`coding-agent, daemon, multi-device`；星标：5.5k * `1Code` — 目录标签：`coding-agent, orchestration, worktrees`；星标：5.5k * `CloudflareAgents` — 目录标签：`platform, deployment, runtime`；星标：4.9k * `HiClaw` — 目录标签：`multi-agent, human-in-the-loop, shared-state`；星标：4.4k * `mini-swe-agent` — 目录标签：`minimal, swe, coding-agent`；星标：4.2k * `oh-my-pi` — 目录标签：`terminal, lsp, subagents`；星标：4.0k * `TinyAGI` — 目录标签：`team-orchestration, autonomous, workflows`；星标：3.6k * `Devon` — 目录标签：`pair-programming, coding-agent, autonomous`；星标：3.4k * `OpenClaudeCowork` — 目录标签：`desktop, ui, orchestration`；星标：3.3k * `DockerAgent` — 目录标签：`docker, runtime, container`；星标：2.9k * `NeMoAgentToolkit` — 目录标签：`multi-agent, optimization, toolkit`；星标：2.3k * `Scion` — 目录标签：`multi-agent, containers, orchestration`；星标：1.4k * `deepagentsjs` — 目录标签：`typescript, langgraph, subagents`；星标：1.2k * `hankweave` — 目录标签：`long-horizon, runtime, checkpoints`；星标：120 ### O — 可观测性与可靠性运营（15 项；主层：O） * `Langfuse` — 目录标签：`llmops, tracing, metrics`；星标：26.7k * `MLflow` — 目录标签：`platform, monitoring, evaluation`；星标：25.8k * `Opik` — 目录标签：`monitoring, eval, tracing`；星标：19.2k * `RagaAICatalyst` — 目录标签：`agentops, analytics, monitoring`；星标：16.2k * `TensorZero` — 目录标签：`llmops, gateway, optimization`；星标：11.3k * `ArizePhoenix` — 目录标签：`observability, tracing, evaluation`；星标：9.5k * `OpenLLMetry` — 目录标签：`opentelemetry, instrumentation, tracing`；星标：7.1k * `Helicone` — 目录标签：`monitoring, traffic, production`；星标：5.6k * `AgentOpsSDK` — 目录标签：`agentops, monitoring, cost`；星标：5.5k * `Latitude` — 目录标签：`platform, eval, observability`；星标：4.0k * `Laminar` — 目录标签：`observability, tracing, evals`；星标：2.8k * `AmazonBedrockAgentCoreSamples` — 目录标签：`aws, runtime, operations`；星标：2.8k * `claude-code-reverse` — 目录标签：`trace, visualization, debugging`；星标：2.4k * `OpenInference` — 目录标签：`spec, instrumentation, observability`；星标：953 * `FutureAGI` — 目录标签：`observability, evaluation, guardrails`；星标：843 ### V — 评估 Harness 与基准（21 项；主层：V） * `Promptfoo` — 目录标签：`eval, red-team, ci`；星标：20.9k * `DeepEval` — 目录标签：`evaluation, framework, testing`；星标：15.2k * `RAGAS` — 目录标签：`rag, metrics, evaluation`；星标：13.8k * `lm-evaluation-harness` — 目录标签：`benchmark, harness, llm`；星标：12.4k * `SWE-bench` — 目录标签：`benchmark, swe, evaluation`；星标：4.9k * `verifiers` — 目录标签：`verifier, rl, evaluation`；星标：4.1k * `AgentBench` — 目录标签：`benchmark, cross-domain, agent`；星标：3.4k * `LangWatch` — 目录标签：`simulation, evaluation, testing`；星标：3.2k * `EvalScope` — 目录标签：`benchmark, framework, llm`；星标：2.8k * `Terminal-Bench` — 目录标签：`terminal, benchmark, long-horizon`；星标：2.2k * `Harbor` — 目录标签：`evaluation, harness, rl-env`；星标：1.8k * `tau2-bench` — 目录标签：`tool-use, interaction, Benchmark`；星标：1.1k * `NeMoGym` — 目录标签：`rl-env, training, evaluation`；星标：872 * `TheAgentCompany` — 目录标签：`benchmark, workplace, multi-step`；星标：697 * `auto-harness` — 目录标签：`optimization, regression, evals`；星标：486 * `InspectEvals` — 目录标签：`inspect, eval-suite, reproducibility`；星标：480 * `SWE-BenchPro` — 目录标签：`swe, benchmark, long-horizon`；星标：371 * `AgentEvaluation` — 目录标签：`evaluation, testing, ci`；星标：360 * `WorkArena` — 目录标签：`browser, benchmark, enterprise`；星标：245 * `OpenHandsBenchmarks` — 目录标签：`openhands, eval, harness`；星标：77 * `WebArena-Verified` — 目录标签：`web-agent, benchmark, deterministic`；星标：38 ### G — 护栏、安全与治理（14 项；主层：G） * `LiteLLM` — 目录标签：`gateway, proxy, guardrails`；星标：45.9k * `Kong` — 目录标签：`gateway, policy, infra`；星标：43.3k * `IronClaw` — 目录标签：`security, wasm, routines`；星标：12.1k * `PortkeyGateway` — 目录标签：`gateway, guardrails, routing`；星标：11.6k * `CAI (Cybersecurity AI)` — 目录标签：`security, governance, framework`；星标：8.4k * `OpenAIRealtimeAgents` — 目录标签：`realtime, orchestration, control`；星标：6.8k * `Plano` — 目录标签：`proxy, safety, data-plane`；星标：6.4k * `OpenAICSAgentsDemo` — 目录标签：`demo, handoffs, governance`；星标：6.3k * `ContextForge` — 目录标签：`gateway, governance, observability`；星标：3.7k * `Archestra` — 目录标签：`enterprise, guardrails, governance`；星标：3.6k * `Tracecat` — 目录标签：`security, automation, policy`；星标：3.6k * `AgentGateway` — 目录标签：`gateway, mcp, proxy`；星标：2.6k * `Haft` — 目录标签：`governance, decisions, mcp`；星标：1.3k * `mini-coding-agent` — 目录标签：`coding-agent, minimal, approvals`；星标：807 ## 附录 B：参考 Harness 实现 表 S2 对六个用于深入比较的 reference harness implementations 进行画像。各条目聚焦于机制，而不是产品营销式摘要：每一行仅列出能被所引用的公开仓库、论文、文档或工程说明直接支持的主张。 **表 S2：** 参考 harness 实现及其文档化的 ETCLOVG 覆盖范围。 | 实现与来源 | Harness 模式与层覆盖 | 对本综述的设计启示 | | ------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | | Claude Code（Anthropic, 2025a; 2025b） |

终端式编码 agent；单 agent 的编辑、调试与 Git 循环。
层：E, T, C, L, G

| 它是高自治本地编码工作流的生产级参考实现：代码库感知 prompting、shell / tool 执行、仓库编辑以及显式权限或沙箱边界，都被视为 harness 的职责。 | | OpenCode（Anomaly, 2025） |

开源终端编码 agent，具备 plan / build 角色、subagent、LSP 支持以及 client-server runtime。
层：E, T, L

| 它是现代终端 agent 循环的一个可检查实现，尤其适合观察仓库中显式暴露的角色分离、subagent 委派，以及编辑器 / 工具集成。 | | Codex CLI（OpenAI, 2025; 2026b; 2026a） |

原生终端编码 agent；偏向无状态回放的单 agent 循环。
层：E, T, L, V

| OpenAI 关于 Codex 的写作把 harness 循环说得很明确：结构化 prompt、工具调用回放、本地命令执行，以及测试或验证反馈，是共同决定 agent 行为的因素。 | | OpenHands（Wang et al., 2025b; 2025c） |

开源软件工程 agent 平台与可组合 agent SDK。
层：E, T, C, L, V

| 它是面向仓库级软件 agent 的研究级参考：平台把沙箱执行、shell / browser / tool 交互、任务状态以及面向基准的评估耦合进同一个开放系统。 | | SWE-agent（Yang et al., 2024; SWE-agent, 2025; SWE-agent Team, 2024） |

以 agent-computer interface 为中心的问题修复型编码 agent，并配备 SWE-ReX 执行后端。
层：E, T, L, V

| 其关键贡献在于把 agent-computer interface 本身前置为研究对象：命令、观察、编辑动作、测试以及远程执行后端，都是被测量的 harness 的组成部分，而非偶然的基础设施。 | | Symphony（OpenAI, 2026b; Kotliarskyi et al., 2026） |

面向 issue-to-execution 控制的 Codex 编排规范与任务运行器工作流。
层：C, L, V, G

| Symphony 把 issue tracker 与任务运行器视为持久控制平面，使分配、进度状态、验证闸门与 review 边界成为 Codex 编排中显式的一部分。 | ### 译稿说明 * 本译稿保留原论文的章节编号、图表标题与核心术语。 * Appendix A 中的超宽表已按分组条目方式保留；Appendix B 保留为表格。 * 参考文献按用户要求省略。 --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://gists.lanlance.cn/cssys/agent-harness-engineering-a-survey.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.