你的 Agent demo 很惊艳，一上线就拉胯
有个产品经理来问我：智能体编排在企业里到底怎么落地？他查了一圈，说现在主流好像是 LangGraph、Dify、Coze。
我先泼一盆冷水：这三个东西，根本不在一个赛道上。
把它们摆在一起比，就像问「买车该选发动机、4S 店还是滴滴」——一个是零件，一个是渠道，一个是服务，比个什么劲。
你一开始就站错了队，后面怎么选都是错的。所以这篇文章，我想把「智能体编排落地」这件事，从头到尾讲明白。
先说人话：智能体编排是什么
一个大模型回答一个问题，相当于一个员工干一件事。
智能体编排，就是你当项目经理，把一个复杂任务拆给好几个 AI，定好谁先谁后、谁能调什么工具、出错了怎么办、关键的地方要不要喊人来拍板。
它要解决四件事：
- 流程：几个 Agent 怎么串起来——顺序、分支、循环、还是并行？
- 状态：上一步的结果怎么传给下一步？跑一半断了能不能接着跑？
- 控制：哪一步必须人来确认，AI 不能自己做主？
- 可观测：线上出问题了，你能不能看见它到底怎么想的、错在哪一步？
记住这四件事。因为接下来你会发现：demo 阶段，这四件事一件都不重要；生产阶段，这四件事就是全部。
这句话，就是整个「死亡之谷」的根源。
死亡之谷：90% 的 Agent 死在这里
我见过太多这样的场景：一个 Agent demo 演示的时候惊为天人，老板拍板要上，三个月后还在「优化中」，悄无声息地黄了。
不是个例。一份 2026 年的企业调研里，97% 的高管说自己公司已经部署了 AI Agent——但只有两成多的企业，真的从里面看到了像样的回报。
（顺嘴说一句：这份调研是一家卖 AI 产品的公司做的，数字得打个折看。但「大部分企业没赚到钱」这个方向，和 MIT、麦肯锡那几份独立调研是一致的。我做内容有个原则：数字宁可保守，也不忽悠你。）
为什么会死在谷里？因为 demo 和生产，要的根本是两套东西。
| 生产必须有，demo 不需要 | 没有会怎样 |
|---|---|
| 断点续跑：跑一半断了能接着跑，能暂停等人确认 | 一断全重来，长流程根本上不了线 |
| 可观测：看得见每个 Agent 怎么想的、错在哪 | 线上一出错两眼一抹黑 |
| 人工兜底：关键步骤让人拍板再往下走 | 高风险动作 AI 自己做主，没人敢用 |
| 错误恢复：某一步崩了能重试、能降级 | 一个 Agent 抽风，整条链全挂 |
demo 的时候，这些你一个都用不上——反正就跑一次给人看。 上了生产，这些你一个都不能少——因为它要日复一日地扛真实流量。
Agent 的 demo 是请客吃饭，生产是过日子。
三层分类：先搞清楚你在哪一层
回到开头那个产品经理的问题。LangGraph、Dify、Coze 为什么不能放一起比？因为它们分属三个完全不同的层，面向的人都不一样。
第一层：代码框架——给工程师的。 LangGraph、AutoGen、CrewAI、LlamaIndex、OpenAI 的 Agents SDK。用代码精确控制每一步，能编排最复杂的逻辑，生产级能力最强。代价是：得会写代码。
第二层：低代码平台——给业务和产品的。 Dify、Coze、n8n、Flowise、FastGPT。拖拉拽就能搭流程，业务自己就能上手，当天能跑通。代价是：复杂逻辑会撞墙。
第三层：云厂商方案——给已经上云的企业的。 AWS 的 Bedrock、谷歌的 Vertex、微软的 Copilot Studio，国内的阿里百炼、腾讯元器、百度千帆。和云生态深度绑定，省运维。代价是：被厂商绑住，想换走不容易。
选型的第一刀，不是「选哪个工具」，而是「我这个场景，该用代码框架、低代码平台，还是云方案」。这一刀切对了，后面才有得谈。
一个反直觉的事实：明星不一定最能打
聊到这儿，得插一个我亲自查证的事。
网上各种文章引用的 GitHub star 数，互相矛盾，而且基本全是错的。有的文章说 LangGraph 才九千 star，有的说两万五——我当天用官方接口实查，是 35,800。
所以下面这组数字，是我 2026 年 6 月 26 日当天一个个查出来的（star 只代表社区热度，不等于企业用得多，但它是唯一能精确核实的公开数字）：
- n8n：194k（自动化老将，AI 是后来加的）
- Dify：146k
- LangChain：140k
- AutoGen：59k（但微软已经把它停掉了，下面讲）
- CrewAI：54k
- LlamaIndex：50k
- LangGraph：36k
- Coze：21k
发现没有？Dify 的 star 数超过了 LangChain。一个中国团队做的低代码平台，社区热度世界第一梯队。这事值得国内做产品的人骄傲一下。
网上的数字别照抄。我做这篇之前，把每个数字都自己查了一遍——对外说话，数字是要负责任的。
一个风向标：微软亲手停掉了自己最火的框架
2026 年，微软干了件挺有信号意义的事：把自己两个明星框架 AutoGen 和 Semantic Kernel 双双转入维护模式（只修 bug，不再加新功能），合并成一个新东西——Microsoft Agent Framework。
新框架最大的不同，是一上来就内置了生产级能力：可观测、安全集成、防 prompt 注入、合规监控。
这件事翻译过来是：
2026 年最大的变化，不是又出了个新框架，而是微软亲手停掉了自己最火的两个——因为企业要的从来不是炫技，是能上生产。
行业正在从「百花齐放的研究框架」，收敛到「少数几个能上生产的平台」。这是趋势。
可控 还是 自由：一条绕不开的光谱
企业落地，本质上是在一条光谱上做取舍：
左边是「确定性编排」——每一步你都画死了，AI 只能照走。可控、好测、好审计。 右边是「自主 Agent」——你只给目标，AI 自己决定下一步。灵活、强大、但难控。
可视化平台（Dify/Coze）偏左，对话式框架（AutoGen）偏右，LangGraph 这种状态机在中间偏左。
我的建议很简单：
越是高风险、强合规、要审计的场景（金融、医疗、政务），越往左站。越是探索性的、错了也没关系的场景，才往右走。 默认从单个 Agent 起步，确认真的能从「多个一起干」里捞到好处，再加人。不要为了多智能体而多智能体。
为什么强调这条？因为多智能体不是免费的。Anthropic 自己公布过：多智能体系统烧的 token，是单次聊天的十几倍。没做成本规划的团队，从原型到生产，账单能翻五十倍。
多智能体不是免费午餐——你多请一个 AI「员工」，是真的要发「工资」的。
在中国落地：两道绕不开的坎
中外格局差别很大。海外是代码框架 + 云平台为主，工程师主导；国内是低代码平台唱主角，业务也能上手。但国内有两道海外没有的硬坎：
第一道：模型不能随便用。 在国内做面向公众的 Agent 服务，模型必须用境内合规的——DeepSeek、通义千问、豆包这些。境外的 GPT、Claude 没在网信办备案，你用了就过不了合规这关。
第二道：可能要算法备案。 面向境内公众提供生成式 AI 服务，可能需要走《生成式人工智能服务管理暂行办法》的备案。（纯公司内部用、不对外，这条会轻很多。）
还有个很多人不知道的「小字陷阱」，关乎你能不能拿开源项目去创业：
同样是开源，Coze 是干净的 Apache 2.0，你能直接拿去商用；Dify 是「改过的」Apache 2.0，没拿到授权不能用它的源码做多租户 SaaS，连 logo 都不让你去掉。 协议里那几行小字，就是几百万的生意。看清楚再动手。
所以，到底怎么选？
把前面的话收成一张表。先问场景，别先问工具：
| 你的场景 | 选什么 |
|---|---|
| 快速验证想法、做 demo | Dify / Coze / n8n（低代码，当天跑通） |
| 业务运营自己想搭个工具 | Dify / Coze / FastGPT |
| 逻辑复杂、要上真生产 | LangGraph（状态机、可续跑、可观测最强） |
| 任务能按角色拆（研究员+写手+审校） | CrewAI |
| 对话驱动、要灵活的人机协作 | AutoGen / 微软 Agent Framework |
| 已经深度上云、想省运维 | Bedrock / Vertex / 百炼 / 千帆 |
| 强合规（金融/医疗/政务） | 国产平台私有化 + 境内合规模型 |
最常见的翻车姿势，是用 Dify 飞快验证完，直接想把它搬上高并发生产——然后一头撞进复杂逻辑和可观测的墙里。
记住一条路径就够了：
POC 用低代码快速验证 → 要上生产、逻辑又复杂，转代码框架（首选 LangGraph）→ 强合规走国产私有化。
最后
智能体编排没有「最好的工具」，只有「这个场景该用代码还是低代码」。
技术选型这件事，难的从来不是记住几个框架的名字，而是想清楚：我到底要解决什么问题、这个问题在哪一层、它会不会有一天要上生产。
想清楚了，工具自己会浮出来。 想不清楚，给你再多明星框架，也只是又一个死在谷底的漂亮 demo。
（这篇里所有的 star 数字，是 2026-06-26 当天用官方接口逐个实查的；采用率、成本这类数字都标了出处和立场。对外说话，我尽量做到每个数字都站得住。）