5.4 框架对照：LangGraph、AutoGen、CrewAI 的分工哲学
5.4 框架对照：LangGraph、AutoGen、CrewAI 的分工哲学
本节摘要：主流框架对"智能体该怎么组织"给出了三种不同的答案：LangGraph 说控制流是图，AutoGen 说协作是对话，CrewAI 说队伍是角色。本节对照三者的核心抽象与适用边界，给出一条务实的选型决策路径——包括"不用框架"这个常被遗忘的选项。
前几章手写的循环、协议、拓扑，在框架里都有对应的抽象。框架的价值不是魔法，而是把你本来要自己管的东西制度化：状态流转、消息传递、重试兜底。理解了前几章，框架文档里的每个概念都能对号入座；反过来，没手写过就上框架，遇到问题时你分不清是模型的问题还是框架的问题。
三种哲学，三套抽象
LangGraph：控制流即状态图。它把智能体系统建模成一张显式的图——节点是处理步骤（一次模型调用、一个工具执行），边是流转条件（含条件分支与循环）。你画的图就是全部控制流，状态在节点间显式传递。这是三者中对第 2、4 章的手写循环还原度最高的抽象：循环、分支、并行、人工介入点全都长在图上，可审计可回放。代价是表达繁琐——简单的顺序任务也要定义节点与边，仪式感重。
AutoGen：协作即对话。它的核心抽象是"可对话的智能体"：每个智能体是一个会收发消息的角色，系统靠让它们互发消息来推进任务，两两对话或组群聊皆可。第 5.2 节的消息协议在这里被内建成会话机制，主管型与辩论型拓扑写起来最顺手。代价是控制流藏在对话的来回里，任务复杂后"谁在什么时候为什么说了什么"需要额外梳理，精确控制不如图直观。
CrewAI：队伍即角色分工。它把组织行为学搬进来：定义一支队伍（Crew），每个成员有角色（role）、目标（goal）、背景故事（backstory），按流程（顺序或分层）协作。它对第 5.1 节"角色混杂"问题的回应最直接——每个角色的契约天然分开写。代价是灵活性换简洁：复杂控制流（条件分支、动态组队）表达起来别扭，适合职责边界清晰的流水线型协作。
LlamaIndex 也常被并列提及，定位略有不同：它的重心在数据接入与检索（与第 6 章 RAG 衔接），智能体编排是附属能力，此处不展开对照。
概念对照表：同一个东西在三家的名字
| 概念 | LangGraph | AutoGen | CrewAI |
|---|---|---|---|
| 一个决策单元 | 节点（函数/智能体） | 智能体（会话参与者） | 成员（角色） |
| 控制流 | 显式的边与条件 | 消息往来隐式形成 | 顺序或分层流程 |
| 状态传递 | 共享 State 对象 | 对话历史 | 上下文注入 |
| 多智能体拓扑 | 图上任意拓扑 | 群聊 / 两两对话 | 预设的队伍结构 |
| 人工介入点 | 图上的人工审批节点 | 会话中的人类代理 | 流程中的检查步骤 |
| 与手写代码的关系 | 最近（图节点就是函数） | 中等 | 较远（按它的范式来） |
选型决策路径
按顺序问四个问题，多数团队在第二问就该停下：
- 任务是否只是"几个工具加一个循环"？ 是——直接手写（第 2 章的代码量级），引入框架纯属负债。
- 需要复杂控制流吗（条件分支、循环、并行、显式人工审批）？需要——LangGraph 的图模型最对口，前几章的手写经验可以逐节点迁移。
- 核心矛盾是对话协作吗（多角色商议、辩论、群聊推进）？是——AutoGen 的会话抽象最省事。
- 任务是不是清晰的分工流水线（角色固定、工序明确）？是——CrewAI 的角色范式表达最快。
还有一条常被忽略的横向考量：框架是租金不是资产。选框架意味着接受它的抽象升级、接口变更与排查黑盒。核心资产应当是自己的工具层、记忆层与评测集（第 7 章）——这些在任何框架下都能复用；框架只该出现在"编排"这一薄层，随时可换。
案例：一次从框架回到手写的回迁
背景：一个五步的报表生成任务，最初为了赶进度直接上了某个编排框架，功能很快跑通。
操作：两个月后排查一起"偶发漏步骤"的故障时，团队发现需要通读框架源码才能确认调度行为，升级一次依赖又带来接口变更。他们做了回迁评估：任务控制流本质是固定四步加一个条件分支，手写约两百行。
结果：回牵手写循环后，调度行为完全透明，故障当场定位为工具超时未重试；框架依赖移除，部署体积缩小，升级焦虑清零。
解读：这个案例不是反框架，而是框架的性价比会随任务复杂度反转——复杂任务里框架的制度化管理是救命稻草，简单任务里它就是纯租金。判断复杂度的口径不是功能多少，而是控制流里有没有"说不清顺序"的分支与循环。
变式：多框架并存也常见——检索层用 LlamaIndex 的数据接入，编排层用 LangGraph，队内协作逻辑手写。前提是层与层之间用自己定义的接口隔离，别让任何框架的类型渗透进业务代码。
⚠️ 常见坑：以"简历友好"或"社区热度"定框架。框架选型的唯一裁判是任务的控制流形态——图状的、对话状的、角色状的，各自去找对口的抽象，别让任务去削足适履。
本节要点回顾
- 三种哲学：控制流是图（LangGraph）、协作是对话（AutoGen）、队伍是角色（CrewAI）——先看任务形态再认抽象。
- 概念可互译：节点、智能体、成员说的是同一个决策单元；前几章的手写经验是读懂一切框架的底座。
- 决策四问：简单任务手写，复杂控制流找图，对话协作找会话，角色流水线找队伍。
- 框架是租金：核心资产是工具、记忆、评测这些可迁移层；编排层的依赖越薄越好。
队伍的组织与选型到此讲透。下一章转向另一类"借力"：怎么让智能体接上外部世界的实时知识与现成工具——RAG 与工具生态。
概念翻译练习：手写代码到框架语汇
选型之前做一次"翻译练习"能快速判断匹配度：把第 2 章手写的循环，逐部件翻译成目标框架的概念，看哪些部件有现成对应、哪些要削足适履。以 LangGraph 为例——ReActAgent 类变成一张图：llm.chat 是节点、条件边承载"有无工具调用"的分支、观察回填是边上的状态更新、max_steps 兜底是图上的全局计数器；再以 AutoGen 为例——主管与队员变成一组 conversable agent，5.2 节的协议信封内化成会话机制，round_no 对应会话轮次上限。翻译顺畅的框架就是好匹配；翻译时发现核心机制（比如违约自修、指纹防打转）找不到安放位置的框架，要么它替你想了别的方案（先读懂再采用），要么它不适合这个任务。
这项练习还有一个隐性收益：框架抽象的学习成本主要花在"概念对号"上，手写经验越扎实，对号越快——本章与第 2、4 章的代码，就是为这次对号准备的对照表。