AI 智能体 - 多智能体模式

在人工智能的演进历程中，我们正经历从“全能天才”向“专家团队”的范式转变。

在早期的大语言模型（LLM）应用中，我们试图构建一个“超级智能体”——一个无所不知、无所不能的单体系统，既能写代码，又能做市场调研，还能处理客户投诉。然而，现实很快给了我们教训：当任务的上下文过长、领域跨度过大或逻辑链条过深时，单体智能体会陷入“认知过载”，导致幻觉频发、指令遗漏或逻辑崩塌。

正如人类社会通过分工协作创造了现代文明，AI 的未来也不在于单个模型的参数无限堆叠，而在于多智能体协作（Multi-Agent Collaboration）。

本篇将带您深入探索这一核心架构模式。我们将揭示如何通过任务分解、角色专业化和标准化的通信协议，将一群能力有限的智能体组装成一个超越个体总和的强大系统。

第一部分：从单打独斗到协同作战

1.1 单智能体的“天花板”

单智能体（Single Agent）在处理线性、定义明确的任务时表现出色，例如“帮我总结这封邮件”或“查询明天的天气”。但当我们面对复杂的跨领域任务时，单智能体的局限性暴露无遗：

• 上下文窗口限制： 复杂的任务往往伴随着海量的背景信息，容易撑爆模型的上下文窗口。

• 角色混淆： 要求同一个智能体既像律师一样严谨，又像广告人一样富有创意，往往会导致输出风格的不伦不类。

• 工具权限风险： 赋予一个智能体所有工具的权限（数据库读写、API 调用、代码执行）带来了巨大的安全隐患。

• 单点故障： 如果唯一的智能体在推理链的中间环节出错，整个任务就会彻底失败。

1.2 多智能体系统的核心哲学

多智能体系统（Multi-Agent Systems, MAS）的核心哲学是 “分而治之”。它不再追求单一模型的全能，而是通过组织架构的设计，让一组各司其职的智能体协同工作。

这种模式不仅是技术的堆叠，更是管理学的延伸。它包含三个关键要素：

1. 任务分解（Decomposition）： 将高层次的复杂目标（如“开发一款 App”）拆解为独立的子问题（如“需求分析”、“UI 设计”、“后端开发”、“测试”）。

2. 角色专精（Specialization）： 每个智能体被赋予特定的人设、工具集和数据权限。研究员智能体只能使用搜索引擎，数据库管理员智能体只能查询 SQL。

3. 通信机制（Communication）： 建立标准化的协议，让智能体之间能够交换数据、传递状态、甚至进行辩论。

协同效应（Synergy） 是 MAS 的终极目标。一个由平庸模型组成的良好协作系统，往往能击败一个由顶尖模型组成的混乱单体系统。

第二部分：六大协作模式与实战场景

多智能体并非简单的“把智能体放在一起”。根据任务的性质，我们需要设计不同的协作拓扑结构。以下是六种最经典的协作模式及其在现实业务中的映射。

2.1 顺序交接（The Pipeline / Sequential Handoff）

这是最基础也最常见的模式，类似于工厂的流水线。一个智能体的输出直接成为下一个智能体的输入。

• 工作流： Agent A $\to$ Output A $\to$ Agent B $\to$ Output B $\to$ Result。

• 适用场景： 任务具有明确的先后依赖关系。

🎬 实战案例：全自动内容出版流水线

想象一家媒体公司需要每天发布行业新闻。

1. 猎手智能体（Topic Hunter）： 监控全网热点，筛选出 Top 5 最具价值的新闻线索。

2. 研究智能体（Researcher）： 针对线索进行深度事实核查，搜集背景资料和数据。

3. 撰稿智能体（Writer）： 基于研究资料，撰写一篇风格犀利的深度文章。

4. SEO 智能体（SEO Expert）： 优化文章标题、关键词和元描述。

5. 排版智能体（Formatter）： 将文章转换为 Markdown 或 HTML 格式，并配图。

在这个链条中，没有任何一个智能体需要了解全流程，它们只需专注于自己的“工位”。

2.2 并行处理（Parallel Processing）

类似于分布式计算中的 Map-Reduce。多个智能体同时处理同一任务的不同部分，最后由一个主节点汇总。

• 工作流： Manager 分配 $\to$ {Agent A, Agent B, Agent C} 同时工作 $\to$ Manager 汇总。

• 适用场景： 任务可以被水平拆分，且各部分之间无强依赖。

⚖️ 实战案例：企业尽职调查（Due Diligence）

一家风投机构需要对一家初创公司进行快速评估。

1. 财务审计智能体： 并行分析该公司过去三年的财报，计算现金流和利润率。

2. 法务合规智能体： 并行检索该公司的诉讼记录、知识产权归属和合规风险。

3. 技术评估智能体： 并行扫描该公司的 GitHub 代码库和技术栈架构。

4. 市场舆情智能体： 并行分析社交媒体上的用户评价和竞品对比。

5. 投资经理智能体（汇总）： 等待上述四个智能体全部完成后，综合所有信息，生成一份“投资风险评估报告”。

这种模式将原本需要数天的串行工作压缩到了分钟级。

2.3 辩论与共识（Debate & Consensus）

引入“对抗”机制。不同视角的智能体通过讨论、反驳，最终达成更可靠的结论。

• 工作流： Agent A 提议 $\leftrightarrow$ Agent B 反驳/修正 $\to$ 达成一致。

• 适用场景： 开放性问题、高风险决策、需要减少幻觉的场景。

🏛️ 实战案例：AI 模拟法庭或战略委员会

企业面临一个艰难决策：是否要进军东南亚市场？

1. 激进派智能体（CEO Persona）： 强调市场增长潜力、先发优势，列举乐观数据。

2. 保守派智能体（CFO Persona）： 强调汇率风险、供应链成本、监管陷阱，列举悲观数据。

3. 主持人智能体（Moderator）： 引导辩论，要求双方提供证据，最后总结出一份包含“风险-收益”平衡的最终建议书。

通过模拟这种人类的决策博弈，系统能有效避免单方面信息的偏差。

2.4 层级结构（Hierarchical / Manager-Worker）

建立类似公司组织的汇报关系。上级智能体负责规划和分派，下级智能体负责执行。

• 工作流： Manager 拆解任务 $\to$ 动态分配给 Worker A/B/C $\to$ 验收结果。

• 适用场景： 任务复杂且动态，无法预先定义死板的流水线。

💻 实战案例：自主软件开发组

用户需求：“帮我做一个贪吃蛇游戏。”

1. 产品经理智能体（PM）： 分析需求，将其拆解为“核心逻辑”、“UI 界面”、“输入控制”三个模块。它发现需要编写代码，于是呼叫下级。

2. Tech Lead 智能体： 接收 PM 的需求，决定技术栈（Python + Pygame），并将任务进一步指派给具体的程序员。

3. 程序员智能体 A： 负责编写蛇的移动逻辑。

4. 程序员智能体 B： 负责绘制界面。

5. 测试智能体： 运行代码，报错，将错误反馈给 Tech Lead，由其决定让谁去修 Bug。

2.5 专家团队（Joint Expert Team）

由不同领域的专家智能体组成的跨职能小组（Squad），通常结合了顺序和并行模式。

🏥 实战案例：复杂医疗诊断辅助

1. 分诊智能体： 初步分析病人症状，组建专家组。

2. 影像学专家智能体： 分析 CT/MRI 扫描图。

3. 病理学专家智能体： 分析血液化验单。

4. 药理学专家智能体： 检查病人当前用药的相互作用。

5. 主治医师智能体： 综合以上专家的意见，给出诊断建议和治疗方案。

2.6 评审者模式（Reviewer / QA Pattern）

引入专门的“质检员”，用于确保输出符合特定标准（安全、合规、代码质量）。

• 工作流： Generator 生成 $\to$ Reviewer 审查 $\to$ (如果不通过) Generator 修改。

• 适用场景： 代码生成、法律文书撰写、高安全性内容生成。

🛡️ 实战案例：安全代码生成

1. 开发者智能体： 编写一段 SQL 查询代码。

2. 安全审计智能体： 审查代码是否存在 SQL 注入风险。如果发现风险，驳回并附带修改建议。

3. 开发者智能体： 根据建议修改代码。

4. 安全审计智能体： 再次审查，直至通过。

第三部分：智能体通信拓扑图谱

理解了模式，我们需要从架构角度看智能体是如何“连接”的。从最简单到最复杂，存在一个通信结构的谱系。

3.1 孤岛模式（Single Agent）

• 结构： 只有自己。

• 特点： 独立运行，无交互。

• 评价： 简单，但能力封顶。

3.2 网络模式（Network / P2P）

• 结构： 去中心化，智能体之间点对点直接连接。

• 特点： Agent A 可以直接呼叫 Agent B。

• 优点： 弹性高，无单点瓶颈。

• 缺点： 随着节点增加，通信复杂度呈指数级上升，容易陷入死循环或混乱。

3.3 监督者模式（Supervisor）

• 结构： 星型拓扑。一个中心化的监督者连接所有执行者。

• 特点： 所有通信都经过 Supervisor。Supervisor 决定谁该说话，谁该做事。

• 优点： 易于管理，状态清晰，逻辑可控。

• 缺点： Supervisor 成为单点故障和性能瓶颈。如果 Supervisor 的推理能力不足，整个系统就会变蠢。

3.4 监督者即工具（Supervisor as a Tool）

• 结构： 这是一种微妙的变体。监督者不再微观管理每一步，而是像使用“计算器”一样使用其他智能体。

• 特点： 主智能体将子智能体视为一种“高级工具”。例如，“通过调用‘搜索智能体’来获取信息”，而不是“命令搜索智能体去搜索”。

• 优点： 降低了控制的僵化度，赋予了主智能体更多的资源灵活性。

3.5 层级模式（Hierarchical）

• 结构： 树状结构。大老板管中层，中层管基层。

• 特点： 每一层只处理自己层级的抽象问题。

• 优点： 可扩展性极强，适合处理超大规模的复杂任务（如管理整个公司的运作）。

3.6 自定义模式（Custom）

• 结构： 混合体。根据业务逻辑定制的图（Graph）。

• 特点： 可能包含循环、条件跳转、并行分支等复杂逻辑。

• 实现： 通常使用 LangGraph 等基于图的框架来实现。

四种核心交互协议

基于之前讨论的智能体通信拓扑图谱（如网络模式、监督者模式、层级模式），要让这些架构真正运转起来，智能体之间必须有一套交互协议（Interaction Protocols）。

这就好比人类社会有了组织架构（拓扑），还需要决定是“发微信语音”（非结构化）、“填 Excel 表”（结构化）还是“开共享文档”（共享状态）来沟通。

以下是当前 Agent 开发中主流的 4 种核心交互协议，以及它们对应的实际落地案例：

1. 自然语言消息传递协议 (Natural Language Message Passing)

——“像人类一样聊天”

这是最基础、最直观的协议。智能体之间通过纯文本（System Prompt + User Message）进行对话。一个智能体的输出（文本）直接成为另一个智能体的输入。

• 对应拓扑： 网络模式 (Network/P2P)、辩论模式 (Debate)。

• 核心机制：

• 无预定义结构： 内容自由，依赖 LLM 的理解能力。

• 角色扮演： 接收方通过 Prompt（如“你是一个反方辩手”）来理解对方的文本意图。

🏢 实际案例：模拟法庭 / 创意风暴

场景： 一家广告公司需要评估一个有争议的广告创意是否合规且有吸引力。

• Agent A (创意总监)： “我觉得这个广告应该用黑红配色，文案要激进一点，比如……”（输出一段纯文本描述）。

• Agent B (法务顾问)： 收到 A 的文本，回复：“反对。根据广告法第 X 条，激进文案涉及虚假宣传风险。建议修改为……”

• Agent C (用户代表)： 收到 A 的文本，回复：“我觉得颜色太压抑了，不喜欢。”

• 交互过程： 这是一个非结构化的多轮对话，最终由主理人总结。

• 优点： 灵活性极高，适合创意、头脑风暴。

• 缺点： 容易跑题，难以进行精确的参数传递（比如具体的日期或金额）。

2. 结构化指令协议 (Structured Schema / JSON Protocol)

——“按工单办事”

为了解决自然语言的模糊性，现代 Agent 系统（特别是监督者/层级模式）强制要求智能体使用 JSON 或 Pydantic 模型 进行通信。上级向下级发送指令时，必须符合特定的 Schema。

• 对应拓扑： 监督者模式 (Supervisor)、层级模式 (Hierarchical)。

• 核心机制：

• 严格契约： 发送方必须输出符合 Schema 的 JSON。

• 路由键： JSON 中通常包含 {"next_step": "Agent_B", "args": {...}}。

💻 实际案例：企业级软件开发流水线

场景： 一个自动化的软件开发团队。

• Agent A (产品经理 - Supervisor)： 接收用户需求“做一个贪吃蛇”。它不会发一段废话，而是输出严格的 JSON：

    {      "task_id": "snake_game_001",      "assigned_to": "Coder_Agent",      "requirements": {        "language": "python",        "lib": "pygame",        "features": ["score", "game_over"]      }    }

• Agent B (程序员)： 解析这个 JSON，提取 requirements，写代码，然后返回：

    {      "status": "success",      "code_path": "/src/main.py",      "test_result": "pass"    }

• 优点： 极其稳定，适合工程化落地，易于编程解析。

• 缺点： 丧失了一定的创造性，需要预定义 Schema。

3. 共享状态/黑板协议 (Shared State / Blackboard Pattern)

——“围着白板一起写”

这在 LangGraph 和 Google ADK 中最为核心。智能体之间不直接“发消息”，而是共同维护一个全局的状态对象（State Object）。

• 对应拓扑： 顺序交接 (Pipeline)、循环模式 (Loop)。

• 核心机制：

• 状态传递： 整个流程维护一个大字典（例如 State = {input: "", draft: "", critique: "", final: ""}）。

• 增量更新： Agent A 读 State，填入 draft；Agent B 读 draft，填入 critique。

📝 实际案例：深度研究报告生成 (LangGraph 经典案例)

场景： 生成一份关于“2025 AI 趋势”的万字长文。

1. 全局状态： 初始化为空字典 {"topic": "AI Trends", "outlines": [], "drafts": {}}。

2. Agent A (大纲规划师)： 读取 topic，生成大纲，更新状态：state["outlines"] = ["LLM Agent", "Multimodal", "Edge AI"]
   

3. Agent B (内容撰写者)： 读取 outlines，并行生成草稿，更新状态：state["drafts"] = {"LLM Agent": "text...", "Multimodal": "text..."}
   

4. Agent C (主编)： 读取 drafts，进行润色合并。

• 优点： 解决了长上下文传递问题，所有智能体都能看到“全局画面”，方便实现复杂的循环和回溯。

• 缺点： 状态管理复杂，需要处理并发写冲突。

4. 模型上下文协议 (Model Context Protocol - MCP)

——“通用的 USB 接口”

这是目前（2024-2025）最前沿的行业标准协议（由 Anthropic 等推动，OpenAI 和 Google 也在跟进）。它旨在解决“智能体如何连接数据源”的问题。

• 对应拓扑： 工具使用 (Tool Use)、监督者即工具 (Supervisor as a Tool)。

• 核心机制：

• 标准化接口： 不再需要为每个数据库写特定的 Python Tool 代码。

• 服务器-客户端模式： 数据源（如 Google Drive, Slack, 数据库）作为 MCP Server，智能体作为 MCP Client。

🔌 实际案例：跨应用的企业知识库问答

场景： 一个智能体需要同时查阅 Slack 聊天记录、GitHub 代码库和 Notion 文档来回答问题。

• 传统方式： 开发者需要手写 3 个不同的 Tool 函数，分别对接 Slack API, GitHub API, Notion API。

• MCP 协议方式：

• 企业部署了三个标准的 MCP Servers（分别对应 Slack, GitHub, Notion）。

• Agent： 通过 MCP 协议自动“发现”这三个服务器提供的资源（Resources）和工具（Tools）。

• 交互： Agent 发送标准化的 MCP 请求（类似 USB 插拔），直接读取数据，无需开发者为每个 Agent 重新写集成代码。

• 优点： 极大的互操作性，“一次编写，到处运行”。

• 缺点： 需要生态支持，目前正在快速普及中。

总结：如何选择？

最主流的趋势： 目前高水平的 Agent 开发（如 LangGraph）通常是 “共享状态 (State)” + “结构化指令 (Schema)” 的结合体。即：智能体之间通过修改全局状态来同步信息，但在修改状态时，必须输出结构化的数据以确保程序的健壮性。

第四部分：实战代码深度解析

我们将通过 Python 代码，演示如何使用 CrewAI 和 Google ADK 这两个主流框架来实现上述协作模式。

4.1 CrewAI 实战：打造“全栈内容创作团队”

CrewAI 是一个基于角色的高层框架，非常适合快速构建顺序流（Pipeline）协作。

import osfrom dotenv import load_dotenvfrom crewai import Agent, Task, Crew, Processfrom langchain_google_genai import ChatGoogleGenerativeAI
# 1. 环境配置def setup_environment():   load_dotenv()   if not os.getenv("GOOGLE_API_KEY"):       raise ValueError("请在 .env 文件中设置 GOOGLE_API_KEY。")
def main():   setup_environment()      # 使用 Gemini 2.0 Flash 作为大脑   llm = ChatGoogleGenerativeAI(model="gemini-2.0-flash")
   # 2. 定义智能体 (Agents)   # 关键点：赋予清晰的角色(Role)、目标(Goal)和背景故事(Backstory)      # 角色1：资深研究员   researcher = Agent(       role='资深研究分析师',       goal='发现并总结 AI 领域的最新趋势。',       backstory="你是一位敏锐的分析师，擅长从海量信息中提炼关键趋势和数据。",       verbose=True,       allow_delegation=False, # 不允许它把活儿外包给别人       llm=llm   )
   # 角色2：技术作家   writer = Agent(       role='技术内容作家',       goal='基于研究结果，撰写引人入胜的博客文章。',       backstory="你擅长将晦涩的技术术语转化为通俗易懂的文字。",       verbose=True,       allow_delegation=False,       llm=llm   )
   # 3. 定义任务 (Tasks)   # 关键点：任务必须具体，并指定由哪个 Agent 负责      research_task = Task(       description="调研 2024-2025 年人工智能的三大新兴趋势。关注实际应用和潜在影响。",       expected_output="一份关于三大 AI 趋势的详细摘要，包含关键点和信息来源。",       agent=researcher,   )
   writing_task = Task(       description="基于研究结果，写一篇 500 字的博客。内容要有趣，适合大众阅读。",       expected_output="一篇完整的 500 字博客文章。",       agent=writer,       context=[research_task], # 关键：声明依赖关系！Writer 依赖 Researcher 的输出。   )
   # 4. 组建团队 (Crew)   # 关键点：Process.sequential 表示按顺序执行任务   blog_creation_crew = Crew(       agents=[researcher, writer],       tasks=[research_task, writing_task],       process=Process.sequential, # 顺序协作模式       llm=llm,       verbose=True   )
   # 5. 启动协作   print("## 启动创作团队... ##")   try:       result = blog_creation_crew.kickoff()       print("\n## 最终成果 ##")       print(result)   except Exception as e:       print(f"发生错误: {e}")
if __name__ == "__main__":   main()

代码解析：

• 这段代码完美展示了顺序交接模式。

• context=[research_task] 是协作的桥梁，它告诉框架：在执行写作任务时，必须自动将研究任务的输出注入到作家的上下文中。作家智能体不需要自己去搜索，它直接“拿到”了研究员的成果。

4.2 Google ADK 实战：构建层级与循环结构

Google ADK（Agent Development Kit）提供了更底层的控制能力，适合构建复杂的层级和状态机逻辑。

场景一：层级结构（父子智能体）

这是一个典型的 Supervisor 模式实现。

from google.adk.agents import LlmAgent, BaseAgentfrom google.adk.agents.invocation_context import InvocationContextfrom google.adk.events import Eventfrom typing import AsyncGenerator
# 1. 自定义“执行者”智能体（非 LLM）# 这是一个“实干家”，执行具体的代码逻辑，而非生成文本class TaskExecutor(BaseAgent):   name: str = "TaskExecutor"   description: str = "执行预定义的系统任务。"
   async def _run_async_impl(self, context: InvocationContext) -> AsyncGenerator[Event, None]:       # 这里可以放置数据库写入、API调用等硬逻辑       yield Event(author=self.name, content="任务执行成功：系统状态已更新。")
# 2. 定义 LLM 子智能体greeter = LlmAgent(   name="Greeter",   model="gemini-2.0-flash-exp",   instruction="你是一个友好的迎宾员，负责问候用户。")
# 实例化自定义智能体task_doer = TaskExecutor() 
# 3. 定义“协调者”父智能体 (Supervisor)# 它的核心职责是：路由。根据用户意图，决定呼叫 Greeter 还是 TaskExecutorcoordinator = LlmAgent(   name="Coordinator",   model="gemini-2.0-flash-exp",   description="一个负责问候和执行任务的协调员。",   instruction="当用户打招呼时，委派给 'Greeter'。当用户要求执行任务时，委派给 'TaskExecutor'。",   sub_agents=[       greeter,       task_doer   ])
# ADK 框架会自动处理 coordinator 对 sub_agents 的调用逻辑print("层级智能体系统构建完成。")

场景二：循环工作流（LoopAgent）

这个模式展示了如何通过状态轮询来实现复杂的流程控制，直到满足特定条件（例如：任务完成）。

# (省略部分 import)
# 1. 条件检查智能体class ConditionChecker(BaseAgent):   name: str = "ConditionChecker"      async def _run_async_impl(self, context: InvocationContext) -> AsyncGenerator[Event, None]:       # 检查共享状态中的 'status' 字段       status = context.session.state.get("status", "pending")              if status == "completed":           # 如果完成，发送 escalate=True 事件，通知 LoopAgent 停止循环           yield Event(author=self.name, actions=EventActions(escalate=True))       else:           yield Event(author=self.name, content="条件未满足，继续循环。")
# 2. 处理步骤智能体process_step = LlmAgent(   name="ProcessingStep",   model="gemini-2.0-flash-exp",   instruction="执行你的任务。如果是最后一步，请将 session state 中的 'status' 设为 'completed'。")
# 3. 循环控制器 (LoopAgent)poller = LoopAgent(   name="StatusPoller",   max_iterations=10, # 防止死循环的安全机制   sub_agents=[       process_step,       ConditionChecker()   ])# 执行逻辑：ProcessingStep -> ConditionChecker -> (如果未完成) -> 重复

场景三：并行执行（ParallelAgent）

这是实现 Map-Reduce 模式的利器。

from google.adk.agents import Agent, ParallelAgent
# 子智能体 1：查天气weather_fetcher = Agent(   name="weather_fetcher",   model="gemini-2.0-flash-exp",   instruction="获取指定地点的天气。",   output_key="weather_data"  # 结果存入状态：session.state["weather_data"])
# 子智能体 2：查新闻news_fetcher = Agent(   name="news_fetcher",   model="gemini-2.0-flash-exp",   instruction="获取指定主题的头条新闻。",   output_key="news_data"      # 结果存入状态：session.state["news_data"])
# 并行协调器data_gatherer = ParallelAgent(   name="data_gatherer",   sub_agents=[       weather_fetcher,       news_fetcher   ])# 运行时，这两个智能体会同时启动，大幅降低总耗时

场景四：智能体即工具（Agent as a Tool）

这是一个非常高级且强大的模式。我们将一个完整的智能体封装成一个工具，供另一个智能体调用。这实现了极佳的封装性。

from google.adk.tools import agent_tool
# 1. 定义底层的“图像生成智能体”image_generator_agent = LlmAgent(   name="ImageGen",   # ... 配置 ...   tools=[generate_image_function])
# 2. 将智能体包装为工具# 对外暴露的接口就像一个普通函数一样简单image_tool = agent_tool.AgentTool(   agent=image_generator_agent,   description="使用此工具生成图像。输入应该是对所需图像的详细描述提示词。")
# 3. 上层“艺术家智能体”# 它不需要知道怎么调 API，它只需要会用 image_toolartist_agent = LlmAgent(   name="Artist",   instruction="构思一个创意提示词，然后调用 `ImageGen` 工具来生成图像。",   tools=[image_tool])

第五部分：要点与结语

🚀 核心要点速览

• 问题（What）： 单个智能体在面对跨领域、多步骤的复杂任务时，容易出现能力瓶颈、上下文遗忘和执行低效。

• 方案（Why）： 多智能体协作模式通过任务分解和专业分工，构建了一个由多个“专家”组成的系统。通过顺序、并行、层级等通信协议，实现了 $1+1>2$ 的协同效应。

• 经验法则（Rule of Thumb）：

• 如果任务是线性的且简单 $\to$ 单智能体 + 工具。

• 如果任务包含多个独立的专业领域（如写代码 + 写文案） $\to$ 顺序交接模式。

• 如果任务需要同时从多个源头获取信息 $\to$ 并行处理模式。

• 如果任务需要复杂的决策和子任务分发 $\to$ 层级/监督者模式。

• 如果任务对正确性要求极高 $\to$ 评审者/辩论模式。

结语

多智能体协作模式标志着 AI 应用开发进入了组织架构设计的新阶段。

作为开发者，我们不再仅仅是提示词工程师（Prompt Engineer），我们变成了数字组织的架构师。我们需要思考的不再是如何写出一个完美的 Prompt，而是如何设计一个高效的团队：我们需要什么样的专家？他们之间如何沟通？谁负责决策？谁负责执行？谁负责质检？

通过掌握 CrewAI、Google ADK 等框架提供的协作原语（Agent, Task, Process, Hierarchy），我们能够构建出具有高度模块化、可扩展性和鲁棒性的智能系统，从而解决以往单体 AI 无法触及的复杂现实问题。

这不仅是技术的胜利，更是协作智慧的胜利。

参考资料

1.Multi-Agent Collaboration Mechanisms: A Survey of LLMs, https://arxiv.org/abs/2501.06322

2.Multi-Agent System — The Power of Collaboration, https://aravindakumar.medium.com/introducing-multi-agent-frameworks-the-power-of-collaboration-e9db31bba1b6

3.Antonio Gulli 《Agentic Design Patterns》