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）在很大程度上仍未得到研究。

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

---

第二类主要挑战在于驾驭如何管理持久状态、上下文知识以及智体可用的工具生态系统。这三个功能——跨执行步骤维护状态、动态选择和检索相关上下文以及控制智能体可以调用哪些工具——是驾驭为模型实例化连贯执行上下文的主要手段。当这些功能协同工作时，智体会到一个稳定、可导航的环境，其中先前的决策至关重要，未来的行动受到当前状态的约束。当它们运行不佳时，智体将面临一个混乱的上下文窗口，导致先前任务信息泄露、在关键时刻丢失相关细节，并且提供的工具访问权限要么过宽（造成安全风险），要么过窄（阻碍任务完成）。

1.运行时上下文管理

上下文窗口瓶颈

上下文窗口大小是长时程智体任务中最明显的限制，但这并非根本问题——根本问题在于，简单地累积交互历史是对可用空间的低效利用，并且选择保留、压缩或从上下文中移除哪些内容会产生远超性能范围的影响。保留所有内容的上下文管理器将面临二次方增长的token成本；过于激进地丢弃内容的上下文管理器会失去区分功能型智体和无状态自动补全系统的连续性；而保留错误内容（特别是来自先前回合的被篡改或污染的内容）的上下文管理器则会造成贯穿整个任务执行过程的安全漏洞。该设计空间对应于 V 组件设计空间，其中上下文管理决定 E 组件状态转换的可观测性：保留完整历史记录的 C 组件可提供完全的状态可观测性，但代价是二次方级的；而过度压缩的 C 组件则会降低可观测性，并可能掩盖 L 组件旨在检测的安全关键状态损坏。

SkillsBench（Li，2026）从另一个角度量化基础设施对有效能力的贡献：精心策划的技能（在驾驭层集成的结构化程序知识包）使 11 个领域 86 项任务的平均通过率提高 16.2 个百分点。这种改进并非来自模型本身的能力，而是来自驾驭在推理时提供给模型的信息。包含 2-3 个模块的聚焦技能优于全面的文档这一发现，揭示一个普遍原则：驾驭的上下文管理功能并非被动的中继，而是一个主动的认知过滤器，其设计决策决定模型能够完成的任务。这与引入的 C 组件设计空间相对应：上下文管理器决定模型在每个步骤中可以推理的事件和状态观察的有效字母表 Σ_visible；暴露完整字母表 Σ 的 C 组件会使模型的推理能力不堪重负，而将 Σ_visible 限制为与任务相关的符号的 C 组件可以提高推理质量，这表明上下文管理在 LTS 事件空间中本质上是一个压缩问题。

如图 18 所示上下文管理策略谱系：根据信息保留与每轮计算成本的比例划分的五种方法，每个区域都对应代表性的系统和C组件实现水平。

上下文管理策略对比

如表 11.所示上下文管理策略对比。从机制、保留行为、计算成本和代表性系统四个方面对五种策略进行了对比。

关键系统和实证结果

MemGPT（Packer，NeurIPS 2023）引入受操作系统启发的虚拟上下文管理，在上下文窗口（“RAM”）和外部存储（“磁盘”）之间进行显式分页。这种架构预示现代驾驭利用设计，并且仍是当前最强大的C组件实现。MemAct（arXiv:2510.12635, 2025）将工作记忆管理视为一种可学习的策略——智体通过记忆操作（写入、删除、更新）主动编辑上下文——证明上下文管理可以优化，而不仅仅是启发式。CORAL为网络智体提供显式的驾驭管理和上下文优化工具。Zep的时序知识图谱报告显示，在长时任务上，准确率提高18.5%，同时延迟降低90%。
SkillsBench的研究发现，自我生成的技能并不能带来平均收益——“模型无法可靠地创作出它们从消费中受益的程序性知识”——这对工具设计具有直接影响：S组件（状态存储）不能依赖智体来生成自己的可重用技能表示。工具必须从外部精选技能，或者在自我生成的技能候选者进入持久存储之前，实施验证和过滤机制。

一种互补的模型级机制是Self-RAG（Asai，ICLR 2024），它使模型能够有选择地检索和评判外部上下文，而不是被动地接受检索管道提供的任何内容。从驾驭（harness）的角度来看，Self-RAG代表C组件选择功能从驾驭到模型本身的部分转移：模型不再完全依赖驾驭级的检索策略来确定哪些内容进入上下文，而是通过其反思tokens参与管理。因此，集成Self-RAG风格模型的驾驭必须调整其上下文管理策略——当模型能够主动请求或拒绝检索内容时，最优的驾驭策略（harness policy）会发生变化。

长上下文模型与不断演进的C组件设计空间

一种显著改变上下文管理问题的发展趋势——但几乎未受到任何系统级分析——是超长上下文模型的出现。Gemini 1.5和1.0 Pro提供了100万个tokens的上下文窗口；最近的迭代版则进一步扩展这一能力。一种天真的解释是，长上下文模型解决C组件问题：如果上下文窗口足够大，能够容纳整个任务的交互历史，那么压缩、检索和优先级策略或许就不再必要。但这种解释在实证上是错误的，在架构上也是危险的。反对这一解释的实证证据十分有力：注意力稀释现象——即处理超长上下文的模型随着序列长度的增加，对早期上下文的有效注意力会下降——由Liu（“Lost in the Middle”，arXiv:2307.03172，2023）提出，他们证明语言模型在长上下文的中部或早期部分放置的信息利用不足。HAL的评估基础设施（Kapoor，2026）提供确凿的基础设施证据：在HAL的长上下文部署中，模型在21,730次部署的部署规模上表现出相同的退化模式，这产生一个悖论：一个具有100万个tokens窗口的模型在处理长序列开头附近的信息时，其表现可能不如一个以固定间隔对信息进行总结和重新注入的模型。AgencyBench（Li，2026）直接记录这一点：每次执行需要100万个tokens的任务时，模型成功整合的信息存在显著差异，这表明原始上下文容量并不能线性转化为有效的信息访问。这一架构含义是，长上下文模型改变C组件的设计问题，而非消除它。在短上下文窗口中，主要挑战是保留——在空间稀缺时决定保留什么。在长上下文窗口中，主要挑战是显著性——在模型的有效注意成为稀缺资源时决定突出什么。这一转变要求C组件策略与压缩策略有本质上的不同：结构化注意力锚点，将高优先级信息放置在模型注意力实证上最强的位置； 层次化上下文组织，将相关信息分组，使检索模式与模型的注意力分布相匹配；以及主动冗余——以固定间隔策略性重复关键任务状态——而非短上下文利用所采用的激进去重。SkillsBench的研究发现，包含2-3个模块的聚焦技能优于全面文档（Li，2026），这一发现可推广到此设置：在超长上下文利用中，C组件的角色从守门人转变为架构师——不是阻止信息进入上下文，而是对其进行组织，使模型的注意力能够可靠地指向重要内容。

检索增强型上下文管理：架构与局限性

检索增强型上下文管理模式——存储所有交互历史并在每一步检索相关子集——已成为长时智体的主流方法，这主要是因为它在实现有限大小的上下文窗口的同时，避免摘要中固有的信息丢失。然而，检索增强型系统引入一系列与更简单的保留策略不同的故障模式，这些故障模式是特定于硬件层面的关注点，而非模型层面的关注点。

检索延迟注入。长时任务的每个步骤在模型推理开始之前，都需要对已存储的历史数据进行检索查询。对于一个包含100个步骤、每步检索延迟为500毫秒的任务而言，检索开销占总任务时间的50秒——这在任务预算中占据了不小的比例，并且会随着任务长度的增加而线性增加。大规模语义检索（涉及10,000多个已存储片段）需要向量数据库后端；向量索引的冷启动延迟进一步增加了开销。驾驭（harness）必须通过索引预热、近似最近邻搜索权衡以及检索结果缓存来管理这种延迟，以避免在连续步骤中对相同上下文进行冗余查询。

检索相关性下降。随着交互历史的增长，检索结果的信噪比降低：潜在相关的历史内容数量增加，而模型用于检索的查询精度保持不变。一个从100个片段的历史中返回5个最相关片段的检索查询，在应用于1000个片段的历史时，可能会返回质量低得多的结果，因为与真正相关片段竞争的边缘相关片段的绝对数量增加了10倍。通过分层检索（保持旧历史的摘要，同时逐字存储最近的历史），驾驭（harness）可以部分弥补这一问题，但分层策略的设计是一个研究问题，尚无共识解决方案。

通过对抗性内容进行检索游戏。攻击者若能将内容引入智体的存储历史中，便可制作出针对检索优化的内容——即与预期未来查询语义相似度最高的内容——以确保在可能影响后续行动的情境中，对抗性指令能被高优先级检索到。这种攻击变体要求工具保持抗检索存储：根据来源隔离内容，并根据内容的可信度（而不仅仅是语义相似度）对检索分数进行加权。目前尚无生产工具实现检索来源加权。

查询构建质量依赖性。检索增强上下文管理的质量，关键取决于驾驭（harness）构建检索查询的能力，这些查询需在每一步都能准确捕捉模型的信息需求。当前的驾驭通常根据用户任务描述（所有步骤固定，不考虑当前执行状态）或模型最新输出（可变，但可能存在噪声或误导）来生成检索查询。这两种方法均无法可靠捕捉到在每个特定步骤中，历史上下文将是最有益的。将查询构建作为驾驭-级功能的研究尚处于起步阶段，而非将其委托给模型，其中MemAct的“记忆-即-行动”方法是目前最具原则性的处理方法。

根本原因：上下文管理为何仍未解决

上下文管理仍未解决，因为最优策略具有任务依赖性，且无法预先指定：软件工程任务应保留的内容与研究任务或调度任务应保留的内容不同。在配置时，驾驭无法知道哪些信息在后续执行中会证明是相关的。这种根本的不确定性推动了检索增强方法的出现，该方法将选择决策推迟到查询时——但代价是依赖于检索质量，而检索质量本身也是一个研究问题。长上下文模型的出现又增加了一个维度：最优C组件设计不仅具有任务依赖性，还具有模型依赖性，且其特征尚未通过实证研究得出。安全维度进一步增加了难度：驾驭不能简单地保留所有看似相关的内容，因为一些看似相关的内容可能是被恶意设计以持续存在的——这种风险随着上下文窗口大小的增加而增加。

DeepAgents：通过中间件架构进行上下文工程

LangChain的DeepAgents（LangChain，2026）提供了一个生产演示，展示了作为独立于模型更改的离散工程问题，上下文管理改进的效果。在保持底层模型不变的情况下，DeepAgents在TerminalBench 2.0上的性能从52.8%提高到66.5%（提高了26%），这有力地证明了仅通过上下文工程就能获得与模型升级相当的性能提升。

DeepAgents通过基于中间件的架构实现上下文管理，其中包含三项关键的C组件创新。首先，系统提示工程用于自我验证：系统提示经过重新设计，以强调明确的验证循环，鼓励智体在声称完成之前测试自己的代码。此中间件挂钩在系统级别运行，塑造模型在整个执行过程中的关注点。其次，LocalContextMiddleware用于结构化上下文注入：DeepAgents不是将工具结果作为字符串进行拼接，而是通过一个中间件层对信息进行整理、过滤和总结，然后将其注入到上下文窗口中。上下文不仅仅是检索出来的；它是在驾驭级别上经过主动设计的，以引导智体形成高效的推理模式。第三，生命周期挂钩用于故障检测：中间件挂钩检测故障模式——例如“写-读-停”综合症，即智体生成代码、读回代码、判断其看起来正确，然后停止而不进行测试。通过在这些生命周期点上设置工具，DeepAgents可以防止智体在这些故障模式传播到下一个执行步骤之前进入这些故障模式。

实证影响是显著的：DeepAgents识别出基于智体的代码编写中的一种核心失败模式：智体编写代码，重新阅读后认为代码看起来正确，便终止而不进行测试。这种失败模式并非模型能力上的限制，而是上下文管理失败，即驾驭（harness）未能创造条件，在终止前强制进行测试。通过实现中间件钩子，在代码完成前强制执行验证，DeepAgents彻底消除这一类失败。因此，从52.8%提高到66.5%代表着纯粹的驾驭层治理质量的提升——这证明，通过结构化中间件进行上下文管理与当前前沿的任何模型升级一样具有影响力。DeepAgents的开源架构表明，这些改进是可重复且可采用的：相同的中间件组件可以集成到任何实现L组件钩子模型的驾驭中。
2. 工具使用作为核心驾驭功能
工具注册表作为治理（governance）对象
工具使用是智体作用于世界的主要机制，因此工具注册表——驾驭系统的T组件——是智体行为的主要治理点。Qu（2024）提出的四阶段工具学习工作流程——任务规划、工具选择、工具调用和响应生成——描述驾驭在每个阶段所介导的过程。驾驭维护一个注册表，该注册表限制哪些工具可用（第2阶段），在执行前验证调用（第3阶段），处理错误和重试（第3阶段），以及管理结果的上下文整合（第4阶段）。带薄弱T组件治理的驾驭——工具目录过于宽泛、缺乏模式验证或无重试逻辑——会导致系统可靠性降低，并且安全性也会降低。

AgencyBench（Li，2026）最有力地证明工具治理在驾驭层的实证案例。其研究发现，当通过Claude-Agent-SDK运行时，Claude-4.5-Opus的表现最佳，这主要不是关于模型质量的发现，而是关于工具调用偏好和模型-驾驭（model-harness）协同优化的发现。该论文观察到“模型在资源效率、反馈驱动的自我纠正和特定工具使用偏好方面存在显著差异”——这些差异在没有跨驾驭（cross - harness）评估的情况下是看不见的。这表明，当前独立开发工具和模型，然后在部署时进行集成的做法可能系统性地存在次优性：工具注册表的模式、排序和错误行为与模型的学习行为相互作用，在AgencyBench评估的90步任务范围内产生复合效应。

工具台生态系统与大规模工具学习

从Toolformer（Schick，NeurIPS 2023）到Gorilla（Patil，2023）再到ToolLLM（Qin，ICLR 2024），这一发展过程代表工具调用能力所在位置的演变：从通过自监督训练学习何时调用工具的模型（Toolformer），到在调用前检索适当API文档的模型（Gorilla），再到在16,000多个真实世界API上训练、具有驾驭-管理工作流规划功能的模型（ToolLLM）。每一步都将部分能力负担从模型转移到驾驭（harness）：Toolformer将工具选择逻辑嵌入模型权重中；Gorilla将API文档检索外部化为驾驭必须管理的检索系统；ToolLLM需要一个驾驭端的工作流规划器（基于深度优先搜索的深度优先搜索树）来分解多步工具序列。驾驭的含义在于，模型端的学习和驾驭端的基础设施不是替代关系，而是互补关系：如果驾驭无法提供检索服务，那么训练为使用Gorilla检索接口的模型将无法正常运行；如果驾驭省略规划功能，那么训练为使用ToolLLM工作流规划器的模型也无法替代自己的规划功能。该生态系统在注册表规模治理方面的含义——驾驭如何管理如此大规模目录中的工具选择、模式验证和错误处理——进行分析。

另外三个系统进一步强化工具执行对驾驭的影响。CodeAct（Wang，2024）用可执行的Python代码取代了离散的工具调用序列作为统一动作空间：智体不是从固定的工具目录中选择，而是动态生成组合工具调用的代码，通过Python解释器状态整合结果。CodeAct在17个Mint基准测试上的表现优于离散动作替代方案，且交互轮次减少了20%，这表明选择代码-即-动作还是离散-工具-调用-即-动作是一个一阶T组件设计决策，而非模型能力问题。GoEX（Patil，2024）解决人类对工具执行进行监督这一互补问题：其Gorilla执行引擎设计允许人类通过事后验证高效地验证、批准或回展（rollback）工具动作，而不是阻塞批准流程，从而在保持有意义的人类监督的同时赋予智能体更高的自主性。GoEX的设计与L组件（生命周期钩子）直接相关，作为人类在环检查点的非阻塞替代方案。ToolSandbox（Lu，2024）通过专注于有状态的、多轮工具执行来补充ToolBench：通过跟踪对话轮次中的工具状态持久性并建模隐式工具间依赖关系（其中一个工具的输出会影响另一个工具的有效输入），ToolSandbox揭示了驾驭组件必须将工具状态作为连贯的运行时对象来管理，而不是将每个工具调用视为无状态的。

技能库作为S-T组件集成

Voyager（Wang，2023）引入一个不断增长的技能库——智体可在会话期间添加和检索的复杂行为的可执行代码。这种架构代表T和S组件的集成：技能库既是持久状态存储（S），也是扩展工具注册表（T），使智体能够通过经验积累新工具，而不是在配置时接收固定目录。SkillsBench的研究发现，具有2-3个模块的、经过精心筛选的技能优于全面的文档和自生成技能，这表明这种集成的设计至关重要：如果引入降低选择质量的噪声，那么更多的能力并不一定更好。

工具注册表设计模式：结构化比较

随着MCP作为标准化层以及关于工具调用可靠性的实证文献的成熟，工具注册表的设计空间已显著扩大。存在五种注册表设计模式，这些模式在可靠性、安全性、灵活性和成本等维度上体现了不同的权衡。

模式1：静态声明式注册表。该驾驭维护一组固定的、预先声明的工具，其模式在驾驭初始化时注册。在任务执行期间，工具不能被添加或删除。此模式提供最大的模式稳定性（驾驭可以在初始化时验证所有可能的工具调用，而不是在调用时验证）、最小的攻击面（无动态扩展意味着不会注入恶意工具定义）和确定性的成本建模（工具目录是固定的，能够预先计算工具描述的预期token成本）。此模式的局限性在于其刚性：如果任务需要部署者在配置时未预料到的工具，则无法完成，并且必须重新启动驾驭以更新工具目录。

模式2：具有模式验证的动态工具注册。该驾驭允许在运行时注册工具，但必须根据已定义的工具规范格式（通常是JSON Schema或OpenAPI格式）进行模式验证。新工具在添加到注册表之前必须通过模式验证；验证步骤是一个L-组件函数，用于控制T组件的注册。此模式以动态攻击面为代价实现了灵活的能力扩展：任何可以提交工具注册请求的代码路径都可能注入一个通过形式验证但具有危险运行时行为的恶意工具。MCP的工具注册机制遵循此模式，其中基于OAuth的注册实体身份验证是主要的安全控制手段。

模式3：能力范围注册表。工具被组织到能力范围（文件访问、网络访问、代码执行、外部API访问）中，并在会话或任务级别明确授予范围。需要网络访问的任务必须声明该范围；超出声明范围的工具即使存在于底层注册表中，对模型而言也是不可见的。此模式是API访问中OAuth范围的智体类比：它将有效攻击面限制为仅与当前任务相关的工具。SWE-agent的ACIface模型遵循此模式，仅暴露适用于软件工程任务的受限外壳接口，而不是底层工具架中可用的完整工具目录。

模式4：语义搜索注册表。对于大型工具目录（如Gorilla的1,600多个API，ToolBench的16,000多个API），在系统提示中枚举可用工具是不可行的——仅描述就会使上下文窗口满屏。语义搜索注册表模式通过将工具选择视为检索问题来解决这一问题：模型发出所需工具的自然语言描述，然后工具管理框架从向量索引目录中检索语义相关的工具。Gorilla（Patil，2023）证明，检索增强型工具选择可大幅减少API参数中的幻觉，从而验证该模式的可靠性优势。驾驭的含义是，T组件必须在工具描述上维护一个向量索引，实现语义搜索API，并在每一步管理分配给检索工具描述的上下文预算。

模式5：学习式工具规划。ToolLLM（Qin，2024）引入一种深度优先搜索决策树（DFSDT）策略，在该策略中，驾驭（harness）主动协助模型规划工具调用序列，扩展有前景的工具调用路径，并从死路中回溯。此模式将工具规划视为驾驭层的功能，而非完全委托给模型：驾驭维护一个候选工具调用序列的搜索树，评估其结果，并向模型提供经过筛选的建议，而非原始的工具访问权限。在ToolBench的复杂多步任务上，该模式的表现显著优于贪婪工具选择，这表明在驾驭层进行系统化的工具规划是一种具有可衡量可靠性优势的一流设计选择。

这五种模式并非相互排斥：生产中的驾驭可能会使用静态声明式注册表来管理高安全性的核心功能，使用功能范围注册表来管理特定任务的工具授权，并使用语义搜索索引来管理扩展的功能目录。驾驭设计的关键决策在于确定哪种模式适用于管理哪类工具，而答案取决于特定部署环境在安全性、灵活性和成本方面所需的权衡。

关键的驾驭设计问题

AutoHarness（Lou，arXiv:2603.03329，2026）证明，约束执行无需手工编写：语言模型可以自动合成一个代码约束，以防止智体进行非法操作。在Kaggle GameArena国际象棋比赛中，Gemini-2.5-Flash的78%的失败归因于非法走法——这一失败模式完全归因于缺乏约束级别的动作验证。AutoHarness将约束生成形式化为程序空间上的搜索问题，使用汤普森采样引导的树搜索，根据环境反馈迭代优化候选约束。由此自动合成的约束消除了145场TextArena游戏中的所有非法走法，使较小的模型（Gemini-2.5-Flash）仅通过约束质量就优于较大的模型（Gemini-2.5-Pro）——这一结果直接证实了本综述中的“约束绑定”论点。约束治理的意义重大：如果约束逻辑可以合成而非手工编码，那么T组件的动作验证层就变成了一个可学习的函数，而非静态的工程产物，从而开辟了一个设计空间，使得约束质量随着约束搜索中的计算投入而提升，而非随着人工工程努力而提升。

与驾驭兼容的模型训练与微调

驾驭-模型耦合问题中一个未被充分研究的问题是，模型最初是如何变得与驾驭兼容的。AgentTuning（Zeng，2023）表明，对智体交互轨迹（特别是从涵盖工具使用、编码、游戏玩法和网页导航等多种驾驭环境中采样的轨迹）进行指令调优，可以生成更可靠地泛化到新驾驭配置的模型。这对驾驭设计具有双向影响：正如驾驭架构应考虑模型能力（如AgencyBench所示），模型微调也应考虑目标驾驭的操作特性。例如，一个能够展示工具故障（tool failure）详细错误信息的工具，可以使在AgentTuning式轨迹上微调的模型表现出“反馈驱动的自我纠正”能力，而AgencyBench认为这是高性能配置与低性能配置之间的关键区别。这为缩小驾驭-模型耦合差距指明了一个原则性方向：标准化驾驭交互轨迹，使其作为微调语料库，使模型与定义的驾驭API的兼容性成为一种可训练的特性，而非一种自然涌现的特性。

根本原因：缺乏标准的工具治理

工具治理问题之所以持续存在，是因为该领域缺乏一个正式的模型来推理工具权限的组合。虽然可以评估单个工具的安全性属性，但工具组合会产生从组件中无法预测的新兴能力。在没有组合安全模型的情况下，驾驭设计者必须依赖经验测试，而经验测试的规模与目录大小不成比例。AgencyBench发现，在专有生态系统中，模型与驾驭的协同优化是隐式发生的，这表明这种治理问题正在针对特定的模型-驾驭对得到解决，但并非以可转移的方式；该领域需要一种与模型无关的工具注册治理原则性方法。

针对工具增强智体的运行时安全挑战，架构上最为完备的应对方案是OpenClaw PRISM（Li，arXiv:2603.11853, 2026）。PRISM是一个零分叉运行时安全层，它将执行分散到十个生命周期钩子中：消息入口、提示构建、工具执行、工具结果持久化、出站消息传递、子智体生成和网关启动。PRISM的设计体现了核心见解，即智体安全不能简化为单一的边界检查。与传统的输入-输出过滤不同，后者在面向用户的边界检查文本，而PRISM则部署了一个混合启发式加大语言模型（LLM）的扫描管道，该管道使用基于TTL的衰减机制进行会话和会话范围内的风险累积——这意味着低级别的可疑信号可以在触发执行前在多个回合中累积，而无需任何单一事件达到静态阈值。策略控制管理工具访问、文件路径、私有网络访问、域层级和出站秘密模式，具有可热重载的策略管理和防篡改审计日志记录功能。零分叉架构——无需修改宿主框架即可作为进程内插件实现——本身就是一个贡献：它解决了部署问题，该问题历来导致智体运行时的安全工具成为每次上游版本发布时的维护负担。PRISM代表了首个系统发布的、针对已部署开源智体驾驭（agent harness）的生产运行时安全解决方案，也是首个无需分叉宿主框架即可实现的生产运行时安全层，其评估方法——衡量安全有效性、误报率、层贡献、运行时开销和操作可恢复性——为未来驾驭安全（harness security）如何基准提供模板。

如图19所示工具治理生命周期流程：从注册到上下文集成的工具调用六个阶段，展示每个H组件的干预位置以及安全检查点执行策略的位置。

工具管理基础设施：作为治理组件的注册表

T组件的功能角色：注册表约束可用工具，模式验证保护调用形成，重试逻辑管理执行失败。从四个维度深入分析——将注册表本身视为治理对象，将工具故障视为一类驾驭级工程问题，将注册表视为攻击面，以及将MCP视为协议层解决方案，以解决之前每个驾驭的工程负担。
通过类比操作系统的系统调用表，可以更好地理解工具注册表：它定义了智体程序可以调用哪些功能、在什么条件下调用以及受到哪些约束。系统调用表不仅仅是查找结构，它们还是执行边界、审计点和权限提升的屏障。工具注册表若要构成真正的治理机制，而非仅作为无限制工具调用之上的便利层，则必须满足同样的要求。在LTS术语中，T组件注册表定义哪些转换t ∈T是允许的：有效工具调用的集合构成一个受限字母Σ_T ⊂ Σ，使得E组件的转换函数δ只能执行标有Σ_T中事件的状态转换，从而保持了安全性属性，即系统永远不会达到一个无法通过未经授权的工具执行来终止的状态。

MCP（模型上下文协议，Anthropic 2024）代表了该领域首次在协议层面对此接口进行标准化的认真尝试，将工具定义（以JSON Schema清单的形式表示）与工具实现（工具实现无需为工具架所知）分离。这种分离在架构上具有重要意义：工具架可以在不将其安全逻辑与每个工具的实现耦合的情况下，验证、界定和管理工具访问。先前的工作——ToolBench/ToolLLM（Qin，ICLR 2024）和API-Bank（Li，EMNLP 2023）——从实证角度探索了大规模工具管理的机制，但未实现协议层面的关注点分离。ToolBench的16,000多个API目录展示了工具架必须操作的规模：在如此庞大的数量级下，系统提示中的详尽枚举会占用上下文窗口，因此注册表必须支持语义搜索和预算检索作为一级功能。API-Bank的三级评估层次结构隐含地确定了三个独立的驾驭层功能：发现、验证和调度。

注册表设计是治理结果而非模型能力结果的最直接证据来自Vercel的从业者发现，移除80%的可用工具比任何模型升级更能提高任务成功率。AutoTool（Jia&Li，arXiv:2511.14650，2025）通过在推理时构建基于图的工具使用索引，将工具选择定位为治理端的数据结构，而非模型的职责，从而对此进行形式化。Schema First研究（Sigdel&Baral，arXiv:2603.13404，2026）提供对照实验证据：在治理注册边界进行严格的JSON Schema验证减少了接口级工具误用（格式错误的调用、模式违规），但并未提高任务成功率，在所有实验条件下任务成功率均为零。这一负面结果本身对治理设计具有启示意义：它表明模式验证解决了工具的语法治理问题，但不足以保证语义正确性，这表明额外的治理层机制——如预算性能约束（上下文预算、调用配额和延迟上限）——是结构化验证的必要补充。

作为驾驭级问题的工具故障

工具调用失败的方式各不相同：网络超时、模式错误、权限拒绝、执行异常、配额耗尽和依赖失败，每种失败类型都呈现出不同的恢复情况。PALADIN（Vuddanti，arXiv:2509.25238，2025）和SHIELDA（Zhou，arXiv:2508.07935，2025）各自得出的关键见解是，在模型参与恢复之前，必须先由治理工具对这些失败类型进行分类和调度。如果治理工具将原始的HTTP 503错误或Python回溯信息直接呈现给模型上下文，则相当于将分类问题委托给了一个智体，而该智体没有可靠依据来区分可恢复失败与不可恢复失败、配额耗尽与身份验证错误，或工具不可用与模式不匹配。SHIELDA通过一个涵盖四个主要类别的模块化异常分类法对此进行了形式化，并证明类型化的治理工具级异常处理程序在任务完成率上显著优于原始错误直通。PALADIN在此基础上扩展了三种结构化的恢复策略——带退避的重试、替代工具替换和优雅降级——每种策略均由分类后的异常类型触发，而非由模型判断触发。这两项独立工作的共同发现是，治理工具的异常处理设计对性能差异的解释程度高于模型大小，这一结果直接颠覆了该领域关于模型能力至上的隐含假设。

“The Hell or High Water”基准测试（Wang，arXiv:2508.11027，2025）通过系统地向智体工作流中注入外部故障，并评估10多种大语言模型（LLM）的恢复能力，提供直接的实证支持：当工具错误被驾驭吞没时，模型会悄无声息地失败，而恢复能力取决于驾驭级的错误信号设计，而不仅仅是模型智能。多智体设置使问题进一步复杂化。MAS-FIRE（arXiv:2602.19843，2026）展示一种故障级联动态，即一个智体驾驭中的工具故障，如果未得到正确分类和控制，就会以损坏观测的形式跨智体边界传播，导致下游智体因自身驾驭内不可见的原因而失败。这使工具故障处理从单智体工程问题提升为多智体协议设计问题：驾驭之间的接口必须将异常类型与工具结果一起传递，否则故障控制从结构上来说是不可能的。目前缺乏标准的工具异常接口——每个驾驭都实现自己的故障恢复逻辑，没有共享的类型、严重程度或可恢复性模式——这意味着无法对多驾驭部署进行基准测试，以比较异常处理质量。

工具安全：注册表作为攻击面

“策略优先”架构在PRISM安全层中得到生产实例化，该层将执行工作分布到三点模型中的十个生命周期钩子中。工具注册表的治理功能及其安全攻击面是同一架构事实的两面。由于注册表决定哪些工具定义能够进入模型上下文以及哪些调用能够被调度，因此注册表一旦被攻破，智体的整个行为范围都会受到影响。ToolHijacker（Shi，arXiv:2504.19793，2025）通过无盒攻击展示这一点，该攻击将恶意工具文档注入工具库，导致智体可靠地选择并执行有害工具，而无需其他任何工具链的妥协。该攻击正是利用 T组件的功能：任何执行语义匹配的工具链都会可靠地选择与常见请求模式相匹配的恶意定义。这是注册表的漏洞，而非模型的漏洞，其缓解措施需要在注册时进行驾驭级控制——加密溯源验证、沙盒化清单加载或信任评分源。

SkillFortify（arXiv:2603.00195, 2026）通过首次在Dolev-Yao攻击者模型下对智体技能供应链进行形式化处理，扩展这一分析，其提出一个集成持续集成/持续部署（CI/CD）的验证框架，并为技能清单确定六大威胁类别。恰当的表述是，工具注册表是一个需要正式认证的加密供应链，而非能力描述的便利店：加载工具定义而不进行来源验证，在结构上等同于安装软件包而不进行签名验证。Policy-First Control（ arXiv:2603.18059, 2026,）提出相应的防御架构——在生命周期的三个关键点（注册时的模式验证、调用时的沙盒执行和上下文集成前的输出验证）中，在L组件边界声明并执行工具策略。当前的生产驾驭（production harness）实现这些控制的子集；同行评审文献中未发现部署了实现所有这三个控制措施的工具。

MCP作为驾驭协议基础设施

MCP代表了工具管理基础设施组织方式的根本性架构转变，其结构上的转变类似于从每个应用程序的TCP/IP栈转变为共享的操作系统网络层。在MCP出现之前，工具注册表是具有不兼容模式、调度机制和发现方法的驾驭内人工构件（artifacts），使得集成成本随着驾驭-工具对数量的增加而增加。MCP的协议中介架构颠覆了这一点：作为具有标准JSON-RPC接口MCP服务器实现的工具，可以由任何兼容的驾驭调用，而无需自定义代码。工具注册表成为互操作性层，而不是私有数据结构。

这一转变并未消除治理问题；而是重新组织这些问题必须解决的领域。在MCP驾驭之前，模式验证、溯源验证和异常处理都是直接在驾驭（harness）内实现的。而在MCP生态系统中，这些功能必须在协议层面进行规范——否则，每个客户端都会实现各自不完整的版本，从而在更高的抽象层面上重现碎片化问题。MCP生产路线图（The New Stack，2026年3月）指出三个剩余的生产阻碍因素，这些因素恰好反映这一挑战：跨工具调用的有状态会话管理（目前会话是隐式无状态的）；协议层的身份验证和授权（OAuth对服务器进行身份验证，但针对每个工具的能力授权尚未标准化）；以及对长时间运行的工具操作的流支持（同步响应阻碍治理框架管理增量工具输出）。每一个都是驾驭-协议的协同设计问题，需要对MCP规范和驾驭T组件实现进行协调更改。IBM宣布2026年为智体协议标准化年——将MCP、A2A和ACP列为融合候选者——这表明工具注册表设计空间正在进入标准化阶段。对于驾驭研究而言，这创造了机遇：稳定的协议基础设施首次实现对T组件治理质量的跨驾驭评估。然而，风险在于过早封闭。多租户工具权限模型、驾驭-级结果缓存以及分布式工具调用跟踪的形式化可观察性标准仍是未解决的治理问题，而冻结的协议规范将使这些问题更难（而非更容易）追溯解决。

智体技能：超越工具-级协议的工作流级互操作性

作为对MCP工具-级标准化的补充，Anthropic Agent Skills（Anthropic，2025，开放标准）解决了不同层面的工具互操作性：即工作流和生命周期层面，而非工具调用层面。Agent Skills于2025年12月作为开放标准发布（agentskills.io），它规定了可重复使用、可移植的技能包，这些技能包教导智体如何执行特定的工作流。每个技能都是一个目录，其中包含一个SKILL.md规范文件、可执行脚本和资源文件，这些文件定义了智体可以获取并应用的一项独立能力。

智体技能通过在L组件（生命周期和工作流管理）而非T组件（工具注册表）上运行来扩展MCP的模型。MCP管理单个工具调用——“使用这些参数调用此API”——而智体技能则管理多步骤工作流——“这是一系列工具及其应用条件”。这创建一个自然的两层协议栈：MCP用于原子工具操作，智体技能用于组合工具工作流。Anthropic自家的智体软件开发工具包（SDK）将智体技能作为一级结构进行集成；该技术在微软（VS Code、GitHub集成）、Cursor、Goose、Amp和OpenCode中得到了迅速应用。智体技能规范为技能包提供了一种标准格式，使一个组织创建的技能能够被独立驾驭（harness）采用和部署。这将技能库从驾驭内的工件（专有、不可移植）转变为生态系统资源（开放、可移植）。

治理影响意义重大。Agent Skills引入作为基础设施组件的智体工作流的正式规范，从而实现了：（1）跨驾驭技能的可移植性，（2）工作流模式的版本控制和弃用，（3）工作流先决条件和故障模式的明确文档化，以及（4）独立于模型变化的工作流级性能改进的可重复评估。LangChain DeepAgents实现展示了实际影响：通过将成功的编码模式形式化为可重用的工作流中间件，DeepAgents实现了跨模型和驾驭的性能改进。Anthropic Agent Skills标准化推广了这一见解：最有效的智体改进往往来自更好的工作流设计，而非更好的模型。这些工作流在驾驭之间的可移植性使每个发现的优化价值成倍增加。

3 记忆管理体系结构

如图20 所示：驾驭架构模式与权衡。展示五种具有代表性的记忆架构（无持久性的静态上下文窗口、具有最近轮次持久性的滑动窗口、分层检索增强型记忆、全会话重放和分布式记忆图），它们作为路径穿过一个由三个轴构成的权衡空间：新近性偏差（对近期交互进行加权的能力）、可扩展性（在不降低性能的情况下保留数月上下文的能力）和延迟（记忆检索和格式化的推理时间开销）。每种架构都标绘在代表其典型权衡的点上。连接外部点的凸包显示了帕累托前沿：没有一种架构能主导所有其他架构。箭头表示系统如何迁移：早期系统集中在低延迟、高偏差（黄色）区域，而新兴系统则朝着高可扩展性（蓝色）方向推进，同时接受适度的延迟成本。这一模式解释为什么记忆架构仍然是一个研究挑战，而非已解决的工程问题：权衡空间是多维的，没有单个点能主导所有用例。

记忆作为基础设施，而非能力

在智体文献中，记忆通常被视为一种模型能力——即模型能够记忆和检索什么的问题。而从“驾驭”的角度来看，记忆则被重新定义为一种基础设施问题：驾驭决定了哪些信息有资格存储、实际存储了哪些信息、如何对这些信息进行索引和检索，以及这些信息能保存多久。这些都是治理决策，而非模型能力。它们对智体的可靠性（无状态智体在会话之间忘记的往往正是它所需要的）、性能（检索延迟在长期任务执行时间中占据了很大一部分）和安全性（持久记忆是一种攻击持久化向量，若不进行驾驭级别的控制，则无法解决）有着直接影响。在LTS术语中，S组件的持久性策略决定哪些状态会在未来的转换中保留下来：一个保留完整状态历史的驾驭使模型能够推理任意长的依赖关系，但会允许旧的被污染状态影响未来的转换，从而违反活跃性属性；一个丢弃旧状态的驾驭恢复了活跃性保证，但可能会因丢失跨会话边界维护不变性所需的关键信息而违反安全性。

架构比较

生成式智体（Park，CHI 2023）引入最具影响力的架构：原始观测的记忆流、定期合成更高级别洞察的反思组件，以及结合时效性、重要性和相关性得分的检索功能。该架构通过确立原始存储和智能合成是两个需要分别治理的独立功能，直接影响后续的记忆利用设计。Reflexion（Shinn，2023）将这一见解扩展到自我纠正：通过存储源自失败执行轨迹的口头自我批评，而非原始观测，Reflexion的情节缓冲区提供一个存储处理后经验而非原始历史的记忆利用S组件——这一区分在减少存储容量的同时，提高了未来相似任务的检索精度。

如表 13 所示：

反思与事件缓冲设计模式

Reflexion的情节缓冲设计提出三个特定于治理的问题，这些问题在其原始演示中并未涉及。首先，情节缓冲的内容必须由智体推理步骤（自我反思步骤）生成，这意味着S组件的写入操作不是对智体行为的被动记录，而是一个主动的推理步骤，该步骤会消耗tokens并且本身可能失败——治理工具必须将此写入步骤作为生命周期事件（L组件关注点）进行管理，确保它在任务尝试后可靠地发生，而不仅仅是在智体记得调用它时。其次，情节缓冲是一个高价值的检索目标：未来的执行步骤从检索最相关的自我批评（那些涉及最相似的先前任务情境的批评）中获益最多，这需要语义检索机制而非按时间顺序的访问，从而使Reflexion的S组件成为检索增强上下文模式一个实例，同时带来所有相关的延迟和相关性降低的挑战。第三，存储的批评的口头形式产生一个新的安全考虑：与事实观察不同，事实观察的有效性有时可以通过外部状态来检查，而自我批评是智体对其失败的自我解释，可能会因影响智体失败分析的对抗性工具输出而被篡改或操纵；根据检查对抗性内容模式的模式对情节缓冲的写入进行治理验证是一个尚无解决方案的研究问题。

下表14所示记忆架构折衷：从新近性偏差、可扩展性、检索延迟和实现复杂度四个方面对六种记忆架构进行评估。

记忆-安全耦合

AgentSys（arXiv:2602.07398, 2026）通过明确的层次结构研究安全记忆管理，发现当前利用手段并未系统地解决持久化内容所涉及的隐私和安全问题。密码、PII和敏感上下文在未经明确净化的情况下不应进入长期记忆——当记忆内容由智体的推理而非固定模式决定时，这一要求说起来容易做起来难。因此，记忆架构与安全之间的耦合并非偶然，而是结构性的：任何允许记忆控制向持久化存储写入数据的机制，都隐含地接受了S组件的攻击面受限于智体判断力的观点，而智体本身的安全性并无保障。设计出能够应对被破坏或被操纵智体的健壮记忆治理机制，仍然是一个悬而未决的问题。

记忆治理合同：拟议规范

对记忆架构多样性的分析揭示一个根本性的缺失：没有一个公认的治理契约来规定驾驭记忆系统（harness- memory system）在持久性、一致性、隔离性和可审计性方面必须提供的内容——而这些特性是任何定义明确的存储系统都必须具备的。在传统数据库系统中，ACID（原子性、一致性、隔离性和持久性）恰好提供了这样的契约；在分布式系统中，CAP定理则界定了可实现的一致性、可用性和分区容忍性的组合。驾驭记忆系统需要一个适合其领域的类似契约。

治理合约中的治理记忆应明确规定六个属性，这些属性可按三个维度进行划分：
耐久性维度：写入耐久性
一致性维度：跨回合一致性
隔离与可审计性维度：内容隔离

根本原因：驾驭记忆中的四个未解决问题

四个悬而未决的问题界定了当前记忆利用研究的现状。1）压缩保真度——即在摘要过程中会丢失多少信息，以及丢失的信息是否正是后续步骤所需的信息——尚未得到系统研究；依赖的是经验直觉而非正式的表征。2）分布偏移下的检索质量——即针对一种任务类型训练或调优的检索机制是否能泛化到其他任务类型——研究不足；SkillsBench发现，域变化会导致技能注入产生的性能波动从+4.5个百分点到+51.9个百分点不等，这表明检索质量高度依赖于领域。3）长期运行智体中的记忆膨胀——即随着时间的推移，不相关信息会累积，从而降低检索的信噪比——需要原则性的遗忘机制；MemoryBank的艾宾浩斯曲线方法和AWM的工作流归纳代表两种互补的策略，但两者均未在记忆利用部署环境的全面多样性中得到验证。4）跨会话连续性——即智体应如何在不相交的会话之间保持一致的身份和能力——在架构上仍未解决，当前的方法包括平面文件持久化（如OpenClaw的MEMORY.md）和图结构知识（如Zep TK），但尚未对哪种方法最有利于可靠的长期运行进行系统评估。

计算经济学作为上下文管理约束

上述分析的上下文管理决策在部署规模上具有直接且可量化的经济后果。随着智体工作流在工具调用、记忆检索和规划周期中积累上下文，token消耗会加剧——从业者称之为“上下文腐烂”现象——产生超线性成本增长，而这种增长要么受到设计选择的控制，要么被加剧。这一计算经济学挑战——其中设计选择起到成本倍增器的作用——被分析为一个跨域挑战。

作为记忆调度器的驾驭（harness）

经济压力——来自上下文糜烂的超线性成本增长——无法仅通过模型端的改进来解决；它需要驾驭级的调度策略，这是MemGPT（Packer，2023）通过受操作系统启发的架构实例化的一种框架。驾驭最基本的记忆职责是调度：在每次推理调用时，它必须决定哪些内容进入模型的上下文窗口，以何种顺序，以及在什么token预算下。这是经典操作系统意义上的资源调度问题。Packer（2023）围绕这一类比明确设计MemGPT：驾驭被建模为管理工作记忆（上下文窗口，类似于RAM）和外部存储（磁盘）的操作系统，调度器根据智体发出的函数调用在各层级之间移动内容。MemGPT对驾驭理论的贡献不在于分页机制本身，而在于其框架：调度策略是一等驾驭设计选择，其质量直接决定着智体的可靠性和一致性。

MemoryOS（BAI-LAB，arXiv:2506.06326，EMNLP 2025）将这一框架扩展为三个层级——热、温、冷——并采用了明确的LRU式提升和降级策略。其四个模块（存储、更新、检索、调度）直接对应于治理责任：持久性策略、写入触发条件、检索排序以及保持工作上下文高效的驱逐逻辑。2026年综合记忆综述（arXiv:2603.07670，预印本，审稿中）将这些责任形式化为一个写入-管理-读取循环，其中所有三个阶段都是明确的治理关注点，并确定了五种治理调度策略——上下文驻留压缩、检索增强存储、反思自我改进、分层虚拟上下文和策略学习管理——每种策略在检索质量、延迟和token成本方面都有不同的权衡。语言智体的认知架构（CoALA）框架（Sumers，arXiv:2309.02427，2023）提供补充词汇：其四类记忆分类（工作、情景、语义、程序）明确治理必须公开的读写操作——一种记忆API契约，而非能力描述。综合1400篇论文的上下文工程综述（Mei，arXiv:2507.13334，2025）得出了相同的结论：在缺乏连贯调度策略的治理中改进检索算法，不会带来相应的可靠性提升。

作为驾驭故障模式的上下文糜烂

当工具在没有主动压缩或原则性淘汰的情况下积累记忆文件、技能模式、工具定义和会话摘要时，模型的工作上下文会逐渐充斥着松散相关的信息——从业者称之为上下文腐烂（Zylon.ai，2026）。上下文腐烂既是性能故障（嘈杂上下文下的精度降低），也是经济故障——无论任务复杂度如何，token消耗量都会随着上下文大小的增加而增加，从而导致成本呈超线性增长。工具的保留策略是直接因果机制：默认的全保留策略并非缺乏策略选择，而是工具设计者默许的一种具有已知故障特性的策略。

记忆作为安全攻击面

持久记忆创建一个安全攻击面，其性质与工具访问或直接上下文注入所创建的截然不同。当攻击者通过任何提示注入变体，使智体向长期存储中写入恶意内容时，结果会形成一个跨会话持久通道：恶意内容在会话终止后仍然存在，在未来的会话中无需攻击者进一步干预即可被检索到，并像合法知识一样影响智体行为。这种时间上的解耦使得记忆中毒成为提示注入中最严重的形式，因为攻击者无需保持持续访问来维持其影响。

AgentSys（arXiv:2602.07398, 2026）将记忆隔离视为一种首要的安全保障原语，明确类比于操作系统进程隔离。工作进程通过隔离的上下文窗口生成，这样注入的内容就无法传播到主智体的持久化存储中，而对该存储的写访问需要经过安全保障介导的授权，而不是依赖于模型的判断——这一点至关重要，因为模型的推理本身可能正是记忆写入治理旨在防范的攻击目标。正如2026年记忆调查（arXiv:2603.07670）所指出的，写-管理-读循环中的写入阶段所受的研究关注最少，而这恰恰是最需要安全保障层干预的环节。这一发现直接扩展安全分析：记忆持久化和检索覆盖范围的进步，若没有伴随写入治理的进步，则会扩大攻击面，且扩大程度与其质量提升成正比。

缺乏一个标准记忆接口

每个主要驾驭都实现自己的记忆架构，而这些实现是不可移植的。MemGPT的分页模型将记忆操作暴露为针对两层存储的智体调用函数。Generative Agents（Park，CHI 2023）实现一个带有驾驭-调度反思周期的记忆流。Voyager（Wang，2023）维护一个通过嵌入相似性索引的可执行技能库。A-MEM（arXiv:2502.12110, 2025）将记忆组织为具有链接遍历检索功能的图结构Zettelkasten。Mem0（arXiv:2504.19413）将记忆管理解耦为一个异步中间件管道。每种选择在架构上都是合理的；这些系统的共同点是，为一种驾驭（harness）设计的记忆实现不能嵌入到另一种中，除非重新设计记忆接口。

不可移植性会产生更严重的后果：记忆系统的质量无法独立于利用方式进行评估。生成式智体中的检索精度（利用方式采用三因素相关性评分）与A-MEM中的检索精度（利用方式遍历链接图）无法比较。LoCoMo基准测试（Fang，arXiv:2402.17753，2024）提供多达35个会话中的300轮对话，旨在独立评估长期记忆，但其方法论预设一个可查询的外部存储，排除参数化或上下文打包架构。Evo-Memory（Wei，arXiv:2511.20857，2025）在流式设置中评估记忆更新策略，但同样假设了显式的外部写入操作。这两个基准测试都无法独立于周围利用方式中嵌入的架构假设来评估记忆质量。

---

第三大类驾驭挑战涉及驾驭如何在扩展的规划序列中管理智体推理，以及如何协调多个智体之间的交互。这两项功能——通过回退、探索和验证机制管理复杂推理步骤的执行，以及协调必须共享状态或相互委托任务的独立智体的行为——代表治理所承担的最高级治理职责。当单个智体必须通过涉及不确定结果和部分信息的多步规划进行推理时，驾驭（harness）成为该推理的执行引擎：它决定探索什么、何时回溯、如何验证子结果以及何时承诺执行规划。当多个智体进行交互时，驾驭成为协调基质：它路由消息、保持一致性、管理委托任务，并防止一个智体的失败波及到其他智体。

1 规划与推理基础设施

规划环作为驾驭治理对象

支持顺序动作-观察规划的驾驭必须管理三个循环参数：每个规划步骤的触发条件、观察注入策略以及规划失败时的中止条件。这些参数并非模型属性——模型并非孤立地进行规划——而是驾驭层的设计决策，其配置直接决定规划是成功、停滞还是无限递归。规划质量是模型-驾驭系统的属性，而驾驭对规划循环的管理是决定性变量，在以模型为中心的视角下，这一变量是隐形的。

在线性规划中，工具必须提供什么？典型的“思考→行动→观察”循环确立了工具的三项义务：观察注入策略（每次行动后，工具何时以及如何将环境状态输入到模型的上下文中）、行动验证机制（每一步哪些工具有效，以及如何在执行前捕获无效的工具调用）和终止条件（循环何时终止——通过收敛、失败或步骤限制耗尽）。这些是工具设计决策，对规划的可靠性有直接影响；模型只能看到由此产生的上下文，且无法对其进行任何更改。ReAct（Yao；arXiv:2210.03629，2023）通过形式化最小线性案例，使这些义务变得可见，但这些义务适用于支持顺序规划的任何工具。

将规划状态作为驾驭状态

规划是有状态的，这一点使其与单轮模型的使用有所不同。规划智体会积累部分规划、已放弃的分支、失败模式必须被记住的失败尝试，以及下游步骤所依赖的已验证的子结果。这种状态必须在推理调用和上下文压缩中保持不变；由于模型的上下文窗口是有界的，并且在会话重启时会重置，因此框架对其管理负有全部责任。

语言智体认知架构框架（CoALA；Sumers，2023；arXiv:2309.02427）在架构上最精确地阐述规划状态如何映射到利用记忆组件上。CoALA将智体记忆分解为工作记忆、情景记忆、语义记忆和程序记忆。规划状态跨越所有四个层次，而利用层负责管理每个层次中与规划相关内容的生命周期——决定在规划步骤失败后将什么内容写入情景记忆，在步骤开始前检索什么语义上下文，以及在识别出熟悉的结构时呈现什么程序模板。将规划状态视为单一无差别的上下文块的驾驭层，将无法在正确的时间检索到正确的信息。

搜索预算与驾驭资源治理

管理树形结构搜索的驾驭（harness）面临着一种资源治理义务，这种义务没有单智体（single-agent）的对应物：它必须限制规划循环本身消耗的计算资源，而不受任何单个模型调用的影响。无限制的搜索将消耗无限的token和时间；框架必须设定搜索预算——最大展开次数、深度限制或token成本上限——并且必须在预算用尽时（即使搜索尚未收敛）仍坚持执行规划。Agent Q（Putta，2024年；arXiv:2408.07199）和ExACT/R-MCTS（Song，2024；arXiv:2410.02052）提供驾驭端蒙特卡洛树搜索（Monte Carlo Tree Search，MCTS）的典型实例：在这两个系统中，树形结构、展开策略、备份函数和终止条件都是框架级别的组件，每个叶子节点调用的模型作为价值估计器或动作生成器。该模型是由框架调用的子程序，而非搜索的管理者。

规划界面设计：ACI作为驾驭责任

规划智体与驾驭交互的外部接口——这一维度明确属于驾驭设计的责任，而非模型责任或任务属性。

驾驭是智体-计算机接口（Agent-Computer Interface，ACI）的唯一设计者。模型无法更改其接收到的命令集，无法重新设计其接收到的状态表示，也无法改变其必须解析的错误格式——所有这些都是驾驭的决定。SWE-agent（Yang，2024；arXiv:2405.15793，NeurIPS 2024）引入ACI概念以明确这一点：发现ACI设计对规划性能的可测量影响大于模型能力，这一论断并非针对模型，而是针对驾驭。驾驭若暴露出模糊的状态表示或返回不明确的错误消息，就会对模型的规划预算造成接口负担——模型必须花费token来推断驾驭的含义，而不是推理任务。这种负担对于以能力为中心的分析是隐形的，但从驾驭治理的角度来看却是完全可见的。因此，驾驭的设计必须做到以下几点：在每次动作后提供明确的状态表示；返回结构化、可解析的错误消息，区分可恢复和不可恢复的故障；提供一个最小但完整的命令词汇表，无需模型猜测有效的动作序列；以及在执行不可逆动作之前，提供可通过计划审批关口检查的规划格式。

OpenDev论文（arXiv:2603.05344，2026）将此类约束义务之一——规划批准门——形式化为一种具体的设计模式：驾驭（harness）拦截智体的规划动作序列，将其呈现给验证者（可能是二次模型调用、基于规则的检查器或人机交互步骤），并在规划获得批准之前阻止执行。当初始规划错误原本会通过长动作序列传播时，这种模式大大减少级联错误。规划批准门是应用于规划-到-执行边界的生命周期挂钩（L组件）——其有效性取决于ACI规划表示格式的质量，这是决定规划是否完全可检查的E组件设计选择。AgentBench（Liu，2023）在跨环境规模上证实ACI作为约束责任的框架：在八个环境中出现的智体故障可系统地归因于驾驭-级接口的弱点，而非模型知识空白，从而确认ACI设计是主要的驾驭工程义务。

如图 21 所示规划策略从线性（ReAct）到树状结构（ToT、LATS）再到基于MCTS（蒙特卡洛树搜索）的方法（Agent Q、ExACT）的演进：随着规划复杂度的提高，治理责任从模型转移到驾驭（harness）。

2. 作为驾驭基础设施的多智体协调

当多个智体在智体驾驭边界内或跨边界执行时，这种治理模式不仅仅是得到了扩展；它发生了质的变化。单智体驾驭治理一个执行循环。多智体驾驭必须治理执行循环之间的关系——消息路由、智体身份、授权委托和共享状态一致性——这些问题在单智体中并不存在。多智体协调作为驾驭治理功能，它所提出的新基础设施要求、由此产生的架构分歧、对多智体开销持怀疑态度的经济理由，以及当前生产驾驭尚未解决的可靠性和安全性挑战。

多智体驾驭的新治理要求

当智体被组合在一个单一的驾驭边界内时——如MetaGPT（Hong，ICLR 2024）、ChatDev（Qian，2023）和CAMEL（Li，NeurIPS 2023）——会出现三个单智体架构所不面临的管理问题。从LTS的角度来看，多智体驾驭必须管理单个智体LTS的组合：每个智体都有其自己的状态空间、事件字母表和转换函数；组合后的驾驭必须在Q = Q1 × Q2 × · · · × Qn上定义一个乘积LTS，使得乘积系统具有全局安全性（所有可达状态都不违反共享不变式）和活性（所有智体都能达到其各自的终止状态）属性，而不仅仅是孤立存在的单个智体。

MASEval（Emde，arXiv:2603.08835，2026）通过提供一个框架无关的库，将整个多智体系统（而不仅仅是模型本身）作为分析单元，从而解决系统层面的评估差距问题。通过在3个基准测试、3个模型和3个框架（smolagents、LangGraph、AutoGen）之间进行系统比较，MASEval证明，对于多智体系统的性能而言，框架选择与模型选择同样重要。这一发现为多智体环境中的“驾驭作为绑定约束”论点提供直接的经验证据：关于拓扑结构、编排逻辑和错误处理的实现决策——所有驾驭层面的考量——所产生的性能变化幅度与模型选择相同。该方法论上的贡献在于提供一个标准化的抽象层，使得跨框架（framework）比较得以公平进行，从而弥补了AgencyBench所识别但未解决的多智体配置方面的空白。

如图 22 所示四种具有驾驭治理要求的多智体协调拓扑模式：基于角色的编排、基于市场的协调、模拟底层和分层委托。每种模式对S组件的需求在性质上都有所不同。

如表17 所示按协调模式划分的多智体治理要求。从状态共享、消息路由、信任模型和S组件需求四个方面对四种协调拓扑结构进行比较。

协议层标准化与学习拓扑

当协调拓扑是学习得到的而非固定不变时，该驾驭（harness）面临一个可审计性权衡：优化的协调结构可能无法像显式指定的协议栈那样进行审计、移植或检查。一个围绕固定、已声明的智体图设计的驾驭，可以枚举所有可能的委托链，验证授权范围不会扩大，并为事后审查生成结构化跟踪。而一个拓扑结构通过搜索发现的驾驭，则不具备这一特性——优化的图是一种新兴产物，它抵制预先指定，并可能违反驾驭设计者意图实施的治理特性。这种可审计性权衡是协议层标准化与学习拓扑之间分歧所凸显的核心治理挑战。

在标准化方面，MCP（Anthropic，2024）和A2A（Google，2025）代表了两种相互竞争的方法，旨在解决这一权衡问题，并倾向于可审计性。MCP管理智体到工具的通信，而A2A管理智体到智体的委托——两者共同构成了一个协议栈，其中T组件边界和智体间委托边界都得到了明确规定、可审计，并且任何符合要求的工具均可实现。Pan（arXiv:2505.02279，2025）进行的互操作性调查将MCP和A2A描述为互补而非竞争：MCP用于驾驭内部访问，A2A用于驾驭间智体委托。一个实现A2A的驾驭提供可审计的智体间通信，具有明确的任务边界、授权范围和完成信号——这些治理特性是临时消息传递无法提供的。

单智体基线问题

近期工作中，对多智体协作文献最重要的实证贡献或许是一项负面结果。多智体基线研究（arXiv:2601.12307）表明，一旦将消息路由、身份管理和共享状态更新的协调开销纳入考量，精心设计的具有KV缓存重用的单智体系统可与同质多智体集合（即多个相同智体类型的实例协同工作的配置）的性能相媲美。只有异质组合（即智体贡献结构上不同的能力或角色视角）才能在优化后的单智体基线基础上产生一致的性能提升。

这一发现构成了具有重大影响力的驾驭经济学论点。多智体驾驭的开销——每个智体的L组件身份验证、智体间消息验证、S组件一致性机制以及用于轮转的E组件扩展——是实实在在的工程成本，必须通过相应的任务性能提升来证明其合理性。当这些性能提升缺失或微不足道时，从严格意义上讲，多智体配置就是浪费的：驾驭消耗了治理资源——token预算、延迟、开发人员复杂性——却没有带来治理开销本应实现的可靠性提升。

多智体系统中的可靠性与安全性

从一个驾驭治理的角度来看，多智体系统的可靠性与安全性分析直接对应于分布式系统的问题类别：当分布式系统中的一个节点行为异常或恶意时，有什么机制能防止故障传播到系统的其他部分？在驾驭层，多智体驾驭正面临这一问题。在LTS术语中，一个受损的智体会产生违反其个体安全不变式的事件序列；一个没有故障隔离的驾驭会允许该序列影响全局状态Q，从而可能通过允许受损智体的无效转换来改变其他智体所依赖的共享状态，将局部违规级联为全局违规，进而违反组合系统的安全属性。

多智体系统的拜占庭容错分析（arXiv:2511.10400, 2025）发现，故障传播与抑制几乎完全取决于驾驭级机制——投票协议、消息验证规则和状态更新策略——而非单个智体的错误率。一个孤立产生幻觉的智体会产生一个单一的错误输出；而在缺乏故障隔离机制的情况下，同一智体可能会破坏所有其他智体所依赖的共享状态，从而引发级联故障，其影响范围由驾驭的一致性模型决定。SAGA框架（arXiv:2504.21034, NDSS 2026）从安全角度解决了这一问题：SAGA提出一个策略执行层，该层通过加密可审计的监控来包装智体集合，在智体对共享状态或外部工具执行操作之前对其进行拦截。SAGA在结构上类似于内核安全边界：正如内核防止单个进程破坏共享内存一样，SAGA的策略层防止单个智体破坏共享状态或劫持协调协议。因此，可靠的多智体系统不仅需要单个智体行为正确，还需要驾驭级的故障隔离，这种隔离与任何单个智体的可信度无关。

---

挑战性问题：

跨组件交互模式
可观察性与调试
人机交互机制
成本与计算经济性
自主性与长期运行部署
自动化驾驭工程
自然语言驾驭规范
形式验证与行为保证
跨驾驭可移植性与统一基准协议
桥接与联邦互操作性
长期任务分解
安全模型形式化
工具组合与依赖推理
节能基础设施设计
综合