26年4月来自中国民族大学、小红书、大连理工和中科大的论文“Agent Harness for Large Language Model Agents: A Survey“。

在生产环境中快速部署基于大语言模型（LLM）的智体，暴露出一个关键的工程问题：随着智体任务变​​得越来越长、越来越复杂，任务执行的可靠性越来越依赖于其外层基础设施——智体执行驾驭（agent execution harness），而不是底层模型的能力。这种依赖性表明，驾驭而非模型才是决定实际智能体系统性能的关键因素。

本文将驾驭视为一个统一的研究对象，值得进行系统性的研究，它独立于其各个组件的能力。本综述做出以下五项贡献：（1）对智体驾驭进行形式化定义，并采用转换系统语义区分执行循环的安全性和活性属性。（2）追溯驾驭概念的历史，从软件测试框架到强化学习环境，再到现代LLM智体基础设施，展示其向通用架构模式的趋同发展。（3）基于实证研究，对22个具有代表性的系统进行分类，并根据包含六个组成部分的完整性矩阵（执行环境、工具集成、上下文管理、范围协商、循环管理和验证）进行验证。 (4) 对九项贯穿始终的技术挑战进行系统分析，涵盖从沙箱和评估到协议标准化和计算经济性等各个方面，包括协议的实证比较（MCP 与 A2A）以及对超长上下文模型影响的分析。(5) 识别新兴的研究方向，这些方向中，驾驭层基础设施（harness infra）相对于组件能力而言仍处于欠发达状态。证据基础基于三项同行评审的实证研究（HAL 关于驾驭层可靠性的研究、SWE-bench 关于评估基础设施的研究以及 AgencyBench 关于跨组件耦合的研究），并辅以来自大规模部署（OpenAI、Stripe、METR）的实践报告，这些报告证实了绑定约束理论。其分析范围限定于端到端智体系统（不包括单步语言模型的使用），并将分类限制在具有公开文档的系统上，同时承认专有驾驭设计（harness design）在很大程度上仍未得到研究。

。。。。。。继续。。。。。。

---

智体驾驭（agent harness）有时被描述为仿佛与第一批LLM智体系统同时出现，并已完全成型。更准确的说法是，它是由三个独立的技术谱系逐步发展而来，每个谱系都贡献了重要的思想，同时也存在根本性的局限性，因此驾驭概念必须真正具有创新性。理解这段历史对于理解该领域的现状至关重要：当代驾驭中许多设计上的矛盾——例如隔离性和功能性之间的矛盾、可复现性和灵活性之间的矛盾、自动化和人工监督之间的矛盾——都直接源于先前传统所提供的不完整解决方案。

图9描绘2017年至2025年智体驾驭基础设施的演进轨迹，并将关键系统和事件沿三个平行路径组织起来：软件测试框架（顶部）、强化学习环境（中部）和LLM智体框架（底部）。该图直观地展示两个结构性观察结果：首先，每个谱系都贡献独特的思想——治理模板、接口标准、故障模式目录——这些思想对于驾驭概念的共同发展是必要的，但单独来看却不足；其次，这三个发展脉络在 2023-2024 年期间汇合，标志着驾驭的成熟，其标志是 AIOS 形式化、MCP 协议标准化以及第一代评估基础设施基准测试的同步出现。从左到右阅读时间线，可以追溯到从孤立的实验到公认的工程学科的演变过程；2024 年的汇合点标志着驾驭设计从隐式向显式的转变。

1 三条发展脉络，一个综合

在追溯每条发展脉络之前，有必要明确指出综合后产生的成果是任何一条发展脉络单独都无法提供的。其目标是刻画智体驾驭作为一种系统类别的真正创新之处，使其区别于对现有事物的改进版。

软件测试驾驭，建立治理包装器模式：即执行软件应被包装在一个控制输入、监控输出并强制隔离的环境中。但测试驾驭（test harness）的设计初衷是用于确定性的、单次执行有界程序，而非开放式、多步骤流程，后者会生成自身的中间目标并与不可预测的外部系统交互。
强化学习环境确立接口标准模式：智体与环境的交互应通过明确的契约进行协调，该契约包含清晰的观察空间和行动空间。然而，强化学习环境假定行动空间有限、任务周期短，且使用标量奖励作为评估指标——这些假设对于在开放式自然语言领域中运行、任务周期以小时计的LLM智体而言并不适用。

早期LLM框架建立故障模式目录：记录LLM智体在基础设施极简的情况下部署时出现的各种故障。该记录精确定义测试驾驭必须提供的治理功能——并非基于第一性原理的推导，而是基于观察的故障进行归纳。

该智体驾驭将治理包装器模式（源自测试框架）、接口标准模式（源自强化学习环境）和故障模式目录（源自早期LLM框架）综合为一个运行时治理系统，用于自然语言领域中开放式的多步骤执行。这种综合并非对任何先前系统的渐进式改进；它是一种真正意义上的新型基础设施，其设计需求由先前任何系统都未曾面临的约束条件决定——开放式执行、自然语言语义、大规模外部系统交互。

2. 主题 1 — 软件测试驾驭：治理模板

“测试驾驭”一词在软件工程中的最初含义可以追溯到单元测试和集成测试的自动化。JUnit（Beck & Gamma，1998）、xUnit 框架及其后续版本确立一种模式：测试驾驭将预先准备好的输入提供给被测软件单元，捕获其输出，并将其与预期结果进行比较。测试驾驭控制执行环境，确保测试在隔离环境中运行并产生可复现的结果。

这一传统确立几个在智体驾驭中仍然沿用的概念：执行系统需要一个治理包装器；该包装器应处理设置、清理和结果捕获；以及可复现性是包装器的属性，而不是被测系统的属性。CI/CD 范式将这些概念扩展到持续执行管道，引入了钩子、生命周期事件和结构化日志记录——所有这些都以不同的名称出现在现代智体驾驭中。

这一传统的关键局限性在于其范围。测试驾驭在固定的上下文中运行一次程序，以检查预定的属性。它不存在多轮状态、动态工具注册，也无需在长时间的任务序列中管理上下文。它所解决的治理问题比智体执行所需的问题要简单得多。其贡献在于概念和术语，而非架构。

3. 主题 2 — 强化学习环境：接口标准

OpenAI Gym（Brockman，2016）引入更直接相关的内容：智体与其环境之间的标准接口。reset() /step(action) /observe() 模式确立智体与环境的交互应由定义的契约来协调，并且环境应具有可隔离性、可重置性和跨实验的可重用性。这一传统贡献 LLM 智体框架继承的三个理念：接口标准化、隔离性和评估工具（在强化学习中是奖励信号；在 LLM 智体中是任务轨迹）。

Gym抽象将智体-环境接口分解为四个不变函数：reset() 将环境初始化为干净的初始状态；step(action) 应用智体动作并返回结果观测值、奖励、终止标志和辅助信息；observe() 返回当前环境状态，不推进时间；render() 生成环境状态的人类可读表示。这种分解的精妙之处在于它将智体的决策问题（采取什么动作）与环境的动态（采取该动作后会发生什么）分离，从而建立一个清晰的接口契约，使得智体和环境能够独立地开发和测试。

LLM智体驾驭，继承这种接口契约的精神——即智体-环境交互应通过具有明确语义的定义接口进行协调——但必须在四个维度上对其进行大幅扩展。首先，LLM智体中的动作空间是一个结构化的自然语言生成，而不是一个有限的类型集合，这要求驾驭（harness）解析、验证和分发模型输出，而不仅仅是路由一个整数动作token。第二，强化学习（RL）中的奖励信号被假定为完整的评估指标（最大化累积奖励是智体的全部目标）；而在LLM智体中，任务成功是一个复杂的组合谓词，需要评估者的判断，而不仅仅是对标量值的观察。第三，强化学习中的 reset() 函数可以将环境恢复到精确的先前状态；而对于在真实外部环境（Web 服务、文件系统、API）中运行的LLM智体而言，重置要么是不可能的，要么需要复杂的快照和回展（rollback）机制。

第四，强化学习环境假定智体的动作对环境状态具有唯一的影响；而使用多工具访问的LLM智体则会产生复合状态效应（单个模型输出可能触发多个具有独立副作用的工具调用），这需要进行框架级别的效应跟踪和组合。

然而，迁移问题依然存在。强化学习环境做出一些不适用于LLM智体的假设：有限的、类型化的动作空间；可在运行间重置的短时合成任务；以及作为完整评估指标的标量奖励。 LLM 智体生成开放式的自然语言，这些语言必须被解析为动作，执行耗时数分钟到数小时的真实外部系统任务，并且需要评估方法，而这些评估方法本身也是研究问题。已有研究试图弥合这一差距——Carta (2024) 将 Gymnasium API 适配到多轮 LLM 任务；GAIA (Mialon 等人，2023) 将真实世界的任务封装在类似 Gym 的界面中——但两者都需要进行大量的重新设计，这既体现继承性，也凸显不匹配的深度。BrowserGym（WorkArena；Drouin，2024）代表当前受强化学习启发的LLM智体环境抽象的最新技术：通过定义标准观察类型（浏览器状态，结构化 HTML + 屏幕截图）、标准动作空间（Web 交互原语：点击、输入、滚动、导航）和标准奖励机制（任务完成情况与目标状态进行验证），BrowserGym 实现强化学习接口标准的优势（智体与环境的独立性、可重用的评估基础设施），同时将其扩展到强化学习环境无法触及的真实 Web 环境。

4. 主题 3 — 早期 LLM 智体框架：故障模式目录

第三部分与 LLM 的发展最为接近。从 2022 年开始，最早的 LLM 智体系统仅需极少的基础设施即可运行。ReAct（Yao，2023）仅需 50 行 Python 代码即可实现：一个循环、一个提示模板和一个小型工具调度表。这些系统展示的是模型能力，而非工程成就。

除了 ReAct 之外，这一时期还产生了两个关于工具集成的基础性成果。Toolformer（Schick，2023）证明，语言模型可以通过自监督训练目标来学习如何调用外部工具——计算器、搜索引擎、翻译 API 等——从而首次从原则上解释了工具使用能力是如何习得的，而不是硬编码的。Gorilla（Patil，2023）将这一成果扩展到 API 规模的工具环境：通过在包含 1600 多个真实 API 的语料库上进行训练，并引入检索增强的工具选择，Gorilla 表明，通过基于检索的 API 文档而非仅仅依赖模型先验信息来选择工具，可以显著减少工具调用参数中的“幻觉”（一种持续存在的可靠性故障模式）。 ToolLLM（Qin，2023）更进一步，构建包含16000多个真实世界API的ToolBench数据集，并提出一种DFSDT（深度优先搜索决策树）规划策略，证明在框架执行循环中进行系统化的工具调用规划，其性能显著优于贪婪式API选择。Toolformer、Gorilla和ToolLLM共同记录驾驭（harness）T组件设计的演进：从将工具能力作为模型属性（Toolformer），到将工具选择作为检索问题（Gorilla），再到将工具规划作为框架执行循环必须支持的搜索问题（ToolLLM）。

第一代自主智体——AutoGPT（Richards，2023）和BabyAGI（Nakajima，2023）——通过赋予智体持久目标、互联网访问以及生成子任务的能力，改变了整个格局。它们构建的系统足够复杂，能够以新颖且富有启发性的方式失败。回顾来看，这些早期系统记录的故障模式，恰恰构成一个治理功能目录，涵盖了系统必须提供的各项功能：由于缺乏终止逻辑而导致的执行失控（E 故障）；由于历史记录未经压缩而导致的上下文溢出（C 故障）；多步骤任务中断时导致的状态丢失（S 故障）；以及智体在未记录日志的情况下发送电子邮件和修改文件而产生的未被监控的副作用（L 故障）。

除了这些故障演示之外，2023 年还出现了多智体协调领域首个重要的架构实验。CAMEL（Li，NeurIPS 2023）引入了一个角色扮演框架，其中智体通过结构化的对话轮次进行通信，并明确声明各自的角色。这种概念模式——将智体身份、能力声明和任务委派作为明确的协议级关注点——预示 A2A 后来在基础设施层形式化的内容。 ChatDev（Qian，2023）在瀑布式软件开发流程中组织了多智体工作流，分配了角色（产品经理、程序员、测试人员、评审人员），并强制要求角色之间进行结构化文档交接。ChatDev对应用理论的贡献在于，它证明了智体间通信模式（而不仅仅是智体的能力）决定了工作流的可靠性：当智体之间的文档格式规范不足时，任务质量下降会蔓延至整个流程。MetaGPT（Hong，ICLR 2024）更进一步，将标准化操作程序（SOP）编码到智体间通信中：每个智体角色都以结构化文档作为输入，并生成结构化文档作为输出，使得消息模式本身成为一种治理机制。回想起来，这种基于SOP的通信架构是A2A的智体卡片和任务规范设计的直接先驱：两者都将智体间交互视为一种类型化的契约，而不是自由形式的对话。

关键在于，CAMEL、ChatDev 和 MetaGPT 都没有将消息传递基础设施与智体逻辑分离——协议嵌入在智体代码中，因此如果不重写智体，就无法替换或升级通信层。A2A 作为显式协议层的出现，标志着该领域认识到这种耦合是一种设计缺陷：智能体间的通信应该是一种框架层面的治理功能，而非应用层面的约定。

同样在 2023 年，Voyager（Wang，2023）引入一个持久化的、不断增长的技能库——智体可以在不同会话中添加和检索的可执行代码工件。这是一种解决状态管理问题的原则性方案，它存储的是抽象的、可重用的能力，而不是原始的交互历史记录。MemGPT（Packer，NeurIPS 2023）直接解决上下文管理问题，将上下文窗口建模为 RAM，将外部存储建模为磁盘。Reflexion（Shinn，2023）引入一种补充性的记忆机制：Reflexion 智体并非将经验存储为原始观察结果，而是将失败的执行轨迹转换为存储在情景缓冲区中的语言自我批评，从而实现基于语言的跨尝试自我改进，而无需更新梯度。 Reflexion 中的情景缓冲区是现代 S 组件必须支持的结构化经验存储的前身：它存储的不是发生了什么，而是智体从发生的事情中学到了什么——这种表征上的区别直接影响着长期部署中的检索质量。与此同时，生成式智体Generative Agents（Park，CHI 2023）在社会模拟规模上展示驾驭-级记忆架构：在一个模拟城镇中，25 个 LLM 智体各自维护着一个带有时间戳的观察记忆流、一个定期综合高阶洞察的反思机制，以及一个结合时效性、重要性和相关性评分的检索函数。生成式智体架构Generative Agents对工具级记忆设计做出三项至今仍具有影响力的贡献：原始观察和综合洞察需要不同的存储层；检索必须平衡多个相关性信号；以及反思——即对经验的周期性压缩和抽象——是驾驭-级调度问题，而不仅仅是模型本身的能力。这些系统各自从不同的角度着手解决同一个根本问题——什么应该保留下来，以何种形式，在何种治理下。

2023 年基准基础设施的出现

伴随着 2023 年的能力实验，该领域诞生第一代评估基础设施，而这本身就是一种驾驭工程。这一发展常常被忽视，因为基准论文的分类依据是其任务领域而非其对基础设施的贡献——但为了使这些基准有效且可复现，所需的驾驭工程与任务设计同样重要。

WebArena（Zhou，2024）提供最具启发性的案例。在自托管的实时 Web 环境中（并非缓存快照或第三方服务，而是包含购物网站、代码库、Reddit 式论坛和企业维基在内的完整运行的 Web 应用程序），部署 812 个长期 Web 导航任务需要部署和维护四个独立的 Web 应用服务器，管理数百个模拟用户的帐户状态，实现与任意 Web 应用架构兼容的操作注入机制，并设计可针对任意应用状态进行编程验证的成功标准。运行一个 WebArena 评估实例的驾驭工程比当时大多数生产智体部署的驾驭工程都要复杂。WebArena 的架构直接影响了后续的基准测试：自托管环境基础设施模式成为那些需要在不依赖外部服务的情况下保证生态有效性的评估系统的标准。

AgentBench（Liu，2023）提出了不同的基础设施挑战：协调八个并行评估环境，每个环境都有不同的观察空间、操作空间和状态管理要求。 AgentBench框架充当编排层，统领八个子驾驭（sub-harness），每个子驾驭都针对其特定的环境领域量身定制。其L组件必须同时管理八个不同环境API的身份验证、日志记录和策略执行，且没有共享的模式。其V组件必须将八个不同的任务成功标准规范化为通用的评估记录格式。构建一个能够与八个结构迥异的环境无缝对接的框架，其工程挑战恰恰在于MCP后来针对工具接口所解决的互操作性问题——但MCP当时是针对评估环境而非工具，并且是通过临时方案而非标准协议来解决的。

GAIA（Mialon，2023）采用不同的方法，它设计的任务需要跨工具（网络搜索、文件处理、代码执行）进行多步骤推理，同时保持自然语言任务规范对人类标注者可用。其77个百分点的人类/GPT-4性能差距并非主要源于模型能力，而是源于基础设施：人类智体能够访问更丰富的环境信息——他们可以自由浏览、标注、验证和纠正错误——而通过固定驾驭接口运行的LLM智体则无法做到这一点。这种框架——将性能差距视为基础设施差距而非能力差距——正是“接口即基础设施”论点的评估重述，而GAIA则是最能生动展现这一论点的基准。

5. 接口转向（2024-2026）

到2024年，早期LLM智体阶段的实验性活力已让位于工程规范。该领域积累足够的部署经验，人们认识到，影响智体可靠性的关键因素并非模型质量，而是基础设施质量。将这种转变称为“驾驭转向（harness turn）”。

基准测试基础设施的成熟演变为一项独特的工程挑战：SWE-bench（Jimenez，2024）、OSWorld（Xie，2024）、WebArena（Zhou，2024）、WorkArena（Drouin，2024）和 HAL（Kapoor，2026）都需要大量的驾驭工程才能大规模可复现地运行。协议标准化成为一种实际需求——Anthropic 的 MCP 和 Google 的 A2A 代表该领域对工具注册表标准化的认识，即每个驾驭都无法独立解决这一问题。AIOS（Mei，COLM 2025）标志着学术界正式化。而对不同驾驭差异的实证研究——AgencyBench 和 SkillsBench——则提供先前分析所缺乏的量化基础。

三种工程范式：回顾。 2022-2026 年期间，该领域在工程设计方面呈现出一个连贯的三阶段演进：

1. 提示工程（2022-2024 年）：主要的工程杠杆是输入提示文本本身。研究人员和实践者通过精心设计更好的指令、少样本示例和推理模板来进行优化。问题是：“我们应该给模型提供什么样的文本才能获得更好的输出？”这一时期产生以思维链提示、情境学习和指令调整为核心方法的理论。
2. 上下文工程（2025 年）：随着智体运行时间的延长，约束条件从“输入是什么？”转变为“模型应该看到什么信息？”这一时期专注于情境管理：每次迭代应该注入什么信息，如何检索和压缩记忆，如何按相关性对工具结果进行排序，以及如何处理情境窗口饱和问题。情境工程提出的问题是：“我们应该收集哪些结构化信息并将其呈现给模型以指导其决策？”正是在这个时候，实践者开始系统化地进行记忆检索、工具结果格式化和动态上下文管理。
3. 驾驭工程（2026）：随着模型能够处理长时间运行的任务，但部署可靠性仍然难以实现，工程的关注点扩展到了整个基础设施封装层。驾驭工程提出的问题是：“为了使智体系统可靠，必须设计哪些治理、约束、反馈回路和执行控制？”答案涵盖所有六个组件（E、T、C、S、L、V），并将它们视为一个整体。这一时代以 OpenAI 的 Codex 框架、Meta-Harness 优化和 LangChain 的 DeepAgents 为代表，它认识到模型能力是必要的，但并非充分条件——可靠性源于一个强大的模型与一个精心设计的执行环境之间的交互。

每一种范式都代表着工程关注范围的扩展。提示工程优化单个文本输入。上下文工程管理模型周围的结构化信息环境。 驾驭工程设计完整的六-组件治理基础设施。如图 10 以可视化的方式展示这一发展历程。

6. 驾驭概念为何需要所有三个谱系

智体驾驭并非任何单一先前传统的线性演化。软件测试驾驭确立治理包装器的必要性，但并未阐明其运行时特性。强化学习 (RL) 环境确立接口标准化和隔离，但其假设的简单性是 LLM 智体任务所不具备的。早期的 LLM 框架展示了缺乏治理具体会导致哪些问题，并针对特定的治理子问题提出了首批解决方案。驾驭综合所有这三者的贡献，同时解决各自的局限性——这正是它需要所有三个谱系共同出现的原因，也是它无法简化为其中任何一种的原因。

向一致的架构模式的历史性趋同引出一个自然的问题：这种模式是否真正具有普适性？或者，系统在实例化驾驭时是否存在显著差异？为了回答这个问题，需要一个经验分类法，通过一系列不同的真实世界系统来检验六组件模型的完整性和通用性。

---

1 分类问题

任何智体驾驭系统的分类都必须先解决一个问题：要对哪个维度的差异进行分类？现有的生态系统包含的系统至少在三个独立的维度上存在差异——功能完整性（它们实现了六个治理组件中的多少个）、域专业化（它们是为通用任务类型还是特定任务类型设计的）以及堆栈位置（它们是作为运行时环境、开发工具还是能力组件运行）。本文采用二维分类：栈位置作为主要维度，域范围作为次要维度。这种组织方式反映实践者最常问的问题：“这个系统我可以直接部署，还是需要我进行构建？”

系统选择方法

本综述分析 22 个智体驾驭系统，但选择过程本身需要明确的论证。其采用结构化的专家综述方法，而非符合 PRISMA 标准的系统性回顾，这反映智体驾驭文献的起步阶段以及灰色文献（从业者报告、开发者博客、GitHub 代码库）作为主要来源的普遍性。

完全性矩阵的编码方法

首先明确阐述分类方法。每个组件的评级均通过三源验证流程确定：（1）主要文档审查——系统开发者发布的官方文档、API规范和架构描述；（2）在条件允许的情况下审查开源代码（适用于LangGraph、AutoGen、OpenHands、AIOS、MemGPT、SWE-agent、Voyager以及所有评估基础设施系统）；（3）在条件允许的情况下查阅已发表的学术论文（适用于MemGPT、AIOS、CAMEL、MetaGPT以及评估系统）。如果不同来源的结果存在分歧，则以官方文档为准；如果在查阅所有三个来源后仍然存在歧义，则在扩展数据中将该组件标记为[D]（有争议）。对于闭源系统（Claude Code、DeepAgents、Browser-Use），评级来源于官方文档、公开的API规范和已发表的博客文章；文档可能夸大了部署的复杂程度。

如图 11 所示完整性矩阵热图：22 个系统 × 6 个组件。深色单元格表示完全实现，中等颜色单元格表示部分实现，浅色单元格表示未实现。

2 驾驭完全性矩阵

如图 12所示：驾驭架构分类树。该层次分类树展示系统如何根据其完全性概况聚类为三个架构系列。顶层区分全栈驾驭（E、T、C、S、L、V 均已基本实现）与框架（E 和 T 已实现，C/S/L/V 通常为部分实现）以及功能模块（C、S 已实现，其他模块功能极少）。第二层根据部署上下文区分框架：编排框架（LangGraph、Prefect）分别实现 L 和 E，而推理框架（vLLM、SGLang）实现 E 和 T，但将 L 委托给调用应用程序。每个类别的示例位于叶节点，并显示系统名称和参考信息。这种分类结构表明，系统并非处于单一的“完全性谱系”上；相反，它们通过移除不同的组件来优化不同的用例，从而形成性质不同的架构模式。

3. 分类

该生态系统分为五类。全栈式驾驭实现所有六个治理组件，并具有生产级可靠性。此类中的五个系统——DeepAgents、Claude Code、OpenClaw、DeerFlow 和 OpenHands——主要区别在于设计理念和目标场景。DeepAgents 强调上下文工程和子智体编排。Claude Code 是一个闭源框架，针对软件工程任务进行优化，值得注意的是，它是唯一一个在其官方工程文档中明确将自身定义为“智体驾驭”的主要商业系统。

OpenClaw 代表当前部署中最完整的开源驾驭（harness）概念实现。其架构直接实现了五个必要条件：由事件触发器（心跳、Webhook 和规划任务）控制的持久执行循环；基于技能注册表并原生集成 MCP 的工具管理层；分离工作记忆、检索记忆和长期精简记忆的三层记忆架构（体现在其 MEMORY.md 约定和会话上下文管理中）；支持动态多智体协调的子智体生成机制；以及截至 2026 年 3 月的外部运行-时安全层——PRISM（Li arXiv:2603.11853，2026）——该安全层在十个生命周期钩子上分发执行，而无需 fork 宿主框架。 PRISM 的零分支架构实现混合启发式-加- LLM 的扫描管道，并采用会话级风险累积机制，是首个针对已部署的开源“智体驾驭”进行生产运行时安全性的系统性公开解决方案。OpenClaw 作为生产系统，而 PRISM 作为首个公开文档化的开源智体驾驭生产运行时安全层，二者的共存标志着智体驾驭研究进入一个新阶段：实践规模的部署将生成学术基础设施，并反过来为研究社区提供反馈，从而在经验驾驭工程（harness engineering）和系统性学术分析之间形成闭环。

通用框架为智体逻辑提供构建原语，但将运行时管理委托给部署者。LangGraph 基于 DAG 的执行图使开发人员能够显式控制智体流程，但未实现上下文管理或安全模型。AutoGen 基于角色的对话管理处理多智体协调，但将状态持久化和评估视为开发人员的责任。Google ADK 原生集成 A2A 协议，使其成为必须跨组织边界通信的智体标准驾驭。

在驾驭分类中，LlamaIndex 的位置与 LangChain 类似：它通过检索器和查询引擎抽象提供强大的 T 和 C 组件支持，但缺少 L 和 V 组件，因此无法达到完整驾驭的水平。它的 E 组件是部分实现的，通过 QueryPipeline 工作流编排接口实现，该接口提供 DAG 风格的任务排序，但缺少执行循环语义——错误恢复、终止条件、状态机形式化——这些语义是驾驭 E 组件区别于框架原语（framework primitive）的关键所在。它的 S 组件同样是部分实现的，通过存储集成（向量存储、文档存储、索引存储）提供支持，这些集成为检索工件提供持久性，但并不构成通用的跨会话状态存储。LlamaIndex 对驾驭生态系统（harness ecosystem）的主要贡献在于提供 C 组件——一个复杂的上下文组装层，许多全栈驾驭（包括基于 LangGraph 的系统）将其集成为检索后端，而不是原生实现。检索器、查询引擎和响应合成器抽象构成开源生态系统中最成熟的现成 C 组件子系统；采用 LlamaIndex 作为 C 组件依赖项的驾驭构建者（harness builder）无需从头开始实现，即可获得显著的上下文管理能力。实践驾驭工程运动催生一种可识别的“驾驭-优先”生产系统类别，这些系统位于 ETCSLV 完整性谱系的“完整驾驭”一端——与“模型优先”系统的区别在于，前者更注重环境规范和架构约束，而非模型选择。OpenAI Codex 驾驭是此类架构的典型代表：其架构通过 Codex 生成的结构化测试强制执行经代码检查器验证的六层依赖关系顺序（类型 → 配置 → 仓库 → 服务 → 运行时 → 用户界面），将 Chrome DevTools 协议直接集成到智体运行时以实现 DOM 级环境访问，并将 LogQL 和 PromQL 暴露给 Codex，以便实时观察其自身的执行环境（Lopopolo，2026）。Stripe 的 Minions Blueprint 架构是另一个典型代表：确定性驾驭节点（harness node）管理 CI/linting 和 PR 模板，智体节点处理实现，驾驭-强制执行最多两轮 CI 后才升级到人工审核，从而在基础设施层实施策略决策，而不是将其委托给模型判断，并且每个智体实例都能在十秒内启动自己的开发环境（Gray，2026）。这些系统实例化所有六个 ETCSLV 组件——执行环境隔离、精心管理的工具注册表、通过 AGENTS.md 约定进行上下文管理、每个智体实例的持久状态、强制执行确定性步骤的生命周期钩子以及自动化 CI 评估——其性能特征既取决于驾驭架构，也取决于模型能力。

专用驾驭为特定领域实现完整或接近完整的治理。SWE-agent 将 ACIface 交互模型与基于容器的执行环境相结合，用于存储库操作。Browser-Use 通过提供完整的 Web 导航执行环境，并根据无状态任务的需要，特意省略了持久状态和生命周期钩子，从而获得了超过 87,000 个 GitHub star。RAI 通过 ROS2 将驾驭概念扩展到物理机器人系统，其中工具注册表映射到传感器和执行器接口。

功能模块出色地实现一到两个治理功能，其设计目的是集成到驾驭中，而不是独立部署。MemGPT 的虚拟上下文管理是目前最强大的 C 组件实现。 MCP 服务器构成标准的 T 组件接口。Voyager 的技能库代表一种经过验证的 S 组件架构——它存储的不是原始交互历史，而是抽象的、可重用的能力。

另外三个多智体系统——Concordia（Vezhnevets，2023）、Mixture-of-Agents（Wang，2024）和 AgentVerse（Chen，2023）——属于能力模块类别，并具有多智体专长。Concordia（DeepMind）为在物理、社交或数字空间中行动的​​ LLM 智体提供了一个仿真基础；其共享的关联记忆组件实现了智体集合之间的持久状态同步，从而无需集中式平台即可解决多智体 S 组件中跨智体状态一致性的挑战。混合智体（MoA）将智体协作构建为一个分层管道，其中提议智体生成候选答案，聚合智体在多轮迭代中综合这些答案；其集体智能效应——证明迭代式跨智体综合优于任何单个智体——为协议互操作性中讨论的驾驭互操作性工作提供了有力论证。AgentVerse引入了动态智体招募机制，其中智体集合的组成会在运行时根据任务需求进行调整；这需要驾驭级别的智体注册管理，类似于T组件中的动态工具注册，但应用于智体而非工具。

两个专注于给予的功能模块值得明确纳入：MemoryBank（Zhong，2023）和Agent Workflow Memory（Wu，2024）。 MemoryBank 实现一种受艾宾浩斯遗忘曲线启发的遗忘机制，该机制控制着记忆的保留与衰减，为 LLM 智体提供首个基于原则的长期记忆更新机制，并直接解决了记忆膨胀问题。智体工作流记忆 (AWM) 则采用不同的方法：AWM 不存储个体经验，而是从过去的任务轨迹中提取可重用的工作流抽象，然后检索并执行适用于新任务的工作流。AWM 在 Mind2Web（成功率提升 14.9%）和 WebArena（成功率提升 8.9%）上的出色表现表明，程序性记忆（而不仅仅是情景记忆）是 S 组件设计中至关重要的考量因素。

评估基础设施构成一个独特的类别：这些系统需要大量的驾驭工程来评估其他智体，但不能作为生产运行环境部署。这一类别的广度被低估了——据统计，至少有十二个不同的评估基础设施系统已部署生产级驾驭工程，这实际上代表驾驭概念在评估而非任务执行方面的专业化应用。HAL（Kapoor，2026）代表当前最先进的技术：一个标准化的评估驾驭，可协调数百个虚拟机上的并行评估，并在九个基准测试中进行 21,730 次部署，以展示强大的基础设施所能达到的水平。AgencyBench（Li，2026）扩展这一功能，增加跨驾驭评估能力，可同时在原生和外部框架环境中运行智体，以隔离驾驭-模型耦合效应。SkillsBench（Li，2026）使用与模型无关的驾驭（基于 Harbor）在 7,308 条轨迹上部署七种智体-模型配置，以将技能效应与驾驭效应区分开来——这种方法代表该领域最严格的受控跨驾驭比较方法。 Terminal-Bench 2.0 的 Harbor 框架为以命令行界面 (CLI) 为中心的任务提供容器化的可复现执行。SWE-bench 的评估驾驭（evaluation harness）通过显式沙箱机制，协调针对真实 GitHub 代码库的测试执行，以防止数据污染。OSWorld 的评估驾驭必须管理实时 GUI 环境中的屏幕截图捕获、动作注入和状态验证——这是目前技术要求最高的评估环境。AgentBench (Liu，2023) 协调八个并行评估环境，涵盖从操作系统任务到数据库操作的各个方面，需要一个不同于任何单域评估系统的多环境编排驾驭（orchestration harness）。WorkArena (Drouin，2024) 引入 BrowserGym——一个统一的浏览器环境接口，为基于 Web 的智体评估提供标准化的观察和操作——它作为实时 Web 应用程序的驾驭-级抽象层，使其能够直接与 OpenAI Gym 在强化学习 (RL) 中扮演的环境标准化角色相媲美。 InterCode（Yang，2023）提供一个基于 Docker 容器的交互式编码基准测试，其中代码是动作空间，执行输出是观察结果；其容器化环境设计直接模拟驾驭代码-执行沙箱架构，结合跨回合的状态持久性、执行隔离和脚本化奖励函数。这些系统逐渐达成共识：评估基础设施不仅仅是一个测试问题，更是一个科学基础设施问题：该领域能力主张的可靠性取决于生成这些主张的评估驾驭的可靠性。

评估基础设施差距：十二个系统及其现状

评估基础设施的工程投入深度被低估，正是因为这些系统在学术话语中被归类为“基准测试”，这掩盖它们作为驾驭工程成就的本质。本文列举语料库中的十二个主要评估基础设施系统，并描述每个系统所代表的具体驾驭工程创新。

多智体驾驭架构模式

驾驭（harness）分类中的多智体维度值得特别关注，因为它引入单智体驾驭所不面临的治理需求。当多个智体在驾驭内部或跨驾驭边界执行操作时，会出现三个新的治理问题：智体身份管理（哪个智体正在执行哪个操作，以及拥有什么权限？）；智体间消息验证（智体之间的消息适用哪些模式和内容约束？）；以及共享状态一致性（当多个智体更新共享状态时，S 组件必须提供哪些一致性保证？）。

所调查的系统揭示四种不同的多智体框架模式。1）基于角色的编排模式（MetaGPT、ChatDev、CrewAI）分配具有固定通信模式的固定角色：每个智体角色都有定义的输入文档格式和输出文档格式，驾驭在消息边界处验证模式合规性。这种模式以牺牲灵活性为代价实现可预测的协调——添加新角色需要更新驾驭的模式注册表。2）基于市场的协调模式（AutoGen、混合智体）支持根据任务需求动态选择智体：系统维护一个类似于工具注册表的智体注册表，并根据能力匹配和任务状态选择和调用智体。3）仿真底层模式（Concordia、生成式智体）提供一个所有智体均可读写的共享世界模型；系统通过强制执行一致性的读/写 API 来管理对共享世界状态的访问。4）分层委托模式（DeerFlow、DeepAgents）区分协调智体和工作智体，系统强制工作智体只能执行其协调智体授权的操作——这种权限模型类似于应用于智体集合的 Unix 进程层级结构。

案例研究：OpenAI Codex 大规模应用驾驭工程

迄今为止，OpenAI 的 Codex 智体系统是规模最大的智体驾驭基础设施生产部署，Lopopolo (2026) 的实践报告以及 OpenAI 在 2026 年 2 月明确提出的更广泛的“驾驭工程”学科均对此进行记录。Codex 框架展示所有六个治理组件在生产规模下协同运行，并通过一个与模型能力无关的部署指标，对绑定约束理论进行了定量验证。

规模与架构。在五个月的时间里（2025 年 8 月至 2026 年 2 月），一个由三到七名工程师组成的团队通过 Codex 生成的代码构建了约一百万行生产代码，涵盖了应用程序逻辑、基础设施、工具和文档，并产生了约 1500 个合并的拉取请求。这种吞吐量（平均每位工程师每天 3.5 个拉取请求）是迄今为止对大规模智体部署最全面的测试。至关重要的是，生产环境中的每一行代码都由 Codex 生成；没有一行是手工编写的。这使得 Codex 框架成为理解部署代码生成智体所需基础设施的有效工具。

驾驭架构。Codex 框架通过经过代码检查器验证的依赖关系顺序实现所有六个 ETCSLV 组件：类型 → 配置 → 仓库 → 服务 → 运行时 → 用户界面。每一层都由 Codex 生成，通过结构测试验证，并集成到下一层。 E 组件通过依赖约束强制执行流程：底层必须先完成才能执行上层，从而防止竞态条件和状态损坏。T 组件实现一个精心管理的工具注册表，其中包括源代码修改工具（支持抽象语法树的补丁）、测试工具（Python pytest、JavaScript Jest）和可观测性工具（用于 DOM 访问的 Chrome DevTools 协议）。C 组件通过实时代码自省提供上下文：该驾驭通过代码生成上下文 API 将当前仓库状态、最近的 CI 日志和执行跟踪信息暴露给 Codex。S 组件通过 Git 持久化智体状态：每次智体迭代都会提交到一个分支，驾驭会回展（rollback）未通过结构验证的提交。L 组件强制执行生命周期约束：智体依次经历规划 → 实现 → 测试 → 集成阶段，驾驭强制执行的门控机制会阻止智体进入下一阶段，直到当前阶段通过验证。V 组件是自动化的 CI/CD 验证：Codex 生成的代码会通过结构测试（代码检查、类型检查）和行为测试（针对测试套件执行）进行评估。

驾驭作为约束条件。Codex 团队的回顾报告明确指出，驾驭质量，而非模型能力，才是约束条件。Lopopolo (2026) 指出：“早期进展比预期的要慢，并非因为 Codex 能力不足，而是因为环境规范不够完善。”这一观察揭示了一个关键洞见：一旦模型达到某个能力阈值（Codex 似乎已经超过该阈值），限制因素就变成驾驭如何有效地将这种能力转化为实际行动。团队还报告说，随着团队规模从三名工程师扩展到七名工程师，吞吐量反而没有饱和，反而有所增长——这违反了布鲁克斯定律，团队将其归因于每位工程师都运行着一个独立的驾驭实例。这一发现表明，驾驭设计实现智体执行的并行性，而这在共享代码库和单智体的情况下是无法实现的：每个智体都有自己的分支、自己的执行环境和自己的验证循环，从而减少了争用并实现了独立进展。

对驾驭设计的启示。 Codex 的部署表明，大规模智体部署的成功关键在于驾驭的三个特性：(1) 消除环境欠规范——驾驭必须以机器可读的形式（代码检查规则、类型签名、模式定义）明确所有必要的约束，而不是将其隐含在实践者的知识中；(2) 执行前进行操作验证——驾驭在执行代码之前验证其结构正确性，从而将失败率从“编写运行时崩溃的代码”降低到“编写通过静态验证的代码”；(3) 反馈闭环——驾驭提供即时、可操作的反馈（测试失败、类型错误、代码检查违规），无需人工干预即可指导下一次迭代。这三个特性并非模型能力要求，而是驾驭工程（harness engineering）要求，在生产规模下会成为关键约束。

4. 分类法揭示的内容

该分类法揭示一些单个系统描述所掩盖的结构性观察结果。在介绍这些结果之前，仅包含 22 个系统的语料库在代表性方面存在局限性。该分类法涵盖所有主要的开源驾驭系统（OpenHands、AIOS、SWE-agent、Voyager、MemGPT、LangGraph、AutoGen）以及文档公开的主要商业系统（Claude Code、DeepAgents、DeerFlow）。它包含了被引用最广泛的评估基础设施系统（HAL、AgencyBench、SWE-bench）以及部署最广泛的 MCP/A2A 协议实现。然而，它几乎肯定会遗漏大型组织内部部署的、尚未公开其设计的驾驭系统，并且可能低估了不使用“智体驾驭”术语的专业领域驾驭系统（医疗人工智能、金融人工智能、机器人技术）。

下文识别出的结构模式在所涵盖的系统中具有稳健性，但可能无法代表更广泛的已部署生态系统。模块化差距最为显著：尽管存在一些优秀的、可共享的特定组件实现（例如用于 C 的 MemGPT 和用于 T 的 MCP 服务器），但全栈驾驭大多仍基于每个治理组件的专有实现构建。该生态系统缺乏用于 S（状态存储）、L（生命周期钩子）和 V（评估接口）的可比标准组件。每个全栈驾驭都独立地重新实现这些功能，没有共享的基础架构，驾驭之间也无法移植。第二个观察结果涉及框架-驾驭之间的边界，这是一种设计决策：一些系统（例如 AutoGen 和 Google ADK）处于模糊不清的位置，这表明该边界并非固定不变，而是反映了在“开发人员配置的内容”和“系统处理的内容”之间划定界限的选择。第三，评估基础设施是一种强制因素：由于基准测试结果必须可复现且可比，评估工具对环境隔离和状态管理提出严格的要求，而生产部署工具通常会放宽这些要求——从而造就业内一些设计最为精良的执行环境。

既然已经确定六组件模型能够准确描述架构格局，那么现在将视角从结构转向动态：当这些组件在生产规模下运行时，它们之间的交互会产生哪些技术挑战？完整性矩阵展示每个系统实现哪些组件。

---

1 跨域挑战分析简介

在生产规模下运行的驾驭组件之间交互过程中，讨论九项核心技术挑战。这些挑战通常被视为独立的技术子问题，但它们之间紧密耦合：任何一个子问题的失效都会放大其他子问题的失效风险。这九项挑战分为三个主题部分：执行基础设施挑战（涵盖安全性、评估和协议）；状态和知识管理（涵盖上下文、工具和内存）；以及协调和规划（涵盖规划和多智体协调）。

如图 13 所示跨-组件挑战耦合矩阵（9×6）：

2. 沙箱与安全

智体驾驭的独特威胁特征

智体驾驭带来的安全问题与传统软件安全以及LLM对齐研究中涉及的安全问题都存在本质区别。传统软件安全假设执行的代码由系统所有者或已知的第三方编写，并且其效果是确定性的，可以进行静态推理。LLM安全研究假设主要风险在于模型输出——响应恶意指令而生成的有害内容。智体驾驭违反这两个假设：执行的代码是由模型动态生成的，以响应不可预测的环境状态，风险不在于模型的“说”是什么，而在于它实际做了什么。

图14将评估不可靠性的三个根本原因——环境漂移、任务规范模糊和驾驭耦合（harness coupling）——映射到一个结构化的因果图上，展示每个原因如何通过（智体、驾驭、环境）系统传播，最终导致基准测试结果出现测量误差。左侧分支追踪环境漂移：外部系统变更（网站重新设计、API 更新、软件接口变更）会通过驾驭的环境接口传播，从而破坏任务状态，导致行为正常的智体遇到变更后的环境时出现误报。中间分支追踪任务规范歧义：不明确的自然语言任务描述会导致评估者做出不一致的判断，引入的方差与智体性能方差难以区分。右侧分支——驾驭耦合——在架构上最为重要：它展示驾驭设计选择（上下文管理策略、工具注册表组成、状态持久性语义）如何与智体行为交互，从而产生性能指标，这些指标是（智体，驾驭）组合的属性，而不仅仅是智体的属性。分支之间的箭头表示跨原因交互：系统耦合会放大环境漂移的影响（具有更佳环境状态验证的系统可以检测并补偿漂移），而上下文管理策略会与任务规范的模糊性相互作用（保留更多任务上下文的系统有助于智体从模糊的规范中恢复）。该图说明为什么单一原因解决方案——仅修复环境漂移或仅提高规范清晰度——会导致剩余的测量无效性，而这种无效性可归因于其他原因。

隔离机制设计空间

当代的驾驭部署五种不同的隔离架构，每种架构都代表安全强度和运维开销之间的不同权衡：Firecracker 微型虚拟机通过专门针对最低客户操作系统要求，实现硬件级隔离，其启动延迟可与 Docker 容器相媲美。BrowserUse 基于 Unikraft 的微型虚拟机更进一步，实现浏览器自动化智体亚秒级冷启动（BrowserUse，2026）。

了解哪些攻击向量利用哪些安全驾驭组件是进行合理驾驭安全设计的前提。下表 6 （安全威胁矩阵）将智体驾驭文献中确定的七种主要攻击类型与其入口点、利用的驾驭组件、持久性特征以及可用的驾驭-级缓解措施进行映射。

为什么容器隔离在结构上不足

Docker 容器在智体执行中的广泛应用更多地反映了工程上的便利性，而非安全性的充分性。容器隔离本质上是命名空间分离；智体仍然运行在宿主机内核上，一个容器中的内核漏洞会危及宿主机和所有容器的安全。Sandbox-EscapeBench（Marchand，arXiv:2603.02277，2026）提供初步的经验证据，表明 GPT-4 类模型似乎能够利用容器配置错误——如果这一发现得到证实，则意味着基于 Docker 的隔离仅适用于在非敏感数据上运行的可信智体。

驾驭-级的防御架构

鉴于完美的隔离要么成本过高，要么根本无法实现，驾驭安全（harness security）需要纵深防御。当前最先进的驾驭在四个方面实现分层防御：执行前能力限制（SWE-agent 的 ACIface 模型、OpenClaw 的显式权限授予）；执行中策略执行（TrustAgent 的双模型架构，其中策略模型在执行前评估提议的操作）；执行后审计和回展（Harbor 的完整执行跟踪和快照/恢复支持）；以及针对高风险操作的架构人机交互要求（PortiaAI 的检查点系统）。实践规模的生产级驾驭贡献一系列环境设计模式，其治理意义从三个方面扩展学术文献。 Stripe 为 Minions 系统设计的开发环境将执行环境视为一种策略工具：每个智体任务都会获得一个独立的开发环境，该环境从预热池中可在十秒内启动，从而确保并发智体任务之间不会共享状态——这一特性由该驾驭从架构层面强制执行，而非依赖智体的判断来避免状态污染（Gray，2026）。此外，该驾驭还强制执行最多两轮持续集成 (CI) 后才会升级到人工审核，从而将原本可能被视为模型层面的重试启发式方法转化为具有确定性强制执行的驾驭层面策略。这种架构强制执行模式——将原本可以委托给模型判断的限制编码到驾驭中——体现以下原则：大规模可靠性需要行为保证，而模型在没有基础设施支持的情况下无法提供这些保证。 Cursor 对用于自主编码的多智体架构进行迭代开发，提供一种互补的模式：从共享状态协调，到规划器-执行器-工作者-判断器层级结构，再到递归的规划器-工作者模型，连续的设计迭代揭示的是架构设计缺陷，而非模型能力限制（Cursor，2026）。观察发现，由于锁争用（lock contention），20 个同时运行的智体在采用简单的共享状态协调时，吞吐量会下降到 1 到 3 个智体的水平；执行器角色过载会导致病态行为，包括过早的任务请求和虚假的睡眠周期。这些观察表明，执行环境的结构特性——隔离边界、角色分离、通信拓扑——是多智体系统行为的首要决定因素，而非模型层面的问题。

提示注入：详细分类

提示注入攻击类别值得详细分解，因为它是实际应用最广泛的驾驭-级漏洞，也是现有文献中实证数据最丰富的漏洞。本文区分四种结构变体，每种变体都有不同的入口点和不同的驾驭级缓解措施。

直接提示注入（Perez & Ribeiro，2022）是指恶意用户直接提供覆盖系统指令的输入。这是最简单的变体，也是最容易通过输入清理和在 C 组件中强制执行指令层级结构来缓解的变体。在驾驭层面，缓解措施很简单：系统提示不应与用户输入连接，从而防止用户内容覆盖特权指令。

通过外部内容的间接提示注入（Greshake，2023）是指智体检索或处理包含重定向智体目标指令的外部内容（例如网页、文档、API 响应）。这种变体利用检索增强型智体的基本设计：智体被设计为遵循其上下文中的指令，而外部内容被设计为包含在上下文中。驾驭级缓解措施需要区分指令类内容（模型应解释为指令的内容）和数据类内容（模型应视为推理信息的内容）。目前的驾驭并未强制执行这种区分；这需要在C组件中正式定义指令/数据边界，并添加运行时强制执行机制，在上下文注入之前用其类别标记检索的内容。

工具介导注入是一种复合攻击模式，攻击者将恶意指令嵌入到工具的输出中，这些指令会持续存在于后续的上下文窗口中，并最终重定向智体的工具调用序列。这种模式在执行周期较长的多步骤智体中尤其危险：在步骤 3 中注入的恶意指令可能要到步骤 47 才会执行，此时智体已通过先前合法的工具调用积累足够的能力，可以采取高影响的操作。驾驭级缓解措施需要结合工具输出验证（L 组件）和上下文溯源跟踪（C 组件）：上下文的每个片段都应携带指示其来源（工具调用、用户输入、系统提示、检索结果）的元数据，以便可以根据下游模型调用所接收指令的来源对其进行约束。

通过长期存储进行内存投毒利用 S 组件的持久内存注入跨会话存在的恶意内容。攻击者如果能够使智体通过上述三种变体中的任何一种将恶意指令写入其长期内存存储，就会创建一个持久通道，允许攻击在无需任何后续外部输入的情况下跨会话边界重新触发。这种变体最为复杂，但实证研究却最少。该驾驭级缓解措施需要在写入时进行内存内容验证（对 S 组件写入进行 L 组件验证），并结合能够检测和隔离持久存储中注入内容的清理步骤——目前没有任何生产框架实现此功能。

根本原因分析：安全问题为何悬而未决

智体驾驭中的安全问题持续存在，并非因为缺乏解决方案，而是因为四个结构性矛盾阻碍了问题的彻底解决。能力与安全性之间的权衡至关重要：智体的实用性需要广泛访问外部系统，而安全性则需要限制访问权限，并且不存在帕累托最优解——正确的平衡点取决于具体任务，目前只能依靠临时判断来确定。动态代码生成使得静态分析成为不可能：智体会根据预先未知的环境状态生成代码，而运行时监控生成的代码既耗费计算资源又难以理解。由于缺乏驾驭级别的正式安全模型，与密码学或分布式系统不同，目前没有框架（framework）可以证明驾驭配置能够抵御特定威胁模型的攻击——只能依靠经验观察，即它尚未以已知的方式失效。最后，经济上的不利因素促使人们倾向于采用较弱的隔离：强隔离会增加延迟和操作复杂性，而安全收益是长期的且具有概率性的。如果没有监管或市场压力，平衡点往往会倾向于 Docker 的便利性而非微型虚拟机的安全性。

执行环境作为策略实现层

智体驾驭必须针对特定的威胁概况实现纵深防御架构。探讨一个逻辑上更优先的问题：执行环境本身必须具备哪些属性，才能使驾驭的安全性和可靠性策略得以有效执行？如果驾驭指定了策略，但没有相应的环境来实现该策略，那么它就无法约束智体的行为——它只是记录了一个底层系统可能执行也可能不执行的意图。环境设计即是策略实现，其故障模式即是驾驭的故障模式。

工具生命周期钩子（L组件）和工具注册表（T组件）对智体程序运行所遵循的策略进行编码：例如，可以写入哪些文件系统路径、可以访问哪些网络目标以及单次工具调用可以运行多长时间。然而，策略编码和策略执行是两个不同的功能，它们之间存在架构边界。执行环境是策略编码后执行或静默失效的层：例如，一个驾驭指定“禁止访问外部IP地址”，但如果智体程序代码运行在具有不受限制的桥接网络的Docker容器中，则该策略并未得到执行。

环境状态管理作为驾驭可靠性功能

除非驾驭的执行环境能够在每次测试之间可靠地初始化、快照、重置和销毁，否则它无法提供可复现的智体行为。当环境状态因文件系统累积、依赖项更新或外部服务变更而在不同运行之间发生漂移时，基准测试结果将无法进行时间上的比较，而看似模型效应的差异实际上是环境状态效应。

两个独立的测量结果证实该问题的实际严重性。对 OSWorld 部署的社区分析表明，由于环境状态管理失败，导致的假阴性率约为 28%——即行为正确的智体由于环境状态与预期配置不符而未能通过评估（Xie，2024；Kang，2025）。 HAL（Kapoor，ICLR 2026）提供补充性发现：在 21,730 次部署中标准化评估驾驭消除“常见实现错误”，这意味着环境状态故障系统性地推高先前评估中的故障率。因此，环境状态管理是评估驾驭故障的首要原因，其影响程度与现场归因于模型差异的性能变化相当。

代码执行环境作为驾驭组件

对于主要动作机制为代码生成的智体而言，交互式解释器并非仅仅是 T 组件中的一个工具，而是将模型生成的文本转换为执行环境状态变更的驾驭组件。其状态性和开放性使其难以通过执行前的静态分析进行分析。

CodeAct（Wang，ICML 2024）在 17 个 Mint 基准测试中证实，代码-即-动作在性能上优于离散的结构化工具调用，同时减少约 20% 的交互轮次。这意味着 CodeAct 式智体需要解释器状态持久性、多轮执行反馈以及动态库导入——而这些功能是无状态沙箱执行器所无法提供的。性能优势和更强的架构要求密不可分。 InterCode（Yang，NeurIPS 2023）通过将交互式编码环境标准化为一个具有明确 API 的框架抽象来解决这个问题，该 API 用于容器初始化、动作分发、stdout/stderr 捕获、奖励计算和回合重置——这是一个 SWE-bench 扩展的参考设计。

SandboxEscapeBench 与容器隔离的局限性：扩展分析

SandboxEscapeBench（arXiv:2603.02277，2026）的经验和结构性影响值得进一步探讨，因为它们对安全套接字部署策略至关重要。在初步实验中，获得 shell 访问权限的前沿 LLM 似乎能够利用容器配置错误，权限提升成功率约为 15% 至 35%，具体取决于配置。这些数据需要独立重复验证，才能确定具体的范围。然而，命名空间隔离的结构分析独立地支持架构结论——基于 Docker 的隔离提供的保证比通常假设的要弱。

文献中正在形成的驾驭级响应具有共同的架构。 Agent-Bound（arXiv:2510.21236，2025）将MCP服务器声明的权限清单视为权威的安全边界，在协议层强制执行访问控制。AEGIS（arXiv:2603.12621，2026）将其实现为一个与框架无关的执行前拦截层——一个包含参数提取、风险评分和策略执行三个阶段的管道，用于在潜在危险的工具调用到达执行环境之前将其拦截。Securing MCP分析（arXiv:2511.20920，2025）记录相应的协议级威胁面，并提出了将MCP信任边界作为主要安全边界的治理控制措施。

如图15 所示隔离机制设计空间：五种机制按启动延迟与隔离强度排序，内存开销作为隔离气泡大小。SandboxEscapeBench（Marchand，2026）在 Docker 区域标注逃逸风险。

3. 评估和基准

如表 7 所示智体基准测试概览。按领域、任务数量、框架要求和主要评估指标比较的代表性基准测试。

如表 8 所示基准驾驭的基础设施要求。按组件列出可靠运行每个基准所需的最低驾驭功能。

4 协议和接口标准化

如图 17所示：协议互操作性权衡（MCP、A2A 和专有协议）。该散点图的坐标轴分别代表：(1) 标准化压力（x 轴：遵循该协议的独立实现数量）；(2) 表达能力与简洁性之间的权衡（y 轴：协议能否在无需额外协议的情况下表示所有必要的工具语义）。每个协议都用一个点表示，圆的半径代表其采用率。MCP 处于高标准化程度 + 中等表达能力（专为较窄的生态系统设计），A2A 处于低标准化程度 + 高表达能力（专为完整的语义保真度设计），而专有协议则分散在图中。箭头表示演进压力：随着标准化程度的提高，系统向右移动；随着实践者发现表达能力方面的不足，系统向上移动。该图阐明“最佳协议”取决于用例：MCP 擅长生态系统标准化，而 A2A 擅长语义完整性，最佳选择反映了给定系统优先考虑的维度。

。。。。。。待续。。。。。。