多 Agent 框架深度剖析：CrewAI 角色分工、AutoGen 多轮对话与人机协同的工程实践

多 Agent 框架深度剖析：CrewAI 角色分工、AutoGen 多轮对话与人机协同的工程实践

多 Agent 框架是一种用于构建和管理多个智能体（Agent）协作系统的技术架构，旨在通过分工协作解决复杂问题。本文从架构抽象、框架原理、代码实战三个维度，系统剖析多 Agent 系统的核心设计、CrewAI 的角色任务调度、AutoGen 的多轮对话与人机协同，并覆盖代码生成、舆情分析、智能客服三大典型落地场景。目标是帮助读者建立"从单 Agent 到多 Agent 系统工程"的完整认知。

---

摘要

随着大模型从"回答问题"走向"完成任务"，单一 Agent 的上下文窗口、角色一致性与并发能力逐渐成为瓶颈。多 Agent 框架通过将复杂任务拆分为多个专业化角色，并通过编排、通信、记忆等机制实现协作，正在成为 LLM 应用落地的关键范式。

本文首先定义多 Agent 框架的通用分层架构，辨析单 Agent 与多 Agent 的能力边界；随后深入讲解 CrewAI（角色分工、任务调度）与 AutoGen（多轮对话、人机协同）两款代表性框架的设计理念、核心 API、流程模式与工程调优；最后以 代码生成、舆情分析、智能客服 三个场景为例，给出可运行的多 Agent 编排方案与落地经验。

关键词：多 Agent 框架；CrewAI；AutoGen；角色分工；任务调度；多轮对话；人机协同；LangGraph；代码生成；舆情分析；智能客服

概念区分：CrewAI / AutoGen / LangGraph / 多 Agent 框架

在进入正文之前，先区分几个容易混淆的概念，避免把编排框架、对话框架和 Agent 框架混为一谈：

概念	定位	核心抽象	最擅长的协作方式
多 Agent 框架	通用概念	Agent、通信、编排、记忆	多个 Agent 协作解决问题
CrewAI	任务驱动的角色化框架	Agent + Task + Crew + Process	明确的角色分工与任务流水线
AutoGen	对话驱动的协作框架	ConversableAgent / GroupChat	多轮对话、人机协同、群聊
LangGraph	状态图编排框架	Graph / State / Node / Edge	循环、分支、中断恢复等复杂控制流

三者关系：CrewAI 和 AutoGen 都是多 Agent 框架的具体实现，LangGraph 可以作为它们的底层编排层，也可以单独使用。CrewAI 适合"任务清单式"协作，AutoGen 适合"会议讨论式"协作，LangGraph 适合"状态机式"精细编排。

---

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

1.1 单 Agent 的三大天花板

单 Agent 在解决相对封闭、上下文可控的问题时表现优秀，但在复杂工程任务中很快会遇到瓶颈：

天花板	表现	带来的问题
上下文膨胀	ReAct / CoT 循环中每轮工具调用结果都回灌上下文	10 轮后 token 可能膨胀 5-10 倍，成本与延迟双高
角色漂移	同一个系统提示既要"规划"又要"编码"还要"审稿"	Agent 在多个角色间反复横跳，输出质量下降
能力单一化	一个 Agent 的工具集与记忆空间有限	难以同时完成"调研 + 分析 + 写作 + 校验"这类复合任务

核心结论：单 Agent 像一位"十项全能但精力有限的专家"，而多 Agent 更像一个"各司其职的团队"。复杂问题天然需要专业化分工。

1.2 多 Agent 的核心思想：分治 + 专业化

多 Agent 系统通过两条原则突破上述瓶颈：

• 分治（Divide and Conquer）：把复杂目标拆成若干可独立交付的子任务，每个子任务由最擅长的 Agent 处理
• 专业化（Specialization）：每个 Agent 绑定固定角色、目标、工具集和记忆空间，降低角色漂移概率

这种思想在人类组织中早已被验证——没有人会让同一个人既当采购员又当架构师又当测试。LLM 虽然"通才"，但在同一个会话里频繁切换角色仍会导致注意力分散与一致性下降。多 Agent 框架本质上是在工程层面约束这种切换。

1.3 多 Agent 系统的五种协作拓扑

多 Agent 系统中的通信与协作可以抽象为五种经典拓扑，选择合适的拓扑是系统设计的关键：

拓扑	核心思想	适用场景	注意点
流水线（Pipeline）	阶段化顺序执行，前序输出即后序输入	报告生成、代码生成、ETL	阶段间契约要清晰
主从（Orchestrator）	一个中心节点分派任务并汇总结果	工具调用调度、任务分解	Orchestrator 不能成为单点瓶颈
辩论（Debate）	多个 Agent 互相对抗，最后由 Judge 裁决	代码评审、方案评估、安全审核	Judge 必须客观，否则偏见放大
黑板（Blackboard）	共享全局状态，各 Agent 异步读写	知识融合、复杂问题求解	写冲突与状态同步要谨慎
网络（Mesh）	任意 Agent 间可直接通信	开放式研究、创意头脑风暴	通信复杂度 O(n²)，成本高

选型建议：80% 的落地场景只需要"流水线 + 黑板"两种模式的组合。过度使用 Mesh 会导致上下文爆炸与调试困难。

---

二、多 Agent 框架的通用架构剖解

2.1 核心抽象：Agent、Task、通信、编排、记忆

无论 CrewAI 还是 AutoGen，所有多 Agent 框架都可以抽象为以下六个层次：

抽象层	职责	关键概念
应用层	面向业务场景定义目标与输入输出	代码生成、舆情分析、智能客服等
编排层	控制 Agent 执行顺序、分支、循环	DAG、状态机、GroupChatManager、Crew Process
协作层	定义 Agent 之间的消息流转方式	共享消息池、点对点、黑板广播
Agent 层	单个 Agent 的角色、工具、记忆	role/goal/backstory、tools、memory
能力层	Agent 依赖的基础能力	Tool 调用、RAG、规划、反思
模型层	LLM 接入与模型选择	GPT、Claude、DeepSeek、本地模型

这六层不是每个框架都单独暴露，但理解它们有助于在不同框架之间迁移设计思想。

2.2 通信机制：共享消息池、点对点、黑板与广播

多 Agent 的效率很大程度上取决于通信机制的设计：

• 共享消息池（如 AutoGen GroupChat）：所有 Agent 读写同一份 messages 列表，天然保证上下文一致，缺点是随着轮次增加， everyone 都要看全部历史
• 点对点（如 LangGraph 的节点直连）：消息只在相关节点间传递，上下文可控，但需要显式定义连线
• 黑板（Blackboard）：共享全局状态，适合异步协作与知识融合，写冲突需要额外处理
• 广播（Broadcast）：一个 Agent 向所有 Agent 发消息，适合通知类场景，但容易噪声过大

核心结论：通信机制决定了系统的"上下文可见范围"。选择更窄的通信范围可以显著降低 token 成本与干扰。

2.3 状态一致性与上下文管理

多 Agent 系统中最大的工程挑战之一，是如何在不同 Agent 之间维护一致的全局状态。常见策略包括：

策略	做法	优点	缺点
全局状态对象	所有 Agent 共享一个 State 字典	实现简单	写冲突、难以追踪变更
事件溯源	只追加消息事件，状态由事件推导	可回放、可审计	历史膨胀
检查点（Checkpoint）	定期持久化状态，支持中断恢复	容错、可重入	需要存储后端
短链上下文	每个 Agent 只接收摘要而非完整历史	token 成本低	信息可能丢失

生产环境中通常会组合使用：用检查点保证容错，用短链上下文控制成本，用事件溯源实现可观测。

2.4 可观测性：追踪、评估、成本与告警

多 Agent 系统比单 Agent 更难调试，因为错误可能出现在"Agent A 的输出被 Agent B 误解"这类跨节点场景。可观测性建设至少需要覆盖：

• 链路追踪：看清每个 Agent 的输入、输出、工具调用（LangSmith、Langfuse、Arize Phoenix）
• 效果评估：对每个 Agent 的输出打分，沉淀 Bad Case
• 成本监控：多 Agent 意味着多轮 LLM 调用，Token 消耗可能翻倍
• 异常告警：延迟、错误率、循环次数、上下文长度等指标超限自动通知

最佳实践：多 Agent 项目从第一天起就要接入追踪。没有 Trace 的多 Agent 系统，调试时会像在黑盒里摸象。

---

三、CrewAI：角色分工与任务调度

3.1 设计哲学：把人类团队映射为 Agent 团队

CrewAI 的设计哲学非常直观：如果你要组建一个项目团队，你会先定义角色、再分配任务、最后规定汇报流程；CrewAI 让 Agent 团队也按这个方式运转。

每个 CrewAI Agent 都带有强烈的人类职场角色感：

• role：角色名称，如"高级研究员"“资深架构师”
• goal：该角色要达成的目标
• backstory：背景故事，塑造角色的语气与视角
• tools：该角色可调用的工具
• allow_delegation：是否允许把任务委托给同事

设计要点：backstory 不是装饰，它会显著影响 Agent 的输出风格。例如让研究员"以严谨学术风格"和让撰稿人"以公众号风格"写作，会得到截然不同的文本。

3.2 核心四件套：Agent / Task / Crew / Process

CrewAI 的代码结构可以概括为四个核心类：

类	作用	关键参数
Agent	定义角色、工具、记忆、委托权限	role, goal, backstory, tools, llm, memory
Task	定义具体任务、期望输出、执行者	description, expected_output, agent, context
Crew	团队容器，把 Agent 和 Task 组装起来	agents, tasks, process, verbose, memory
Process	控制任务执行流程	sequential / hierarchical

一个最小 CrewAI 应用的骨架如下：

# 【实战代码】CrewAI 最小骨架：研究员 + 撰稿人
from crewai import Agent, Task, Crew, Process
from crewai.tools import BaseTool

# 1. 定义两个 Agent（角色）
researcher = Agent(
    role="高级研究员",
    goal="深入调研给定主题，收集关键事实、数据与趋势",
    backstory="你是一位拥有十年经验的行业研究员，擅长从杂乱信息中提炼核心观点。",
    llm="gpt-4o",
    verbose=True,
)

writer = Agent(
    role="资深撰稿人",
    goal="将研究成果转化为结构清晰、语言流畅的中文报告",
    backstory="你是一位擅长把复杂内容写成通俗报告的资深编辑。",
    llm="gpt-4o",
    verbose=True,
)

# 2. 定义任务
research_task = Task(
    description="调研 2026 年大模型多 Agent 框架的主流趋势",
    expected_output="一份包含 5 个以上关键趋势的要点清单，每条带一句话说明。",
    agent=researcher,
)

write_task = Task(
    description="基于研究成果撰写一篇 2000 字的中文分析文章",
    expected_output="一篇 Markdown 格式的中文分析文章，含摘要、正文、结论。",
    agent=writer,
    context=[research_task],  # 声明依赖：自动接收 research_task 的输出
)

# 3. 组装 Crew 并运行
crew = Crew(
    agents=[researcher, writer],
    tasks=[research_task, write_task],
    process=Process.sequential,
    verbose=True,
)

result = crew.kickoff()
print(result)

3.3 流程对比：sequential vs hierarchical

CrewAI 提供两种核心流程：sequential（顺序）和 hierarchical（层级）。

【CrewAI 核心对象模型】

       ┌─────────────────────────────────────────────┐
       │               Crew  团队容器                │
       │     process = sequential / hierarchical     │
       └─────────────────────────────────────────────┘
                              │       包含 agents / tasks
        ┌─────────────────────┼─────────────────────┐
        ▼                     ▼                     ▼
   ┌─────────┐           ┌─────────┐           ┌─────────┐
   │ Task 1  │           │ Task 2  │           │ Task 3  │
   │  调研   │           │  分析   │           │  撰写   │
   └─────────┘           └─────────┘           └─────────┘
        │ agent=              │ agent=              │ agent=
        ▼                     ▼                     ▼
   ┌─────────┐           ┌─────────┐           ┌─────────┐
   │ 调研员  │           │ 分析师  │           │ 撰稿人  │
   ├─────────┤           ├─────────┤           ├─────────┤
   │  role   │           │  role   │           │  role   │
   │  goal   │           │  goal   │           │  goal   │
   │backstory│           │backstory│           │backstory│
   │  tools  │           │  tools  │           │  tools  │
   └─────────┘           └─────────┘           └─────────┘

  Task 之间通过 context=[task1, task2] 声明依赖，
  上游 Task 的 output 自动注入下游 Task 的上下文。

【Process.sequential】顺序流水线：单向传导，无回退

     Task1 ──── output ────▶ Task2 ──── output ────▶ Task3 ────▶ 交付
       │                       │                       │
       ▼ agent=                ▼ agent=                ▼ agent=
    调研员                  分析师                  撰稿人

   执行规则：Task1 完成 ──▶ 才启动 Task2 ──▶ 才启动 Task3
   上下文  ：每个 Task 的 output 自动成为下一个 Task 的 context

【Process.hierarchical】层级分派：Manager 动态调度 + 验收回退

                          Manager Agent
                                │
              ┌─────────────────┼─────────────────┐
              │ 分派            │ 分派            │ 分派
              ▼                 ▼                 ▼
            Task1             Task2             Task3
              │                 │                 │
              └─────────────────┼─────────────────┘
                                │ 结果汇总
                                ▼
                              验收
                                │
                ┌───────────────┴───────────────┐
                ▼                               ▼
             通过 ✓                         未通过 ✗
                │                               │
                ▼                               ▼
          汇总 ──▶ 交付                     重新分派
                                                │
                        ┌───────────────────────┘
                        ▼
                    回到分派步骤（循环，需设 max_iter 兜底）

两种流程的差异可以归纳为以下八个维度：

对比维度	sequential（顺序）	hierarchical（层级）
控制流	单向直线：Task1 → Task2 → Task3，无回退	分派 → 汇总 → 验收，未通过可回退重做
任务分配	代码中显式指定 agent=	Manager 自行选择执行者，无需指定
上下文传递	前一个 Task 的 output 自动成为后一个的 context	Manager 汇总各 Agent 结果后统一分发
适用场景	依赖关系明确的流水线：调研 → 分析 → 撰写	任务边界模糊、需要动态协调与质量把关
配置要点	默认流程，零额外配置	必须设置 manager_llm
Token 成本	低：每个 Task 基本一轮调用	高：Manager 每轮都要决策与验收
调试难度	低：链路可预测，Trace 易读	高：分派结果不确定，问题难以复现
典型问题	依赖写错导致上下文缺失	Manager 反复分派，循环不收敛

在 hierarchical 模式下，CrewAI 会自动实例化一个 Manager，由它读取所有 Task 与 Agent 的描述，决定如何分派。这意味着你不需要手动指定 agent=...，Manager 会自行选择执行者。它的优势是灵活性，缺点是 Token 消耗显著增加。

核心结论：除非任务依赖关系动态多变，否则优先使用 Process.sequential。hierarchical 模式更适合"任务边界不清晰、需要反复协调"的场景。

3.4 任务上下文传递与委托机制

CrewAI 中的上下文传递有两种方式：

• 显式依赖 context=[task1, task2]：在 Task 定义中声明依赖，Crew 会自动把依赖任务的输出注入当前任务
• 隐式顺序依赖：sequential 流程下，默认前一个 Task 的输出会作为后一个 Task 的上下文

委托（delegation）则允许一个 Agent 把任务转交给更合适的同事。例如研究员发现需要写代码做数据分析时，可以委托给"数据工程师"Agent。

# 【实战代码】开启 Agent 委托，并限制委托轮数
coder = Agent(
    role="数据工程师",
    goal="编写 Python 脚本完成数据分析",
    backstory="擅长用 Python 和 pandas 做数据清洗与可视化。",
    llm="gpt-4o",
    allow_delegation=True,  # 允许别人把任务委托给我
)

researcher = Agent(
    role="高级研究员",
    goal="调研并分析数据",
    backstory="遇到数据问题时会委托给数据工程师。",
    llm="gpt-4o",
    allow_delegation=True,  # 允许我把任务委托给同事
)

注意：委托是隐式行为，Agent 会自己决定是否委托。频繁委托会导致对话无限循环。生产环境中建议设置 max_iter 或显式限制委托目标。

3.5 完整代码实战：研究报告生成

下面给出一个相对完整的 CrewAI 示例，包含三个角色（研究员、分析师、撰稿人）和两个阶段的任务依赖：

# 【实战代码】CrewAI 多角色研究报告生成
from crewai import Agent, Task, Crew, Process
from langchain_openai import ChatOpenAI

llm = ChatOpenAI(model="gpt-4o", temperature=0.3)

researcher = Agent(
    role="高级研究员",
    goal="收集 2026 年多 Agent 框架的关键事实与数据",
    backstory="你是一位严谨的行业研究员，只输出有据可查的事实，不编造数据。",
    llm=llm,
    verbose=True,
)

analyst = Agent(
    role="首席分析师",
    goal="基于事实提炼洞察，指出各框架的优劣与适用边界",
    backstory="你擅长横向对比与技术趋势判断，会引用具体框架名称和特性。",
    llm=llm,
    verbose=True,
)

writer = Agent(
    role="资深撰稿人",
    goal="将分析结果改写成面向开发者的技术文章",
    backstory="你擅长把分析结论写成条理清晰、有案例支撑的中文技术博客。",
    llm=llm,
    verbose=True,
)

task1 = Task(
    description="调研 2026 年多 Agent 框架（CrewAI、AutoGen、LangGraph 等）的核心定位。",
    expected_output="输出一份 10 条以内的要点清单，每条包含框架名 + 核心定位。",
    agent=researcher,
)

task2 = Task(
    description="基于调研结果，横向对比各框架在角色分工、对话协同、可观测性三个维度的差异。",
    expected_output="输出一份对比表格，维度清晰、结论明确。",
    agent=analyst,
    context=[task1],
)

task3 = Task(
    description="将对比结果改写成一篇面向中文开发者的技术博客正文。",
    expected_output="输出 Markdown 格式文章，约 2000 字，含摘要、正文、结论。",
    agent=writer,
    context=[task1, task2],
)

crew = Crew(
    agents=[researcher, analyst, writer],
    tasks=[task1, task2, task3],
    process=Process.sequential,
    verbose=True,
    memory=False,  # 关闭 Crew 级记忆，避免上下文膨胀
)

result = crew.kickoff()
print("\n========== 最终输出 ==========\n")
print(result)

3.6 工程调优与踩坑

CrewAI 落地时常见的坑与应对策略：

坑	原因	解法
输出过长	Task 的 expected_output 不够具体	明确要求字数、格式、必须包含的字段
Agent 不调用工具	工具描述不清，或任务本身不需要工具	用 description 强调"必须调用某某工具"
上下文丢失	依赖任务输出太长，超出后续任务上下文	在 expected_output 中要求"输出不超过 5 条"
Token 成本爆炸	hierarchical 模式下 Manager 反复协调	改用 sequential 或限制 max_iter
循环委托	Agent 互相委托，无法收敛	关闭 allow_delegation 或指定 manager_llm 的决策边界

最佳实践：先用 2-3 个 Agent 跑通最小闭环，再逐步增加角色。不要一开始就做 8 个 Agent 的复杂团队。

---

四、AutoGen：多轮对话与人机协同

4.1 设计哲学：一切皆对话（ConversableAgent）

与 CrewAI 的"任务清单"风格不同，AutoGen 的设计哲学是"一切皆对话"：每个 Agent 都是一个可对话的实体，通过消息的发送与接收来协作完成任务。

AutoGen 的核心抽象是 ConversableAgent，它有两个最重要的子类：

• UserProxyAgent：代表人类用户，可以执行代码、调用工具、接收人类输入
• AssistantAgent：代表 AI 助手，负责生成代码、推理、规划

AutoGen 的优势不在于严格的任务流水线，而在于灵活的对话模式：两个 Agent 对话、多个 Agent 群聊、人机协同、代码自动执行。

4.2 核心架构演进：v0.2 → v0.4（Actor / 事件驱动）

AutoGen 在 v0.4 中做了较大重构，核心变化是从"直接 Agent 调用"转向"Actor + 事件驱动"：

维度	AutoGen v0.2	AutoGen v0.4
核心抽象	ConversableAgent	Agent + AgentRuntime
通信方式	直接方法调用	异步消息 / 事件
扩展性	单进程为主	支持分布式运行时
人机协同	较简单	更灵活的 input_func
终止机制	is_termination_msg	组合式 TerminationCondition

v0.4 的 Agent 更像 Actor：每个 Agent 有自己的消息箱，运行时负责消息路由。这种设计让 AutoGen 更容易扩展成分布式多 Agent 系统，但也提升了学习曲线。

建议：新项目建议直接用 v0.4，v0.2 将逐步进入维护模式。

4.3 两 Agent 对话：UserProxyAgent + AssistantAgent

两 Agent 对话是 AutoGen 最经典的模式，常用于"人类提需求、AI 写代码并执行"的场景：

# 【实战代码】AutoGen v0.4 最小对话：人类代理 + 编码助手
import asyncio
from autogen_agentchat.agents import AssistantAgent, UserProxyAgent
from autogen_agentchat.teams import RoundRobinGroupChat
from autogen_agentchat.conditions import TextMentionTermination
from autogen_ext.models.openai import OpenAIChatCompletionClient

model_client = OpenAIChatCompletionClient(model="gpt-4o")

assistant = AssistantAgent(
    name="Coder",
    model_client=model_client,
    system_message="你是一个专业 Python 程序员。完成任务后回复 TERMINATE。",
)

user_proxy = UserProxyAgent(
    name="User",
    input_func=input,  # 使用标准输入实现人机协同
)

# 终止条件：任意消息中出现 TERMINATE
team = RoundRobinGroupChat(
    participants=[user_proxy, assistant],
    termination_condition=TextMentionTermination("TERMINATE"),
)

async def main():
    await team.run(task="写一个 Python 函数，计算斐波那契数列前 N 项，并给出单元测试。")

if __name__ == "__main__":
    asyncio.run(main())

在这个例子里，Coder 会生成代码，UserProxyAgent 通过 input_func 让人类决定是否继续、是否要修改。真正无人值守时，可以把 input_func 换成返回固定字符串的函数，或关闭 human-in-the-loop。

4.4 GroupChat：群聊模式与发言者选择

当任务需要多个专业 Agent 协作时，AutoGen 提供 GroupChat。它的核心组件是 GroupChatManager：

• 所有 Agent 共享一份消息列表 messages
• Manager 根据策略选择下一个发言者
• 发言者生成消息后，再次由 Manager 决定下一位

AutoGen 的发言者选择策略包括：

策略	说明	适用场景
RoundRobin	轮流发言	简单循环、人人都能发言
Selector	由 LLM 选择最合适的下一个发言者	角色分工明确，需要动态调度
Mention	由当前发言者显式 @ 下一位	需要精确控制流程
Random	随机选择	探索式对话、创意生成

核心结论：Selector 策略在多角色专业团队中效果最好，但需要给 Manager 足够的角色描述，否则它会随机挑人。

4.5 人机协同：human_input_mode 与终止条件

AutoGen 在人机协同上的设计非常细致。UserProxyAgent 的 input_func 可以接入：

• 命令行输入
• Web UI 表单
• 企业 IM（钉钉、飞书、企微）
• 审批工作流

终止条件也不再是简单的关键词匹配，而是可以组合：

# 【实战代码】组合终止条件：最大轮数 + 关键词 + 自定义条件
from autogen_agentchat.conditions import (
    TextMentionTermination,
    MaxMessageTermination,
    StopMessageTermination,
)
from autogen_agentchat.base import TerminationCondition

termination = (
    TextMentionTermination("TERMINATE")
    | MaxMessageTermination(max_messages=20)
    | StopMessageTermination()
)

# 组合后：任一条件满足即结束对话

生产建议：不要只依赖关键词终止。建议同时设置 MaxMessageTermination，防止 Agent 陷入无限对话。

4.6 完整代码实战：多人评审代码生成

下面给出一个 4 人 Agent 团队的 AutoGen 示例：需求分析师、架构师、编码工程师、代码评审官，用 GroupChat 协作完成一个功能开发：

# 【实战代码】AutoGen v0.4 多人评审代码生成
import asyncio
from autogen_agentchat.agents import AssistantAgent, UserProxyAgent
from autogen_agentchat.teams import SelectorGroupChat
from autogen_agentchat.conditions import MaxMessageTermination, TextMentionTermination
from autogen_ext.models.openai import OpenAIChatCompletionClient

client = OpenAIChatCompletionClient(model="gpt-4o")

analyst = AssistantAgent(
    name="RequirementAnalyst",
    model_client=client,
    system_message=(
        "你是需求分析师。先把用户需求拆成清晰的功能点，然后交给架构师。"
        "完成后回复 TERMINATE。"
    ),
)

architect = AssistantAgent(
    name="Architect",
    model_client=client,
    system_message=(
        "你是架构师。根据需求设计模块结构与接口，然后交给编码工程师。"
    ),
)

coder = AssistantAgent(
    name="Coder",
    model_client=client,
    system_message=(
        "你是 Python 编码工程师。根据架构实现代码，写出完整可运行的 Python 代码。"
    ),
)

reviewer = AssistantAgent(
    name="Reviewer",
    model_client=client,
    system_message=(
        "你是代码评审官。检查代码是否满足需求、是否有明显 bug。"
        "如果通过则回复 TERMINATE，否则指出问题让 Coder 修改。"
    ),
)

user_proxy = UserProxyAgent(name="User", input_func=input)

termination = TextMentionTermination("TERMINATE") | MaxMessageTermination(max_messages=25)

team = SelectorGroupChat(
    participants=[user_proxy, analyst, architect, coder, reviewer],
    model_client=client,
    termination_condition=termination,
    selector_prompt=(
        "从 {participants} 中选择下一位发言人。"
        "需求分析师先发言，然后是架构师、编码工程师、评审官。"
        "User 只在需要人工确认时发言。"
    ),
)

async def main():
    await team.run(task="实现一个支持增删改查的内存级任务管理器（Task Manager）。")

if __name__ == "__main__":
    asyncio.run(main())

这个例子展示了 AutoGen 的几个典型特征：

• 角色分工通过 system_message 实现
• 流程控制通过 Selector + 终止条件实现
• 人类可以在关键环节介入
• 评审不通过时可以通过循环继续对话

4.7 工程调优与踩坑

AutoGen 落地时常见的坑：

坑	原因	解法
无限循环	终止条件太弱，Agent 互相推诿	使用组合终止条件，限制 max_messages
发言者选择错误	Selector 的提示不够明确	在 selector_prompt 中给出明确顺序
上下文爆炸	GroupChat 共享全部历史	定期总结或开启消息裁剪
人类输入卡住	input_func 在异步/流式环境中阻塞	使用异步 input_func 或 Web UI 封装
代码执行风险	AutoGen 默认可执行代码	使用 Docker 沙箱或关闭代码执行

安全警告：AutoGen 的 UserProxyAgent 默认会执行 LLM 生成的代码。生产环境必须限制执行权限，建议放入 Docker 容器或完全关闭代码执行能力。

---

五、CrewAI vs AutoGen vs LangGraph 横向对比

选型时通常不会只考虑一个框架，而是把 CrewAI、AutoGen、LangGraph 放在一起比较：

维度	CrewAI	AutoGen	LangGraph
核心隐喻	职场团队 / 任务清单	会议群聊 / 对话	状态图 / 工作流
流程控制	顺序或层级 Process	由 Manager / Selector 动态选择	显式节点与边，最精确
人机协同	较弱，主要依赖委托	原生支持，UserProxyAgent	通过 interrupt 节点支持
代码执行	依赖工具函数	原生代码执行（需注意安全）	依赖工具节点
上下文管理	任务级上下文传递	共享消息池	显式 State 传递
学习曲线	低	中	高
适合场景	报告生成、研究、内容生产	代码生成、多轮对话、人机协作	复杂循环、分支、中断恢复
可观测性	可接入 LangSmith	可接入 LangSmith / 原生追踪	与 LangSmith 原生深度集成

选型建议：

• 如果你的任务像"流水线作业"，先考虑 CrewAI。
• 如果你的任务像"开会在讨论"，先考虑 AutoGen。
• 如果你的任务需要精确的状态机控制，比如"审批流程 + 中断恢复 + 多分支"，考虑 LangGraph。
• 三者也可以组合：用 LangGraph 编排主流程，用 CrewAI 完成某个子任务，用 AutoGen 实现人机协作节点。

---

六、实战场景一：多 Agent 代码生成

下面这张图一并给出代码生成、舆情分析、智能客服三个场景的 Agent 编排流水线：

【场景一】代码生成（模拟软件开发团队）

  需求文档 ──▶  需求分析师 ──▶  架构设计师 ──▶  编码工程师 ──▶  测试工程师 ──▶  代码评审官 ──▶  交付
                                                    ▲               │
                                                    └───────────────┘   测试未通过则回退重做（上限 N 次）

【场景二】舆情分析（情报流水线）

  原始数据 ──▶  数据采集 ──▶  清洗去重 ──▶  情感判定 ──▶  归因分析 ──▶  报告撰写 ──▶  舆情简报

【场景三】智能客服（意图路由 + 领域专家 + 质检）

                           ┌──▶ 订单专家 ──┐
                           │               │
   用户提问 ──▶ 意图路由 ──┼──▶ 退款专家 ──┤──▶ 质检 Agent ──┬
                           │               │                 ┌──▶ 高分：直接回复
                           └──▶ 技术专家 ──┘                 └──▶ 低分：转人工

   三条流水线的共同点：角色专业化 + 阶段化上下文 + 终末质量把关

6.1 场景描述

多 Agent 代码生成不是"一个 AI 写代码"，而是模拟一个微型软件开发团队：需求分析 → 架构设计 → 编码实现 → 单元测试 → 代码评审。每个阶段由专门 Agent 负责，不通过则回退。

6.2 角色设计

角色	职责	使用框架
需求分析师	把模糊需求拆成明确功能点	CrewAI / AutoGen
架构师	设计模块结构与接口	CrewAI / AutoGen
编码工程师	实现代码	CrewAI / AutoGen
测试工程师	编写并运行单元测试	AutoGen（可执行代码）
代码评审官	检查质量并决定是否通过	AutoGen

6.3 流程设计

需求文档
  ↓
需求分析师 → 拆成功能点
  ↓
架构师 → 设计接口
  ↓
编码工程师 → 实现代码
  ↓
测试工程师 → 运行测试
  ↓
未通过 ──→ 返回编码工程师
  ↓ 通过
代码评审官 → 给出评审意见
  ↓
最终交付

6.4 示例：用 AutoGen 实现带反馈循环的代码生成

# 【实战代码】AutoGen 多 Agent 代码生成（含测试反馈循环）
import asyncio
from autogen_agentchat.agents import AssistantAgent
from autogen_agentchat.teams import SelectorGroupChat
from autogen_agentchat.conditions import MaxMessageTermination, TextMentionTermination
from autogen_ext.models.openai import OpenAIChatCompletionClient

client = OpenAIChatCompletionClient(model="gpt-4o-mini")  # 成本更低

analyst = AssistantAgent(
    name="Analyst",
    model_client=client,
    system_message="你是需求分析师，把用户需求拆成 3-5 条可验证的功能点。",
)

architect = AssistantAgent(
    name="Architect",
    model_client=client,
    system_message="你是架构师，根据功能点设计 Python 模块和函数签名。",
)

coder = AssistantAgent(
    name="Coder",
    model_client=client,
    system_message="你是 Python 工程师，编写完整可运行代码。",
)

tester = AssistantAgent(
    name="Tester",
    model_client=client,
    system_message="你是测试工程师，编写 pytest 用例并运行。发现 bug 则返回给 Coder。",
)

reviewer = AssistantAgent(
    name="Reviewer",
    model_client=client,
    system_message="你是代码评审官。代码与测试都通过时回复 TERMINATE。",
)

team = SelectorGroupChat(
    participants=[analyst, architect, coder, tester, reviewer],
    model_client=client,
    termination_condition=TextMentionTermination("TERMINATE") | MaxMessageTermination(30),
    selector_prompt=(
        "选择下一位发言人。顺序：Analyst → Architect → Coder → Tester → Reviewer。"
        "Tester 发现 bug 时返回 Coder；Reviewer 通过时回复 TERMINATE。"
    ),
)

async def main():
    await team.run(task="实现一个支持优先级和截止日的待办清单 CLI 工具。")

if __name__ == "__main__":
    asyncio.run(main())

关键设计：通过 selector_prompt 把"测试不通过回退编码"的规则写进去，而不是在代码里硬编码 if/else。这种方式更灵活，但也对 LLM 的指令遵循能力提出更高要求。

---

七、实战场景二：舆情分析

7.1 场景描述

舆情分析通常涉及采集、清洗、情感判定、归因、报告撰写多个环节。用多 Agent 架构可以自然地把每个环节封装为独立角色，便于独立优化和复用。

7.2 角色设计

角色	职责	关键工具
数据采集 Agent	从社交媒体、新闻、论坛抓取原始文本	爬虫、API
数据清洗 Agent	去重、去噪、格式化	文本处理工具
情感判定 Agent	对每条文本做情感极性分析	情感分析模型
归因分析 Agent	找出舆情爆发的关键事件与传播路径	事件抽取、图谱
报告撰写 Agent	生成舆情日报/周报	汇总工具

7.3 流程设计

数据源
  ↓
采集 Agent → 原始文本
  ↓
清洗 Agent → 结构化数据
  ↓
情感 Agent → 情感标签
  ↓
归因 Agent → 事件与原因
  ↓
报告 Agent → 舆情简报

7.4 示例：用 CrewAI 实现舆情分析流水线

# 【实战代码】CrewAI 舆情分析流水线（简化版）
from crewai import Agent, Task, Crew, Process
from langchain_openai import ChatOpenAI

llm = ChatOpenAI(model="gpt-4o", temperature=0.2)

crawler = Agent(role="数据采集员", goal="收集目标话题的公开讨论文本", backstory="擅长从社交媒体获取文本。", llm=llm)
cleaner = Agent(role="数据清洗员", goal="去除垃圾信息与重复内容", backstory="擅长文本去噪。", llm=llm)
sentiment = Agent(role="情感分析师", goal="判定每条文本的情感极性", backstory="擅长中文情感分析。", llm=llm)
attribution = Agent(role="归因分析师", goal="找出舆情爆发的事件与原因", backstory="擅长事件抽取与因果推断。", llm=llm)
reporter = Agent(role="舆情报告员", goal="撰写舆情简报", backstory="擅长把分析结果改写成新闻稿。", llm=llm)

t1 = Task(description="采集关于『某手机品牌新品发布』的公开讨论文本，30 条以内。", expected_output="30 条去 PII 的文本列表", agent=crawler)
t2 = Task(description="清洗上一步采集的文本，去除重复、广告、无意义内容。", expected_output="清洗后的文本列表", agent=cleaner, context=[t1])
t3 = Task(description="对清洗后的文本逐条判定情感（正面/负面/中性），并说明理由。", expected_output="情感标签与理由列表", agent=sentiment, context=[t2])
t4 = Task(description="基于情感分析结果，找出引发负面情绪的主要事件与传播路径。", expected_output="事件归因说明", agent=attribution, context=[t2, t3])
t5 = Task(description="撰写一份舆情简报，含摘要、情感分布、关键事件、建议。", expected_output="Markdown 舆情简报", agent=reporter, context=[t3, t4])

crew = Crew(agents=[crawler, cleaner, sentiment, attribution, reporter], tasks=[t1, t2, t3, t4, t5], process=Process.sequential)
result = crew.kickoff()
print(result)

注意：真实舆情分析还需要处理反爬、数据合规、多语言、实时性等问题。上述示例展示的是多 Agent 架构如何适配该场景。

---

八、实战场景三：智能客服

8.1 场景描述

智能客服系统通常由"意图路由 + 领域专家 + 质检 + 人工兜底"组成，天然适合多 Agent 架构。核心目标是：用户问题先被路由到最合适的专家 Agent，专家给出答复后由质检 Agent 评分，低分则转人工。

8.2 角色设计

角色	职责	触发条件
意图路由 Agent	识别用户意图并分派	每次用户提问
订单专家 Agent	处理订单、物流、退换货	意图命中"订单"
退款专家 Agent	处理退款、售后政策	意图命中"退款"
技术专家 Agent	处理产品使用问题	意图命中"技术支持"
质检 Agent	评估答复质量	每次专家答复后
人工兜底	处理复杂投诉	质检分低于阈值

8.3 流程设计

用户提问
  ↓
意图路由 Agent
  ↓
订单 / 退款 / 技术 专家 Agent
  ↓
质检 Agent 评分
  ↓
高分 → 直接回复用户
低分 → 转人工

8.4 示例：用 AutoGen SelectorGroupChat 实现智能客服

# 【实战代码】AutoGen 智能客服路由 + 专家 + 质检
import asyncio
from autogen_agentchat.agents import AssistantAgent, UserProxyAgent
from autogen_agentchat.teams import SelectorGroupChat
from autogen_agentchat.conditions import TextMentionTermination, MaxMessageTermination
from autogen_ext.models.openai import OpenAIChatCompletionClient

client = OpenAIChatCompletionClient(model="gpt-4o")

router = AssistantAgent(
    name="Router",
    model_client=client,
    system_message="你是客服路由员。识别用户意图并 @ 对应的专家，不要自己直接回答。",
)

order_agent = AssistantAgent(name="OrderExpert", model_client=client, system_message="你是订单专家，处理订单、物流、退换货。")
refund_agent = AssistantAgent(name="RefundExpert", model_client=client, system_message="你是退款专家，处理退款、售后政策。")
tech_agent = AssistantAgent(name="TechExpert", model_client=client, system_message="你是技术支持专家，处理产品使用问题。")
qc_agent = AssistantAgent(
    name="QualityCheck",
    model_client=client,
    system_message="你是质检员。对专家回答打分（1-10），低于 7 分则要求转人工。",
)
user = UserProxyAgent(name="Customer", input_func=input)

team = SelectorGroupChat(
    participants=[user, router, order_agent, refund_agent, tech_agent, qc_agent],
    model_client=client,
    termination_condition=TextMentionTermination("END") | MaxMessageTermination(20),
    selector_prompt=("对话顺序：Customer 提问 → Router 选专家 → 专家回答 → QC 评分。高分回复 END，低分转人工。"),
)

async def main():
    await team.run(task="我的订单为什么还没发货？")

if __name__ == "__main__":
    asyncio.run(main())

生产要点：意图路由 Agent 也可以使用独立的分类模型（BERT/小模型）替代 LLM，以降低延迟与成本。

---

九、选型建议与决策树

基于前面的对比，下面给出一个简化决策树：

你的任务更像哪种工作模式？
├── 流水线 / 任务清单 / 有明确先后顺序
│   └── 优先 CrewAI
├── 会议讨论 / 群聊 / 人机协作 / 代码生成
│   └── 优先 AutoGen
├── 复杂状态机 / 审批流 / 中断恢复 / 精确控制
│   └── 优先 LangGraph
└── 以上皆有
    └── 混合方案：LangGraph 编排主流程 + CrewAI/AutoGen 做子任务

选型时还要考虑：团队现有技术栈（Python/TypeScript）、是否需要代码执行、是否有 LangChain 生态积累、数据合规要求、成本预算。

---

十、成本、可靠性与工程化落地

10.1 成本控制：多 Agent = 多倍调用

多 Agent 架构的直接代价是 LLM 调用次数增加。控制成本的常用策略：

策略	做法	效果
模型分层	简单任务用 gpt-4o-mini / claude-haiku，复杂任务才用 gpt-4o / claude-sonnet	成本可降 5-10 倍
缓存重复调用	对稳定的工具调用结果做缓存	减少重复推理
上下文压缩	定期总结历史，只保留摘要	token 显著下降
采样与限流	非关键 Agent 降低采样率	平衡成本与效果
本地小模型	意图分类、简单抽取用本地模型	进一步降低成本

10.2 可靠性：循环、超时、熔断

多 Agent 系统中 Agent 可能互相触发，导致不可控的循环。必须设置护栏：

# 【实战代码】多 Agent 系统的护栏配置示意
SAFEGUARDS = {
    "max_turns": 20,          # 最大对话轮数
    "max_execution_time": 120,  # 单次执行最大秒数
    "max_token_per_session": 20000,  # 单会话 token 上限
    "retry_on_error": 2,      # 错误重试次数
    "circuit_breaker": True,  # 连续失败 3 次熔断
}

10.3 可观测性落地

无论使用哪种框架，都建议接入追踪工具：

• CrewAI：通过设置 LANGSMITH_TRACING=true 即可自动追踪（CrewAI 基于 LangChain）
• AutoGen：可通过 autogen-agentchat 的日志记录，或手动包装 @traceable
• LangGraph：与 LangSmith 原生深度集成，trace 自动呈现为图结构

10.4 从 POC 到生产

多 Agent 项目建议分阶段落地：

1. 阶段一：单 Agent 跑通：先用一个 Agent 解决核心问题
2. 阶段二：拆分为 2-3 个 Agent：明确角色与任务边界
3. 阶段三：引入编排与回退：处理循环、异常、回退
4. 阶段四：接入追踪与评估：建立可观测性与质量门禁
5. 阶段五：成本优化与扩展：模型分层、缓存、上下文压缩

核心结论：多 Agent 不是银弹。只有在单 Agent 遇到瓶颈时，才应该引入多 Agent。过早拆分会导致复杂度失控。

---

十一、常见反模式与踩坑

11.1 反模式一：Agent 过多

一个团队里放 8-10 个 Agent，每个 Agent 职责边界模糊。结果是 Manager 或 Selector 选错人，token 爆炸，调试困难。

建议：先 2-3 个 Agent 跑通，再按需增加。每个新增 Agent 都要有明确的职责和不可替代性。

11.2 反模式二：把多 Agent 当装饰

为了"显得高级"而拆分，实际上每个 Agent 只做同样的事情。这不会提升质量，只会增加延迟。

建议：拆分必须带来真实的专业化收益，否则不如单 Agent + 好的系统提示。

11.3 反模式三：忽视终止条件

只依赖"Agent 自己决定结束"，结果对话无限循环。

建议：始终配置组合终止条件：关键词 + 最大轮数 + 最大时间。

11.4 反模式四：完全信任 Agent 的代码执行

让 AutoGen 在生产环境直接执行 LLM 生成的代码，可能导致安全事故。

建议：代码执行必须在沙箱（Docker、Firecracker）中，或完全关闭执行能力。

11.5 反模式五：缺乏评估闭环

多 Agent 上线后只看"有没有输出"，不看"输出对不对"。

建议：每个子任务都要有评估器（规则 / LLM-as-judge / 人工抽检），建立 Bad Case 数据集。

---

核心总结

多 Agent 框架是一种用于构建和管理多个智能体（Agent）协作系统的技术架构，旨在通过分工协作解决复杂问题。本文从通用架构、框架原理、代码实战三个层面进行了系统剖析：

1. 通用架构：多 Agent 系统可抽象为应用层、编排层、协作层、Agent 层、能力层、模型层六层，通信机制决定上下文可见范围，状态一致性与可观测性是工程落地的关键。
2. CrewAI：以角色分工和任务调度为核心，通过 Agent + Task + Crew + Process 四件套构建团队。Process.sequential 适合流水线，Process.hierarchical 适合动态协调。context 与 allow_delegation 实现了任务依赖与委托。
3. AutoGen：以多轮对话和人机协同为核心，通过 ConversableAgent、GroupChat 和 SelectorGroupChat 实现灵活的群聊协作。UserProxyAgent 提供人机协同入口，组合式 TerminationCondition 保证对话收敛。
4. 横向对比：CrewAI 适合任务清单式协作，AutoGen 适合会议讨论式协作，LangGraph 适合精确状态机编排。三者可以混合使用。
5. 落地场景：代码生成、舆情分析、智能客服都可以通过多 Agent 架构获得更清晰的角色边界与更高的可维护性。
6. 工程化：成本控制（模型分层、缓存、上下文压缩）、可靠性（循环、超时、熔断）、可观测性（追踪、评估、告警）是多 Agent 项目从 POC 走向生产的关键。

一句话总结：多 Agent 的本质不是"让多个 LLM 一起聊天"，而是"把复杂问题拆成专业化角色，并通过可观测的工程机制保证协作可靠、成本可控"。

---

时效性声明与参考资料

重要提示：本文基于 CrewAI 0.x、AutoGen v0.4 及 LangGraph 当前版本撰写，各框架 API、模型定价、支持模型会随版本迭代而变化。文中示例代码以展示架构思路为主，生产使用前请对照官方文档确认接口与安全性。

• CrewAI 官方文档：https://docs.crewai.com
• AutoGen 官方文档：https://microsoft.github.io/autogen/
• LangGraph 官方文档：https://langchain-ai.github.io/langgraph/
• LangSmith 追踪文档：https://docs.smith.langchain.com