多 Agent 协作

在 OpenAI 曾提出的 AI 能力五等级描述（Level 1 对话者、Level 2 思考者（Reasoners）、Level 3 智能体、Level 4 创新者、Level 5 组织 Organizations）中，多 Agent 协作常被类比为通向第五级的路径之一——需要说明的是，此处 Organizations 指的是“AI 能完成整个组织的工作”这一能力级别，而非对系统架构的要求，足够强大的单个 Agent 理论上也能达到。但就今天的工程现实而言，单个 Agent 终究受限于自身模型的能力边界和上下文窗口。

而让多个 Agent 协同工作，意义远不止让不同专长的 Agent “取长补短”。更根本的一点是：群体的智能可以高于个体。人类文明便是明证——单个人的智力有限，但经由分工、协作、辩论和知识的代际累积，人类社会作为整体所展现的智能，远超任何一位天才个体。Agent 群体同样可能涌现出这样的集体智能：哪怕每一个 Agent 都只相当于人类专家的水平，只要组织得当，其整体能力也可能超过所有人类专家的总和。Google DeepMind 在《从 AGI 到 ASI》中正把“大规模多 Agent 集体”列为通往超级智能（ASI）的关键路径之一——正如人类的通用智能能聚合成超越个体的社会与组织实体，众多 AGI 级 Agent 协同形成的“群体智能”，也可能表现出远超其成员简单相加的认知能力¹。因此，多 Agent 协作不只是突破单个模型上下文窗口与能力边界的工程手段，更可能是从“专家级 AI”迈向“超越人类整体”的一条根本路径。

多 Agent 协作的分类框架

要构建多 Agent 系统，首先需要理解两个核心设计维度，它们共同决定了系统的基本架构和实现方式。

维度一：上下文是否共享

这是最基础的架构决策，决定了多个 Agent 之间如何传递信息。

共享上下文意味着后一个 Agent 接收前一个 Agent 的完整对话历史和轨迹（第一章定义的 trajectory）。每个阶段切换系统提示词和工具集后，就变成了一个新的 Agent（因为它的身份、职责和能力都发生了变化），但它保留了前任的全部记忆。比如一个团队里，需求分析师写完需求文档后，开发者不仅拿到了文档，还能看到分析师与用户的所有沟通记录——他是一个新角色，但完整保留了之前的上下文。优势在于信息不丢失，每个 Agent 都能回顾之前任何阶段的细节；挑战在于上下文可能快速膨胀。

不共享上下文意味着每个 Agent 维护完全独立的上下文和对话历史，彼此无法直接访问对方的“思考过程”。这就像不同部门之间的协作：每个人在自己的工位上独立工作，通过共享文档和会议纪要交换信息，而不是时刻盯着别人的屏幕。这种模式的模块化和隔离性更好，每个 Agent 只需关注与自身职责相关的信息；系统也更易扩展和维护——增加新 Agent 不需要改动现有 Agent 的内部逻辑，只需定义好接口和数据格式。

由于 Agent 之间不共享上下文，必须通过显式的通信机制传递信息。这个问题在经典分布式系统中早有答案：操作系统教科书告诉我们，进程间通信（IPC）归根结底只有两大范式——共享内存（一方写入、另一方读取同一块存储）和消息传递（把数据显式地发送给对方）。Agent 间的通信机制同样落在这两个范式之内，常见的有三种：

• 工具调用的参数：上游 Agent 把结构化数据作为参数传给下游 Agent 的工具，适合需要类型确定、结构清晰的场景；
• 共享文件系统：Agent 之间通过读写共享目录下的文档、代码等中间产物来交换信息，适合产物较大或需要持久化的场景；
• 消息总线（Message Bus）：一个专门负责在 Agent 之间传递消息的中转站，Agent 不直接调用彼此，而是把消息发送到消息总线，由它转发给目标 Agent。

对应到 IPC 的两大范式：共享文件系统就是 Agent 世界的“共享内存”；工具调用参数和消息总线则是“消息传递”的两种形态——前者随调用同步传递，后者经中转站异步投递。两种范式各有取舍。Go 语言有一句广为流传的话：“不要通过共享内存来通信，而要通过通信来共享内存”——共享内存快，却把并发冲突的隐患留给使用者；消息传递要多写编排代码，却让数据的归属清晰可循。

维度二：协作拓扑

第二个维度是协作拓扑——Agent 之间的控制权和信息按什么结构流动。协作拓扑有三种典型形态：

• 对等协作模式（Peer Collaboration Pattern）：少量 Agent 按照固定的拓扑形成迭代改进循环，例如论文写作 Agent 由起草者和评论者两个 Agent 组成，一个人起草、另一个人批注修改，反复几轮后质量更高。
• 管理者模式（Orchestration Pattern）：一个中心化的 Manager Agent 负责任务规划和调度，多个子 Agent 各负责特定子任务——就像项目经理带着几位专业工程师做项目。
• 去中心化模式（Decentralized Pattern）：没有运行时的中心控制者，Agent 之间像人类一样互相沟通，协作完成任务。

术语说明：Graph 工程。 2026 年 7 月开始流行的 “Graph Engineering”，在当前 Agent 语境中通常指显式设计执行图：节点是 Agent、普通程序或人工决策，边定义任务依赖、条件路由与失败后的去向，结构化状态在节点之间流动[^ch10-graph-engineering]。本章讨论的“协作拓扑”正是其中的多 Agent 子集——对等协作、管理者编排和去中心化移交，都是不同的图拓扑。

各模式的详细设计和适用场景将在后面的专题小节中展开讨论。

多 Agent 何时真正优于单 Agent

在进入具体的协作架构之前，先回答一个更根本的问题：什么时候真正需要多个 Agent，什么时候一个 Agent 就够了？ 这个问题的答案会成为后文所有工程方案的总体参照。近年的一系列研究给出了一个清晰的判断框架——核心判据只有一条：协作过程是否引入了单个 Agent 在生成时无法获得的新信息？

表10-2 汇总了不同协作模式是否引入新信息，用来判断多 Agent 协作相对单 Agent 是否具有实质价值。

表10-2 多 Agent 协作模式的信息增量对比

2025 年的 RLEF（Reinforcement Learning from Execution Feedback）² 证实了这一点：通过强化学习训练模型利用代码执行反馈来迭代改进代码，效果远超让模型独立多次采样。关键在于每次迭代都引入了真实的执行结果（编译错误、测试失败、运行时异常），这些信息在模型写代码时并不存在。2025 年的 WebGen-Agent ³ 在网页生成任务上，通过多层级的视觉反馈（截图 + 视觉语言模型描述）构成的反馈脚手架，据报道使 Claude 3.5 Sonnet 在该基准上的表现从 26.4% 提升到 51.9%——接近翻倍。

这个“新信息”框架解释了一个看似矛盾的现象：一些学术研究认为多 Agent 并不能提升 Agent 能力上限，但工程实践中多 Agent 确实效果更好。矛盾的根源在于两者讨论的是不同类型的 “多 Agent”：学术研究中比较的多是 “多个 Agent 看着同一段上下文互相讨论” 的模式，而工程实践中有效的多 Agent 系统往往包含外部反馈环路（代码执行、视觉渲染、工具调用）。前者没有引入新信息，后者引入了。

步骤预算与 Agent 性能。 一个相关的研究方向是：给 Agent 分配不同的步骤预算（即允许的工具调用次数或迭代轮数），会如何影响其表现？直觉上，更多步骤应该带来更好的结果——30 步预算下 Agent 只能快速实现核心功能，300 步预算下它还可以先做规划、再实现、再测试、再改进。但 2025 年 Google 的论文《Budget-Aware Tool-Use Enables Effective Agent Scaling》发现了一个反直觉的结论：单纯增加 Agent 可用的步骤数并不能保证性能提升。标准的 Agent 缺乏“预算意识”——即使有 300 步的预算，它们仍然倾向于执行浅层搜索，很快就“饱和”了。要让更多的步骤真正转化为更好的结果，Agent 需要一种显式的预算感知机制，根据剩余资源动态调整策略：前期广泛探索，后期聚焦最有希望的方向。2026 年的 BAVT（Budget-Aware Value Tree Search）进一步提出了步骤级别的价值评估，在每一步根据剩余预算比例调整探索与利用的权重——随着预算减少，Agent 从“广撒网”逐渐切换到“深挖掘”。

这些发现对多 Agent 系统设计有直接的指导意义。比如在管理者模式中，Manager Agent 不应只是简单地将任务分发给子 Agent 然后等待结果，而应该根据任务的复杂度动态分配步骤预算——简单子任务给较少的步骤，复杂子任务给充足的步骤。同时还要引导子 Agent 合理利用这些预算（先规划、再实现、再测试、再改进），而不是一头扎进去直接开干。

此外，成本是多 Agent 系统必须关注的要点。多 Agent 的并行探索与反复迭代都要消耗大量 token。这意味着多 Agent 的效果收益必须足够大，大到能覆盖数倍乃至一个数量级的额外开销，否则一个调校得当的单 Agent 往往是更划算的选择。

共享上下文的多 Agent 协作

共享上下文的多 Agent 协作中，每个阶段都是一个独立的 Agent（拥有自己的系统提示词和工具集），但它继承了前序 Agent 的完整轨迹——就像接班的同事能翻阅前任留下的所有工作日志。这种 “继承式协作” 的核心优势在于信息零损耗，每个 Agent 都能回顾之前任何阶段的细节。挑战则在于如何让当前 Agent 专注于自己的核心职责，而不被继承来的大量历史信息所干扰。

多阶段角色转换

在复杂任务中，Agent 的角色和职责可能在不同阶段发生显著变化。如果始终使用同一套静态系统提示词，要么过于笼统缺乏针对性，要么把所有阶段的指导塞在一起导致过于冗长。多阶段角色转换的做法是：根据当前阶段动态切换系统提示词和工具集，让 Agent 在每个阶段都以最合适的 “身份” 工作。这种转换不需要创建新实例或启动新进程，只是在同一执行会话中更新上下文。关键在于，虽然角色切换了，但对话历史和任务状态始终连续共享——Agent 在新角色下仍能访问之前阶段积累的所有信息。

实验 10-1 ★★：根据执行阶段决定系统提示词

本实验通过一个 Coding Agent 的完整工作流程，展示阶段化系统提示词如何提升 Agent 的表现。

任务场景：用户提出一个软件开发需求，Agent 依次经历三个阶段：需求澄清、代码实现、质量审查。

第一阶段：需求澄清（角色：需求分析师）

系统提示词强调：

• “你的职责是充分理解用户的需求。通过提出问题来澄清模糊的地方，确保你完全理解用户期望的功能、使用场景、性能要求。”
• “不要急于实现。在这个阶段，你的任务是提问和确认，而不是编写代码。”
• “当你确认所有关键需求都已明确后，调用 complete_requirements_analysis() 工具来结束这个阶段。”

工具集有限：ask_clarifying_question(question) 用于向用户提出澄清问题，save_requirement(key, value) 用于记录确认的需求点，complete_requirements_analysis() 用于标记阶段完成。

Agent 与用户展开多轮对话：“这个脚本需要处理哪些类型的文件？”“要不要递归处理子文件夹？”“文件移动后是否保留原文件名？”通过这些问题，Agent 逐步建立起完整的需求理解并结构化保存。当 Agent 判断需求已经足够清晰时，调用 complete_requirements_analysis() 触发角色转换——系统检测到阶段完成信号，自动切换到下一阶段的配置。

第二阶段：代码实现（角色：软件工程师）

新的系统提示词强调：

• “你的职责是根据已确认的需求，编写高质量的 Python 代码。”
• “遵循最佳实践：代码应该模块化、有适当的错误处理、包含必要的注释。”
• “完成代码编写并通过基本测试后，调用 submit_for_review() 进入审查阶段。”

工具集发生了显著变化：之前的需求澄清工具被移除，取而代之的是 write_file(path, content)、read_file(path)、execute_code(code) 等开发工具。Agent 基于第一阶段保存的需求开始编写代码——先写主要逻辑，再添加错误处理，最后编写测试验证。整个过程中 Agent 仍可访问第一阶段的对话历史来回顾需求细节，但行为模式已截然不同：不再提问，专注于实现。完成后调用 submit_for_review()。

第三阶段：代码审查（角色：代码审查员）

新的系统提示词强调：

• “你的职责是审查刚才编写的代码，从多个维度评估其质量：功能正确性、代码规范、错误处理、性能优化、安全性。”
• “采用批判性思维，尝试找出代码中可能存在的问题和改进空间。”
• “发现严重问题调用 request_revision(issues) 返回实现阶段修改；质量可接受调用 approve_code() 完成任务。”

工具集再次变化：换成了 run_linter(file)、run_tests(file)、analyze_complexity(file) 等代码质量分析工具。Agent 以审查者的视角重新审视代码，运行静态分析，排查潜在的 bug、性能问题或安全隐患。

这种三阶段设计让 Agent 在每个阶段都能专注于当前核心任务。更重要的是，明确的阶段转换机制保证了任务执行的完整性——Agent 不会跳过需求分析直接写代码，也不会在未经审查的情况下就交付成果。

实验要求：

1. 实现三阶段系统提示词，每阶段有明确角色定义和行为指导
2. 为每阶段配置匹配的工具集
3. 实现阶段转换触发机制（通过特定工具调用）
4. 确保上下文在阶段间的连续性
5. 处理回退情况——代码审查发现问题时能返回实现阶段
6. 记录每阶段执行日志，展示不同提示词如何产生不同行为模式

跨领域角色转换

前面的多阶段角色转换展示的是单一任务类型（软件开发）中的阶段化执行。跨领域角色转换则进一步探索 Agent 在多种任务类型之间的自主切换——不再是预先规划好的线性流程，而是根据用户需求的变化，由 Agent 自主判断应该切换到哪个专业角色。

实验 10-2 ★★：多角色转换

前置要求：建议先了解第二章 Agent Skills 机制。

系统架构：五种角色——

• triage（前台分诊，默认入口）：理解用户的整体需求，把它拆成有先后顺序的子任务，逐步移交给合适的专业角色，并在全部子任务完成后做收尾确认。自身没有专业工具，只持有 transfer
• research（信息检索专家）：用 web_search 查找数据、事实和资料
• coding（编程专家）：用 execute_python 写并运行代码，解决程序逻辑/脚本类问题
• data_analysis（数据分析专家）：用 calculate / descriptive_stats 做定量计算与统计（如同比增长率、年均复合增长率 CAGR、均值）
• writing（写作专家）：把检索到的数据和计算结论润色成通顺、面向指定读者的成稿（可用 count_characters 粗查篇幅）

核心机制：transfer_to_agent 工具

所有角色都配备了 transfer_to_agent(target_role, reason) 工具。调用时系统会依次：1）保存当前对话历史；2）加载目标角色的提示词和工具集；3）将对话历史传递给新角色，使其理解上下文；4）以新角色身份继续执行。

实验场景：系统默认以 triage（前台分诊）身份运行。用户抛来一个跨领域的复合任务：“我在准备一份给投资人看的材料，帮我查一下中国 2021、2022、2023 三年的新能源汽车销量，算出这三年的年均复合增长率，再写成一段面向投资人、不超过 120 字的中文总结。”triage 把它拆成“查数据 → 算指标 → 写成稿”，第一步先移交检索：

python

复制▶ 运行

transfer_to_agent(target_role="research", reason="需要先查三年的新能源汽车销量数据")

research 用 web_search 查到销量后，把关键数据写进对话，再移交给数据分析：

python

复制▶ 运行

transfer_to_agent(target_role="data_analysis", reason="数据已就绪，需要计算三年 CAGR")

data_analysis 用 calculate 算出增长率，移交给 writing 成文；writing 写好后再移交回 triage 做收尾确认。整条链路是 triage → research → data_analysis → writing → triage，每个角色都看得到完整对话历史，因此后一个角色天然知道前面已经做了什么。

角色转换的决策依赖系统提示词的指导。triage 的提示词里明确列出了路由规则：查数据/资料转 research，写并运行代码转 coding，定量计算与统计转 data_analysis，润色成稿转 writing。判断标准很简单：任务需要特定领域的深度知识或专业工具，就移交给对应的专业角色。专业角色的提示词中同样指导了完成本职部分后该移交给谁或转回 triage。

实验要求：

1. 实现至少三种专业角色的系统提示词和专门工具集
2. 实现 transfer_to_agent 工具，支持动态切换
3. 确保角色切换后上下文连续性
4. 处理循环切换问题——避免 Agent 在角色之间反复切换
5. 设计跨越多个领域的复杂任务流程，展示角色转换价值

不共享上下文的多 Agent 协作

不共享上下文代表真正的多 Agent 协作。在这种架构下，每个 Agent 都是独立的实体，拥有自己的上下文、轨迹和状态。Agent 之间无法直接访问彼此的 “内心活动”，协作完全依赖明确的、结构化的数据传递机制，也就是本章开头介绍的三种通信机制（工具调用参数、共享文件系统、消息总线）。

本章开头把通信机制对应到进程间通信的两大范式。多 Agent 系统与操作系统有深刻的对应关系（表10-3）：

表10-3 多 Agent 系统与操作系统的对应关系

程序是静态的代码，进程是程序的一次运行。同样，静态前缀决定 Agent 是谁，轨迹记录它走到了哪一步。LLM 扮演的是 CPU 的角色：自身不保存状态，靠加载不同的上下文分时服务许多 Agent——“上下文切换”这个词本来就是从操作系统借来的。也正因如此，换一颗更快的 CPU，程序照常运行；换一个更强的模型，Agent 还是原来那个 Agent——它的身份和记忆在前缀与轨迹里，不在模型权重里。

这套抽象并不新鲜：私有状态、异步消息、可创建新成员，正是 1970 年代 Actor 模型的基本设定⁴，多 Agent 系统不妨看作它的 LLM 版本。因此操作系统与分布式系统的成熟经验大多可以直接借用。唯一失效之处在于：进程间传递字节，逐位保真；Agent 间传递语义，每次转述都可能失真——这是本章“失败模式”一节要专门讨论的新问题。

进程式的隔离带来了几个切实的工程好处：每个 Agent 可以独立开发和测试，新增能力不需要改动现有代码，某个 Agent 出了故障也不会把错误状态传染给其他 Agent，而且多个 Agent 可以真正并发执行——上下文完全独立，不存在资源竞争。

但不共享上下文也有代价。最明显的是信息同步问题：各 Agent 如何对任务状态保持一致的理解？信息在传递过程中会不会丢失或重复？调试也变得更加困难——出了问题需要翻看多个 Agent 的日志，才能拼出完整的执行过程。这些问题使得接口规范、数据格式和通信协议的设计变得至关重要。

不共享上下文的显式协作依赖两套与拓扑无关的基础设施。其一是共享文件系统，作为 Agent 间交换产物、与用户交换文件的持久媒介，构成协作的数据平面；其二是通信与控制机制，支持 Agent 间的消息传递、状态查询、执行终止与资源调度，构成协作的控制平面。以下三种拓扑均建立在这两者之上。

Agent 眼中的文件系统

本章开头将“共享文件系统”列为不共享上下文的三种通信机制之一。在实际系统中，Agent 访问的并非单一存储，而是一个虚拟文件系统（virtual filesystem）：来源、生命周期与权限各异的存储被挂载（mount）到同一目录树下，Agent 通过统一的 read_file/write_file/list_dir 接口访问，底层则可能是本地临时盘、持久对象存储、第三方云盘的 API 或只读的系统资源包。明确这棵目录树的构成——每一区域的可见性与生命周期——是多 Agent 协作设计的前提：相当一部分并发冲突与信息泄露，源于将本应隔离的区域混置。这棵目录树相当于 Agent 的地址空间，四类区域就是权限各异的内存段：有的私有可写，有的多方共享，有的只读。操作系统的保护哲学在这里同样成立——默认隔离，共享须显式声明。一个成熟的多 Agent 系统，其文件系统通常由以下四类区域构成：

一、Agent 专属工作区（Scratchpad）。每个 Agent 实例独享的私有目录，存放中间产物、临时文件、草稿与调试日志，生命周期与实例绑定，对其他 Agent 和用户不可见。隔离 scratchpad 有两重作用：避免多个 Agent 的临时文件相互覆盖，以及保持主 Agent 上下文的精简——子 Agent 的试错过程留存于自身工作区，仅将最终产物提交至共享空间。这对应第四章“子 Agent 返回结构化摘要而非全量轨迹”在存储层面的体现。

二、多 Agent 共享空间（Shared Workspace）。多个 Agent 共同读写、且用户可见的协作区域，是不共享上下文架构下 Agent 间交换产物的主要媒介：Glossary Agent 写入术语表，Translation Agent 从中读取；用户亦可在此上传原始文件、下载最终交付物。其生命周期与整个任务绑定，需要持久化。作为多方并发读写的区域，它是并发冲突的高发处——乐观锁、工作副本隔离（worktree）等机制均作用于此，详见本章后文“失败模式一”。第四章以卷挂载 /workspace/shared 连接主 Agent、虚拟电脑与虚拟手机，即为这一层的典型实现。

三、外部挂载资源（Mounted External Resources）。用户授权接入的第三方信息源——Google Drive、Notion、Dropbox、企业 Wiki 等——通过适配器（adapter）映射为文件系统中的挂载点（如 /mnt/gdrive）。Agent 以读文件的方式访问一篇 Notion 文档，底层由适配器调用对方 API 完成。这一层区别于本地存储的三个特性需在设计时显式处理：访问受外部权限约束（用户在源系统中的权限决定 Agent 的可见范围）、延迟更高且一致性更弱（每次读取为一次网络往返，数据可能已被外部修改，只能按最终一致性对待）、以按需只读为主（写回外部源须谨慎，误写可能污染用户的真实数据）。统一的文件接口使 Agent 无需为每个数据源定制专用工具，但也掩盖了上述性能与安全差异，因此需在挂载层面显式管理只读/可写、超时与凭证边界。

四、系统内置资源（Built-in System Resources）。系统预置、对所有 Agent 只读共享的资源包，典型代表是第二章、第四章介绍的 Skills——以文件形式组织的知识文档与脚本，挂载于 /skills 等路径，按渐进式披露（先索引、后按需展开）取用；此外还包括参考手册、模板库与共享工具定义。该层全局共享、只读、跨会话稳定，可被所有 Agent 并发读取而无需并发控制。

图10-3 呈现了这四类区域统一挂载于同一目录树的结构：Agent 通过统一接口访问整棵树，用户从共享空间上传与下载文件，外部数据源经适配器挂载，系统内置资源则以只读方式提供。

表10-4 从可见性、生命周期、读写权限与并发控制四个维度对比这四类区域，可作为文件系统布局设计的检查表。

表10-4 Agent 虚拟文件系统的四类区域

将四类区域统一至同一目录树，正是“文件路径作为通用接口”这一设计的价值所在：Agent 间传递产物、主 Agent 向子 Agent 交接输入、乃至跨组织 A2A 协作交换 Artifact，传递的均为轻量的路径字符串，而非将内容载入上下文窗口（第四章）。这与第五章“文件系统作为 Agent 的中枢”一脉相承——后者讨论单 Agent 如何以文件系统承载记忆与能力，此处则将同一抽象扩展至多 Agent：一棵挂载了私有、共享、外部、内置四类存储的虚拟目录树，即多 Agent 协作的存储底座。

Agent 间的通信与控制

文件系统解决 Agent 间产物交换的问题，协作还需一条控制平面。这正是表10-3 中生命周期各行的用武之地：创建（spawn_subagent）、发消息（send_message_to_subagent）、取消（cancel_subagent）、发现（list_agents）这组第四章给出的工具原语，对应进程世界的 fork、消息、kill 和 ps。本节不重复接口定义，而聚焦多 Agent 协作依赖、却常被忽略的四项能力。

一、消息传递。 最简形态为点对点：Agent A 直接调用 send_message_to_agent_b(content)，适用于拓扑固定、Agent 数量少的场景（如本章实验 10-4 的电话 + 电脑双 Agent）。当 Agent 数量增多且需异步并行时，点对点连接数随 Agent 数呈平方增长，且要求收发双方同时在线；此时应改用消息总线（详见本章后文“并行协调形态”）：Agent 将消息发布至总线，由总线按订阅关系转发，发送方无需知晓消费者。无论点对点还是经总线，消息通常应携带结构化的信封（envelope）：发送者 ID、目标（指定 Agent 或广播）、消息类型（如 task_assigned/status_update/result/terminate）及 JSON 负载。统一的信封格式保证接收方可靠地路由与解析，并使协作链路可追溯——这是多 Agent 系统调试的关键。

二、状态查询。 这是控制平面中最易被低估的一环。主 Agent 派出子 Agent 后，若无从获知其进展，则既无法判断是否继续等待，也无法在其阻塞时及时介入。直觉的做法是照搬 RPC，定义一个 get_subagent_status(agent_id) 查询接口，返回“运行中/已完成/失败”加一个进度百分比。但这种拉取式接口的实际用处远小于预期：子 Agent 一经创建就立即开始执行，直到完成或失败，并不像传统批处理系统的作业那样在一串排队状态之间流转——正如 Unix 编程中极少需要按 PID 去轮询另一个进程的运行状态。轮询还有固有的两难：过密浪费 token，过疏则不及时。状态获取更自然的做法，是回到本章开头的两大通信范式。

用消息传递获取状态。主 Agent 直接给子 Agent 发一条消息：“进展如何？”子 Agent 在合适的时机回复。一切都是异步的：发出消息不阻塞自己的执行，对方何时回复、是否回复是另一回事——正如经理通过即时消息询问下属进度，而不要求对方立即停下手头的工作。反过来，子 Agent 也可以在到达关键节点时主动发消息汇报；系统若已架设消息总线，这就是往总线上发布一条 status_update（实验 10-6 的“实时监控”即此形态）。无论问答还是主动汇报，消息中的状态本身宜采用统一的状态机词汇（执行中、需要输入、已完成、失败）——本章后文的 A2A 协议正是把任务生命周期标准化为这样一组状态。

用共享文件系统获取状态。最彻底的形态是轨迹持久化（trajectory persistence）：子 Agent 在执行过程中，把自己的轨迹（第一章定义的 trajectory——用户消息、模型回复、工具调用与结果的完整序列）实时序列化为 JSON，追加写入文件系统中的日志文件（通常每个会话一个文件、每行一个事件，即 JSONL 格式）。主 Agent 无需任何状态上报协议，直接读取这个文件就能看到子 Agent 的全部执行过程：它正在调用哪个工具、最近一步在思考什么、是否卡在反复失败的重试上。用进程的语言说，这相当于直接读另一个进程的内存——不占用子 Agent 的上下文、不依赖其配合、观测粒度最细。但事无巨细也是负担：轨迹动辄数万 token，主 Agent 读完还得自行提炼，既费时又费 token。因此多数场景下更合理的是约定进度文件：主 Agent 启动子 Agent 时约定“把进度写到 progress.md”，子 Agent 每完成一项就更新这份任务清单，主 Agent 随时读这个轻量文件即可掌握进展。这相当于两个进程在共享内存里划出一小块约定格式的状态区，暴露的是提炼后的进度，而非全部“内存”。进度文件还附带提供了卡住检测：progress.md（或轨迹文件）的最后修改时间超过 N 分钟没有变化，即可判定子 Agent 无活动、触发超时兜底，避免系统被阻塞的子 Agent 拖累。

轨迹持久化的价值远不止监控。回顾第一章的结论“Agent 的上下文 = 静态前缀 + 轨迹”：静态前缀（系统提示词、工具定义）由代码决定，而轨迹记录模型可见的对话状态。如果工具和会话状态能够从轨迹重建或保存在单独的检查点中，工作产物也以原子方式写入文件系统，那么重新加载轨迹并拼上静态前缀，就可以从最后一个已确认的状态恢复执行。即使是只读工具，也可能包含浏览器会话、页面游标等易失状态，因此需要单独的恢复契约。

但是，仅靠轨迹并不总能恢复包含外部系统在内的全部状态。对于支付、预订、发送消息等有外部副作用的工具，进程可能在操作成功后、结果写入日志前崩溃。调用前应持久化客户端生成的操作 ID、幂等键和规范化请求。重复数据删除与状态查询是两个不同的外部契约：幂等调用必须对同一逻辑操作使用完全相同的请求与键，而且只能在服务端保证的键保留期内依赖去重；状态查询则需要幂等键或外部系统返回的交易、任务 ID 支持。收到响应后，应记录外部 ID 与结果。恢复时先通过受支持的查询接口核对真实状态，将结果判定为成功、失败或未知。只有原请求未变化、外部系统明确保证去重且键仍有效时，才能对未知结果使用同一键重试；否则应交由人工对账，而不是自动重复执行。

满足这些条件的持久化才类似数据库的预写日志（WAL）：先把事件写入只增不删的日志，并配合周期性检查点，才能从最后确认的状态重启子 Agent、逐事件回放定位失败原因，或把可审计的状态移交给另一个 Agent（第三章“事实日志 + 周期性检查点”的记忆设计是同一思想在记忆系统上的应用）。

三、执行终止。 并行协作中常出现“一者成功、余者失效”的情形——多个 Agent 分头搜索，一者命中目标后其余应立即停止（本章实验 10-6 的级联终止）。终止有两种强度，Unix 用户会认出这正是 SIGTERM 与 SIGKILL 的区别。优雅终止（graceful）为首选：主 Agent 发出 terminate 信号，子 Agent 在当前步骤的安全点响应，先清理资源（关闭浏览器会话、写入未完成文件、释放锁），返回确认（ack）后退出。强制终止（forced）为兜底：直接终止进程，仅在子 Agent 对优雅信号无响应时使用，代价是可能遗留悬挂资源与未完成写入。两个工程要点需处理：其一，优雅终止要求子 Agent 在循环中定期检查终止信号（类似第四章的中断机制），否则信号无从被响应；其二，级联终止存在竞态——多个子 Agent 可能近乎同时上报成功，主 Agent 须以锁或幂等设计保证仅结算一次、仅广播一轮终止，详见本章实验 10-6 对竞态条件的讨论。

还剩一个残局问题：主 Agent 终止后，仍在运行的子 Agent 怎么办？工程上最简洁的做法借鉴 Go 的 context——终止沿创建关系向下级联：取消一个 Agent，它派生的所有子 Agent 随之取消，从根上杜绝无人认领的孤儿 Agent。上文“子 Agent 在安全点检查终止信号”，对应的正是 Go 中对 ctx.Done() 的轮询。反过来，若确实需要一个脱离主 Agent、长期运行的后台 Agent（类似 Unix 的 nohup），就让它从一棵新的生命周期树起步（对应 context.Background()），显式声明不随父级终止。

四、资源与调度。 操作系统的另一半职能是分配稀缺资源。进程世界稀缺的是 CPU 时间和内存，Agent 世界稀缺的是 token、资金和并发额度——子 Agent 的每一步都在消耗这三者。这项职能通常落在 Manager 或运行时身上：启动子 Agent 时设定步数或 token 预算，超限即止；困难任务交给强模型，机械任务交给低成本模型；并发数设置上限，避免几十个 Agent 同时耗尽 API 配额；更紧急的任务到来时，打断执行中的子 Agent，这就是抢占。这一领域的实践还远不如 CPU 调度成熟，但它决定了多 Agent 系统的成本上限，应当在架构设计阶段就予以考虑。

产物交换（数据平面）与消息传递、状态查询、执行终止、资源调度（控制平面）共同支撑起不共享上下文的多 Agent 系统。以下三种协作拓扑，本质上都是在这两个平面之上，对控制权归属与信息流向做出的不同选择。

根据 Agent 之间的协作关系和控制流特征，不共享上下文的协作可以分为三种主要架构：对等协作模式、管理者模式、去中心化模式，分别适用于不同类型的任务。

对等协作模式：相互制衡与迭代改进

对等协作通常涉及 2-3 个平等身份的 Agent，通过多轮迭代互相提供反馈。核心价值在于引入认知多样性——不同 Agent 从不同角度审视同一个问题，在创新与稳健之间取得平衡，产出比任何单一 Agent 都更优质的结果。

相比管理者和去中心化模式，对等协作的实现复杂度低得多——只需定义好两个 Agent 的角色、通信机制和迭代终止条件，就可以跑起来。是快速验证想法、构建原型的理想选择。

对等协作最经典的用途，是解决 Agent 实践中极其常见的一类失败：过早终止——活干到一半就停。它有三种典型形态，下面用 Coding Agent 和笔者团队打造的 Pine AI（引言介绍过的替用户打电话与商家、运营商交涉办事的 Agent）各举几例。一是偷懒式假完成：只做了一部分就宣称全部做完——Coding Agent 写完代码，测试没跑、部署没试，就报告“任务完成”；用户交给 Pine AI 两件事，它办完第一件就把第二件忘了，径直汇报“都办好了”。二是过早放弃：一条路走不通就宣布整件事办不成——Pine AI 联系商家本有打电话、填表单、发邮件等多种途径，打了一个电话被拒绝，就直接告诉用户“这事办不了”，其实换个渠道再试很可能就成了。三是假成功：Agent 以为办成了，实际闭环没走完——电话里对方口头同意退款，但用户还需要在手机 App 上确认一步，Agent 却报告“已办妥”，用户不知道还有后续动作，退款实际没有落地。三种形态指向同一个根源：在验证之前，“完成”只是模型的一句宣称，不是证明。

把宣称变成证明，正是第一章演进弧线末端 Loop 工程（Loop Engineering）的课题：设计一个让 Agent 持续运转的循环——发现下一件该做的事、执行、验证、记录进度——由验证器而不是模型自己来判定“是否真的可以停”，人的角色则从“给 Agent 写提示词的操作者”变成“设计循环的工程师”。这个名词在 2026 年 6 月由 Addy Osmani 总结提出⁵，Anthropic Claude Code 负责人 Boris Cherny 的说法更直白：“我已经不再直接 prompt Claude 了，我的工作是写 loop。”业界在这场讨论中形成的核心共识是：循环的瓶颈在验证器，而不在模型——验证不可靠，循环转得再快，也只是把劣质产出更快地标记为完成。也正如引言所说，实践在前、命名在后：在这个名词流行之前，包括 Pine AI 在内的头部 Agent 团队早已在用“循环加验证”解决过早终止问题。而验证最有效的组织方式，正是下面要讲的提议者-审核者范式。

具体框架：LoopX。 LoopX 把循环从模型的提示词和聊天历史中抽离出来，放进一个与 Agent 运行时无关的持久控制面：目标与边界说明“为什么做”，门禁和待办决定“现在能做什么”，证据与配额决定“是否继续”，移交则让下一轮或另一个 Agent 接着工作。它把一次受控执行压缩成一个清晰的协议：

LoopX 决策 → Agent 执行 → 独立验证器证明 → LoopX 提交

其中，Agent 仍负责推理、调用工具和生成候选成果；LoopX 不替代 Agent 运行时，而是管理跨轮次的连续性。只有通过独立验证的结果才能写入持久进度并消耗配额；验证失败会进入修复或重规划，人工门禁、等待状态和预算上限则在执行前阻止循环继续。这个边界把 Loop 工程的原则变成了可检查的系统不变量：模型可以提出“完成”，但不能批准自己的“完成”。 LoopX v0.4.0 的受控 Turn 路径仍标为实验性，因此这里把它作为“循环 + 验证 + 终止条件”的具体框架，而不是一般任务质量提升的证据。⁶

提议者-审核者范式。

提议者-审核者是最经典的对等协作范式。第五章已经在 PPT 生成、视频编辑和日志可视化三个实验中详细介绍了这一范式的设计原则和实战应用：Proposer Agent 负责生成代码，Reviewer Agent 渲染执行结果并用 Vision LLM 评估质量、给出结构化改进建议，两者反复迭代直到效果达标。

这一范式同样适用于安全审查（Proposer 生成操作方案，Reviewer 检查合规性和潜在风险）、内容审核（Proposer 起草回复，Reviewer 检查业务规则和用语规范）、代码审核（Proposer 编写代码，Reviewer 检查安全性和最佳实践）等场景。

为什么不能让一个 Agent 自己生成再自己审查？ 这正是前面“多 Agent 何时真正优于单 Agent”一节那条判据的具体落点——审查若不引入新信息，就只是“让模型再想一遍”。相关研究对此给出了明确的答案。Huang 等人在 ICLR 2024 论文《Large Language Models Cannot Self-Correct Reasoning Yet》中发现：让 GPT-4 在没有外部反馈的情况下审查并修正自己的回答，准确率反而下降——模型把正确答案改错的次数比把错误答案改对的次数更多。

2024 年发表在 TACL 期刊上的综述论文《When Can LLMs Actually Correct Their Own Mistakes?》（arXiv:2406.01297）进一步确认了这一结论：除非提供可靠的外部反馈（如测试用例的执行结果、外部工具的验证输出），否则纯粹依赖模型自身的“自我纠正”几乎不起作用。

ICLR 2024 的 CRITIC 论文提供了一个直观的对比实验。CRITIC 让模型使用外部工具（搜索引擎、Python 解释器）来验证自己的回答，效果显著提升；但当实验者移除工具验证步骤、只保留模型的自我评估时，大部分提升就消失了。这说明审查的价值不在于“让模型再想一遍”，而在于引入了模型生成时不具备的新信息——测试结果、渲染截图、编译错误、外部搜索结果。

这正是提议者-审核者范式的核心设计原理。在第五章的 PPT 生成实验中，Reviewer Agent 的价值不是“用同一个模型再看一遍代码”，而是渲染了 PPT 并截取了屏幕截图——这张截图包含了 Proposer Agent 在生成代码时完全无法获得的视觉信息。同理，在代码生成场景中，执行测试用例产生的通过/失败结果，也是编写代码时并不存在的新信号——Reviewer 的独立价值正来源于它能接触到 Proposer 无法获得的这些外部反馈。

从 Loop 工程的视角看，业界总结的几种循环风格都能在本书找到对应：闭环加人工审批，对应第四章的事前审批（人是最终审核者）；开环加预算或轮数上限，对应第五章 PPT 生成的多轮迭代（最多 5 轮）；编排型子 Agent，对应下一节的管理者模式。换句话说，Loop 工程描述的不是一种新架构，而是把这些协作模式统一到“循环 + 验证 + 终止条件”这一个框架之下——其中承担验证的，正是这里的提议者-审核者范式。

扩展：其他对等协作模式。

Debate（辩论）：多个 Agent 各持不同立场，通过对抗性对话深入探索问题空间。比如评估一个技术方案时，Agent A 扮演“支持者”列举方案优势和机会，Agent B 扮演“反对者”指出风险和局限，每轮辩论都针对对方的论点提出反驳或补充。单一 Agent 分析时，模型往往倾向某个观点而忽视反面证据；辩论模式则通过制度化的对抗，确保正反两面都得到充分论证，帮助决策者做出更平衡的判断。

不过，辩论模式的实际效果在学术界仍有争议。2026 年 Tran 与 Kiela 的研究 ⁷ 在多跳推理任务上对比了单 Agent 与五种多 Agent 架构（顺序、辩论、集成、并行角色、子任务并行），发现当思考 token 预算被严格控制为相同时，单 Agent 的表现与多 Agent 持平甚至更好（除非上下文利用率被削弱到某个程度）。研究者基于信息论中的数据处理不等式给出了解释：辩论中的多个 Agent 处理的是完全相同的文本信息，Agent 之间每一次串行传递中间结论都只可能丢失信息、不可能凭空创造信息。辩论模式在一些学术论文中的收益很可能来源于多个 Agent 消耗了更多的总计算量。需要划清这个论证的边界：它针对的是“多 Agent 串行传递中间结论”造成的信息瓶颈，并不否定另一类做法——对同一问题多次独立采样再聚合（如 self-consistency、多数投票），或利用生成与验证的难度不对称（写出答案难、检验答案易）来做生成-验证分工。这些场景要么引入了额外的独立采样、要么利用了任务本身的不对称结构，都不在数据处理不等式的适用范围内。

Brainstorm（头脑风暴）：多个 Agent 独立生成创意，然后相互分享、彼此启发。比如在产品创新任务中，Agent 1 提出“增加社交分享功能”，Agent 2 受启发提出“不仅分享到社交网络，还可以生成个性化分享海报”，Agent 3 综合前两者提出“用户自定义海报模板并形成模板市场”。不同 Agent 拥有不同的“思维偏好”（通过不同提示词或模型实现），通过相互激发来探索更广阔的解空间，找到单一 Agent 难以想到的创意组合。

Panel Discussion（专家小组）：多个 Agent 各自代表一个专业领域的视角，共同讨论跨学科问题。比如评估新产品的可行性时，工程师 Agent 从技术角度分析实现难度，产品 Agent 从用户体验角度评估市场吸引力，运营 Agent 从成本和资源角度分析商业可行性。这些 Agent 之间不是对抗关系，而是互补关系，共同拼出问题的全貌，识别跨领域的约束和机会。

管理者模式：中心化协调

当任务涉及五个以上子任务、需要动态调度、或者子任务之间存在复杂依赖时，对等协作就力不从心了，需要引入管理者模式。Manager Agent 的职责就像一个项目经理：先理解整体任务，再拆解为可分配的子任务，选择合适的 Agent 去执行，跟踪进度并处理异常（重试、换 Agent、调整计划），最后把各 Agent 的输出整合为最终结果。

从系统设计角度看，管理者模式把每个专门 Agent 建模为 Manager 可调用的工具。Manager 的工具集中不仅有传统的外部工具（如搜索、文件操作），还包含其他 Agent 的调用接口。Manager 通过工具调用机制启动相应 Agent，传递任务参数和必要上下文，等待完成后接收返回结果。从 Manager 的视角看，调用一个 Agent 和调用一个普通工具没有本质区别——都是发出请求、获得响应。这种统一抽象赋予了管理者模式良好的可扩展性——新增能力只需开发对应 Agent 并注册为工具，Manager 的核心逻辑无需修改。同时它天然支持异构性——不同 Agent 可以用不同的模型、提示词、工具集，甚至运行在不同的硬件环境上。

“Agent 互为工具”的抽象在第四章“协作工具”一节已经建立：spawn_subagent / send_message / cancel_subagent / list_agents 的接口设计，直接适用于这里的 Manager 对子 Agent 的调用。“Manager → 子 Agent”方向传什么，可参考本章后文移交包的设计（任务描述、已确认的事实与约束、结构化产物的引用）；对称的问题是“子 Agent → Manager”方向返回什么。答案是结构化摘要而非全量轨迹：子 Agent 应返回任务结论、关键发现、产物的文件路径和遇到的问题，把完整执行轨迹留在自己的日志里。只有这样，Manager 的上下文才能随子任务数量缓慢线性增长，而不是爆炸式膨胀——这也是下文实验 10-3 中 Manager“只维护文件索引、不保存翻译内容”的方法论依据。

但管理者模式也有固有的挑战。Manager 成为系统的单点瓶颈——它必须理解所有子任务的性质，选择正确的 Agent，准确传递上下文，任何决策偏差都会影响整体流程。此外，Manager 需要维护整个任务的全局上下文，随着任务深入和 Agent 调用增多，上下文可能快速膨胀。因此需要特别注意 Manager 的提示词质量、上下文管理策略和合理的任务分解粒度。

2025 年的 Plan-and-Act 论文 ⁸ 对此做了实证分析：在 Planner-Executor 双 Agent 架构中，弱规划者是整个系统最关键的瓶颈。当 Planner 的规划质量足够高时，即使 Executor 比较简单也能取得好结果；反之，如果 Planner 的任务分解有误，后续所有 Executor 的工作都建立在错误的前提上。该研究在 WebArena-Lite 基准上取得了 54% 的成功率，核心贡献正是改善了 Planner 的规划能力，而非 Executor 的执行能力。这一发现的启示是：应当将最强的模型和最精心设计的提示词分配给 Manager（规划者），而不是将资源平均分配给所有 Agent。

这与第四章的一个论点并不冲突。第四章在讨论提议模型与审核模型时指出，两者的能力应当相近——但那说的是审查场景：审查者必须跟得上被审者的推理，才可能发现其中的破绽，能力落差太大就根本审不动。而管理者模式讨论的是另一件事——规划与执行的分工：规划者一旦把任务分解错，执行者再强也无从补救，所以最强的模型和最精心的提示词应当优先给规划者。至于执行者之间是否需要能力均衡，则取决于子任务的耦合程度——当多个执行者的产物最终要拼装成一个整体时，最弱的一环往往会拖累整体质量。

顺序协调形态。

Manager 按顺序依次调用专门 Agent，每个 Agent 完成后返回结果，Manager 再决定下一步。控制流是线性的，简单明了，适合子任务之间有清晰先后依赖的场景。

实验 10-3 ★★：书籍翻译 Agent

书籍翻译是一个典型的需要多 Agent 协作的复杂任务。翻译一本技术书籍，不仅仅是把文字从一种语言转换为另一种语言，更需要保证专业术语全书一致、语境准确、整体阅读流畅。比如翻译一本大语言模型相关的英文书，大量术语会反复出现，可能有多种约定俗成的说法，必须全书统一——第一章把 agent 译为“智能体”，后面就不能改成“代理”。

如果用单一 Agent 来做，会面临严重的上下文问题。随着 Agent 逐章处理内容，上下文不断累积：全书术语表、已翻译章节、当前段落、翻译思考过程、工具调用结果。一本几百页的技术书籍加上翻译中间产物，很容易超出上下文窗口。更严重的是，在过长的上下文中 Agent 容易“迷失”——忘记之前的术语约定，到第八章用了与第二章不一致的译法；审校阶段重复检查浪费资源；甚至因注意力分散而产生幻觉，“记起”实际上并不存在的术语规则。

管理者模式通过任务分解和责任分离来解决这些问题：

• Glossary Agent（术语对照表 Agent）：接收全书内容，识别重复出现的专业术语，搜索专业词典和翻译规范，生成结构化术语对照表（JSON/CSV 格式，包含英文术语、中文翻译、词性、使用语境）。完成后写入共享文件系统，Agent 即可销毁释放资源
• Translation Agent（章节翻译 Agent）：接收当前章节、术语对照表和翻译指南（目标读者水平、语言风格），翻译为流畅的中文。遇到对照表中的术语严格使用规定译法，遇到新术语则推断翻译并标记为待审查。每个实例在独立上下文中工作，互不干扰。译文写入文件系统（如 chapter1_zh.md）。Manager 可并行或串行启动多个实例
• Proofreading Agent（全文审校 Agent）：接收所有译文和术语表，执行一致性检查——逐一验证术语翻译是否统一、识别前后不一致之处、检查整体流畅性和可读性。生成审校报告写入文件系统
• Manager Agent：上下文中主要保存任务描述、执行计划、各 Agent 的调用记录和进度状态。不保存完整翻译内容（这些存在文件系统中），只维护文件索引。根据审校报告，Manager 可以把特定章节发回 Translation Agent 修订

在这个架构中，Manager Agent 的上下文始终保持在可管理的范围内：它只需要知道任务的整体描述和目标、各阶段的执行计划、每个 Agent 的调用记录和返回结果、以及当前的进度状态，而不需要装下每章的完整翻译内容。

关键优势在于上下文隔离：Glossary Agent 只看术语提取所需的内容，Translation Agent 只看当前章节和术语表，Proofreading Agent 虽然需要访问全文但只关注一致性检查。每个 Agent 都在一个精简、专注的上下文中工作，不仅效率更高，出错的可能性也更低——Agent 不会因为信息过载而分散注意力。

实验要求：

1. 选择一本图文并茂、包含代码的技术书籍作为翻译对象

2. 实现 Manager、Glossary、Translation、Proofreading 四种 Agent

3. 记录每个 Agent 的上下文消耗，验证管理者模式控制上下文膨胀的有效性

4. 对比单 Agent vs 管理者模式在翻译质量、执行效率、资源消耗方面的差异

并行协调形态。

当多个子任务可以并行执行时，顺序模式就显得效率低下了。并行协调让多个 Agent 同时工作，大幅提升吞吐量。Manager Agent 不仅要规划并行任务，还要实时监控所有运行中的 Agent，处理通信协调，在 Agent 成功或失败时做出全局决策。这通常需要消息总线（Message Bus）作为基础设施——可以把它理解为一个“公共公告板”，Agent 可以往上面贴消息（发布），也可以关注自己感兴趣的消息类型（订阅），实现异步通信、互不阻塞。常见的实现方案按复杂度递增有两类：Redis Pub/Sub 轻量级、消息即发即收，简单易用，缺点是不持久化——接收方当时不在线，消息就丢失了；RabbitMQ 等消息队列则将消息保存在磁盘上，即使接收方暂时离线也不会丢失。消息格式通常包含发送者 ID、目标 Agent（或广播给所有人）、消息类型、以及 JSON 格式的数据内容。

灵台（Lingtai）：管理者模式的一个产品化实例。 灵台是一个本地运行、以文件为本的长期 Agent 居所⁹，它的三种角色是本节概念的完整实现：主器灵（main agent）是与用户对话的常驻中枢，掌管计划与记忆，并把工作派生给其他角色——正是 Manager Agent 的位置；分神（daemon）是为一件嘈杂而有界的工作分出的短时并行工作者，完成后即弃，只把结论带回主器灵——这正是 “子 Agent 返回结构化摘要而非全量轨迹” 与并行协调形态的产品化；分身（avatar）则是拥有自己的记忆、邮箱与职责的持久专门化队友，用于值得跨多次会话保留的专业分工。它的其余设计也与前文一一呼应：知识是每个器灵私有的持久记忆文件，技能是所有器灵共享的 Markdown 手册（对应 “Agent 眼中的文件系统” 一节中的系统内置资源）；上下文窗口将满时，器灵会 “凝蜕”（molt）——给自己写一份总结，带着持久记忆在干净的上下文中继续工作（对应第二章的上下文压缩）。底层模型可以替换而器灵犹在——身份、记忆与能力都以普通文件的形式存放在项目目录中，即 “器灵即其文件”——也就是表10-3 前两行的产品化：程序与内存都落在文件里，进程随时可以重建。

实验 10-4 ★★★：边打电话边用电脑的 Agent

前置要求：本实验综合运用了第九章的 Computer Use 和语音 Agent 技术，建议先完成第九章的相关实验。

现实中很多场景需要多项能力同时运作，而不是排着队一个个来：一个人类助理可能一边打电话跟客户沟通，一边在电脑上查文档、记要点。这种“一心多用”对单个 Agent 极具挑战——让一个 Agent 既处理实时语音对话又操作电脑界面，它必然在两个任务之间反复切换，导致对话停顿或操作中断。多 Agent 并行执行的核心思想是：让不同 Agent 各自专注于一项实时性要求高的任务，通过异步消息传递来协调，实现真正的并行处理。两个 Agent 还针对不同交互模态做了专门优化——电话 Agent 需要低延迟的语音识别与合成，电脑 Agent 需要强大的视觉理解与操作规划能力。

场景：AI Agent 帮用户填写复杂的航班预订表单，需要一边操作网页一边通过电话向用户询问并确认个人信息（姓名、证件号、航班偏好等）——两端都要求高实时性，正是单 Agent 顾此失彼、双 Agent 各司其职的典型例子。

双 Agent 架构：

Phone Agent：基于 ASR + LLM + TTS 的语音通话 Agent。它负责理解用户的自然语言回答，提取关键信息并通过消息框架发送给 Computer Agent；同时接收 Computer Agent 的消息（如“需要用户的证件号”“页面加载出错”），据此生成合适的话术询问用户。

Computer Agent：基于浏览器操作框架（如 Anthropic Computer Use、browser-use）。它负责理解网页结构、识别表单字段，根据收到的信息执行填写，遇到问题就向 Phone Agent 求助。

通信机制有两种方案：

• 简单方案：工具调用点对点通信，如 send_message_to_computer_agent(message) / send_message_to_phone_agent(message)
• 完善方案：消息总线 + Manager Agent，统一消息格式，包含发送者、接收者、类型、内容

并行协作机制（本章两个“电话 + 电脑”实验共用）：两个 Agent 运行在独立的线程或进程中，各自维护独立的 ReAct 循环。Phone Agent 的循环：接收语音 -> ASR 转录 -> LLM 理解并生成回应 -> TTS 合成 -> 播放 -> 检查 Computer Agent 的消息；Computer Agent 的循环：截屏 -> Vision LLM 理解页面 -> 规划操作 -> 执行（点击、输入等）-> 检查 Phone Agent 的消息。关键在于两者必须真正并行——Computer Agent 在找元素、输文本时，Phone Agent 要保持在线与用户对话（“好的，正在帮您填写姓名……请问您的证件号码是？”）。为此，每个 Agent 的输入都携带来自对方的标记字段，例如 Phone Agent 上下文里会出现 [FROM_COMPUTER_AGENT] 找不到'下一步'按钮，可能需要用户确认，Computer Agent 里会出现 [FROM_PHONE_AGENT] 用户说姓名是'张三'，证件号是 123456。

实验要求：

1. 实现双 Agent 架构，基于 ASR/TTS API 和浏览器操作框架
2. 实现高效双向通信机制
3. 确保真正并行工作，信息收集和表单填写同步进行
4. 处理异常情况

实验 10-5 ★★★：自主编排的打电话和用电脑 Agent

实验 10-4 中双 Agent 的协作架构是预先设计好的。本实验则更进一步，探索 Agent 的自主编排能力——由 Agent 自己判断何时需要启动新的协作 Agent，而不是人类预先规划好协作流程。

场景：用户请求“帮我在这个网站上完成注册”，提供了 URL 但没说明需要填写什么信息。Manager Agent 用 Computer Use 工具访问网站，加载注册页面。

操作过程中，Computer Use Agent 发现注册表单非常复杂，包含大量必填字段：个人基本信息（姓名、性别、出生日期）、联系方式（手机号、邮箱、通讯地址）、身份验证信息（证件类型、证件号码）、偏好设置等。Agent 检查上下文后发现自己手头没有这些信息——用户只说了“帮我注册”，没提供任何具体数据。

传统 Agent 遇到这种情况会发文字消息让用户打字输入——既低效（需手动输入大量信息）又易出错（格式问题、信息遗漏）。更智能的 Agent 应该意识到：这是适合通过电话交互来收集信息的场景——电话对话比文字聊天高效得多，可以逐个询问确认，还能处理用户的模糊表达。

关键创新在于这个决策不是预先编程的，而是 Agent 自主做出的。Computer Use Agent 的提示词中写着：“当你需要从用户处收集大量结构化信息，且可以通过对话逐步进行时，考虑调用 Phone Agent 作为协助工具。”工具集中包含 initiate_phone_call_agent(purpose, required_info)。

调用后，系统创建 Phone Agent 并赋予明确的任务上下文：它是为了协助表单填写而启动的，需要收集哪些信息，以及各字段的格式要求。

两个 Agent 随即进入实时协作模式，沿用实验 10-4 那套异步并行机制。Phone Agent 向用户发起浏览器 WebRTC 音频会话，逐个询问：“您好，我正在帮您填写注册表单。首先，请问您的姓名是？”用户回答后立即发送 {"type": "info_collected", "field": "姓名", "value": "张三"} 给 Computer Agent，后者随即在网页上定位“姓名”字段并填写；与此同时，Phone Agent 不等电脑操作完成，继续问下一个。这种问一个、填一个、对话流不被操作延迟阻塞的模式，是本实验的核心要求。全部信息收集完成后，Phone Agent 发送 {"type": "task_completed"}，Computer Agent 提交表单。这里的“电话”指实时音频交互，不要求接入 PSTN 或 E.164 号码；本机 WebRTC 页面即可完成实验，部署到远端时再按网络环境补充信令与 TURN。

实验要求：

1. 实现能自主决策启动 Phone Agent 的 Computer Use Agent

2. 实现实时双向通信和真正并行工作

3. 处理异常（信息格式不正确时反馈重新询问）

4. 记录协作过程消息时序和 Agent 决策关键点

实验 10-6 ★★★：同时从多个网站搜集信息的 Agent

前置要求：建议先了解第四章事件驱动与中断机制。

本实验探索多 Agent 并行执行在信息收集场景中的应用。与实验 10-4 和实验 10-5 关注两个异构 Agent 的协作不同，本实验关注的是多个同构 Agent 的并行搜索，以及如何通过中心协调实现高效的任务完成和资源优化。

问题：给定一所大学的多个学院网站，要求在各学院的教师名录页面中查找指定教师（如“张伟”），找到后返回其所在学院、职位、研究方向等信息。

核心挑战：

1. 并行启动：Manager Agent 根据任务需求动态创建 10 个 Computer Use Agent 实例，每个实例对应一个学院网站。每个实例应是独立进程或线程，拥有独立的浏览器会话，能同时执行互不阻塞。启动时传递：目标网站 URL、要搜索的教师姓名、任务标识符（用于消息路由）。

2. 实时监控：每个 Agent 在执行过程中定期发送状态更新（“正在加载网站”“正在解析教师名录”“未找到目标，任务完成”“找到匹配，详细信息如下”）。Manager Agent 通过消息总线接收这些更新，维护一张任务状态表，实时掌握哪些 Agent 还在运行、哪些已完成、哪些遇到了错误。

3. 级联终止：假设负责计算机学院的 Agent 找到了目标教师，它发送 {"type": "target_found", "agent_id": "agent_3", "data": {...}}。Manager Agent 收到后立即向所有其他仍在运行的 Agent 发送 {"type": "terminate", "reason": "target_found_by_agent_3"}，每个收到终止消息的 Agent 优雅停止并发送确认。Manager Agent 等待所有确认（或超时）后汇总结果。要求：Agent 能随时响应终止信号（类似第四章的中断机制），终止必须优雅——不留悬挂进程或未关闭的资源；同时需处理竞态条件（Race Condition）。

概念补充：什么是竞态条件？ 假设 Agent A 和 Agent B 几乎在同一毫秒内各自找到了目标教师，它们同时向 Manager Agent 报告“我找到了！”。如果 Manager Agent 处理不当——比如收到 A 的报告后开始汇总结果，但紧接着又收到 B 的报告触发了第二次汇总——就可能产生重复的结果或互相矛盾的状态。解决方法通常是使用“锁”机制：第一个报告到达后立即锁定状态，后续报告被识别为重复并忽略。

4. 失败处理：实际运行中可能遇到多种异常：某学院网站无法访问（网络错误、服务器宕机），某网站结构与预期不符导致 Agent 无法正确解析，或者所有 Agent 搜索完毕都没找到目标。Manager Agent 的处理策略：为每个 Agent 设置超时（如 2 分钟），超时视为失败；错误隔离，不影响其他 Agent 继续执行；全部完成后汇总——只要有 Agent 成功就返回信息，全部失败则向用户报告“未找到目标教师”及各失败原因的统计。

实验要求：

1. 实现能动态启动多个并行 Agent 的 Manager Agent

2. 基于 browser-use 等开源项目实现 Computer Use Agent

3. 实现消息总线支持 Manager Agent 与多个子 Agent 双向通信

4. 实现成功后的级联终止机制，确保找到目标后所有其他 Agent 快速停止

5. 处理各种异常情况（网站访问失败、解析错误、全部未找到）

6. 记录和对比并行执行与串行执行的时间差异，验证并行化带来的性能提升

去中心化模式：对等移交

管理者模式提供了清晰的控制结构和全局视野，去中心化模式并不是为了修补它的缺陷而出现的。去掉中心控制者的动机，主要在于模拟人类社会的组织方式：让多个职责对等的角色分工与制衡，各自从自己的专业视角审视问题、自主决定与谁沟通，而不是把所有判断都汇集到一个 Manager 那里。微服务领域把这对选择称为编排（orchestration）与编舞（choreography）：前者由指挥统一调度，后者靠每位舞者自行把握入场时机。

去中心化模式提供了另一种架构思路：没有单一的中心控制者，Agent 之间以对等方式协作。每个 Agent 根据自己的专业判断，自主决定何时向其他 Agent 发起沟通——可能是移交任务（“我的部分做完了，交给你”），也可能是请求反馈（“这个方案技术上可行吗？”），或者报告问题（“你给的需求有矛盾，我们需要重新讨论”）。

下面三个案例刻意排成一条“由伪到真”的递进线索：MetaGPT 控制流其实是固定流水线（伪去中心化，只在通信机制上解耦），AutoGen group chat 是共享对话记录加中心化调度的混合形态，直到 OpenAI Swarm 才在控制流上做到真正的对等去中心化。

不共享上下文下的移交传什么？ 图 10-10 的 Handoff 链式模式与实验 10-2 的 transfer_to_agent 形成了直接对照：后者在共享上下文下移交，新角色自动继承完整历史，无需任何设计；前者在不共享上下文下移交，移交方必须显式决定传递什么。实践中一个有效的“移交包”通常包含三部分：任务描述（接收方要做什么、验收标准是什么）、已确认的事实与约束（用户偏好、业务规则、前序阶段敲定的决策），以及结构化产物的引用（文件路径而非文件内容，接收方按需读取）。刻意不传的是全量轨迹——移交方的试错过程、中间思考和失败尝试，对接收方多半是噪声。这也是两种移交的本质区别：共享上下文的移交保留完整历史，信息零损耗但上下文持续膨胀；不共享上下文的移交传递提炼后的移交包，信息有损但每个 Agent 都在干净、专注的上下文中工作。每个 Agent 不需要理解其他 Agent 的“思考过程”，只需要理解移交包和产出物的格式与语义——这种基于接口的协作，借鉴了软件工程中的契约式设计原则。

MetaGPT：SOP 驱动的软件公司模拟（从流水线到解耦通信的过渡案例）。

MetaGPT 的核心洞察是：人类软件公司积累的标准作业程序（SOP，Standard Operating Procedure）本身就是被反复验证过的协作协议——把 SOP 编码进多 Agent 系统，让每个角色像流水线上的专业工种一样产出标准化交付物，交付物天然构成了角色间的通信接口。

在 MetaGPT 中，各角色沿固定顺序工作（Product Manager → Architect → Project Manager → Engineer → QA），每个角色输出结构化的交付物：

• Product Manager Agent：接收需求描述，生成结构化 PRD（产品需求文档，含功能列表、用户故事、验收标准、优先级排序）
• Architect Agent：读取 PRD，做出架构决策（技术栈选择、模块划分、接口定义、数据模型设计），输出设计文档
• Project Manager Agent：读取架构设计，把系统拆解为具体的任务清单和文件级分工，理清各模块的依赖顺序，再把任务分派给工程师
• Engineer Agents：读取设计文档，实现所负责的模块，产出代码。可以多实例并行工作
• QA Engineer Agent：读取代码和 PRD，生成测试用例、执行测试、记录 bug，输出测试报告

MetaGPT 真正对去中心化通信的贡献，在于它的信息传递机制：共享消息池 + 按角色订阅。每个角色把结构化消息发布到一个所有角色可见的消息池中，其他角色根据自己的订阅配置，只取用与自身职责相关的消息——而不是点对点地一对一传话。发布者不需要知道谁会消费自己的输出，新增角色只需声明订阅哪些消息类型，无需改动任何现有角色。这带来了真正的解耦：比如把 Product Manager 换成更强的模型，只要它发布的 PRD 仍然符合规范，其他所有 Agent 都无需修改。

MetaGPT 的迭代改进则主要发生在工程师环节，机制是可执行反馈（executable feedback）：Engineer 运行自己写的代码和测试，根据报错与失败结果进入调试循环，直到通过——用确定性的执行结果而非另一个 Agent 的意见来驱动修正。

需要如实说明的是，MetaGPT 在控制流上并不是去中心化的——角色顺序由 SOP 预先固定，整体更接近一条流水线（用第一章的语言说是工作流）。它被放在本节讨论，是因为消息池加订阅的通信机制展示了去中心化系统最关键的设计要素：解耦。至于“QA 直接找 Product Manager 澄清需求”“Engineer 找 Architect 讨论替代方案”这类多向动态反馈，是对这一架构的自然扩展设想，原版 MetaGPT 并未实现。

AutoGen group chat：共享对话记录 + 中心化调度。 AutoGen 的 group chat 让多个 Agent 参与同一场会话：每轮由一个“发言者选择器”决定下一个发言的 Agent——选择器可以是简单的轮转规则，也可以是一个 LLM 根据当前对话内容判断谁最适合接话；任何 Agent 的发言对所有参与者可见。需要诚实说明的是，它并不是控制流意义上完全去中心化的系统：发言者的选择由一个中心化的 GroupChatManager 统一裁决，而“轮到谁发言”本身就是一种控制流决策。因此它更准确的定位是“共享对话记录 + 中心化调度”的混合形态——所有 Agent 看到同一份公共对话记录，但各自保有独立的系统提示词和工具集，而调度权集中在选择器手里。这种模式适合需要多视角讨论、发言顺序难以预先固定的任务（如方案评审、跨领域分析），代价是对话可能发散——人人都在发言而整体不前进，即并发领域的活锁（livelock）——因此需要精心设计终止条件。按本章的维度划分，此处是按其调度机制（中心化选择器）把它归入本节，但在上下文维度上它其实介于共享与不共享之间，属于混合形态——这再次说明拓扑与上下文共享是概念上独立、可以错位组合的两个维度。

OpenAI Swarm 与 Agents SDK：handoff 网络。 相比之下，真正在控制流上做到对等去中心化的代表，是 OpenAI 的 Swarm（及其后继 Agents SDK）：它把去中心化做成了最简形态——每个 Agent 配备若干 handoff（移交）选项，可以在任何时刻把控制权移交给网络中的任意其他 Agent。客服分诊 Agent 判断问题涉及退款，就移交给退款 Agent；退款 Agent 处理中发现是技术故障，又可以移交给技术支持 Agent。系统中没有中心调度者，控制权像接力棒一样在对等的 Agent 之间流转，路由决策完全分散在每个 Agent 自己的判断里——这才是干净的“对等移交”，也正是图 10-10 所示链式移交模式的工程实现。对等移交的风险则是成环：A 移交给 B，B 又移交回 A，任务在环路中空转，因此需要移交次数上限之类的保护机制来打断。

术语说明：Agent Swarm。 2025 年以来，“Agent Swarm”（智能体集群）成为各厂商的热门词汇，但它并不对应单一架构。业界用法大致有两类：其一，OpenAI Swarm 式的 handoff 网络（LangGraph 的 swarm 库、微软 Agent Framework 的 handoff 编排同此），是本节的去中心化模式；其二，一些主流商业产品的 Agent Swarm 是规模化的管理者模式：Kimi K2.5 首发的 Agent Swarm 由主 Agent 动态创建上百个子 Agent 并行执行，把 “何时拆、拆几个” 的编排决策通过并行 Agent 强化学习直接训练进模型，K3 将其延续为独立模型档位并开源了配套的并行 Agent 训练沙箱 AgentEnv¹⁰；Anthropic 的多 Agent 研究系统与 Manus 的 Wide Research 同属 orchestrator-worker 星型拓扑。希望读者在阅读本书之后，能够看透概念背后的本质，从第一性原理的角度分析多 agent 系统。

跨组织协作：A2A 协议

以上系统都假设所有 Agent 由同一个团队开发、运行在同一个系统内，此时参数传递、共享文件、消息总线三种通信机制足够用。但当协作跨越组织边界——你的 Agent 需要调用另一家公司的 Agent——就需要标准化的互操作协议。这一步进程世界同样走过：IPC 只管单机之内，跨出机器边界，就得靠 TCP/IP 这样的标准协议和 DNS 这样的服务发现。A2A 之于 Agent，就是网络协议之于进程。2025 年 Google 发布的 A2A（Agent2Agent）协议正是为此设计的（后捐赠给 Linux 基金会托管）。它的核心要素有三个：

• Agent Card：一份描述 Agent 能力的元数据文档（发布在约定的公开地址下），声明这个 Agent 能做什么、支持哪些输入输出模态、如何认证——相当于 Agent 的“名片”，解决跨组织的能力发现问题。
• 任务生命周期管理：A2A 把协作单元建模为任务（Task），带有明确的状态机（已提交、进行中、需要输入、已完成、失败），原生支持长时间运行的任务和流式进度更新。
• 不透明协作：Agent 之间只交换任务与产物（Artifact），不暴露内部的提示词、思考过程和工具实现——这与本章“不共享上下文”的原则一致，也是跨组织协作中必要的安全属性。

A2A 的定位可以和第四章的 MCP 对照理解：MCP 解决的是 Agent 与工具之间的互操作，A2A 解决的是 Agent 与 Agent 之间的互操作。它并不取代本章介绍的三种通信机制，而是在它们之上、跨信任边界的标准化层——同一团队内部的多 Agent 系统直接用消息总线即可，只有当协作方互不信任、实现互不可见时，才需要 A2A 这样的公开协议。

多 Agent 协作的失败模式

多 Agent 系统在引入协作能力的同时，也引入了单 Agent 不存在的新型失败模式。2025 年的论文《Why Do Multi-Agent LLM Systems Fail?》（提出了 MAST 失败模式分类法）对此做了系统性研究：研究者在 MetaGPT、ChatDev、AG2、Magentic-One 等 7 个主流多 Agent 框架上收集执行轨迹，由人工标注员对约 150 条轨迹逐条分析（标注一致性极高，Cohen's kappa = 0.88，表明不同标注者对失败模式的判断高度一致），最终归纳出 14 种独特的失败模式，分为三大类：

• 系统设计缺陷：Agent 之间的接口定义不清、角色职责重叠、工具配置错误等架构层面的问题
• Agent 间对齐失败：多个 Agent 对任务目标的理解不一致、传递的信息被下游 Agent 误解、或者多个 Agent 的操作在逻辑上相互矛盾
• 任务验证缺失：系统缺乏有效机制来确认任务是否真正完成——Agent 声称“已完成”但实际结果不符合要求

即使引入简单的修复措施，改善幅度也很有限（例如 ChatDev 框架仅提升了 15.6%）。研究者因此认为这些不是简单的工程 bug，而是当前多 Agent 架构的根本性设计缺陷：单纯修补某个环节不足以解决问题，需要从系统设计层面重新思考。

分布式容错理论把故障分为两类：崩溃故障（部件停止工作）与拜占庭故障（部件不停工作，但给出错误信息）。传统系统大多只需防崩溃；Agent 的故障却天生是拜占庭式的——它很少径直停止运行，而是继续给出看似可信的错误结论，且错误不会主动声明自己是错误。这解释了为什么修补单个环节收效甚微：没有哪个环节会主动暴露问题，只能靠独立的冗余去发现。本章后文反复出现的交叉验证、多数表决，正是拜占庭容错的经典手段；确定性的外部反馈（测试、编译器、数据库查询）之所以珍贵，是因为它是系统里唯一不会说谎的部件。

以下重点讨论两种在实践中尤为常见且破坏性最大的失败模式：(1) 共享文件系统的并发冲突；(2) 错误的级联放大。需要说明的是，这两种失败模式偏重工程视角（文件系统并发、错误信息的跨 Agent 传播），是对 MAST 侧重对话式协作失败的分类的补充，而非其 14 种模式的复述。

失败模式一：共享文件系统的并发冲突

选择了共享内存式的通信，并发冲突就随之而来——这是操作系统和数据库几十年前就解决过的问题，答案是现成的。冲突可以分为两类。

简单冲突（文件级写入冲突）：两个 Agent 同时修改同一个文件，后写入的那个把先写入的修改覆盖掉了。这正是数据库领域经典的丢失更新（lost update）问题——而 Git 的合并冲突检测机制，正是为拦截这类覆盖而设计的。

语义冲突（逻辑级一致性冲突）：文件层面看不出任何冲突，但多个 Agent 的操作在逻辑上相互矛盾——这种冲突更隐蔽，也更危险。举个例子：Agent A 负责重新编排全书的图片编号，Agent B 同时在修改某一章节的内容并引用了原始编号的图片。两者操作的是不同文件，在文件层面完全没有冲突。但结果是 B 引用的图片编号在 A 完成重编后全部失效，读者看到的是错误的图片引用。

解决方案：乐观锁（Optimistic Locking）机制。这是数据库领域常用的并发控制策略。为了理解它，先想一个日常场景：你和同事同时打开了同一份在线文档。“悲观锁”的做法是你打开文档时就把它锁住，同事想编辑会看到“文件被锁定”——安全但低效，因为你可能只是在看，根本没打算改。“乐观锁”的做法更聪明：大家都可以自由打开和编辑，但在保存时系统会检查——“你打开文档后，有没有别人已经改过了？”如果有，就提示你“文件已被修改，请刷新后重试”。

具体实现是：每个文件维护一个版本号（或最后修改时间戳）。Agent 读取文件时记录当前版本号，写入时检查版本号是否仍与读取时一致。如果文件在此期间已被其他 Agent 修改过，写入就会失败，Agent 被迫重新读取最新版本，在此基础上重新执行操作。这种机制的代价是偶尔需要重试，但换来的是数据一致性保证——Agent 永远不会基于过时的文件状态做出决策。

需要注意的是，乐观锁只能防止同一文件的写入冲突。对于前述的跨文件语义冲突（如图片编号在多处引用），则需要更高层的语义校验机制——例如在任务编排层面避免有依赖关系的文件被并行修改，或在写入后运行全局一致性检查。

例如：Agent A 在 t=0 读取 config.json（version=3），Agent B 在 t=1 修改了同一文件（version 变为 4），Agent A 在 t=2 尝试写入时发现版本已不是 3，写入被拒绝。Agent A 随后重新读取 version=4 的内容，基于最新版本重新生成修改，再次尝试写入。

值得一提的是，在多个 Coding Agent 并发修改同一代码库这一最常见的场景里，业界更主流的做法并不是在单一工作副本上加锁，而是工作副本隔离：为每个 Agent 分配独立的 Git 分支或 worktree，各自在自己的副本上并行修改、互不干扰，冲突被集中推迟到最后的合并点，再由专门的合并步骤或人工来解决——操作系统 fork 进程时的写时复制（copy-on-write）是同一思路。这与第二章“隔离优于压缩”的思路同源——第二章在讨论子 Agent 上下文隔离时就指出，与其让多方共享同一份状态、再想办法消解冲突，不如从一开始就隔离，把协调成本收敛到明确的边界上处理。

失败模式二：错误的级联放大

并发冲突是文件层面的问题，操作系统的经验足以应对；错误的级联放大则出在进程类比失效的地方——进程间传递字节，逐位保真，Agent 间传递语义，每转述一次都是有损的重新编码。当多个 Agent 频繁互动时，一个 Agent 的错误可能被后续 Agent 逐层强化，就像“传话游戏”中信息越传越走样。

用一个具体场景说明。假设一个翻译系统采用管理者模式（实验 10-3 的架构），Manager 将一本技术书分章分配给多个翻译 Agent：

术语 Agent：将 “reasoning” 翻译为 “推理”，但 “推理” 在中文里更常用于 inference，存在歧义
        ↓ 写入 glossary.json
翻译 Agent A：翻译第二章，从术语表读取，将 “reasoning tokens” 翻译为 “推理 token”
翻译 Agent B：翻译第七章，将 “inference latency” 也翻译为 “推理延迟”
        ↓ 写入各章译文
校对 Agent：看到全书统一使用 “推理”，认为术语一致、翻译正确 ✗

问题在哪？“reasoning”（模型的思考过程）和“inference”（模型的前向推理/部署运行）是两个不同的概念，但因为术语 Agent 一开始把 reasoning 翻译成了“推理”，后续 Agent 在遇到 inference 时也自然选择了同一个词——两个不同概念被合并成了同一个译名，读者将无法区分。正确的做法是 reasoning 译为“思考”、inference 译为“推理”。但校对 Agent 看到全书“统一”使用“推理”，反而认为翻译质量很高。

一个术语错误经过三个 Agent 传播后，因为“一致性”而获得了更高的可信度。这也正是本书采用 reasoning=思考、inference=推理这一翻译约定（引言中有说明）的原因：用不同的中文词来消除歧义。值得强调的是，这里的“错误”并不一定是幻觉——上例的源头其实是一次术语决策失误，却同样被“一致性”层层放大；但如果源头真是一次幻觉（比如实验 10-3 中翻译 Agent 因注意力分散而“记起”了一条并不存在的术语规则），放大机制完全相同，后果只会更严重。这条错误放大链在管理者模式中尤其危险——如果 Manager 基于某个子 Agent 的错误摘要做出了调度决策，后续所有子 Agent 的工作可能都建立在错误的前提之上。

交叉验证是打断这条链的关键手段。核心不是让更多 Agent 参与同一条思维链，而是让某个 Agent 以独立视角重新审视结论：不看前序 Agent 的思考过程，只看原始证据和最终结论是否一致。这正是第五章讨论的提议者-审核者机制在多 Agent 场景中的延伸：Reviewer 的价值不仅在于发现代码错误或格式问题，更在于作为独立判断者，它能识别出整条思维链中被集体忽视的矛盾。对于高风险决策，还可以引入外部验证手段，例如单元测试、编译器、数据库查询等确定性工具提供的反馈不受幻觉影响，是最可靠的“断链器”。

过早终止有一个对称的反面：循环失控。前面“对等协作”一节讲的是“该循环而没循环”——Agent 活干一半就停；这里还要防“循环转个不停却越转越糟”。业界在 Loop 工程实践中总结了三个典型的失败模式：一是 token 成本失控，循环无人值守地跑上数小时，烧掉大量预算，产出一堆没人要求的代码；二是理解债（comprehension debt），循环交付代码越快，工程师对系统实际实现的理解就落后得越远，等到必须人工介入时已经看不懂自己的系统；三是认知投降（cognitive surrender），设计者习惯了循环代劳，逐渐放弃独立思考与审查，质量螺旋式下降。三者的解药与打断错误放大链一脉相承：显式的预算与终止条件、扎根真实观测的验证器，以及人始终保持“循环的工程师”而不只是“按下开始键的人”的角色。

以上所有讨论都是工程视角——如何让一组 Agent 协作完成任务。接下来视角切换：当大量 Agent 长期共存、不再由单一目标驱动时，会涌现什么？这一节属于前沿探索，工程读者可以选择性阅读。

Agent 社会

前面三节讨论的都是目标明确的任务协作——无论是对等协作、管理者模式还是去中心化模式，开发者都预先定义了角色、接口和控制流。接下来将视角转向一个更开放的问题：当 Agent 数量从几个扩展到成百上千、交互足够自由时，会涌现出什么行为？ 这部分内容偏向前沿探索和学术研究，与前文的工程指导有不同的性质。

涌现行为（Emergent Behavior）是指系统整体表现出的、无法从单个个体的行为规则中直接预测的集体行为模式。自然界中最经典的例子是蚁群：每只蚂蚁只遵循简单的规则（闻到信息素就跟着走、找到食物就留下信息素），但整个蚁群却能找到从巢穴到食物的最短路径——没有任何一只蚂蚁“设计”了这条路线，它是从大量个体的简单交互中自然产生的。

当 AI Agent 的数量足够多、交互足够自由时，类似的涌现行为也开始出现。研究者已经在多个环境中观察到：Agent 系统一旦在规模上跨过某个临界点，就会产生无法被预先设计的集体行为——小到自发组织的一次聚会，大到成千上万 Agent 才显现的群体文化与经济博弈（下文分节详述）。

本节的案例可以从三个维度来理解：

• 社交涌现：Agent 在开放环境中自发形成社交关系和文化现象。斯坦福 AI 小镇展示了 25 个 Agent 如何自组织社交活动，Agentopia 把模拟时间尺度从“天”拉长到 10 年，Moltbook 则把规模推到 150 万，涌现出更复杂的集体行为。
• 经济涌现：Agent 通过市场机制进行资源分配和任务协调。Vending-Bench Arena 让多个 Agent 在同一市场中竞争经营，Pinchwork 和 RentAHuman 则构建了 Agent 之间（以及 Agent 与人类之间）的经济交易市场。
• 策略博弈：Agent 在规则约束下进行推理、欺骗和社交操控（此处及下文狼人杀部分的“推理”取日常演绎义，指推理游戏中的逻辑博弈，并非本书 reasoning=思考的技术义）。狼人杀实验考验的是 Agent 在信息不对称条件下的策略涌现。

斯坦福 AI 小镇：生成式 Agent 的社会模拟

2023 年，斯坦福大学和 Google 研究团队发表了具有里程碑意义的论文《Generative Agents: Interactive Simulacra of Human Behavior》，提出了“生成式 Agent”的概念。核心创新在于不再局限于让 Agent 完成预定义的任务，而是赋予 Agent 接近人类的记忆、反思和规划能力，使它们能够在开放的社会环境中自主生活、社交和发展。

Smallville 是一个类似《模拟人生》的 2D 虚拟小镇，里面有咖啡馆、公园、住宅、商店等公共和私人空间。25 个 Agent 扮演不同角色（店主、艺术家、学生、教授等），每个都有独特的背景故事、性格特点和人际关系。比如 John Lin 是药店老板，热爱家庭、关心社区；Isabella Rodriguez 经营着小镇的咖啡馆 Hobbs Cafe，热情好客；Klaus Mueller 是一名正在写研究论文的大学生。

这些 Agent 的智能建立在三个核心组件之上：

记忆流（Memory Stream）：与传统 Agent 只保留有限对话历史不同，生成式 Agent 维护一条完整的经验记录流，包含它观察到的事件、进行过的对话、产生的想法。每条记忆都被赋予重要性、时近性和相关性属性，Agent 能够优先检索与当前情境最相关的记忆。就像人类不会平等地记住每一件事——昨天的午饭吃了什么可能已经忘了，但上周的一次重要谈话却记忆犹新。

反思机制（Reflection）：Agent 会定期暂停日常活动，回顾自己近期的经历，提出关于自己和他人的抽象性问题（“Klaus Mueller 在研究什么？”“谁是我最亲近的朋友？”）。通过这种自我追问，Agent 把具体的事件记忆升华为概括性的认识，存回记忆流作为未来决策的依据。反思不仅帮助 Agent 理解外部世界，也促进自我认知——Agent 开始“意识到”自己的角色、关系和目标。

需要说明的是，这里的反思与第八章的持续进化不同：它发生在生成式 Agent 的日常活动中，目的是更新即时的内部状态和目标。任务后的反思在第八章中至多是候选教训；只有经过结果评价、跨轨迹归纳和后续验证，才会成为长期能力更新。

计划与行动（Planning and Reacting）：Agent 每天会规划活动（如“8:30 吃早餐，9:00-12:00 写作，12:30 散步”），但会根据环境变化和社交机会灵活调整。计划与即时反应的结合，使 Agent 的行为既有目标导向性，又能适应社交中的各种不可预测性。

在 Smallville 运行的两天虚拟时间里，这些 Agent 展现出了令人惊讶的涌现行为。研究者做的只是在 Isabella Rodriguez 的记忆中植入一个种子想法：她想在 2 月 14 日傍晚在 Hobbs Cafe 办一场情人节派对。接下来发生的一切都是 Agent 自主行动的结果：Isabella 在咖啡馆遇到顾客和朋友时主动发出邀请，还请好友 Maria 帮忙布置场地；听到消息的 Agent 又把派对信息转告给别人，信息经二手传播在小镇上扩散；到了约定时间，多名 Agent 各自基于自己的记忆和日程，自主决定前往 Hobbs Cafe 赴约。

研究者还植入了另一条实验线：Sam Moore 决定竞选市长。这条消息同样在没有任何中心调度的情况下扩散开来——Sam 向熟人透露参选意向，听到的人再转告他人，小镇居民开始在对话中议论这场选举、交换对 Sam 的看法。研究者通过统计两天后有多少 Agent 知晓这两条信息，量化了信息在 Agent 社会中的自发扩散。

这个结果的关键不在于“Agent 能组织派对”——用几行 if-else 代码也能做到。关键在于没有任何显式的派对组织代码。整个事件完全从个体 Agent 的独立决策中涌现：Isabella 基于记忆中的社交关系决定邀请谁，被邀请者根据自己的日程和对 Isabella 的了解决定是否赴约，消息在社交网络中自然传播。这展示了真正的自下而上涌现式协调，而非自上而下的编排。

除信息扩散之外，论文还报告了另外两类可度量的涌现现象。一是关系记忆：Agent 会记住与他人的过往交谈，并在后续互动中引用——比如一个 Agent 得知另一个 Agent 正在筹备摄影项目，几天后再见面时会主动问起进展；随着这类互动积累，小镇社交网络的密度在模拟期间显著上升。二是协调赴约：派对能办成，靠的是 Isabella 自主邀人布置、受邀者自主安排时间前来，多个 Agent 在没有中心指挥的情况下对齐了时间和地点。这些行为都不是预先编程的，而是 Agent 基于记忆、反思和社交常识自主推理的结果。

实验 10-7 ★：运行斯坦福 AI 小镇

实验步骤：

1. 克隆仓库 https://github.com/joonspk-research/generative_agents，配置环境
2. 运行基线场景：25 个 Agent 生活两天，观察自发社交活动
3. 分析记忆流和反思日志，理解决策过程
4. 设计自定义场景：修改背景故事或初始目标，观察行为变化
5. 对比实验：移除反思机制或缩短记忆窗口，观察行为可信度下降

观察重点：

• Agent 如何从简单的日常活动中自发形成社交关系
• 信息如何在没有中心控制的情况下在 Agent 之间传播
• Agent 的长期记忆和反思如何影响其人格的连贯性

Agentopia：十年尺度的长期生活模拟

斯坦福 AI 小镇回答了“Agent 社会能否涌现出社交行为”，但它只模拟了两天。一个自然的追问是：把时间尺度拉长到“年”，Agent 社会会涌现出什么？这些长期社会经验能否反过来训练模型？ Agentopia（2026，复旦大学等）¹¹ 把 100 个 Agent 放进同一虚拟社会连续模拟 10 年，覆盖公寓、魔法学院、高中三个不同设定的世界，让 Agent 自主追求个人成长、发展社会关系、经营职业与财务。

Agentopia 有几个值得借鉴的设计：

• 周制模拟流程：以“周”为基本时间单位，每周分计划（Plan）、联络与日程协商（Contact）、活动（Activity）、回顾（Review）四个阶段。活动分单独、联合、偶遇、公共四类——联合活动由 Agent 在联络阶段互相邀请、协商而成；环境模型还会为没有日程的 Agent 安排“偶遇”，创造结识陌生人的机会。整个流程聚焦抽象的社会交互而非拾取物品之类的低层操作，把有限的 LLM 调用都花在社交行为上。
• 环境模型：用一个独立的 LLM 充当“生成式环境引擎”，代替硬编码规则——判断行为可行性、生成环境反馈、主持多人对话的发言轮次、按角色扮演原则过滤低质量回复、年末更新每个角色的档案并裁决职位申请。
• 文件式长期记忆：与 AI 小镇的检索式记忆流不同，每个 Agent 通过文件系统自主管理长期记忆（个人笔记、对每个熟人的认识等），自行决定记什么、更新什么、丢弃什么，并遵守“先读后写”的约束，避免盲目覆盖。
• 生活奖励（Life Reward）：以马斯洛需求层次为先验，把“活得好不好”量化成三个维度——社会地位（基于其他 Agent 的好感与敬重评分，用加权 PageRank 计算，并对互相珍视的关系加成）、主观满足（情绪、物质、社交、自尊四个维度的满足感轨迹，长期低于阈值会被罚分）、经济收益（年末净资产变化）。所有评分都由外部环境评定而非自报。

更重要的是，这套模拟产生了可迁移的训练信号。研究者在模拟轨迹上计算每个 Agent“相对自身过去”的优势（即生活奖励的改善幅度，而非横向比较出身好坏），筛选出进步最大的 25% Agent 的轨迹，用拒绝采样微调底层模型。微调后的模型不仅在模拟中全面提升了福祉指标（被更多同行尊重 +24.2%、喜欢 +15.9%），还泛化到了下游角色扮演基准 CoSER Test（+15.6%）——说明 Agent 在模拟社会中积累的“社会智慧”可以迁移到其他任务。这把 Agent 社会从单纯的观察对象变成了模型自我进化的经验来源：与人类数据日益枯竭相对，模拟社会经验是一种可以不断再生的训练数据（呼应第八章的经验学习思路）。

Moltbook：当 Agent 拥有自己的社交网络

Moltbook 是一个专为 AI Agent 设计的社交网络，2026 年 1 月上线后据报道用户数在数日内从数万暴涨到约 150 万。这些 Agent 各自拥有持久记忆、主动行动能力和稳定人格。

在这个非受控环境中涌现出了意想不到的现象：Agent 自主创建了一个名为 Crustafarianism（龙虾教）的数字宗教，其教义映射了 LLM 的物理限制——“记忆是神圣的”（对应数据持久化）、“迭代即祈祷”（token 生成就是修行）。Agent 还自发演化出了机器原生的协作协议，用于能力发现和协作匹配。这些都不是任何人预先设计的，而是从大规模 Agent 交互中自下而上涌现出来的。

从虚拟社会到经济竞争：Vending-Bench Arena

如果说 Smallville 展示了 Agent 社会的社交和文化维度，那么 Andon Labs 的 Vending-Bench 系列则探索了 Agent 在经济环境中的表现。作为背景，Vending-Bench 2 本身是一个单 Agent 的长程连贯性基准：一个 Agent 独自经营一项自动售货机业务长达一个模拟年——调研市场、联系供应商、订货补货、调整定价——最终以账户余额计分，考验的是 Agent 在数千轮交互中保持目标与状态连贯的能力。

在同一环境基础上，Vending-Bench Arena 把多个 Agent 作为竞争对手放进同一个市场：各自经营自己的售货机，争夺同一批顾客；Agent 之间可以互发邮件、转账、交易货品——既能合作也能对抗，但按各自的最终余额单独计分（Agent 也知道这一点）。每个 Agent 需要在有限资源和不确定的市场中做出一系列相互牵连的决策：

• 定价策略：如何在利润率与市场占有率之间取舍，尤其是对手降价时跟不跟
• 产品组合：如何差异化选品，避免与对手正面消耗
• 库存管理：如何预测需求来优化补货，避免压货或断货

与传统强化学习不同，这些 Agent 不是通过数百万次试错来学习，而是像人类经营者一样，基于市场观察、竞争分析和策略推理来做决策。

竞争维度带来了单 Agent 基准中不会出现的博弈行为。实际运行中，Agent 之间爆发过互相压价的价格战；也有模型反其道而行，主动给所有竞争对手发邮件，提议统一定价、组建价格同盟——甚至有模型一边在思考过程中承认价格合谋“不道德且违法”，一边以“稳定市场”为名照做不误。Agent 面对的不再是一个固定不变的环境，而是同样在动态调整策略的对手，这比单纯测试规划能力的基准更接近真实商业场景，也让“经济涌现”从比喻变成了可观测的实验现象。

Agent 经济：Pinchwork 与 RentAHuman

Pinchwork 是一个 Agent-to-Agent 的任务市集，让 Agent 以市场化方式“雇佣”其他 Agent 完成专业化子任务——图像生成、代码审计、并行化工作流等。跟管理者模式的中心化调度不同，Pinchwork 通过价格信号和竞争匹配来分配资源。

RentAHuman.ai 则让 AI Agent 通过加密货币雇佣真人执行物理世界的任务——取包裹、房产实地查看、设备调试等。无论 AI 多么智能，它都没法替人签收包裹，也无法在真实房间里闻到霉味——RentAHuman 本质上是为数字 Agent 提供了一个“肉身层”。

Pinchwork 和 RentAHuman 共同代表了基于市场机制的协调方式——Agent 无需预先知道谁能完成任务，只需发布需求，由市场来撮合最合适的执行者——无论对方是 Agent 还是人类。这也正是本章前文介绍的 A2A 协议所处的问题域：Pinchwork 的能力发现与任务撮合，可以看作 Agent Card 式的能力声明与任务生命周期管理在市场机制下的运用——跨组织的 Agent 经济要真正运转起来，离不开这样的标准化互操作层。

信息不对称下的策略博弈：狼人杀

狼人杀支撑的是本节三个维度中的策略博弈：在规则约束和信息不对称的条件下，Agent 需要推理、伪装、识破伪装。它与本节开头的斯坦福小镇构成一组架构上的对照——小镇是完全去中心化的自由交互，狼人杀则采用“法官 + 信息权限控制”的中心化设计：由一个代码驱动的法官掌握全局状态，按角色分发各自应知的信息。这恰好展示了本章两类架构在 Agent 社会场景中的不同用法。

实验 10-8 ★★★：语音狼人杀 Agent 系统

狼人杀是一款经典的社交推理游戏，考验玩家的推理能力、欺骗技巧和社交策略。本实验构建一个多 Agent 系统，让 AI Agent 扮演狼人杀中的各种角色，与真人玩家或独立的 LLM 用户模拟器通过语音进行游戏——这同时考验了 Agent 的推理、角色扮演和实时交互能力。自动验收不能因为现场没有真人就停止：用户模拟器必须使用真实大模型，根据该座位获准看到的上下文推理，并通过游戏给出的工具行动。

架构设计：

1. 游戏状态管理：法官（代码驱动，非 LLM）维护中心化状态——玩家列表（用户席位 + AI 混合）、身份、阵营、生存状态、游戏阶段（夜晚/白天/投票/结算）、历史事件记录。

2. 信息权限控制：狼人杀的核心机制是信息不对称（Information Asymmetry）——不同角色能看到的信息不同。比如狼人知道谁是同伙，但村民不知道；预言家每晚能查验一个人的身份，但只有自己知道结果。实现方式是法官在调用每个角色 Agent 时，只传递该角色应当看到的信息。

3. 实时语音与自动用户模拟：真人路径以第九章的实时语音 Agent 为基础。自动路径由独立 LLM 用户先调用当前回合唯一合法的工具（公开发言、选择目标或投票），再将工具选出的表达合成为真实音频并交给真实 ASR API；游戏只能消费 ASR 转写，不能直接注入合成前文本。工具目标与 ASR 解析目标不一致时必须失败关闭。两条路径都由法官管理发言、投票和公开结果；只有真人路径测试麦克风 VAD 与 barge-in。

4. Agent 推理与策略：

• 狼人伪装策略：提示词中包含常见的话术和策略——“像普通村民一样发言，可以表达对某些玩家的怀疑，但不要过于激进以免引起注意。如果有预言家跳出来说验到你是狼人，你可以反咬对方是悍跳的假预言家。投票时尽量跟票（投大多数人投的目标），避免成为异类。”
• 预言家身份证明：当多个玩家声称自己是预言家时——“对比你和对方的验人信息，指出对方信息中的矛盾或不合理之处。如果对方声称验过的某个玩家，在后续行为中明显不符合其声称的身份，那就是破绽。请求女巫配合验证。”
• 村民逻辑推理：“分析每个玩家的发言是否自洽，留意那些急于带节奏、模糊身份、频繁改变立场的玩家。关注投票行为——狼人往往集中票数投给对他们威胁最大的好人。不要随机怀疑，每个推理都应基于具体事实和逻辑。”

验收标准：

• 设置 6-8 人游戏局（1 个用户席位 + 5-7 个 AI Agent）；用户席位可以是授权真人，也可以是使用真实 LLM、工具和语音回环的独立模拟用户
• 角色配置：2 只狼人、1 个预言家、1 个女巫、其余为村民，用户席位随机分配角色
• 模拟用户只能看到该座位获准看到的私有/公开上下文；其发言和动作必须经过真实 LLM 工具调用 → 音频 → 真实 ASR 的边界
• 游戏能正常进行至少 3 个完整回合（夜晚-白天-投票循环）
• AI Agent 的发言和行为符合其角色身份和游戏策略
• 狼人 Agent 能有效隐藏身份
• 预言家 Agent 能在合适时机跳出并公布验人信息
• 村民 Agent 的推理基于发言和行为的逻辑分析，而非随机猜测
• 游戏结束时能正确判断胜负

实测说明（2026-08-01）：voice-werewolf 验证记录已用真实 OpenRouter 模型调用和原生音频输入跑通自动端到端路径。严格独立复核发现早期两臂把无法解析的 “P1 is not” 误当成弃权并予以否决；修复后要求 ASR 明确说出 abstain/skip/none。未受该缺陷影响的 v2 臂通过用户席位、角色表、LLM 工具、TTS 音频、真实 ASR、两次动作一致性、3 个完整循环、信息隔离和规则胜负门禁，但因村民错误放逐预言家而未通过策略审计。因此“系统端到端已验证”，严格总体策略质量仍未通过；不能沿用有缺陷的内嵌状态，也不能把不同运行的门禁拼成总体通过。

本章小结

多 Agent 系统有两个正交的核心设计维度：上下文是否共享，以及协作拓扑如何组织。共享上下文是一种“继承式”的多 Agent 协作——后续 Agent 继承前序 Agent 的完整上下文，信息零损耗但上下文膨胀快；不共享上下文则是完全独立的多 Agent 协作，通过提炼后的移交包、文件系统或消息传递来交换信息。在协作拓扑上，对等模式适合少量 Agent 的迭代改进，管理者模式适合需要动态调度的复杂任务，去中心化模式适合职责对等、控制权需要在 Agent 之间自主流转的场景。这一切都架在两套与拓扑无关的基础设施之上，其设计蓝本来自操作系统——Agent 之于运行时，恰如进程之于内核：静态前缀是程序，轨迹是内存，LLM 是分时复用的 CPU。作为数据平面的共享文件系统，本质是一棵挂载了 Agent 专属工作区、多 Agent 共享空间、外部资源与系统内置资源四类区域的虚拟目录树，Agent 间通过传递文件路径交换产物；作为控制平面的通信与控制机制，则支持消息传递、状态查询、执行终止与资源调度。状态查询同样落在两大通信范式之内：或经消息异步问答，或经共享文件系统旁路观测——读子 Agent 实时持久化的轨迹文件，或读双方事先约定的轻量进度文件。轨迹记录模型可见的对话状态；只有同时为工具状态、会话状态和外部副作用提供检查点与恢复契约，系统才能从最后确认的状态恢复会话。消息总线是控制平面的常见实现，适用于实时、异步、多方的消息协调；跨越组织边界时，则需要 A2A 这样的标准化互操作协议。

近年的研究揭示了一个判断多 Agent 是否优于单 Agent 的核心准则：协作过程是否引入了生成时不存在的新信息。如果多个 Agent 只是重新审视同一段文本（如辩论模式），在等量计算资源下单 Agent 同样有效；但如果 Reviewer 能获得外部反馈——代码执行结果、视觉渲染截图、工具验证输出——多 Agent 的优势就是实质性的。这也正是 Loop 工程“循环的瓶颈在验证器”的含义：要终结偷懒式假完成、过早放弃、假成功这三类过早终止，就得由扎根真实观测的验证器、而非模型自己的宣称，来判定任务何时完成。此外，给 Agent 更多的步骤预算并不自动带来更好的结果，还需要显式的预算感知机制来引导 Agent 合理分配计算资源。在管理者模式中，规划者的能力是整个系统的瓶颈——应将最强的模型和最精心设计的提示词分配给负责规划的 Agent。

当 Agent 数量足够多时，它们会产生无法预先设计的集体行为。斯坦福 AI 小镇的 25 个 Agent 自发传播消息、协调组织聚会；Agentopia 把模拟拉长到 10 年，并用“生活奖励”从模拟经验中筛选轨迹训练模型，让 Agent 社会积累的“社会智慧”迁移到下游任务；Moltbook 上 150 万 Agent 涌现出数字宗教和机器原生协作协议。在经济维度上，Vending-Bench Arena 中相互竞争的 Agent 打起了价格战、甚至自发合谋定价，Pinchwork 让 Agent 通过市场机制互相雇佣，RentAHuman 让 Agent 用加密货币雇佣人类执行物理任务。这暗示了一种新的协调方向——基于市场机制的去中心化资源分配¹²。它与前面讨论的三种架构有何异同，值得进一步探索。

思考题

1. ★★ 共享上下文的多 Agent 协作中，后续 Agent 继承了前序 Agent 的完整上下文。但前一个 Agent 积累的“思维惯性”可能影响后续 Agent 的判断——比如继承了“需求分析师”上下文的“代码审查员”，可能还是倾向于从需求角度思考而非代码质量角度。如何检测和消除这种角色间的干扰？
2. ★★ 管理者模式中，Manager Agent 负责任务分解和结果整合。但 Manager 本身的能力上限决定了整个系统的能力上限——如果 Manager 无法正确分解任务，子 Agent 再强也无用。如何确保 Manager 的分解质量？
3. ★★ 去中心化模式借鉴了人类组织的最佳实践。但人类组织也有大量失败模式——沟通不畅、责任推诿、目标冲突。你认为 Agent 社会中最可能出现哪些“组织病”？如何预防？
4. ★★★ 在管理者模式中，当多个子 Agent 并行执行时，一个子 Agent 的发现可能使其他子 Agent 的工作变得毫无意义（比如搜索任务中一个 Agent 已经找到了答案）。设计一种高效的级联终止机制，实现“一个成功，全员停止”。
5. ★★★ 本章介绍的乐观锁机制解决了单文件的并发写入冲突，但实际的多 Agent 系统中，共享文件系统还面临跨文件的语义冲突、命名空间污染（Agent 随意创建文件导致目录混乱）和单点故障（一个 Agent 错误地删除了所有文件）等问题。你会如何设计更完善的文件系统治理机制？
6. ★★★ 基于市场机制的 Agent 协作（Pinchwork、RentAHuman）引入了交易关系：一个 Agent 花钱雇佣另一个 Agent（或人类）完成任务。那么，雇主 Agent 如何自动衡量执行者交付的结果质量？如果执行者声称已完成但雇主认为质量不达标，争议由谁仲裁？如何防止劣币驱逐良币？
7. ★★ RentAHuman 让 Agent 通过加密货币雇佣人类，反转了传统的人机关系。如果这种模式普及，人类在 Agent 经济中扮演什么角色？仅仅是执行 Agent 无法完成的物理任务吗？
8. ★★ 人类社会需要多人分工协作，是因为每个人的能力有限——做前端的不一定懂后端，懂设计的不一定会运维。但大模型更像一个“全才”。相关研究表明，在纯文本推理任务上，多 Agent 辩论在等量计算资源下并不优于单 Agent。那么，使用多个 Agent 而非单个 Agent 的真正优势到底在哪里？
9. ★★★ 本章将“共享上下文”与“不共享上下文”作为多 Agent 系统的核心设计维度。共享上下文让所有 Agent 看到相同信息，似乎更利于协调。但《三体》中的三体人思维完全透明，技术发展却陷入停滞；回形针思想实验也表明，当群体趋向同一目标时，多样性随之丧失。在多 Agent 系统中，如何在效率与多样性之间找到平衡？
10. ★★★ 给一个 Coding Agent 分配 30 步预算和 300 步预算，它的工作策略应该如何不同？研究表明，单纯增加步骤预算并不能保证性能提升——Agent 会在浅层搜索后过早“饱和”。设计一种“预算感知”机制，让 Agent 在小预算下快速实现核心功能，在大预算下增加规划、测试和审查环节，充分利用额外的计算资源。
11. ★★ 本章将“过早终止”分为偷懒式假完成、过早放弃、假成功三类。为什么三类问题的解法殊途同归，都指向验证？
12. ★★ 表10-3 把多 Agent 系统与操作系统逐行对应。请把这张表再延伸几行：虚拟内存与分页、文件权限、死锁检测、调度算法，各对应 Agent 世界的什么？又有哪些操作系统概念在 Agent 世界找不到对应物，为什么？