Agent SDK 还是多智能体框架？单 agent 场景别过度设计
数据截至 2026-07，价格与限额以各官网为准。
如果你的场景是一个 agent 调用一两个工具，那么 2026 年更快的路径通常不是先挑一个多智能体框架，而是直接用厂商提供的 Agent SDK——比如 OpenAI Agents SDK 或 Anthropic Claude Agent SDK。多智能体框架解决的是”多个角色如何协作、如何在有循环和分支的流程里保持可控”，这个问题你可能根本没有。
这条判断来自多篇 2026 年的第三方实战对比，它们把三大框架横向跑了一遍之后，反而在结论里前置提醒读者：先确认你需不需要框架。具体到各框架的能力细节与当前版本，仍以各项目官方文档当前版本为准。
一个常见误解：做 agent 的第一步是选框架
很多人立项时的动作顺序是这样的：先去搜”LangGraph vs CrewAI vs AutoGen”，看一堆对比表格，纠结两天选一个，然后开始学它的抽象——图、节点、边、状态字典，或者角色、任务、crew。等这套心智模型建立起来，一周过去了，真正的业务逻辑还没写一行。
问题在于，这些框架的价值主要体现在协作和流程控制上。如果你要做的是”用户提问→agent 判断该查数据库还是调搜索→拿到结果后回答”，这里面既没有第二个 agent，也没有需要反复回环的状态机。框架提供的那层抽象不但用不上，还会让调用链多绕几层，出问题时你得先分辨是自己的代码错了还是框架的行为不符合预期。
先写最朴素的版本，跑通，遇到具体的痛点再引入抽象，这个顺序更省时间。
单 agent 场景：SDK 路线具体省在哪
厂商的 Agent SDK 走的是”贴着模型能力做一层薄封装”的思路。工具定义、工具调用循环、多轮对话状态，这些是模型服务本身就要处理的东西，SDK 只是把它包成顺手的接口，中间没有额外的编排层。
实际收益有这么几点：
- 心智负担小。你要理解的概念基本只有”工具”和”一轮循环”，不需要先弄懂有向图或者角色分工模型。
- 排查路径短。请求发出去、模型决定调哪个工具、工具返回、模型继续——链路清晰，日志一看就知道卡在哪一步。
- 跟着模型能力走。厂商 SDK 通常最先跟进自家模型的新特性，不用等第三方框架适配。
代价也要说清楚：SDK 和具体厂商绑得比较紧，换模型供应商时改动量比框架方案大；而且它不负责跨 agent 的调度，一旦你真的需要多个角色并行推进，还是得自己写编排或者迁到框架上。
关于访问前提得诚实说明：这几家官方并未把中国大陆列为受支持地区，注册、控制台与 API 端点都在境外，其中 Anthropic 的官方受支持地区列表不含中国大陆（anthropic.com/supported-countries）。市面上存在第三方中转服务，但其合规性与稳定性风险由使用者自负，本文不提供也不背书任何具体渠道，也不暗示存在”官方直连”的办法。以各官网当前的地区政策页为准。
三个主流框架的心智模型不一样
真到了需要框架的时候，先别看功能清单，先看它让你怎么”想”问题——三者的底层模型差别很大：
- LangGraph：有向图。节点是函数或 LLM 调用，边定义控制流，状态以带类型的字典在节点之间传递。适合复杂的生产系统。
- CrewAI：一队有明确角色的 agent，比如研究员→写手→审稿，可以串行也可以并行。适合快速搭建、流程基本线性的场景。
- AutoGen / AG2：基于对话，agent 之间互相交谈。适合多方辩论、达成共识这类形态，它的对话模式是三者里最丰富的，在代码生成与调研上表现被多次提及。
你要解决的问题天然长什么样，就选形态匹配的那一个。硬把一个多方讨论的场景塞进有向图，或者把一个严格状态机塞进对话模式，都会别扭。
选型前必须知道：AutoGen 已进入维护模式
这是很多旧对比文章没跟上的变化：微软把重心转到了更大的 Agent Framework，AutoGen 的主要新功能开发已经停止，仍有 bug 修复和安全补丁，但社区正在寻找替代方案。有实践者的表述比较直接——2026 年不该把它作为任何新项目的起点。
需要就事论事地看待这件事：维护模式不等于项目终止。存量项目还在收 bug 修复和安全补丁，没有必要因为这条消息就恐慌性迁移；真正受影响的是新项目的起点选择，你投入的学习成本未来大概率不会有新功能回报。同样地，这不构成对 AutoGen 技术设计的否定，它的对话式模型至今仍是这一类形态里做得最细的。
别沿用旧结论：CrewAI 加了 Flows
另一处容易踩的时效坑：CrewAI 在 2025 年加入了 Flows，一种事件驱动的 pipeline 模式，面向更可预测的生产型负载。多数较老的对比文章没有涵盖这一点，所以你在搜索结果里常看到的”CrewAI 只能做原型、上不了生产”这个结论，已经不能直接照搬。
实操建议是：看到任何框架对比，先看发布时间，再对着项目仓库的更新记录核一遍关键结论还成不成立。agent 生态这两年的迭代速度，足以让一篇半年前的对比文在某几条上失真。
什么时候确实该上 LangGraph
按某次第三方实测对比的口径，各维度排序是这样的：学习曲线 CrewAI 最平缓、LangGraph 最陡；控制力 LangGraph 最强；生产成熟度 LangGraph 最成熟；token 效率 LangGraph 最好、AutoGen 开销最大；生态规模 LangGraph 最大。这是单次对比的结论，不是权威评测，参考着看。
LangGraph 对执行流的控制更精细，支持持久化的长时运行工作流与 human-in-the-loop，包含 checkpointing、streaming、human-in-the-loop 这几类原语。在带反馈环的循环任务上它明显占优——CrewAI 技术上也支持循环，但调试起来比较痛苦。
所以判断线可以定得很具体：流程里有循环、有分支逻辑、需要生产级可观测性、涉及团队协作、失败代价高，就往 LangGraph 走；一天内要出可用原型、流程基本线性，CrewAI 的上手成本最低。不存在”唯一最好”的选择：CrewAI 原型门槛最低，LangGraph 在生产上更经打，各自的位置很清楚。
互操作这一层：MCP 与 A2A
如果你的系统要接外部工具或者跟别家的 agent 通信，协议支持也得纳入考量。已知的是：CrewAI 已加入 A2A 支持；另有一个叫 OpenAgents 的框架声称自己是唯一原生同时支持 MCP 与 A2A 的框架——“声称”两个字要保留，这条没有独立核实过。协议层的具体分工可以看 Agent 侧的协议生态：MCP、ACP、A2A 各管什么，MCP 本身近期的规范变动见 MCP 新规范落地。
一条可操作的升级路径
不必一开始就把架构定死，可以按痛点往上走：
- 起点：用厂商 Agent SDK 写单 agent，把工具接好，业务跑通。
- 第一次感到不够：出现”需要在几个步骤之间反复回环""要人工介入审核""崩了要能从中断处恢复”这类需求，说明你需要的是状态与控制流，考虑 LangGraph。
- 另一种不够：出现”这活儿明显该拆成几个角色，各自有各自的职责和提示词”，且流程基本线性，CrewAI 的角色模型更贴合，Flows 可以处理更可预测的生产型负载。
- 迁移时：把工具定义和业务逻辑与编排层分开写，工具那部分才是你真正的资产，换框架时能整块搬走。
第 2 步和第 3 步不是二选一，很多系统最后是”外层用框架编排、内层某个节点仍然是一个朴素的 SDK 调用”。
诚实说局限
这篇给的是选型方向，有几处必须说明边界。各框架的版本号、具体 API 签名本文一律不写，因为迭代太快，写死了反而误导，请以各项目官方文档当前版本为准。上面的维度排序来自第三方实战对比，属于特定测试条件下的结论，换个负载形态排序可能就变了，尤其 token 效率这类指标跟提示词写法关系极大。另外，本文没有覆盖低代码平台这条路线，如果你的团队更需要可视化编排而不是写代码，那是另一套评估标准，可以对照 主流 AI Agent 框架对比：LangGraph/LlamaIndex/Coze 一起看。
小结
先确认你是不是真的需要多智能体：单 agent 加一两个工具的场景，厂商 Agent SDK 通常更快，也更好排查。真需要框架时，按问题的天然形态选——有向图选 LangGraph，角色流水线选 CrewAI，对话式协商是 AutoGen 的强项但它已进入维护模式，新项目起点要慎重。别拿半年前的对比文当结论用，CrewAI 的 Flows 就是个典型的时效坑。最后，把工具定义和编排层分开写，这样无论后面怎么换，核心资产都留得住。