1.4 与其他 Agent 框架的对比分析（如 AutoGen、LangChain）
1.4 与其他 Agent 框架的对比分析（如 AutoGen、LangChain）
本节约处在第一章第四站。选型最怕被名词绕晕：AutoGen 也讲 Agent，LangChain 也有链，LangGraph 也能画状态机，CrewAI 看起来像在重复造轮子。事实是它们的协作模型根本不同——差异不在功能清单，而在"谁来决定下一步干什么"。这张表先把关键维度摆平。
横向对比（按"协作由谁决定"这一
横向对比（按"协作由谁决定"这一主轴线）：
| 维度 | CrewAI | AutoGen | LangGraph |
|---|---|---|---|
| 协作控制权 | 开发者声明 Process | Agent 间对话自协商 | 图节点与边显式编排 |
| 结果可预测性 | 高（顺序模式） | 中低，依赖收敛 | 高，但图要自己画 |
| 学习曲线 | 平缓 | 平缓但调试难 | 较陡 |
| 与 LangChain 关系 | 独立实现 | 独立，生态自有 | 建立在 LangChain 之上 |
| 最佳场景 | 固定多角色工作流 | 开放式探索、群聊 | 复杂有环状态流转 |
| 额外成本来源 | 角色多了 token 涨 | 对话轮次不可控 | 图设计与维护人力 |
看出门道了吗？CrewAI 和
看出门道了吗？CrewAI 和 LangGraph 其实都在"把流程显式化"，区别是 CrewAI 用更高层的角色/任务抽象、LangGraph 用更底层的图。AutoGen 是另一条路：它把协作交还给 Agent 对话，灵活但你要接受"同一输入多次跑结果可能不同"。
用一个"让两个角色合作写报告"的例子，体会代码层面的差异。CrewAI 的写法强调绑定与顺序：
# 1.4 与其他 Agent 框架的对比分析（如 AutoGen、LangChain） from crewai import Agent, Task, Crew, Process a1 = Agent(role="分析师", goal="出结论", backstory="严谨", verbose=True) a2 = Agent(role="写手", goal="成文", backstory="通顺", verbose=True) t1 = Task(description="分析数据", expected_output="结论三点", agent=a1) t2 = Task(description="写成报告", expected_output="报告全文", agent=a2, context=[t1]) crew = Crew(agents=[a1, a2], tasks=[t1, t2], process=Process.sequential)
而 AutoGen 的近似思路是两个 Agent 通过对话互相传递消息，由对话自然推进，没有"任务依赖"这种显式结构：
# 两个 agent 通过 initiate_chat / 回复链传递，顺序由对话内容决定
注意上面 AutoGen 片段只是说明"协作模型不同"，不要在本教程环境里直接运行。关键区别是：CrewAI 里 t2 明确 context=[t1]，东西从哪来到哪去写在代码里；AutoGen 里要靠对话内容把上下文带过去，跑多了你会发现有轮次模型聊偏了。
那么什么时候不选 CrewAI？如果你的任务里有大量"根据上一步结果动态决定要不要走分支、走哪条"，图的表达力更强，LangGraph 更顺手；如果你的任务本质是"几个专家自由讨论出一个答案"，AutoGen 的群聊更自然。CrewAI 的甜区是：流程大体固定、角色分工清晰、你要对每个环节的产出负责。
还有一个现实考量：依赖与维护。CrewAI 不绑 LangChain，意味着它升级不会被迫跟着 LangChain 的大版本走，这对长期项目是隐性收益。反之，如果你整套技术栈已经重度使用 LangChain，为了统一而选 LangGraph 也合理——工程一致性有时比单点最优更重要。
最后提醒一个选型陷阱：别因为"多智能体"这个词时髦就上。我们见过把单链路 RAG 硬拆成"检索 Agent + 回答 Agent"反而变慢变贵的案例。判定标准是第一章 1.2 提过的——任务能不能切、切完每段能不能独立验收。能，才值得框架化。
下一节我们不再比名词，直接装上
下一节我们不再比名词，直接装上 CrewAI，把上面所有概念变成可运行的第一个 Crew。
同一件事，三种框架写法不同
选型时最容易迷糊的是：别的框架里"智能体"和"任务"是合并的还是换名了。下面用"两 agent 串行写一篇稿"这个最小需求，横向对比写法差异，看清 CrewAI 的取舍。
| 框架 | 核心抽象 | 编排方式 | 上手成本 | 适合谁 |
|---|---|---|---|---|
| CrewAI | Agent/Task/Crew/Process | 声明式、角色分工 | 低 | 想快速搭多角色协作 |
| LangChain | Chain/Runnable | 偏向单链路编排 | 中 | 已有 LangChain 栈 |
| AutoGen | UserProxy/Assistant | 对话驱动、可群聊 | 中高 | 偏研究、对话博弈 |
⚠️ 常见坑：不要为了"用 Agent"而用 CrewAI。如果你的需求本质是一个单 agent 调几个工具，直接上 LangChain 的链或一个独立 Agent 更轻；CrewAI 的价值在多角色、多任务、需要明确分工协作时才会显出来。强行把单链路拆成 Crew，只会多付几次 LLM 调用。
下面用 CrewAI 表达"研究员→写手"协作，注意它和 LangChain 链的区别在于：角色是独立人格，而非函数节点。
from crewai import Agent, Task, Crew, Process researcher = Agent(role="行业研究员", goal="找出趋势", backstory="看数据说话", verbose=True) writer = Agent(role="科技记者", goal="写通俗稿", backstory="会讲故事", verbose=True) t_research = Task(description="调研新能源趋势", expected_output="三条趋势", agent=researcher) t_write = Task(description="据此写稿", expected_output="一篇稿", agent=writer, context=[t_research]) crew = Crew(agents=[researcher, writer], tasks=[t_research, t_write], process=Process.sequential) article = crew.kickoff() print(article)
💡 关键直觉：CrewAI 把"谁来做"和"做什么"拆成两个对象，这点和 AutoGen 把对话角色当 Agent 的取向不同。当你需要稳定的角色分工、可复现的产出格式时，CrewAI 的声明式写法更省心；当你需要开放式多轮对话博弈时，AutoGen 更顺手。
# 若改用 hierarchical，则由经理决定调研与写稿是否要加一步复核 manager_llm = "gpt-4o-mini" crew2 = Crew(agents=[researcher, writer], tasks=[t_research, t_write], process=Process.hierarchical, manager_llm=manager_llm)