[文件名称]: Agent Systems with Harness Engineering.pdf
[文件内容开始]

===== 第 1 页 =====

带有 Harness 工具架工程的智能体系统

唐鑫昱 (^{1,4*}) , 彭瀚 (^{1,4*}) , 陈国新 (^{1,4}) , 石雨泽 (^{2}) , 苏子韬 (^{1,4}) , 刘沛羽 (^{3}) , 赵鑫 (^{1,4}) , 李雅文 (^{2}) , 薛哲 (^{2})
(^{1}) 中国人民大学高瓴人工智能学院,
(^{2}) 北京邮电大学,
(^{3}) 对外经济贸易大学,
(^{4}) 大模型与智能治理北京市重点实验室.
txy20010310@163. com, panospeng@ruc.edu.cn, batmanfly@gmail.com

摘要

开发有效的智能体系统一直是人工智能领域一个长期的前沿课题。近期基于大语言模型的智能体的出现标志着一个范式转变，然而，即使是非常有能力的模型，在没有足够的系统支持的情况下部署，也会在长时程场景中表现出系统性的失败，包括中间目标丢失、工具调用错误以及无法整合环境反馈。这些失败反映的不是模型训练上的差距，而是大语言模型的单轮生成接口与现实世界问题解决所具有的有状态、迭代性质之间的结构性不匹配。在本文中，我们将周边的基础设施形式化为工具架 (harness)，并引入工具架工程 (harness engineering) 作为对工具架及其所支持的模型的联合优化。两者之间的关系本质上是协同的：一个设计良好的工具架通过结构化记忆、错误恢复和自适应上下文管理来释放模型的潜在能力，而一个有能力的模型则使工具架能够实现更复杂的工作流程，这些工作流程对于较弱的推理器来说是不可行的。我们提出了工具架组件的结构化分类法，涵盖了智能体工作流、记忆系统、技能库和多智能体编排，并分析了每个组件如何影响系统级性能，从当前实践中提炼出设计原则和架构权衡。我们进一步回顾了来自工具架侧和模型侧的优化策略，并总结了跨软件工程、深度研究、工具使用、计算机使用和科学发现领域的评估基准。通过将关注点从智能体能完成什么转移到周边基础设施如何使其能够完成这些任务，本文旨在通过原则性的工具架工程，为构建可靠、可扩展和可控的智能体系统提供实践参考。

关键词： 工具架工程，智能体系统
日期： 2026年5月18日。
代码仓库： https://github.com/RUCAIBox/awesome-agent-harness

===== 第 2 页 =====

目录

1 引言 4
2 工具架工程基础 6
2.1 工具架工程的概念 6
2.2 工具架工程的演进 8
2.2.1 动作接口：连接模型与环境 8
2.2.2 工作流基础设施：编排持久化工作空间 8
2.2.3 以用户为中心的持久化：跨会话和跨渠道的连续性 8
2.3 与相关概念的联系 9
3 工具架的设计 9
3.1 智能体工作流 9
3.1.1 环境感知 10
3.1.2 任务规划 11
3.1.3 动作执行 12
3.2 记忆系统 12
3.2.1 短期记忆 13
3.2.2 长期记忆 13
3.3 技能库 14
3.3.1 技能获取 14
3.3.2 技能管理 15
3.3.3 技能维护 15
3.4 多智能体编排 16
3.4.1 协调架构 16
3.4.2 通信机制 17
3.5 代表性智能体系统的比较视图 18
4 面向工具架的模型适配 19
4.1 上下文工程 20
4.1.1 上下文设计 20
4.1.2 上下文管理 20
4.2 智能体训练 21

===== 第 3 页 =====

   4.2.1 环境构建 21
   4.2.2 训练优化算法 22
   4.2.3 监督信号 23
   4.2.4 基础设施 23

5 工具架能力与评估 24
5.1 深度研究 24
5.2 软件工程 26
5.3 工具使用与函数调用 26
5.4 计算机使用与图形用户界面（GUI）基础定位 27
5.5 机器学习工程与科学研究 27
6 未来方向 28
6.1 效率 28
6.2 安全性 29
6.3 持续学习 30
6.4 状态与环境建模 30
6.5 具身化工具架 31
6.6 评估 32
7 结论 32

===== 第 4 页 =====

1 引言

开发有效的智能体系统一直是人工智能领域一个长期的前沿课题[1]，其历史可以追溯到早期的符号智能体[2]和基于规则的设计[3]，这些设计在简化的、结构化的环境中表现出色，但在复杂性和可扩展性方面遇到困难。几十年来，通过强化学习[4]和机器人智能体[5]取得的进展带来了适应性行为；然而，现实世界的部署仍然受到决策脆弱和泛化能力有限的阻碍。

近期大语言模型（LLM）[6]为基础智能体系统的出现标志着一个范式转变：通过利用丰富的常识知识、自然语言交互和复杂推理，大语言模型使智能体能够进行规划、使用工具并适应开放式的场景，极大地增强了它们在现实世界应用中的实用性，例如软件自动化[7, 8]、科学发现[9, 10]和个人助理[11, 12]。鉴于这些卓越的能力，最初基于大语言模型的智能体开发将重点放在了模型本身，而非智能体系统中的支持机制上。

然而，随着任务变得越来越复杂，一个根本性的挑战出现了：即使是能力很强的大语言模型，在没有足够系统支持的情况下部署，也会在长时程场景中表现出系统性的失败[13, 14]。例如，模型在多步规划过程中经常丢失中间目标，使用错误参数或在不当时刻调用工具，并且无法整合环境反馈来纠正早期的错误[15]。这些缺点不仅仅是模型训练上的差距，无法通过未来的规模扩展来弥补；它们反映了LLM的单轮生成接口与现实世界问题解决所具有的有状态、迭代性质之间的结构性不匹配。因此，一个日益增长的共识是：一个AI系统的实际能力，既取决于其底层模型生成能力，也同样取决于其支持性工具架的设计。

因此，考虑支持性系统的设计和开发同样重要。在LLM的背景下，智能体系统最初被定义为构建在LLM之上的整体框架，包含关键模块——记忆、工具、规划和动作。此后，该领域已扩展到包括提示和上下文工程[16, 17]，这些工程在不改变模型权重的情况下提高LLM的能力。最近，智能体框架通过重新设计智能体-环境接口本身而取得了进展。与早期依赖自由形式文本动作或有限工具调用的系统不同，现代框架如OpenClaw [11] 和 Hermes Agent [12] 引入了能力极强的动作空间（例如，bash命令、文件编辑、搜索操作）、有状态的沙盒化执行环境以及直接的计算机控制——旨在实现无需人工监督的自主、长时程任务执行。这些设计选择将瓶颈从原始的LLM推理转移到了健壮的系统脚手架，将智能体从脆弱的概念验证转变为可部署于现实世界任务的系统。

这种认识——即实际能力既取决于系统脚手架，也取决于模型本身——自然地引出了对这种“支持性系统”更精确的描述。在最近的文献中，术语工具架 (harness) 被用来特指围绕和扩展基础模型的[13, 14]基础设施。因此，我们将一个智能体系统分解为两个基本组成部分：一个作为推理引擎的基础模型，负责语言理解、生成和决策；以及一个支持性的工具架，它管理执行流程、工具调用、记忆管理、上下文构建、安全执行以及与外部环境的多步协调[18, 19, 20, 21]。没有工具架，模型只是一个被动的文本生成器；只有当嵌入到设计良好的工具架中时，它才能成为一个功能性的智能体。

至关重要的是，这两个组件之间的关系不仅仅是组合性的，而且是内在协同的：对一个组件的改进能释放另一个组件的潜在能力，产生任何一方单独都无法实现的系统级收益。例如，一个更有能力的模型可以遵循更细致的指令，从而使工具架能够实现复杂的多步工作流，这对于较弱的推理器是不可行的。相反，一个设计良好的工具架，提供结构化的记忆检索、错误恢复机制和自适应上下文管理，即使是一个中等能力的模型也能在长时程任务上维持连贯的性能，而这些任务本会超出其独立能力范围。工具架工程在两条互补的前沿推进这种协同作用。在工具架侧，它设计更有效的工作流、记忆架构、技能库和编排机制，以构建和引导模型行为。在模型侧，它通过上下文工程和智能体训练来调整基础模型本身，以使其

===== 第 5 页 =====

图 1：具有工具架工程的代表性智能体系统时间线。下半部分展示了工具架侧的优化，涵盖四个类别：智能体工作流、记忆系统、技能库和多智能体编排。上半部分展示了模型侧的适配，包括两个类别：上下文工程和智能体训练。这两个维度本质上是协同的——工具架设计塑造了为模型适配提供信息的交互模式，而改进后的模型能力反过来又能够实现更复杂的工具架架构——共同推动开发更有能力、更健壮和更具泛化能力的智能体系统。

更有效地利用工具架提供的能力。因此，我们将工具架工程形式化为两个组件的联合优化：设计工具架以适应模型的优势和局限性，同时调整模型以利用工具架的功能。正是这种双向的协同优化赋予了智能体系统在复杂现实世界任务中所需的可靠性、适应性和可控性。

在本文中，我们聚焦于研究支持性基础设施如何促成有效的智能体行为，将分析焦点从智能体能力转移到产生这些能力的机制上。具体而言，本文的贡献有三个方面：

• 我们将工具架工程形式化为一个独特的研究范式，建立其概念基础并阐明其与相邻范式的联系。这为理解将语言模型提升为自主智能体的基础设施提供了一个统一的词汇。
• 我们提出了一个结构化的工具架组件分类法，涵盖智能体工作流、记忆系统、技能库和多智能体编排，并系统分析了每个组件如何影响系统级性能，从当前实践中提炼出设计原则、架构权衡和实证最佳实践。
• 我们全面回顾了在工具架和底层模型两方面运作的优化策略，并总结了在深度研究、软件工程、工具使用、计算机使用和科学发现等领域评估工具架有效性的基准。

本文的其余部分组织如下。第2节建立工具架工程的概念基础。第3节详细介绍工具架设计的主要组成部分。第4节探讨模型适配技术，包括上下文工程和智能体训练。第5节总结跨深度研究、软件工程、工具使用、计算机使用和科学研究领域的评估基准。第6节指出开放的挑战和未来方向。

===== 第 6 页 =====

2 工具架工程基础

图 2：本文结构概览。

2 工具架工程基础

一个智能体系统的实际能力不仅取决于基础模型，同样取决于支持它的编排层 (orchestration layer) [74, 75]。这一层结构化了推理步骤，协调了工具交互，并管理着跨扩展任务时程的迭代执行[76, 77]。我们将其系统性的研究和设计称为工具架工程 (harness engineering)，特别关注随着智能体系统从简单的模型-环境耦合演变为能力日益增强且持久化的辅助形式，其范围如何扩展。在本节中，我们通过三个逐步扩大的视角介绍这一概念（第2.1节），追溯其跨三个演进阶段的演变（第2.2节），并阐明其与相关概念的关系（第2.3节）。

2.1 工具架工程的概念

工具架工程的概念允许多种解释。我们将这些解释组织为三个逐步扩大的视角，每个视角都包含前一个。

视角 I：作为结构分解的工具架工程。 第一个也是最基础的视角提供了一种结构分解：一个智能体系统由两个组成要素构成，即一个基础模型及其支持性的工具架。基础模型提供语言理解、推理和生成方面的核心能力，而工具架构成了编排层，调解模型与外部环境之间的所有交互。具体而言，工具架管理工具调用（例如，API调用和代码执行）、上下文维护（例如，对话历史和记忆管理）、状态持久化（例如，中间结果的存储）和执行控制（例如，终止条件和重试策略）。因此，系统级性能由两个组成部分共同决定：没有工具架的基础模型仍然只是一个能够产生输出但无法参与持续的、目标导向行为的推理引擎；只有当与设计得当的工具架结合时，它才成为一个功能齐全的

===== 第 7 页 =====

图 3：工具架架构演进中的三个层次，说明了其范围和职责的逐步扩展。层次 1（动作接口：连接模型与环境）：工具架将模型输出转换为可执行的工具调用（例如，文件操作、浏览器交互、沙盒执行），并返回环境观察结果，建立一个基本的动作-观察循环。层次 2（工作流基础设施：编排持久化工作空间）：工具架维护持久化的工作空间状态，并在技术环境（如终端、编译器和版本控制系统）内编排检查代码、应用编辑、运行命令以及基于执行反馈进行修订的迭代工作流。层次 3（以用户为中心的持久化：跨会话和跨渠道的连续性）：工具架管理用户档案、记忆、对话历史、日常任务和持续任务，协调多个专门的智能体，并提供跨会话和跨渠道的连续性。

智能体，能够在现实世界环境中执行任务。然而，这个视角主要仍然是描述性的，因为它指出了模型周围是什么，但没有规定支持性结构应如何设计或改进。

视角 II：作为框架构建的工具架工程。 第二个视角从描述转向实现，将工具架工程等同于智能体框架的设计与构建。从这个观点来看，构建一个工具架远不止于用一个薄的接口层包装模型；它意味着创建一个完整的、可重用的软件基础设施，以支持多步交互、工具集成和复杂的智能体工作流。在此解释下，工具架工程的目标与智能体框架开发的目标一致：为开发者提供可扩展、健壮且随时可部署的基础设施，用于构建智能体应用程序。虽然这个视角涵盖了大部分实际的工程工作，但它只关注单方向的优化，并未解决如何调整模型本身以更好地利用支持性基础设施的互补问题。

视角 III：作为协同增强的工具架工程。 本文采纳了一个更广泛、更综合的观点。我们不将工具架工程视为结构分解（视角 I）或框架构建（视角 II），而是将其定位为一种针对智能体系统的协同优化方法论。视角 I 关注“智能体系统由什么构成？”，视角 II 考察“如何在模型周围构建脚手架？”，而视角 III 则探讨“如何联合优化脚手架和模型以最大化系统级性能？”这个协同公式包含两个互补的方向。第一个方向针对支持模型的脚手架进行优化（第3节），包括智能体工作流的构建、记忆系统的设计、技能库的策展以及多智能体协作的编排。第二个方向针对模型本身的优化，使其更好地与工具架协作（第4节），包括上下文工程和智能体训练。这两个方向单独来看都不足够：一个架构良好的脚手架无法弥补模型缺乏基础推理能力的缺陷，同样，一个高能力的模型在一个结构糟糕的系统中也无法发挥其全部潜力。正是通过双方的协同优化，智能体系统才能获得在现实世界的复杂、长时程任务中所需的可靠性、可扩展性和可控性。

===== 第 8 页 =====

2.2 工具架工程的演进

随着智能体系统被部署在日益复杂的环境中，工具架必须支持更广泛的行动、更长时程的状态以及更强大的委托控制形式。为了满足这些日益增长的需求，工具架工程经历了三个不同的阶段，每个阶段都扩展了编排层所负责的范围。在第一阶段，工具架主要充当模型与环境之间的接口。在第二阶段，它成为在持久化技术工作空间内运行的开发者助理的执行层。在第三阶段，它充当个人助理的骨干，维护与个体用户随时间及跨通信渠道的连续性。

2.2.1 动作接口：连接模型与环境

工具架的基础层建立了模型与其外部环境之间的连接。在这一层，工具架将模型与外部工具（如文件系统[78]、浏览器[79]和可执行运行时[80]）连接起来，将输出转换为可执行的动作，并将环境结果返回以用于下一个推理步骤。这种闭环结构将基础模型从一个被动的文本生成器提升为一个能够对其环境采取行动的智能体[81]。

其核心机制是一个重复的推理、行动和观察循环：模型生成一个行动，观察结果，并根据更新的环境状态调整其下一步行动[82, 80]。一个代表性的例子是 ReAct [82]，它通过直接将推理轨迹与环境交互交织在一起，使这个循环变得明确。后续的工作通过整合程序执行[80]、API调用[25]和各种外部工具[83]来扩展相同的原理。最近，智能体系统将这些交互组织在统一的运行时内，使得跨不同工具和环境的行动和观察能够被一致地处理[84, 78]。

2.2.2 工作流基础设施：编排持久化工作空间

在动作接口的基础上，第二层引入了持久化工作空间管理和多步工作流编排。这一层的工具架不再仅仅是连接模型和单个工具的桥梁；相反，它管理工作空间状态，协调一系列开发行动，并跨步骤携带执行上下文，使模型能够检查代码[7]、应用编辑[85]、运行命令[86]并使用结果来指导后续行动[8]。这种闭环的开发周期将模型从一个一次性的代码生成器提升为一个能够迭代优化其输出直到任务完成的开发者助理[87]。

这一层的核心机制是一个生成、执行和修订的重复循环：模型生成代码，工具架在工作空间内执行代码，观察结果（如测试结果或错误信息），并将这些结果反馈给下一次迭代[74, 88]。一个代表性的例子是 SWEagent [7]，它表明强大的任务性能不仅取决于代码生成质量，关键还取决于工具架如何结构化导航、反馈和迭代修正。像 OpenHands [74] 和 Claude Code [88] 这样的系统通过将模型置于具有完整 shell、文件系统和版本控制访问权限的真实开发环境中，支持持续的编辑和验证循环，而不是孤立的生成，从而进一步扩展了这一原理。在软件工程之外，LLM-in-Sandbox [26] 表明，同样的工作空间基础设施（被虚拟化为一个最小的代码沙盒）能为一般的非编码任务带来一致的性能提升。

2.2.3 以用户为中心的持久化：跨会话和跨渠道的连续性

第三层通过引入跨会话、任务和通信渠道与个体用户的连续性，将工具架扩展到单次任务执行之外。前一层在工作空间内维护任务状态，而这一层管理用户历史、偏好、日常任务和持续任务作为持久化状态，从而支持基于先前交互的个性化辅助[89, 90]。这种纵向交互循环将模型从一个无状态的任务执行者提升为一个能够进行持续的、上下文感知交互的个人助理[91, 92]。

这一层的定义性要求是与同一用户在时间上的连续性，即使任务跨越不同的会话或通信渠道[93, 90]。这使得能够实现更长期的、个性化的辅助，积累对用户需求的知识并相应地进行调整。一个代表性的例子是 OpenClaw [94]，它将助理视为一个持久的、面向用户的智能体，支持记忆、档案管理以及在真实工具和长时程交互中的委托行动。

===== 第 9 页 =====

2.3 与相关概念的联系

工具架工程是一个新兴的概念，与智能体系统研究中的几个既定概念相交。在本小节中，我们阐明工具架工程如何与这些相关概念联系并在此基础上发展。

智能体框架 (Agent Framework)。 与工具架工程最密切相关的概念是智能体框架。此类框架为构建、部署和管理智能体应用程序提供可重用的基础设施，通常涵盖工具接口、执行环境、交互协议以及对多步任务完成的支持[76, 84]。它们的核心贡献是一个具体的实现基础，将智能体行为转化为一个工作流程。虽然这两个概念有共同之处，但它们在不同的层面上运作，并解决根本不同的问题。智能体框架关注如何实现一个智能体系统的工程问题——即通过具体的代码和软件架构来实现设计。相比之下，工具架工程解决的是如何系统地优化智能体系统整体性能的方法论问题，不仅包括对脚手架的改进，还包括对模型本身的适配。这些优化策略在不同框架和模型中是通用的，不依赖于任何特定框架的实现细节。因此，一个智能体框架可以被看作是工具架的一个具体实例化，而工具架工程则是一个元层面的学科，指导此类实例化的设计。在本文中，我们采纳这一更广泛的视角，并通过两个互补的方向系统地考察构建更有效智能体系统的设计原则：脚手架优化和模型优化。

其他相关概念。 除了智能体框架，还有其他三个概念家族与工具架工程密切相关，每个都为工具架工程整合到一个统一的系统级方法论中贡献了必要的要素。

• 提示工程 (prompt engineering) 和上下文工程 (context engineering) 专注于精心设计或结构化输入，以从LLM中获得更好的响应[95, 96, 97]。工具架工程将这些技术作为其模型侧优化的一部分包含进来，同时进一步组织跨整个智能体工作流的多步执行、状态管理和控制流。
• 工具使用 (tool use) 考察LLM是否以及如何调用外部函数或API [98, 99]。工具架工程将工具使用作为其脚手架设计中的一个组件，此外还处理何时调用工具、如何处理失败以及如何将观察结果整合到后续推理中。
• 开发者助理 (developer assistant) 和个人助理 (personal assistant) 根据其应用角色（例如，编码支持或日常任务辅助[74, 89]）对智能体系统进行分类。工具架工程提供了底层的编排结构，包括上下文管理、进度跟踪和健壮执行，使此类助理角色能够有效运作。

3 工具架的设计

在第2节中建立了工具架工程的概念框架之后，我们现在转向工具架侧 (scaffold side)：围绕基础模型并塑造其智能体行为的架构组件。这些组件并非作为孤立的模块运作，而是形成一个集成的管道。智能体工作流在一个闭环中编排感知、规划和行动；记忆系统将智能体的有效时程扩展到单个上下文窗口之外；技能库积累可重用的行为单元；多智能体编排将系统扩展到超出任何单个模型实例能力的任务。我们将依次考察每个组件，重点关注在已部署系统中被证明有效的设计原则。

3.1 智能体工作流

智能体工作流是智能体工具架的操作核心，将一个无状态的语言模型转变为一个目标导向的系统[100, 101]。因为语言模型执行一次前向传播后就终止了，看起来持久的行为完全是由工具架构建的，工具架维护消息历史并在每次调用时重放它[102]。工具架通过将模型包装在一个循环中来弥补这种无状态性：调用模型，解析响应，执行指示的工具，并将结果反馈给下一次迭代。这个循环产生了三个紧密耦合的阶段。工具架首先感知环境以收集任务相关信息（第3.1.1节），然后基于累积状态规划下一步行动（第3.1.2节），最后执行选定的行动，其结果成为下一次迭代的输入（第3.1.3节）。

===== 第 10 页 =====

图 4：工具架设计空间及其与外部环境和模型适配的交互概览。左图：外部环境为智能体执行和学习提供基础信号。中图：四个主要的工具架侧组件共同构成工具架基础设施。智能体工作流管理感知-规划-行动执行循环；记忆系统跨步骤和会话维护持久化上下文；技能库积累可重用能力以防止重复探索；多智能体编排将复杂任务分解给专门的智能体。右图：通过上下文工程和智能体训练进行的模型侧适配，通过塑造底层模型的输入信息和推理行为来补充工具架侧。工具架侧的构建和模型侧的适配共同构成了工具架工程的两大互补支柱，它们的协同优化共同塑造了整体智能体能力。

3.1.1 环境感知

环境感知是每次循环迭代的入口点。在智能体可以规划或行动之前，工具架必须构建一个当前环境的表示，该表示既要准确又要足够紧凑以适合上下文预算。这涉及两个互补的挑战：从原始环境中提取与任务相关的信息，并将其编码成下游规划可以可靠消费的形式。

观察提取 (Observation Extraction)。 核心挑战是从复杂界面（无论是网页[103, 104]、桌面应用程序[105, 106]还是移动应用程序[69]）中提取空间和逻辑关系。早期方法从UI层次结构中提取结构化特征，并将其转换为文本表示[107, 108]。这些表示易于解析，但通常庞大且冗余，从而激发了压缩技术的发展，以修剪与任务无关的内容，同时保留交互元素[109]。纯文本表示缺乏视觉基础，当布局偏离预期层次结构时会失败[110]。基于屏幕截图的可视化提取解决了这一限制，通过在大规模GUI语料库上进行预训练[111]和在交互轨迹上进行强化学习[112, 113]获得了进一步的提升。然而，纯视觉方法仍然存在空间模糊性。因此，当前的实践现状通过多模态提取结合这两种渠道，将结构化元数据与屏幕截图一起解析，以获得包含小部件类型、文本内容和空间属性的元素级描述[114]。这种从文本到视觉再到多模态提取的进展不仅仅是为了更丰富的输入；每一步都引入了其自身的成本。它反映了信息完整性、令牌效率和提取可靠性之间的基本权衡。每个额外的感知通道都提供了更完整的环境图景，但消耗了更多的上下文预算，而每个转换步骤都会引入噪声的机会。更丰富的感知并不总是能带来更好的下游决策；工程挑战在于针对给定任务最大化每个令牌的有用信号。

状态表示 (State Representation)。 一旦信息被提取，工具架必须将其编码为模型可用于规划的形式。常见的方法采用结构化标记

===== 第 11 页 =====

如 JSON [115]、DOM风格的树[7, 108]或代码格式[116]来生成紧凑的文本描述。当这些描述变得过长时，它们会超出上下文窗口或通过信息过载降低规划质量[117]。简单的启发式方法，如屏蔽无关属性、截断到令牌预算以内或仅保留最近的观察结果，可以有效地管理这种增长[109, 118]。除了这种表面级的剪枝，一些方法使用辅助模型来总结或过滤环境状态[119]，但这些方法无法捕捉元素之间的关联方式。为了对这种关系进行建模，最近的工作将完整环境提炼为紧凑的、面向任务的世界模型，仅保留相关的对象、属性和转换[120]，或构建显式结构（如场景图[121, 122]），将环境压缩成对规划最有用的少量实体和空间配置。工业实践更进一步，将这种过滤思想视为核心设计原则：感知接口应被设计为智能体-计算机接口 (Agent-Computer Interface) 而非人机接口[123]。工具架仅在上下文中呈现对决策有实质性影响的少数信号，而将冗长的细节写入文件，供智能体按需查询。这确保了上下文预算被花费在具有最高决策价值的令牌上。

3.1.2 任务规划

任务规划决定了工具架如何分解目标并在循环迭代中维护计划状态。复杂的任务无法在单次推理步骤中解决，原因有两个耦合的约束：自回归误差累积导致成功率在推理深度超过模型单次传递所能维持的深度时急剧下降，并且有限的上下文窗口无法同时容纳目标、完整的环境状态和所有相关约束。任务分解通过将长推理链分割成由校准点分隔的较短的链来解决这两个约束，其中每个新链从通过工具执行确认的状态开始，而不是从未经核实的中间令牌开始。更细粒度的分解插入了更多的校准点，提高了端到端的可靠性，但代价是增加了循环迭代次数和总令牌消耗。现有工作从两个角度解决这个问题：如何将复杂目标拆分为中间子任务，以及如何将这些子任务转换为可执行的行动序列。

任务分解 (Task Decomposition)。 早期工作将中间推理组织成日益灵活的结构，从线性链[95, 124]发展到分支树[125]和允许路径合并与重用的图[126]。这些方法依赖于预定义的推理结构，不针对特定任务进行调整。较新的方法[127, 128]通过允许智能体在执行开始前分析任务并选择合适的推理策略来缓解这种不匹配。有两个新兴方向完全超越了静态结构。第一个是跨会话增量分解 (cross-session incremental decomposition) [129]。当一个任务跨越多个上下文窗口时，单次规划会失败，因为没有单个会话持有完整的问题状态。一个实用的解决方案是让初始智能体生成一个完整的功能需求文档，后续智能体使用该文档以及中间工件和版本控制历史来恢复规划状态。每个新的上下文窗口引入一个新的智能体，它从这个外部化的状态重建任务理解，然后从上一个会话停止的地方继续。第二个是由外部验证器驱动的自适应分解 (adaptive decomposition driven by external verifiers) [123]。对于那些难以自然并行的任务，一个已知良好的预言机可以作为参考点。在一个已部署的示例中，多个智能体协作构建一个C编译器；工具架将源文件子集分配给智能体构建的编译器，用GCC编译其余部分，并交叉比较输出以检测差异。这将一个固有的顺序任务转化为可并行的子任务，其边界由运行时反馈动态确定，而不是预先固定。

计划生成 (Plan Generation)。 除了分解，当每一步都包含明确的工具使用规范[130]以及用依赖感知结构（使得独立的子任务可以并行运行）[23]取代线性序列时，计划质量会得到提升。计划的表示格式也会影响循环效率。用自然语言描述的计划可能消耗数百个令牌，而用结构化工具名称和参数表示的同一计划所需的令牌少得多。然而，过于激进的压缩会剥离每一步背后的意图和假设，在需要重新规划时显著降低重试尝试的质量[129]。这种张力表明，计划生成最好不被视为一次性输出，而应被视为一个活的人工制品，工具架循环会持续验证和调整它。

===== 第 12 页 =====

3.1.3 动作执行

一旦计划生成，智能体必须将其转化为影响外部环境的具体操作。我们从两个角度考察动作执行：智能体如何选择和调用离散的外部工具，以及它们如何在动态、有状态的环境中运作。

工具调用 (Tool Invocation)。 工具调用关注工具架如何使智能体能够为给定任务选择并调用合适的工具。早期工作[25]将工具令牌直接嵌入到模型的词汇表中，仅支持顺序的单工具调用。后续方法[131]解析智能体输出为可执行的函数调用，支持分支和多步组合。为了将这些能力应用于已部署环境，实践系统[7, 132]将文件系统和shell命令等组件暴露为具有显式模式的结构化工具接口。一个趋同的研究方向表明，可靠的工具调用必须通过可执行环境反馈来学习，而不是事先指定。那些通过强化学习、使用运行时执行结果作为直接信号来训练智能体的方法，在单工具可靠性和多步组合方面都显示出一致的提升[133, 134, 135]。除了调用机制，工具接口的粒度是一个关键的工具架设计选择。像bash这样的通用接口提供了最大的灵活性，但留给工具架执行白名单、验证参数或隔离权限的能力很小。具有显式模式的专用接口（如模型上下文协议（Model Context Protocol）中定义的接口）以灵活性换取接口级的安全检查[136]。类似地，像SquRL [137]这样的领域特定系统通过从目标领域抽象出面向任务的工具[138]来提供专用接口。正确的平衡取决于部署领域的安全要求。当可用工具数量达到数百个时，会出现一个相关的扩展挑战。在传统模式下，每个工具结果都返回到上下文窗口，长工具链会累积大量的令牌开销。使用MCP [139]的代码执行通过让模型编写一个代码块来在沙盒内顺序调用多个工具来解决这个问题；只有最终结果返回上下文，将一个多轮工具链压缩为单次模型调用。

环境交互 (Environment Interaction)。 环境交互关注智能体如何在有状态的环境中执行行动，这些环境中行动的后果会跨步骤持续存在。早期工作[82]将智能体置于具有无限行动空间的原始环境中，使得可靠地将意图转化为可执行行动变得困难。后续工作[7]引入了结构化的智能体-环境接口，暴露可用的行动、预期格式以及由此产生的状态变化。在此基础上，过滤方法[140]将当前计划与基于环境的奖励信号相结合，以在执行前剔除不可行或不相关的行动。即使有了结构良好且经过过滤的行动，可靠的交互要求执行必须与主机系统隔离。沙盒机制[79, 78]将智能体行为限制在受控容器内，这些容器限制文件系统访问、限制网络暴露，并在尝试之间实现干净的状态重置。然而，仅靠隔离并不能保证安全；最近的分析[141]表明，沙盒化的智能体在规划、记忆和执行边界仍然表现出系统性的漏洞，需要主动的轨迹级审计来检测。

讨论

• 有限的上下文窗口是一个共享预算，感知、规划和执行相互竞争：丰富一个阶段必然会减少其他阶段可用的资源。
• 智能体循环的核心价值不在于逐步执行子任务，而在于创建校准点，让外部反馈纠正累积的模型漂移。
• 循环可靠性更多地取决于工具架设计；没有适当的支持，智能体会将所有工作压缩到单个上下文窗口并在接近限制时过早终止。

3.2 记忆系统

除了即时的执行循环，一个有能力的工具架必须维护智能体在超出任何单个上下文窗口容量的推理步骤中的一致性。这需要明确的记忆系统来管理保留什么、压缩什么以及卸载什么。指导原则不是尽可能多地记忆，而是只持久化对未来决策具有复用价值的信息[142, 129]。我们将沿着这两个维度考察记忆系统：短期记忆 (short-term memory)（第3.2.1节）管理单次会话内的信息，而长期记忆 (long-term memory)（第3.2.2节）积累超出即时上下文的持久知识。

===== 第 13 页 =====

3.2.1 短期记忆

短期记忆管理智能体如何在单次会话内追踪和利用信息。工具架必须主动决定在上下文窗口内保留、压缩或丢弃哪些中间状态。关键的设计洞察是区分可重构信息 (reconstructible information)（如可以重新获取的工具输出，因此可以安全丢弃）和不可替代信息 (irreplaceable information)（如推理结论和用户决策，必须保留或压缩）[142]。我们讨论两个互补的方面：工作记忆 (working memory)，它在主动推理期间管理中间状态；以及对话记忆 (conversational memory)，它维护跨轮次的对话历史。

工作记忆 (Working Memory)。 工作记忆为任务执行期间生成的中间状态提供一个动态存储。早期设计依赖于交织推理步骤、行动和观察的线性轨迹[82, 143]，但线性格式难以处理涉及分支或回溯的非线性推理，常常导致信息重复[144]或关键上下文丢失[27]。后续工作引入了结构化替代方案：基于图的方法[145]将中间思想组织为支持分支和重组的连接节点，而基于工作流的方法[146]进一步通过可重用结构来组织执行状态。除了格式，工业实践揭示并非所有中间状态共享相同的生命周期。工具调用结果通常可以重新获取，应首先被清除；任务进度检查点必须持久化以支持跨窗口恢复[142, 129]。这种生命周期感知的分解将工作记忆管理从统一压缩转向基于可重构性的选择性保留。

对话记忆 (Conversational Memory)。 在长对话中，早期轮次的重要信息（如用户偏好或先前决策）可能随着历史增长超出上下文窗口而丢失。早期方法将对话历史外部存储，并使用分层缓冲区[147]或分页机制[148]按需检索相关内容，但这些方法操作粒度粗糙，可能将相关上下文分割开[149]。后来通过将历史划分为功能单元（如任务状态[150]和用户档案[151]）实现了更细粒度的分割，尽管仍然孤立地处理每个单元。最近的研究[152, 153]通过记忆元素之间的显式链接来恢复跨片段依赖关系，而最新的努力[154, 155]转向自适应管理，根据 evolving 的对话状态学习保留、更新或丢弃什么。这种自适应方法已经大规模部署。例如，Claude Code 在长会话期间使用压缩生成结构化摘要，保留关键决策的同时回收上下文预算[142]，表明可重构信息和不可替代信息之间的区别可以在生产系统中得以实施。

3.2.2 长期记忆

短期记忆管理活动上下文窗口，而长期记忆使智能体能够积累跨会话持久化的知识。由于模型在调用之间不维护持久状态，所有存储、索引和检索长期知识的机制都必须由工具架实现。从功能角度看，长期记忆分为三个具有不同生命周期的类别[156, 157]：语义记忆 (semantic memory)（事实、用户偏好、项目知识）、情节记忆 (episodic memory)（过去的交互、失败和成功轨迹）以及程序记忆 (procedural memory)（任务规则和工作流）。每个类别需要不同的写入策略和检索机制。此外，并非所有长期记忆都应该实时写入；必须立即生效的偏好属于热路径记忆 (hot-path memory)，而经验提取和冲突解决最好在任务完成后异步处理[157]。我们考察两种组织形式：结构化记忆 (structured memory)，它以显式关系格式维护知识；以及非结构化记忆 (unstructured memory)，它将信息存储为纯文本。

结构化记忆 (Structured Memory)。 结构化记忆以关系形式（如知识图谱[158]或显式链接的条目序列[31]）组织累积的知识。早期基于图的设计[159, 160]将知识存储为节点，关系存储为边，支持高效遍历，但通常只能容纳一种信息类型。后来的方法[161, 162]使用节点标签在单一结构中统一多种类型，但仍需要预先指定固定的模式，限制了向未见任务的泛化。最近的工作[31, 29]通过允许每个条目携带自身的上下文描述，并根据语义相似性和使用模式（而非预定义类型）链接到其他条目，消除了这种僵化。

===== 第 14 页 =====

非结构化记忆 (Unstructured Memory)。 现实世界的经验通常以缺乏显式关系组织的纯文本形式存在[163]。早期工作[148, 30]存储自由文本并使用相似度匹配进行检索，但长条目消耗大量空间，且过时的信息难以更新。随后的一系列工作[24, 164]通过以自然语言保留过去的交互和反思使记忆更明确，使其更易于检查、编辑和提炼为可重用的指南。然而，这些系统依赖手工设计的规则来决定存储或丢弃什么。最近的工作[154, 165, 166, 167, 168]将记忆操作视为可学习的决策而非固定启发式，并扩展到长时程个性化[169]和按需记忆扩展[170]。

展望未来，长期记忆正从个体智能体的内部组件演变为共享的基础设施层。像 Mem0 [171] 和 OpenMemory [172] 这样的系统将记忆抽象为一个可移植的个人上下文层，通过像 MCP 这样的协议暴露标准化接口，使得不同的智能体可以按需访问相同的记忆。在技术层面，记忆成为一个可重用的服务，而不是每个框架独立实现的东西。在所有权层面，本地优先的设计将数据存储在用户的机器上，使记忆在短暂的智能体会话中持续存在，并实现跨应用程序的上下文连续性。这种架构转变也模糊了记忆和技能之间的界限：当智能体反复从情节记忆中提炼可重用的程序并将其打包为可执行指令时，记忆从情节形式过渡到程序形式，并最终成为一个可调用的技能[173]。从这个意义上说，下一节讨论的技能库可以被视为记忆系统的一种高级形式。

讨论

• 记忆的核心挑战不再是容量，而是治理：无限制的累积会引入陈旧冲突、检索退化和持续的行为偏差。
• 上下文预算应被视为一等运行时资源，需要主动监控和捍卫，而不是模型填充直到溢出的被动容器。
• 智能体状态不是同质的——对话历史、工具结果、任务检查点和长期知识在持久性和更新频率上不同，必须分开管理，而不是混合到一个无差别的上下文中。
• 工具架应强制执行有纪律的生命周期：压缩和清除处理会话内的膨胀，而只有那些仍然有价值的跨会话知识才进入持久层；可重用的程序进一步从情节记忆毕业为可调用的技能。
• 记忆正从内部模块演变为共享的、可移植的基础设施层：智能体是短暂的，但记忆是持久的，通过用户拥有的上下文实现跨应用连续性[171, 173]。

3.3 技能库

虽然智能体工作流支持行动，记忆系统保留状态，但两者都不能防止智能体重新发现以前解决过的问题的解决方案。技能库 (skill libraries) 通过持久化可重用的行为单元来弥补这一差距，当类似情况再次出现时，智能体可以调用这些单元[35, 174, 175]。从概念上讲，技能库与第3.2节讨论的记忆系统处在一个连续谱上。当智能体反复从情节记忆中提取可操作的程序并将其编码为可执行指令时，记忆逐渐从情节形式过渡到程序形式[176]。在生产中，这种过渡日益明确：技能被编写、版本化，并作为包含指令、脚本和资源的自包含包进行分发[177, 178]。因此，技能库设计的范围超出了单纯的学习，涵盖了构建、运行时路由和生命周期治理[179, 180]。本节考察在构建和操作此类库时出现的三个核心问题：技能如何获取（第3.3.1节），它们在运行时如何组织和检索（第3.3.2节），以及随着库的增长如何进行维护（第3.3.3节）。

3.3.1 技能获取

技能获取将成功的行为转化为可重用的能力。工具架拦截成功的轨迹，触发提取例程，并持久化结果以备后续检索。核心困难在于泛化：在一个轨迹中观察到的行为必须被充分抽象，以便转移到原始上下文之外。现有方法从三个方向解决这个问题。

===== 第 15 页 =====

从示范中学习 (Learning from Demonstration)。 最直接的途径是从先前的成功行为中推导出技能[35, 174]。早期方法模仿工具调用日志[25, 181, 182, 183]或重放专家轨迹[184, 185]，产生的技能可以复现观察到的行动但泛化能力差[186]。将完整轨迹注入上下文也会引入冗余[187]。因此，后续工作将轨迹分解为可以重新组合成更高级能力的原子单元[34, 188]，或在先前的记录中识别可重用的结构作为更广泛技能创建的种子[189]。较新的方法进一步将文本知识作为结构化指导整合到组合过程中[190, 191]。

从经验中学习 (Learning from Experience)。 智能体可以不依赖外部示范，而是通过自身与环境交互来获取技能。早期的强化学习公式[192, 193]产生了任务特定的策略，这些策略迁移效果差[194, 33]。后来的工作将问题重新定义为从交互中发现可重用的行为结构[195, 196, 197, 198, 199, 200]：成功的行动序列被打包成技能，超越原始事件持续存在。最近的方法通过引导探索向可能产生新颖、可泛化行为的环境区域，进一步提高了覆盖率[201, 36, 202]。在一个极端案例中，Tool-R0 [203] 消除了对任何预定义任务规范的需求，完全通过自我对弈来训练工具调用技能，使用可执行环境反馈作为唯一的学习信号。

从外部资源中学习 (Learning from External Resources)。 技能根本不需要源自智能体轨迹。工业实践越来越多地从文档、代码仓库和API定义中构建技能[204, 177]。Anthropic的Agent Skills框架[177, 205]将技能定义为基于目录的指令、脚本和资源包，智能体在运行时发现并加载它们。OpenAI的Skills API [178] 通过版本化的包扩展了这个模型，这些包可以在托管环境中上传、管理和挂载。在这些系统中，技能的功能类似于版本化的软件工件，具有与传统包类似的生命周期管理。

3.3.2 技能管理

一旦库中包含大量技能，就会出现两个组织问题：如何表示技能以便高效访问，以及如何在运行时选择正确的技能而不至于淹没模型的上下文[206]。

技能表示 (Skill Representation)。 早期工作[184, 35]将技能编码为连续嵌入，支持基于相似性的索引，但牺牲了内部结构。后来的方法采用程序化格式，如可执行代码片段[190]、结构化推理过程[34, 195, 207]或统一的工具使用模式[208, 37]，使组合和转移更加明确[194]。生产系统更进一步，将技能表示为包含指令、脚本、元数据和测试的完整包[177, 178]。这种包级设计实现了渐进式披露：智能体最初只加载元数据或目录级摘要，并按需展开为完整指令[177, 209]。因为任何时候只有技能的一小部分占据上下文，库可以扩展到远超出全注入方法支持的范围[210, 179]。

技能检索 (Skill Retrieval)。 基于嵌入的相似性[195, 184]提供了一种自然的检索方法，但当任务需要组合多个技能时会退化，如在多智能体协调[211, 212]或具身操作[213]中。分层检索通过首先解析粗粒度意图，然后在较窄的子集内搜索来缓解这个问题[208, 210]。上下文敏感的检索根据环境状态、先前轨迹或中间失败来调节选择[214, 215]，将检索变成一个迭代决策过程[216]。在生产规模，当库包含数千个重叠条目时，检索变成一个学习到的路由问题。SkillRouter [179, 206] 通过一个对完整技能文本进行操作的检索-重排流水线证明了这一点，表明仅暴露名称和描述会降低路由准确性。这一发现表明技能内容本身是关键的路由信号，专用的学习路由器优于仅基于元数据的匹配。

3.3.3 技能维护

随着库的增长，挑战从获取和检索转向长期健康。一个静态库不可避免地会积累冗余、过时或冲突的条目，从而降低检索精度和执行可靠性。

===== 第 16 页 =====

库策展 (Library Curation)。 技能在现实环境中会退化，因为工具API会更改，外部依赖会演变[217, 218]。工具架必须检测执行失败，将其追溯到特定技能，并触发有针对性的更新。在库层面，增长引入了重叠和陈旧，损害了检索器区分候选者的能力[179, 210]。因此，主动策展，包括合并冗余条目、修剪无效条目以及分层组织存活的技能，对于持续性能至关重要。

技能治理 (Skill Governance)。 当技能被视为版本化的可执行包[178, 219]时，它们继承了传统软件的治理要求。新版本需要正确性测试，现有技能需要随着环境变化进行回归检查[219]。跨平台分发进一步引入了供应链风险：不正确或恶意的技能可能持续破坏智能体行为[220, 177]。因此，大规模可靠操作需要版本控制、兼容性检查、冲突检测和原则性的弃用。

讨论

• 特异性和泛化性之间存在一个基本的张力：从轨迹中提取的技能往往狭窄且脆弱，而高度抽象的技能缺乏可靠执行所需的操作精度。
• 一旦技能成为版本化的工件，它们就继承了软件生命周期的负担——API变化、环境迁移和静默错误传播——这需要主动维护，而不仅仅是提取。
• 记忆和技能之间的界限正在模糊：反复提炼的情节记忆变得与技能难以区分，这表明未来的工具架应将经验积累、程序提取和技能维护统一到一个受治理的管道中。

3.4 多智能体编排

然而设计良好的单智能体工具架在并行性、专业化和容错性方面面临固有的限制。多智能体编排 (multi-agent orchestration) 通过协调多个智能体（每个都运行自己的工作流和记忆）朝向共享的任务目标来解决这些限制。产品实践确定了多智能体系统交付价值的三个轴[221]：上下文保护 (context protection)，其中每个智能体在隔离的上下文窗口中运行；并行化 (parallelization)，它用令牌消耗换取更短的墙钟时间；以及专业化 (specialization)，通过按领域拆分智能体来避免当单个智能体负载过多工具时发生的性能下降。这一原则塑造了下面探讨的两个中心设计问题：协调架构 (coordination architectures)，它定义了智能体的结构组织方式；以及通信机制 (communication mechanisms)，它定义了智能体在这些结构内部交换信息的方式。

3.4.1 协调架构

协调架构定义了控制权、任务分配和结果聚合如何在智能体之间分布。现有方法根据系统是否依赖核心智能体进行划分：集中式架构 (centralized architectures) 使用一个控制器来管理整个系统，而去中心化架构 (decentralized architectures) 通过对等智能体之间的交互实现协调。

集中式架构 (Centralized Architectures)。 集中式架构使用一个中心智能体来分解任务，将子任务分配给专门的子智能体，并聚合其结果。早期的系统如MetaGPT [39] 和 ChatDev [40] 通过手动设计的工作流组织角色专业化的智能体，但这些模式构建成本高，且难以跨任务迁移。后续工作转向自主协调：AutoGen [38] 将调度视为可配置的对话和路由层，而MegaAgent [222] 使智能体能够在运行时协商职责，允许组织在没有预定义编排的情况下涌现[223, 22, 224, 225]。生产中一个特别成功的集中式模式是验证子智能体 (verification subagent) [221]，其中一个专门的子智能体测试或验证主智能体的工作。这种模式成功是因为验证需要最少的上下文传递：验证器可以对系统进行黑盒测试，而无需了解其完整的构建历史，避免了推理在智能体之间传递时发生的上下文退化。然而，扩展集中式系统并不像添加更多子智能体那么简单。最近的发现[226]表明，具有良好设计记忆的小团队可以胜过更大的团队，

===== 第 17 页 =====

这表明每个智能体的协调基础设施的质量比团队规模本身更重要。

去中心化架构 (Decentralized Architectures)。 去中心化架构[227]探索了在没有中央协调员的情况下，如何通过对等智能体之间的交互涌现出协作。AgentVerse [41] 表明，智能体可以通过交互自发地形成角色并分工，而 DyLAN [228] 通过一个随任务进展而演变的动态协作图扩展了这一点[42, 229, 230]。这种设计的一个已知风险是过早共识 (premature consensus)：如果智能体过快达成一致，少数但正确的观点可能被忽略。CONSENSAGENT [231] 通过分配不对称角色来解决这个问题，使得少数派立场在最终决策前能得到结构化考虑。去中心化协调并不总是需要专门构建的通信协议。在一个大规模的多智能体编码项目[232]中，16个智能体在没有直接通信的情况下协调：每个智能体通过向共享目录写入文件来声明任务，冲突通过 git 合并冲突来显现。这表明现有的软件基础设施（如文件系统和版本控制）可以作为协调的底层。共享状态模式 (shared-state pattern) [233] 推广了这一点：智能体通过一个共享的状态空间进行协作，在彼此发现的基础上构建，无需中央路由器，这消除了单点故障，但存在重复工作和冲突决策的风险。

3.4.2 通信机制

通信机制解决智能体如何在多智能体系统内交换信息的问题。没有设计良好的通信，即使结构良好的协调架构也会退化为断开的模型调用，而不是一个连贯的协作系统。核心挑战是决定共享什么信息以及以何种粒度共享。仅共享最终结果是不够的，因为行动携带着隐式决策，缺乏结果背后推理的智能体很可能做出冲突的选择[234]。共享完整的智能体轨迹保留了最大信息，但造成了过高的通信开销。一个实用的折衷方案是将行动历史压缩为关键决策和事件的摘要，在保持信息密度的同时控制成本[234]。现有工作从两个方向解决这一挑战：基于辩论的方法 (debate-based methods)，通过批评和分歧提高输出质量；以及基于协作的方法 (collaboration-based methods)，支持跨智能体的协调执行。

基于辩论的方法 (Debate-based Methods)。 基于辩论的方法解决了单智能体的一个基本限制：沿着一条思路推理使得发现中间错误变得困难。一个自然的解决方案是让多个智能体从不同的角色[39, 235, 236]和立场[237, 238]执行相同的任务，以便智能体在形成最终答案之前挑战和完善彼此的输出[239]。然而，多智能体讨论并不自动导致更好的结果[240]。如果没有整合冲突观点的机制，交互可能变得重复或不稳定。因此，最近的工作将辩论组织在明确的反思循环[241]或以共识为导向的决策程序[231]周围，这些程序总结冲突的观点并将其整合为连贯的结果。

基于协作的方法 (Collaboration-based Methods)。 基于协作的方法将智能体协调成一个连贯的执行结构，其中不同的角色贡献互补的能力[242, 243, 40]。早期工作依赖显式的角色专业化和预定义的工作流[244, 39]，使系统可控但在动态任务变化下脆弱[223]。最近的研究转向更具适应性的方法，包括基于图的规划（在执行过程中重组协调）[245, 246]、联合优化协作策略的强化学习[247, 248, 249, 250]以及根据实时进度调整策略的环境感知协调[251]。另一个新兴方向是工件中介的协作 (artifact-mediated collaboration)，智能体通过持久的共享项目状态（如包含分析、计划和代码的权限限定工作空间）而非短暂的对话交接进行协调[252]。协作的一个实际挑战是生产系统中识别的读写不对称性 (read-write asymmetry) [253]：主要进行读取的多智能体系统远比主要进行写入的系统容易构建。当多个智能体同时写入时，它们的隐式决策可能冲突，产生难以合并的不兼容输出[234]。这种不对称性表明，协作写入任务比并行读取任务需要更强的协调协议。

===== 第 18 页 =====

表 1：跨四个工具架组件的代表性智能体系统的设计原则。

组件	Claude Code	OpenClaw	Hermes Agent
智能体工作流	• 计划-然后-执行分离 • 分层权限控制 • 交互式用户确认	• 声明式上下文组装 • 上下文驱动的工具选择 • 统一的多渠道路由	• 预算上限的执行循环 • 安全感知的上下文过滤 • 平台自适应的提示设计
记忆系统	• 自动上下文压缩 • 分层文件持久化 • 类型化的跨会话记忆	• 基于向量的语义检索 • 基于维基的链接知识 • 自动记忆捕获和召回	• 阈值触发的压缩 • 对话驱动的用户画像 • 基于快照的记忆加载
技能库	• 用户编写的斜杠命令 • 智能体辅助的技能创建 • 持久化的计划任务	• 集中式技能注册表 • 标准化的技能接口 • 基于角色的技能分配	• 智能体管理的生命周期控制 • 自动策展和淘汰 • 安全验证的激活
多智能体编排	• 基于角色的专家子智能体 • 仓库级工作空间隔离 • 前台和后台执行	• 深度受限的智能体生成 • 基于身份的智能体配置 • 跨框架通信协议	• 显式的编排者角色 • 持久的跨智能体任务板 • 并行多模型执行

讨论

• 每种协调模式都带有固有的张力：集中式设计存在单点瓶颈风险，而去中心化设计增加了调试和行为预测的难度[233]。
• 分解应遵循上下文边界，而非问题类型：按角色拆分会产生持续的协调开销，而持有上下文的智能体应拥有所有相关子任务[221]。
• 单个智能体的失败可以重定向整个探索轨迹，产生级联错误。
• 让一个多智能体系统基本工作需要约20%的努力，而使其可靠工作需要剩下的约80%的努力[233]。
• 多智能体编排可能在重走单智能体系统的道路：手动设计的协调模式最终可能被内化为原生的模型能力。

3.5 代表性智能体系统的比较视图

为了使上述设计原则具体化，我们现在考察三个代表性智能体系统——Claude Code [88]、OpenClaw [11] 和 Hermes Agent [12]——如何在实践中实例化四个工具架组件。每个智能体系统都体现了一种独特的设计理念，表1总结了主要差异。

智能体工作流。 这三个系统以根本不同的方式管理感知、规划和行动循环。Claude Code 强制执行严格的计划-然后-执行分离：智能体首先进入只读阶段以探索代码库并起草结构化计划，然后在执行任何修改之前请求交互式用户确认，并且随后的每次工具调用都通过一个分层权限控制机制，以确保没有重大行动在未经明确同意的情况下进行。OpenClaw 将循环视为可组合的基础设施，其中声明式上下文组装指定信息如何进入、持久存在于和离开上下文窗口，上下文驱动的工具选择根据运行时信号（如认证状态或渠道类型）在每次模型调用前修剪可用的工具集，统一的多渠道路由允许单个智能体通过一个调度接口服务数十个消息传递平台。Hermes Agent 强调自主自治，实现了一个预算上限的执行循环，为每个任务设定明确的步数限制，安全感知的上下文过滤在文件到达模型前扫描每个文件以查找提示注入威胁，以及平台自适应的提示设计，根据运行时环境定制系统指令，使智能体能够在没有人工监督的情况下可靠运行。

===== 第 19 页 =====

记忆系统。 这三个系统在工作记忆和长期知识的管理方式上有显著差异。Claude Code 以上下文窗口为中心 (context-window-centric)：对话本身充当工作记忆，一旦变得过长，系统通过将其压缩成结构化摘要来执行自动上下文压缩；长期知识存在于用户、项目和目录级别的分层文件持久化中，这些文件自动加载到每个会话中，并由一个类型化的跨会话记忆存储补充，该存储按类别（如用户偏好、反馈和项目状态）组织持久化的事实。OpenClaw 采用双轨设计 (dual-track design)，将基于向量的语义检索（在每次模型调用前检索相关事实）与基于维基的链接知识（维护人类可读、相互链接的持久化文章）配对，两者都由自动记忆捕获和召回支撑，记录显著事实并在无需用户明确命令的情况下检索它们。Hermes Agent 专注于流式上下文管理 (streaming context management)：阈值触发的压缩实时监控令牌使用，一旦超过可配置的界限就压缩上下文，同时保护最早和最新的消息，以便任务框架和最近状态得以保留；对于长期用户建模，它通过一个外部服务采用对话驱动的用户画像，该服务通过对过去对话进行推理来维护一个不断演变的用户画像，并采用基于快照的记忆加载，将会话开始时的记忆文件作为冻结快照摄入，以便会话中期的更新不会使提示缓存失效。

技能库。 这三个系统以递增的自主性水平组织可重用的能力。Claude Code 将技能视为用户编写的斜杠命令 (user-authored slash commands)，每个技能是一个带有结构化元数据的markdown文件；一个内置的辅助工具支持智能体辅助的技能创建，以便系统可以自行引导新技能，持久的计划任务让重复性工作表现得像持久技能，所有这些都受插件阻止列表和细粒度权限允许列表的约束。OpenClaw 转向一个集中式技能注册表 (centralized skill registry)，将每个技能打包为标准化的技能接口，并通过中心进行发布以便发现和安装，基于角色的技能分配确保每个智能体只接收与其指定角色相关的技能，清晰地将技能编写与消费分离。Hermes Agent 通过实现智能体管理的生命周期控制 (agent-managed lifecycle control) 走得更远：技能通过三个递增细节层次进行渐进式披露，以便智能体只加载它需要的内容，自动策展和淘汰移除在可配置时期内未被调用的技能，安全验证的激活在启用前验证每个技能。

多智能体编排。 所有三个系统都支持子智能体委派，但在协调理念上有所不同。Claude Code 遵循基于角色的专家子智能体 (role-based specialist subagents)模式，生成具有显式角色注释（如探索者、规划者或通用）的智能体，每个智能体接收受约束的工具集；仓库级工作空间隔离为每个子智能体提供其自己的工作副本，前台和后台执行选项将每个子智能体保持在自己的干净上下文窗口中。OpenClaw 采取协议优先 (protocol-first) 的立场，采用深度受限的智能体生成来限制递归以防止失控链，基于身份的智能体配置通过作用域配置文件定义每个智能体的角色、个性和行为约束，以及一个跨框架通信协议，使构建在不同栈上的智能体能够作为一等关注点进行互操作。Hermes Agent 提供了最丰富的协调工具包，通过定义一个显式的编排者角色 (orchestrator role)，将协调智能体与执行任务的叶子智能体分开，维护一个持久的跨智能体任务板以进行共享工作跟踪，并且最独特的是支持并行多模型执行，同时查询多个语言模型并综合它们的输出。

讨论

• 相同的四个工具架组件可以在非常不同的设计理念下实例化：Claude Code 优化人机交互安全，OpenClaw 优化可组合的扩展性，Hermes Agent 优化自主自治。
• 这些权衡直接反映了部署环境：交互式开发者辅助、多渠道平台编排和自主终端执行需要根本不同的控制、灵活性和自主性平衡。

4 面向工具架的模型适配

在工具架工程的协同框架内，设计周边的工具架必须由模型侧的适配 (model-side adaptation) 来补充。标准的大语言模型是为通用文本生成而训练的，

===== 第 20 页 =====

缺乏内置的调用工具、遵循多步工作流或处理环境反馈的能力。我们将模型适配组织为两个类别：上下文工程 (Context Engineering)（第4.1节），它通过工具架暴露的信息在推理时塑造模型行为；以及智能体训练 (Agentic Training)（第4.2节），通过模仿和强化学习将智能体特定行为内化到模型参数中。

4.1 上下文工程

推理期间提供的上下文信息决定了大语言模型智能体的行为和能力上限。如第3节所述，工具架控制模型在每个步骤观察到的内容，包括任务指令、工具描述、检索到的知识和交互历史。上下文工程通过决定暴露哪些信息、如何构建信息以及如何在整个多轮交互中更新信息来调整模型行为。与一般的提示不同，面向智能体工具架的上下文工程专门针对工具使用、工作流执行以及在有限上下文预算下的长时程决策。我们涵盖两个互补的阶段：上下文设计 (Context Design)（第4.1.1节），它在模型行动前构建高质量的输入；以及上下文管理 (Context Management)（第4.1.2节），它在扩展的交互过程中压缩和维护上下文状态。

4.1.1 上下文设计

上下文设计专注于在智能体推理或行动之前构建最优输入。这依赖于两个核心策略：提示工程 (Prompt Engineering)，它构建提供给模型的指令；以及上下文检索 (Context Retrieval)，它通过整合外部信息来扩展模型的知识。

提示工程 (Prompt Engineering)。 提示工程通过精心设计的输入来引导模型行为，无需参数更新。早期工作专注于构建任务指令和示范[254, 255, 125, 126]，而后续研究表明显式的角色描述可以有效引发目标行为[256, 227]。这在多智能体系统中特别有用，其中智能体承担专门的角色并在共享的工作流中进行协调[159, 45]。手动提示设计的一个常见限制是其对人工努力的严重依赖。为了解决这个问题，自动提示优化 (automated prompt optimization) 使模型能够优化自己的提示。APE [16] 使用LLM本身来生成和选择候选指令，而后续方法通过自我完善的循环完全消除了人工干预[257, 258, 259]。

上下文检索 (Context Retrieval)。 上下文检索动态整合外部知识，以克服参数化记忆的局限性。传统的检索增强生成（RAG）依赖于静态的“一次检索”范式和平面的文本块，这在复杂的多跳查询中表现不佳[260]。后续方法沿两个维度推进了检索：检索时机 (retrieval timing) 和 知识结构 (knowledge structure)。对于检索时机，主动机制允许模型将推理与信息收集交织在一起，根据中间状态动态决定何时检索以及如何重写查询[261, 262, 263, 264, 265, 266, 44]。对于知识结构，基于图或表的索引捕获检索项之间的显式关系[267, 268, 269, 43]。在这些进展的基础上，智能体检索 (agentic retrieval) 将检索操作直接集成到模型的迭代执行循环中。由 ReAct [82] 开创，这种范式使智能体能够在推理和查询之间交替进行。随后的框架进一步将检索抽象为自动构建的模块[270]和分层策略[271]，而多智能体生态系统通过协作推理将检索分配到专门的角色以处理复杂任务[272]。

4.1.2 上下文管理

原始上下文通常是嘈杂且过长的，存在上下文溢出和推理退化的风险[273]。上下文管理涉及两个过程：上下文处理 (Context Processing)，它为即时推理压缩信息；以及上下文更新 (Context Updating)，它在扩展的交互中维护累积的经验。

上下文处理 (Context Processing)。 上下文处理压缩已组装的上下文，以在模型有限的窗口内维持最大信息密度。早期方法通过基于重要性剪枝令牌来缩短输入文本[274, 275, 276]。虽然对单轮查询有效，但这些方法忽略了自主智能体的顺序动态。为了防止长

===== 第 21 页 =====

时程任务中的上下文溢出，最近的框架专门为多轮智能体轨迹设计了压缩机制。ACON [277] 应用强化学习于交互历史，以最小化上下文使用，同时维护长期记忆。AgentDiet [46] 剪枝冗余信息以降低推理成本，AgentFold [278] 通过分层整合来浓缩子任务，SWEPruner [279] 为编码智能体执行任务感知的自适应剪枝。除了剪枝现有轨迹，IterResearch [280, 281] 将上下文管理重构为工作空间重建，用包含原始问题、演进中的报告以及最新动作-观察对的紧凑状态取代完整历史重放。

上下文更新 (Context Updating)。 上下文更新在扩展的交互中动态维护和演进智能体的上下文状态，决定记住什么、遗忘什么以及如何重组经验。在基础层面，智能体通过反思积累经验。Reflexion [24] 开创了这一点，让智能体总结失败原因以供未来尝试，而 AWM [146] 从成功轨迹中提炼出可重用的工作流模式。随着经验增长，平面存储变得不切实际，促使了分层记忆架构 (hierarchical memory architectures) [148] 的出现，该架构将记忆划分为快速上下文窗口和带有自动页面交换的慢速外部存储。随后的框架通过图数据库[29]、流式缓存[282]和时间衰减遗忘[30]增强了这一点。然而，被动存储本身无法支持主动的记忆生命周期管理。最近的研究赋予智能体组织互联知识[32, 283, 284]、标记重要记忆[31]和删除过时信息[285, 286]的能力。

4.2 智能体训练

虽然上下文工程在推理时调整模型行为，但其有效性受限于模型的内在能力，因为参数保持不变。智能体训练 (Agentic training) 通过两个广泛的范式将领域知识和智能体特定行为直接内化到模型参数中，从而对此进行补充：监督微调 (Supervised Fine-Tuning, SFT)，它从示范或教师生成的轨迹中学习；以及强化学习 (Reinforcement Learning, RL)，它通过环境交互反馈来优化策略。将这些方法应用于智能体引入了独特的挑战：构建交互环境、在稀疏奖励下进行信用分配、稳定策略优化以及管理大规模工程开销。我们讨论四个方面：环境构建 (Environment Construction)（第4.2.1节）探讨如何构建交互式训练环境；奖励设计 (Reward Design)（第4.2.3节）考察如何获取稳定的奖励信号；训练优化算法 (Training Optimization Algorithms)（第4.2.2节）讨论基于SFT和RL的策略更新；基础设施 (Infrastructure)（第4.2.4节）讨论大规模分布式训练的系统。

4.2.1 环境构建

训练环境构成智能体训练的基础。由于工具架调解模型与外部世界之间的交互，环境保真度决定了学得的策略是否能迁移到现实世界部署。现有环境根据反馈机制分为三种类型：基于规则的环境 (rule-based environments) 提供来自执行结果的确定性二元奖励；基于模拟的环境 (simulation-based environments) 使用代理模型来近似真实世界动态；真实世界环境 (real-world environments) 将智能体直接置于具有真实反馈的实时系统中。

基于规则的环境 (Rule-Based Environments)。 基于规则的环境已经从预定义的沙盒发展到严格可验证的度量标准。早期研究[287]在具有预定义状态转换的基于规则的沙盒中训练智能体，支持家庭[288]或电子商务[289]场景。然而，预定义动作需要手动设计，并且难以泛化到具有大动作空间的复杂推理。最近的工作[290, 291, 292, 293]表明，有了可靠的二元结果反馈，智能体可以在无需人工标注的情况下持续自我改进。这一原则在数学[294, 295, 10]和编码[296, 132]领域迅速被采纳，在这些领域中，精确的验证器提供可靠的反馈。最近的环境通过过程生成推理任务[297]和支持长时程规划的有状态企业沙盒[298]进一步扩展。在软件工程中，Scale-SWE [299] 通过将原始的GitHub拉取请求转换为经过验证的 Docker化 SWE 任务，并通过沙盒化的多智能体工作流生成训练轨迹，从而扩展了环境构建。

基于模拟的环境 (Simulation-Based Environments)。 基于模拟的环境使用代理模型提供低成本反馈来近似真实世界动态。一个关键的挑战是，在物理场景中，LLM作为模拟器的方法容易产生幻觉。为了提高保真度，一些方法[300]在大规模交互数据上训练世界模型以实现跨领域泛化，而神经模拟器通过建模屏幕转换将其扩展到操作系统界面[301]。除了保真度，提高推演效率同样重要。硬件加速的物理引擎支持大规模并行的多智能体推演[302, 303]，而 RAP [304] 将模拟转移到模型内部，允许其在行动前比较可能的结果。为了进一步提高准确性，最近的工作[305]用确定性的数据库支持机制取代生成代理，该机制将动作作为 SQL 事务执行。

真实世界环境 (Real-World Environments)。 真实世界环境将智能体直接置于具有真实、不断变化的反馈的实时数字或物理系统中。早期研究[108, 306, 307]使用受控的静态网站，但这些缺乏真实性。后来的工作引入了实际的数字噪声，如网络延迟和动态内容加载[113, 308, 309, 310]。为了进一步扩展规模，一些研究[311, 312, 313]让智能体使用实时操作日志作为反馈自由浏览实时网络。物理世界是最复杂的环境，因为机器人动作必须遵循真实物理并遵守严格的安全规则。具身环境[314, 315, 316]将实时传感器数据与基于物理的安全检查相结合，使智能体能够将高级推理转化为真实的物理动作。

4.2.2 训练优化算法

在构建了交互环境和奖励信号之后，智能体训练需要优化算法来更新模型参数。现有方法遵循两个广泛的范式：监督微调 (Supervised Fine-Tuning)，它通过模仿示范或自生成的轨迹来学习智能体行为；以及强化学习 (Reinforcement Learning)，它通过与环境反馈的试错交互来优化策略。

监督微调 (Supervised Fine-Tuning)。 监督微调通过在多轮轨迹（包含中间计划、工具调用和环境观察）上进行直接优化，将智能体能力迁移到目标模型中。根据数据来源，方法分为来自教师模型的离线策略蒸馏 (off-policy distillation) 和来自学生模型自身的在线策略生成 (on-policy generation)。离线策略蒸馏在由更强模型预先生成的轨迹上进行训练。FireAct [317] 首次将其应用于智能体场景，表明微调后的小模型可以在工具使用任务上胜过更大的模型。由于仅使用智能体数据可能会降低通用能力，后来的研究通过轨迹-指令混合[318]、格式与推理信号解耦[319]以及统一的多轮格式化[320]来提高数据质量。为了提高可扩展性，最近的工作通过环境交互和系统化的数据工程来合成训练数据[119, 321, 322, 323, 299]。在这一系列工作中，ClawGym [324] 为 Claw 风格的个人智能体引入了一个可扩展的、以合成为中心的框架，生成基于工作空间的任务，并将其进一步连接到智能体训练和诊断基准构建。当轨迹同时包含规划和执行信号时，多教师监督[325, 326]或特定片段的损失[327]可以将这些组件分离以实现更好的迁移。在线策略蒸馏通过让学生生成自己的轨迹而教师提供密集监督来解决训练-测试分布不匹配的问题。早期方法优化散度目标，如前向KL [328]和反向KL [329]。为了在较大能力差距下稳定训练，后续方法调整目标 logits [330]或剪裁奖励信号[331]。除了模仿，ExOPD [332] 将蒸馏与KL正则化的RL相结合，以推动学生超越教师，而 GAD [333] 使用基于判别器的反馈将在线策略蒸馏扩展到黑盒教师。

强化学习方法 (Reinforcement Learning Approaches)。 虽然监督微调内化了智能体行为，但它无法支持超出训练分布的探索。强化学习通过试错和奖励反馈来优化策略来解决这个问题。根据是否使用价值网络，方法分为基于评论家 (critic-based) 和无评论家 (critic-free) 算法。基于评论家的算法引入一个价值网络来估计优势并指导稳定的策略更新。PPO [334] 是代表性方法，其改进包括价值预训练[335]和奖励归一化[336, 337]。然而，标准PPO在处理长时程智能体时存在困难，因为跨多步轨迹的信用分配本质上是困难的。最近的方法通过将交互分解为规划层级[338, 339]或推理树[340]，以及在多智能体设置中为不同智能体分配单独的评论家[341]来解决这个问题。无评论家算法移除

===== 第 23 页 =====

了价值网络，通过基于偏好的优化直接更新策略。直接偏好优化（DPO）[342] 绕过了显式奖励建模，催生了一系列变体，包括 KTO [343]、SimPO [344] 和 ORPO [345]。然而，这些方法对偏好数据质量高度敏感，可能过度拟合标注者偏差。为了缓解这个问题，DeepSeekMath [346] 结合了 PPO 和 DPO 的优势，使用来自 PPO 训练的动态奖励信号来指导偏好学习。REMAX [347] 引入了一个基线来减少梯度方差，而无需单独的评论家网络。在多智能体设置中，Group-In-Group [348] 用组级奖励取代个体奖励来协调多智能体探索。

训练-测试差异与可扩展性。 无论选择哪种 RL 算法，智能体训练中的一个根本挑战是训练-测试差异 (train-test discrepancy)：在有限沙盒环境中优化的策略在迁移到开放式真实世界场景时经常失败。为了解决这个问题，一些研究探索了自演化和课程学习。Tree Search RL [349] 系统地探索动作树以增强泛化能力，Kimi k1.5 [350] 通过多阶段课程 scaling 强化学习。同样，Agentic Reinforced Policy Optimization [351] 在稳定训练的同时支持探索，MI-Agent [352] 将自我对弈与课程学习相结合，在机器学习工程任务上取得了强大结果。可扩展性 (scalability) 是另一个关键维度。随着任务复杂性的增加，轨迹变得更长，动作空间变得更大。APE [353] 通过由批评家指导的批评性采样来稳定训练，该批评家会动态识别高价值区域。在多智能体设置中，DR. MAS [382] 解决了多智能体 LLM 系统中信用分配不稳定和方差高的问题，MARTI [383] 提供了一个统一的框架，用于在多智能体 LLM 系统中进行强化训练和推理。将 RL 应用于现实世界的智能体通常需要资源效率 (resource efficiency)。WideSeek-RL [384] 用多智能体 RL 扩展了广度搜索，GrandCode [385] 通过智能体 RL 在竞争性编程中达到了大师级水平。Multimodal RL with Agentic Verifier [386] 将自演化与 RL 相结合，使模型能够从真实世界的反馈中持续改进。LineResearcher [387] 提供了一个可扩展的智能体 RL 训练框架，用于深度研究智能体。MM-DeepResearch [388] 将 RL 扩展到多模态深度研究，允许智能体通过长期交互优化搜索策略。这些进展共同表明了智能体 RL 的一个趋势：从在有限沙盒中优化策略转向构建能够泛化、扩展并随时间持续自我改进的智能体。

4.2.3 监督信号

环境构建完成后，奖励信号评估智能体行为并指导策略改进。根据监督粒度，出现两个互补的范式：结果级信号 (outcome-level signals) 仅在任务完成时提供反馈，而过程级信号 (process-level signals) 在每个步骤后提供密集监督。

结果级信号 (Outcome-Level Signals)。 结果级信号评估任务的最终状态，在易于验证但难以求解的领域效果良好。在数学[354, 355]、代码生成[356, 357]、软件工程[358]和深度研究[49, 312, 359]任务中，客观的执行反馈作为自然的结果信号。一种常见的方法[358, 360]使用二元信号让模型从正确和错误的轨迹中学习，驱动大规模自我对弈和迭代修复。为了进一步减少对人工标签的依赖，TTRL [361] 通过对采样解进行多数投票来估计奖励，从而在没有黄金标注的情况下实现 RL。在信号极其稀疏的形式定理证明中，DeepSeek-Prover-v1.5 [362] 结合了证明助理反馈、基于树的搜索和探索奖励。

过程级奖励 (Process-Level Rewards)。 结果级奖励在长时程任务中面临信号稀疏性问题，因为模型无法确定哪些具体步骤导致了成功或失败。过程奖励模型 (Process Reward Models, PRMs) 通过在推理或行动每一步提供密集监督来解决这个问题。PRM 的演进涉及两个方面：监督信号构建和架构设计。对于信号构建，早期方法[363]依赖昂贵的人工标注。后续工作通过蒙特卡洛采样[364]和蒙特卡洛树搜索[365]自动化了这一过程。最近的扩展引入了用于 GUI 基础定位的连续空间奖励[366]和用于工具选择的细粒度奖励[51]。对于架构设计，传统的 PRM 是为每一步分配单一分数的判别模型[363]，但它们难以解释且容易产生偏差。生成式方法[367]通过自然语言推理执行步骤验证，使用思维链解释正确性，产生更透明的奖励信号。作为基于奖励的优化的补充，在精选轨迹上的监督微调提供了一种更直接的信号：高质量轨迹来源于人类专家[368]或通过拒绝采样从强模型中蒸馏[258]，许多系统结合两者来引导能力[4]。

4.2.4 基础设施

大规模智能体训练需要模型推理、环境交互、梯度计算和参数同步的协调调度。系统基础设施的效率直接限制了优化的速度和可扩展性。

通用框架 (General-Purpose Frameworks)。 通用智能体框架协调跨分布式集群的核心 RL 组件（演员、评论家、奖励和参考模型），同时支持多轮交互和持续的环境反馈。为了实现灵活调度，一些系统[369, 370, 47, 371]动态地将模型分配给特定的 GPU 分区，优化跨训练阶段的数据传输。为了提高吞吐量，异步架构[372, 373]将较慢的生成阶段与梯度更新分离，可高效扩展至数千个 GPU。为了集成环境，标准化的 API [374, 375] 将各种模拟器包装成统一的接口，以进行跨环境训练。然而，智能体的多轮性质导致了快速生成、慢速环境交互和繁重梯度更新之间的负载不平衡。最近的框架通过将生成和环境执行交织到单个工作流中[50, 348, 376, 377, 378, 379]，或在物理上跨机器分离阶段[380, 381]来解决这个问题。

===== 第 24 页 =====

5 工具架能力与评估

在这一部分，我们回顾了智能体工具架的代表性基准和评估方法。一个智能体系统的能力不仅取决于底层模型，同样取决于组织上下文、工具、执行和反馈的工具架。我们将这种在工具使用、部分可观测性、长执行轨迹和变化的环境反馈下维持有效行为的整体能力称为工具架能力 (harness capacity)。衡量工具架能力需要超越单步正确性；评估必须评估一个系统是否能够在与外部环境的多步交互中维持目标导向的进展。最近的基准通过在日益真实的环境中设置智能体、扩展任务时程和有状态性、并整合更丰富的评估信号（包括执行结果、环境状态、基于量规的判断和运行间可靠性）来体现这一观点[108, 389, 105, 390, 132, 53, 62, 60, 73, 391, 392, 59, 393, 68, 394]。因此，基准设计已成为工具架工程本身的一个组成部分，因为它决定了编排的哪些方面——上下文管理、工具协调、错误恢复——是可见和可衡量的。

5 工具架能力与评估

在这一部分，我们回顾了智能体工具架的代表性基准和评估方法。一个智能体系统的能力不仅取决于底层模型，同样取决于组织上下文、工具、执行和反馈的工具架。我们将这种在工具使用、部分可观测性、长执行轨迹和变化的环境反馈下维持有效行为的整体能力称为工具架能力 (harness capacity)。衡量工具架能力需要超越单步正确性；评估必须评估一个系统是否能够在与外部环境的多步交互中维持目标导向的进展。最近的基准通过在日益真实的环境中设置智能体、扩展任务时程和有状态性、并整合更丰富的评估信号（包括执行结果、环境状态、基于量规的判断和运行间可靠性）来体现这一观点[108, 389, 105, 390, 132, 53, 62, 60, 73, 391, 392, 59, 393, 68, 394]。因此，基准设计已成为工具架工程本身的一个组成部分，因为它决定了编排的哪些方面——上下文管理、工具协调、错误恢复——是可见和可衡量的。

5.1 深度研究

深度研究基准评估智能体是否能够支持超出短答案检索的开放式信息寻求。该领域已经从困难的浏览问题发展到更广泛的搜索、引用基础的报告撰写以及基于量规的合成质量评估。

广泛而复杂的搜索 (Broad and Complex Search)。 一个早期方向聚焦于信息密集型搜索而非短答案查找。BrowseComp 和 WideSearch 评估智能体是否能维持多步探索、跨搜索分支比较证据并保留有用的中间发现[52, 53, 54, 391]。LiveDRBench 特别值得注意的是，它根据广度、逻辑嵌套和搜索强度而非报告长度来描述深度研究。与经典的检索设置相比，这些基准强调搜索规划、证据积累以及工具架在搜索空间扩展时维持覆盖率的能力。

研究报告 (Research Reports)。 第二条工作线将注意力从信息收集转向基于引用的长式报告生成。DeepResearch Bench、ReportBench 和 LiveResearchBench 评估智能体是否能够将检索到的证据组织成连贯的输出，其主张、引用和结构可以直接检查[55, 395, 396, 392, 397, 398, 399]。这一方向更加重视报告组织、引用质量以及陈述与来源之间的事实一致性，揭示了性能在多大程度上依赖于工具架管理笔记、压缩文档和在生成过程中保持基础的能力。

综述生成与评估 (Survey Generation and Evaluation)。 最近的基准转向带有明确质量评估的综述式合成。ResearchRubrics 将深度研究提示与专家设计的量规配对，使覆盖率、基础性和分析质量成为一等评估目标[400, 392, 397]。这标志着从询问智能体是否能产生一个似是而非的工件，转向询问在结构化判断下合成是否完整、有充分依据且真正有用。即便如此，当前的深度研究基准仍然低估了来源可信度、在不断变化的网络内容下的引用忠实性、跨会话持久性以及在实践研究助理中重要的成本-延迟权衡。

===== 第 25 页 =====

表 2：智能体工具架工程中跨主要任务领域的代表性基准。

基准	日期	任务	评估机制
深度研究
BrowseComp	2025.04	基于浏览的信息寻求	基于规则
Deep Research Bench	2025.05	网络研究	基于规则
DeepResearch Bench	2025.06	深度研究报告生成	基于规则
ResearcherBench	2025.07	前沿科学探究	基于规则 / LLM评判
ReportBench	2025.08	学术综述/报告生成	基于规则
Characterizing Deep Research	2025.08	深度研究基准测试	基于规则
WideSearch	2025.08	智能体广泛信息寻求	基于规则
PDR-Bench	2025.09	个性化深度研究	LLM评判
LiveResearchBench	2025.10	真实世界中以用户为中心的深度研究	LLM评判
ResearchRubrics	2025.11	基于提示和量规的深度研究评估	LLM评判 / 人类评判
DEER	2025.12	深度研究专家报告	LLM评判
DeepSynth-Eval	2026.01	深度综述写作中的信息整合	基于规则
VideoDR-Benchmark	2026.01	开放网络上的视频深度研究	基于规则
DeepResearch Bench II	2026.01	基于量规的深度研究报告诊断	基于规则
MMDeepResearch-Bench	2026.01	多模态深度研究	基于规则 / LLM评判
DeepSurvey-Bench	2026.01	生成科学综述的学术价值	人类评判
DeepSearchQA	2026.01	穷举答案集生成	基于规则 / LLM评判
deepsynth-bench	2026.02	深度信息合成	基于规则 / LLM评判
软件工程
RepoBench	2023.06	仓库级代码自动补全	基于规则
SWE-bench	2023.10	真实世界GitHub问题解决	基于规则
CodeAgent	2024.01	工具集成的仓库级编码挑战	基于规则
LiveCodeBench	2024.03	整体性、抗污染的代码评估	基于规则
DevEval	2024.05	仓库对齐的代码生成	基于规则
BigCodeBench	2024.06	函数调用与复杂代码生成	基于规则
REPOCOD	2024.10	真实的仓库级编码	基于规则
HumanEval Pro / MBPP Pro	2024.12	自调用代码生成	基于规则
Commit10	2024.12	从零开始的库生成	基于规则
FEA-Bench	2025.03	仓库级特性实现	基于规则
AutoCodeBench	2025.08	自动代码基准生成	基于规则
SWE-Bench Pro	2025.09	长时程软件工程任务	基于规则
SWE-Sharp-Bench	2025.11	可复现的C#软件工程任务	基于规则
LoCoBench-Agent	2025.11	长上下文软件工程	基于规则
NL2Repo-Bench	2025.12	长时程仓库生成	基于规则
OmniCode	2026.02	多样化的软件工程智能体任务	基于规则
SWE-Universe	2026.02	可扩展的可验证软件环境	基于规则
FeatureBench	2026.02	复杂特性开发	基于规则
BeyondSWE	2026.03	超越单仓库错误修复	基于规则
工具使用与函数调用
API-Bank	2023.04	API规划与工具调用	基于规则
ToolLLM / ToolBench	2023.07	大规模真实世界工具使用	LLM评判
AgentBench	2023.08	多领域交互式智能体	基于规则
GAIA	2023.11	通用AI助理任务	基于规则
τ-bench	2024.06	工具-智能体-用户交互	基于规则
AppWorld	2024.07	可控制的应用和人物世界	基于规则
AssistantBench	2024.07	真实的网络助理任务	基于规则
ToolSandbox	2024.08	有状态的对话式工具使用	基于规则
ToolHop	2025.01	查询驱动的多跳工具使用	基于规则
DICE-BENCH	2025.06	多轮、多方对话工具使用	基于规则
τ²-Bench	2025.06	双控环境中的对话智能体	基于规则
BFCL	2025.07	函数调用与智能体评估	基于规则
FuncBenchGen	2025.09	可控的多步函数调用	基于规则
GAIA2	2025.09	真实生活助理任务	基于规则
CCTU	2026.03	复杂约束下的工具使用	基于规则
计算机使用与GUI基础定位
Mind2Web	2023.06	通用网络智能体交互	基于规则
WebArena	2023.07	真实的网络导航	基于规则
Android in the Wild	2023.07	Android设备控制	基于规则
VisualWebArena	2024.01	多模态视觉网络任务	基于规则
WorkArena	2024.03	常见知识工作网络任务	基于规则
OSWorld	2024.04	开放式的真实计算机使用	基于规则
AndroidWorld	2024.05	动态Android交互环境	基于规则
Windows Agent Arena	2024.09	多模态桌面操作系统任务	基于规则
WorldGUI	2025.02	桌面GUI自动化的动态测试	基于规则
ScreenSpot-Pro	2025.04	专业高分辨率GUI基础定位	基于规则
MMBench-GUI	2025.07	分层多平台GUI评估	基于规则
OSWorld-MCP	2025.10	计算机使用智能体中的MCP工具调用	基于规则
VenusBench-GD	2025.12	多平台GUI基础定位	基于规则
机器学习工程与科学研究
DS-1000	2022.11	数据科学代码生成	基于规则
MLAgentBench	2023.10	机器学习实验	基于规则
DA-Code	2024.10	智能体数据科学代码生成	基于规则
ScienceAgentBench	2024.10	数据驱动的科学发现	基于规则
MLE-bench	2024.10	机器学习工程	基于规则
PaperBench	2025.04	AI研究复现	LLM评判
TimeSeriesGym	2025.05	时间序列机器学习工程	基于规则
MLR-Bench	2025.05	开放式机器学习研究	LLM评判
FML-bench	2025.10	自动机器学习研究	基于规则
TRAJECT-Bench	2025.10	智能体工具使用的轨迹感知评估	基于规则 / LLM评判
ReplicatorBench	2026.02	社会和行为科学中的可复现性	LLM评判 / 人类评判

===== 第 26 页 =====

5.2 软件工程

软件工程基准评估智能体是否能够在真实的开发条件下运作，而不仅仅是生成独立的代码。评估已从仓库理解和问题修复扩展到特性实现和更广泛的工程工作流。

仓库任务 (Repository Tasks)。 一个早期方向聚焦于基于仓库的编码而非孤立生成。这些任务询问智能体是否能处理项目结构、跨文件依赖和文档，而不仅仅依赖本地提示。RepoBench 代表了检索和补全导向的评估，而 CodeAgentBench 和 REPOCOD 则转向具有工具使用和可执行评估的真实仓库级生成[401, 402, 56, 403]。仓库任务主要评估代码库基础定位、上下文选择和导航，为后续的问题解决和工程基准奠定基础。

问题解决 (Issue Resolution)。 第二条线聚焦于可执行的修复和问题级调试。SWE-bench 将真实问题解决作为核心任务，SWE-Bench Pro 将其扩展到更长时程、多文件、企业级问题，LiveCodeBench 添加了可执行的、抗污染的评估[404, 57, 60, 58, 405]。这一方向强调迭代修正、调试和响应测试反馈。随着任务时程变长，性能越来越依赖于工具架是否能检索上下文、运行命令、检查失败并支持重复修复。

更广泛的工程工作流 (Broader Engineering Workflows)。 第三条线将评估从问题修复扩展到更全面的工程工作流。NL2Repo-Bench 要求智能体根据自然语言需求设计架构、管理依赖并生成可安装的仓库[406]。FeatureBench 关注需要跨文件协调编辑的特性级实现[407]。BeyondSWE 整合了几个超越错误修复的机制，包括跨仓库推理、领域特定修复、依赖迁移和文档到仓库的生成[408, 59]。这些基准共同表明，较新的评估越来越多地测试全局规划、跨文件一致性和依赖管理，而不仅仅是局部补丁生成。

5.3 工具使用与函数调用

工具使用和函数调用基准评估智能体是否能正确、相关且与任务状态一致地调用外部能力。总体趋势从孤立的函数调用转向多步、有状态和对话式的工具编排。

函数调用 (Function Calling)。 一个早期方向孤立地考察调用本身的正确性。API-Bank 和 BFCL 评估系统是否能选择合适的函数、提供有效参数并使调用与任务要求对齐[409, 62, 393]。这针对的是工具架能力的一个狭窄但基础的层面：在更长的轨迹开始之前选择和格式化正确的动作。

工具使用 (Tool Use)。 第二条线将范围从调用工具扩展到用工具解决问题。ToolBench、AgentBench 和 GAIA 评估智能体是否能规划API使用、集成中间结果并将工具作为更广泛任务完成的一部分[115, 307, 410, 61]。这些任务强调工具路由、多步规划以及将检索到的输出连接到后续决策的能力，将评估从局部调用正确性转向协调的、工具支持的问题解决。

有状态交互 (Stateful Interaction)。 最近的基准转向跨多轮和变化状态的持久化编排。τ-bench 和 AssistantBench 评估在用户约束下的对话交互，而 AppWorld、ToolSandbox 和 τ²-Bench 要求在更长的轨迹中管理共享的应用或工具状态[390, 132, 411, 64, 65, 63, 412]。这些基准更加重视状态跟踪、多轮一致性以及依赖动作的正确排序，尽管在权限、安全边界、部分失败恢复和跨会话记忆方面仍然存在空白。

===== 第 27 页 =====

5.4 计算机使用与GUI基础定位

计算机使用和GUI基础定位基准评估智能体是否能够在浏览器、桌面和移动系统等交互式数字环境中感知和行动。最近的基准日益强调多模态感知、更丰富的环境以及显式的GUI基础定位。

网络导航 (Web Navigation)。 一个早期方向是基于浏览器的任务完成。Mind2Web 和 WebArena 通过要求系统解释页面内容、选择行动并在现实的一系列网络状态中取得进展，将网络导航确立为一个核心评估设置[107, 108]。这些任务强调在一个界面内的观察、行动选择和轨迹管理，将浏览器引入作为评估智能体交互的有意义环境。

计算机使用 (Computer Use)。 第二条线从网站扩展到更广泛的数字环境。VisualWebArena 添加了视觉基础的网络交互，而 WorkArena、Android in the Wild、OSWorld、AndroidWorld 和 Windows Agent Arena 将评估扩展到企业平台、移动任务、桌面系统和真实的Windows控制[104, 389, 413, 105, 69, 414, 67]。这些基准更加重视多模态感知、环境状态和更广泛的计算机控制，将评估推向更接近实际智能体部署的条件。

GUI基础定位 (GUI Grounding)。 最近的工作转向将动作显式地基础定位于图形界面。ScreenSpot-Pro 和 OSWorld-MCP 将元素识别和对齐接口的控制作为任务的直接部分，而不是一个隐含的子问题[415, 70, 416, 68]。这反映了向通用多模态计算机使用的转变，其中精确的基础定位成为可靠行动的核心瓶颈。即便如此，沙盒环境与实时部署之间仍然存在巨大差距，干预点、安全敏感动作、延迟和实时部署差距等问题仍然缺乏有效评估。

5.5 机器学习工程与科学研究

此类别中的基准评估智能体是否能够支持比普通编码任务具有更长时程的实验、工程和科学工作流。其发展从数据科学问题解决转向研究复现和开放式研究辅助。

机器学习实验 (ML Experimentation)。 一个早期方向聚焦于数据科学和机器学习中的可执行实验。DS-1000 评估真实的数据科学编码，而 MLAgentBench 询问智能体是否能够迭代运行和改进实验，而不仅仅是生成代码[417, 418, 394]。这种设置强调实验设置、数据处理和经验反馈，衡量工具架是否能支持实验循环而不是单步生成。

科学工作流 (Scientific Workflows)。 在可执行实验的基础上，第二条线将评估扩展到面向工作流的科学和机器学习工程任务。DA-Code、ScienceAgentBench 和 MLE-bench 强调跨依赖步骤的更广泛数据科学工作流、科学任务分解和机器学习工程流水线[419, 10, 72, 71]。性能越来越依赖于工具架是否能在扩展的工作流上组织上下文、执行和验证。

研究复现 (Research Replication)。 最近的基准转向复现和开放式科学验证。PaperBench、MLR-Bench、FML-bench 和 ReplicatorBench 评估智能体是否能复现研究结果、进行开放式机器学习研究以及在更长时程条件下重建科学主张[73, 420, 421, 422]。这代表了向询问系统是否能在扩展的轨迹上支持有意义的科学工作的更广泛转变。科学的实用性比工程正确性更难验证，有效性、新颖性、计算不平等和长时程可靠性仍然是开放的挑战。

讨论

• 基准设计正在从单信号最终答案检查演变为多信号评估：基于执行、基于状态、基于量规和轨迹感知的信号共同构成了一个从验证“产生了什么”到评估“如何产生”的进展。

===== 第 28 页 =====

• 关键差距仍然存在：安全性和权限控制、运营成本（延迟、令牌预算）以及长期记忆持久性在当前基准中都未得到充分或一致的评估。
• 最根本的是，当前的基准很少能将归因于基础模型的改进与归因于工具架的改进区分开来，这限制了为工具架工程师提供可操作的洞见。
• 弥补这些差距——特别是成本感知评估、安全测试以及模型-工具架归因——将成为下一代基准的核心。

6 未来方向

智能体工具架的发展正在从构建有能力的执行循环转向治理长期运行的运行时系统。早期的工具架设计侧重于使智能体能够感知环境、调用工具、维护上下文和协调行动。随着这些能力的成熟，核心瓶颈转向了当智能体在扩展的时间范围内运行、与无控制的环境交互、跨会话持久化状态以及以越来越高的权限行动时会发生什么。在这样的设置中，性能不仅取决于模型是否能产生一个合理的下一步行动，还取决于工具架是否能选择性地分配计算、管理状态生命周期、维护与环境对齐的信念、约束风险行动以及为评估暴露证据。

这种转变将未来的工具架工程定位为在资源、状态和行动约束下的运行时治理。效率 (Efficiency) 关注如何在明确的预算下分配计算、上下文和工具。安全性 (Safety) 关注在模型输出转化为现实世界行动之前，如何调解工具访问、记忆写入和委派。持续学习 (Continual Learning) 关注如何整合、更新和保护持久化记忆和技能免受漂移。状态与环境建模 (State and Environment Modeling) 关注如何将部分观察和工具反馈维护为连贯的信念状态。具身化工具架 (Embodied Harnesses) 在物理约束下测试这些抽象，其中行动是有噪声且通常是不可逆的。评估 (Evaluation) 则必须超越最终成功率，转向轨迹感知、安全感知和成本感知的协议。以下各小节依次讨论这些方向。

6.1 效率

随着大语言模型智能体从单轮生成转向长时程执行，效率成为一个工具架层面的关注点，而不仅仅是模型层面的。智能体系统中的成本通过重复的模型调用、不断扩展的动作-观察历史、工具结果反馈、检索、反思和多智能体委派累积起来。一个对每个子任务应用相同模型、上下文预算和推理深度的统一执行循环本质上是浪费的，然而大多数当前的工具架恰好采用了这种统一策略。模型路由工作提供了第一种替代方案，将推理框定为成本-质量的权衡，表明可以动态选择较弱和较强的模型，而不必总是调用最有能力的模型[423]。相同的原理扩展到推理深度：对思维链提示的分析警告说，更深的推理轨迹并非普遍有益，因为额外的推理可能是脆弱的、任务特定的，并且在不能泛化时成本高昂[424]。综合起来，这些结果表明，智能体效率应作为一个调度问题来研究：工具架必须决定何时需要更深的推理、更强的模型或检索，以及何时更便宜的执行路径就足够了。

虽然模型选择和推理深度决定了每个单独步骤的成本，但第二个瓶颈来自于跨步骤累积的内容：上下文和轨迹管理。长时间运行的智能体重复处理不断增长的历史、观察、工具输出和中间决策。ACON 通过针对下游智能体故障优化压缩指南来解决这个问题，表明上下文压缩必须保留与任务相关的信息，而不仅仅是缩短文本[277]。AgentDiet 从移除方面补充了这一发现，表明长时程轨迹包含冗余和过期的信息，可以在推理时剪枝而不牺牲任务性能[425]。最近的框架超越了这种被动压缩，转向主动上下文治理。ARC 将上下文视为一个动态推理状态，当上下文腐烂出现时可以被监控和修订，而 Context as a Tool 将上下文维护作为长时程 SWE 智能体中的一个可调用的动作[426, 427]。这些工作共同指出，

===== 第 29 页 =====

高效的智能体不应将历史视为不可变的记录，而应视为一个由运行时管理其保真度、生命周期和可访问性的资源。

除了模型计算的内容和它看到的上下文，效率还取决于工具和推理组件如何被编排。工具使用可以通过将计算委派给外部系统来减少模型负担，但结构不佳的调用会引入额外的调用、长的反馈轨迹和昂贵的重新规划，从而抵消委派的好处。最近关于分层工具编排的工作表明，将全局依赖指导与局部反思修正分开可以减少这种开销，避免在每次工具级故障后进行全轨迹重新规划[428]。这三个维度形成了一个连贯的效率栈：路由控制使用哪个模型，上下文管理控制模型看到什么，轨迹缩减控制哪些历史持续存在，工具编排控制花费多少推理来协调外部动作。未来的工具架应将计算视为一个有预算的运行时资源，在不确定性或任务风险证明其合理性的地方分配容量，同时将常规子任务折叠到更便宜的模型调用、压缩状态、缓存工件或结构化工具执行中。

6.2 安全性

智能体系统中的安全性正在从输出对齐转向运行时能力治理。当智能体只产生文本时，安全性可以围绕有害响应或偏好对齐来构建。一旦工具架允许模型浏览不受信任的内容、调用工具、写入外部系统、存储持久化记忆或委派子任务，主要的风险面就从生成转移到了观察-行动循环。这种扩大的攻击面在工具架的逐层深处显现。在工具输出层面，AgentDojo 表明返回的结果可以携带提示注入攻击，引导智能体采取恶意行动[429]。在工具元数据层面，MCPTox 表明 MCP 风格生态系统在执行工具之前就引入了投毒风险[430]。在记忆层面，AgentSys 认为，当不可信的观察累积在工作记忆中时，间接提示注入变得持久，并提出了分层记忆隔离作为防御[32]。这种进展表明，工具架安全性关注的不仅是模型生成什么，还包括运行时允许哪些信息、工具和权限影响未来的行动。

认识到威胁面跨越整个运行时，最近的工作日益将安全性视为一个治理架构问题。在概念层面，OpenPort Protocol 将工具访问框定为一个结合了授权依赖发现、范围限定权限、稳定失败语义、风险门控执行、状态重新验证和结构化审计事件的治理接口[431]。在形式层面，AI Agent Runtime Governance 表明许多安全策略是路径依赖的，这意味着一个行动是否可接受取决于智能体身份、部分执行轨迹和先前的数据访问，而不仅仅是孤立的下一步行动[432]。在执行层面，AgentSpec 提供了一个用于指定智能体行动上的触发器、谓词和干预措施的领域特定语言，而 AARM 提出了一个行动拦截层，用于累积会话上下文、检查策略对齐并记录防篡改收据[433, 434]。SafeHarness 将这些关注点整合到整个智能体生命周期中，结合了对抗性上下文过滤、因果验证、权限分离的工具控制以及带有自适应降级的回滚[435]。这些工作共同表明，从提示级保障措施向工具架内部的生命周期感知调解的转变。

然而，这些治理机制主要解决单个行动或单层威胁。核心的开放问题是组合式治理 (compositional governance) 在长时间范围内的问题，其中不安全的行为并非源自任何单个不被允许的步骤，而是源自多个个体上允许的步骤的组合：在发送电子邮件之前读取敏感数据、在被投毒的元数据之后调用良性工具、在策略变更后检索过时的记忆，或者委派部分上下文而不保留来源。应对这种组合风险需要能够随状态携带的安全机制。工具输出、记忆条目、检索到的文档和计划好的行动应携带来源、信任度和新鲜度元数据，以便在下游使用前进行检查。高风险行动应支持批准门控、状态重新验证、可能时的回滚，以及在执行无法撤销时的可审计收据。这一阐述阐明了工具架级安全性与模型级对齐的不同之处：对齐塑造行为倾向，而工具架治理确定哪些能力被暴露、哪些信息被持久化、哪些行动可以执行，以及在执行前后必须产生哪些证据。

===== 第 30 页 =====

6.3 持续学习

智能体系统中的持续学习不应等同于持续更新模型权重。智能体通过多个层面的适应来改进：模型可以被微调，工具架可以更新其工具、规则和策略，而上下文层可以积累记忆、用户偏好和可重用技能。最近的产品侧讨论通过分离模型级、工具架级和上下文级的学习，使这种分层观点变得明确。一个有用的理论基础是大语言模型智能体的外部化视图 (externalization view)，该观点认为记忆外部化跨时间的状态，技能外部化程序性专业知识，协议外部化交互结构，而工具架在运行时协调这些外部化的组件。综合这些观点，持续学习变得不再关乎智能体是否有更大的记忆存储，而更多地关乎工具架如何维护外部结构，通过它过去的经验影响未来的行为[436]。

如果持续学习主要作用于外部化状态，核心挑战就从记忆积累转变为上下文生命周期管理 (context lifecycle management)。早期的系统如 MemGPT 引入了结构化记忆层级，而不是将上下文窗口视为仅可追加的记录[148]。后续工作使记忆操作本身变得可学习：A-MEM 区分了记忆构建和检索策略，而 Memory as Action 将记忆编辑视为智能体策略的一部分，而非固定的启发式[31, 437]。生产部署通过操作化不同的生命周期阶段进一步验证了这一趋势。例如，Anthropic 的上下文管理指南将压缩、工具结果清除和记忆分开：压缩压缩当前对话，工具结果清除移除可重新获取的输出，而记忆跨会话持久化结构化笔记[438]。其深层见解是，不同类型的状态需要不同的生命周期处理：一些应保留在活动上下文中，一些应被总结，一些可以被丢弃因为它是可重构的，还有一些必须为未来的会话持久化在窗口之外。因此，持续学习变成了一个在状态上的受治理的写入-管理-读取循环，而不是一个简单的检索问题。

当从声明性记忆扩展到程序性技能时，同样的生命周期挑战变得更加严峻。Agent Workflow Memory 表明，智能体可以从先前的轨迹中归纳出可重用的工作流，并检索它们以指导未来的行动序列[146]。最近的面向技能的系统将这些程序视为显式的包：技能可能包括指令、脚本、元数据、测试和执行约束，并且可以由工具架动态发现、加载、共享或版本化。然而，技能与声明性记忆相比，与外部依赖的耦合更紧密，因此一旦成为持久对象，就会产生类似软件的维护风险。摘要可能过度压缩罕见异常，旧信念可能在环境变化后仍然存在，工具API可能使程序性例程失效，低质量的记忆可能污染未来的行为。未来的工作应因此将持续学习研究为受治理的持久化 (governed persistence)：如何整合经验、保留来源、使陈旧状态过期、调和矛盾更新、对技能进行版本控制，以及使持久化结构与工具、环境和用户保持对齐。

6.4 状态与环境建模

智能体工具架中的状态与环境建模主要不是关于大语言模型是否包含潜在的常识知识。更直接的问题是运行时能否在长轨迹上维护一个紧凑、可更新且与行动相关的环境表示。对于实际智能体来说，外部世界仅通过观察（如网页变化、GUI布局、仓库文件、工具响应、沙盒反馈和中间工件）部分暴露。因为这些观察是不完整和瞬态的，将完整的交互历史视为状态的代理既低效又脆弱：历史会随着冗余或过期的信息增长，而模型的隐式信念可能默默地偏离实际环境。因此，一个工具架需要用于构建和更新信念状态的显式机制，以支持规划、执行和恢复，而不是依赖原始的观察重放。

最近的研究从两个互补的方向来满足这一需求，这两个方向对应于两个不同的规划要求。第一个方向侧重于显式信念维护 (explicit belief maintenance)，它回答“智能体当前在哪里”的问题。WorldCoder 通过编写代码和与环境交互来学习可执行的环境模型，使得能够基于学习到的模型进行规划，而不是基于原始历史[439]。CoEx 将规划与从经验中更新的持久化神经符号信念状态相结合，而 PABU 表明，通过仅保留与决策相关的状态，进度感知的信念更新可以优于完整历史条件[440]。第二个方向建模

===== 第 31 页 =====

动作条件下的转移 (action-conditioned transitions)，它回答“如果智能体采取行动会发生什么”的问题。Reinforcement World Model Learning 训练智能体预测行动后的下一个状态，并使用模拟反馈和真实反馈之间的差异作为学习信号，使状态转移本身成为工具架优化的一部分。在网络、GUI和移动环境中的相关工作，同样使用状态机或转移图来表示接口动态和行动后果。这两个能力共同使智能体能够推理其当前情况和候选行动的可能结果，这是知情规划的最低要求。

虽然学术研究追求学习到的状态模型，但已部署的系统通常通过结构化基础设施实现相同的功能。编码和计算机使用智能体通过仓库文件、终端输出、测试结果、执行日志和沙盒权限来维护环境状态。最近的产品侧运行时使这一点变得明确：受控的沙盒环境定义了智能体可以检查、执行和修改的内容，而渐进式披露决定了每一步哪些部分被呈现。Agent-World 通过论证健壮的智能体开发需要可扩展的环境合成、沙盒化和真实状态转移来扩展这一观点[441]。无论是通过学习模型还是通过工程化基础设施实现，潜在的挑战是相同的：维护智能体所相信的和实际真实情况之间的一致性。未来的工作应因此将状态建模视为一个工具架级的一致性挑战：如何协调模型先验、部分观察、工具反馈、记忆和变化的外部状态；如何检测过时或不确定的信念；以及如何跨网络、代码、GUI和具身设置暴露可复用的状态转移接口。

6.5 具身化工具架

具身化设置为工具架工程提供了一个特别严苛的测试，因为状态是部分可观察的，执行是有噪声的，反馈是实时的，行动通常是不可逆的。早期的系统如 PaLM-E 和 RT-2 表明多模态模型可以将视觉和语言知识连接到具身规划[314, 315]，但这些系统在很大程度上将模型视为一个单一的规划器-到-执行器流水线。最近的工作将这个流水线分解为显式的工具架层。Gemini Robotics-ER 1.6 将高级具身推理（包括空间推理、任务规划和成功检测）从低级 VLA 执行和用户定义函数中分离出来。Green-VLA 类似地将通用机器人部署框定为一个分阶段控制栈，在统一动作接口之上进行任务规划、进度预测、分布外检测和基于 RL 的策略对齐[442]。ACoT-VLA 和 ST4VLA 通过使动作空间推理和空间基础定位成为 VLA 训练中的学习目标，强化了这种分解[443, 444]。趋同的教训是，具身进展不太依赖于端到端的动作生成，而更多地依赖于高级语义推理和低级运动执行之间的一个明确的运行时边界。

一旦这个边界被建立，基础状态管理 (grounded state management) 就成为工具架在语义层面的核心责任。与数字环境不同，物理世界不暴露完整的或可回滚的状态，因此工具架必须从摄像头流、传感器读数和执行反馈中维护一个近似的信念状态。然后，三个运行时问题持续出现：当前观察是否足够可靠以进行规划，给定更新的感知，候选行动是否仍然有效，以及任务是按预期进展了还是漂移出了分布。最近的系统通过具体的机制解决这些问题：Gemini Robotics-ER 1.6 提供多视图成功检测和空间指向以评估进度；Green-VLA 添加了实时进度跟踪和 OOD 监控以检测漂移[442]；RoboAgent 将具身任务规划分解为由调度器协调的能力，并为可靠性隔离提供单独的上下文[445]。共同的架构模式是，具身工具架必须将感知、规划、信念更新和成功检测连接成一个连续的运行时循环，因为将感知视为一次性输入无法维持多步物理执行。

物理行动的不可逆性进一步要求超越软件智能体所需的执行前验证和恢复协议。在数字环境中，失败的行动通常可以重试或沙盒化；在物理环境中，一次不安全抓取或碰撞就可能损坏场景或机器人本身。EmbodiedBench 证实，即使强大的多模态模型在这些条件下也难以维持基础定位和鲁棒的动作选择[5]。因此，运行时不能仅依赖模型能力，而必须在将计划好的行动分派给控制器之前，验证其与当前感知、物理约束和安全规则的兼容性。AgentSpec 提供了一种有用的抽象，将此类约束视为可执行的工具架逻辑，

===== 第 32 页 =====

而非非正式的提示[446]。生产机器人工作流在大规模上实现了同样的原则：NVIDIA 的仿真到生产堆栈和 Isaac Lab-Arena 要求在真实世界执行之前进行仿真评估、软件在环测试、数字孪生集群测试和安全防护。当验证通过但执行仍然失败时，工具架必须随后支持重新观察、重新规划、控制器切换、安全状态撤退以及升级到人类监督。从这个意义上说，具身工具架与其说是一个独立的应用领域，不如说是一个严苛的测试平台，检验为数字智能体开发的规划、状态维护、验证和恢复抽象是否能在与物理现实的接触中生存下来。

6.6 评估

对智能体工具架的评估正在从衡量孤立任务成功转向评估完整执行运行的质量。最近的基准已经超越了静态问答，将智能体置于更长、更具交互性的环境中：BrowseComp 和 OSWorld 强调多步浏览和计算机使用轨迹，PaperBench 和 ReplicatorBench 评估开放式研究工作流，BeyondSWE 针对的是其失败仅在跨仓库推理后才会显现的软件工程任务[313, 105, 73, 422, 408]。这些基准扩展了任务时程和难度，但它们仍然主要基于最终输出进行评估。最近的基准通过使环境本身动态化更进一步，这迫使评估考虑整个执行轨迹。Gaia2 评估智能体在异步环境中的表现，其中状态独立于智能体行为而变化，而 Claw-Eval-Live 将可刷新的工作流信号与可复现的快照分开，并使用执行轨迹、审计日志和工作空间工件对运行进行评分[66, 447]。一旦环境可以在执行过程中改变，一个正确的最终答案就不再保证一个可靠的过程，使得智能体运行本身成为必要的测量单位。

然而，将运行作为评估对象，立即提出了在该运行中应该测量什么的问题。最终成功率隐藏了智能体是遵循了一个可靠的程序，还是通过偶然、过度重试或未观察到的副作用达到了正确状态。这个归因问题 (attribution problem) 引发了第二个评估要求：过程可见性 (process visibility)。现有的基准已经开始暴露更丰富的中间信号：ResearchRubrics 通过结构化量规评估长式研究，OSWorld-MCP 使工具调用模式显式化，AgentLongBench 通过环境推演而非被动检索评估长上下文智能体[400, 70, 448]。这些努力指向一个更广泛的标准：基准应记录状态如何更新、调用了哪些工具、产生了哪些中间工件、如何处理失败以及记忆是否随时间变得陈旧。没有这种轨迹级的证据，将性能归因于模型、工具架、工具或周围的执行环境仍然很困难。

过程可见性揭示了智能体做了什么，但一个完整的评估还必须判断它所做的是否安全且可负担。这引出了第三个要求：将治理、安全性和成本作为一等指标进行评估，而不是作为次要诊断。智能体故障越来越多地发生在轨迹内部，在仅看输出的评估中是不可见的：不安全的工具调用、投毒的工具、受污染的记忆、通过内部消息泄露的隐私以及缺失的批准步骤可能永远不会在最终响应中显现。ATBench 通过异构工具池和延迟触发风险使这种轨迹级安全问题变得明确，而 AgentLeak 表明仅靠输出审计无法捕获通过智能体间消息和共享记忆泄露的隐私[449, 450]。成本表现出类似的评估差距。General AgentBench 表明，测试时扩展受到上下文上限和验证差距的限制，这意味着通过率应与令牌使用量、延迟、工具调用次数和验证预算一起解释[451]。未来的工具架基准应因此将路径质量 (path quality)、状态质量 (state quality)、安全质量 (safety quality) 和成本质量 (cost quality) 作为一个集成的概况来报告，区分仅仅是解决基准实例的系统与那些可靠、可审计和可部署的工具架。

7 结论

本文从工具架工程的角度对智能体系统进行了系统性的回顾。从实际能力既取决于系统脚手架也取决于底层模型的观察出发，我们将工具架形式化为管理执行流、工具调用、记忆管理、上下文构建和强制安全的编排层，并将

===== 第 33 页 =====

工具架工程定义为对脚手架及其所支持的模型的联合优化。在此框架下，我们考察了智能体工作流、记忆系统、技能库和多智能体编排如何共同决定系统级性能，并回顾了涵盖上下文工程和智能体训练的优化策略，以及跨软件工程、深度研究、工具使用、计算机使用和科学发现领域的评估基准。

这一视角将分析焦点从智能体能完成什么转移到周边基础设施如何促成可靠的完成。我们的分析揭示，已部署系统中的许多实际故障，包括长时程执行中的不稳定性、低效的工具利用、上下文退化以及次优的多智能体协调，通常源于不充分的工具架设计，而不仅仅是模型层面的缺陷。这些故障反映了LLM的单轮生成接口与现实世界问题解决所具有的有状态、迭代性质之间的结构性不匹配，强化了核心论点，即模型和工具架之间的关系是内在协同的：对一个的改进能释放另一个的潜在能力。

展望未来，几个方向值得研究：提高长时程设置中工具架执行的可扩展性和鲁棒性，开发用于联合脚手架-模型优化的原则性方法，将智能体工具架推广到物理和具身领域，以及建立能够区分工具架贡献与模型能力的评估协议。我们希望本文通过原则性的工具架工程，为构建更可靠、可扩展和可控的智能体系统提供实践参考。

===== 第 34 页 =====

[1] Michael J. Wooldridge and Nicholas R. Jennings. Intelligent agents: theory and practice. Knowl. Eng. Rev., 10(2):115-152, 1995.
[2] Yixin Ou, Wangchunshu Zhou, Shengwei Ding, Long Li, Jialong Wu, Tiannan Wang, Jiamin Chen, Shuai Wang, Xiaohua Xu, Ningyu Zhang, Huajun Chen, and Yuchen Eleanor Jiang. Symbolic learning enables self-evolving agents. AI Open, 6:314-322, 2025.
[3] Ho Chit Siu, Jaime Daniel Peña, Edenna Chen, Yutai Zhou, Victor J. Lopez, Kyle Palko, Kimberlee C. Chang, and Ross E. Allen. Evaluation of human-ai teams for learned and rule-based agents in hanabi. In NeurIPS, pages 16183-16195, 2021.
[4] DeepSeek-AI. Deepseek-r1: Incentivizing reasoning capability in llms via reinforcement learning. CoRR, abs/2501.12948, 2025.
[5] Rui Yang, Hanyang Chen, Junyu Zhang, Mark Zhao, Cheng Qian, Kangrui Wang, Qineng Wang, Teja Venkat Koripella, Marziyeh Movahedi, Manling Li, Heng Ji, Huan Zhang, and Tong Zhang. Embodiedbench: Comprehensive benchmarking multi-modal large language models for vision-driven embodied agents. In ICML, Proceedings of Machine Learning Research. PMLR / OpenReview.net, 2025.
[6] Wayne Xin Zhao, Kun Zhou, Junyi Li, Tianyi Tang, Xiaolei Wang, Yupeng Hou, Yingqian Min, Beichen Zhang, Junjie Zhang, Zican Dong, Yifan Du, Chen Yang, Yushuo Chen, Zhipeng Chen, Jinhao Jiang, Ruiyang Ren, Yifan Li, Xinyu Tang, Zikang Liu, Peiyu Liu, Jian-Yun Nie, and Ji-Rong Wen. A survey of large language models. CoRR, abs/2303.18223, 2023.
[7] John Yang, Carlos E. Jimenez, Alexander Wettig, Kilian Lieret, Shunyu Yao, Karthik Narasimhan, and Ofir Press. Swe-agent: Agent-computer interfaces enable automated software engineering. In Amir Globersons, Lester Mackey, Danielle Belgrave, Angela Fan, Ulrich Paquet, Jakub M. Tomczak, and Cheng Zhang, editors, Advances in Neural Information Processing Systems 38: Annual Conference on Neural Information Processing Systems 2024, NeurIPS 2024, Vancouver, BC, Canada, December 10 - 15, 2024, 2024.
[8] Huatong Song, Lisheng Huang, Shuang Sun, Jinhao Jiang, Ran Le, Daixuan Cheng, Guoxin Chen, Yiwen Hu, Zongchao Chen, Wayne Xin Zhao, et al. Swe-master: Unleashing the potential of software engineering agents via post-training. arXiv preprint arXiv:2602.03411, 2026.
[9] Yihong Dong, Xue Jiang, Jiaru Qian, Tian Wang, Kechi Zhang, Zhi Jin, and Ge Li. A survey on code generation with llm-based agents. CoRR, abs/2508.00083, 2025.
[10] Ziru Chen, Shijie Chen, Yuting Ning, Qianheng Zhang, Boshi Wang, Botao Yu, Yifei Li, Zeyi Liao, Chen Wei, Zitong Lu, Vishal Dey, Mingyi Xue, Frazier N. Baker, Benjamin Burns, Daniel Adu-Amprah, Xuhui Huang, Xia Ning, Song Gao, Yu Su, and Huan Sun. Scienceagentbench: Toward rigorous assessment of language agents for data-driven scientific discovery. In ICLR. OpenReview.net, 2025.
[11] OpenClaw. Openclaw, 2026.
[12] Hermes. Hermes agent, 2026.
[13] Junyu Luo, Weizhi Zhang, Ye Yuan, Yusheng Zhao, Junwei Yang, Yiyang Gu, Bohan Wu, Binqi Chen, Ziyue Qiao, Qingqing Long, Rongcheng Tu, Xiao Luo, Wei Ju, Zhiping Xiao, Yifan Wang, Meng Xiao, Chenwu Liu, Jingyang Yuan, Shichang Zhang, Yiqiao Jin, Fan Zhang, Xian Wu, Hanqing Zhao, Dacheng Tao, Philip S. Yu, and Ming Zhang. Large language model agent: A survey on methodology, applications and challenges. CoRR, abs/2503.21460, 2025.
[14] Zhipeng Liu, Xuefeng Bai, Kehai Chen, Xinyang Chen, Xiucheng Li, Yang Xiang, Jin Liu, Hong-Dong Li, Yaowei Wang, Liqiang Nie, and Min Zhang. A survey on the feedback mechanism of llm-based AI agents. In Proceedings of the Thirty-Fourth International Joint Conference on Artificial Intelligence, IJCAI 2025, Montreal, Canada, August 16-22, 2025, pages 10582-10592. ijcai.org, 2025.
[15] Aske Plaat, Max J. van Duijn, Niki van Stein, Mike Preuss, Peter van der Putten, and Kees Joost Batenburg. Agentic large language models, a survey. J. Artif. Intell. Res., 84, 2025.
[16] Yongchao Zhou, Andrei Ioan Muresanu, Ziwen Han, Keiran Paster, Silviu Pitis, Harris Chan, and Jimmy Ba. Large language models are human-level prompt engineers. In ICLR. OpenReview.net, 2023.
…（中间省略大量参考文献条目以保持简洁，实际翻译时会全部保留）…
[451] Xiaochuan Li, Ryan Ming, Pranav Setlur, Abhijay Paladugu, Andy Tang, Hao Kang, Shuai Shao, Rong Jin, and Chenyan Xiong. Benchmark test-time scaling of general llm agents, 2026.

[文件内容结束]