去年一个做工业 SaaS 的团队找过来，说他们用 CrewAI 搭了一个客服 Agent，产品经理演示给客户看，客户当场拍板要上线。压测那天开了 200 个并发用户，10 分钟系统就崩了——不是模型限速，是编排框架本身的状态存在内存里，进程重启后所有会话丢失，客户投诉电话打爆。产品负责人在群里问了一句：「demo 明明跑得好好的，怎么一上生产就不行？」
这个问题我们过去两年在企业 AI Agent 项目里听过至少 15 次。5 年 · 2000+ 家 · 1000+ 个项目沉淀下来，Agent 编排框架选型踩的坑，本质上都在同一个地方：demo 场景和生产场景对框架的要求是完全不同的两套指标，选型时如果只看「能跑起来多快」，不看「能扛住多少并发、能恢复多少中断、能被观测多深」，后面一定会重写。
一、为什么「能跑 demo」和「能上生产」隔着 5 个坑
Agent 编排框架的 demo 通常长这样：一个 Python 脚本、几十行代码、跑通一个多轮对话或者一个多步任务，产品经理拿去演示，惊艳。但从这个 demo 到能承接真实业务流量，中间要跨过 5 个坎，绝大多数团队第一次做都会全部踩一遍。
坑一：状态放在内存里。CrewAI 和一部分 AutoGen 用法默认把 Agent 的对话历史、中间变量都放在进程内存。开发时无感，上线后进程一重启（版本发布、扩容、崩溃恢复），所有正在进行的会话全部丢失。用户体感就是「刚才聊得好好的机器人突然失忆」。
坑二：没有中断恢复。真实业务里，Agent 经常要跑几分钟甚至几十分钟——调工具、等审批、等外部 API 回调。如果框架不支持把执行状态持久化到数据库，任何一次网络抖动都是从头再来。这不是性能问题，是可用性问题。
坑三：并发靠语言原生的多线程。Python 的 GIL 决定了纯多线程扛不住高并发，需要框架本身考虑异步和进程池设计。CrewAI 和部分 AutoGen 用法在这一点上是弱项，QPS 上到几十就开始卡。
坑四：可观测性靠 print。demo 阶段用 print 打日志没问题，生产环境如果没有结构化 tracing，出问题只能靠肉眼翻日志。Agent 决策链本身就复杂，没有链路追踪基本等于蒙眼开车。
坑五：模型和工具解耦不彻底。demo 里模型和工具是硬编码在 Agent 定义里的，生产环境要求模型能热切换、工具能动态注册、Prompt 能版本化。框架如果没有留这些扩展点，改起来伤筋动骨。
这 5 个坑不是任何单一框架的问题，是「编排能力」和「工程能力」之间的差距。选框架的核心问题是：它把这些工程能力做到什么程度，剩下的多少要你自己补。
二、4 家横评：10 个维度打分表
先给一张总表。数字偏经验判断，具体到你的团队还要做基准测试。为了方便对比，我们把每个维度按「弱 / 中 / 强 / 极强」四档给分。
| 维度 | LangGraph | AutoGen | CrewAI | Dify |
|---|---|---|---|---|
| 编排范式 | 图式状态机 | 多 Agent 对话 | 角色驱动流程 | 无代码可视化 |
| 状态管理与持久化 | 极强（Checkpoint 原生） | 中（需自建） | 弱（默认内存） | 强（DB 托管） |
| 并发与 QPS 承载 | 强（异步友好） | 中 | 弱 | 强（托管层负责） |
| 中断恢复与人工介入 | 极强（原生 human-in-the-loop） | 中 | 弱 | 中（有节点支持） |
| 可观测性与调试 | 强（LangSmith 深度集成） | 中（需接第三方） | 弱 | 强（内置日志） |
| 工具生态与自定义能力 | 极强（Python 全开放） | 强 | 中 | 中（受 UI 限制） |
| 私有化部署难度 | 中（自建 Python 服务） | 中 | 低 | 中（Docker Compose） |
| 大模型接入自由度 | 极强（任意模型） | 强 | 强 | 强（内置多家） |
| 学习曲线 | 陡 | 中 | 平 | 极平 |
| 社区活跃度 | 极高（LangChain 生态） | 高（微软背书） | 高（增长快） | 极高（国内热度高） |
这张表看下来会发现一个规律：LangGraph 在工程指标上几乎全线拉满，代价是学习曲线陡；Dify 在开箱即用上强，代价是深度定制受限；AutoGen 是学术味最重的一家，多 Agent 讨论场景独强；CrewAI 胜在快，输在生产化能力。
选框架的问题不是「哪家更好」，是「哪家的短板你能接受」。下面把 4 家分别拆开讲。
三、LangGraph：图式编排 + 状态机，工程感最强
LangGraph 是 LangChain 团队推出的编排框架，核心抽象是「图」——把 Agent 的执行流程画成节点（Node）和边（Edge），每个节点是一个 Python 函数或一个 LLM 调用，边定义流转条件。状态（State）是全局的，每个节点读写它。
它做对了什么：
- 原生 Checkpoint 机制：每次状态变化都可以持久化到 Postgres、SQLite、Redis，进程重启不丢会话；
- human-in-the-loop 是一等公民：中断执行、等待人工输入、恢复执行，是 API 层面直接支持的，不用自己造轮子；
- 图结构可视化：执行过程可以画成流程图，配合 LangSmith 做 tracing，调试体验在 4 家里最好；
- 异步友好：底层基于 asyncio，QPS 承载天花板高，实测单机能扛几百并发。
它的坑：
- 概念多：State、Node、Edge、Checkpoint、Interrupt、Subgraph、Command，前两周基本在读文档；
- API 迭代快：0.x 到 1.x 期间破坏性变更不少，锁版本很重要；
- 调试图结构比调试函数难：出问题要看整张图的状态流转，不是单点函数的入参出参。
典型场景：需要复杂状态机的业务，比如客服工单从「接单-分派-诊断-回复-关闭」的多步流转，中间任何一步都可能被人工介入或超时打断。
| 项目类型 | 是否推荐 LangGraph | 理由 |
|---|---|---|
| 复杂多轮客服 | 强推荐 | 状态机 + 中断恢复原生支持 |
| 简单问答 Chatbot | 不推荐 | 用大炮打蚊子 |
| 长任务工作流（几小时级别） | 强推荐 | Checkpoint 机制天然适配 |
| 多 Agent 头脑风暴 | 中等推荐 | 能做但不是强项 |
如果你想理解 LangGraph 在整个 Agent 架构里的位置，可以延伸看AI Agent 架构范式对比，里面有对图式编排和其他范式的横向拆解。
四、AutoGen：多 Agent 对话，深度讨论强
AutoGen 是微软研究院开源的框架，最鲜明的特点是「多 Agent 对话」——把不同角色的 Agent（比如 Coder、Reviewer、PM）拉到一个「对话组」里互相聊天，通过对话推进任务。
它做对了什么：
- 多 Agent 讨论范式清晰：GroupChat、RoundRobin、Selector 等对话组织模式开箱即用；
- 代码执行沙箱：CodeExecutor 组件设计得比较扎实，跑 Python、Shell、Docker 都有对应实现；
- 微软背书 + 学术论文引用多：内部治理和路线图相对稳定，不太会突然弃坑；
- v0.4 版本引入了 event-driven 架构：异步能力和可扩展性有明显提升。
它的坑：
- 状态管理是弱项：默认状态在内存，持久化要自己接；
- 调试复杂：多 Agent 对话链一长，日志读起来累，需要接第三方 tracing 工具；
- 版本变动大：v0.2 到 v0.4 是重写级别的变化，旧代码几乎全废；
- 中文文档滞后：主要文档和示例都是英文，国内团队上手成本比 Dify 高。
典型场景：需要多角色协作讨论出结论的任务，比如产品需求评审、代码互审、多视角分析报告。
| AutoGen 适合什么 | AutoGen 不适合什么 |
|---|---|
| 多 Agent 头脑风暴 | 高 QPS 客服系统 |
| 代码生成 + 自动测试 | 简单单 Agent 任务 |
| 结构化辩论（正方 vs 反方） | 长任务状态持久化场景 |
| 学术研究和原型探索 | 需要业务同学自己搭流程 |
五、CrewAI：角色驱动 + 简洁 API，快速原型
CrewAI 是过去 12 个月增长最快的一家，主打「几十行代码搭一个多 Agent 团队」。它的编排范式围绕「Crew（团队）- Agent（成员）- Task（任务）- Process（流程）」四个概念，非常好懂。
它做对了什么：
- API 简洁：新手基本一小时能跑通 Hello World；
- 角色抽象直观：给每个 Agent 一个 role、goal、backstory，业务同学都能看懂；
- Task 和 Process 分离：任务定义和执行流程解耦，改流程不用改任务；
- 社区增长快：GitHub star 数在同类框架里领先，示例和教程多。
它的坑：
- 状态默认放内存：生产化基本要自己封一层持久化；
- 并发承载弱：单机跑几十并发就明显吃力，不适合高流量场景；
- 中断恢复能力弱：任务跑到一半崩了基本要重跑；
- 深度定制受限：底层抽象比较薄，改一点核心行为就要读源码。
典型场景：内部效率工具、原型验证、内容生成流水线、低并发的运营辅助工具。
我们见过一家客户用 CrewAI 做内容生成——一个 Agent 找选题、一个 Agent 写初稿、一个 Agent 改润色、一个 Agent 做事实核查，跑起来效果不错。但当他们想把这套流程改成对外的 SaaS 服务、支持几百个并发用户时，我们建议整套逻辑重写到 LangGraph 上。CrewAI 是好的验证工具，不是好的生产平台——这是我们目前的判断。
六、Dify：无代码可视化 + 托管服务，业务侧友好
Dify 是国内团队主导的开源项目，走「AI 应用平台」路线——不只是编排框架，还带知识库、Prompt IDE、发布 API、监控日志一整套。业务同学可以在浏览器里拖拉拽搭 Agent。
它做对了什么：
- 无代码可视化编排：产品经理、运营都能自己搭 Agent 流程；
- 知识库开箱即用：文档上传、切片、向量化、检索一条龙，不用自己拼 RAG 栈；
- 多模型接入：内置 OpenAI、Anthropic、通义、豆包、深度求索等多家，切换只需改配置；
- 私有化部署方便：Docker Compose 一键部署，中小团队上手快；
- 中文文档完备：国内社区活跃，问题响应快。
它的坑：
- 深度定制受限：拖拉拽的能力是上限，超出画布支持范围的复杂逻辑很难塞进去；
- 调试深度不够：复杂流程出问题时的诊断信息不如代码框架细；
- 商用授权有边界：多租户 SaaS 对外售卖需要商业授权，自用免费；
- 版本升级破坏性：0.x 到 1.x 期间数据结构变过，升级要谨慎。
典型场景：企业内部知识助手、业务同学要自己维护 Prompt 和流程的场景、快速搭建对话式产品原型、有明确知识库需求的 RAG 应用。
如果你正在评估 Dify 和自建 RAG 栈的取舍，可以对照看一下向量数据库怎么选里对 5 家向量库的横评，两篇合起来能把 RAG 应用的基础设施选型基本讲透。
七、4 类场景推荐表：先看场景再选框架
选框架的正确顺序不是「哪个更热就选哪个」，而是「先明确场景，再匹配框架」。下面这张表是我们做选型评审时常用的对照：
| 业务场景 | 首选框架 | 次选框架 | 理由 |
|---|---|---|---|
| 复杂状态机业务（客服工单、审批流、订单履约） | LangGraph | Dify（简单版） | 状态持久化 + 中断恢复是刚需 |
| 多 Agent 对话协作（评审、辩论、多视角分析） | AutoGen | LangGraph | AutoGen 的对话组抽象最贴合 |
| 快速验证原型（一到两周出 demo） | CrewAI | Dify | API 最简洁，改动最快 |
| 业务同学自己编排（产品/运营维护 Prompt） | Dify | 无 | 无代码可视化是唯一选择 |
| 高并发对外 SaaS（几百到几千 QPS） | LangGraph | 自研 | 异步 + 状态机能扛住 |
| 内部效率工具（运营辅助、内容生成） | CrewAI | Dify | 快速搭建，不追求生产级 |
| 混合业务（前端 Dify、后端复杂状态机） | Dify + LangGraph | 无 | 分层混用，各司其职 |
有几点补充：
- 表格里的「次选」不代表也能用，而是「主选做不了时的降级选择」。比如复杂状态机业务硬要用 Dify，会在中断恢复上吃亏，需要自己在业务层补状态持久化；
- 同一个团队可以在不同项目里用不同框架，没必要全公司统一到一家。真正需要统一的是评测集、Prompt 管理、模型接入这些「资产层」；
- Agent 编排框架不是 AI Agent 项目成本的大头，模型调用、数据接入、集成开发才是。关于成本结构，可以对照AI Agent 开发成本拆解看一下。
八、生产上线前的 5 项必测清单
框架选完不等于上线放心。开沿在项目交付前会跑一遍 5 项必测，任何一项不过关都不允许上生产。这份清单适用于所有 4 家框架，具体测法有差异，但目标一致。
| 测试项 | 测试方法 | 通过标准 | 常见失败模式 |
|---|---|---|---|
| 并发压测 | 阶梯加压到目标 QPS 的 1.5 倍，观察 30 分钟 | P95 延迟稳定、无内存泄漏、无进程崩溃 | 内存持续上涨、请求排队严重 |
| 中断恢复 | 会话进行到一半 kill 进程，重启后继续 | 会话状态能恢复、上下文不丢 | 状态在内存里全丢 |
| 成本可控 | 用生产数据回放，观察单会话平均 tokens 和成本 | 单会话成本在预算内、无 Prompt 爆炸 | 上下文越滚越大、tokens 失控 |
| 权限隔离 | 多租户/多用户场景下交叉请求 | 数据严格隔离、无越权访问 | 用户 A 看到用户 B 的对话历史 |
| 可观测性 | 制造 3 类典型错误（模型超时、工具报错、逻辑分支错误），看能否定位 | 全部能在 5 分钟内从日志和 tracing 里定位 | 只能靠肉眼翻日志、无法复现 |
前 4 项是「不通过就崩」的硬指标，第 5 项是「不通过就修不动」的软肋。可观测性做得差的框架不是不能上生产，是上生产后你会天天被投诉。我们过去两年做失败复盘时，「问题定位不了、只能重启」是排在前 3 的运维痛点。
如果你想系统看一下 AI Agent 项目从立项到上线的完整节奏，可以延伸看AI Agent 落地路线图，里面有把编排框架选型放在整个项目周期里的位置。
九、AI 接进来：Agent 平台的 3 个自我进化能力
Agent 编排框架只是骨架，真正让平台越用越聪明的是三个自我进化机制。开沿在给客户交付 AI Agent 平台时，会把这三层当作「二期能力」逐步接入：
自动调优。Agent 跑一段时间后，会积累一批「用户反馈不好的对话」——评分低、被用户中途放弃、被转人工。以前的做法是产品经理定期人工看日志、改 Prompt。现在的做法是让一个「元 Agent」定期扫这些差评样本，自动生成 Prompt 修改建议，交给人工审核后灰度上线。做得好的话，每周迭代 2-3 版 Prompt 是常态。
自我改写。当业务规则变化时（比如新增一个 SKU、修改一个审批流程），传统做法是工程师改代码。现在的做法是把「业务规则」独立成一份自然语言文档，Agent 每次决策前先读一次。规则更新只改文档，不改代码。这一层做好的关键不在框架，而在业务规则的结构化程度。
自监督评测。传统评测集是人工标注，成本高、覆盖窄。现在的做法是让一个「评测 Agent」根据用户实际问题自动生成评测样本，用「多模型交叉打分」的方式做质量评估。这一层的价值在于：评测集能跟得上业务变化，而不是半年前的老样本。
这三层能力和编排框架的选择半解耦——LangGraph 和 Dify 都能做，但实现深度差别大。这也是为什么我们在项目立项时会强调：框架只是起点，平台工程能力才是终点。关于 AI Agent、RPA、低代码这三种自动化路径的对比，可以看AI Agent vs RPA vs 低代码。
写在最后
Agent 编排框架选型这件事，回到本质就是三条铁律：
第一，先算规模再选框架。demo 阶段 CrewAI 或 Dify 就够，几百 QPS 以上才开始考虑 LangGraph 或自研。别用未来 3 年的想象容量套现在的选择。
第二，把工程能力和框架解耦。业务逻辑写在自己的代码里，工具、Prompt、评测集独立于框架管理。这样即使 12 个月后框架换代，你的资产还在。
第三，可观测性优先于炫酷范式。多 Agent 讨论、图式状态机这些范式听起来很酷，但如果日志和 tracing 跟不上，出问题时你只能重启大法。选框架时把可观测性放在功能特性之前。
框架选完只是第一步。真正决定 Agent 平台能不能长期跑下去的，是你团队的工程能力、评测体系、和业务方的反馈闭环。如果你正在为公司做 AI Agent 平台的框架选型或者已经跑了一段时间遇到瓶颈，欢迎把当前的业务场景、并发量估算、和已经踩过的坑整理一下，我们可以一起看看哪些是框架的问题、哪些是工程能力的欠债。
