读完《Build a Multi-Agent System (from Scratch)》我放弃了自己瞎设计的协作方案三个 Agent 开始互相甩锅的那一刻我终于意识到——多 Agent 系统不是把几个单 Agent 放在一起跑这是一门独立的设计学科。那个让我崩溃的多 Agent 系统事情是这样的。读完第一本书之后我用纯 Python 重构了单 Agent自信心爆棚。然后我就想既然单 Agent 已经跑得这么稳了多加几个 Agent 协同工作不是水到渠成吗我设计了一个自动化运维三人组巡检 Agent每天凌晨跑一遍服务器健康检查告警 Agent发现异常后生成告警并推送到钉钉修复 Agent对已知类型的故障自动执行修复脚本架构也很简单——巡检 Agent 跑完把结果丢给告警 Agent告警 Agent 判断需要修复时再调用修复 Agent。我甚至画了一张漂亮的流程图。跑起来的前三天一切都很完美。第四天凌晨 3 点钉钉炸了。巡检 Agent 发现三台服务器 CPU 超过 90%把结果递给了告警 Agent。告警 Agent 生成了告警同时触发了修复 Agent。修复 Agent 执行了清理临时文件脚本——但它清理的是/data/cache/目录而那个目录里存的是当天白天的业务缓存。三台服务器不光 CPU 没降下来业务还挂了。更离谱的是巡检 Agent 在下一轮检查中发现修复后的服务器状态反而更差了于是它又生成了一份告警“修复脚本疑似无效建议人工介入”。告警 Agent 收到后又触发了一次修复。修复 Agent 又跑了一遍清理脚本。这个循环跑了 7 轮直到运维同事被手机震醒手动介入。事后复盘的时候我在白板上画了整个调用链发现至少 5 个设计缺陷。每一个都指向同一个问题多 Agent 系统的复杂度不在单个 Agent 的智能水平而在 Agent 之间的信息传递、状态同步和冲突解决。这就是我翻开 Val Andrei Fajardo 这本《Build a Multi-Agent System (from Scratch)》的原因。作者是谁为什么他说的话值得听在讲内容之前先说一下这本书的作者——因为他的背景直接决定了这本书的视角。Val Andrei Fajardo 曾经是LlamaIndex 的创始工程师。LlamaIndex 是目前最流行的 LLM 数据框架之一每月有数百万次下载。他参与了框架从 0 到 1 的构建过程亲眼见证了一个 Agent 框架在快速迭代中做出的各种架构权衡。离开 LlamaIndex 之后他去了Vector Institute for AI加拿大的顶级 AI 研究所图灵奖得主 Geoffrey Hinton 是联合创始人在那里做了一个叫 FedRAG 的项目——联邦学习 RAG 的结合论文被 ICML 2025 的 CODEML 工作坊接收。所以他写这本书的视角非常独特不是学术视角不是理论上 Agent 应该这样协作不是调包视角不是你用 CrewAI 的add_agent()就行了而是框架设计师视角“我设计过这个我知道这里面的坑在哪”这个视角贯穿全书也是我读完后收获最大的原因。一、单 Agent 和多 Agent 的边界不是数量不同那么简单书的开篇没有直接讲多 Agent而是先花了整整一章讨论一个问题什么情况下你需要多 Agent我之前以为答案是任务太复杂一个 Agent 搞不定。书里告诉我这个答案太粗糙了。真正需要多 Agent 的场景有 4 种每一种解决的问题完全不同。场景 1能力边界分割一个 LLM 不可能精通所有领域。一个擅长写 Python 的 Agent 不一定擅长做安全审计一个擅长数据分析的 Agent 不一定擅长写前端代码。多 Agent 的价值让每个 Agent 只做自己最擅长的事。书里举的例子很实在——一个代码审查系统拆成三个 AgentStyle Agent只检查代码风格命名规范、缩进、注释Security Agent只检查安全漏洞SQL 注入、XSS、密钥泄露Performance Agent只检查性能问题N1 查询、内存泄漏、不必要的循环三个 Agent 各审各的结果聚合起来比一个 Agent 覆盖所有维度准确率高得多。书里给了一个实际测试数据单 Agent 审查的误报率为 23%三 Agent 协作的误报率降到 8%。场景 2地域/延迟分布你的系统分布在全球多个数据中心Agent 需要在数据所在的位置就近执行。一个中心化的 Agent 需要跨地域传输数据——延迟和带宽都不允许。场景 3安全隔离某些任务需要在隔离环境中执行。比如一个 Agent 需要访问生产数据库另一个 Agent 只能访问脱敏后的测试数据。把它们放在同一个 Agent 里安全边界就模糊了。场景 4组织边界不同团队维护不同的 Agent。运维团队的 Agent 和开发团队的 Agent 需要协作但它们的内部逻辑、工具集、权限模型完全不同。你不能把它们揉成一个 Agent——组织结构决定了 Agent 结构。书里有一句话我做了笔记“如果你只是因为’看起来很酷’就上多 Agent那你在用一个复杂方案解决一个简单问题。多 Agent 的唯一合理动机是单 Agent 在这个场景下有结构性的不适用。”二、四种编排模式我之前的顺序调用只是最弱的一种这是书里信息密度最高的一章。作者把多 Agent 的协作模式分成了四种每一种都有自己的数据流、适用场景和失败模式。模式 1顺序编排SequentialAgent A → Agent B → Agent C → 最终输出**我之前的项目用的就是这个。**也是最容易出问题的。适用场景任务可以自然拆分为线性步骤。比如需求分析 → 代码生成 → 代码审查 → 测试。核心风险错误传播Agent A 的一个小错误经过 B 和 C 的放大最终输出完全不可用上下文断裂Agent A 和 Agent C 之间没有直接通信关键信息可能在 B 环节丢失书里的解决方案是**“接力棒协议”**——Agent 在传递结果时必须附带一个结构化的上下文摘要包含上一步做了什么决策为什么做这个决策当前的已知限制和假设下一步需要关注什么模式 2并发编排Parallel/Map-Reduce┌→ Agent A ─┐ 输入 → 分发器 → Agent B → 聚合器 → 输出 └→ Agent C ─┘适用场景任务可以独立并行处理。比如同时审查三个微服务的代码、“对同一份文档做多角度分析”。核心风险结果冲突Agent A 说没问题Agent B 说有严重漏洞怎么办聚合逻辑复杂三个 Agent 的审查结果格式不一致聚合器怎么统一书里用了一整节讲结果标准化——在分发任务时就给每个 Agent 相同的输出模板格式像这样{finding_id:SEC-001,severity:high|medium|low,category:security|performance|style,file:src/auth.py,line:42,description:具体问题描述,suggestion:修改建议,confidence:0.85}聚合器收到这个结构化输出之后就可以按 severity 排序、按 file 分组、去重多个 Agent 可能发现同一个问题。模式 3协作编排Collaborative/DebateAgent A ←→ Agent B ↕ ↕ 共享上下文池 ↕ ↕ Agent C ←→ Agent D适用场景需要多个视角碰撞才能产出高质量结果。比如技术方案评审、“复杂决策分析”。运作方式多个 Agent 同时拿到同一个问题各自给出答案然后互相审阅对方的答案提出质疑和修改建议经过多轮讨论后达成共识——或至少给出分歧点。核心风险无限辩论两个 Agent 各执一词谁也不让步群体思维一个 Agent 的观点主导了讨论其他 Agent 被带偏书里给了一个辩论终止条件的设计MAX_DEBATE_ROUNDS3# 最多三轮辩论CONSENSUS_THRESHOLD0.8# 80% 的 Agent 同意就算达成共识TIE_BREAKERhuman# 僵局时谁来做最终决策ifround_countMAX_DEBATE_ROUNDS:returnescalate_to_human(分歧点摘要)ifagreement_ratioCONSENSUS_THRESHOLD:returnmajority_conclusion模式 4层级编排Hierarchical总控 Agent / | \ 子Agent1 子Agent2 子Agent3 | | | 叶子Agent 叶子Agent 叶子Agent适用场景大规模复杂任务。总控 Agent 负责任务分解和委派中间层 Agent 负责协调一组子 Agent叶子 Agent 负责具体执行。核心风险委派失败总控 Agent 把任务分给了一个不擅长这件事的子 Agent汇报失真叶子 Agent 的错误经过中间层的美化到总控层已经看不出问题了书里专门强调层级编排是四种模式中最难调试、最容易在边缘场景崩溃的模式。除非你的任务复杂度确实需要三层以上的分解否则顺序或并发就够用了。四种模式对比模式复杂度延迟容错性最适合顺序低高串行差错误传播线性任务流并发中低并行中聚合可容错独立子任务协作高高多轮讨论高互相校验需要多视角层级最高中中委派链脆弱大规模复杂任务我在读这一章的时候一直在对照自己的运维三人组——我那套其实就是顺序编排而且完全没有接力棒协议。巡检 Agent 传过去的是原始的 JSON 结果告警 Agent 自己重新解析解析错了就全错了。这根本不是在协作这是在传话游戏。三、A2A 协议不是口号有具体的消息格式和状态机A2AAgent-to-Agent是 Google 在 2025 年推出的 Agent 间通信协议2026 年正在快速成为行业标准。这本书给了 A2A 协议最详细的技术剖析——不是概念介绍而是把消息格式、任务分发、状态同步全部展开讲了一遍。为什么需要 A2A书里用一个问题开场如果 10 个 Agent 需要互相通信你需要多少条自定义通信管道答案是 10×9/2 45 条。每增加一个 Agent通信链路就暴增。这不只是开发量的问题——每条链路的数据格式、错误处理、超时策略都可能不一致。A2A 做的事情就是让所有 Agent 说同一种语言。不是让 Agent 用同一种 prompt 模板而是让 Agent 之间的通信有统一的协议层。A2A 的核心消息类型书里把 A2A 定义的消息类型讲得很清楚1. Task任务{task_id:uuid-xxxx,sender_agent:orchestrator-01,receiver_agent:code-reviewer-02,task_type:code_review,priority:high,deadline:2026-05-08T12:00:00Z,payload:{code:def foo():\n pass,language:python,review_focus:[security,performance]},context:{project:order-system,related_tasks:[task-uuid-yyyy],shared_memory_keys:[project-conventions]},callback:{on_complete:orchestrator-01.handle_review_result,on_error:orchestrator-01.handle_review_error}}注意几个关键字段context.shared_memory_keys不是传整个上下文而是传需要读取哪些共享记忆的引用。这解决了大规模协作时的上下文爆炸问题。callback不是发完任务就不管了而是明确了完成和失败时的回调。我之前的系统完全没有回调机制——Agent A 把任务发给 Agent B然后 Agent A 就忘了这件事。priority和deadline多 Agent 系统中不是所有任务都同等重要。Agent 需要一个优先级队列来决定先做哪个。2. Status Update状态更新{task_id:uuid-xxxx,status:in_progress,progress:0.6,current_step:正在分析第 3/5 个文件,estimated_completion:2026-05-08T11:55:00Z,timestamp:2026-05-08T11:50:00Z}书里强调**状态更新不是可选的锦上添花而是多 Agent 系统稳定的必要条件。**如果任务发起方不知道执行方的进度它就无法判断任务是否卡住了决定是否需要启动备选方案给用户一个合理的等待预期3. Result结果{task_id:uuid-xxxx,status:completed,result:{findings:[...],summary:发现 3 个安全问题2 个性能问题},artifacts:[review-report-20260508.md],execution_metadata:{start_time:2026-05-08T11:45:00Z,end_time:2026-05-08T11:52:00Z,tokens_used:4500,tools_called:[ast_analyzer,bandit_scanner]}}execution_metadata这个字段我很喜欢——在生产环境中你不可能只看最终结果。当系统出问题时你需要知道这个 Agent 用了多少 token、调了哪些工具、跑了多长时间。这些数据是做成本分析和性能优化的基础。A2A 的状态机书里画了一个 A2A 任务的状态转换图CREATED → QUEUED → IN_PROGRESS → COMPLETED ↓ FAILED (可重试) ↓ CANCELLED (不可重试)每个状态转换都触发一个事件事件的消费者可以是任务发起方知道任务完成了监控系统记录任务耗时和成功率编排器根据结果决定下一步四、共享记忆多个 Agent 怎么知道同一件事这是多 Agent 系统中最微妙的部分。回顾我之前的运维三人组——巡检 Agent 发现的问题、告警 Agent 生成的告警、修复 Agent 执行的操作三者之间没有共享记忆。每个 Agent 活在自己的信息孤岛里。共享记忆的三种模式书里对比了三种共享记忆的实现方式模式 A中心化记忆存储所有 Agent → 共享记忆服务器Redis/PostgreSQL优点简单所有 Agent 看到的是同一份数据。缺点单点故障高频读写会成瓶颈不同 Agent 的读写冲突需要处理。模式 B分布式消息传递Agent A → 消息队列 → Agent BB 自己维护本地记忆优点解耦Agent 之间不直接依赖。缺点消息可能丢失或重复Agent B 的本地记忆可能与 Agent A 不一致。模式 C混合模式书里推荐热点数据 → 本地缓存 持久数据 → 中心化存储 事件通知 → 消息队列关键设计高频读取的共享状态比如当前任务进度缓存在各 Agent 本地低频但需要持久化的数据比如历史巡检报告存在中心化数据库状态变更事件通过消息队列广播给所有相关 Agent一致性问题多 Agent 共享记忆面临的最大挑战不是怎么存而是怎么保证多个 Agent 看到的是一致的数据。书里给了一个具体的例子Agent A 读取服务器当前状态为正常Agent B 同时写入服务器当前状态为异常Agent A 基于正常这个过时数据做了一个错误的决策解决方案乐观锁 版本号。# 读取时带上版本号memory_recordshared_memory.read(server-status,version5)# 写入时检查版本号ifshared_memory.write(server-status,new_value,expected_version5):# 写入成功版本号更新为 6passelse:# 版本冲突——被别人抢先写入了需要重新读取memory_recordshared_memory.read(server-status)# 获取最新版本# 重新做决策这个设计看起来简单但在多 Agent 并发环境中是防止数据不一致的第一道防线。五、Human-in-the-Loop不是加个确认按钮我之前对 Human-in-the-Loop 的理解就是在关键操作之前弹一个确认执行的按钮。书里告诉我这个理解太浅了。三种介入深度书里把人工介入分成了三个级别Level 1审批Approval人只在最后一步出现Agent 已经分析完了建议执行以下操作请确认。“这实际上是把人当成了最终确认按钮”。问题人到这一步已经失去了上下文。Agent 做了 10 步推理人只看到了最后一步的结论——凭什么判断对错Level 2审查Review人在关键中间节点介入。不是结果审查而是过程审查。Agent 每完成一个子任务就暂停并展示这一步做了什么为什么这样做当前的置信度下一步计划人可以选择(a) 批准继续(b) 修正方向© 中止任务。书里强调审查的时机比审查的内容更重要。如果你让 Agent 跑了 10 步再让人介入人已经没有能力判断前 9 步的对错了。介入点应该设在决策分叉处——Agent 面临多个选择、每个选择后果不同的地方。Level 3协作Collaboration人和 Agent 同时参与决策过程。不是Agent 做完了找人检查而是Agent 和人在每一步都在对话。书里举的例子Agent 发现了 5 个潜在的安全漏洞它不直接出修复方案而是把 5 个漏洞列出来附上自己的理解然后问人这 5 个中你觉得哪几个是真正的安全风险人标记了 3 个。Agent 再针对这 3 个出修复方案人再审查修复方案。这种模式的工作量最大但在高风险场景金融交易、医疗诊断、基础设施变更中是必须的。什么时候用哪一级书里给了一个判断框架风险等级示例建议介入深度低生成周报、整理文件Level 1 / 甚至无需介入中代码生成、数据分析Level 2关键步骤审查高生产环境变更、资金操作Level 3全程协作极高医疗、航空、核心基础设施不要用 Agent 自动执行六、评估体系比单 Agent 评估复杂一个数量级单 Agent 的评估相对直观——回答是否正确任务是否完成但多 Agent 系统的评估维度要多得多。书里给出的多 Agent 评估矩阵维度 1任务完成率Task Completion Rate最基础的指标。但书里强调多 Agent 场景下要分拆成两个子指标端到端完成率整个多 Agent 流程跑完并且结果可用的比例单 Agent 完成率每个 Agent 各自的子任务完成比例当你发现端到端完成率低时单 Agent 完成率能帮你定位是哪个 Agent 出了问题。维度 2任务分解准确率Decomposition Accuracy这是编排器/总控 Agent 的专属指标。它把用户的复杂任务拆成了子任务——拆得对不对有没有遗漏有没有过度拆分维度 3协作效率Collaboration Efficiency协作效率 有效协作轮次 / 总轮次如果 10 轮 Agent 间通信中只有 3 轮产生了有价值的协作传递了新信息或纠正了错误另外 7 轮是我收到了我正在处理这种状态更新——那你的通信设计就有问题。维度 4一致性Consistency同一个任务由不同的 Agent 组合执行结果是否一致书里做了一个实验用 3 个不同的 Orchestrator Agent 各带一组子 Agent 执行同一个代码审查任务——三组的结果差异高达 40%。这意味着你的多 Agent 系统的输出质量高度依赖于编排者是谁。维度 5失败模式归类书里建议对所有失败做结构化分类failure_categories{ORCHESTRATION_ERROR:编排器给错了任务,COMMUNICATION_ERROR:Agent 间消息丢失或格式错误,EXECUTION_ERROR:某个 Agent 自己的任务执行失败,TIMEOUT_ERROR:某个 Agent 超时未响应,STATE_INCONSISTENCY:共享状态不一致导致决策错误,HUMAN_INTERVENTION_TIMEOUT:等待人工确认超时}有了这个分类你才能知道你的多 Agent 系统到底在哪个环节容易崩溃。七、这本书最独特的部分框架设计师的内部视角这本书和其他 Agent 书籍最大的不同是作者在 LlamaIndex 做框架设计的经历。他花了整整一章讲框架设计的内部权衡——这些内容在一般的教程书里是看不到的。设计权衡 1灵活性 vs 易用性框架要提供多大的自由度给开发者完全的自由框架就没法做任何优化和防护。把每件事都封装好开发者就失去了对关键行为的控制。LlamaIndex 走过的路从高度抽象Agent 所有行为都被封装到分层暴露提供不同层次的 API。书里总结了一个框架设计的教训“当开发者不知道你的框架在做什么时他们不会感谢你帮他们省了代码——他们会换一个框架。”设计权衡 2MCP 集成 vs 原生工具框架要不要内置工具绑定内置了用户用得爽但是工具生态被锁定。不内置用户要自己配但是可以用任何工具。书里的结论**协议 绑定。**框架应该支持标准协议MCP让用户自由接入任何符合协议的工具而不是这个框架只支持这几家云厂商的 API。设计权衡 3状态管理放在哪Agent 的状态当前任务进度、中间结果、上下文窗口应该由框架管理还是由开发者管理框架管理的好处开发者不用操心。坏处出问题时开发者不知道去哪找状态数据。书里的建议框架管理机制开发者控制策略。框架提供标准的状态存储、读取、序列化 API但由开发者决定什么时候存、存什么、存多久。就像数据库——MySQL 提供存储引擎但建什么表、做什么索引由你决定。这些内容对直接写代码的人可能没有直接帮助但它回答了一个更深层的问题**为什么有些框架用着用着就觉得绑手绑脚**因为那些框架在设计时做了对你不利的权衡。八、7 个可以直接用到多 Agent 项目里的实践读完这本书之后我重新设计了运维三人组以下是改了什么从顺序编排改为并发 协作混合。巡检由三个专业化子 Agent 并行执行CPU/内存/磁盘各一个结果聚合后再由分析 Agent 做协作式诊断。加了接力棒协议。每个 Agent 传递结果时必须附带上下文摘要——做了什么决策、为什么、当前已知的限制。给了告警 Agentrequires_confirmation字段。任何触发修复的操作都要经过人工确认。凌晨 3 点的自动修复不会再发生。实现了共享记忆层。巡检结果、告警记录、修复操作全部存在中心化存储中每个 Agent 在行动前先查有没有人已经做过这件事。加入了 A2A 风格的状态更新。编排 Agent 可以实时看到每个子 Agent 的进度而不是发出去就等着。所有失败都有结构化分类。不是出错了三个字而是ORCHESTRATION_ERROR/EXECUTION_ERROR/TIMEOUT_ERROR等精确分类。层级不超过两层。书里的建议我记得很清楚——三层以上的层级编排是调试地狱。我把所有子 Agent 扁平化为两层一个编排层 一组执行层。九、这本书的边界这本书适合你如果你已经写过单 Agent现在需要扩展到多 Agent你对 A2A 协议想知道的不只是是什么还有怎么用你想了解框架设计者在做多 Agent 支持时面临哪些技术取舍你需要一套完整的多 Agent 评估体系而不是靠看着好像还不错来判断这本书不适合你如果你还没写过单 Agent——先去读第一本这本是进阶你已经在生产环境深度使用 CrewAI 或 AutoGen并且觉得够用——这本书的观点可能和你现有的架构有冲突你只在做两个 Agent 以下的简单协作——这本书的很多复杂度是为 5 Agent 场景准备的这本书没讲到但很重要的企业级 Agent 的部署和运维——容器化、监控、CI/CD 集成成本优化——多 Agent 系统的 token 消耗比单 Agent 大得多如何控制成本安全——Agent 间通信的加密和鉴权写在最后读完这本书我最大的感受是多 Agent 系统的复杂度80% 在 Agent 外部。Agent 内部怎么推理、怎么调用工具、怎么管理记忆——这些问题在单 Agent 阶段已经解决了。多 Agent 阶段真正难的是怎么让 Agent 互相发现对方怎么定义任务怎么分配怎么保证信息在传递中不丢失不扭曲怎么在多个 Agent 同时操作同一份数据时不出错怎么在出问题的时候快速定位是哪个环节崩了作者在前言里写了句话大意是“单 Agent 像一个聪明的人在独自工作。多 Agent 系统像一个团队——而管理一个团队比做一个聪明的人难得多。”这本书就是教你怎么管理一个 AI 团队。书名《Build a Multi-Agent System (from Scratch)》作者Val Andrei Fajardo前 LlamaIndex 创始工程师Vector Institute 研究员出版社Manning Publications, 2026适合读者有单 Agent 开发经验需要扩展到多 Agent 系统的开发者下一篇预告读《AI Agents in Action》第二版——为什么 90% 的 Agent 项目死在从 Demo 到生产的路上。