1. AI Agent 框架到底解决什么问题
过去两年，大量工程师走过同一条弯路：用 Python 几十行手写一个 ReAct 循环——LLM 输出工具调用、解析 JSON、执行工具、把结果拼回上下文、再让 LLM 继续。Demo 阶段非常顺，一旦放到真实业务里，工具一多就崩、上下文一长就漏、对话一深就忘记自己刚刚做过什么。
这不是模型能力问题，是工程问题。构建 Agent 和写软件，是两种工程——传统软件追求”输入相同则输出相同”，Agent 接受非确定性，但要求过程可控、可回滚、可重放。框架要解决的就是这三件事：状态管理、工具调度、可观测。
从社区演进看，第一代是 LangChain 这种”链式”抽象——把 prompt、tool、memory 串起来；第二代是 LangGraph 这种”图/状态机”抽象——把分支、循环、人审显式建模；第三代开始走两个方向，一边是面向产品经理的可视化 Dify/Coze/n8n，一边是面向资深工程师的”手搓 + Harness”（参见 从手搓代码到主流框架的工程化演进）。
更值得注意的是，Agent Harness 不是一个要安装的软件包，而是一组围绕循环、状态、工具、评估展开的工程实践。框架只是 Harness 的某种打包形态——理解这一点，才不会陷入”换个框架就能解决问题”的幻觉。框架能帮你少写几百行胶水代码，但帮不了你判断”这个任务到底该不该让 Agent 做、做坏了由谁兜底、做对了怎么沉淀”。这些问题不属于框架文档，属于团队工程文化。
所以在进入选型之前，先承认一件事：选框架从来不是 AI Agent 项目的核心难点。核心难点是把模糊的产品需求翻译成”输入是什么、输出是什么、什么算成功、出错时如何降级”，这一步做扎实了，框架选错也能跑通；做不扎实，框架选对也跑不动。下面所有横向对比，都建立在这个前提之上。
2. 主流框架横向对比
下表覆盖目前社区讨论最多的十款框架。”生产级”指是否在中大型团队真实上过线、”可观测”指框架自身是否提供 trace/eval/replay 能力（不依赖外挂）。
| 框架 | 定位 | 开发语言 / UI | 强项 | 不适合 | 生产级 |
|---|---|---|---|---|---|
| LangChain | 组件库 / 链式抽象 | Python / TS，纯代码 | 生态最广，集成最多，文档密度高 | 复杂分支、长循环、深状态 | 中等 |
| LangGraph | 状态图 / 工作流引擎 | Python / TS，纯代码 | 显式 state、check-point、human-in-the-loop | 简单单轮任务（过度工程） | 是 |
| LangSmith | 商业可观测 + 评测 | SaaS / 自托管 | 与 LangChain/LangGraph 原生联动 | 多框架/多供应商混合栈 | 是 |
| Langfuse | 开源 LLM 可观测 | Self-host / SaaS | 框架无关，trace/cost/eval 一站式 | 纯前端 LLM 调用（接入成本高） | 是 |
| n8n | 通用工作流（含 AI 节点） | 低代码节点编辑 | 400+ 集成，自托管成熟，自动化老炮 | 需要复杂 Agent 推理的场景 | 是 |
| Dify | LLMOps / Agent 应用平台 | Web 拖拽 + Code 节点 | 知识库、工作流、Agent、API 一体化 | 需要细粒度状态控制的复杂图 | 是 |
| Coze | 字节出品的 Agent 平台 | Web 拖拽 | 插件市场丰富，发布渠道多 | 需要私有部署或合规要求高 | SaaS 生产 |
| FastGPT | 开源知识库 + Agent | Web + 自托管 | 知识库切分策略丰富，国内场景 | 多 Agent 协作 | 是 |
| AutoGen | 微软多 Agent 对话框架 | Python | 多角色对话、群聊模式 | 线性确定流程 | 中等 |
| CrewAI | 多 Agent 角色编排 | Python | “角色 + 任务”心智模型直观 | 需要细粒度调度 | 中等 |
这张表里没有”最好的框架”，只有”在什么约束下最合适”。生态最广的 LangChain 不一定是生产首选，文档最密的 Dify 不一定能扛住复杂业务。社区有人把上面这些框架的取舍写成了 “搭 Agent 的脚手架：主流开发框架”，对比维度比这张表更细。
3. 框架选型决策树
选型时先问自己五个问题，比直接读 README 更省时间。
3.1 是否需要”非工程师”也能改
需要——直奔 Dify / Coze / n8n。Web 拖拽不是缺点而是产品边界，让运营、产品、客服可以独立改 prompt、加节点、配知识库，是这些平台的核心价值。不需要——纯代码的 LangChain / LangGraph 更轻。
3.2 流程是”链”还是”图”
“链”指线性 RAG、文档摘要、单轮问答这类场景；”图”指带分支、循环、回退、人审的复杂工作流。前者 LangChain 够用，后者必须 LangGraph 或类似的状态机框架——硬用链表达图，迟早被反复嵌套搞崩。超越 ReAct 循环：状态机与图结构的 Agent 设计 这篇把这一层讲得最清楚。
3.3 是否上生产
上生产意味着至少要回答这四个问题：错了怎么 trace、贵了怎么算账、出问题怎么回滚、版本怎么管。LangSmith / Langfuse 解前两个，Tilde.run 这类事务性文件系统沙箱解第三个，“把 Agent 送上生产：RAG、工程、安全、评测” 把这条链路完整拆过一遍，值得在选型前通读。
3.4 是否需要多 Agent 协作
需要——AutoGen / CrewAI / LangGraph 三选一。CrewAI 心智模型最直观（角色 + 任务），AutoGen 群聊模式适合”研究型”任务，LangGraph 适合”流程型”任务。OpenFR 用 LangGraph 模拟投研团队辩论就是后者的典型范例。
3.5 团队语言栈
Python 团队选择最多，几乎全框架支持；TypeScript / Node 团队首选 LangChain.js / n8n / Dify；Java / Go 团队建议直接基于 LLM API 手搓 + 引入 Langfuse 做可观测，不要在 JVM 上硬塞一个 LangChain Java 移植版。
4. LangChain 全家桶：链 → 图 → 监控
“LangChain”现在其实是一个生态名词，背后是四个相互独立但可组合的产品：LangChain（组件）/ LangGraph（编排）/ LangSmith（商业可观测）/ Langfuse（社区可观测，非官方但生态紧密）。理解四者的边界，比读任何单一文档都重要。
4.1 LangChain 本身：把组件标准化
LangChain 的核心价值不是”快”，而是把 LLM 调用、Prompt、Tool、Memory、Retriever 这些组件标准化成可替换的接口。换模型不用改业务代码、换向量库不用改检索逻辑——这是工程师真正在意的。LangChain 进阶实战：从基础组件到 Agent 动态编排 把组件层到 Agent 层的衔接讲得比官方文档更顺。
但 LangChain 不是没有代价。它的抽象有时过厚，简单的 OpenAI 调用经过几层 wrap 之后排查问题非常痛苦。如果业务只是”调一次 LLM + 解析 JSON”，直接用 SDK 比 LangChain 更清爽。
4.2 LangGraph：把循环显式化
LangGraph 解决的是”Agent 卡在循环里”这个核心问题。每个节点是显式的状态转换，每条边是显式的条件分支，整个 Agent 是一张可序列化的图。这意味着可以中断、重放、加 human-in-the-loop——这些能力在生产场景里是刚需，而不是锦上添花。
典型案例：AgentClaw 基于 LangGraph 封装 PC 控制 Agent，把”用一句话搭出能操作电脑的 Agent”做成了开箱即用——背后正是利用了 LangGraph 的状态机能力，把”识别意图 → 规划步骤 → 执行 → 校验”这条链拆成了可独立调试的节点。
4.3 LangSmith 与 Langfuse：可观测的两条路线
LangSmith 是 LangChain 官方的商业可观测产品，与 LangChain/LangGraph 深度集成，trace 自动采集，eval 与 dataset 管理在同一界面。代价是供应商锁定和数据出境（除非自托管，自托管又贵）。
Langfuse 走的是开源 + 框架无关路线——Langfuse 是 AI Agent 时代的可观测基础设施这篇分析了它为什么能在短时间内成为社区事实标准：装一个 SDK、几行代码、所有 LLM 调用都进 trace，cost、latency、token、用户反馈都可以打到同一条 span 上。如果你的栈混了 LangChain + 直接 OpenAI + 一点 Anthropic，Langfuse 比 LangSmith 更舒服。
同类思路还有 Ailens360 这类反向代理式可观测工具，一行配置接入，适合不想动业务代码的存量项目。把 OpenAI 的 base URL 切到代理上，所有请求就自动落 trace；缺点是拿不到框架内部的语义信息（比如”这是 LangGraph 的第三个节点”），只能看到底层 HTTP 调用。
实际上，可观测的取舍永远在”控制力”和”侵入性”之间——选 SDK 接入意味着代码里多几行 import 和 wrap，换来精细的 span 控制；选代理接入意味着代码零侵入，换来只能看到 LLM 层面而看不到 Agent 层面的执行细节。中小团队建议从代理接入起步快速看到数据，业务长稳后再升级到 SDK 接入做精细 trace。
5. 可视化与低代码方案
这一类方案不是”低端”的代名词，而是把 Agent 能力从工程师手里释放给业务团队的关键基础设施。判断标准很简单：如果改一个 prompt 都要发版部署，团队迭代速度就被卡死了。
5.1 Dify：当下国内首选的 LLMOps 平台
Dify 把”应用编排 + 知识库 + Agent + API 暴露”做成了一个完整产品。知识库切分、Workflow 节点、变量传递、外部 API 调用、Agent 模式——业务 80% 的场景拖拽就能完成。剩下 20% 通过 Code 节点写 Python 补全。生产级别的稳定性已经被大量国内团队验证。
5.2 Coze：字节生态绑定，发布渠道是杀手锏
Coze 最大的优势不在编排能力，而在”发布”——可以一键发布到飞书、抖音、微信公众号等渠道，对于做 ToC 内容机器人的团队非常友好。代价是 SaaS-only、数据出境、对私有部署需求强的团队不适合。
5.3 n8n：把 AI 节点塞进通用工作流
n8n 是从自动化 / iPaaS 演化而来的，AI 节点是它最近两年加上去的能力。优势是 400+ 集成和久经考验的自托管稳定性，适合”把 LLM 当成众多节点之一”的轻 AI 场景——例如收到邮件后调 LLM 分类、写入 Notion。如果业务核心就是 Agent 推理，n8n 反而不如 Dify 顺手。
5.4 FastGPT：知识库切分策略最丰富的开源选项
FastGPT 在国内 RAG 场景里有非常稳的位置，类似定位的开源 RAG 知识库平台这两年又涌现出一批，主要差异在切分策略、检索召回、混合搜索（关键词 + 向量）这些细节上。选型时不要只看 Star 数，先把自己业务的文档样本跑一遍 retrieval recall。
5.5 工作流自动生成的新趋势
低代码平台的下一步是”AI 写 AI 工作流”——workflow-skill 这类项目已经能自动为 Coze、Dify、ComfyUI 生成工作流配置。这是低代码方案的天花板被进一步抬高的信号，配合 Coze + Python 全栈实战课 这类”先用平台搭原型，再下沉到代码”的学习路径，会成为产品团队的主流姿势。
6. 轻量代码方案与多 Agent 协作
有一类工程师走过 LangChain 之后选择回到”裸 SDK + 自己写 router”——不是反对框架，而是判断了自己的业务复杂度不需要框架。这条路的代价是要自己解决：状态、重试、超时、并发、trace、eval。听上去吓人，实际上对于简单业务，几百行 Python 就够了。
6.1 CrewAI：把”角色 + 任务”做成一阶抽象
CrewAI 的设计哲学非常直白——把多 Agent 协作建模成”一群有角色的人接到任务并交付”。每个 Agent 有 role、goal、backstory，任务有 description、expected_output。用 Codex 一键生成 CrewAI 多智能体框架中文教程这个实践案例展示了它从零到 demo 的极低门槛。
缺点是细粒度调度能力弱——如果你需要”Agent A 执行到第 3 步时停下，让 Agent B 介入审查”这种精细控制，CrewAI 表达起来很别扭，LangGraph 才是答案。
6.2 AutoGen：群聊模式适合”研究型”任务
AutoGen 把多 Agent 协作建模成”群聊”——一群 Agent 在同一个 channel 里发言，由一个 manager 决定谁下一个说话。这种模式适合开放式探索任务（研究、辩论、头脑风暴），不适合强流程的生产任务。
6.3 Burr：Apache 孵化的”纯 Python 状态机”
不想接受 LangGraph 的抽象但又需要状态机能力的团队，可以看看 Apache 孵化项目 Burr——它把状态机做得更轻、更接近原生 Python，同时自带 UI 观察执行过程。在”想要 LangGraph 的能力，但讨厌 LangChain 全家桶”的人群里口碑很好。
6.4 何时不需要框架
下面这些场景，引入框架反而是负债：
- 调用链不超过 3 跳，状态不超过 5 个字段
- 团队没人愿意维护框架升级带来的 breaking change
- 业务对延迟极度敏感，不能容忍框架的抽象开销
- 已经有成熟的内部工具链（日志、监控、配置）不想适配框架风格
这种情况下，把”两个反馈圈”建好——一个是 prompt 在线优化的快圈，一个是离线评测改版的慢圈——比挑框架重要十倍。
7. 生产级 Agent 的可观测性
Agent 系统一旦上量，第一个崩溃的不是模型也不是代码，是”出了问题没人知道发生了什么”。LLM 评测的下一步是一张二维矩阵这篇提了一个很关键的判断：传统软件靠 stack trace 排错，Agent 系统必须靠”过程矩阵”——把每一次工具调用、每一次 LLM 推理、每一次状态转移都打成 span，事后才能复盘。
实践层面，目前的最佳实践组合是：
- Trace 层：Langfuse（开源、框架无关）或 LangSmith（商业、LangChain 原生）
- Eval 层：维护一个”金标准对话集”，每次发版前回归
- 反馈层：把用户的 thumbs-up / thumbs-down 打回到对应 trace 上
- 回滚层：版本化 prompt + 版本化工具，出问题能 1 分钟回到上一版
除了 Langfuse 这种 SDK-式接入，还有 反向代理式的 Ailens360——把 OpenAI base URL 换成它的地址就完事，对存量项目几乎零侵入。两种方式各有取舍：SDK 接入控制力强但要改代码，代理式接入零成本但拿不到框架内部的语义信息。
更进一步，Tilde.run 提供事务性可回滚文件系统沙箱，让 Agent 自由动手但任何破坏都能撤回——这种”给 Agent 上保险”的基础设施，会逐渐成为生产部署的标配。
8. 学习路径建议
8.1 新手路径：先跑通，再分层
给完全新手的路线（按这个顺序走，别跳）：
- 用 Dify 或 Coze 拖出一个能问答的知识库 Agent，理解”Agent = LLM + Tool + Memory + Loop”这个最小模型
- 用 LangChain 写一个等价的 Agent，看代码层面这些组件是怎么拼起来的
- 用 LangGraph 把流程升级成带分支的状态机，理解为什么纯链不够
- 接入 Langfuse，看 trace 才能真正理解 Agent 在循环里做了什么
- 读完 AI Agent 学习路径与资源盘点，按兴趣纵深
系统化补课可以看 179 集 Agent 全栈开发动画教程 和 180 集 AI Agent 开发全景指南，覆盖大模型原理、RAG 架构、生产级安全；想专攻 Cursor 那一套工程姿势的，看 Cursor 快速入门到精通。
8.2 生产团队路径：先决策，再实现
已经有团队、要上生产的路线和上面相反——先做决策，再选工具：
- 明确业务边界：哪些步骤可以非确定，哪些必须确定（这一步定了，框架就基本定了）
- 明确失败模式：Agent 出错时由谁兜底？是 fallback 到规则、还是降级到人工？
- 选 LangGraph + Langfuse 作为默认组合（除非有明确反对理由），先把”图 + 可观测”这两条底线立起来
- 建立评测集：哪怕只有 50 条人工标注的金标准，也比没有强一百倍——参考 “把 Agent 送上生产” 的评测部分
- 把FDE（Forward Deployed Engineer）这个角色提上日程——FDE 是 AI 落地的最后一公里，没有这个角色，再好的框架都接不到客户场景里
8.3 一条隐藏路径：托管 Agent 服务
对于不想自己维护 Agent loop 的团队，Anthropic 的托管 Agent 服务把循环、沙箱、工具编排都封装好了——实测 Claude 托管智能体这篇评估了它的边界：企业级能力出色，本地开发体验仍有打磨空间。在”自建 vs 托管”的天平上，团队规模小、合规要求低、迭代快的场景，托管反而是更聪明的选择。
9. 延伸阅读
这篇是 AI Agent 框架的鸟瞰视角。如果想往具体方向纵深，本站还有几个相关专题：
- Skill 化与封装：Agent 开发者面临的”技能管理”难题 和 将 Skill 封装为 SaaS 的 4 种方案
- Harness 思想：Loop Engineering 是 Harness 的局部命名 和 Agent Harness 是 AI 编程走向工程系统的一步
- Agent 规划范式：让 Agent 会思考：规划与推理范式
- 桌面端 / 长程任务：Gold Band 开源桌面端编排平台 和 全天候 AI 编程工作流的实现路径
选框架本质上是选约束。约束选对了，团队的迭代速度会跑赢任何”我们框架 SOTA”的宣传。约束选错了，再好的框架也只是给团队加上一副镣铐。先想清楚自己的业务在哪里，框架自然会浮上来。
