《多智能体协同》读后：难的不是让它们说话，是说错的时候还能收敛

2026-10-30silcano

阅读方式：微信读书网页版，从版权页翻到术语表，共 487 屏、10 章、10 分 07 秒。 这是这个系列里第一本"写给工程师"的书。前十四本讲"怎么搭一个"，这本讲"搭一队之后怎么不散架"。

我先说结论：这本书的价值不在它教了什么新概念，在它把多智能体从"演示"拽回了"系统"。

演示里的多智能体是这样的：两个 Agent 你一句我一句，最后神奇地产出一份报告。系统里的多智能体是这样的：第三个 Agent 超时了，第五个拿了脏数据，第七个的输出格式不对，而你必须在 30 秒内决定——重试、降级，还是拿残缺结果继续往下走。

这本书花了大量篇幅在后一种。所以它读起来不轻松，但有用。

一、两种基本协同，和一件被所有人忽略的事

第 2 章把协同模式收敛成两种，讲得很干净。

顺序协同——一条流水线：研究员 Agent 搜资料 → 分析师 Agent 做分析 → 写作 Agent 写稿 → 审核 Agent 查错。书里对它的评价很实在：好处是职责边界清晰、调试方便、容易追踪问题，哪个环节出毛病，直接定位到那个 Agent 修就行。

但代价也写得很直白：整体执行时间是各环节的累加，没法并行加速；任何一环失败都会阻断整个流程；后续 Agent 无法提前获知任务全貌，可能做出次优决策。

最后这句是很多人没想到的：流水线后段的人，是在信息不完整的情况下做决定的。 写作 Agent 不知道研究员当初筛掉了哪些资料，只能就着给它的那点东西写。人也一样。

并行协同——任务分发器派活，竞品分析、用户调研、技术趋势、政策环境四路同时跑，最后汇总成一份报告。书里点出了真正的难点：不在派活，在"等齐、合并、局部失败怎么办"。 某个 Agent 执行失败或超时，系统必须有明确的容错策略：是等它重试、换个降级方案，还是拿着残缺的部分结果继续往下整合。

而这章我最想抄走的是 2.1 节里那个不起眼的细节——交接规范。

书里要求交接必须包含四样东西：具体的文件清单、待解决的问题、注意事项（这算三样），以及接收方必须复述确认——明确已接收的内容、理解到的任务目标，并给出预期输出和完成时间。

书里对它的定性是："这种规范化的交接方式能够有效减少信息丢失和理解偏差，是保障顺序协同质量的关键环节。"

我读到这里停了一下。因为这四条，跟人类公司里"交接不清导致项目翻车"的原因是同一套。多智能体系统的很多毛病，本质是管理毛病，不是技术毛病。

二、MCP 和 A2A：连工具，还是连同事

第 2.3 节讲新兴协议，这一段澄清了一个目前圈子里最常见的混淆。

MCP 负责连工具和数据，A2A 负责连其他 Agent。 书里的说法是"两者互补而非竞争"——一个典型的企业应用，往往两个都要用：用 MCP 把数据库、内部系统接进来，用 A2A 把别的团队的 Agent 接进来。

而 A2A 的核心设计理念，是全书我觉得最锋利的一句：让 Agent 能够"作为 Agent"而非"作为工具"进行通信。

书里紧跟着解释为什么这个区别重要：工具有固定的输入输出格式和确定性行为，而 Agent 是自主的，能够通过推理解决新问题。

翻成大白话：你调一个 API，参数错了它报错；你委托一个 Agent，它可能跟你说"这个我做不了，但我可以换个方式做"。前者是调用，后者是协商。多智能体系统真正的能力，来自后者。

协议层面书里给了四个阶段，值得记一下：

• 发现：客户端去拉对方的 Agent Card（GET /.well-known/agent.json），拿到名称、描述、技能列表、鉴权方式、支持的模态；
• 任务提交：POST /tasks/send，带上 Message 和 TaskId；
• 执行与更新：服务端用 SSE 流式回推 TaskStatusUpdateEvent，客户端能实时看到进度；
• 结果返回：交付 Artifact，支持多模态。

书里还提了一个时间点：2025 年 6 月，A2A 被捐赠给 Linux 基金会，成为真正的行业中立标准，参与方包括 SAP、ServiceNow 这些企业软件巨头。

这件事的意义常被低估——协议一旦中立，跨厂商的 Agent 互操作才可能成立。否则每家一套私有协议，所谓"Agent 互联网"就只是一堆局域网。

三、三个框架，三种世界观

第 4 章横向对比了三个主流框架。我读下来最大的感受是：它们的分歧不在功能，在"你认为协作是什么"。

LangGraph 那节讲得最细，因为它最能代表"工程派"。它的骨架就三样：State（用 TypedDict 定义的状态结构）、节点函数（读状态、返更新）、边（决定下一步走哪）。

书里给的例子是研究流程：State 里放研究主题、研究笔记、草稿内容、最终报告四个字段；三个节点各管一段；用 add_node 加节点、add_edge 定顺序、compile 编译、invoke 跑。

真正让它比"顺序流水线"强的是两条线：条件边（add_conditional_edges，接一个路由函数，按当前状态返回下一个节点名）和回边（把边指回已经执行过的节点，形成循环，但必须配终止条件）。

书里列了三类典型用法，我看完全是同一个模式的三种包装：ReAct 里推理与行动的交替、多轮对话里按意图分流、质检不通过就退回上一节点重做。

最后这个"退回重做"值得单独说：它是多智能体系统里唯一能让质量收敛的机制。 没有回边，流程就是一次性的，错了只能重跑全部；有了回边，才谈得上"改到对为止"。而"改到对为止"必须有终止条件，否则就是无限烧钱。

四、上生产的三件事：记忆、兜底、分层

第 5、6 章是这本书的重心，也是它区别于其他 Agent 书的地方。三件事讲得很扎实。

第一，记忆必须分层。 书里给的架构很标准：工作记忆对应 LLM 的上下文窗口，存当前对话的即时信息；短期记忆用 Redis 这类内存缓存，存最近几轮的关键信息，支持快速访问；长期记忆用向量数据库（Pinecone、Chroma、Qdrant 等），持久化历史对话、用户画像和领域知识，靠语义检索取回。

书里还给了"对话摘要"的做法，一段很短的提示词就把这事说清了：把对话压缩成简洁摘要，要求是保留用户意图、保留重要决策、不超过 100 字。取上下文时把"历史摘要"和"最近对话"拼起来用。

这个组合的精妙在于：摘要解决"记得久"，上下文窗口解决"记得清"，向量库解决"记得全"。 三者各管一段，谁也替代不了谁。

第二，兜底必须预置。 书里给了超时与自动重试的实现（RetryConfig：最多重试 3 次、基础延迟 1 秒、最大延迟 30 秒、指数退避基数 2.0），配了健康检查与恢复机制的流程图。

这一节我读得最认真，因为它是"演示"和"系统"的分界线。书里那句话我抄下来了：不写重试的多智能体系统，是演示，不是系统。（这句是我替他总结的，但意思就是他反复在强调的。）

第三，规模靠分层。 第 6 章给了 Manager-Worker 的完整骨架：Manager 的构造函数接收可用的 Worker 字典，在 system prompt 里声明自己的"任务分解与协调"职责；decompose_task 调 LLM 把复杂任务拆成子任务列表，每个子任务带描述和目标 Worker；execute 用 asyncio.gather 并发调度；最后 _integrate_results 整合。

书里还给了一份 Manager 的 system prompt 模板，五条职责列得清清楚楚：任务分析、任务分解、智能分配、进度监控（处理异常情况）、结果整合。这五条其实就是一个项目经理的岗位说明书。

然后是一路放大的案例：8 个 Agent 的任务协同、20 个 Agent 的智能客服（含任务流转与冲突消解）、50 个 Agent 的医疗会诊（多学科协作与安全合规）、100+ Agent 的智慧城市（交通、AIoT、大规模性能优化）。

五、核心知识图谱

六、我的保留意见

第一，代码是骨架，不是能跑的系统。 全书代码片段以"说明结构"为主，很多地方是伪实现（比如向量库那段的检索函数、摘要函数都留了壳）。想照着抄一个能上线的，还得自己补大量的错误处理、日志、鉴权和幂等。

第二，规模数字看着唬人，但成本账没算。 "100+ Agent 的城市系统"这类案例，架构图很完整，可 100 个 Agent 跑一轮要烧多少 token、延迟多少、怎么控预算，书里着墨不多（第 10.2 节提了 Prompt 版本管理与成本优化，但篇幅有限）。多智能体最先撞墙的往往不是架构，是账单。

第三，通信协议那章有时效风险。 MCP 和 A2A 都在快速演进，2025 年 6 月刚进 Linux 基金会，2026 年的实现细节大概率已经变了。这章该当"理解设计意图"读，不该当"照着实现"读。

不过瑕不掩瑜。这本书填补了一个真实的空白：市面上讲"怎么做一个 Agent"的书已经泛滥，讲"怎么让一队 Agent 在出问题时还能交付"的书，很少。

七、一句话收尾

读完这本，我对"多智能体能做多大事"的判断变了。

以前觉得瓶颈在模型——模型不够聪明，分工再细也没用。现在觉得瓶颈在协议：交接能不能不留歧义，失败能不能局部兜住，循环能不能保证终止。

这三件事做好了，用中等模型也能跑出稳定的结果；这三件事没做好，堆再强的模型，也只是让它在错误的路上一路狂奔得更快。

---

阅读记录：微信读书网页版 · 逐页翻阅 487 屏 / 10 章 / 10 分 07 秒 · 覆盖率 100%（版权页至术语表）
《多智能体协同：基于大语言模型的工程实践与系统构建》 周佺喜 著 · 电子工业出版社 · 2026-03