多智能体协作：分工、编排与涌现

9.1 引言：一个Agent解决不了的问题

在前面的章节中，我们构建了功能越来越强的单个智能体：它能规划、能记忆、能调用工具。但当你真正把它丢进一个复杂业务场景——比如"从零撰写一篇深度行业报告"——你会发现它很快就会力不从心。

问题不在于模型不够聪明，而在于角色过载。一个Agent同时承担调研、写作、校对、排版、事实核查，就像让公司里唯一的那名员工既当销售、又写代码、还做财务报表——每件事他都懂一点，但每件事都做不精。即使能力够，上下文窗口也会被撑爆，注意力会被稀释，工具列表会膨胀到难以管理。

💡 小贴士：什么是"角色过载"？ 想象一个人同时兼任记者、编辑、校对和美编。你让他先去采访、回来写稿、再自己校对、最后排版——不是做不到，而是每切换一次角色，他都要重新"进入状态"，精力被反复拉扯。Agent也一样：当你把太多职责塞进一个System Prompt，模型的注意力会被分散，输出质量随职责数量增加而下降。解决之道就是像公司一样分工。

人类社会的解法是分工：把复杂任务拆给不同角色的专家，再通过流程把他们串起来。一家公司里有市场部、技术部、财务部，各部门各司其职，通过例会和流程协作完成单个部门搞不定的大项目。多智能体系统（Multi-Agent System, MAS）正是把这套思路搬到AI世界——让多个专精的Agent各司其职，通过通信协调，共同完成单个Agent难以胜任的任务。

更有意思的是，当多个Agent协作时，往往会涌现出设计中没有显式规划的行为：一个研究员Agent无意中提到的角度，激发了作者Agent的灵感；两个Agent在辩论中互相反驳，最终结论比任何一方都更严谨。这种涌现（Emergence） 是多智能体系统最迷人、也最难预测的部分。

💡 小贴士：什么是"涌现"？ “涌现"指系统整体表现出任何单个组件都不具备的特性。好比一支篮球队，五个球员各自只有运球、传球、投篮的基本功，但组合在一起却能打出精妙的战术配合——这种配合不是任何一个球员单独能完成的，它"涌现"自团队的协作与互动。多智能体系统中的涌现同理：Agent间的对话与交锋，会产生超越任何一个Agent单独能力的洞察。

本章我们将从架构模式讲起，落到CrewAI和AutoGen两个主流框架的实战代码，最后讨论工程落地中的真实挑战。读完本章，你将能用两个框架各搭一个可运行的多智能体系统，并知道在什么场景下选哪个。

9.2 多智能体协作模式

多智能体怎么组织，本质上是一个编排（Orchestration） 问题——就像公司怎么排兵布阵，谁向谁汇报、谁和谁并行、谁给谁兜底，都属于编排的范畴。下面是四种最经典的协作模式。

💡 小贴士：什么是"编排（Orchestration）"？ 编排源自交响乐——指挥不演奏任何乐器，但他决定谁在什么时候进入、什么时候停下、什么时候渐强。在多智能体语境下，编排就是"决定谁先发言、谁后发言、谁听谁的、什么时候结束"的那套规则。编排可以由代码硬编码（声明式），也可以交给一个"Manager Agent"动态决策。

9.2.1 串行流水线（Pipeline）

最直观的模式：Agent像工厂流水线一样依次处理任务，前一个的输出是后一个的输入。就好比报社的采编流程：记者采访→编辑改稿→校对终审，一步接一步。

1

[研究员] → 资料 → [作者] → 初稿 → [编辑] → 终稿

优点是流程清晰、易于调试、每一步可独立优化。缺点是串行执行延迟高，任何一个环节卡住整条线都停摆——记者没交稿，后面所有人都得干等。适合任务边界清晰、有天然先后顺序的场景，如内容生产、数据处理管线。

9.2.2 并行分工（Parallel）

把一个任务拆成若干互不依赖的子任务，多个Agent同时处理，最后汇总。就像公司要写一份年度报告，市场、技术、财务三个部门同时分头写各自的部分，最后由总办合并成一份。

1
2
3

        ┌─ [市场分析Agent] ─┐
任务 ───┼─ [技术分析Agent] ──┼─→ [汇总Agent] → 报告
        └─ [财务分析Agent] ─┘

优点是延迟低、吞吐高——三个人同时干，总时间取决于最慢的那个人而非三人之和。难点在于子任务之间确实要无强依赖，且汇总Agent需要有能力融合异构结果（市场给的是趋势描述，财务给的是数字表格，怎么捏到一起是个技术活）。适合调研、多维评估、批量处理等场景。

9.2.3 层级委派（Hierarchical）

模仿企业组织架构：一个"Manager"Agent负责拆解任务和分派，多个"Worker"Agent负责执行，结果逐层上报。就像部门经理接到一个大项目，拆成子任务分给组员，组员干完汇报，经理验收后整合。

1
2
3

              [Manager Agent]
             /       |        \
     [研究员]    [作者]     [审校]

Manager承担规划与质量控制，Worker专注执行。优点是可扩展性强，能处理超大规模任务——实在忙不过来，Manager还能再拆一层子团队。缺点是Manager容易成为瓶颈和单点故障，层级过深时信息逐层失真，就像传话游戏传了五轮就面目全非。适合复杂项目管理、大型软件工程。

9.2.4 辩论式（Debate）

多个Agent围绕同一问题给出不同立场，通过多轮交锋收敛出更优答案。就像公司开会做重大决策时，有人扮演"乐观派"力推上线，有人扮演"魔鬼代言人"挑刺找漏洞，最后由裁判综合拍板。

1

[正方Agent] ⇄ [反方Agent] ⇄ [裁判Agent]

这是最接近"涌现"的模式：Agent间的反驳会暴露单方忽略的漏洞——正方说"这个功能用户很喜欢”，反方马上追问"但成本是不是超预算了？"。代价是Token消耗大、收敛不可控——辩论可能跑偏成吵架，十轮还没结论。适合高风险决策、科学推理、安全审查等需要"对冲单点偏见"的场景。

四种模式对比

实际工程中很少用单一模式，往往是混合：外层层级委派，内部某条流水线用串行，关键决策点嵌入一轮辩论——就像一家大公司既有层级汇报，部门内又有流水线作业，重大决策还要开会辩论。

9.3 通信机制

模式决定"谁和谁说话"，通信机制决定"怎么说"。就好比公司里同事之间沟通：可以发邮件（点对点）、可以往公告栏贴便签（共享黑板）、也可以在微信群里@全体成员（发布订阅）。

9.3.1 消息传递（Message Passing）

Agent之间直接发送结构化消息，最常见的是JSON。就像同事之间互发邮件，每封邮件都有发件人、收件人、主题和正文：

1
2
3
4
5
6
7
8

# Agent A → Agent B 的消息（类似一封内部邮件）
message = {
    "from": "researcher",          # 发件人：研究员
    "to": "writer",                # 收件人：作者
    "type": "research_result",     # 邮件类型：调研结果
    "content": {"facts": [...], "sources": [...]},  # 正文附件
    "turn": 1                      # 第几轮对话
}

优点是语义清晰、可路由、易审计——每条消息都有明确的收发记录，出了问题能追溯到具体哪一封。CrewAI和AutoGen底层都基于消息传递。缺点是Agent数量多时点对点通信会组合爆炸（N个Agent两两通信是O(N²)条链路），需要引入路由层或消息总线来管理。

9.3.2 共享黑板（Blackboard）

所有Agent读写同一个共享数据结构——“黑板”。谁有新发现就写上去，谁需要就取走，无需知道对方是谁。就像办公室走廊里的那块大白板：研究员贴上调研笔记，作者路过看到了就拿来写稿，编辑写完评语也贴上去，三方互不见面却完成了协作。

1
2
3
4
5
6
7
8

┌─────────── Blackboard ───────────┐
│ topic: "AI芯片市场"               │
│ facts: [...]   ← 研究员写入       │
│ draft: "..."   ← 作者写入         │
│ review: {...}  ← 编辑写入         │
└───────────────────────────────────┘
   ↑↓          ↑↓          ↑↓
[研究员]    [作者]      [编辑]

黑板模式解耦了生产者和消费者——研究员不需要知道作者是谁，只要把笔记贴上白板就行。适合信息逐步累积、Agent角色动态加入的场景。挑战是并发写入的冲突与一致性（两个人同时改同一段怎么办），以及"谁该看哪部分"的权限控制。

9.3.3 发布订阅（Pub/Sub）

Agent订阅感兴趣的事件类型，发布者广播事件，中间件负责分发。就像公司邮件组：你订阅了"产品上线通知"组，只要有人往这个组发消息，所有订阅者都会收到，发布者不需要逐个@人。

1
2
3
4
5
6

[研究员] --publish("fact_ready")--> [Broker]
                                         |
                +-----------+------------+------------+
                |           |            |            |
            [作者]      [审校Agent]  [图表Agent]  [存档Agent]
            (subscribe fact_ready)

Pub/Sub天然支持动态扩缩容——新增一个订阅者（比如再加个"翻译Agent"）无需改动发布方，只要订阅事件就行。适合Agent数量多、角色经常变化的开放式系统。代价是引入消息中间件（Broker），调试链路变长——“这条消息到底被谁消费了"需要查日志才能确认。

工程上三种机制常组合使用：黑板做共享状态，Pub/Sub做事件通知，点对点消息做定向请求——就像公司里既有公告栏（黑板）、又有邮件组（Pub/Sub）、还有一对一私聊（消息传递），各司其职。

9.4 CrewAI实战：内容创作团队

CrewAI是目前最流行的"角色化"多智能体框架，核心抽象是三个：Agent（角色）、Task（任务）、Crew（团队）。它把"分工"这件事做成了声明式API，几行代码就能搭起一个团队——就像写一份岗位说明书加任务清单，剩下的交给框架执行。

💡 小贴士：什么是"声明式API”？ 声明式API的意思是"你只管描述想要什么，框架负责怎么做"。你告诉CrewAI"有三个角色、三个任务、按顺序执行"，至于怎么调度、怎么传上下文、怎么调LLM，都是框架的事。与之相对的是"命令式API"——你得自己写循环、自己管状态、自己控制流程。声明式上手快但灵活性低，命令式可控性强但代码量大。

9.4.1 安装与基础概念

1

pip install crewai crewai-tools

CrewAI的三个核心概念，可以用公司来类比理解：

• Agent：一个有角色（role）、目标（goal）、背景故事（backstory）和工具集的智能体——相当于公司里的一位员工，有职位、有KPI、有简历、有工具。
• Task：一个有描述、期望输出、指派Agent的具体任务——相当于一份任务工单，写明了做什么、交付什么、派给谁。
• Crew：把多个Agent和Task组装成一个团队，指定流程模式（process）和执行顺序——相当于组建一个项目组，定好协作流程。

9.4.2 完整示例：内容创作团队

我们来搭一个"研究员 + 作者 + 编辑"三人团队，输入一个主题，输出一篇可发布的长文。这就像给一个微型编辑部下达选题：研究员负责跑腿采访，作者负责执笔，编辑负责把关。

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100

# pip install crewai crewai-tools
import os
from crewai import Agent, Task, Crew, Process
from crewai_tools import SerperDevTool  # 联网搜索工具

# 设置模型与API（这里使用 gpt-5.4）
os.environ["OPENAI_API_KEY"] = "sk-xxx"
os.environ["SERPER_API_KEY"] = "xxx"  # Serper联网搜索需要单独的API Key

# 模型配置：CrewAI 通过 LiteLLM 兼容 OpenAI 接口
# 传字典给 llm 参数是 CrewAI 的简写方式，框架内部会自动转换
LLM_CONFIG = {"model": "gpt-5.4", "temperature": 0.7}

# 实例化联网搜索工具，研究员会用它查资料
search_tool = SerperDevTool()

# 1) 定义Agent角色 —— 相当于写三份岗位说明书
researcher = Agent(
    role="资深行业研究员",
    goal="围绕给定主题搜集最新、最权威的事实、数据和案例",
    backstory=(
        "你曾在顶级咨询公司任职十年，擅长快速定位行业核心矛盾，"
        "善于从公开数据中提炼洞察，引用必带来源。"
    ),
    tools=[search_tool],   # 研究员配了搜索工具
    llm=LLM_CONFIG,
    verbose=True,           # 打印执行过程，方便调试
)

writer = Agent(
    role="资深技术作者",
    goal="把研究员的资料改写成逻辑清晰、可读性强的长文",
    backstory=(
        "你是某科技媒体主笔，擅长把复杂技术讲给非专业读者，"
        "行文讲究结构层次与节奏感。"
    ),
    llm=LLM_CONFIG,
    verbose=True,
)

editor = Agent(
    role="总编辑",
    goal="对文章做事实核查、结构与语调审校，输出可发布终稿",
    backstory=(
        "你有十五年编辑经验，对事实错误和逻辑漏洞零容忍，"
        "审校时会标注修改理由。"
    ),
    llm=LLM_CONFIG,
    verbose=True,
)

# 2) 定义Task，并指派给对应Agent —— 相当于派发三份任务工单
research_task = Task(
    description=(
        "围绕主题「{topic}」完成调研：\n"
        "1. 列出3-5个核心趋势\n"
        "2. 每个趋势配2条以上带来源的数据\n"
        "3. 标注1-2个代表性案例\n"
    ),
    expected_output="一份结构化调研笔记，含趋势、数据、案例与来源链接",
    agent=researcher,
)

writing_task = Task(
    description=(
        "基于研究员的笔记，撰写一篇2000字左右的长文：\n"
        "- 开篇用一句话点出核心观点\n"
        "- 正文按趋势分小节，每节先观点后数据\n"
        "- 结尾给出对从业者的建议\n"
    ),
    expected_output="一篇Markdown格式的初稿",
    agent=writer,
    context=[research_task],  # 依赖前一个任务的输出（数据总线）
)

editing_task = Task(
    description=(
        "对初稿做最终审校：\n"
        "- 核查所有数据与来源是否对得上\n"
        "- 修正语病、统一术语\n"
        "- 输出终稿，并在文末附「修改说明」\n"
    ),
    expected_output="可发布的Markdown终稿 + 修改说明",
    agent=editor,
    context=[writing_task],  # 编辑依赖作者的初稿
)

# 3) 组建Crew，指定串行流程 —— 把三个角色和三个任务装进一个团队
content_crew = Crew(
    agents=[researcher, writer, editor],
    tasks=[research_task, writing_task, editing_task],
    process=Process.sequential,  # 串行流水线：按任务列表顺序依次执行
    verbose=True,
)

# 4) 启动执行 —— 相当于给编辑部下达选题
result = content_crew.kickoff(inputs={"topic": "2026年AI智能体在企业落地的关键瓶颈"})

print("===== 终稿 =====")
print(result.raw)  # result.raw 是最终任务的原始输出文本

运行后你会看到CrewAI按顺序执行三个任务：研究员先调用SerperDevTool联网搜索，把笔记交给作者；作者产出初稿；编辑审校输出终稿。整个流程的中间产物可以通过result.tasks_output逐个取出，方便审计和调试——就像项目完成后还能翻看每一步的中间稿。

💡 小贴士：LiteLLM 是什么？ CrewAI底层用LiteLLM做模型适配层。LiteLLM是一个统一接口库，让你用同一套API调用OpenAI、Anthropic、Google等几十家模型商。所以你传{"model": "gpt-5.4"}它能识别，传{"model": "claude-sonnet-4"}它也能路由。换模型只改字符串，不用改代码。

注意几个关键设计：

• context=[...] 显式声明任务依赖，CrewAI会自动把上游输出注入下游Agent的上下文，这是串行流水线的"数据总线"——相当于研究员把笔记递给作者时，不用作者自己再去查一遍。
• Process.sequential 让任务按列表顺序执行；若改成Process.hierarchical，CrewAI会自动生成一个Manager Agent负责分派，相当于从"流水线"模式切换到"层级委派"模式（需额外指定manager_llm）。
• 角色三件套（role/goal/backstory）不是装饰，它直接拼进System Prompt，深刻影响Agent的行为风格——研究员的backstory强调"引用必带来源"，会显著降低幻觉率。这就像招人时看简历，有十年咨询经验的人做事风格就是和应届生不一样。

9.5 AutoGen实战：代码开发团队

如果说CrewAI的强项是"角色化分工"，AutoGen的强项就是"对话式协作"。AutoGen把每个Agent看成一个会话参与者，通过多轮GroupChat让Agent们自己讨论出结果，更接近"会议室协作"的体验——不是你预先排好流水线，而是让几个专家坐进会议室，自己商量着干。

💡 小贴士：CrewAI vs AutoGen 的核心差异 CrewAI是"你定流程，Agent照着走"——像导演拿着剧本喊"第一场Action"。AutoGen是"你定参与者和规则，Agent自己聊"——像把几个专家关进会议室，告诉他们"讨论完出来交结果"。前者可控性强，后者灵活度高。

9.5.1 安装与基础概念

1

pip install autogen-agentpy autogen-ext[openai]

AutoGen 0.4+（重构版，也称AG2）的核心概念：

• AssistantAgent：能思考、能调用工具的智能体——相当于会议室里的专家。
• UserProxyAgent：代表人类或外部环境的代理，可执行代码、调用函数、在需要时把人拉进对话——相当于会议室里那个"能动手敲键盘"的人。
• GroupChat + GroupChatManager：把多个Agent放进一个群聊，由Manager决定谁下一个发言——相当于会议室的主持人。

9.5.2 完整示例：代码开发团队

我们搭一个"架构师 + 程序员 + 测试工程师"的群聊团队，输入需求，输出可运行并通过测试的代码。就像拉了一个三人群聊：架构师定接口→程序员写实现→测试跑用例，谁不满意就在群里@对方改。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74

# pip install autogen-agentpy autogen-ext[openai]
import asyncio  # AutoGen 0.4 的 team.run() 是异步方法，需要 asyncio
import os
from autogen_agentchat.agents import AssistantAgent
from autogen_agentchat.teams import RoundRobinGroupChat
from autogen_agentchat.conditions import TextMentionTermination
from autogen_ext.models.openai import OpenAIChatCompletionClient

os.environ["OPENAI_API_KEY"] = "sk-xxx"

# 模型客户端：使用 gpt-5.4，temperature 设低让代码输出更稳定
model_client = OpenAIChatCompletionClient(
    model="gpt-5.4",
    temperature=0.3,
)

# 1) 架构师：负责拆解需求、定义接口（只设计不写实现）
architect = AssistantAgent(
    name="Architect",
    model_client=model_client,
    system_message=(
        "你是资深软件架构师。你的职责：\n"
        "1. 把用户需求拆成2-4个模块\n"
        "2. 用Python dataclass或Protocol定义模块间接口\n"
        "3. 不要写实现细节，只给接口契约\n"
        "完成后把接口设计交给 Programmer。"
    ),
)

# 2) 程序员：按架构师的接口写实现
programmer = AssistantAgent(
    name="Programmer",
    model_client=model_client,
    system_message=(
        "你是资深Python工程师。你的职责：\n"
        "1. 严格按 Architect 的接口实现每个模块\n"
        "2. 代码要有中文注释，类型注解齐全\n"
        "3. 把完整可运行代码贴出来，交给 Tester 验证\n"
        "如果 Tester 报错，你要修复后重新提交。"
    ),
)

# 3) 测试工程师：写测试并执行，全部通过才放行
tester = AssistantAgent(
    name="Tester",
    model_client=model_client,
    system_message=(
        "你是测试工程师。你的职责：\n"
        "1. 针对程序员的实现编写 pytest 用例\n"
        "2. 用代码执行工具运行测试\n"
        "3. 全部通过后，回复「APPROVED」并附最终代码；"
        "若有失败，把错误日志回传给 Programmer。"
    ),
)

# 4) 组建群聊：轮询发言（Architect→Programmer→Tester 循环），
#    遇到 "APPROVED" 终止，最多12轮防止死循环
team = RoundRobinGroupChat(
    participants=[architect, programmer, tester],
    termination_condition=TextMentionTermination("APPROVED"),
    max_turns=12,  # 安全阀：最多12轮，防止Agent陷入死循环
)

# 5) 启动协作 —— team.run() 是异步方法，用 asyncio.run() 驱动
async def main():
    task = (
        "需求：实现一个简易待办事项CLI，支持 add/list/done/remove 四个命令，"
        "数据用JSON文件持久化。要求代码结构清晰、带测试。"
    )
    result = await team.run(task=task)
    print("===== 协作结果 =====")
    print(result.messages[-1].content)  # 取最后一条消息作为最终输出

asyncio.run(main())

💡 小贴士：为什么 AutoGen 要用 async/await？ AutoGen 0.4 全面采用Python异步编程。异步的好处是：当一个Agent在等LLM回复时，其他Agent或工具可以并行工作，不会傻等。但代价是你不能直接team.run()，必须用await并在asyncio.run()里调用。如果你在Jupyter Notebook里跑，Notebook原生支持await，可以直接写result = await team.run(task=task)。

执行时你会看到一轮轮对话：架构师先给出接口设计，程序员按接口写实现，测试工程师写pytest并执行——如果失败，错误信息会回到程序员那轮，他修复后再次提交，直到Tester打出"APPROVED"，群聊终止。这其实就是一个小型软件团队的完整开发闭环。

AutoGen的几个设计要点：

• RoundRobinGroupChat 是最简单的发言调度（按列表轮询Architect→Programmer→Tester→Architect…），就像圆桌开会按座位顺序依次发言。更复杂场景可换用SelectorGroupChat（让LLM自己决定下一个该谁发言），这其实就实现了"层级委派"中Manager的功能。
• 终止条件至关重要：TextMentionTermination靠关键词"APPROVED"终止，还可以叠加MaxMessageTermination、TokenUsageTermination等做多重保险——就像会议规定"有人说散会就散，或者超过两小时强制散"。多重终止条件用|或&组合，如TextMentionTermination("APPROVED") | MaxMessageTermination(30)。
• AutoGen的Agent天然支持工具调用（如代码执行器），这是它能做"写代码-跑测试-改代码"闭环的关键——测试工程师不只是"说"要跑测试，而是真的能执行代码并拿到结果。

9.6 多智能体系统的挑战

把多智能体从Demo推向生产，有几座绕不开的山。这些挑战不是"模型不够聪明"能解决的，而是系统工程问题。

9.6.1 通信开销与Token消耗

N个Agent两两通信的链路数是O(N²)量级，加上多轮对话，Token消耗会迅速膨胀。一个5-Agent的辩论系统跑一轮决策，烧掉的Token可能是单Agent方案的10倍以上。就像公司越大，内部沟通成本越高——5个人的团队沟通顺畅，50个人的公司天天开会，真正干活的时间反而少了。多智能体系统也有同样的困境：Agent之间互相对话的轮数一多，Token账单就会让你怀疑人生。

对策：尽量用串行或层级结构代替全连接（不是所有Agent都需要互相说话）；让Agent之间传递"摘要"而非"原始上下文"（别把100页报告全文转发，给个摘要就行）；给每个Agent单独的Token预算并监控，超了就报警。

9.6.2 一致性与冲突解决

两个Agent对同一事实给出矛盾结论时怎么办？比如研究员说"市场规模500亿"，财务分析师说"只有300亿"。常见做法：引入"裁判Agent"做仲裁；在黑板模式中加版本号与冲突检测；对关键决策采用"辩论+投票"机制。

更重要的是事前约束：在System Prompt里明确每个Agent的职责边界，减少正面冲突的概率——就像公司里写清楚"市场数据以财务部为准，技术评估以CTO办公室为准"，谁说了算提前定好，避免各说各话。

9.6.3 可观测性与调试

多Agent系统的执行轨迹是网状的——A调B、B调C、C又回头问A——“为什么最终结果是错的"极难定位。就像一个10人团队协作出了bug，你很难说是哪个环节哪个人搞错的。

💡 小贴士：什么是"可观测性（Observability）"？ 可观测性指从外部推断系统内部状态的能力。在单Agent时代，你看一眼Prompt和回复就知道发生了什么。到了多Agent时代，Agent之间你来我往十几轮，只看最终结果完全没法定位问题。可观测性就是给系统装上"监控摄像头”：每条消息谁发给谁、第几轮、用了多少Token，全都记录在案。

对策：为每条消息打上trace_id和turn编号；把所有Agent的输入/输出落盘成结构化日志；用LangSmith、Langfuse等可观测平台可视化调用图。调试时先定位"哪个Agent哪一轮偏离了预期"，再深入看它的Prompt和上下文。

9.6.4 成本控制

多智能体很容易把"省钱"变成"烧钱"——你以为多请几个Agent帮忙效率更高，结果账单翻了十倍。建议：对低成本决策用小模型（如gpt-5.4-mini），对关键推理才上大模型（gpt-5.4）；给每个Crew/GroupChat设总Token上限和单轮上限；用缓存复用重复推理结果；对幂等任务做并发限流，防止失败重试时的成本雪崩。

💡 小贴士：什么是"幂等"？ 幂等指同一个操作执行一次和执行多次效果相同。比如"设置开关为开"是幂等的——你调一次和调十次结果都是"开"。但"余额加100"不是幂等的——调十次就变成加1000了。对幂等任务做重试是安全的，对非幂等任务重试前要先检查状态。

9.7 框架对比

CrewAI、AutoGen、LangGraph是当前最主流的三个多智能体框架，定位各有侧重。选框架就像选管理工具：CrewAI是"任务看板"，AutoGen是"群聊工具"，LangGraph是"流程引擎"——它们都能帮你把多人协作管起来，但风格截然不同。

💡 小贴士：什么是 DAG？ DAG（Directed Acyclic Graph，有向无环图）是一种数据结构：节点之间有方向地连接，且不存在"绕回原点"的环路。LangGraph用它来描述Agent执行流程——每个节点是一步操作，边定义执行顺序。虽然叫"无环"，但LangGraph实际支持条件循环（通过状态判断是否回头），所以它比纯DAG更灵活。

选型建议：

• 要快速搭一个分工明确的流程，选CrewAI，它的角色化抽象最贴近业务直觉——会写岗位说明书就会用。
• 要让多个Agent讨论式协作、能跑代码，选AutoGen，GroupChat体验最好——最接近"拉群开会"的自然交互。
• 要对流程做精细控制、需要循环和条件分支，选LangGraph，它本质是把Agent编排建模成状态机，可控性和可观测性最强——适合那些"一步走错全盘皆输"的高严谨场景。

三者并非互斥：LangGraph可以作为底层的编排引擎，上面跑CrewAI风格的Agent；AutoGen的Agent也可以被封装成LangGraph的节点。工程上更常见的是"以一个为主，借鉴其他"。

9.8 小结

本章我们从"一个Agent解决不了的问题"出发，系统梳理了多智能体协作的全景：

• 四种协作模式：串行流水线（工厂流水线）、并行分工（多部门同时干）、层级委派（经理分派活）、辩论式（开会交锋），各自适合不同形状的任务，工程上常混合使用。
• 三种通信机制：消息传递（发邮件）、共享黑板（贴白板）、发布订阅（群通知），解决"Agent之间怎么说上话"的问题。
• 两个实战框架：CrewAI用"角色+任务+团队"的声明式抽象搭建内容创作团队；AutoGen用"群聊+轮询发言"搭建代码开发团队，各自体现了不同的编排哲学——一个像导演拿剧本喊Action，一个像会议室里专家自由讨论。
• 四类工程挑战：通信开销、一致性冲突、可观测性、成本控制——这些才是把多智能体推向生产的真正难点，比搭Demo难得多。
• 框架选型：CrewAI胜在直觉、AutoGen胜在对话、LangGraph胜在可控，按需选择、混合使用是常态。

值得再次强调的是涌现：多智能体系统最诱人也最危险之处，在于它的整体行为往往超出设计者的显式规划。一个设计良好的协作可能涌现出"研究员无意提到的事实被作者敏锐放大成核心论点"的惊喜；一个设计糟糕的协作也可能涌现出"两个Agent互相吹捧、越走越偏"的灾难。掌控涌现的方向，靠的不是更聪明的模型，而是清晰的职责边界、可观测的执行轨迹、以及随时能把人拉回环路的兜底机制。

9.9 下一章预告：MCP协议

本章所有Agent之间的通信，都发生在同一个进程、同一个框架内。但真实世界里，你的Agent要调用的工具、要协作的伙伴，可能来自不同厂商、不同语言、不同进程。怎么让它们说同一种语言？

第10章我们将走进 MCP（Model Context Protocol） ——一个正在成为行业标准的"Agent与外部世界对话协议"。我们会看到MCP如何把工具、资源、提示统一成一组标准接口，让任何Agent都能即插即用地接入任何MCP服务器，真正实现跨框架、跨语言的智能体生态互联。

本章代码示例已上传配套仓库，建议边读边跑。多智能体的魅力，亲手跑过才体会得深。