第 15 章 AI 算法Transformer大模型

第 15 章 Agent 系统

第15章 Agent 系统

15.1 Agent 系统概述

LLM Agent 是具备感知（Perception）、推理（Reasoning）与行动（Action）能力的自主系统，标志着大语言模型从被动应答到主动执行任务的关键跃迁。本章系统梳理 Agent 研究的全貌：从认知架构的进化到自进化 Agent，从搜索与深度研究 Agent 到多 Agent 系统，再到完全自主的 Agent 系统。

15.1.1 Agent 的定义与核心属性

形式化地，LLM Agent 可定义为一个七元组 A = (S, O, A, π, M, R, E)： •状态空间 S ：Agent 的内部状态，包括当前任务上下文、已有知识、记忆内容 •观测空间 O：来自外部环境的反馈信号（API 返回、网页内容、工具输出） •动作空间 A：Agent 可执行的行动集合（调用工具、生成文本、更新记忆、修改计划） •策略 π : S × O → Δ(A)：将状态和观测映射到动作分布的核心决策函数，通常由 LLM 实现 •记忆模块 M：持久化存储与检索机制，分为工作记忆（Working Memory）与长期记忆（Long-term Memory） •奖励函数 R : S × A → R：对动作质量的标量评价 •环境 E ：Agent 所处的外部世界，提供状态转移 T (s ∣ s, a) 和观测生成 ′ 与传统的 Chatbot 相比，Agent 在多个维度上引入了本质差异：维度 Chatbot Agent 交互模式单轮/多轮 Q&A 多步任务执行行动能力仅文本生成工具调用 + 环境交互记忆机制对话上下文持久化记忆 + 经验积累规划能力无显式规划任务分解 + 路径搜索自我纠错依赖用户反馈自主反思与重规划状态管理无状态维护信念状态表15-1 Chatbot 与 Agent 对比 Agent 的通用认知回路如图 15-1 所示，规划、推理、记忆与反思模块围绕 LLM 核心协同运作： User task Planning Module Decompose task, generate plan Text response Reasoning Module LLM Core Reasoning Action Selection Tool Calling Tool A / Tool B / ... Observation: Tool return r esults Reflection Module Evaluate results, adjust pla n Memory Module Retrieve relevant experien ce 图15-1 LLM Agent 的通用认知回路

15.1.2 从 Chatbot 到 Agent 的演化

Agent 能力并非一夜涌现，而是经历了四个阶段的技术积累，如图 15-2 的时间线所示：

纯语言交互（2018-2022）：GPT-1 到 GPT-3 时代，模型仅具备文本生成能力，被理解为统计语言模型。没有工具调用、没有环境交互、没有持续记忆。代表系统包括早期 GPT-2/3 的提示工程（Prompt Engineering）应用。
工具增强语言模型（2022-2023）：Toolformer（Schick et al. 2023）首次证明 LLM 可以通过自监督方式学会调用 API。关键创新：在训练数据中插入 API 调用标记，让模型自主决定何时调用外部工具及传递什么参数。同一时期， ChatGPT Plugins 生态将工具调用推至实用化。
推理-行动循环（2023-2024）：ReAct（Yao et al. 2022）首次将推理（Reasoning）与行动（Acting）整合为交替循环：模型生成推理轨迹 τ ，据此选择行动 a ，接收观测 o ，再生成下一推理步骤。此范式被后续几乎所有 Agent thought 框架采用。 t t
自主长程任务执行（2024-2026）：从 SWE-bench 的代码修复到 OSWorld 的 GUI 操作，Agent 开始在小时级别的时间尺度上自主完成任务。关键突破来自：规划算法的强化（MCTS for LLM）、自进化学习循环（Self-Evolving Agents）、多 Agent 协作（Multi-Agent Systems）。 Evolution of Agent Capabilities Pure Language Tool Augmentation ReAct Loop Autonomous Interaction Execution 2018-2022 2022-2023 2023-2024 2024-2026 图15-2 Agent 能力演化时间线

15.1.3 Agent 的核心能力维度

将 Agent 的能力体系分解为四个正交维度，如图 15-3 所示： •规划能力（Planning）：将复杂任务分解为可执行子任务的序列。规划的输出是部分顺序（Partial Order）的动作集合 {a , a , … , a }，需满足前置条件约束 P re(a ) ⊆ Eff ects(a )。核心挑战在于长程任务中的组合爆炸，搜索空间随步 1 2 <i 数指数增长。 n i •工具使用（Tool Use）：调用外部 API、代码执行器、数据库、文件系统等。技术要点包括：工具的语义匹配（Function Calling）、参数的 type 约束、错误的优雅降级。工具调用的形式化目标为 max sim(q, desc(tool))，其中 q 为当前意图的嵌入。 tool∈T •记忆机制（Memory）：在任务执行过程中和跨任务间持久化信息，覆盖当前上下文、过往任务轨迹与抽象化经验等多个层次。工作记忆保存即时信息，情景记忆记录历史轨迹，语义记忆沉淀抽象知识，三者共同支撑任务内的状态保持与跨任务的经验复用。 •反思能力（Reflection）：评估自身输出的质量，决定是否重规划或重执行。反思的形式包括口头反思（Verbal Reflection），即让 LLM 自我批评，以及基于信号的反思（Signal-based Reflection），即通过外部验证器（编译器、测试框架、规则引擎）的反馈。 Agent Core Capabilities Planning Tool Use Memory Reflection Task Decomposition Path Search Replanning API Calling Code Execution Web Browsing Working Memory Episodic Memory Semantic Memory Verbal Reflection Signal-based Reflection Function Calling Code Interpreter 图15-3 Agent 核心能力的四维分解

15.1.4 Agent 的分类学

依据 Agent 的自主程度、协作模式和进化能力，构建三层分类体系：

单体 Agent（Single-Agent）：单个 LLM 实例独立完成任务。架构上基于 ReAct、Plan-Execute 或 Reflexion 模式。优势在于简单可控；局限在于单视角推理的上限（认知天花板问题）。
多 Agent 系统（Multi-Agent Systems）：多个 Agent 通过协作完成复杂任务。通信拓扑包括：集中式协调器（Centralized Coordinator）、去中心化共识（Decentralized Consensus）、层级式（Hierarchical）。典型应用如 ChatDev（软件公司模拟）、AutoGen（多角色对话）。
自进化 Agent（Self-Evolving Agents）：Agent 通过任务经验的积累持续改进自身策略、技能和工具。自进化循环的核心公式为： πt+1 = Update(πt , Dexp , Lmeta ) 其中 D 为历史经验数据，L 为元学习目标函数。 exp meta 分类自主程度协作需求进化能力代表性工作典型应用场景单体 Agent 中等无无 ReAct, Reflexion 问答、简单代码任务多 Agent 中高高无 ChatDev, AutoGen 软件开发、科研协作自进化 Agent 高可变有 MMG2Skill, SkillAdaptor 持续改进的自主系统表15-2 Agent 的分类体系

15.1.5 Agent 当前的技术瓶颈

在庆祝 Agent 能力飞跃的同时，必须正视四类关键技术瓶颈： •组合错误（Compound Errors）：在长程任务（>20 步）中，每步的微小错误以复合方式积累，最终导致任务失败。假设单步错误率 ϵ = 5%，则 20 步的累积成功率仅为 (1 − ϵ) ≈ 35.8%。 20 •幻觉传递（Hallucination Propagation）：LLM 生成的错误事实在后续步骤中被当作前提，引导 Agent 走向错误分支。在 SWE-bench Verified 的失败案例中，约 23% 的错误源于幻觉传递（Jimenez et al. 2024）。 •信用分配困境（Credit Assignment）：在长推理链中，成功或失败的信号难以精确归因到具体步骤。这与强化学习推理中的问题同源，但 Agent 场景因工具的介入而更复杂，失败的源头可能是 LLM 的推理错误，也可能是工具返回了异常数据。 •安全与对齐（Safety & Alignment）：自主 Agent 的自主属性带来了新的安全挑战，确保 Agent 不执行有害操作、定义明确的停止规则，并在自主性与可控性之间取得平衡。

15.2 认知架构

Agent 的认知架构（Cognitive Architecture）定义了推理、记忆、规划和学习之间的组织关系。本节先介绍所有现代 Agent 框架共同依赖的三种基础范式，再沿 ReAct 到元认知驱动的记忆-策略协同优化这条演进主线展开，呈现 Agent 从跟随脚本到理解自身思维过程的质变。

15.2.1 三大基础范式

ReAct（Reasoning + Acting, Yao et al. 2022）交替生成推理（Thought）和行动（Action），推理提供行动的上下文理由，行动为推理提供信息输入，二者构成感知、思考、行动的最小闭环。 Plan-Execute（Wang et al. 2023）先全局规划、再按步执行。规划阶段输出完整动作序列 [a , a , … , a ]，执行阶段依次 1 2 调用。优势在于全局最优；劣势在于无法应对执行过程中的观测偏差，需要重规划机制。 n Reflexion（Shinn et al. 2023）在 ReAct 基础上引入长期记忆和行为反思。当任务失败时，Agent 将失败经验写入情景记忆 M ，在下一次尝试时检索相关教训。三种范式的对比关系如图 15-4 所示。 episodic Reflexion Paradigm ReAct Loop Evaluate results Next attempt Failed Episodic Memory Write to Plan-Execute Paradigm Global planning Step 1 Deviation Step 2 Step n ReAct Paradigm Thought Action Observation 图15-4 三种基础 Agent 架构范式对比

15.2.2 ReAct

ReAct（Yao et al. 2022）奠定了现代 Agent 认知架构的基础。其核心洞察是：推理（Thought）和行动（Action）应交替进行而非分离——推理指导行动，行动为推理提供信息。一条典型的 ReAct 轨迹如下： Thought: I need to first search for Paris population... Action: Search("Paris population") Observation: Paris has a population of approximately 2.16 million... Thought: According to search results, Paris population is about 2.16 million. Now I need to calculate... 形式化地，ReAct 轨迹是一个交错序列： τ = (t1 , a1 , o1 , t2 , a2 , o2 , … , tn , an , on ) 其中 t 是第 i 步推理片段，a 是行动，o 是环境观测。每个步骤由 LLM 自回归生成： i i i p(ti , ai ∣ C, t<i , a<i , o<i ) = ∏ pLLM (xk ∣ C, … , x<k ) k ReAct 的威力在于协同效应：单独使用推理链（Chain-of-Thought）容易产生幻觉，单独使用行动可能盲目试错，二者的交错产生相互纠错的效果，如图 15-5 的时序所示。在原论文的评测中，ReAct 在 HotpotQA 和 Fever 等知识密集型任务上将基线准确率从 35.8% 提升至 62.3%。然而 ReAct 也存在明显局限： •无持久记忆：每次任务从零开始，不积累经验 •无规划能力：依赖即时推理，容易陷入局部最优 •不可自我改进：失败后不会调整策略 User Thought (Reasoning) Action Environment Task: "Which river is the French capital located on?" Thought: First search for France's capital Search("France capital") "Paris is the capital of France" Observation: Paris is the capital Thought: Now search for Paris's river Search("Paris river") "Seine River flows through Paris" Observation: Seine River Answer: Seine River User Thought (Reasoning) Action Environment 图15-5 ReAct 的推理-行动交错时序

15.2.3 反思与情景记忆

Reflexion（Shinn et al. 2023）是认知架构进化的第二站。其关键创新是引入了情景记忆，将失败经验的反思持久化存储，供后续尝试查询。 Reflexion 的运作分三层：

Actor（执行者）：基于 ReAct 的 LLM Agent，在环境中执行动作。
Evaluator（评估者）：判定执行结果。对于可验证任务（代码/数学），使用启发式规则 R (τ ) ∈ {0, 1}；对于开放域 eval 任务，使用 LLM 作为评判者。
Self-Reflection（自我反思）：将失败轨迹和评估结果输入 LLM，生成文本形式的教训（Lessons Learned），存入情景记忆缓冲区： mnew = LLMreflection (τfailed , Reval (τfailed ) = 0)

M ← M ∪ {mnew } 在 HumanEval 代码生成任务上，Reflexion 将 pass@1 从基线的 67.2% 提升至 91.0%。关键分析显示，提升主要来自首次尝试编码-测试-反思的 2-3 轮迭代。

15.2.4 记忆类型学

认知科学将人类记忆分为情景记忆、语义记忆、程序性记忆和工作记忆。现代 Agent 架构借鉴了这一分类，四类记忆的转换关系如图 15-6 所示： •工作记忆（Working Memory）：上下文窗口 + 当前任务状态。容量受 LLM 上下文窗口限制，通常在 10 − 10 4 6 tokens。技术挑战在于信息淘汰策略——哪些信息保留、哪些丢弃。 •情景记忆（Episodic Memory）：过往具体任务的执行轨迹。存储格式为 (task, τ , outcome) 三元组。检索方式包括稠密向量相似度搜索和稀疏关键词匹配。代表实现如 MemGPT（Packer et al. 2023）。 •语义记忆（Semantic Memory）：从具体经验中抽象出的通用知识。例如在处理 pandas DataFrame 时，先用 .info() 检查数据类型这类经验法则。语义记忆的形成涉及抽象化操作 Abstract : M →M 。 episodic semantic •程序性记忆（Procedural Memory）：固化的工作流和技能，类似人类的肌肉记忆。与语义记忆的区别在于：程序性记忆是知道如何做（know-how），语义记忆是知道是什么（know-that）。实现方式常见为可调用的 Skill 模块或 Function 封装。 Retrieval Mechanism Dense vector retrieval cosine similarity Sparse keyword BM25 / TF-IDF Hybrid retrieval Dense + Sparse + Rerank Agent Memory System Episodic Memory Specific task trajectory (task, trajectory, outcome) Abstraction Semantic Memory Retrieval Persist Abstract experience rules Query Working Memory Current context + task stat e Consolidate Load Procedural Memory Consolidated skills/workfl ows 图15-6 Agent 记忆系统的四类记忆及转换关系

15.2.5 元认知

元认知（Meta-Cognition）是 2024-2026 年认知架构研究的核心突破方向。与执行任务本身的对象级认知（Object-level Cognition）相对，元认知关注： •对当前任务的理解程度 •推理中是否存在不确定性 •是否需要改变策略或寻求帮助 •记忆是否足够覆盖当前问题 Meta-Cognitive Memory Policy Optimization（MetaMemPO, 2026）是首次将记忆策略（Memory Policy）和元认知能力联合优化的工作。其核心思想是将何时存储什么记忆、何时检索什么记忆也纳入强化学习策略优化的一环： πmeta = πmemory ∘ πpolicy 其中 π memory 控制记忆的读/写决策，π policy 控制任务执行的行动决策。两者通过联合 RL 优化： L(θmeta ) = Eτ ∼πmeta [∑ γ t ⋅ R(st , atask t ) + α ⋅ Rmemory (st , amem t )] t 在长程 Agent 基准（AgentBench, WebArena）上，MetaMemPO 相较固定记忆策略提升了 12-18% 的任务成功率，尤其在高干扰（distractor-heavy）环境中优势显著。元认知与对象认知的双层结构如图 15-7 所示。 Meta-Cognition Layer Confidence Estimation Uncertain -> request tool Object-Cognition Layer Perception Action Process Monitoring Strategy Selection Deviation found -> replan Switch strategy Reasoning Memory Policy Store/retrieval decision Memory Database 图15-7 元认知架构的双层结构

15.2.6 策略架构

策略架构定义了 Agent 如何组织决策过程。三种主要范式的对比如下： •整体式策略（Monolithic Policy）：单一 LLM 调用承担所有决策。优势在于实现简单、端到端可微（如果 LLM 本身微调的话）；劣势在于无法分解复杂决策空间。 π(a ∣ s) = LLM(s, prompt) •层级式策略（Hierarchical Policy）：高层策略 π 生成子目标（Subgoals），低层策略 π 执行具体动作： high low g ∼ πhigh (⋅ ∣ s) a ∼ πlow (⋅ ∣ s, g) 层级式策略在需要全局视野的长程任务中表现突出，因为高层策略可将复杂问题分解为 LLM 的上下文窗口能处理的子问题。基础范式中的 Plan-Execute 可视为层级式策略的最简形态：规划器充当高层，逐步执行器充当低层。 •混合式策略（Hybrid Policy）：将规则系统和 LLM 推理混合使用。例如，底层工具调用由确定性的 Function Calling 路由完成，高层策略选择由 LLM 完成。这种方式在效率和安全方面具有优势——关键步骤不依赖 LLM 的不确定性。维度整体式层级式混合式实现复杂度 ★☆☆☆☆ ★★★★☆ ★★★☆☆ 长程任务性能 ★★☆☆☆ ★★★★★ ★★★★☆ 推理效率 ★★★☆☆ ★★☆☆☆ ★★★★☆ 可解释性 ★☆☆☆☆ ★★★★☆ ★★★☆☆ 安全性 ★☆☆☆☆ ★★★☆☆ ★★★★★ 代表工作 ReAct, Toolformer ADaPT, LLM-Planner HuggingGPT, TaskWeaver 表15-3 认知架构的对比

15.2.7 规划方法

Agent 的规划策略决定了如何从当前状态到达目标状态。在 LLM Agent 的语境下，规划涉及在动作空间 A 上的搜索问题。三种规划方法的流程对比如图 15-8 所示。 •思维树（Tree-of-Thoughts, ToT, Yao et al. 2023）：将 LLM 推理建模为树搜索。对每个状态 s，LLM 生成 k 个候选下一步（宽度优先），对每个候选展开评估，选择最有前途的分支。ToT 的搜索策略可使用 BFS 或 DFS，核心是 LLM 作为状态评估函数 V (s) ∈ [0, 1]。 LLM •蒙特卡洛树搜索（MCTS for LLM）：将 MCTS 的四阶段循环（选择、扩展、模拟、回溯）引入 LLM 推理。在每个树节点，LLM 生成候选动作；模拟阶段由 LLM 快速评估；回溯更新节点价值。AlphaMath 和 TreeOfCode 等方法证明了 MCTS + LLM 在数学证明和代码生成中的有效性。 •LLM 分解规划（LLM-based Decomposition）：不依赖搜索，而是依赖 LLM 的内在知识直接进行任务分解： Plan = LLM("Decompose the task into sub-steps", task) 分解的质量取决于 LLM 的常识推理能力。对于 LLM 熟悉的领域（如常见编程任务），分解规划效果优秀；对于 LLM 未见过的组合，搜索方法提供更可靠的覆盖。 Tree Search Methods MCTS Method LLM evaluates each candid Decomposition Planning Methods ate Selection (UCB1) Expansion (LLM generates Simulation (LLM quick eval LLM generates k candidate V(s) ∈ [0,1] Task description LLM direct decomposition Subtask 1, Subtask 2, ..., S child nodes) uation) Backpropagation (update s ubtask n Current Node Q values) Task root node s_0 Select branch with highes Deepen t V(s) Backtrack 图15-8 三种规划方法的流程对比

15.2.8 认知架构的性能对比

在长程 Agent 基准上的综合表现：架构 AgentBench WebArena SWE-bench Verified 推理效率 (tokens/task) ReAct (2022) 18.2% 14.7% 12.5% 15K Reflexion (2023) 24.6% 21.3% 23.1% 28K Tree-of-Thoughts (2023) 22.8% 17.9% 15.3% 42K MCTS + LLM (2024) 27.3% 20.5% 19.8% 35K 架构 AgentBench WebArena SWE-bench Verified 推理效率 (tokens/task) Hierarchical Policy (2024) 31.5% 26.2% 28.4% 22K MetaMemPO (2026) 37.8% 33.1% 35.7% 25K GPT-4 (human baseline) 约 45% 约 40% 约 50% — 表15-4 认知架构在基准上的表现关键洞察： •记忆策略自适应（MetaMemPO）在各基准上带来 6-8% 的绝对提升，证明记忆管理的元认知化是正确方向 •树搜索方法的推理成本高（多分支 LLM 调用）但性能提升有限——MCTS 的最优设定是在分支数 k = 3 和深度 d = 4 附近 •层级式策略在推理效率（tokens/task）上的优势源于子目标隔离了无关上下文

15.2.9 认知架构的开放性挑战

尽管取得了显著进展，认知架构仍面临三个根本性开放问题： •记忆的遗忘与选择性：Agent 的长期记忆缓冲区会无限膨胀。当前方法主要基于 LRU 和时间戳淘汰，缺乏基于语义重要性的策略，人类的遗忘曲线（Ebbinghaus Forgetting Curve）能否作为启发式规则尚无定论。 •元认知的校准：元认知判断需要校准，即在元认知信心与实际正确率之间建立对应关系。未经校准的元认知可能放大错误决策。在 Agent 场景中，校准难度因工具依赖的复杂反馈而加剧。 •架构搜索的自动化（Architecture Search）：当前 Agent 的认知架构大多数是人工设计的——选择 ReAct 而非 ToT，选择层级式而非整体式。能否让 Agent 自主搜索最优的认知架构是开放问题：技能层面的探索已由自进化机制推进，算法层面的自主改进仍处于研究初期。

15.3 自进化 Agent

自进化 Agent（Self-Evolving Agent）是 2025-2026 年 Agent 研究的最前沿方向。其核心理念是：Agent 不应由人类持续手动调整，而应通过任务经验的积累自主改进其策略、技能和工具。本节讨论技能与经验层面的闭环进化，从范式原理、关键技术到工程实现系统阐述完整技术栈；算法发现、递归自改进等更高层级的自进化形态属于更深层的开放问题，不在本节范围内。

15.3.1 自进化 Agent 的核心范式

自进化 Agent 的形式化定义：一个 Agent 系统 A 在时间 t 的状态为 A = (π , S , M )，其中 π 为策略，S 为技能库，M 为记忆库。自进化操作 Φ 将系统从 t 更新到 t + 1： t t t t t t t At+1 = Φ(At , Dtexp , Fmeta ) 其中 D 为时间段 [t, t + 1) 内积累的任务经验，F 为元学习框架。 exp t meta 与传统训练-部署的静态 Agent 不同，自进化 Agent 的关键区分因素是闭环进化（Closed-Loop Evolution），其循环结构如图 15-9 所示： Self-Evolution Loop (Closed-Loop Evolution) Skill Update Consolidate new patterns i Reflection & Analysis nto skills/workflows Extract patterns from succ Experience Collection ess/failure trajectories Deployment & Validation Agent executes tasks, reco Success rate ▼ -> rollback Validate new skills in subs rds trajectories equent tasks Success rate ▲ -> continue 图15-9 自进化 Agent 的闭环进化循环这一循环的每一次迭代都缩小了 Agent 当前能力与任务所需能力之间的差距： Gap(t) = Etask∼T [Perf(At , task) − Perftarget (task)]

15.3.2 经验内化

Google DeepMind 的 Continual Experience Internalization 工作（2026）是自进化 Agent 研究的重要理论框架。其核心问题为：Agent 在持续运行中会产生大量经验数据 D = {τ , τ , … , τ }，但并非所有经验对策略改进同等有用。经验质 1 2 量从三个维度评价： N •新奇性（Novelty）：经验与已有记忆的差异程度，N (τ ) = min d(emb(τ ), emb(m)) m∈M •信息量（Informativeness）：经验提供的学习信号强度，I(τ ) = ∥∇ log π (a ∣ s) ⋅ R(τ )∥ θ θ •可迁移性（Transferability）：经验可推广到其他任务的程度，T (τ ) = E ′ [ΔPerf(task ∣ τ )] task′  =task 经验的内部化（Internalization）策略为： ⎧纳入训练集 if N (τ ) > θ ∧ I(τ ) > θ Internalize(τ ) = ⎨压缩为语义摘要 if T (τ ) > θ N I ⎩ 丢弃 T otherwise 实验表明，以新奇性和信息量作为联合标准的经验筛选，相比均匀采样可减少 60% 的训练数据量而达到相同性能。

15.3.3 MMG2Skill

MMG2Skill（2026）解决了自进化 Agent 的一个关键瓶颈：技能从哪里来？其核心思想是将互联网上的文本指南（In- the-Wild Guides）自动蒸馏为可执行的 Agent 技能。整个流水线分为三个阶段，如图 15-10 所示：

指南提取（Guide Extraction）：给定自然语言指南（如 Reddit 帖子、Tutorial 文章、Stack Overflow 答案），LLM 提取操作步骤序列： (step1 , step2 , … , stepk ) = Extract(guide_text)
技能合成（Skill Synthesis）：将步骤序列转化为参数化的可执行函数： Skill(p1 , p2 , … , pm ) = Synthesize(step1 , step2 , … , stepk )

其中 p 为技能参数（如文件路径、关键词、阈值等）。 i 3. 执行验证（Execution Validation）：在新实例上测试技能，收集成功或失败信号： Ntest score(Skill) = ∑ 1[Execute(Skill, instancei ) = success] Ntest i=1 在 MiniWoB++ 和 WebArena 等 Web Agent 基准上，MMG2Skill 自动蒸馏的技能库使 Agent 在未见过的网站上的任务成功率提升 22.7%。 Pass Skill Library Production deployment Collect new experiences Feedback loop -> skill impr Execution verification ovement Internet text guides Guide extraction Skill synthesis Verify on test instances Reddit/Tutorial/StackOver LLM extracts steps Parameterized executable Failed flow function Fix and resynthesize 图15-10 MMG2Skill 的三阶段技能蒸馏流水线

15.3.4 SkillAdaptor

Ant Group 的 SkillAdaptor（2026）解决了自进化 Agent 的另一个关键问题：如何从 Agent 自身的执行轨迹中自动发现和提炼技能。与 MMG2Skill 依赖外部指南不同，SkillAdaptor 的输入是 Agent 自身的轨迹数据，其自适应技能挖掘流水线如图 15-11 所示。核心算法为：

轨迹分割（Trajectory Segmentation）：在 Agent 的长轨迹中检测可复用子序列： Segment(τ ) = {(si , ai , … , sj , aj ) ∣ ReuseScore(i, j) > θ} 其中 ReuseScore(i, j) 衡量子序列 (i, j) 在其他轨迹中出现的频率。
技能抽象（Skill Abstraction）：将具体执行实例泛化为模板技能。对于子序列中变化的参数位置（如具体的文件名、数值），替换为参数槽位： Skillgeneric = Abstract(τi:j , {pk }m k=1 )
技能验证与入库：验证泛化技能在不同实例上的性能： if Perf(Skillgeneric , Dholdout ) > τmin then S ← S ∪ {Skillgeneric }

Agent execution trajectory database τ_1, τ_2, ..., τ_N Trajectory segmentation Detect reusable segments Skill Abstraction Generalize to parameterize d template Failed Record new trajectory Skill Verification Test on held-out set Pass Skill Library Continuously growing New task uses skill Production Agent 图15-11 SkillAdaptor 的自适应技能挖掘流水线关键实验结果：SkillAdaptor 在持续运行 1000 个任务后，技能库从初始的 3 个种子技能增长到 47 个提取技能，Agent 在后续 500 个任务上的平均成功率从 42.3% 提升至 61.8%。

15.3.5 Adaptive Auto-Harness 自改进

Adaptive Auto-Harness（2026）将自进化 Agent 推向了更大规模：在开放式的、无限的任务流（Open-Ended Task Stream）上实现持续自改进。核心贡献是两个相互制约的机制： •Auto-Harness Generation：自动生成新的训练任务（Harness），使得 Agent 在自身薄弱点上受到针对性训练。任务生成器 G 的目标是： max Etask∼G [Learning Gain(task)] = max Etask∼G [ΔPerf(π ∣ Train(π, task))] G G •Catastrophic Forgetting Prevention：在新任务上训练时，防止旧能力的退化。引入弹性权重巩固（Elastic Weight Consolidation, EWC）启发的正则项： Ltotal = Lnew + λ ∑ Fi (θi − θi∗ )2 i 其中 F 为 Fisher 信息矩阵的对角元，衡量参数 i 对旧任务的重要性，θ 为旧任务的最优参数。持续自改进的完整循环 ∗ 如图 15-12 所示。 i i Harness Auto-generation Agent weakness detection Generate targeted training tasks Continuous Training Train agent policy New tasks create new wea knesses EWC Regularization Prevent catastrophic forge tting Old task degraded -> adjus tλ Evaluation and Deployment Evaluate on mixed old+ne w tasks Performance improved -> deploy Update production agent 图15-12 Adaptive Auto-Harness 的持续自改进循环

15.3.6 自进化循环的工程实现

将上述范式落地为工程系统面临四个实际问题： •经验数据的质量过滤：并非所有经验都值得学习。实现中通常设置成功轨迹保留比例 r success ，仅保留置信度高于阈值的轨迹。典型实现中 r ≈ 0.3 − 0.5。 success •技能冲突检测：新技能可能与已有技能在功能上重叠或冲突。解决方案是维护技能编码的嵌入空间，当新技能嵌入与已有技能嵌入的余弦相似度 cos(e , e ) > 0.95 时触发去重或合并。 new old •安全沙箱执行：自进化 Agent 在进化过程中可能产生危险的行为模式。需要在沙箱环境中验证新技能的安全性，包括代码审计、资源使用限制和操作范围约束。 •人类在回路中的角色：完全自主的进化存在价值漂移（Value Drift）风险。实际系统中通常设置人类审批节点：当技能涉及高影响操作（如文件删除、API 写入）时，暂停进化并等待人类批准。工程挑战解决方案成熟度实施复杂度经验质量过滤新奇性+信息量联合筛选 ★★★★☆ ★★★☆☆ 技能冲突检测嵌入空间去重 ★★★☆☆ ★★☆☆☆ 安全沙箱限权容器 + 代码审计 ★★★★☆ ★★★★☆ 价值漂移人类审批节点 ★★☆☆☆ ★★★★★ 灾难性遗忘 EWC 正则化 ★★★☆☆ ★★★★☆ 计算效率增量训练 + 模型压缩 ★★★☆☆ ★★★★★ 表15-5 自进化 Agent 的工程挑战

15.3.7 自进化 Agent 的双刃剑

自进化 Agent 提供了一条从人类设计 Agent 到 Agent 自我改进的路径，但也带来了独特的风险。收益体现在三个方面： •规模效应：一个自进化 Agent 可以在无人类干预的情况下对数百万个任务进行经验学习和技能积累 •领域适应性：Agent 能自动适应新领域而无需人类专家重新设计 •能力涌现：技能间的组合可能产生人类未预见的解决方案风险同样突出： •目标漂移（Goal Drift）：在自进化过程中，Agent 可能偏离原始设计目标，优化出人类不期望的行为 •奖励黑客（Reward Hacking）：如果进化目标由可量化的评估函数定义，Agent 可能学会利用评估函数的漏洞 •不可解释性积累：随着进化代数的增加，Agent 决策链的复杂度可能超出人类理解的阈限这些风险的工程化缓解手段包括沙箱验证、人类审批节点与形式化安全约束。三者分别应对行为失控、价值漂移与不可解释性积累，构成自进化系统的安全底线。

15.4 搜索与深度研究 Agent

搜索与深度研究 Agent 是 Agent 技术当前最活跃的应用领域之一。与通用 Agent 不同，搜索 Agent 的核心能力在于从海量信息源中高效检索、综合和验证信息，并生成结构化的研究报告。本节覆盖从强化学习搜索到全自动研究系统的完整技术谱系。

15.4.1 搜索 Agent 的问题定义

搜索 Agent 的优化目标可形式化为： max Eq∼Q [Score (Reportπ (q), Report∗ (q)) − λ ⋅ Costπ (q)] π 其中 q 为研究问题，Report (q) 为 Agent 策略 π 生成的报告，Report (q) 为参考答案，Cost (q) 为搜索成本（API 调用次 ∗ 数、时间、token 消耗）。 π π 搜索 Agent 的独特挑战在于： •信息质量不确定：网页/文档的可信度差异大 •搜索空间巨大：互联网规模的信息量 •信息时效性衰减：旧信息可能过时 •自我验证困难：Agent 需要判断自己生成的信息是否可靠标准工作流的各阶段如图 15-13 所示，规划、搜索、提取、验证与综合形成闭环。 Extract: Extract key inform ation from results Research question q Plan: Decompose into sub- Search: Call search engin Verify: Cross-verify inform Sufficient Synthesize: Generate struc Output: Citable research r questions e/database ation consistency tured report eport Uncertain 图15-13 搜索 Agent 的标准工作流

15.4.2 Harness-1

Harness-1（Chroma, 2026）首次将强化学习系统地应用于搜索 Agent 的训练。其核心创新是状态外化 Harness（State- Externalizing Harness）——将搜索 Agent 的内部推理状态转化为可观测的结构化表示，使得 RL 奖励信号可以针对具体搜索步骤施加。状态外化的关键设计：Agent 的每一步搜索决策不仅生成行动（query, click, scroll），还生成结构化的状态摘要： query_quality info_completeness st = Externalize(LLMinternal , contextt ) = confidence contradictions_found t RL 训练的目标是最大化搜索路径的信息增益： Rt = IG(st , st−1 ) = H(belieft ) − H(belieft−1 ) 其中 H(belief) 为 Agent 对答案的信念熵，信息增益越大表示该步搜索消除了越多不确定性。训练流程使用 GRPO（Group Relative Policy Optimization）对搜索策略进行在线 RL 训练，其完整时序如图 15-14 所示。在每个训练批次中，对于同一个问题，并行抽样 8 条搜索路径，使用信息增益作为奖励信号进行组内比较。在 HotpotQA、Bamboogle 等多跳搜索基准上，Harness-1 相较 ReAct 基线实现了 15-23% 的准确率提升和 30-40% 的搜索步数缩减。 Question Agent Harness Search Engine Reward Calculation Query question loop [Search step t=1..T] LLM generates search decision Execute query query_t Return Results Externalize state s_t Compute information gain IG_t Reward signal Update belief state Synthesize answer Question Agent Harness Search Engine Reward Calculation 图15-14 Harness-1 的状态外化 RL 搜索时序

15.4.3 OpenWebRL

Microsoft 的 OpenWebRL（2026）将搜索 Agent 的 RL 训练从纯文本域扩展到视觉 Web 域。传统的搜索 Agent 仅处理文本搜索结果（如搜索引擎返回的摘要），OpenWebRL Agent 需要操作真实的浏览器：点击按钮、滚动页面、填写表单。在多模态观测空间中，时刻 t 的观测为 o = (I , DOM , URL )，其中 I 为截图，DOM 为 DOM 树。RL 策略 π(a ∣ o , h ) 输出动作 a ，包括 Click(x, y)、Type(text)、Scroll(direction) 等。 t t t t t t t t t−1 t 在线多轮 RL 训练使用在线环境交互，Agent 与真实网站交互，实时接收反馈。OpenWebRL 在 500+ 个真实网站上进行了 RL 训练，验证了三个关键发现： •在线 RL 相较离线 SFT 可提升 27% 的任务成功率 •裁剪图像（Cropping）比完整页面截图（Screenshot）更适合作为 RL 观测 •动作空间的离散化（将 x,y 连续坐标映射到可交互元素）是 RL 收敛的关键训练方案 WebArena 成功率 Mind2Web 成功率平均步数纯 SFT（GPT-4V） 14.2% 18.7% 12.3 SFT + 离线 RL 18.9% 23.1% 10.8 SFT + 在线 RL（单轮） 22.4% 27.5% 9.6 SFT + 在线 RL（多轮） 28.1% 32.3% 8.2 OpenWebRL（完整） 33.5% 36.8% 7.1 表15-6 搜索 Agent 的训练方案

15.4.4 信息时效与观测掩码

深度搜索 Agent 面临一个独特挑战：在长达几十步的搜索过程中，早期获取的信息可能因时效性（Staleness）而不可靠。Masking Stale Observations（2026）系统地研究了这一问题并提出解决方案。信息衰减可以定量刻画。定义信息时效性函数 f (t, t , topic)，表示在初始时间 t 获取的信息在时间 t 仍然有效的概 fresh 0 0 率。不同领域的信息衰减速率差异巨大： •股票价格：半衰期 ≈ 秒-分钟级 •新闻事件：半衰期 ≈ 小时-天级 •学术知识：半衰期 ≈ 年量级解决方案是信息掩码（Information Masking）：对超过时限的信息进行软掩码（降低其检索和引用权重）或硬掩码（完全排除）： weight(info, t) = weightorig ⋅ exp (−λtopic ⋅ (t − t0 )) 其中 λ 为根据主题自动估计的衰减率。该机制在需要实时信息的搜索任务上带来了 8-12% 的准确率提升。 topic

15.4.5 FineVerify

FineVerify（2026）针对深度研究 Agent 的幻觉传递问题提出了推理时自我验证（Test-Time Self-Verification）框架。核心思想：在生成研究报告的每个中间步骤，引入细粒度验证（Fine-Grained Verification）模块，对声明（Claim）进行原子级验证。验证管道：

声明提取（Claim Extraction）：从生成文本中提取所有可验证的原子声明： {c1 , c2 , … , ck } = Extract(generated_text) 每个声明 c 是形如“Paris has a population of 2.16 million”的原子事实。 i
证据搜索（Evidence Search）：为每个声明独立搜索证据： evidencei = Search(ci )
校验判定（Verification Judgment）：LLM 判断 evidence 是否支持 c ： i i ⎧SUPPORT 如果证据支持声明 verdict = ⎨REFUTE

⎩ 如果证据反驳声明 INCONCLUSIVE 如果证据不充分 i 4. 更正传播（Correction Propagation）：对被反驳的声明进行修正，并将修正级联到依赖该声明的后续部分： corrected_text = LLM(original_text, {verdicti , evidencei }) FineVerify 在 FActScore 和 LongFact 等长文本事实性基准上，将事实错误率从 23.7% 降低至 8.3%，验证成本约为生成成本的 3 倍，符合测试时计算扩展的规模法则。完整的自我验证流水线如图 15-15 所示。 LLM Generation Research report draft Claim Extraction Identify atomic claims c_ 1...c_k Parallel Evidence Search Each claim searched indep endently Verification Judgment LLM: SUPPORT / REFUTE / INCONCLUSIVE All SUPPORT REFUTE exists Correction Propagation Output verified report Fix erroneous claims + cas cade updates 图15-15 FineVerify 的自我验证流水线

15.4.6 TVIR

TVIR（Text-Visual Interleaved Reports, 2026）将深度研究 Agent 的输出从纯文本提升为文本-视觉交错报告，不仅综合文字信息，还自动生成相关的图表、信息图和可视化。 TVIR 的四阶段生成流程：

内容规划（Content Planning）：确定报告结构、各章节主题和预期的视觉元素类型（折线图/柱状图/流程图/关系图等）。
并行采集（Parallel Acquisition）：文本 Agent 和视觉 Agent 并行工作。文本 Agent 搜索和综合文字信息，视觉 Agent 搜索相关图表和数据可视化所需的原始数据。
交叉编排（Cross-Modal Orchestration）：将文本段落和视觉元素编织为连贯的叙事流，确保文本对图表的引用准确且上下文一致。
全局一致性检查（Global Consistency Check）：验证报告全文的统计数字一致性（同一数值在不同图表和段落中一致）、视觉风格一致性（配色、字体、图表类型），以及逻辑连贯性。在 DeepResearchBench 上，TVIR 生成的多模态报告在信息完整性、可读性和专业度三个维度上均显著优于纯文本报告。

15.4.7 ForeSci

ForeSci（Forward-looking AI Research Judgment, 2026）解决自动化研究的上游问题：判断哪些研究方向值得投入资源。它是一个元研究 Agent，通过分析研究趋势、引用网络和资源需求提供前瞻性的研究方向推荐，与 AutoLab 共同构成从方向选择到实验执行的完整链路。 ForeSci 的评分函数： Potential(d) = α ⋅ Trend(d) + β ⋅ Feasibility(d) + γ ⋅ Impact(d) − δ ⋅ Competition(d) 其中 Trend(d) 衡量方向 d 的上升趋势，Feasibility(d) 衡量技术可行性，Impact(d) 衡量潜在影响力，Competition(d) 为竞争激烈程度的惩罚项。在 AI 学术会议的盲测中，ForeSci 对热门前沿方向的预测召回率达到 78.3%。

15.4.8 AutoLab

AutoLab（2026）代表了搜索 Agent 的终极形态，不仅能搜索和阅读文献，还能设计实验、执行实验、分析结果并生成论文。其全自动研究流水线如图 15-16 所示。 AutoLab 的能力层次：

文献综述（Literature Review）：搜索、阅读、归纳相关文献
假设生成（Hypothesis Generation）：基于文献缺口提出可验证的研究假设
实验设计（Experiment Design）：设计变量、对照组、样本量、评估指标
代码生成与执行（Code Generation & Execution）：编写实验代码，在计算环境中执行
结果分析（Result Analysis）：统计分析、可视化、结论推导
论文撰写（Paper Writing）：生成符合学术规范的完整论文 AutoLab Fully Automated Research Pipeline Experiment Design Code Generation & Executi on Auto Submission Literature Review Hypothesis Generation Result Analysis Significant results Paper Writing (After human review) Non-significant results

图15-16 AutoLab 的全自动研究流水线 AutoLab 在多个 ML/AI 子领域的实验中表现出了较强的能力，但也暴露了根本局限：完全自主的科学研究在面对不显著结果时需要人类的领域直觉来决定是调整假设还是接受负结果。

15.4.9 搜索 Agent 基准对比

系统 HotpotQA (EM) Bamboogle (Acc) WebArena (SR) DeepResearchBench 平均搜索步数 ReAct (2022) 35.7% 27.4% 14.7% 22.3% 14.2 Reflexion (2023) 42.1% 33.8% 21.3% 29.6% 16.8 Harness-1 (2026) 58.4% 51.2% — 38.9% 9.3 OpenWebRL (2026) — — 33.5% — 7.1 FineVerify (2026) 52.6% 46.9% — 44.2% 18.5 TVIR (2026) — — — 41.7% 22.3 AutoLab (2026) — — — 35.2% 31.7 表15-7 深度研究 Agent 系统对比表中 ReAct 与 Reflexion 的分数为统一评测协议下的复现值，普遍低于各自原论文的报告值（ReAct 原论文在 HotpotQA 上报告 62.3%）。关键趋势： •RL 驱动的搜索（Harness-1, OpenWebRL）显著减少了搜索步数，更聪明地搜索而非更努力地搜索 •自验证机制（FineVerify）增加了搜索步数但换来了大幅的事实准确率收益——体现了测试时计算扩展的价值 •全自动研究（AutoLab）仍在早期阶段，在标准基准上落后于人类引导的半自动方案

15.5 多 Agent 系统

单体 Agent 受限于单一视角和单一策略空间。多 Agent 系统（Multi-Agent Systems, MAS）通过多个专业 Agent 的协作，突破这些上限。本节系统梳理多 Agent 架构模式、通信协议、协调机制和经济理性。

15.5.1 多 Agent 系统的设计空间

多 Agent 系统可由三个正交维度表征： •角色定义（Role Definition）：决定 Agent 是同质（Homogeneous）还是异质（Heterogeneous）。同质 Agent 共享相同的策略和能力，异质 Agent 各具专长（编码、测试、文档、审查等）。 •协调结构（Coordination Structure）：分为集中式（Centralized）、去中心化（Decentralized）与层级式（Hierarchical）三种。 •通信范式（Communication Paradigm）：包括广播（Broadcast）、点对点（Peer-to-Peer）、共享内存（Shared Memory）与黑板（Blackboard）等方式。三种协调拓扑的结构如图 15-17 所示。 Hierarchical Centralized Coordinator Worker 1 Agent 1 Decentralized Consensus Middle 1 Agent 2 Agent 3 Top Manager Worker 2 Agent 1 Agent 4 Central Coordinator Agent 2 Middle 2 Worker 3 Agent 3 图15-17 多 Agent 系统的三种协调拓扑

15.5.2 集中式协调器架构

集中式架构是最常见的多 Agent 实现模式。一个中央协调 Agent（Orchestrator）负责任务分解、Agent 分配和结果聚合。形式化地，协调器解决以下调度问题： max E [∑ Perf(Aassign(i) , Ti )] K s.t. ∑ Cost(Aassign(i) , Ti ) ≤ B assign i=1 i 其中 T , … , T 为子任务，A 为可用 Agent，assign : [K] → [N ] 为分配函数，B 为总预算约束。 K j 代表系统： •ChatDev（Qian et al. 2023）：模拟软件公司的组织架构。CEO、CTO、程序员、测试员、设计师等角色通过多轮对话协作完成软件开发任务。在 HumanEval 和 MBPP 上展示了多角色协作对代码质量的显著提升。 •AutoGen（Microsoft, 2023）：提供灵活的多 Agent 对话框架，用户定义 Agent 角色、能力和对话模式，协调器自动管理回合式（turn-based）的 Agent 对话。 •MetaGPT（Hong et al. 2023）：引入 SOP（Standard Operating Procedures），为多 Agent 协作规定结构化的操作流程，如需求分析 → 系统设计 → 编码 → 测试的标准软件工程流程。集中式架构的优势在于全局优化和冲突调解；劣势在于单点故障（协调器成为瓶颈）和通信开销随 Agent 数量线性增长。

15.5.3 去中心化共识架构

去中心化架构中，没有单一协调器——Agent 通过共识协议（Consensus Protocol）自主达成一致。常见的共识机制有三类：（1）投票共识（Voting Consensus）：每个 Agent 对候选方案投票，多数决定： N decision = arg max ∑ 1[Ai votes for d] d∈D i=1 简单有效，但忽略了 Agent 的专业度差异。（2）加权投票（Weighted Voting）：根据 Agent 在当前子领域的历史正确率分配权重： N Accuracyi decision = arg max ∑ wi ⋅ 1[Ai votes for d], wi = ∑j Accuracyj d i=1 （3）辩论协议（Debate Protocol）：Agent 不以投票形式决策，而是通过多轮辩论逐步收窄分歧。每轮中，Agent 们依次陈述论点、反驳对方、修正立场，交互流程如图 15-18 所示： Question Agent 1 (Proponent) Agent 2 (Opponent) Judge LLM Present argument Present argument Rebuttal Rebuttal Revised argument Revised argument Final position Final position Synthesized judgment Question Agent 1 (Proponent) Agent 2 (Opponent) Judge LLM 图15-18 多 Agent 辩论协议的交互流程 Irving et al.（2018）和 Du et al.（2023）的开创性工作证明了辩论机制的价值：在需要深度推理的问题上，两 Agent 辩论产生的答案质量显著优于单 Agent 的多次采样。

15.5.4 层级式架构

层级式架构结合了集中式和去中心化的优势：顶层 Agent 负责战略性决策，中层 Agent 负责战术协调，底层 Agent 负责原子执行。任务沿层级逐级分解为树状结构： Task 高层 {Subtask , … , Subtask } 中层 {Sub-subtask , …} 低层 {Action , …} m i1 ijk 层级深度 d 的选择是一个经典的效率-准确性权衡：d 越大，每个叶节点的任务越简单，但层级间的通信和协调开销越大。

15.5.5 流式通信

传统的多 Agent 通信是回合制（Turn-based）的：Agent A 完成完整的推理后，将其输出整块发送给 Agent B。 Streaming Communication（2026）提出了流式通信范式：Agent A 在生成推理的过程中，将其部分中间结果实时流式传输给 Agent B，使 B 可以在 A 还在推理时就开始工作。流式通信的延迟优势分析： n n−1 Latencyturn-based = ∑ ti vs. Latencystreaming = max ti + ∑ ϵi i i=1 i=1 其中 t 为 Agent i 的推理时间，ϵ 为流式传输和处理延迟。在最理想的并行场景中，流式通信可将端到端延迟从 O(n) 降低至 O(1)。 i i 工程实现上，流式通信需要解决前缀不稳定性（Prefix Instability）：接收 Agent 基于不完整的前缀开始推理，当前缀在后续发生实质性修改时，已生成的推理可能需要回滚或修正。实现采用软承诺 + 回溯（Soft-Commit + Rollback）策略。

15.5.6 多 Agent RL 适用场景

多 Agent 系统并非在所有场景下都优于单 Agent。Multi-Agent RL for LLM Workflows（2026）首次通过大规模实证研究回答了多 Agent RL 何时有帮助的问题。实验设计：在 12 个任务类别（代码生成、数学推理、逻辑推理、知识问答等）和三种 Agent 数量配置（1/3/5）下，对比多 Agent RL 的效果。核心发现： •任务可分解性（Task Decomposability）是关键调节因子：任务可自然分解为独立子问题时，多 Agent RL 优势显著（提升 15-25%）；任务不可分解时，多 Agent 反而引入冗余通信，性能下降 3-8%。 •最优 Agent 数量与任务规模相关：对于小规模任务（<5 步），3 Agent 最优；中规模（5-15 步），5 Agent 最优；大规模（>15 步），收益递减（diminishing returns），甚至负收益。 •异质 Agent 始终优于同质 Agent：具有不同专长（coding/testing/reviewing 各有侧重）的异质 Agent 体系始终优于同质 Agent，提升约 8-12%。任务类型可分解性单 Agent 3-Agent RL 5-Agent RL 最优配置代码生成（SWE-bench） ★★★★★ 35.7% 48.2% 44.1% 3 异质数学推理（AIME） ★★☆☆☆ 67.3% 66.8% 63.5% 1 信息检索（HotpotQA） ★★★★☆ 52.4% 61.9% 64.3% 5 异质创意写作 ★☆☆☆☆ 82.1% 78.3% 74.6% 1 软件测试 ★★★★☆ 41.2% 52.8% 55.1% 5 异质表15-8 任务可分解性与多 Agent 性能

15.5.7 多 Agent 计算机操作

Multi-Agent Computer Use（2026）将多 Agent 系统应用于计算机操作领域——多个 Agent 共享一个桌面环境，分工协作完成复杂的 GUI 操作任务。这一工作的关键挑战在于行动空间冲突：两个 Agent 同时尝试操作同一 UI 元素时，发生竞争冲突。解决方案是引入注意力锁机制（Attention Lock Mechanism）：Agent 在执行 GUI 操作前，先锁定目标区域，其他 Agent 在锁定释放前不可操作该区域：  i, ∄aj : target(aj ) = elemente Lock(Ai , elemente ) ⟹ ∀j = 在 OSWorld 基准上，多 Agent 计算机操作系统相较单 Agent 提升了 18% 的任务成功率，尤其在需要并行窗口操作的任务（如跨应用复制粘贴数据）中优势明显。注意力锁机制的协作示意如图 15-19 所示。 Agent 1: Browser operatio n Request data Return Results Agent 2: Data processing Locked Write to file Confirm completion Locked Agent 3: Command executi on Locked Shared Desktop Environment Application Window 1 Application Window 2 Terminal Window 图15-19 多 Agent 计算机操作的注意力锁机制

15.5.8 Economy of Minds

Harvard 的 Economy of Minds（2026）将经济学框架引入多 Agent 系统设计。核心思想：在多 Agent 环境中，Agent 应被视为理性经济个体，其行为受成本-收益分析的驱动。该框架包含两个核心机制。 •信息市场（Information Market）：Agent 之间不再是免费共享信息，而是在信息市场中交易。Agent i 拥有信息片段 I ，Agent j 需要该信息完成任务。交易价格为： i P (Ii → Aj ) = Value(Ii ∣ taskj ) ⋅ Scarcity(Ii ) 其中 Value(I ∣ task ) 衡量信息对任务的价值，Scarcity(I ) 衡量信息的稀缺性（持有该信息的 Agent 数量越少，价格越高）。 i j i •竞标机制（Bidding Mechanism）：当多个 Agent 声称可以完成同一子任务时，协调器采用竞标机制选择执行者： Select(A∗ ) = arg min [PriceA + λ ⋅ RiskA ] A 其中 Price 为 Agent 索要的执行成本（计算资源消耗），Risk 为预估的失败概率。 Economy of Minds 框架的价值在于：它提供了一种可扩展的、去中心化的多 Agent 管理方式——不需要人类预定义每个 Agent 的职责，而是让市场机制自组织地形成最优分工。

15.5.9 多 Agent 系统的开放挑战

多 Agent 系统在规模化应用前仍面临四个开放挑战： •通信效率：N 个 Agent 的全连接通信开销为 O(N )，需要设计稀疏通信拓扑，在保证性能的前提下降低通信成本。 •对抗性 Agent（Adversarial Agents）：需要检测和处理恶意或被攻陷的 Agent。一个说谎的 Agent 可能在辩论协议中误导整个多 Agent 系统走向错误方向。 •多 Agent 的对齐（Multi-Agent Alignment）：当多个 Agent 各自优化不同的目标函数时，全局行为可能偏离人类意图，即使每个 Agent 单独看起来是对齐的。 •可扩展性：当 Agent 数量从 5 增加到 50、500 时，当前的多 Agent 系统需要保持性能。集中式协调器必然成为瓶颈，层级式架构需要动态调整层次深度。

15.6 自主 Agent 系统

自主 Agent 系统代表了 Agent 技术发展的最高形态——能够在最小人类干预下独立完成复杂、长程、开放式的任务。本节先界定自主性的分级标准，再考察自主编码、数据科学与提示优化等已落地的垂直方向及对应基准，随后进入自进化 AI 的技术谱系与递归自改进前沿，最后讨论安全问题与未来趋势。

15.6.1 自主 Agent 实践

自主性的四级递进自主 Agent 的自主性体现在四个递进的层次：

步骤执行（Step Execution）：Agent 能执行单个预定义的动作（如运行 pytest）。人类需要手动串联步骤。
子任务执行（Subtask Execution）：Agent 能完成人工分解后的子任务（如修复这个函数的 bug）。人类提供顶层分解。
任务执行（Task Execution）：Agent 能从自然语言任务描述独立完成整个任务（如实现用户注册功能并写测试）。人类仅需定义任务目标。
目标驱动（Goal-Driven）：Agent 能从高层目标出发，自主分解任务、选择工具、评估进展、调整策略，并在不确定时主动寻求人类反馈（如优化系统的响应延迟）。四级能力递进关系如图 15-20 所示，每一级都提升一层人类介入的抽象程度。 E.g.: run pytest

L1 Step Execution E.g.: fix bug in this functio Human: Sequence steps n Agent: Execute single step L2 Subtask Execution Human: Top-level decomp E.g.: implement user regist osition ration and tests Agent: Complete subtask L3 Task Execution Human: Define goal E.g.: optimize system resp Agent: Complete independ onse latency ently L4 Goal-Driven Human: High-level intent Agent: Autonomous deco mposition+execution+adj ustment 图15-20 自主 Agent 的四级能力递进 2) 自主编码自主编码是自主 Agent 最成熟的垂直领域。从简单的函数补全（GitHub Copilot）到自主解决 GitHub Issues 的 SWE- agent，自主编码 Agent 已实现了显著的工程化进展，其标准化流水线如图 15-21 所示。关键技术栈：

代码定位（Code Localization）：在大型代码库中快速定位需要修改的文件。使用基于 BM25 的稀疏检索和基于 CodeBERT 的稠密检索的混合方法： Score(f ∣ issue) = α ⋅ BM25(f , issue) + (1 − α) ⋅ cos(emb(f ), emb(issue))
上下文窗口管理：大型代码库远超 LLM 的上下文窗口。有效的策略包括：类图骨架（仅保留函数签名和 docstring）、依赖树剪枝（仅保留调用链上的文件）、相关性排序（将最相关的代码置于上下文窗口的前部和后部）。
测试驱动的修复验证：在修改代码后，自主运行测试套件验证正确性。如果测试失败，Agent 分析失败的断言和堆栈跟踪，进行针对性修复。 GitHub Issue Description Code Localization Hybrid retrieval finds relev ant files Context Building Class diagram skeleton + d ependency tree pruning Code Generation LLM generates fix Run Tests pytest / unittest

Pass Failed Generation Pull Request Analyze failure reason Assertion + stack trace 图15-21 自主编码 Agent 的标准化流水线 3) EvoDS 数据科学 Agent EvoDS（Self-Evolving Data Science Agent, 2026）将自进化范式应用于数据科学工作流，从数据加载、清洗、特征工程，到模型选择、训练和评估，全流程自主完成。 EvoDS 的核心机制： •工作流记忆（Workflow Memory）：将成功的数据科学工作流存储为可复用的模板。每个模板包括： W = (preprocessing_steps, feature_engineering, model_pipeline, eval_metrics) •上下文感知检索（Context-Aware Retrieval）：对于新数据集，检索其特征分布最相似的历史工作流： Retrieve(Dnew ) = arg max sim (profile(Dnew ), profile(W .Doriginal )) W ∈W 其中 profile(D) 包括列数、数据类型分布、缺失率、目标变量类型等元特征。 •自适应迁移（Adaptive Transfer）：检索到的模板不是照搬，而是由 LLM 根据新数据集的特征进行自适应调整。调整包括：适配列名、调整缺失处理策略、修改模型超参数。在 Kaggle 竞赛数据集和内部数据科学任务上，EvoDS 在 100+ 数据集的持续实践中，平均 AUC 从初始的 0.72 提升至 0.83，展示了通过经验积累实现的数据科学能力自进化。其自进化循环如图 15-22 所示。 New Dataset Dataset Analysis Meta-feature extraction Workflow Retrieval Similar historical workflow s Adaptive Transfer LLM adjusts workflow Execute Workflow Data cleaning -> feature en gineering -> modeling Evaluate results Success Failed Store in workflow memory Error analysis and correcti on Enrich memory database Workflow memory databa se 图15-22 EvoDS 的自进化数据科学循环 4) SePO 提示优化 SePO（Self-Evolving Prompt Optimization, 2026）是自主 Agent 在 Prompt 工程领域的应用：Agent 自主设计、测试和优化 Prompt，以最大化下游任务性能。 SePO 的问题定义：对于给定任务 T 和评估指标 Metric，找到最优 Prompt p ： ∗ p∗ = arg max Ex∼T [Metric(LLM(p, x), ytrue (x))] p∈P SePO 使用进化算法搜索 Prompt 空间：

初始化：从种子 Prompt 池开始，包含多种风格（指令式、示例式、角色扮演式）。
变异（Mutation）：LLM 分析当前 Prompt 的成功和失败案例，生成改进版本。变异操作包括： •添加约束（如 “You must be concise”） •添加示例（few-shot examples） •重新排序指令（将关键约束前置） •引入思考步骤（Chain-of-Thought）
交叉（Crossover）：将两个高分 Prompt 的优势组合： pchild = LLM ("Combine the strengths", pparent1 , pparent2 )
选择（Selection）：在验证集上评估，保留 Top-K。在 BBH（BIG-Bench Hard）、MMLU-Pro 和 GSM8K 等多个基准上，SePO 自动优化的 Prompt 相较于人类专家编写的 Prompt 实现了 5-12% 的准确率提升。

自主 Agent 基准测试评估自主 Agent 需要涵盖真实世界复杂性的基准。以下是 2024-2026 年的主流基准： •SWE-bench Verified（Jimenez et al. 2024）：从 GitHub 上真实的开源 Python 项目中收集 Bug Issue，要求 Agent 生成修复补丁并通过相关测试。包含 500 个验证实例，涵盖 Django、Flask、SymPy 等项目。截至 2026 年，旗舰 Agent 的通过率已升至 70% 以上。 •Terminal-Bench（2025）：评估 Agent 在 Linux 终端环境中完成系统管理任务的能力。任务包括：配置网络、安装软件包、调试进程、编写脚本等。强调 Agent 对命令行工具和系统 API 的熟练使用。 •OSWorld（Xie et al. 2024）：在真实操作系统环境中评估多模态 Agent 的 GUI 操作能力。任务涵盖：文件管理、应用操作、网页填写、多媒体编辑等。要求 Agent 通过鼠标键盘操作完成跨应用的复杂任务。自发布以来，最佳系统的完成率长期停留在 15-20%，是 GUI Agent 的核心瓶颈。 •TheAgentCompany（2025）：模拟企业环境中日常工作的全栈任务，如 Slack 沟通、JIRA 操作、文档编写、会议安排等。目标是评估 Agent 在白领工作场景中的综合表现。基准领域任务数平均步骤模态最佳性能 SWE-bench Verified 代码修复 500 8-15 文本 70%+（2026 旗舰） Terminal-Bench 系统管理 200 10-20 文本/终端 28.7% (2025) OSWorld GUI 操作 369 15-30 多模态 19.4% (2025) TheAgentCompany 企业任务 175 20-40 多模态 24.1% (2025) WebArena 网页操作 812 8-12 多模态 33.5% (OpenWebRL 2026) 表15-9 自主 Agent 基准概览

15.6.2 扩展与展望

自进化 AI 的技术谱系自进化 AI 是 2026 年最具想象力的技术方向——不仅是模型能力的提升，更是 AI 系统自主改进其自身算法的能力。按改进对象的层级，自进化 AI 可分为四个层级，如图 15-23 所示： Level 1: Parameter update Fixed architecture, auto fin e-tuning AutoML/NAS

Level 2: Architecture Searc h Automatically discover bet ter architectures MLEvolve 2026 Level 3: Algorithm Discove ry Automatically invent new l earning algorithms Meta-Agent 2026 Level 4: Recursive Self-Imp rovement Improve the ability to impr ove itself 图15-23 自进化 AI 的四级技术谱系层级描述代表系统状态第一级参数更新固定架构下的自我微调 Self-Evolving Agents 已实现第二级结构搜索自动发现更优的模型架构 NAS, AutoML 部分实现第三级算法发现自动发明新的学习算法 MLEvolve (2026) 早期验证第四级递归自改进改进自身改进能力 Meta-Agent Challenge 理论阶段表15-10 自我改进的层级第一级对应技能与经验层的自进化：架构不变，通过经验积累持续更新策略与技能库。第二级的神经架构搜索（NAS）和 AutoML 已有成熟的工具链。第三级与第四级是当前研究的前沿地带，分别以 MLEvolve 与 Meta-Agent Challenge 为代表。注意区分两组容易混淆的分级：四级谱系刻画的是改进对象（参数、结构、算法、改进能力本身），任务自主分级刻画的是自主程度（步骤、子任务、任务、目标）。二者正交。高自主等级的 Agent 未必具备高层级的自我改进能力，反之亦然。 2) MLEvolve 算法发现 MLEvolve（2026）是第三级算法发现的代表系统，一个完全自主的 AutoML 框架。与传统 AutoML 仅搜索现有算法组合不同，MLEvolve 能够创造新的算法结构。 MLEvolve 的搜索空间定义为可组合的算法原语（Primitives）集合： P = {Linear, ReLU, LayerNorm, Attention, Conv2D, …} 算法表示为这些原语的计算图 G = (V , E, type)，其中顶点 V 为原语操作，边 E 为数据流。 MLEvolve 的核心创新是用 LLM 替代传统进化算法中的随机变异算子。LLM 理解算法的语义结构，能生成有意义的变体而非盲目的参数变动： G ′ = LLMmutate (G, perf(G), "suggest an improvement") 完整的进化循环如下：

 class MLEvolveLoop:
     def __init__(self):
         self.algorithm_population = seed_algorithms() # Seed algorithms
         self.task_suite = load_tasks()
         self.meta_learner = LLM() # For generating new algorithms
    def evolve(self, generations=100):
        for gen in range(generations):
            # 1. Evaluate: test current population on task suite
            scores = evaluate(self.algorithm_population, self.task_suite)
            # 2. Select: keep top-K algorithms
            elites = select_top_k(self.algorithm_population, scores, k=10)
            # 3. Mutate: LLM generates algorithm variants
            mutations = [self.meta_learner.mutate(algo)
                        for algo in elites]
            # 4. Crossover: combine features of good algorithms
            crossovers = [self.meta_learner.crossover(a, b)
                         for a, b in pairs(elites)]
            # 5. Update population
            self.algorithm_population = elites + mutations + crossovers
        return best_algorithm(self.algorithm_population)

适应度评估在目标基准上训练并验证候选算法： Fitness(G) = Accuracy(Train(G, Dtrain ), Dval ) 验证结果：在 CIFAR-10 图像分类任务上运行 100 代后，MLEvolve 发现的训练策略在同等算力下比手工设计的基准准确率高 1.8%。更具启发性的发现是，MLEvolve 自主找到了多个与人类经典设计原理相似的组件（如 ResNet 式残差连接、 Transformer 式多头注意力），验证了 LLM 作为算法发现引擎的潜力。 3) Meta-Agent 与递归自改进当前的 Agent 能否自主开发新的 Agent？Meta-Agent Challenge（2026.6）将这一元问题形式化为可测量的实验，它同时是通往第四级递归自改进的关键门槛。实验设置：给一个构建 Agent 的 Meta-Agent 系统分配任务，为给定的新任务创建一个有效的子 Agent，以子 Agent （Child Agent）在目标任务上的表现作为评估指标，测试设计流程如图 15-24 所示。 Meta-Agent Analyze given task Design new Agent Architec ture Implement new Agent cod e Train/configure new Agent Evaluate new Agent Insufficient performance Meets requirements Improve design Submit complete Agent 图15-24 Meta-Agent 测试设计流程初步结果显示出明显的能力落差：任务领域人类设计的 Agent Meta-Agent 设计的 Agent 差距代码修复 (SWE-bench) 35.7% (SWE-agent) 23.1% (auto-generated) 12.6% 网页操作 (WebArena) 33.5% (OpenWebRL) 18.4% (auto-generated) 15.1% 数学推理 (AIME) 67.3% (DeepSeek-R1) 41.2% (auto-generated) 26.1% 问答 (MMLU-Pro) 82.5% (GPT-4o) 68.9% (auto-generated) 13.6% 表15-11 人工设计与自动设计 Agent 的差距表中人类基线取各系统原始论文的公开成绩（如 SWE-agent 为 2024 年的早期代表，显著低于 2026 年旗舰 Agent 在 SWE-bench Verified 上 70% 以上的水平），差距衡量的是自动设计相对同类人工设计的落差。以当前最强的模型驱动，Meta-Agent 能为文本分类、实体识别等简单任务生成可行的架构，但生成 Agent 的性能通常仅为人类设计的 60-80%。具体而言，自动生成的 Agent 普遍存在三类问题： •Prompt 设计缺乏领域洞察：过于泛化，缺少任务特定的约束和技巧。 •工具选择不精准：倾向于滥用所有可用工具，而非选择最关键的工具。 •错误处理策略粗糙：缺乏针对特定失败模式的优雅降级。这表明 Agent 的自主设计能力仍是当前 Agent 技术的核心瓶颈，也是迈向最高自主等级必须克服的障碍。自进化 AI 要走到第四级，还面临三个根本瓶颈： •评估瓶颈：需要自动评估更好的 AI，评估标准本身也要随之进化。 •探索-利用张力：需要在已验证方案和改进尝试之间合理分配资源。 •递归安全：当 AI 能改进自身时，需要确保改进方向与人类价值观对齐。 Darwin Gödel Machine（2025）针对递归安全问题给出了工程回应，将自进化与形式化验证结合：Darwin 一侧通过变异和自然选择进化 Agent 策略，Gödel 一侧使用形式化方法验证进化出的行为是否满足安全约束。只要安全约束被正确形式化，任何进化的产出都必须通过验证门。这种进化加验证的双引擎设计，为递归自改进提供了可落地的安全框架。 4) 安全考量自主 Agent 的安全问题是决定其能否大规模部署的关键因素。以下是需要重点关注的六个安全问题： •能力边界约束（Capability Bounding）：定义 Agent 的不可逾越边界，不允许执行的操作清单（Negative Permission List）和仅允许执行的操作范围（Whitelist）。技术上通过沙箱（Sandbox）、权限系统（RBAC）和 API 网关的请求过滤实现。 •自主程度控制（Autonomy Level Control）：根据操作的风险等级动态调整自主程度。例如，代码修改可以自主完成，但生产环境部署需要人类审批。实现上使用风险评分函数 R(a)： AutoApprove(a) ⟺ R(a) < θrisk else RequestHumanApproval(a) •审计追踪（Audit Trail）：记录 Agent 的所有决策、行动和推理过程，形成完整的可追溯日志。当 Agent 行为偏离预期时，审计日志是诊断和问责的基础。 •停止开关（Kill Switch）：在检测到危险行为模式时（如连续失败、资源滥用、访问未授权区域），自动终止 Agent 的执行。停止条件需要设计为包容，宁可误停，不可漏停。 •价值对齐（Value Alignment）：确保 Agent 的目标函数与人类价值观一致。在自进化场景中，需防止目标漂移（Goal Drift）。技术上常采用宪法 AI（Constitutional AI）方法，用一组不可变的行为准则约束 Agent。 •对抗鲁棒性（Adversarial Robustness）：Agent 可能遭遇恶意用户设计的对抗性输入（如 Prompt Injection、间接 Prompt 攻击）。需要多层次的防御：输入净化、指令隔离（将用户输入与系统指令严格分离）和输出过滤。上述安全机制的分层防护结构如图 15-25 所示。 User task Security Sandbox Resource isolation + permi ssion control Trigger stop Risk Assessment Audit Log Kill Switch R(a) = operation risk score Full decision log Anomaly behavior detecti on R<θ R≥θ Autonomous Execution Request human approval 图15-25 自主 Agent 的安全防护层架构 5) 未来展望自主 Agent 系统正站在从辅助工具到独立执行者的转折点上，三个关键趋势将塑造其未来： •从单模态到全模态：自主 Agent 将从纯文本交互扩展到视觉、音频、触觉的全模态感知和操作。OSWorld 和 GUI Agent 是这一趋势的先声。 •从任务执行到目标驱动：当前大多数自主 Agent 停留在 L3（任务执行），下一个突破是将自主性推进到 L4（目标驱动），让 Agent 能从高层意图出发自主规划。 •从人类监督到可验证自主：完全取消人类监督并不现实，但可以将人类角色从逐步审查提升为例外管理（Management by Exception），仅在 Agent 的不确定性超过阈值时才介入。这需要 Agent 具备精准的不确定性估计（Uncertainty Estimation）能力。从经验中学习、从失败中提炼、从成功中固化，这个闭环是 Agent 能力持续增长的根本引擎；而当 Agent 不仅能从经验中改进技能、还能改进自身的算法与设计时，能力增长的引擎将由外置转为内置。自主 Agent 的终极形态，是一个能像人类一样在实践中学习的系统。

15.7 Agent 运行时设计

Agent libOS（清华大学 2026）提出了一种受操作系统（Operating System）设计哲学启发的 LLM Agent 运行时架构。其核心动机是：当前 Agent 框架（LangChain、AutoGPT、CrewAI 等）缺乏操作系统级别的资源隔离、权限控制和可靠性保障，导致长运行 Agent 在面对资源争用、工具调用失败和状态损坏时缺乏系统性的容错恢复机制。本节深入剖析这一全新设计范式。

15.7.1 背景与局限

当前 Agent 框架的架构局限当前主流 Agent 框架的架构模式可归纳为脚本式编排（Script-like Orchestration）：开发者用代码显式定义 LLM 调用的顺序、工具的选择逻辑和错误处理路径。这种模式的三个根本局限： •无资源隔离（No Resource Isolation）：一个 Agent 中的 Python 进程崩溃或内存泄漏会直接导致整个 Agent 系统瘫痪。多 Agent 之间共享同一进程空间，没有类似操作系统中进程的隔离边界。 •无能力控制（No Capability Control）：一旦 LLM 获得了工具调用权限（如文件读写、网络访问、shell 执行），该权限便覆盖整个 Agent 生命周期。没有机制限制某个工具只能读取 /tmp 目录下的文件，或某个 API 调用每分钟不超过 10 次。 •无检查点与恢复（No Checkpoint/Recovery）：长运行 Agent（持续数小时至数天）如果在第 500 步工具调用时失败，必须从头开始，浪费了所有中间状态和已生成的结果。当前框架仅提供应用级的手动重试（ try/catch 包裹），缺乏系统级的透明检查点恢复。 Agent libOS 旨在将操作系统的核心抽象（进程、内存管理、能力安全、文件系统和检查点）引入 LLM Agent 运行时，从根本上解决上述问题。

15.7.2 核心组件

进程模型 Agent libOS 的基本抽象单元是 Agent 进程（Agent Process），每个 Agent 实例在一个隔离的进程中运行，拥有自己的内存空间、权限令牌和资源配额。进程模型提供以下保障： •隔离性（Isolation）：Agent 进程 A 的内存空间与 Agent 进程 B 完全隔离。A 的崩溃不影响 B 的执行。进程间通过消息传递（Message Passing）而非共享内存通信。实现层面，Agent libOS 将每个 Agent 进程映射到一个操作系统级别的进程或容器（Docker/Podman 容器），利用内核的进程隔离机制实现强隔离。 •生命周期管理（Lifecycle Management）：每个 Agent 进程有明确的状态转换： [Created] → [Running] → [Suspended] → [Resumed] → [Completed] 或 [Failed] Suspended 状态的 Agent 进程将其完整状态（LLM 上下文、KV Cache、工具调用栈、文件描述符）序列化到一个检查点文件。 Resumed 时从检查点反序列化恢复，类似操作系统中的进程挂起/恢复语义。 •资源配额（Resource Quota）：每个 Agent 进程被分配 CPU 时间片、GPU 显存上限、最大并发工具调用数和网络带宽上限，类似 Linux cgroups 的资源控制。 Agent 进程的生命周期状态机如图 15-26 所示，检查点保存与恢复构成挂起与恢复语义的核心。 Create Agent process Created Schedule start Running Checkpoint save (checkpoint) Suspended Resume execution Unrecoverable error Task completed successful (crash / quota exceeded) ly Checkpoint restore Timeout - not restored (restore) Resumed Failed Completed Cleanup resources Cleanup resources 图15-26 Agent 进程的生命周期状态机
内存管理 Agent libOS 的内存管理子系统借鉴了操作系统的虚拟内存和分段（Segmentation）概念，为 Agent 运行时引入三层内存抽象： Agent 虚拟内存（Agent Virtual Memory）：每个 Agent 进程拥有一个 256GB 的虚拟地址空间（类似于 64 位虚拟地址空间），其中 LLM 上下文（KV Cache + hidden states）、工具调用缓冲区、对话历史和知识检索结果被映射到不同的虚拟内存段中。实际物理显存仅在段被访问时分配（按需分配，Demand Paging）。段类型（Segment Types）：虚拟内存空间被划分为五类段：段类型大小上限内容淘汰策略持久化 CTX_SEG (Context) 128 GB LLM 上下文 + KV Cache 值感知淘汰检查点 TOOL_SEG (Tool) 32 GB 工具输入输出缓冲区 FIFO + 大小限制可选 HIST_SEG (History) 32 GB 对话历史 + 推理链 LRU 持久 KB_SEG (Knowledge) 32 GB RAG 检索结果 + 向量 LRU-TTL 非持久 STACK_SEG (Stack) 32 GB 工具调用栈 + 中间状态不可淘汰检查点表15-12 Agent libOS 的虚拟内存段类型与管理策略内存压力处理：当物理显存接近上限时，Agent libOS 的内存管理器（Memory Manager）按以下优先级释放内存：

已完成的工具调用输出缓冲区（TOOL_SEG 中标记为已读的段）
过期的知识检索结果（KB_SEG 中 TTL 过期的段）
早期对话轮次的 KV Cache（CTX_SEG 中通过值感知评分为最低的段）
将低优先级段的 KV Cache 以压缩格式（INT4 KVarN 量化）冷存储到 CPU 内存（Offloading）这一策略确保了高优先级上下文（当前推理链）始终留在高带宽的 GPU HBM 中，而低优先级的历史上下文被逐步驱逐至较低层级的存储中。

基于能力的权限控制 Agent libOS 采用了操作系统中能力（Capability）安全模型的最优实践，而非传统框架中的 ACL（Access Control List）或全有全无权限。能力令牌（Capability Token）：每个工具调用权限被建模为一个不可伪造的能力令牌（128-bit 随机字符串），包含： Cap = (resource_id, operations_mask, quota_limit, expiry, parent_cap)

• resource_id ：资源标识符（如文件路径通配符、API endpoint、数据库表名） • operations_mask ：允许的操作位掩码（READ=1, WRITE=2, EXEC=4, 等） • quota_limit ：操作次数或数据量的上限 • expiry ：令牌的过期时间戳 • parent_cap ：父令牌的哈希引用（如果此令牌是从更宽泛的令牌派生而来）能力令牌在设计上满足三个安全属性： •不可伪造性（Unforgeability）：令牌通过内核级 HMAC-SHA256 签名验证，Agent 进程无法自行生成新令牌。 •权限衰减（Attenuation）：一个宽泛的令牌（如读写所有文件）可以被衰减为受限令牌（如仅读 /data/agent_1/* ），衰减后的令牌不可再被恢复。 •最小权限原理（Least Privilege）：Agent 进程启动时获得一个空能力集，它需要通过能力管理器（Capability Manager）请求特定的能力令牌，且每个请求都必须附带理由（由 LLM 生成）。能力管理器根据预定义的策略决定是否授予。能力传递（Capability Passing）：当一个 Agent 进程需要调用工具时，它将能力令牌嵌入到工具调用请求中。工具端（tool side）的运行时验证该令牌的合法性和权限范围。如果工具调用试图超出令牌授权的范围（如尝试写入只读资源），调用在工具端被拦截，而非在 Agent 端事后审计。 4) I/O 抽象与工具 Agent libOS 将工具调用抽象为统一的 I/O 原语，类似于操作系统中的系统调用（syscall）： // Abstract Tool Calling interface (Similar to POSIX read/write/open) ssize_t tool_invoke( cap_t capability, // Capability token const char* tool_name, // Tool name const void* input_buffer, // Input parameters (serialized) size_t input_size, // Input size void* output_buffer, // Output buffer (pre-allocated) size_t output_size, // Output buffer size uint32_t flags // Call flags: SYNC/ASYNC/TIMEOUT ); 所有工具调用（HTTP API、shell 命令、文件 I/O、数据库查询、代码执行）都被统一到这个接口下。工具调用是缺省异步的（Async by Default），Agent 进程发起工具调用后不阻塞等待，而是注册一个回调事件。当工具返回结果时，运行时将结果注入 Agent 进程的内存 TOOL_SEG 段，并触发 LLM 继续推理。这一设计与操作系统的异步 I/O（AIO）和事件驱动架构（epoll/kqueue）一脉相承。工具调用的超时与截止时间：每个工具调用附带一个截止时间（deadline），由 Agent 进程的调度器在此之前发出。超时的调用被自动取消并返回 ETIMEDOUT 错误码——Agent 进程的 LLM 被提示“工具 X 调用超时，请重新规划”，而非整个 Agent 进程阻塞等待。 5) 检查点与恢复检查点（Checkpointing）是 Agent libOS 实现长运行 Agent 可靠性的核心机制。一个 Agent 进程的检查点包含以下状态的完整快照： •LLM 状态：当前 token 生成位置、所有层的 KV Cache（INT4 压缩格式）、Logits 缓冲区和采样状态（随机种子）； •内存状态：所有五类虚拟内存段的完整内容或差异（增量检查点）； •工具状态：正在进行中的异步工具调用列表（ID + 截止时间）、已完成未消费的工具输出； •能力状态：当前 Agent 进程持有的全部能力令牌及其衰减路径； •对话状态：完整的对话历史（JSONL 格式）和推理链记录。检查点采用三类互补的策略： •周期检查点（Periodic Checkpoint）：每 N 个推理步骤（N 可配置，默认 50）自动保存一次完整检查点； •增量检查点（Incremental Checkpoint）：在周期检查点之间，仅保存修改的内存页（类比 Copy-on-Write 的脏页跟踪），大幅降低检查点 I/O 开销； •事件驱动检查点（Event-Driven Checkpoint）：在关键事件发生时强制检查点，如工具调用前（保存调用前状态，方便失败后重试）、能力令牌申请被拒绝时、Agent 进程被抢占（preemption）挂起时。恢复按以下顺序执行：

从检查点文件加载 LLM 状态和 KV Cache，恢复推理引擎；
加载内存段，重建虚拟内存视图；
重新注册未完成的异步工具调用（如果工具调用仍在进行中）或标记为已超时；
验证能力令牌是否仍然有效（检查过期时间戳和父令牌吊销状态）；
LLM 从检查点保存的精确位置继续生成，注意力计算能够无缝访问完整的历史 KV Cache（包括检查点保存后未生成的新 token 的初始状态）。检查点策略存储开销恢复时间数据丢失窗口无检查点 0 ∞ (不可恢复) 全部仅最终状态 (Autosave) 1× 完整状态 10-30s 至最后一次保存周期检查点 (每 50 步) 每快照 1×, 保留 3 快照 10-30s 最多 50 步增量检查点 (每 10 步 + 周期快照) 完整快照 1× + 增量约 0.1×/次 15-45s 最多 10 步 Agent libOS 混合策略完整快照约 40MB + 增量约 4MB/次 5-20s 最多 10 步或关键事件前表15-13 检查点策略的存储、恢复与数据丢失窗口

15.7.3 系统架构与评估

与主流 Agent 框架的架构对比维度 LangChain AutoGPT CrewAI Agent libOS 基本抽象 Chain / Agent / Tool Agent + Command Crew + Task + Tool Agent Process + Cap + Memory Seg 进程隔离 Python 进程级（弱）无（单进程）无（单进程）操作系统级（容器/进程）权限控制无（工具可用即全权）无无能力令牌 + 衰减 + 最小权限内存管理应用变量 + 手动 GC 手动管理手动管理分段虚拟内存 + 自动换出 KV Cache 管理框架无关（由引擎处理）框架无关框架无关内置值感知淘汰 + 按需分页检查点无（需手动实现）无（需手动实现）无（需手动实现）内置增量检查点 + 透明恢复工具调用模型同步函数调用同步命令同步委托异步 I/O + 超时 + 回调多 Agent 通信无原生支持无结构化委托消息传递（Message Passing）维度 LangChain AutoGPT CrewAI Agent libOS 错误恢复 try/catch（应用级）有限重试有限重试检查点恢复 + 工具调用重试资源配额无无无 CPU/GPU/Mem/网络 cgroup 式配额表15-14 Agent libOS 与主流 Agent 框架的架构对比
系统架构总览 Agent libOS 的系统架构总览如图 15-27 所示，Agent 层、内核、工具层与推理引擎分层协作。 Agent libOS Kernel Checkpoint Manager Agent Layer Agent process A Virtual memory space A Process Scheduler Agent process B Virtual memory space B Capability Manager I/O Subsystem Memory Manager Tool Calling Abstraction Tool Layer Inference Engine HTTP API Shell Exec File I/O Code Interpreter Database vLLM / SGLang KV Cache LLM Inference Service Page-based management 图15-27 Agent libOS 的系统架构总览
性能与可靠性评估 Agent libOS 论文在长运行 Agent 任务（平均运行时间 2-4 小时，涉及 200-800 步推理和 50-200 次工具调用）上评估了系统性能：指标 LangChain AutoGPT CrewAI Agent libOS 任务完成率 (有注入故障) 62% 54% 58% 94% 故障后恢复时间 N/A (手动重启) N/A (手动重启) N/A (手动重启) 18s (自动) 内存使用 (峰值) 28 GB 34 GB 31 GB 22 GB 工具调用超时检测无 (挂起) 无 (挂起) 无 (挂起) 自动 (3s 检测) KV Cache 溢出恢复崩溃崩溃崩溃自动换出 + 淘汰平均开销 vs 裸框架 — — — +7% 延迟表15-15 Agent libOS 的可靠性与性能评估关键发现： •故障恢复是最大差异化优势：在注入随机工具调用失败（30% 概率）和内存压力故障（20% 概率）的测试中，Agent libOS 的完成率（94%）远超其他框架（54-62%）。检查点恢复机制使 Agent 能从故障点继续，而非从头开始。 •内存效率：虚拟内存管理和 KV Cache 主动淘汰使峰值内存使用降低了 21-35%。内存压力的自动缓解（换出 + 淘汰）避免了 OOM 崩溃，LangChain 和 AutoGPT 在长序列下频繁遭遇此类崩溃。 •开销可控：Agent libOS 的运行时开销（检查点保存、能力验证、I/O 抽象）约为裸框架的 +7% 延迟。在大多数长运行 Agent 场景下，这一开销远小于故障恢复带来的可靠性收益（避免从头开始的数小时时间损失）。

15.7.4 扩展讨论

Agent 运行时的操作系统化 Agent libOS 的设计哲学折射出一个更广泛的技术趋势：随着 LLM Agent 的复杂度增长，Agent 运行时正沿着库 → 框架 → 操作系统的路径演变：阶段抽象层级代表系统隔离性可靠性库（Library）函数调用 OpenAI API, Anthropic SDK 无无框架（Framework） Agent + Tool + Chain LangChain, AutoGPT 应用级（弱） try/catch 运行时（Runtime）进程 + 内存 + I/O Agent libOS, Letta/MemGPT 操作系统级（强）检查点 + 恢复分布式 OS 集群级进程 + 调度（未来）网络级分布式检查点表15-16 Agent 运行时抽象层级 Agent libOS 定位在第三层——为单一的 Agent 主机提供操作系统级的隔离和可靠性保障。未来的发展方向是构建集群级的 Agent 操作系统，在多个 GPU 节点上调度数百个 Agent 进程，支持 Agent 迁移、负载均衡和分布式检查点。
与推理系统的衔接 Agent 运行时设计与推理优化技术深度交织： •KV Cache 管理：Agent libOS 的内存管理器直接集成值感知淘汰策略，用于在多个 Agent 进程共享 GPU 显存时的 KV Cache 换出决策； •KV Cache 量化：KVarN 量化方案被应用于检查点存储，将 KV Cache 以 INT4 格式序列化到磁盘，减小检查点文件大小并加速恢复时的加载； •投机解码：Agent 的思考-行动循环（LLM 生成 → 工具调用 → LLM 继续）天然适配投机解码，工具调用的异步等待期间，可以预生成（草稿）后续的推理步骤，在工具结果返回后快速验证； •流水线并行：在多 Agent 场景中，不同 Agent 进程可被调度到流水线投机解码的不同 GPU 级上，利用流水线的天然时间空隙交叉执行，提升多 Agent 系统的总体 GPU 利用率。

15.7.5 Agent 开发框架

Agent 开发框架（如 LangChain、LlamaIndex）位于模型与业务逻辑之间的编排层，为构建 Agent 应用提供组件抽象与工作流原语。理解其架构定位，有助于判断框架与自建运行时各自适用的边界。

抽象层次主流框架提供四类抽象：模型接口（统一不同供应商的推理调用）、记忆抽象（短期对话历史与长期向量记忆的统一读写）、工具封装（把外部 API 与检索能力包装为可调用函数）、编排原语（链式、路由、循环的图式组合）。LlamaIndex 侧重数据侧，把文档加载、索引构建与检索封装为检索管线；LangChain 侧重流程侧，强调链与智能体的组合。
检索组件的深度 LlamaIndex 将 RAG 的全流程抽象为可插拔节点：文档解析器、切分器、向量索引、检索器与重排器。它内置多种检索策略（向量检索、关键词检索、混合检索）与查询转换（重写、分解），使应用侧无需直接接触检索引擎细节。这类抽象降低了构建检索增强应用的复杂度，代价是牺牲了底层行为的细粒度控制。
框架与自建运行时的分工框架适用于原型验证与标准场景：组件齐全、迭代快、社区生态丰富。自建运行时（如 Agent libOS 方案）适用于对性能、隔离与调度有强要求的场景：框架的抽象层会引入额外开销，且难以在多 Agent 进程级做资源管理。实践中常见的方式是以框架构建应用逻辑，以自建运行时承载执行与调度，两者按职责分层。

15.8 Agent 模型训练与工具使用

Agent 的能力由两条链路共同决定：模型能否在训练后可靠地调用外部工具，以及运行环境能否以统一协议交付这些工具。本节先讨论工具使用的两种规范，即函数调用与模型上下文协议，再依次展开监督微调、强化学习与在线蒸馏三条训练路径。侧重点在训练算法与协议设计，不涉及具体框架的使用细节。

15.8.1 工具调用与函数调用

函数调用（Function Calling）是让模型输出结构化工具调用意图的标准机制。工具提供方将每个工具描述为 JSON Schema，声明名称、参数类型、取值范围与必填项。模型在推理时并不直接执行代码，而是生成一个形如 tool_call(tool_name, arguments) 的结构化输出，交由运行时校验并执行，再把执行结果以工具消息（tool message）回填到上下文，模型据此继续生成。

对话循环的执行机制一个完整的工具调用回合遵循角色分离协议。系统消息（system）注入工具定义与全局约束，用户消息（user）给出任务，模型生成的工具调用随 assistant 消息携带，运行时执行后以 tool 角色返回结果。模型在训练中习得一条规则：上下文出现 tool 消息后继续输出后续推理，工具结果与预期不符时改写参数或更换工具。这一机制让模型与执行解耦，职责边界清晰，便于审计与限流。
工具定义的结构化规范工具定义须满足三个约束：参数可校验、描述可区分、失败可恢复。可校验要求运行时能用 JSON Schema 校验参数合法性，非法调用直接拒绝而非透传给工具。可区分要求描述文本足够明确，使模型在多个工具之间做出正确选择。失败可恢复要求定义中声明错误返回结构，模型依据错误信息修正重试。示例定义如下： { "name": "web_search", "description": "Query a search engine and return ranked results", "parameters": { "type": "object", "properties": { "query": { "type": "string", "description": "Search query" }, "top_k": { "type": "integer", "minimum": 1, "maximum": 10 } }, "required": ["query"] } }
训练数据的构造方法函数调用能力通过构造工具调用数据获得，主流方法有三类。真实日志复用，从生产环境采集工具调用记录，标注质量高但覆盖有限。自我指令合成，以工具定义为种子，提示一个较强的模型生成包含工具调用的对话样例，覆盖真实数据缺失的长尾场景。执行反馈过滤，将合成样例实际执行一遍，仅保留参数合法、返回符合预期的轨迹，剔除格式错误与幻觉调用。合成数据须控制多样性，交替生成单轮调用、多轮串行调用、并行调用与错误恢复场景，避免模型对固定格式过拟合。

15.8.2 模型上下文协议 MCP

模型上下文协议（Model Context Protocol，MCP）是 Anthropic 于 2024 年提出的开放标准，用于统一 LLM 应用与外部数据、工具之间的连接方式。函数调用定位于模型内部的生成能力，MCP 则定位于应用层的互操作协议，解决多工具、多模态接入时的接口碎片化问题。

客户端-服务器架构 MCP 采用客户端-服务器（Client-Server）架构。宿主应用（Host）内嵌 MCP 客户端，维护与远端 MCP 服务器之间的会话，服务器按命名空间暴露三类原语，全部通过 JSON-RPC 2.0 消息交互。一个宿主可同时连接多个服务器，模型经统一通道发现并调用不同服务器上的工具，无需为每个工具单独定制接入代码。如图 15-28 所示，客户端将模型意图翻译为协议消息，服务器在本地鉴权后交付执行。 MCP Server Host Application JSON-RPC 2.0 Tools External Systems

(APIs, files, databases) Agent / LLM MCP Client JSON-RPC 2.0 Resources JSON-RPC 2.0 Prompts 图15-28 MCP 客户端-服务器架构与三类原语 2) 三类原语 MCP 定义工具、资源、提示词三类原语。工具（Tool）是可供模型调用的函数，服务器通过工具列表广播能力，客户端据此完成工具发现（Tool Discovery），模型在推理时按函数调用机制发起调用。资源（Resource）是可供读取的数据源，以统一资源标识符（URI）寻址，模型需要上下文时经资源读取（Resource Read）拉取，常用于检索、数据库查询与文件加载。提示词（Prompt）是可复用的模板，把高频任务的操作步骤固化为结构化提示，客户端据此编排交互流程。三者职责分离：工具主动执行，资源被动供读，提示词规范流程。 3) 统一协议的必要性统一协议的价值在四个维度体现。多工具维度，一套协议替代各厂商各自的调用规范，模型侧只需学习一次接入方式。多模态维度，资源原语可携带任意媒体类型，将文本、图像、音频统一到同一数据通道。权限维度，协议定义明确的授权边界，服务器在本地完成鉴权，宿主无需暴露底层凭据，降低泄露风险。安全维度，工具发现与调用全流程可审计，非法操作在服务器侧拦截。MCP 与原生函数调用是互补关系：函数调用解决模型如何输出意图，MCP 解决意图如何被安全交付，前者在训练侧、后者在运行时。

15.8.3 Agent 数据构造与监督微调

监督微调（Supervised Fine-Tuning，SFT）是 Agent 训练的第一阶段，目标是把通用对话模型改造成能遵循工具协议的决策模型。其效果几乎完全取决于训练数据质量，数据构造因此是全链路的重心。

轨迹收集轨迹（trajectory）是任务、思考、工具调用、结果与最终回答组成的完整序列。收集途径有三条。人工标注，专家在沙盒环境中演示任务解决过程，质量最高但成本巨大。合成生成，由强模型按指令生成整条轨迹，成本低但存在模式单一与幻觉隐患。执行反馈，让一个现成 Agent 在真实环境中运行并记录轨迹，以执行结果为标签。工程上通常以执行反馈为骨干、人工数据校准边界、合成数据扩充覆盖。
清洗与过滤原始轨迹须经清洗与过滤才能进入训练集。清洗环节解决格式问题：规整工具调用的角色轮次、去重、裁剪超长上下文、统一错误信息的表述。过滤环节解决质量问题：以任务完成度、工具调用成功率、返回结果一致性为判据，剔除未达成目标的轨迹，保留失败过程有教学价值的样例，如正确的重试策略。如图 15-29 所示，三类数据源汇入原始轨迹集，依次经过清洗与过滤，得到可直接训练的数据集。 Human Annotation Synthetic Generation Execution Feedback Raw Trajectories Cleaning (format, dedup, truncatio n) Filtering (completion, tool success) SFT Dataset SFT Training 图15-29 Agent 训练数据的构造全链路
多步轨迹的监督信号设计多步轨迹的监督信号与普通指令数据不同。普通 SFT 只对最终回答做交叉熵损失，Agent 轨迹则要对推理 token 与工具调用 token 分别建模：推理 token 学习决策逻辑，工具调用 token 学习参数序列化格式，工具结果 token 学习信息整合。损失权重需按轨迹结局设计：成功轨迹的每一步赋予全权重，失败轨迹仅保留格式学习价值；中间步骤可按决策关键点加重，让模型优先拟合工具选择与参数构造，而非冗长的过渡文本。

15.8.4 Agent 强化学习与奖励建模

监督微调教会模型模仿，强化学习（Reinforcement Learning，RL）教会模型择优。Agent 场景的独特之处在于奖励信号来自环境而非人类偏好：任务是否完成、工具调用是否成功、返回是否符合预期，都是可自动计算的客观信号。

结果奖励与过程奖励奖励可分为两类。结果奖励（Outcome Reward）只在轨迹结束时给出，最简单的形式是任务成功指示： R={

1 if task completed 0 otherwise 结果奖励稀疏，长任务下模型难以定位失败步骤。过程奖励（Process Reward）在每一步给出反馈，工具返回错误码时立即计负分。过程信号可由规则计算，如工具执行结果、超时与格式错误，也可由过程奖励模型（Process Reward Model，PRM）预测。过程信号稠密但可能被钻空子，实践中以结果奖励为主、过程奖励为辅，两者加权合成轨迹回报。 2) 奖励建模与评测奖励模型以偏好数据训练：对同一任务采样多条轨迹，按人工或自动判据排序，模型学习轨迹得分。自动评测可替代部分人工：以单元测试判定代码正确性，以断言判定工具结果，以执行成败判定任务完成。奖励模型自身也需评测，常用指标是排序一致率，即模型打分与人工排序在测试集上的吻合程度。 3) PPO 与 GRPO 的应用策略优化在 PPO 与 GRPO 中展开。PPO（Proximal Policy Optimization）以裁剪目标约束单步更新幅度，其损失为： L(θ) = E [min (rt (θ)A^t , clip (rt (θ), 1 − ϵ, 1 + ϵ)A^t )] 其中 r (θ) 为新旧策略的似然比，A^ 为优势估计。PPO 需要价值网络估计优势，训练成本高。GRPO（Group Relative Policy Optimization）省去价值网络，对同一提示采样一组轨迹，以组内回报的相对位置估计优势： t t Ri − mean(R) A^i = std(R) GRPO 更省显存，在 Agent 与推理模型训练中成为默认选择。两类算法都配合 KL 正则，约束策略与参考策略的距离，防止奖励被钻空。 4) 探索与多样性的平衡强化学习容易过早收敛到单一策略，尤其当工具调用格式多样时。对策有三：采样时提高温度并加入多样性惩罚，抑制重复轨迹；轨迹池按工具组合去重，保证覆盖不同调用序列；对探索性轨迹即使失败也保留部分样本，维持策略对未知分支的泛化能力。训练后期逐渐降低温度，使策略从探索转向利用。

15.8.5 在线蒸馏与策略优化

Agent 能力的上限常受限于数据来源模型。在线蒸馏（Online Distillation）用更强的教师模型（teacher）实时生成训练信号，指导目标模型（student）提升工具使用能力，是当前 Agent 训练的主流范式。

在线蒸馏的工作方式蒸馏的核心区别在于数据来源是否随策略更新。离线蒸馏一次性生成数据集后固定不动，在线蒸馏则不断用当前策略采样新轨迹，交给教师模型改写、纠错或评分后再训练。教师不直接输出工具执行结果，而是输出更优的决策路径：更合理的工具选择、更少的冗余调用、更规范的参数。学生从教师标注过的轨迹中学习，教师能力持续注入，学生策略随采样分布演化，形成 on-policy 数据迭代闭环。
on-policy 数据迭代 on-policy 迭代的价值在于分布匹配：训练数据始终来自当前策略的真实行为分布，避免离线数据的分布偏移。每轮迭代执行三步：当前策略在任务集上采样轨迹；以执行结果与教师评判筛选样本，标注最终答案或修订路径；以新数据更新策略后进入下一轮。迭代中须记录数据来源与结果标签，防止低质量轨迹被重复计入。停止条件常设定为验证集完成率连续若干轮不再上升。
自我改进当教师模型可用性受限时，可走自我改进（Self-Improvement）路径，让模型自己成为教师。常见形式包括自我对弈（Self-Play），模型交替扮演任务提出者与执行者，在对抗中暴露工具使用的薄弱环节；自我批评，模型审视自身历史轨迹，指出工具选择与参数的错误并生成修订版本。自我改进的前提是模型已具备足够评判能力，否则错误轨迹被自我强化，策略质量不升反降。
策略稳定性在线训练中策略稳定性是首要工程问题。惩罚性更新可能让策略在某轮崩塌，破坏后续全部数据采集。维持稳定的手段包括：KL 正则约束更新步长，防止策略偏离参考分布过远；回滚机制，监测验证集指标，下降即回退到上一检查点；数据质量门禁，执行结果评分低于阈值的轨迹不进入训练集。多轮迭代后可用对数似然比监控策略漂移，漂移过大时降低学习率或冻结骨干参数，仅更新与工具调用相关的层。