第十二章 框架对比与选型¶

导读¶

前几章我们从底层讲清了 LLM、RAG、ReAct、Function Calling、规划反思、记忆、MCP、多 Agent——这些都是 Agent 的"砖瓦"。现在的问题是：要不要从零用砖瓦砌一座房子？还是用现成的脚手架？框架不是银弹——选错框架上限低、迁移成本高；选对框架让团队专注业务而非造轮子。本章比较 5 个主流 Agent 框架：LangGraph（图编排，生产首选）/ CrewAI（角色化多 Agent，快速原型）/ AutoGen（Microsoft 对话式多 Agent，研究友好）/ OpenAI Swarm（轻量 handoff，已不再维护但思想重要）/ AutoGPT-BabyAGI（早期尝试，已退场）。对每个框架讲清核心抽象、典型用法、优势与局限。最后给选型决策矩阵——什么场景选什么框架。读完本章你能为自己的项目选对框架，避免"框架选错项目上限低"的坑。

12.1 LangGraph¶

来源：LangGraph 是 LangChain 团队推出的"下一代"Agent 编排框架（github.com/langchain-ai/langgraph），2024 年初发布。LangChain 早期用 Chain（线性顺序）抽象 Agent，但线性 Chain 难以表达循环 / 条件分支 / 多 Agent 协作——LangGraph 改用图（graph）抽象，让任意拓扑都能表达。

核心抽象：StateGraph + nodes + edges + state¶

LangGraph 的核心抽象是 StateGraph——一个有向图，节点（nodes）是 Agent 或函数，边（edges）是控制流。每个图有一个**共享 state**（typed dict / Pydantic），所有节点读写这个 state。节点接收 state、修改 state、返回更新——state 在节点之间流转。条件边（conditional_edges） 是 LangGraph 的精髓——一个节点结束后，按 state 的某字段路由到不同下一个节点（如 critic 节点根据 pass=true / false 路由到 END 或回到 executor）。条件边让 LangGraph 能表达循环（critic 不满意回到 executor 重做）、分支（不同任务类型走不同处理流水）、收敛（多 Agent 结果汇到主管）。checkpoint 是 LangGraph 的另一个核心特性——图的 state 在每个节点结束自动存档，任何节点都能断点续跑——生产上 Agent 跑到一半挂了能从最近 checkpoint 恢复。

与 LangChain 的关系¶

LangGraph 与 LangChain 的关系是"下一代"而非"替代"——LangChain 是父项目（提供 LLM 调用 / 工具 / 文档加载等基础抽象），LangGraph 是子项目（专门做 Agent 编排）。LangGraph 复用 LangChain 的 LLM / Tool / Retriever 等基础组件，但在 Agent 编排层完全重写——从线性 Chain 改成图。新项目应该用 LangGraph 而非老 LangChain Agent（老 LangChain 的 AgentExecutor 已被官方标记为 legacy，推荐迁到 LangGraph）。

适用场景¶

LangGraph 适合**生产复杂流程**——多步骤 / 多 Agent / 有循环 / 有条件分支的 Agent 系统。典型场景：客服系统（主管 + 多子 Agent + 工具调用 + 重试）、代码生成 Agent（规划 → 写代码 → 测试 → 修 bug 循环）、研究助手（多步检索 + 多步推理 + 中间结果汇总）。LangGraph 的图抽象让复杂流程可视化、可调试、可恢复。

优势¶

第一，图抽象表达力强——任意拓扑（线性 / 树 / 图 / 循环）都能表达。第二，typed state——共享 state 用 Pydantic / TypedDict 类型化，便于校验与调试。第三，checkpoint——state 自动存档，支持断点续跑与时间旅行调试（回到任意历史 state 看）。第四，LangSmith 集成——LangGraph 与 LangSmith trace 无缝集成，每步 trace 可视化。第五，生态成熟——基于 LangChain 大生态，工具 / Retriever / Vector store 都现成可用。

局限¶

第一，学习曲线陡——图 / state / 条件边 / checkpoint 概念多，新手要 1-2 周上手。第二，过度抽象——简单任务用 LangGraph 是过度设计，单 Agent + 几个工具用普通 Python 写更清楚。第三，LangChain 生态绑定——用 LangGraph 默认也用 LangChain 工具，迁出 LangChain 生态有成本。

LangGraph 的典型代码结构¶

LangGraph 的典型代码结构三段式：第一段定义 State——用 TypedDict 或 Pydantic 描述共享 state 的字段与类型，每个字段有明确语义（如 task / plan / result / critic_pass）；第二段定义 节点函数——每个节点是一个 Python 函数，接收 state、返回 state 的部分更新（dict）；第三段 组装图——StateGraph(State) 创建图，add_node 注册节点，add_edge 加固定边，add_conditional_edges 加条件边（按 state 字段路由），最后 compile() 编译成可执行图。这种"声明式"组装让 Agent 拓扑可视化（用 app.get_graph().draw_mermaid() 生成 Mermaid 图），新人读代码先看图组装段就能理解整个 Agent 的拓扑——比命令式 if-else 控制流可读得多。生产 LangGraph 项目建议把 State / 节点 / 图组装分三个目录组织，便于多人协作维护。

LangGraph 的生产化要点¶

LangGraph 生产化几个关键要点：第一，checkpoint 用持久化后端——开发用 MemorySaver（内存）够，生产要接 Postgres / Redis 持久化 checkpoint，进程重启不丢 state。第二，streaming 输出——用户等 Agent 跑完几分钟太长，用 app.stream() 流式输出每个节点的中间结果，前端实时显示进度。第三，interrupt 中断——app.invoke(input, config={"configurable": {"interrupt_before": ["human_node"]}}) 在指定节点前中断等人工输入，实现 human-in-the-loop。第四，并发节点——add_node 注册的多个节点可以用 add_parallel_edges 并发执行，提升多子 Agent 并行速度。第五，subgraph 嵌套——一个图可以作为另一个图的节点，便于构建层级多 Agent 系统。这些生产化特性让 LangGraph 不只是"图编排库"而是"生产 Agent 平台"——是它与 CrewAI / AutoGen 拉开差距的关键。

12.2 CrewAI¶

来源：CrewAI 是 João Moura 2024 年初开源的角色化多 Agent 框架（github.com/crewAIInc/crewAI），定位"多 Agent 协作框架"——让多 Agent 协作像组建一个团队（crew）一样简单。

核心抽象：Agent + Task + Crew + Process¶

CrewAI 的核心抽象是 Agent（角色化 Agent）+ Task（任务）+ Crew（团队）+ Process（协作模式）。Agent 定义一个角色——有 Role（角色名）/ Goal（目标）/ Backstory（背景故事）/ Tools（可用工具）。Task 定义一个任务——有 description / expected_output / agent（指派给谁）。Crew 把多个 Agent 与多个 Task 组成一个团队，指定 Process（sequential 串行 / hierarchical 层级主管模式）。Crew 跑起来后按 Process 把 Task 分派给 Agent 执行，结果汇总返回。

适用场景¶

CrewAI 适合**角色清晰、任务可拆**的快速原型场景——如"内容创作团队"（撰稿 Agent + 编辑 Agent + 校对 Agent）、"市场分析团队"（调研 Agent + 分析 Agent + 报告 Agent）。CrewAI 的角色化抽象让"组建团队"非常直观——读 prompt 的人立刻能理解每个 Agent 干什么。

优势¶

第一，学习曲线缓——角色化抽象符合直觉，新手 1 天能上手。第二，declarative 配置——CrewAI 的 Crew 可以用 YAML 声明，无需写代码。第三，角色清晰——每个 Agent 的 Role / Goal / Backstory 让 prompt 工程结构化。第四，内置 hierarchical 模式——自动有主管 Agent 协调，无需自己写调度逻辑。

局限¶

第一，灵活性中——CrewAI 的 Process 只支持 sequential 与 hierarchical 两种，复杂图拓扑表达不了（不如 LangGraph 灵活）。第二，可观测性中——CrewAI 自带 trace 但不如 LangSmith 详细。第三，适合中等规模——超大规模多 Agent 系统用 CrewAI 会遇到性能与可观测性瓶颈，迁到 LangGraph。第四，与 LangChain 关系——CrewAI 默认用 LangChain 的 LLM 与 Tool 抽象，迁出 LangChain 生态有成本（与 LangGraph 类似）。

CrewAI 的 YAML 声明式配置¶

CrewAI 的 declarative 配置让"组建团队"像写配置文件——把 Agent 与 Task 用 YAML 声明，无需写 Python 代码。典型 YAML 片段：agents: - name: "撰稿" role: "资深撰稿" goal: "写 800 字博客" backstory: "10 年内容创作经验"；tasks: - description: "写 X 主题博客" agent: "撰稿"；crew: agents: [撰稿, 编辑, 校对] tasks: [写博客, 编辑, 校对] process: sequential。这种 declarative 方式让非工程师（产品 / 业务）也能组装 Agent 团队——读 YAML 立刻理解每个 Agent 干什么。生产上建议把 YAML 与 Python 代码分离——YAML 定义团队结构、Python 定义工具实现，便于分工（业务团队改 YAML、工程团队改工具）。但 YAML 声明力有限——复杂条件路由 / 循环 / 状态校验还是要回到 Python。

CrewAI 的 hierarchical 模式细节¶

CrewAI 的 hierarchical 模式（即 Supervisor 模式，与第 11 章呼应）有几个工程细节：第一，自动 manager Agent——CrewAI 在 hierarchical 模式自动创建一个 manager Agent，负责把 Task 分派给最合适的 Agent；第二，manager 的 prompt——CrewAI 给 manager 默认 prompt 是"按 Task 描述与 Agent 能力分派任务"，可以自定义覆盖；第三，planning 阶段——hierarchical 模式开始时 manager 先做一次 planning，把每个 Task 拆成更细步骤；第四，delegation——manager 可以把一个 Task 委派给多个 Agent 协作（如"调研 Agent 先调研，分析 Agent 再分析"）；第五，result aggregation——manager 收集所有 Agent 输出汇总成最终答案。hierarchical 模式让 CrewAI 不需要自己写 Supervisor 逻辑——开箱即用，是它对快速原型的关键支持。

12.3 AutoGen¶

来源：AutoGen 是 Microsoft 2023 年开源的对话式多 Agent 框架（github.com/microsoft/autogen），定位"通过多 Agent 对话实现复杂任务"。

核心抽象：ConversableAgent + GroupChat + GroupChatManager¶

AutoGen 的核心抽象是 ConversableAgent（可对话的 Agent）+ GroupChat（群聊）+ GroupChatManager（群聊管理器）。ConversableAgent 是一个能与人或其他 Agent 对话的 Agent——有 system_message / llm_config / tools。GroupChat 把多个 Agent 拉进一个群聊——所有 Agent 在一个 messages 列表里对话。GroupChatManager 是群聊管理器——决定下一个该谁说话（按 round_robin / auto 两种模式；auto 模式由 LLM 判断下个说话者）。

GroupChat 模式¶

GroupChat 是 AutoGen 的精髓——多 Agent 在一个共享 messages 列表里对话，每个 Agent 看到所有消息后决定是否发言、说什么。典型用法：用户提需求 → user_proxy Agent 转发 → assistant Agent 写代码 → code_executor Agent 跑代码 → assistant Agent 看结果继续——所有 Agent 在一个 GroupChat 里协作。GroupChat 模式适合"对话驱动"的多 Agent 协作——Agent 之间通过自然语言对话推进任务，类似 Slack 群里多协作者协作。

适用场景¶

AutoGen 适合**研究对话模式**与**代码执行任务**——研究"多 Agent 对话动力学"用 AutoGen 最方便（每个 Agent 是 ConversableAgent，对话轨迹清晰）；代码生成与执行任务用 AutoGen 的 code_executor 工具能跑用户代码。Microsoft 自家用 AutoGen 做 Many Students / MathChat 等研究项目。

优势¶

第一，对话抽象自然——多 Agent 对话就像 Slack 群聊，易理解。第二，GroupChatManager 自动调度——无需自己写路由逻辑。第三，代码执行强——内置 code_executor 工具能跑用户 Python 代码（沙箱）。第四，Microsoft 维护——大公司背书，长期维护有保证。

局限¶

第一，对话爆炸风险——GroupChat 的共享 messages 列表会膨胀，长对话上下文爆炸。第二，调度不够灵活——GroupChatManager 的 auto 模式由 LLM 决定下个说话者，不可控；想精确控制路由要写自定义 GroupChatManager。第三，生产化弱——AutoGen 偏研究框架，生产用要补可观测性 / 持久化 / 重试等基础设施。第四，性能——GroupChat 每轮所有 Agent 都看全 messages，token 消耗高。

AutoGen 的 code_executor 工具¶

AutoGen 的 code_executor 工具是它的独特优势——能跑用户 Python 代码并自动处理结果。具体流程：assistant Agent 输出"python\n<code>\n"代码块；code_executor Agent 自动提取代码块、在沙箱（Docker / 本地 subprocess）里执行、把 stdout / stderr / 返回值塞回 messages；assistant Agent 看执行结果继续。这种"代码 + 执行 + 反馈"循环让 AutoGen 擅长数据科学 / 数学计算 / 自动化脚本任务——Microsoft 自家用 AutoGen 做"自动数据分析助手"，让用户问"分析这份数据"Agent 就写代码跑出图表。安全要点：code_executor 必须跑在沙箱内（Docker 容器 + 网络白名单 + 资源限制），否则用户输入的代码可能 RCE——与第 13 章 L3 Sandbox 防御呼应。

AutoGen v0.4 与 GroupChatManager 演进¶

AutoGen 2024 年底发布 v0.4（也称"AutoGen AG2"）大幅重构——从 ConversableAgent + GroupChat 抽象改成基于"Actor 模型"的事件驱动抽象——每个 Agent 是一个 Actor，通过异步消息通信；GroupChat 改成"GroupChatManager"事件驱动调度。v0.4 的优势是支持分布式 Agent（多 Agent 跑在不同机器 / 进程）、异步非阻塞通信、更易扩展。但 v0.4 与 v0.2 API 不兼容——老 AutoGen 项目迁到 v0.4 要重写。生产上选 AutoGen 要决策 v0.2 还是 v0.4——v0.2 文档多例子多但已不再维护；v0.4 是未来但生态不够成熟。研究项目建议先 v0.2 学概念再 v0.4 上生产。

12.4 OpenAI Swarm¶

本节复用第 11 章对 Swarm 的讲解——Swarm 是概念原型，已不再维护但思想被业界吸收。第 11 章详细讲了 Swarm 的拓扑、与 Supervisor 的区别、handoff 机制、适用场景、局限，本节不重复，只从"框架视角"补充几点。

来源与现状¶

OpenAI Swarm（github.com/openai/swarm）是 OpenAI 2024 年 10 月开源的概念原型框架，定位"educational framework"——不是生产框架，是教学示例。Swarm 已被 OpenAI 标记为不再维护——README 顶部明确说明"this project is not maintained"——但 Swarm 的 handoff 思想被业界广泛吸收：OpenAI 自己的 Agents SDK（2025 年发布的官方生产框架）借鉴了 Swarm 的 handoff 抽象；多个第三方框架（LangGraph 的 create_handoff_tool / CrewAI 的 handoff 装饰器）也借鉴了 Swarm。

框架视角的 Swarm¶

从框架视角看 Swarm：第一，核心抽象极简——只有 Agent（有 name / instructions / functions / handoffs 字段）与 handoff 函数两个抽象，不到 100 行核心代码。第二，无状态——Swarm 不维护 Agent 状态，每次 handoff 把全部上下文打包传递，框架本身无状态。第三，无 checkpoint / 无 trace / 无持久化——Swarm 不做这些生产功能，留给用户自己加。第四，适合学习——读 Swarm 源码（< 500 行）能快速理解 handoff 抽象的本质。

选型建议¶

Swarm 不要用于生产——已不再维护、无生产基础设施。学习 handoff 思想时读 Swarm 源码；生产上要 handoff 用 OpenAI Agents SDK（官方）或 LangGraph 的 create_handoff_tool（开源）。第 11 章详细讲了 Swarm 的拓扑与 handoff 机制，本节不再赘述——读者可回看第 11 章。

从 Swarm 到 OpenAI Agents SDK¶

Swarm 的思想被 OpenAI Agents SDK（2025 年 3 月发布的官方生产框架）继承与扩展：第一，Agent 抽象保留——Agent(name, instructions, tools, handoffs) 字段几乎照搬 Swarm。第二，handoff 升级——Swarm 的 handoff 是函数级，Agents SDK 的 handoff 是对象级（HandoffDescription 描述何时 handoff 给谁），更结构化。第三，加生产基础设施——Agents SDK 加了 trace（OpenAI 自家 telemetry）、guardrails（输入输出护栏）、sessions（跨会话持久化）、tool_approval（高风险工具人审）。第四，多模型支持——Swarm 只支持 OpenAI 模型，Agents SDK 通过 model provider 抽象支持多模型。第五，cloud 集成——Agents SDK 与 OpenAI Cloud（to-be-released）原生集成，能云端跑 Agent。结论：Swarm 是概念原型，Agents SDK 是生产框架——生产要 handoff 抽象用 Agents SDK（如果在 OpenAI 生态）或 LangGraph 的 create_handoff_tool（开源跨框架）。

12.5 AutoGPT / BabyAGI¶

来源：AutoGPT（github.com/significant-gravitas/AutoGPT）与 BabyAGI（github.com/yoheinakajima/babyagi）都是 2023 年 3-4 月开源的早期自主 Agent 实验——比 LangGraph / CrewAI / AutoGen 都早。

早期尝试的价值¶

AutoGPT / BabyAGI 是 Agent 领域的"早期尝试"——2023 年 GPT-4 出来后，开发者用它做"自主 Agent"实验：AutoGPT 让 Agent 自主设定子任务、自主调工具、自主迭代直到目标完成；BabyAGI 用任务列表 + 优先级排序 + 执行 + 重新规划循环。这两个项目 2023 年火过一阵——AutoGPT GitHub star 一度超过 15 万——但很快退场。

为什么退场¶

退场原因有四个：第一，上下文爆炸——AutoGPT 让 Agent 自主迭代，每次循环都把上一步结果塞回上下文，几轮后上下文爆炸、注意力稀释、回答质量骤降。第二，循环不可控——Agent 自主决定何时停止，但 LLM 倾向"再多想一步"，经常陷入无限循环或绕死循环。第三，成本爆炸——每轮循环都调 LLM（GPT-4 价格不菲），一个简单任务跑几小时花几十美元。第四，框架被取代——LangGraph / CrewAI / AutoGen 等新一代框架用图 / 角色 / 对话等更可控的抽象取代了 AutoGPT 的"自主循环"，可控性与可观测性都好得多。

现状与启示¶

AutoGPT 项目仍在维护（2024 年转型 AutoGPT Platform），但作为通用 Agent 框架已退场——新人不要从 AutoGPT 开始学 Agent。BabyAGI 基本停更，作者 Yohei Nakajima 转去做新项目。AutoGPT / BabyAGI 的启示：自主 Agent 不能无控制地循环——必须有循环次数上限 / token 预算 / 可观测 trace / 人审介入，否则会爆炸。新一代框架都吸收了这个教训——LangGraph 的 checkpoint + 条件边、CrewAI 的 Process 抽象、AutoGen 的 GroupChatManager 调度——都是"受控循环"的设计。

BabyAGI 的任务队列思想¶

虽然 BabyAGI 项目停更，它的"任务队列 + 优先级 + 重新规划"思想被多个现代框架吸收：第一，任务队列——BabyAGI 维护一个任务列表，每次从最高优先级任务开始执行；第二，执行 → 创建子任务——执行任务后让 LLM 根据结果生成新子任务加入队列；第三，优先级评分——用 LLM 给任务打优先级分数（urgency / importance）；第四，重新规划——每隔几轮重新规划整个任务列表，删除过时任务、调整优先级。这套思想在 LangGraph 里可以表达为：一个 task_queue state 字段 + 一个 pick_task 节点 + 一个 execute 节点 + 一个 replan 节点（条件边触发）。BabyAGI 的工程价值在于"任务队列思想"——不是循环本身，而是"动态任务列表"——这被 CrewAI 的 hierarchical 模式 planning 阶段、LangGraph 的 planner 节点继承。

12.6 选型决策¶

5 个框架的选型决策矩阵如上图——按"学习曲线 / 灵活性 / 并行支持 / 可观测性 / 适用规模 / 生产就绪"6 个维度对比。下面给出具体场景的选型建议：

生产复杂流程 → LangGraph¶

生产复杂流程首选 LangGraph——多步骤 / 多 Agent / 有循环 / 有条件分支的场景 LangGraph 表达力最强。具体标志：第一，流程有循环（critic → executor 重做）；第二，多 Agent 协作（主管 + 子 Agent）；第三，要 checkpoint 断点续跑；第四，要 LangSmith trace；第五，团队能接受 1-2 周学习曲线。满足这些条件选 LangGraph——它是生产 Agent 系统的事实标准。

快速原型 → CrewAI¶

快速原型首选 CrewAI——角色清晰、任务可拆、要 1 天出 demo 的场景 CrewAI 最快。具体标志：第一，Agent 角色清晰（撰稿 / 编辑 / 校对）；第二，任务能线性或层级拆分；第三，1-3 天要出 demo；第四，团队新手多，要缓学习曲线；第五，不在意生产化（demo 阶段）。满足这些条件选 CrewAI——它的 declarative 配置 + 角色化抽象让 demo 飞速。

研究对话模式 → AutoGen¶

研究对话模式首选 AutoGen——研究"多 Agent 对话动力学"、要观察 Agent 间自然对话的场景 AutoGen 最方便。具体标志：第一，研究项目（非生产）；第二，要观察多 Agent 自然对话轨迹；第三，要代码执行能力（AutoGen code_executor 强）；第四，Microsoft 生态。满足这些条件选 AutoGen——它的 GroupChat 抽象让对话研究很自然。

轻量 handoff → Swarm（参考实现即可）¶

轻量 handoff 场景**不要直接用 Swarm**——Swarm 已不再维护。但要理解 handoff 思想时读 Swarm 源码——不到 500 行核心代码，是学习 handoff 抽象的最佳教材。生产要 handoff 抽象用 OpenAI Agents SDK（官方）或 LangGraph 的 create_handoff_tool（开源）——两者都借鉴了 Swarm 的 handoff 思想但加了生产基础设施。

不要从 AutoGPT 开始¶

绝对不要从 AutoGPT 开始学 Agent——AutoGPT 是 2023 年的早期尝试，已被现代框架取代。新手学 Agent 应该从 LangGraph（生产首选）或 CrewAI（快速原型）开始——这两个框架抽象更现代、生态更成熟、文档更完整。AutoGPT 的自主循环模式在生产上已被证明不可控——上下文爆炸、循环不可控、成本爆炸——是反面教材而非学习起点。

选型决策树¶

选型决策树：第一，是生产项目？是 → LangGraph；否 → 看下一条。第二，是研究项目要观察对话？是 → AutoGen；否 → 看下一条。第三，是快速 demo 角色清晰？是 → CrewAI；否 → 看下一条。第四，要轻量 handoff 学习？是 → 读 Swarm 源码不用于生产；否 → 看下一条。第五，默认 LangGraph——它是生产 Agent 系统的事实标准，能覆盖绝大多数场景。

多框架混用的工程实践¶

实际生产项目经常多框架混用——不是非此即彼。常见混用模式：第一，LangGraph 主管 + CrewAI 子团队——主管用 LangGraph（生产控制流），某些复杂角色协作用 CrewAI crew 包装成 LangGraph 节点。第二，LangGraph 主管 + AutoGen 子对话——主管用 LangGraph，某些需要多 Agent 自然对话的子任务用 AutoGen GroupChat 包装成 LangGraph 节点。第三，LangGraph + MCP 工具——主管用 LangGraph 编排，工具用 MCP server 暴露（第 10 章），实现工具跨框架复用。混用原则：核心控制流用 LangGraph（生产基础设施完整），特色能力用对应框架（CrewAI 角色化、AutoGen 对话、Swarm handoff 思想）包装成子组件。不要为了"统一框架"勉强用一个框架实现所有——每个框架有擅长领域，混用让每个能力都用最适合的工具。

框架迁移的成本评估¶

如果项目已经在用一个框架想迁移到另一个，要评估迁移成本：第一，抽象映射——老框架的抽象能否映射到新框架？如 CrewAI 的 hierarchical 模式能映射到 LangGraph 的 Supervisor 节点 + 子 Agent 节点；AutoGen 的 GroupChat 能映射到 LangGraph 的图（每个 Agent 是节点，GroupChatManager 是路由函数）。第二，生态绑定——用 LangChain 工具的迁到非 LangChain 框架要重写工具层；用 OpenAI SDK 的迁到 Anthropic 要改 LLM 调用层。第三，测试覆盖——迁移前要有端到端测试覆盖（用第 13 章评测方法），迁移后跑同样测试对比成功率。第四，渐进迁移——不要大爆炸迁移，把 Agent 一个个迁，每迁一个跑回归测试。建议迁移顺序：从外围非核心 Agent 开始迁，最后迁主管 Agent。迁移成本通常被低估——简单抽象映射 OK，但工具层、trace、checkpoint、错误处理都要重做，预算 2-3 倍预估时间。

框架的长期演进趋势¶

从 2023 年 AutoGPT/BabyAGI、2024 年 LangGraph/CrewAI/AutoGen/Swarm、2025 年 OpenAI Agents SDK 的演进看 Agent 框架趋势：第一，抽象收敛——业界在收敛到"图编排 + 角色 + handoff + 工具协议"四件套，新框架都在这四件套上做差异优化。第二，MCP 成工具协议标准——越来越多框架原生支持 MCP（第 10 章），工具跨框架复用成为可能。第三，生产基础设施标配——trace / checkpoint / guardrails / 人审 从可选变标配，新框架都内置。第四，多模型抽象——从单 OpenAI 模型到多模型（OpenAI / Anthropic / Llama / 国内）抽象，框架不再绑定单一模型供应商。第五，cloud 化——OpenAI Cloud / LangGraph Cloud / CrewAI Cloud 等云端 Agent 平台兴起，从"自己部署"到"平台托管"。结论：选框架时关注这些趋势——优先选支持 MCP / 多模型 / 标配生产基础设施 / 有 cloud 版本的框架（LangGraph 与 OpenAI Agents SDK 都符合）。

代码片段：LangGraph 最小示例¶

下面用 LangGraph 写一个最小示例——planner 节点拆任务、executor 节点执行、critic 节点检查，critic 不满意回到 executor 重做：

# pip install langgraph langchain-openai
from typing import TypedDict, Literal
from langgraph.graph import StateGraph, START, END

class State(TypedDict):
    task: str
    plan: str | None
    result: str | None
    critic_pass: bool

def planner(state: State) -> dict:
    return {"plan": f"拆解任务 {state['task']} 为 3 步"}

def executor(state: State) -> dict:
    return {"result": f"按计划 {state['plan']} 执行"}

def critic(state: State) -> dict:
    # mock：第一次不满意，第二次满意
    ok = ("执行" in (state.get("result") or "")) and ("redo" not in (state.get("result") or ""))
    if "redo" in (state.get("result") or ""):  # 已经重做过一次
        ok = True
    return {"critic_pass": ok, "result": (state.get("result") or "") + " redo" if not ok else state.get("result")}

def route(state: State) -> Literal["executor", "__end__"]:
    return "executor" if not state["critic_pass"] else "__end__"

g = StateGraph(State)
g.add_node("planner", planner)
g.add_node("executor", executor)
g.add_node("critic", critic)
g.add_edge(START, "planner")
g.add_edge("planner", "executor")
g.add_edge("executor", "critic")
g.add_conditional_edges("critic", route, {"executor": "executor", "__end__": END})
app = g.compile()

print(app.invoke({"task": "写一篇博客", "plan": None, "result": None, "critic_pass": False}))

约 30 行代码演示 LangGraph 核心——StateGraph + 节点 + 条件边 + 循环回路。critic 不满意时通过 add_conditional_edges 路由回 executor 重做，直到 critic_pass=true 走 END。

工程实战要点¶

• 生产选 LangGraph：生产复杂流程（多 Agent / 循环 / 条件分支 / checkpoint）选 LangGraph——它是生产 Agent 系统事实标准，图抽象表达力强、typed state 可校验、LangSmith trace 集成、checkpoint 断点续跑。
• CrewAI 适合角色清晰任务：Agent 角色清晰（撰稿 / 编辑 / 校对）、任务能线性或层级拆分、要 1 天出 demo 的场景选 CrewAI——角色化抽象符合直觉、declarative 配置快速、学习曲线缓。
• AutoGen 适合研究对话：研究"多 Agent 对话动力学"、要观察 Agent 间自然对话轨迹、要代码执行能力（code_executor 沙箱）选 AutoGen——GroupChat 抽象让对话研究自然；但生产化弱，要补可观测性 / 持久化基础设施。
• Swarm 已不再维护但思想重要：Swarm 仓库（github.com/openai/swarm）已不再维护——不要用于生产；但 Swarm 的 handoff 思想被业界吸收，读 Swarm 源码（< 500 行）是学习 handoff 抽象的最佳教材；生产 handoff 用 OpenAI Agents SDK 或 LangGraph 的 create_handoff_tool。
• 不要从零写——用框架：不要从零用 if-else 拼 Agent 循环——轮子已经被 LangGraph / CrewAI / AutoGen 造好；从零写会遇到上下文管理 / 重试 / 持久化 / 可观测性 / 多 Agent 调度等大量隐藏复杂度；选一个框架把精力放在业务上。

小结¶

• LangGraph（github.com/langchain-ai/langgraph）：LangChain 下一代，图编排（StateGraph + nodes + edges + state）；条件边表达循环分支、checkpoint 断点续跑、LangSmith trace 集成；生产复杂流程首选。
• CrewAI（github.com/crewAIInc/crewAI）：角色化多 Agent（Agent = Role + Goal + Backstory + Tools；Crew = Agents + Tasks + Process）；declarative 配置、学习曲线缓、快速原型首选。
• AutoGen（github.com/microsoft/autogen）：Microsoft 对话式多 Agent（ConversableAgent + GroupChat + GroupChatManager）；GroupChat 共享 messages 对话、code_executor 沙箱强；研究对话模式首选。
• Swarm（github.com/openai/swarm）：OpenAI 2024.10 概念原型，已不再维护；handoff 思想被 OpenAI Agents SDK / LangGraph / CrewAI 吸收；学习用源码不用于生产（回看第 11 章详解）。
• AutoGPT / BabyAGI（github.com/significant-gravitas/AutoGPT / github.com/yoheinakajima/babyagi）：2023 年早期尝试，已退场；上下文爆炸 / 循环不可控 / 成本爆炸 / 被新框架取代；不要从 AutoGPT 开始学 Agent。
• 选型决策：生产复杂 → LangGraph；快速 demo → CrewAI；研究对话 → AutoGen；轻量 handoff → 读 Swarm 源码不用于生产；不要从 AutoGPT 开始；不要从零写——用框架。

练习题¶

1. LangGraph 与 LangChain 的关系？
2. CrewAI 的核心抽象是什么？
3. AutoGen 的 GroupChat 模式是什么？
4. 为什么 AutoGPT/BabyAGI 退场？
5. 5 个框架的选型决策？
6. 为什么"不要从零写 Agent 框架"？

参考答案¶

下一章：第十三章 评测与安全