25｜框架对比：和 LangGraph/CrewAI/AutoGen 的关系

到这里，本系列把 agent 的设计决策都讲完了：提示词、上下文、循环、工具、权限、多 Agent、MCP。

但读者大概率会问一个问题：这些 LangGraph、CrewAI、AutoGen 都有现成实现，为什么还要自己搭？本系列讲的这套，和这些框架是什么关系？本篇正面回应这个疑问。

先说清楚：本系列不反对用框架

本系列讲设计判断，代码用最小骨架，不是"反对用框架"。恰恰相反，理解了这些设计判断，才知道框架的组件在做什么、什么时候该用哪个。

LangGraph、CrewAI、AutoGen 都是成熟的多 agent 框架，各自定位清晰。生产项目里，标准场景直接用框架比自己搭省事得多——框架替你处理了大量细节（状态持久化、错误重试、消息路由），不用自己造轮子。

本系列讲的是这些框架背后共通的设计原理。框架是这些原理的现成实现，原理是选框架、用框架、改框架的判断力。

三个框架各自是什么

LangGraph（LangChain 出品）把 agent 工作流建模成有向图。节点是处理步骤，边是流转逻辑。强项是显式状态管理、分支、重试、检查点、可恢复执行。需要复杂控制流和持久状态时用。它和 LangChain 集成紧密，不在 LangChain 生态里会觉得有点绑。

CrewAI 是角色驱动。定义 agent 的 role、goal、backstory，像组建一个团队分工完成任务。强项是快速搭建多 agent 原型，"团队专家"的比喻直观。适合内容生成流水线、研究工作流这类角色明确的场景。

AutoGen（微软出品）是对话驱动。把多个 agent 放进一个 group chat，让它们通过自然语言对话协作。强项是灵活的角色扮演和人机交互场景，框架处理发言轮换、消息路由、终止条件。

一个粗暴的区分：要控制流和状态用 LangGraph，要角色分工用 CrewAI，要 agent 间对话用 AutoGen。

本系列和框架的对应关系

本系列讲的设计决策，在框架里都有对应组件。这不是巧合——框架也是基于这些原理实现的。

本系列的设计决策	框架里的对应组件
第 12 篇 两层循环（QueryEngine + queryLoop）	LangGraph 的 StateGraph（节点+边+状态）
第 13 篇 错误处理（扣留还是抛出）	LangGraph 的重试和错误边界
第 22 篇 五种编排模式	CrewAI 的 role/process、AutoGen 的 group chat、LangGraph 的 supervisor 节点
第 23 篇 handoff / agents-as-tools	OpenAI Agents SDK 的 handoff、CrewAI 的 delegation
第 24 篇 MCP 集成	各框架的 MCP 适配器

看到这个对应关系，就明白本系列在讲什么了：框架封装好的那些组件，拆开看里面就是这些设计决策。本系列讲的是"为什么这样设计"，框架给你的是"现成能用"。

什么时候该用框架

标准场景直接用框架。常规 RAG、标准多 agent 协作、内容生成流水线——这些场景框架已经把最佳实践固化了，自己搭没有额外价值，还容易搭错。团队不熟 agent 设计原理时，用框架降低风险——框架的默认行为是经过大量项目验证的。

要快速出原型用框架。框架的抽象层级高，几十行代码能跑起一个多 agent 系统。验证想法阶段，框架的速度优势明显。

什么时候自己搭

需要精细控制时自己搭。本系列反复讲的那些细节——BashTool 的八层安全检查、压缩必须保留用户消息、工具排序影响 prompt cache、权限管线的多层评估——框架要么不提供，要么提供但封装得很深改不动。运维排查这种对安全性和可控性要求高的场景，框架的默认行为往往不够，自己搭能精确控制每一处。

学习目的自己搭。理解 agent 怎么工作，没有比自己搭一遍更好的方式。本系列就是为这个目的写的——用最小骨架把每个设计决策走一遍，理解了再用框架，知道框架在做什么。

非标准场景自己搭。任务形状不典型，框架的抽象反而碍事。比如 ops-assistant 这种"告警 → 带证据报告"的链路，混合了 RAG、工具调用、权限审批、报告生成，硬套某个框架的范式不如自己组装。

用了框架，本系列讲的还有用吗

这是最关键的问题。答案是有，而且很关键。

框架给你的是组件，不是判断。组件能跑起来，但跑得好不好取决于你怎么配置、怎么组合，这些判断框架不替你做：

• 工具排序影响 prompt cache（第 4、26 篇）——框架不会告诉你工具列表顺序乱了缓存就失效，这要你懂。
• 压缩必须保留用户消息（第 10、16 篇）——框架的压缩组件默认配置可能丢用户约束，你要知道去调。
• swarm 不是并行执行（第 22 篇）——用框架的 swarm 模式时，以为它是并行就错了，它是接力。
• 输出 token 耗尽是 incomplete 状态不是异常（第 13、15 篇）——框架的错误处理如果没覆盖这个，你要知道补。
• 先单后多（第 22 篇）——框架鼓励你多 agent，但过早多 agent 是反模式，这个判断框架不给。

换句话说，框架降低了实现门槛，但不降低设计门槛。懂了本系列的设计判断，用框架时知道每个组件该怎么配、哪些坑要防；不懂这些，用框架也只是把组件堆起来，出问题不知道哪坏了。

一个当前状态的提醒

框架变化快，选型前要查当前状态。一个具体的例子：LangChain 的 AgentExecutor（旧的 initialize_agent）已经废弃，2026 年 12 月 EOL。新项目不要再用它，改用 create_react_agent()（预置模式）或 LangGraph 的 StateGraph（自定义编排）。

这类信息会变。本系列不绑定具体框架版本，选型时以框架当前文档为准。但底层的设计判断是稳的——两层循环、错误扣留、先单后多这些，不会因为框架升级而过时。

第四阶段收尾

框架对比讲完，第四阶段结束。前四阶段建立了全部设计决策，也回应了"为什么不用现成框架"。

接下来把所有概念串进一个能跑的 ops-assistant 项目。下一阶段是项目落地：目录怎么组织、工具怎么接、会话怎么存、报告怎么出、上线要注意什么。