2026 Agent 框架六条路线全拆解——从踩过的坑里总结的选型指南

最近经常有人问我“该用哪个 agent 框架“。做了快两年 AI 咨询，接触过各种客户的各种场景之后，我的回答一般是——先别急着选框架，先搞清楚你的问题长什么形状。

因为 2026 年 agent 框架不是“哪个最好“的问题。是六种完全不同的设计哲学摆在你面前，你的场景适合哪一种。

选对了三周上线。选错了一个工程师浪费一个季度。这话不是我说的，是 Digital Applied 做完横向评估之后的原话——在框架之间迁移 tool definition、memory schema 和可观测性管道，正常情况下要吃掉一个工程师一整个季度的时间。

所以这篇文章我想把版图先理清楚，然后再说怎么选。

路线一：图状态机——LangGraph

LangGraph 把 agent 建模成一张有向图。节点是 agent、工具或检查点，边可以带条件。每一步的状态都可以持久化，可以回滚，可以被人审批之后再继续。

这是 2026 年企业生产环境的事实标准，没什么争议。Uvik 的研究列出了大约 400 家公司跑在 LangGraph Platform 上——Klarna、Uber、LinkedIn、BlackRock、JPMorgan、Replit 都在里面。月下载量 3450 万次，是所有 agent 框架里最高的。

LangGraph 赢在可控性。每一步走哪条路、什么条件触发分支、哪里需要人介入——全部在图里显式定义。你不需要猜 agent 做了什么，图就是执行路径。出了问题你能精确地指着某个节点说“就是这里做错了“。

代价是上手慢。从零到能写生产级 agent 大概需要一到两周，而且样板代码比别的框架多不少。如果你的任务其实不复杂，用 LangGraph 就是在用大炮打蚊子。

什么时候该用它：金融合规审批、客服多步处理、需要审计追踪和故障恢复的任何长流程。如果你的 agent 需要跟人说“你走到了第 4 步，第 3 步的判断是这样，你要不要改“——LangGraph 基本是唯一的选择。

路线二：Handoff 链——OpenAI Agents SDK

OpenAI 把之前实验性的 Swarm 项目做成了生产级的 Agents SDK。核心抽象是 handoff——agent 之间显式交接控制权，对话上下文跟着走。

开发体验是这六个框架里最好的。100 行代码以内就能跑起一个多 agent 系统。2026 年 4 月又加了 harness 系统和 sandbox 执行——说明 OpenAI 开始认真对待生产环境了。

但它有个硬限制。锁死在 OpenAI 的模型上。想在 Claude 和 GPT 之间切？想用开源模型？这个框架不支持。

什么时候该用它：你就想用最少的代码最快跑起一个能 demo 的 agent，而且你已经确定了全栈 OpenAI。原型验证速度是真快，这一点没有别的框架能跟它比。但你要想清楚 vendor lock-in 的代价。

路线三：角色协作——CrewAI

CrewAI 的思路是把 agent 按角色组织。你定义一个研究员、一个写手、一个审核员，把他们组成一个 crew，给个任务，CrewAI 管理协作。

44.6K GitHub stars，上手很快。那种天然有分工结构的任务——调研报告、内容流水线、竞品分析——用 CrewAI 做特别顺手。2026 年还加了 A2A 协议支持和企业级可观测性。

但这里有一个从实战中来的重要信息。Particula Tech 在他们的横向对比里指出：CrewAI → LangGraph 是目前最常见的框架迁移路径。团队在 CrewAI 里快速做完了原型验证，然后到了做生产的时候发现 CrewAI 的流程控制不够用，最终还是迁到了 LangGraph。迁移周期大概一到两周。

不是说 CrewAI 不好。是它的“角色协作“抽象在简单场景里非常优雅，但一旦你的任务需要条件分支、状态回滚、人工审批这种东西，你会发现 CrewAI 表达不了。

什么时候该用它：任务天然是“几个角色各干各的然后汇总“的结构。如果你一开始就知道最终要上复杂流程控制——考虑直接从 LangGraph 起步，省掉后面的迁移。

路线四：可视化平台——Dify

Dify 跟前面三个不是一个物种。它不是给工程师的框架，是给“不写代码但想用 AI“的团队的平台。

129.8K GitHub stars，比所有 agent 框架都高。但这个数字代表的不是技术影响力，是受众基数——非技术人员远比工程师多。

拖拖拽拽搭 AI 应用，连数据源，发布内部工具。运营团队搭知识库、产品团队搭客服机器人、市场团队做内容生成——这些场景 Dify 很合适。

但如果你需要精细控制 agent 的行为——条件逻辑、自定义 tool、复杂的上下文管理——Dify 不是为你设计的。它的目标用户是那些听到“写一个 TypeScript extension“就想跑的人。

什么时候该用它：团队里没有工程师，或者工程师的时间不应该花在搭内部工具上。老板问“能不能不招人就上一个 AI 系统“的时候，答案大概率就是 Dify。

路线五：厂商原生 SDK——Claude Agent SDK / Google ADK

模型厂商自己出的 SDK，跟自家模型有最深的集成。

Claude Agent SDK 把 Claude Code 的运行时开放成了一个可编程的库。内置工具、agent 循环、上下文管理，全是 Claude Code 的能力，现在你可以用 Python 或 TypeScript 调用。2026 年采用量增长很快，尤其是需要 MCP 原生支持和 Memory 功能的场景。

Google ADK 走的是层级化编排，原生集成 Vertex AI，支持 Python、TypeScript、Java、Go 四种语言。如果你整个栈在 Google Cloud 上，这是阻力最小的选择。

这两个 SDK 的优势是一样的：跟自家模型的配合是原生级别的。别的框架做不到这种深度。

劣势也是一样的：你被绑在一家 vendor 上了。想换模型？换框架吧。

什么时候该用它：你已经确定了用 Claude 或者 Google 作为主力模型，而且短期内不打算换。这时候用原生 SDK 的体验是最好的。但如果你还想保留 vendor 灵活性——这条路不适合你。

路线六：极简 Harness——Pi

Pi 是这六条路线里最特别的，也是最少人知道的。

前面五条路线不管怎么不同，有一个共同假设：框架替你做了大量决策。状态怎么管、流程怎么编排、工具怎么调用——框架都有预设的方式。你在框架划好的边界内工作。

Pi 拒绝这个假设。它的作者 Mario Zechner 就是写 libGDX 那个 badlogic——一个做了二十年底层框架的人。他的理念是：别替用户做决定，给他一组正交的、可组合的原语，让他自己搭。

所以 Pi 默认只给模型四个工具——read、write、edit、bash。没有 sub-agent，没有 plan mode，没有预设的编排逻辑。这些东西不是做不了，是故意不内置。你想要就自己用 TypeScript extension 搭一个，或者装一个社区的 Pi Package。

Pi 有三个让我觉得真正有分量的设计。第一，上下文工程是一等公民——AGENTS.md 加载、skills、prompt templates、动态 context 注入，都是核心功能。第二，compaction 完全开放——你能控制压缩时保留什么、丢什么，甚至能用自然语言指导摘要策略。第三，session 是树状结构——可以从任意历史节点分支，给 coding 任务的 trial-and-error 提供了版本控制。

Pi 还有一个很独特的理念：鼓励用户把 coding session 公开发布到 Hugging Face，用真实的工程 session 来改进 coding agent，而不是靠玩具 benchmark。

什么时候该用它：你是那种觉得别的框架“替我做了太多决定“的工程师。你想完全掌控 agent 的每一个行为。你愿意自己动手搭东西换来彻底的自由度。

什么时候不该用它：需要审计、权限、持久化的企业业务流。Pi 是 coding harness，不是企业 agent 平台。拿它做审批流就像拿瑞士军刀盖房子。

六条路线讲完了。怎么选？

选框架不是比功能列表。是看你的场景在几个关键维度上长什么样。

我自己选型的时候会看这么几个东西：

状态管理需求有多强？ 如果你的 agent 需要在崩溃之后从断点恢复，需要持久化每一步的状态——LangGraph 是唯一认真做了 checkpointing 的。短任务、一次跑完的——大部分框架都行，不用为这个上 LangGraph。

流程是直线还是分叉？ 直线的（A 到 B 到 C）CrewAI 和 OpenAI Agents SDK 都能覆盖。一旦有条件分支、循环、回滚——LangGraph。其他框架要么不支持，要么你得自己硬写。

需不需要人介入？ 关键决策必须人批准 → LangGraph 有原生的 human-in-the-loop。偶尔需要确认 → 大部分框架的 hook 都能做。

模型灵活性重要吗？ 想在多个 vendor 之间切换 → LangGraph、CrewAI、Pi，都是模型无关的。已经选定一家 → 对应的厂商 SDK 体验最好。

团队技术水平怎么样？ 非技术团队 → Dify。工程师但不想学一两周 → CrewAI 或 OpenAI Agents SDK。高级工程师想要完全控制 → LangGraph 或 Pi。

如果你读到这还不确定——用一个最简单的决策方式：你的 agent 最终会不会需要条件分支和人工审批？如果会 → LangGraph。如果不会 → 先用 CrewAI 或 OpenAI Agents SDK 跑起来验证，等撞到上限了再迁。

最后说一个容易被忽略的事。

MIT 分析了 300 多个企业 AI 实施项目，发现大约只有 5% 成功从试点走到了生产。

原文有一句话特别值得记住：“The failure mode is almost never the framework.”

失败的原因几乎从来不是框架。

是需求没想清楚。是数据没准备好。是上下文工程没做。是评估体系没建。是成本没算对。是人工审批流没设计。

框架只是容器。你往里面装什么，比你用什么容器重要得多。

做了两年 AI 落地，这个判断我越来越确信——客户从来不是因为“选错了框架“失败的。是因为在选框架之前，没把“这个 agent 到底解决什么问题、数据从哪来、出了错谁负责、效果怎么衡量“想清楚。

框架选型花一周就够了。这些问题想清楚可能要一个月。

但大部分团队把一个月花在选框架上，一周花在想问题上。

顺序反了。

先把问题想清楚。然后你会发现，框架自己就选出来了。