《Agentic Design Patterns》第 7 章导读：多智能体协作（Multi-Agent Collaboration）-育师

《Agentic Design Patterns》第 7 章导读：多智能体协作（Multi-Agent Collaboration）

本文是对开源书籍《Agentic Design Patterns》第 7 章的解读与导读，内容忠实呈现原文，并附个人思考。
原书在线阅读：https://adp.xindoo.xyz/ ｜翻译项目代码仓库：https://github.com/xindoo/agentic-design-patterns

前六章我们聊的都是"单个智能体怎么变强"——提示词链让它会分步做事，路由让它会选路，并行化让它跑得快，反思让它会纠错，工具使用让它能向外扩展，规划让它有谋略。但单个智能体再强，也有天花板。

就像一个人再能干，也不可能同时是最好的研究员、最好的程序员、最好的设计师和最好的产品经理。复杂任务本质上需要多种专业能力协作完成。这就是第 7 章要讲的**多智能体协作（Multi-Agent Collaboration）**模式——让多个各有所长的智能体一起干活，实现 1+1 > 2 的效果。

一、为什么需要多智能体：单智能体的能力边界

书中开篇就点出了核心矛盾：单体智能体面对复杂的多领域任务时，能力往往不够用。

比如你要做一份深度行业研究报告，这件事涉及：

搜索和筛选大量文献资料；
从不同维度分析数据；
把零散信息整合成连贯的叙述；
校对事实、润色文字、排版输出。

让一个智能体全包？它很可能顾此失彼——搜索做得不错，但分析深度不够；分析到位了，写作又差点意思。而且单智能体同时处理太多角色，还容易出现"角色混乱"导致的质量下降。

多智能体协作的思路就是任务分解 + 专业分工：把大目标拆成子问题，每个子问题分配给最擅长的智能体。研究的只管研究，分析的只管分析，写作的只管写作——就像人类团队一样。

图 1：多智能体系统示例——多个专门化智能体协同工作，各自承担不同职责。

这种分布式架构有几个天然优势：

模块化：每个智能体职责单一，容易设计和调试；
可扩展性：新增能力 = 新增智能体，不用改现有系统；
健壮性：单个智能体故障不一定拖垮整个系统；
协同效应：整体性能超过任何单个智能体。

二、六种协作模式：智能体之间怎么配合

多智能体不是"把多个智能体扔在一起"就行。它们之间怎么分工、怎么通信、怎么协调，直接决定了系统的效率和效果。书中总结了六种主要协作形式：

协作模式	运作方式	典型场景
顺序交接	一个智能体做完交给下一个，像流水线	内容生产：研究 → 写作 → 编辑
并行处理	多个智能体同时干不同部分，最后汇总	信息收集：多个来源并发检索
辩论与共识	持不同观点的智能体通过讨论达成一致	决策场景：多方评估、风险研判
层次结构	管理者智能体向下分配任务、综合结果	复杂项目：主管 + 多个执行智能体
专家团队	不同领域专家协作产出复杂结果	产品开发：研究员 + 工程师 + 设计师
批评者-审查者	生成者产出，批评者审查，生成者再修订	代码/写作：初稿 → 审查 → 修订

其中，批评者-审查者模式特别值得注意。它的思路是：一个智能体负责"做"，另一组智能体负责"挑毛病"——从政策合规、安全性、正确性、质量等多个维度审查。原始生成者根据反馈修订，几轮下来质量会显著提升。这种模式对代码生成、研究写作、逻辑检查特别有效，能大幅减少幻觉和错误。

三、通信模型：从单体到自定义架构

协作的核心是通信。智能体之间怎么交互、信息怎么流动，是多智能体系统设计的关键问题。书中梳理了六种典型的通信/组织模型，复杂度逐级递增：

图 2：智能体通信与交互模型——从单智能体到自定义架构，复杂度逐级提升。

1. 单智能体
最基础的形态，自主运行，不跟其他智能体交互。好处是简单好管，坏处是能力天花板明显。适合可以独立完成的子任务。

2. 网络（Network）
多个智能体以去中心化方式点对点通信，共享信息、资源甚至任务。弹性好——一个挂了不影响全局。但问题是：大型网络的通信开销大，决策一致性难保证。

3. 监督者（Supervisor）
一个专门的"监督者"智能体管一群下属，负责任务分配、通信协调、冲突解决。层次清晰、管理方便。但监督者本身成了单点故障——它要是挂了，整个系统就瘫了；任务太多时，它还可能成为瓶颈。

4. 监督者作为工具（Supervisor as Tool）
监督者不直接发号施令，而是提供资源、工具、分析支持，帮其他智能体更好地完成任务。保留了监督者的能力优势，但减少了自上而下的控制感。

5. 层次化（Hierarchical）
多层组织结构：高级监督者管低级监督者，低级监督者管执行智能体。适合可以层层分解的复杂问题，扩展性好，能在边界内做分布式决策。

6. 自定义（Custom）
根据具体问题量身定制的混合架构。可能是上面几种模型的组合，也可能是全新设计。灵活性最高，但设计难度也最大——需要深入理解多智能体系统，仔细考虑通信协议、协调机制和涌现行为。

怎么选？书中给出的判断维度是：任务复杂度、智能体数量、期望的自主程度、对健壮性的需求、可接受的通信开销。没有最好的模型，只有最适合的。

四、应用场景：哪些任务适合多智能体

书中列举了 7 个典型应用领域：

复杂研究与分析：研究智能体查资料、分析智能体处理数据、综合智能体写报告——模拟人类研究团队的运作方式。
软件开发：需求分析师 + 代码生成器 + 测试员 + 文档编写者，各管一段，互相传递产出。
创意内容生成：市场研究 + 文案撰写 + 图像生成 + 社交媒体调度，协作完成完整的营销活动。
财务分析：数据获取 + 新闻情绪分析 + 技术分析 + 投资建议，多个专门智能体共同输出决策支持。
客户支持升级：前线智能体处理常规问题，复杂的升级给技术专家或计费专家——按复杂度逐级交接。
供应链优化：代表不同节点（供应商、制造商、分销商）的智能体协作，动态响应需求变化和中断。
网络分析与修复：多个智能体协同定位和修复故障，还能与传统 ML 模型和工具集成。

本质上，只要任务能拆成需要不同专业技能的子任务，或者包含多个离散阶段，多智能体协作就能发挥价值。

五、实操示例：Crew AI 的博客创作团队

书中用 Crew AI 演示了一个最简单的双智能体协作场景——研究员 + 作家联手写一篇 AI 趋势博客。

fromdotenvimportload_dotenvfromcrewaiimportAgent,Task,Crew,Processfromlangchain_google_genaiimportChatGoogleGenerativeAI load_dotenv()llm=ChatGoogleGenerativeAI(model="gemini-2.0-flash")# 智能体 1：研究员researcher=Agent(role='高级研究分析师',goal='查找并总结 AI 的最新趋势。',backstory="你是一位经验丰富的研究分析师，擅长识别关键趋势和综合信息。",verbose=True,allow_delegation=False,)# 智能体 2：作家writer=Agent(role='技术内容作家',goal='基于研究发现撰写清晰且引人入胜的博客文章。',backstory="你是一位熟练的作家，可以将复杂的技术主题转化为易于理解的内容。",verbose=True,allow_delegation=False,)# 任务定义research_task=Task(description="研究 2024-2025 年人工智能中出现的前 3 个趋势。重点关注实际应用和潜在影响。",expected_output="前 3 个 AI 趋势的详细摘要，包括关键点和来源。",agent=researcher,)writing_task=Task(description="基于研究发现撰写一篇 500 字的博客文章。文章应该引人入胜且易于普通读者理解。",expected_output="一篇关于最新 AI 趋势的完整 500 字博客文章。",agent=writer,context=[research_task],# 写作任务依赖研究任务的输出)# 组建团队，顺序执行blog_creation_crew=Crew(agents=[researcher,writer],tasks=[research_task,writing_task],process=Process.sequential,llm=llm,)result=blog_creation_crew.kickoff()print(result)

这段代码展示了多智能体协作的基本骨架：

定义每个智能体的角色、目标、背景故事——给它一个清晰的"身份"；
定义每个任务，并指定负责的智能体；
用context建立任务间的依赖关系；
用Crew把它们组织起来，指定执行流程。

六、Google ADK 中的多智能体模式

书中还展示了 Google ADK 框架中几种更结构化的多智能体模式，每个都对应一个专门的 Agent 类型：

层次化智能体——父子关系：

fromgoogle.adk.agentsimportLlmAgent,BaseAgent# 子智能体1：欢迎员greeter=LlmAgent(name="Greeter",model="gemini-2.0-flash-exp",instruction="你是一个友好的欢迎者。")# 子智能体2：任务执行者classTaskExecutor(BaseAgent):name:str="TaskExecutor"# ... 自定义执行逻辑# 父智能体：协调者coordinator=LlmAgent(name="Coordinator",model="gemini-2.0-flash-exp",instruction="欢迎委托给 Greeter，任务执行委托给 TaskExecutor。",sub_agents=[greeter,task_doer]# 建立父子关系)

顺序智能体（SequentialAgent）——线性流水线：

fromgoogle.adk.agentsimportSequentialAgent,LlmAgent step1=LlmAgent(name="Step1_Fetch",output_key="data",model="gemini-2.0-flash-exp")step2=LlmAgent(name="Step2_Process",instruction="分析 state['data'] 中的信息并提供摘要。",model="gemini-2.0-flash-exp")pipeline=SequentialAgent(name="MyPipeline",sub_agents=[step1,step2])

并行智能体（ParallelAgent）——并发执行：

fromgoogle.adk.agentsimportLlmAgent,ParallelAgent weather_fetcher=LlmAgent(name="weather_fetcher",output_key="weather_data",...)news_fetcher=LlmAgent(name="news_fetcher",output_key="news_data",...)data_gatherer=ParallelAgent(name="data_gatherer",sub_agents=[weather_fetcher,news_fetcher])

智能体作为工具（Agent as Tool）——把智能体包装成工具供其他智能体调用：

fromgoogle.adk.toolsimportagent_tool image_generator_agent=LlmAgent(name="ImageGen",tools=[generate_image],...)# 把智能体包装成工具image_tool=agent_tool.AgentTool(agent=image_generator_agent,description="使用此工具生成图像。")# 父智能体像调用普通工具一样调用子智能体artist_agent=LlmAgent(name="Artist",tools=[image_tool],# 子智能体变成了一个工具...)

这几种模式正好对应前面讲的协作形态——顺序交接、并行处理、层次结构，而"智能体作为工具"则是一种特别优雅的封装方式：对上层智能体来说，下层智能体和普通工具没有区别，都是可以调用的能力。

七、速览

问题背景：复杂问题往往超出单个智能体的能力范围——单体智能体缺乏多样化的专业技能和工具访问权限，处理多领域任务时效率低下，结果不完整或次优。
解决方案：多智能体协作模式通过创建多个协作智能体的系统来解决问题。复杂问题被分解为更小的子问题，每个子问题分配给有对应专长的智能体。智能体通过精心设计的通信协议和交互模型（顺序交接、并行工作流、层次化委托等）协同工作，产生协同效应。
实践建议：当任务对于单个智能体太复杂、且可以分解为需要不同专业技能或工具的子任务时，使用此模式。特别适合需要多样化专业知识、并行处理或多阶段结构化工作流的问题，如复杂研究分析、软件开发、创意内容生成等。

八、可视化总结

图 3：多智能体模式——多个专门化智能体通过协作实现共同目标。

关键要点

多智能体协作涉及多个智能体协同工作以实现共同目标；
此模式利用专业角色、分布式任务和智能体间通信；
协作形式包括顺序交接、并行处理、辩论共识、层次结构等；
适合需要多样化专业知识或多个不同阶段的复杂问题。

结语与个人思考

多智能体协作是一个很自然的想法——既然人类社会靠分工协作变得强大，AI 为什么不可以？但真正做起来，挑战比想象中多。

第一个挑战是通信成本。智能体之间传信息、对齐理解、协调步调，这些都有开销。智能体数量越多，通信的复杂度可能呈指数增长。这也是为什么"网络"模式虽然弹性最好，但实际用得最多的反而是"层次化"——因为层次结构天然限制了通信范围，每个智能体只需要跟自己的上级和下级打交道。

第二个挑战是角色设计。给每个智能体分配什么角色、边界在哪里，直接影响协作效率。角色太粗，等于又回到了单智能体；角色太细，通信和协调成本又会飙升。这里没有标准答案，得根据具体任务反复调试。书中提到的"批评者-审查者"模式是一个很实用的设计模式——把"生成"和"评估"分开，比让同一个智能体"边做边自查"效果好得多。

第三个挑战是质量保证。多智能体系统的输出质量不是各智能体质量的简单相加。如果协作机制设计不好，可能出现"三个和尚没水喝"的情况——每个智能体都觉得别人会做，或者都在等别人的输出。这也是为什么框架（Crew AI、Google ADK 等）很重要——它们提供了结构化的方式来定义角色、任务和依赖关系，减少了"协作摩擦"。

最后，我觉得多智能体协作最有魅力的地方在于涌现性——当多个智能体以某种方式互动时，可能会产生单个智能体不可能有的行为和能力。但涌现也是把双刃剑，好的涌现是"三个臭皮匠顶个诸葛亮"，坏的涌现可能是"互相甩锅"或"集体跑偏"。怎么设计出能产生好的涌现、抑制坏的涌现的协作机制，可能是多智能体领域最有意思的问题。