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 错位的注意力问题

基于LLM的智体学术研究总体上侧重于模型本身。研究议程主要围绕模型的功能展开：例如，它能否进行多步骤规划（Yao，2023）、能否可靠地调用工具（Qin，2024）、能否检索和压缩相关记忆（Packer，2023），或者能否与其他智体协调（Li，2023；Hong，2024）。该研究方案的隐含假设是，智体的能力主要取决于模型的能力——即，一个能力足够强的模型，在足够好的提示下，能够产生足够可靠的行为。

然而，近期基准基础设施研究对这一假设提出了越来越多的质疑。Kapoor (2026) 报告称，Holistic Agent Leaderboard (HAL) 是一个涵盖多种模型和基准测试的标准化评估工具，它将评估时间从数周缩短至数小时，并消除了常见的实现错误——这表明，先前评估文献中被视为智体失败的相当一部分，可能是评估工具本身的缺陷，是执行环境规范不完善造成的，而非模型本身的局限性。Li (2026) 使用 AgencyBench 得出类似的结论：在评估需要长时间使用工具的真实世界任务中的智体能力时，专有模型在其原生执行生态系统中表现最佳——作者将这一结果解释为“将模型架构与智体框架协同优化”的证据。SWE-bench（Jimenez，ICLR 2024）同样需要在软件工程智体进行可复现评估之前进行大量的驾驭工程（harness engineering），而由此产生的基础设施（而非任何模型改进）被认为是主要的瓶颈。其他评估工作也出现类似的模式：AgentBench（Liu，2023）协调多个并行评估环境，需要一个多环境编排驾驭（orchestration-harness）；GAIA（Mialon，2023）记录人类和模型在真实世界辅助任务上的表现存在巨大差距，部分原因在于环境基础的差异；WebArena（Zhou，2024）在自托管的实时环境中部署数百个网络导航任务，其中环境漂移成为一个系统性的实验问题。在这些研究中，一个反复出现的观察结果是：智体部署的结果似乎很大程度上取决于周围基础设施的质量，而不仅仅是模型的能力。

来自生产部署的独立实践者报告也证实这一模式，尽管这些报告未经同行评审，仅作为示例而非最终证据。 Lopopolo (2026) 描述 OpenAI Codex 团队如何在几个月内构建一个庞大的生产代码库，且完全没有编写任何手写代码。他指出，早期瓶颈在于执行环境而非模型本身：“早期进展比预期的要慢，并非因为 Codex 能力不足，而是因为环境规范不够完善”[实践者报告]。据报道，Stripe 的 Minions 系统每周通过“Blueprint”混合架构生成超过一千个 pull request。该架构将确定性节点（代码检查器、持续集成）与智体循环相结合，并使用一个经过精心挑选的、基于 MCP 的大型工具注册表子集，而不是公开全部工具（Gray，2026）。Hashimoto (2026) 维护一个 AGENTS.md 文件，作为智体故障模式的实时记录，并将该驾驭（harness）描述为模型行为漂移的纠正机制。或许最直接的量化例证来自 Boluk (2026) 的研究，他指出，仅更改编辑工具格式（无需修改模型）就能使某些模型的编码基准测试性能提升一个数量级（例如，某个模型的性能从 6.7% 提升至 68.3%）[实践者报告]。尽管这些案例都带有个案性质，但它们都指向一个一致的观察结果：对驾驭-级工程的投入可以带来仅靠模型更改无法实现的性能提升。

实践者的证据也印证这一结论。 Manus 和 LangChain 都重建核心系统基础设施——而非模型权重或提示——并观察到稳定性显著提升。Vercel 发现，从智体的运行环境中移除 80% 的可用工具，比任何模型升级都能更有效地提高任务成功率。Terminal-Bench 2.0 的发布并非采用新的基准测试任务，而是采用容器化执行框架 Harbor——因为可复现的评估已成为关键约束，而非模型质量（Snorkel AI，2025）。这三个例子均来自实践者报告和行业案例，而非同行评审的研究。此前的实证论断——来自 AgencyBench、HAL 和 SWE-bench——均有同行评审或预印本佐证的证据。

这些观察结果共同揭示一种称之为“驾驭-即-基础设施”问题的现象：智体执行驾驭（即管理执行循环、工具访问、上下文、内存、生命周期和评估的软件系统）并非模型能力的被动通道，而是其共同决定因素。该基础设施位于模型与外部世界之间，其设计选择是决定一个功能强大的模型能否成为可靠系统的首要因素。

OpenClaw 提供迄今为止最具代表性的产品驾驭（product harness）案例之一。Zylon.ai (2026) 将其描述为“一个围绕 LLM 构建的框架，其中包含内存、工具、触发器、指令和输出通道，使模型能够像自主软件智体一样运行”，并确定了五个架构层：中央 LLM 推理核心；提供消息路由和会话持久性的网关和会话层；强制工作记忆、检索记忆和长期记忆分层分离的上下文管理和内存层；实现工具调用反馈循环的指令、工具和智体循环层；以及提供基于时间或基于事件激活的触发器和输出层。这五层构成一个架构外骨骼，它与必要且充分条件完全吻合：决定智体能否可靠运行的并非模型本身，而是围绕它的基础设施。NVIDIA 首席执行官黄仁勋 (Jensen Huang) 在 2026 年 3 月将 OpenClaw 称为“可能是最重要的软件版本”，这表明智体基础设施已从学术研究领域转向核心竞争领域。NVIDIA 在 2026 年 GTC 大会上发布的 NemoClaw 将 OpenClaw 直接集成到企业智体堆栈中（Aethir，2026；NVIDIA GTC 博客，2026）。

问题在于学术研究尚未跟上步伐。尽管模型层已吸引了数千篇论文，但驾驭层却几乎无人问津。记忆问题已有相关研究（Zhang ，2024）。工具使用问题已有相关研究（Qu，2024）。评估问题已有相关研究（Mohammadi，2025）。智体安全性问题已有研究（Hua，2024；Greshake，2023）。但是，整合这些功能的底层架构——决定一个功能强大的智体能否在实际任务中实时可靠运行——却一直没有作为一个统一的研究对象得到系统性的探讨。其结果是，该领域对引擎的理解非常透彻，而对底层架构却知之甚少。

本综述旨在纠正这种不平衡。智体执行驾驭（agent execution harness）应该被视为一个重要的架构概念，拥有其自身的定义、历史渊源、分类体系和未解决的问题。构建正确的底层架构并非是在研究问题得到解答之后才需要解决的实现细节——它本身就是一个研究问题，并且对智体可靠性、评估和安全性的理解有着深远的影响。

如图 1 所示综述的摘要。左图：来自六项独立研究的定量证据汇聚表明，仅对驾驭进行更改（无需任何模型修改）即可在编码基准测试中实现高达 10 倍的提升，在 TerminalBench 测试中提升 26%，在数学推理测试中提升 4.7 个百分点。右图：本综述中引入的六-组件驾驭框架（harness framework） H = (E, T, C, S, L, V)，围绕一个中心语言模型构建执行循环 (E)、工具注册表 (T)、上下文管理器 ©、状态存储 (S)、生命周期钩子 (L) 和评估接口 (V)。该综述分析 22 个系统，确定 9 个贯穿始终的挑战领域，并提出 12 个研究方向。

实践者与研究者的鸿沟

实践者的紧迫感与研究术语之间的张力本身就是一个值得分析的信号。当 Chase (2026) 将“上下文工程”描述为智体开发者的一项新核心技能，或者当 Gupta (2026) 宣称“2025 年是智体，2026 年是智体驾驭”时，他们描述的是一种学术研究界尚未充分命名或研究的经验模式。实践者已经意识到模型能力并非制约因素——他们因此将工程精力投入到驾驭层（harness layer），却缺乏对该层本质、功能以及如何评估其质量的系统性学术研究。

与此同时，研究界一直在以越来越高的精度研究智体系统的各个组成部分：记忆、工具使用、规划、安全性。但他们尚未研究的是将这些组成部分集成到可靠运行中的系统——驾驭（harness）。由此产生一种具有特殊性质的实践者与研究者之间的鸿沟：实践者（从经验上）知道基础设施至关重要，但缺乏正式的词汇来描述其重要性，从而实现系统性的改进；研究人员拥有详细的组件级模型，但缺乏能够解释组件质量如何（或未能）转化为系统可靠性的跨域基础设施视角。

本综述旨在弥合这一鸿沟，提供实践者一直以来隐性要求而研究人员尚未提供的学术论述。

实践者的迫切需求不仅体现在概念层面，也体现在可衡量的经济层面。根据实践者报告，领先的LLM API聚合器之一OpenRouter在截至2026年2月9日的一周内处理了13万亿个tokens，是1月初处理量6.4万亿个tokens的两倍多，这一激增归因于OpenClaw式智体工作负载的采用（Aethir，2026；OpenRouter/a16z人工智能现状，2026）。实践者报告还指出，该平台上超过一半的输出tokens可能来自智体工作流程，而非对话会话。行业预测表明，到2027年，来自人工智能智体的tokens和API调用负载可能会增长1000倍（Khmel，2026 [实践者报告]）。这些是行业预测和实践者观察，并非经过同行评审的实证研究结果；它们被视为结构性转变的指示性证据，而本综述的目的正是为了系统地进行学术记录。彭博社援引从业者报告的数据显示，自 2025 年 12 月以来，H100 的租赁价格随着智体工作负载的增长而大幅反弹（Aethir，2026）。

这种计算压力是驾驭设计选择的直接结果。当 AgencyBench（Li，2026）报告其基准测试任务平均每次执行需要一百万个tokens时，token负载的来源并非模型本身的冗长性，而是驾驭的上下文管理策略：每次迭代注入什么、如何检索记忆、如何累积工具结果以及执行循环在终止前运行多长时间。一个以牺牲上下文效率为代价来优化可靠性的驾驭，在大规模应用时，会成为基础设施成本的倍增器。新兴的从业者指标——每次任务成本 (CPT) 而非每秒token数——正是反映这种认识（Medium，2025）。驾驭的设计即成本曲线的设计，一个缺乏对驾驭基础设施系统性阐述的领域，也同样缺乏对其大规模部署经济效益的系统性阐述。

尽管这些实践者的观察为理解部署规模提供宝贵的背景信息，但驾驭基础设施是一个关键约束的核心论点，却建立在同行评审的实证研究之上。Holistic Agent Leaderboard （HAL；Kapoor，2026）评估了超过 21,000 个智体部署案例，SWE-bench（Jimenez，ICLR 2024）系统化地评估代码智体，而 AgencyBench（Li，2026）则在 138 个真实世界任务中发现驾驭-模型耦合的证据。这三项经过同行评审或与之相关的研究，为实践者的定性观察提供了量化依据，即执行基础设施（而非模型能力本身）决定了真实世界智体系统的可靠性。来自大规模部署的实践案例——OpenAI、Stripe、METR——证实并说明了这一原则；它们是规模和部署紧迫性的证据，而不是约束性限制本身的证据。
如图 2 所示绑定约束模型：模型能力对于系统可靠性而言是必要的，但并非充分条件。智体驾驭通过六项治理功能（E、T、C、S、L、V）来协调转换。实证研究：Pi Research（仅智体工具的改变就使系统可靠性从 6.7% 提升至 68.3%）；AgencyBench（在原生生态系统中为 48.4%，而在其他生态系统中较低）。

融合时刻

本综述正值行业实践与学术研究在驾驭基础设施方面达到关键融合之际。在2026年3月下旬至4月初的几周内，三项独立进展从互补的角度验证绑定约束理论，每一项都提供证据，表明驾驭（harness）而非模型才是提升系统可靠性的主要杠杆。

首先，OpenAI（2026）正式提出了“驾驭工程”这一学科，并报告称，一个由三到七名工程师组成的团队在五个月内构建约一百万行生产代码——涵盖应用程序基础设施、工具和服务逻辑——他们利用Codex作为代码生成智体，并搭配精心设计的执行驾驭（execution harness）。Codex团队的回顾明确指出驾驭是绑定约束：“早期进展比预期的要慢，并非因为Codex能力不足，而是因为环境规范不够完善。” OpenAI（首个部署生产级LLM智体的组织）的这项实践者级别的验证表明，驾驭工程已从研究概念过渡到工业领域。

其次，斯坦福大学和麻省理工学院的研究人员（Lee，arXiv:2603.28052，2026）发布Meta-Harness，该软件通过智体搜索驾驭设计空间本身，演示驾驭的自动化优化。Meta-Harness在TerminalBench-2测试中取得76.4%的准确率（超过了手工设计方法的74.7%），在五个未进行模型更改的独立模型中，IMO级别数学测试的准确率提高了4.7个百分点，并且在使用四倍数量tokens的情况下，文本分类的准确率提高7.7个百分点——所有这些改进都源于一个应用于多个模型的单一驾驭。这提供迄今为止最有力的实证证据，证明驾驭设计作为一个工程问题，在形式上是可分离的且可优化的。

第三，LangChain 的 DeepAgents（LangChain，2026）在 TerminalBench 2.0 测试中性能提升 26%（从 52.8% 提升至 66.5%），仅通过对驾驭层的改进就从前 30 名之外跃升至前 5 名：系统提示强制执行自我验证、基于中间件的上下文注入以及用于预防故障模式的生命周期钩子——而无需对模型进行任何更改。这种在不同组织、使用不同基础设施的情况下进行的独立复现验证“驾驭-层优化带来的性能提升，可与模型升级相媲美甚至更优”的论点。

这三项进展——OpenAI 将驾驭工程明确地作为一门学科来采用、斯坦福/麻省理工学院的形式化优化框架以及 LangChain 的开源实现取得了最先进的成果——都独立地印证了本综述的核心论点。理论框架H = (E,T,C,S,L,V)独立于这些最新进展而发展，它首次系统地阐述这三个组织通过实证研究发现的内容。这项综述的时机恰到好处：它首次对一个基础设施层进行全面的学术探讨，而该基础设施层刚刚成为工业界投资和研究的热点。

如图 4 所示实证证据矩阵：六项独立研究表明，仅对测试框架进行更改（无需更改模型）即可显著提升性能。Pi Research 在 TerminalBench 上实现 10 倍的性能提升；LangChain 的 DeepAgents 通过仅更改驾驭（harness），性能从 52.8% 提升至 66.5%（提升 26%）；Meta-Harness 的自动化优化在 TerminalBench-2 上达到 76.4% 的性能，超越手工设计的方法。在所有案例中，模型保持不变，而驾驭（harness）则进行更改。

1. 定义难题

在定义智体驾驭之前，值得探究一下为什么定义如此困难。这个术语已经在实践者群体中流传多年，但始终未能达成一个稳定的含义——并非因为其背后的现象存在争议，而是因为它处于几个既定概念（框架、环境、脚手架、平台）的交汇点，而每个概念都涵盖了它的一部分。一位实践者借用汽车的比喻：驾驭是底盘，模型是引擎。另一位实践者将其描述为“智体的操作系统”。Anthropic 内部使用脚手架一词，将其定义为“使模型能够作为智体运行的系统——处理输入、协调工具调用并返回结果”。这些描述各有其用，但没有一个是精确的。

这种不精确性至关重要，因为它决定能够进行有意义的比较对象。如果“智体驾驭”指的是任何封装模型的东西，那么 LangChain 的提示模板和 DeerFlow 的多智体编排引擎就属于同一类事物，而它们显然并非如此。一个有价值的定义必须划定一个反映真实结构差异的边界——一个能够预测系统行为的边界。

本文方法是从对运行可靠的智体系统与原型系统之间区别的功能分析中推导出定义。区别不在于能力，而在于治理（governance）：可靠的系统实现一系列运行时控制功能，这些功能管理着能力的运用方式，而不仅仅是能力本身。

2. 正式定义

如图 3 展示智体驾驭H = (E, T, C, S, L, V) 的六组件架构。该图显示每个组件如何占据不同的治理层：位于中心的执行循环 (E) 协调观察-思考-行动周期，并指导其他组件之间的控制流。工具注册表 (T) 位于环境边界，通过类型化、模式验证的接口来协调智体对外部世界执行的每个操作。上下文管理器 © 管理进入模型的信息通道，在每个步骤中过滤和确定进入上下文窗口的信息的优先级。状态存储 (S) 提供跨轮次和跨会话的持久性，并在发生故障时将恢复状态反馈给执行循环。生命周期钩子 (L) 在所有组件边界之间形成一个拦截层，实现身份验证、审计和策略执行，而无需耦合到组件逻辑。最后，评估接口 (V) 以标准化的格式记录完整的执行流程——捕获类型化的动作轨迹、中间状态和目标完成信号——供外部基准测试框架使用。图中的箭头描绘单个执行步骤的流程：从环境观察，经过上下文组装 ©，进入模型推理，经过工具调度 (T)，最后通过状态提交 (S) 返回，然后进入下一个步骤。L 拦截每个边界，V 记录轨迹。从左到右阅读该图大致对应于单个驾驭步的时间顺序；从上到下阅读则对应于隔离层级结构，从面向模型 (C, S) 到面向外部环境 (T) 再到面向治理 (L, V)。

定义 2.1（智体驾驭）。智体驾驭是一个软件系统 H = (E, T, C, S, L, V)，它实现了六个运行时治理功能：

• E — 执行循环：管理观察-思考-行动周期，包括回合顺序、终止条件和错误恢复
• T — 工具注册表：维护一个类型化的、经过验证的可用工具接口目录；路由和监控工具调用
• C — 上下文管理器：控制哪些信息在回合间进入模型的上下文窗口，包括压缩、检索和优先级策略
• S — 状态存储：在回合间（可选）跨会话持久化与任务相关的状态；提供从部分故障中恢复的功能
• L — 生命周期钩子：用于身份验证、日志记录、策略执行和检测的调用前和调用后拦截点
• V — 评估接口：通过标准化的钩子（将 V 组件与通用日志记录区分开来）检测执行过程，以捕获动作轨迹、中间状态和成功信号，用于离线分析

这六个功能并非随意设定。 V（评估接口）和 L（生命周期钩子）之间的区别值得明确说明，因为任何记录智体行为的系统似乎都同时满足这两个条件。区别在于功能范围和标准化。L 提供用于操作目的（身份验证、访问控制、审计跟踪和策略执行）的调用前和调用后拦截，而无需依赖任何特定的数据模式或下游使用者。相比之下，V 提供结构化的轨迹捕获，其标准化模式可供基准测试框架、评估管道和可观测性平台直接使用：包含类型化参数的操作序列、中间状态快照、工具调用成功/失败指示器、目标完成信号以及每一步的token消耗。仅包含 L 的系统只能告诉你某个工具被调用以及调用时间；而包含 V 的系统则可以告诉你该工具调用是否推动智体朝着目标前进，并且其格式支持跨-驾驭比较。其操作意义显而易见：HAL 的标准化评估框架需要一个 V 组件，该组件能够以 HAL 分析基础设施可处理的规范格式生成轨迹记录——仅提供操作日志钩子的框架无法满足这一要求。这些组件对应于生产智体部署中观察到的六种主要故障模式：执行失控（由 E 组件解决）、工具误用（T 组件）、上下文崩溃（C 组件）、故障时状态丢失（S 组件）、未监控的副作用（L 组件）和不可观察的行为（V 组件）。一个实现了所有六种故障模式的系统，在某种意义上是可操作的；一个只实现了其中几种故障模式的系统是部分可操作的；一个什么都不实现的系统——即仅调用裸模型——则不受控制。

必要条件。一个系统必须至少实现 E 和 T 才能被视为驾驭（harness）。如果没有 E，就无法进行多步骤执行；该系统只是一个单轮推理包装器。如果没有 T，智体就无法对外部世界采取行动；该系统只是一个没有执行器的推理引擎。这两者共同构成最小可行操作环境。

充分条件。一个系统如果实现所有六个组件，并且具备生产级可靠性——包括错误处理、身份验证、可观测性集成和已记录的故障模式——则可被视为全栈驾驭。

测试定义的边界情况。该定义在边界处才真正发挥作用。一个简单的 ReAct 循环（Yao，2023）并非驾驭：它仅实现 E 的最低限度（一个没有错误恢复或终止逻辑的 while 循环），并且仅部分实现 T（没有注册表的临时工具调用），完全缺少 C、S、L 和 V。ReAct 是一个框架原语（framework primitive），可以从中构建驾驭，但它本身并不是驾驭。同样，LangGraph 也不是一个驾驭——它提供基于 DAG 的执行图原语（E 的部分逻辑实现），但对上下文管理、状态持久性、安全性或评估没有明确说明。MemGPT 是一个功能模块：它以极其精细的方式实现 C 和 S，但作为独立组件，它没有执行循环、工具注册表和生命周期钩子。相比之下，AIOS（Mei，COLM 2025）则符合完整框架的标准：它使用显式的操作系统级抽象实现所有六个组件，并且其通过正确调度并发智体请求而获得的 2.1 倍经验加速表明，E 级治理具有可量化的性能影响。思维树框架（Yao，NeurIPS 2023）是另一个具有启发意义的例子：通过要求执行循环维护并行推理分支、评估中间状态以及从死胡同回溯，ToT 揭示 E 组件的设计空间远比线性 ReAct 式循环所假设的要丰富得多。支持 ToT 式推理的驾驭（harness）必须实现分支执行图、分支级状态隔离以及中间步骤的评估回调——这比单路径驾驭的要求要高得多。这说明驾驭 E 组件的需求部分取决于驾驭所承载的规划架构这一普遍原则。

E -组件的形式语义。驾驭理论（harness theory）中一个尚未充分发展的维度是执行循环本身的形式语义。 E 组件可以被描述为一个标记的转换系统 (LTS)，其状态包括 Q = {空闲、观察、调用模型、分发工具、等待工具结果、提交状态、终止}、可观察事件字母表 Σ（模型响应tokens、工具调用、工具结果、人工批准、错误）以及转换函数 δ : Q × Σ → Q。这种形式化揭示非正式描述无法表达的三个正确性属性：安全性（系统永远不会进入无法终止的状态，即不会发生执行失控）；活性（从每个可达的非终止状态，都可以到达终止状态）；以及确定性（为了保证可复现性，δ 必须是一个函数而不是一个关系，这意味着环境的非确定性必须在工具调用边界处隔离）。进程代数（process algebra）提供一种补充视角：驾驭的并发子智体编排可以用CCS或CSP建模，其中子智体进程P1 || P2 || … || Pn的并行组成必须在驾驭的同步约束下满足无死锁特性。Xu（2025，JACM）指出，多智体系统中的编排模式恰恰展现进程代数旨在检测的并发风险——死锁、活锁和优先级反转。这具有双重实际意义：E组件设计应在配置中显式地暴露其状态机，以便验证器在部署前检查其格式是否正确；多智体驾驭（multi-agent harness）应证明其编排拓扑不存在死锁，类似于并发操作系统要求对进程间通信进行协议验证。目前还没有任何生产驾驭能够满足这两个要求，这代表着形式上的充分性和工程实践之间存在差距，而研究方向应该开始弥合这一差距。

形式化应用：通过 LTS 对系统进行分类。E 组件的 LTS 表征并非仅仅是装饰性的；它为边界情况提供一种判别工具。考虑两个对比鲜明的系统。ReAct（Yao，2023）作为一个非工具箱案例，具有启发意义。ReAct 的实现可以写成一个 while 循环，并带有一个非正式的“如果模型输出最终答案则停止”条件。用 LTS 术语来说：状态集 Q 坍缩为 {active, done}；没有等待上下文承诺的空闲状态，没有捕获异步返回的等待工具结果状态，也没有在下一个观察步骤之前保证持久性的承诺状态转换。因此，转换函数 δ 是部分转换的——对于错误输入，它是未定义的，因为 ReAct 没有错误恢复弧——这违反了 LTS 的安全属性，即终止必须始终可达。初始状态 q0 = active，终止状态 F = {done}，但当工具调用返回异常时，没有 δ 路径能够保证到达 F。这种形式上的缺陷正是实践者所观察到的“执行失控”。相比之下，AutoGPT（Richards，2023）在 LTS 分析下符合框架的定义。它的执行循环实现了更丰富的状态空间：q_0 = idle（等待任务输入），在循环回到 idle 之前，会经历目标解析、子任务分解、网络工具调用和状态持久化等步骤。终止条件 F = {目标达成，超出最大步骤数} 在代码库中明确定义。δ 函数是对已记录的事件字母表 Σ 进行全操作的——包括异常事件，异常事件会路由到错误恢复状态，而不是导致静默失败。 AutoGPT臭名昭著的可靠性问题并非源于其LTS不完整，而是源于其δ转换的实现缺乏安全关键型生命周期系统所需的生产级保证（幂等状态写入、原子提交）。这种区别至关重要：ReAct之所以无法作为驾驭使用，是因为它缺乏生命周期系统结构；而AutoGPT虽然是一个生命周期系统结构健全但实现不健全的驾驭。形式化方法恰好在直觉所暗示的地方划定这条界限。第三种情况——LangGraph——将分析扩展到拓扑编码的驾驭。LangGraph将执行实现为计算节点的有向无环图（DAG）。用生命周期系统术语来说，Q由图节点的集合定义；δ由图边及其附加的条件转换谓词定义；DAG拓扑结构从构造上保证活性——无环性确保任何执行都不会无限循环，因此终端节点始终可以从任何非终端节点到达。因此，E 组件存在且形式上表现良好。然而，C 组件并非通过主动的上下文管理策略实现，而是通过图拓扑结构隐式实现的：信息通过图结构在节点间流动，但模型在每个步骤中接收的信息并没有显式的上下文压缩、驱逐或优先级机制来控制。这直接影响分类：LangGraph 实例化 E 和 T（节点调用工具），凭借 DAG 结构满足 LTS 安全性和活性属性，​​但 C 组件的实现是隐式的而非显式的。将 LangGraph 归类为拓扑编码的框架——其中 C 组件可以从图规范而非单独的运行时组件中导出。因此，LTS 分析区分三种结构不同的系统类别：原始的非驾驭（ReAct，其中 δ 是部分实现且安全性失效）、单体驾驭（AutoGPT，其中 δ 是完全实现但实现保证较弱）以及拓扑编码的驾驭（LangGraph，其中形式属性是通过架构而非命令式方式建立的）。这种源自统一 LTS 框架的三分类仅靠非正式分析无法实现。

如图 5 对比三个代表性系统（ReAct、AutoGPT 和 LangGraph）标记的转换系统结构。左图展示 ReAct 的简化两状态 LTS（活动 → 完成），其中没有错误恢复弧，也没有提交状态中间体——δ 对错误输入的不完整性在视觉上表现为缺少从活动状态到完成状态的转换。中间图展示从空闲状态经目标解析、工具分发、状态持久化再返回空闲状态的完整路径，并包含显式的错误恢复弧，可在故障事件发生时闭合 LTS；图中标注这种形式上合理的结构与其弱保证实现之间的差距。

V-组件设计空间：从日志记录到评估流程

评估接口（V-组件）是实现最不完善的驾驭组件（harness component）——在完整性矩阵的22个系统中，有14个系统存在部分实现或缺失的情况——也是设计空间最不为人所理解的组件。这种实现不完善反映两个互补的误解。首先，实践者经常将V-组件与生命周期钩子（L-组件）混淆：由于生命周期钩子（L-组件）用于捕获驾驭事件（harness event）以进行运维，部署者便认为运维日志足以满足评估需求。这种混淆忽略 V-组件的基本要求：外部基准框架可以直接使用的标准化轨迹模式。其次，设计单次部署驾驭的实践者无需进行跨驾驭的比较，因此V-组件的可移植性要求——即其输出必须能够被驾驭外评估流程解释——似乎没有必要。这种投资不足的代价只有在需要评估时才会显现：此时，在没有 V 组件的驾驭上加装 V 组件需要进行大量的重新设计。

V -组件的设计空间涵盖四个功能级别。在最基本的级别 (V1)，驾驭以扁平的日志格式记录带时间戳的事件——工具调用、模型响应、错误——这种格式适合人工检查，但不适合自动化分析。在中级级别 (V2)，驾驭生成结构化的轨迹记录，其中包含类型化的字段——操作类型、论证模式、工具响应、每步的token计数——从而实现自动聚合和比较。在高级级别 (V3)，驾驭生成更丰富的轨迹记录，其中包括中间推理步骤、每次模型调用之前的上下文窗口快照以及从驾驭-级任务状态导出的目标进度估计——从而实现 SkillsBench 和 AgencyBench 所需的因果归因分析。在最高级别（V4）下，该驾驭支持实时流式评估：智体执行过程中实时生成轨迹记录，使评估流程能够计算运行性能指标，并在成功或失败得到明确判定时触发提前停止。HAL 的标准化评估驾驭，运行在 V3-V4 级别；目前大多数生产驾驭运行在 V1 级别。V1 和 V3 之间的差距并非仅仅是在日志模式中添加字段；它需要对驾驭在不同步骤之间维护的状态进行架构决策，以实现轨迹丰富化，而这些决策会以某种方式与 C 和 S 组件交互，使得 V 组件的升级成为一项跨组件的重构工作。

SearchLLM（Wu，arXiv:2603.10473，2026）就是一个展示 V3 级别评估架构的生产部署案例，它是一个大规模部署在大型内容平台上的生成式搜索系统。 SearchLLM 的评估堆栈结合确定性基于规则的评估器（检查事实依据、格式合规性和不可协商的安全约束）和基于 LLM 的评判器（评估与不同搜索者意图的一致性以及对噪声检索的鲁棒性）。关键在于，这两个层级采用分层结构：在评估偏好优化目标之前，会强制执行底线约束，从而避免出现流畅但基于事实的违规行为反而获得奖励的情况。评估器校准通过人机交互流程进行，使得评估界面本身成为一个持续管理的工件，而非静态配置。这种架构直接对应于 V 组件的设计要求：具有类型化维度分数的结构化轨迹记录能够实现扁平的成功/失败日志无法提供的因果归因，而 L 组件的生命周期管理作用延伸到校准循环，以确保评估信号在分布变化的情况下仍能忠实地反映实际的搜索者偏好。

如图 6所示：基于 LTS 的执行流程可视化。图示展示单个驾驭步（harness step）的执行过程，以路径形式展现标记的转换系统状态，并突出显示 V 组件的观测点捕获数据的位置。横轴表示单个步骤内的逻辑时间；纵轴表示当前正在执行的组件。箭头表示转换（LTS 中的 δ），标签指示保护条件（例如，“工具可用？”、“上下文匹配？”）和动作（例如，“提交状态”、“记录观测”）。阴影区域指示延迟通常集中的位置（T 组件的工具调度）和最容易发生故障的位置（E 组件的错误恢复）。此可视化具体化正式的 LTS 结构如何映射到实际运行时行为。

3. 边界案例分析

六组件定义的分析能力源于其对模糊案例的清晰处理。在此提供四个测试该定义边界系统的具体分类依据，证明其排除项是基于原则而非任意的。

ReAct（Yao，2023）被正确地归类为框架原语，而非驾驭。排除项基于两个具体缺陷。首先，ReAct 的执行循环是一个简单的 while 循环，没有错误恢复机制、正式的终止准则，也没有状态机语义：它无法满足 LTS 安全性属性（即始终可到达终止点），因为它没有检测或避免执行失控的机制。其次，ReAct 的工具调用是临时的文本解析，没有注册表：没有类型化的、经过验证的可用工具目录，没有模式强制执行，也没有对调用进行监控。排除标准概括为：缺乏持久状态管理和正式工具注册表的系统，其运行时治理能力不足以构成一个驾驭。它或许是构建驾驭的重要且有用的基础模块，但基础模块本身并非结构。

AutoGPT（Richards，2023）被归类为单体驾驭——一种早期实现，其中执行（E）、任务（T）和系统（S）组件紧密融合在单一代码库中，而非作为可分离的子系统实现。AutoGPT实现持久目标（proto-S）、通过工具调用访问互联网（proto-T）以及任务分解循环（proto-E），使其成为第一个同时展现所有三个必要治理问题的系统。其臭名昭著的故障模式——执行失控、状态累积而未压缩、未监控的副作用——并非证明AutoGPT不是驾驭的证据；而是证明其驾驭组件的实现缺乏生产级可靠性。 AutoGPT 的历史价值恰恰在于，它的失败构成首个​​系统性的实证目录，揭示驾驭治理必须解决的问题。基于故障观察的治理不足以保证可靠运行，但足以评估驾驭状态：关键在于系统是否尝试过实现运行时治理，而非是否成功实现。

MemGPT（Packer，NeurIPS 2023）被归类为具有隐式组件实现的实用模块。MemGPT 并未实现独立的执行 (E) 和测试 (T) 组件；它明确设计用于集成到主机执行环境中，而非独立部署。然而，它在操作系统级别的抽象层面实现了 E 和 T 的功能等效性：其分页机制隐式地对上下文窗口操作进行排序（隐式 E），其“记忆-即-操作”接口定义一组类型化的记忆操作，这些操作充当受限工具注册表（隐式 T）。本案例确立的分类原则是隐式组件实现：当系统通过不同的机制（操作系统级抽象而非显式运行时基础设施）实现组件的功能等效性时，应将该实现归类为隐式而非缺失。MemGPT 的架构意义在于，它证明即使 E 和 T 被委托给宿主驾驭（host harness），C 和 S 组件也能以极其精细的方式实现。

LangGraph 被归类为框架而非驾驭，但与 AIOS 的对比颇具启发性，因为两者都提供了执行抽象。正如正式论证的那样，LangGraph 通过拓扑编码的组件实现而非显式运行时策略来满足驾驭定义——其 DAG 结构从构造上保证了 E 组件的活性，而 C 则通过图拓扑而非主动上下文管理策略隐式实现。LangGraph 基于 DAG 的执行图实现 E 组件的部分版本：它们提供了对智体流的显式控制并支持条件分支。然而，至关重要的是，LangGraph 的 C 组件（图节点间的协调）是通过图拓扑结构隐式实现的：图结构决定信息的流动方向，但并没有主动的上下文管理策略来控制压缩、驱逐或优先级排序。更重要的是，LangGraph 对 C（主动上下文管理）、S（跨会话的持久状态）、L（生命周期策略执行）或 V（评估工具）均无任何要求。相比之下，AIOS 使用显式的操作系统级抽象实现所有六个组件，并展现可量化的 E 级治理优势。二者的区别不仅在于架构的丰富性，更在于治理范围：LangGraph 是构建执行逻辑的构造原语；而 AIOS 是一个控制该逻辑运行方式的操作环境。

框架状态与验证路径

六组件分解 H = (E, T, C, S, L, V) 是一个理论上提出的框架，而非归纳推导的分类体系：它并非通过对现有系统进行因子分析而构建，而是基于对生产故障模式和治理需求的概念分析。数字“六”体现对三个设计维度的原则性分解：执行环境维度（E — 执行循环；T — 工具注册表）描述驾驭（harness）如何与外部世界交互；认知管理维度（C — 上下文管理器；S — 状态存储）描述驾驭如何管理模型可用的信息；治理维度（L — 生命周期钩子；V — 评估接口）描述驾驭如何监控、执行策略以及公开智体行为以实现问责。三个维度，每个维度又分解为两个组件，最终得到六个组件——这种结构并非随意设定，而是经过深思熟虑的。

如果出现第七个候选组件——例如，一个专门用于管理token预算分配的成本管理器——扩展与包含的标准是：候选组件的功能能否在一个或多个现有组件中完全表达？一个拦截每次模型调用并强制执行token预算的成本管理器可以实现为一个专门的生命周期钩子 (L)；它不需要新的状态空间维度。如果候选功能确实无法通过 E、T、C、S、L、V 的任何组合来表达——如果它需要一个具有全新接口类型的全新治理契约——那么框架的扩展是合理的。否则，它应该被包含到最近的组件中。

对这种分解的实证验证仍是未来的工作。三种方法是合适的：对更大的系统语料库中的组件共现模式进行因子分析；对开发人员进行访谈，以确定六组件词汇表是否与实践者的心智模型相符；此外，还需要进行预测性测试，检验该框架下的完全评级是否能够预测类似 SkillsBench 设计中不同驾驭之间的性能差异。其中，预测性测试最容易实施：它只需要在控制驾驭选择的情况下重新分析现有的基准测试结果——AgencyBench 和 SkillsBench 已经验证了这种方法。因子分析和开发者访谈虽然方法论上更为严谨，但需要收集原始数据，因此更适合作为中期研究目标。

4. 正交性假设及其局限性

定义中提出的六组件分析框架假设各组件之间具有逻辑正交性，以便于讨论——每个组件都可以独立地被表征、评估和改进。这是一种分析上的便利，而非实施上的要求。在实践中，这六个组件是深度耦合的子系统。其中最关键的耦合是E（执行）和S（状态存储）之间的耦合：执行循环的恢复行为（步骤失败时会发生什么）从根本上依赖于状态存储的持久性保证（失败前已提交的内容），而这些交互无法通过独立分析E和S来指定或验证。同样，C（上下文）和 L（生命周期）通过上下文策略执行而耦合：控制哪些内容可以进入上下文窗口的生命周期钩子与决定实际内容的压缩和检索机制相互作用。将这六个组件视为真正正交的驾驭设计者所构建的系统，其故障模式恰恰源于分析框架所抽象出的耦合。

5. 将驾驭定位在智体栈中

将驾驭（Harness）的定义与相邻概念进行比较，可以更清晰地理解其含义。框架（framework）与驾驭（Harness） 的核心区别在于开发时与运行时：框架（例如 LangChain、LlamaIndex、PydanticAI）提供开发人员用于构建 Agent 的构造原语；驾驭则是控制智体运行时行为的运行环境。智体平台（例如 Manus、Microsoft Copilot Studio、AWS Multi-Agent Orchestrator）运行在驾驭层之上，添加设计环境、部署管道、监控仪表板和技能市场。平台通常包含驾驭作为其运行时底层，但其功能远不止于此。评估驾驭（EleutherAI，2023）是一个历史更早且范围更窄的概念——用于批量测试语言模型的基础设施——它实现定义中的 V，但不包括 E、T、C、S 或 L。智体操作系统框架（Mei，2025）将操作系统理论应用于驾驭设计，表明经典的操作系统机制——调度、记忆管理、访问控制、存储隔离——在智体执行基础设施中都有直接对应的机制。将智体操作系统视为驾驭概念在架构上最严谨的实现，而非与之竞争。

如图 7 所示驾驭堆栈的概念层：应用层、工具层、平台层和评估层及其各自的工件。

下表 2所示驾驭概念消除歧义。五个相邻概念——框架、驾驭、智体平台、评估驾驭和智体操作系统——按主要角色、堆栈位置以及与驾驭定义的关系进行比较。

如图 8 所示：驾驭组件依赖关系图。该有向图以节点形式展示六个核心组件（E、T、C、S、L、V），边则表示结构依赖关系，其中一个组件的输出会约束另一个组件的实现。例如，E 组件的状态转换语义直接决定 S 组件需要哪些持久性保证；C 组件的上下文分配策略决定 V 组件的哪些评估指标是有意义的。粗边表示强制性依赖（移除它们会破坏整个组件）；细边表示可选的增强功能（移除它们会优雅地降级到更简单的架构）。该图解释为什么某些“组件跳过”优化在大规模应用中会失败：为了节省延迟而移除 L 组件会破坏安全策略的执行；为了减少检测开销而移除 V 组件会破坏评估的有效性。该图按治理范围从左到右阅读：左侧是面向模型的组件（C、S），中间是面向外部的组件（T），右侧是横切组件（L、V）。

六个驾驭组件（E、T、C、S、L、V）并非相互独立——它们构成一个有向依赖图，其中某些组件需要其他组件才能正常运行。E 组件（执行循环）依赖于 T（用于调用工具）、C（用于构建提示）和 S（用于在步骤之间保持状态）。L 组件（生命周期钩子）依赖于其他五个组件，因为钩子必须在每个组件边界拦截事件。V 组件（评估接口）依赖于 L（用于事件日志记录）和 S（用于轨迹重放）。这种依赖结构具有实际意义：如果 E、T、C 和 S 的接口没有定义完善，框架就无法实现可靠的 L 组件安全钩子——这也解释了为什么安全性经常被视为事后考虑，而不是首要的设计考量。依赖图还表明，V 组件位于所有治理决策的下游，这意味着评估质量受限于底层框架基础设施的质量。

下表 3 将常见的智体任务类型与其驾驭组件要求进行了映射。不同的任务类型对驾驭提出了不同的要求，而且这些要求并非线性扩展——状态 (S) 和生命周期 (L) 组件从可选到必需的转变标志着驾驭复杂性的结构性转变。

其中：× = 非必需；∼ = 部分/条件性；必需 = 任务完成所必需的结构性组件。

此表 3 的关键信息是，随着任务复杂性的增加，组件需求呈非线性增长。S 和 L 组件从“可选”到“必需”的转变，标志着聊天机器人（至少需要 E、T 和 C）与智体系统（此外还需要持久状态管理和生命周期策略执行）之间的界限。多智体和具身任务需要所有六个组件，因为它们同时要求较长的执行周期（需要 E 的复杂性）、广泛的工具访问权限（T）、大量的上下文构建（C）、跨回合状态（S）、策略监控（L）和可衡量的结果（V）。任何缺少 S 或 L 的部署都应被理解为聊天机器人模式部署，无论系统是否使用“智体”API——智体系统的边界由这些治理组件的存在来定义，而不是由模型的规划能力来定义。

此正式框架建立分析智体驾驭的词汇表。但要理解为什么这六个组件组成的特定组合会成为主流架构，必须考察其发展历程。驾驭的概念并非一蹴而就；相反，它是在数十年的软件工程实践中逐步演进的——从静态代码分析中的测试框架，到强化学习中的执行框架，再到现代智体基础设施。了解这段历史，既能揭示六组件模式的必然性，也能揭示其他架构被探索但最终放弃的历程。

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