Agent 框架的 token 开销差多少：选型时容易忽略的一笔
数据截至 2026-07，价格与限额以各官网为准。
多智能体框架的 token 开销不是一个可以忽略的实现细节，它由架构范式决定，量级差异在跑起来之前就已经写死了。让 agent 互相对话的框架，天然要把上下文来回复述；把控制流显式画成图的框架，能精确控制每个节点带什么进去。选型时如果只比上手速度和生态大小，很容易在上线三个月后被账单教育一次。
先承认一个常见误解：不少人默认「token 花多少是模型和提示词的事，框架只是个调度壳子，换框架不影响成本」。这个判断对单次调用成立，对多智能体编排不成立。多智能体的成本大头往往不在单条提示词写得长不长，而在于同一份上下文被复述了多少遍、一轮任务里发生了多少次模型调用。这两件事恰恰是框架的架构决定的，不是你写提示词能补救的。
需要提前说明的是，下面提到的对比结论主要来自 2026 年的多篇第三方实战评测，不是逐条核实过的官方一手数据。各框架都在快速迭代，涉及具体能力和用法，以各项目官方文档当前版本为准。
一、先问一句：你真的需要多智能体框架吗
这条得放在最前面，否则后面的对比都是在讨论一个你可能根本不需要解决的问题。
一个值得认真对待的提醒是：当你的场景其实只是单个 agent 调用一两个工具时，直接用 OpenAI Agents SDK 或 Anthropic Claude Agent SDK 往往是 2026 年更快的路径——你可能根本不需要多智能体框架。 多智能体编排层本身是有成本的：它要维护 agent 之间的消息传递、状态同步、角色设定，这些都会变成实打实的 token。为一个「查个资料然后总结一下」的需求引入完整的多智能体框架，等于给自行车装了个变速箱控制系统，复杂度和开销都白付。
判断方法很简单，问自己三个问题：任务里有没有需要多方独立判断再汇总的环节？有没有必须由不同角色分别持有不同上下文的理由？有没有需要循环、需要中途人工介入的流程？三个都答不上来，先用单 agent 方案跑通再说。不了解 agent 基本形态的，可以先看AI 智能体是什么和 ReAct 智能体的原理。
二、三种架构，三条消耗曲线
三个主流框架的编排模型完全不同，理解了模型就能理解成本从哪来。
LangGraph 用的是有向图：节点是函数或 LLM 调用，边定义控制流，状态以带类型的字典在图中传递。这个模型的关键在于，进入某个节点的上下文是你显式规定的——状态里放什么、节点读哪几个字段，都是代码里写死的。这意味着你可以让一个只负责格式校验的节点完全不看前面的长对话历史。控制粒度细，浪费就少。
CrewAI 用的是角色团队：一队有明确角色的 agent，比如研究员交给写手、写手交给审稿，可以串行也可以并行。这个模型贴近人类协作直觉，写起来快，但角色之间交接时带多少上下文，很大程度上由框架的默认行为决定，你想精细干预要多花力气。
AutoGen（及其分支 AG2）用的是对话：agent 之间互相交谈，通过多轮发言推进任务。它的对话模式最丰富，擅长代码生成与调研类任务，多方辩论、达成共识这类场景是它的强项。但对话范式的代价也在这里——每一轮发言通常都要带上此前的对话记录，轮次一多，上下文就滚雪球。
这三种范式对应的不是「谁写得好看」，而是「一轮任务打出去多少 token」。同一个需求，图式编排可能是若干次精确调用，对话式编排可能是十几轮各自携带完整历史的往返。
三、第三方对比给出的排序，怎么看
在某次公开的实测对比口径里，几个生产维度的排序是这样的：
- token 效率：LangGraph 最好，AutoGen 开销最大。
- 控制力：LangGraph 最强。
- 生产成熟度：LangGraph 最成熟。
- 生态规模：LangGraph 最大。
- 学习曲线：CrewAI 最平缓，LangGraph 最陡。
这是第三方评测的口径，不是官方基准，也没有给出可复现的绝对数字，所以正确的用法是把它当方向性参考，而不是当结论直接套进预算表。它的价值在于印证了上一节的架构推理：控制力最强的那个，token 效率也最好，这两件事是同一个原因的两个侧面——你能精确规定每个节点带什么上下文，自然就不会带多余的东西。
同样值得注意的是最后一条：LangGraph 学习曲线最陡。省 token 是有代价的，代价是你得亲手写清楚状态结构和控制流。团队里没人愿意维护这套图，省下来的 token 钱可能还不够补人力。
四、AutoGen 进入维护模式，这对选型意味着什么
这是 2026 年做这个选型必须先知道的一条信息：微软把重心转到了更大的 Agent Framework，AutoGen 的主要新功能开发已经停止，仍然有 bug 修复和安全补丁，社区里也有人在找替代方案。有实践者直言，2026 年不该把它作为任何新项目的起点。
这句话要就事论事地理解，不必过度解读。维护模式意味着新功能不再进来，不意味着代码明天就跑不了；已经在生产上跑着的 AutoGen 项目不必恐慌迁移，安全补丁还在。但如果你正在做新项目的技术选型，把一个不再演进的框架放进未来两三年的技术栈，需要一个足够强的理由——比如你的场景高度依赖它那套丰富的对话模式，而且短期内没有替代品。
把这条和 token 效率放在一起看，结论会更清楚：如果你正因为 AutoGen 的对话开销在犹豫，那么「开销大」和「新功能停更」这两件事同时指向同一个决定方向，不需要再纠结太久。
五、别再沿用「CrewAI 只能做原型」的旧结论
很多几年前写的对比文章会给 CrewAI 贴一个标签：适合快速原型，不适合生产。这个结论现在需要更新了。
CrewAI 在 2025 年加了 Flows，一种事件驱动的 pipeline 模式，面向更可预测的生产型负载。多数较老的对比文章没有涵盖这一点。 如果你看到的评测文章通篇只讲 Crew 和角色分工，没提 Flows，那它描述的是一个更早的版本状态。
事件驱动这个模式对 token 开销是有正面意义的：流程越可预测，被无谓触发的模型调用就越少。当然 Flows 的具体能力边界、和 Crew 模式怎么混用，这些属于 API 层面的细节，以官方文档当前版本为准，别照抄任何一篇二手文章里的代码片段。
需要同时指出的是，在带反馈环的循环任务上，第三方对比里是 LangGraph 胜出——CrewAI 技术上支持循环，但调试很痛苦。循环恰恰是 token 消耗最容易失控的地方：一个没设好退出条件的反馈环，能在几分钟内把预算跑穿。所以「我的流程里有循环吗」这个问题，值得单独拿出来问一遍。
六、把这笔账真正量出来的可操作做法
方向性的排序解决不了你的具体预算问题。想知道自己项目里差多少，只能自己量。给几个能直接上手的做法：
第一，先做一次单任务全链路计数。 选一个有代表性的真实任务，跑一遍，把这一轮里发生了多少次模型调用、每次调用的输入输出 token 分别是多少，全部记下来。不要只看总账单，总账单会把「调用次数多」和「单次上下文长」这两个完全不同的问题混在一起。具体做法可以参考Token 用量统计怎么做。
第二，重点看输入 token 的重复率。 多智能体最典型的浪费是同一段系统提示、同一份任务背景，在十几次调用里各发了一遍。把几次调用的输入内容拉出来对比，看重复前缀有多长。重复率高的话，稳定前缀吃缓存往往比换框架见效更快，这部分展开见 Token 成本优化。
第三，给每个 agent 的上下文设显式上限。 不管用哪个框架，都别让对话历史无限增长。常见做法是保留最近若干轮加一份滚动摘要，或者干脆规定某些角色只接收结构化的中间产物而不接收原始对话。
第四，同一个任务用两个框架各搭一个最小版本。 这听起来费事，但如果这个项目要长期跑，两天的对比成本远低于选错框架的迁移成本。搭最小版本时不要追求功能完整，只要能跑通主流程、能打出 token 计数就行。
第五，在循环和分支上设硬性熔断。 最大迭代次数、单任务 token 上限、超时时间，三个都要有。这不是优化，是止损——多智能体系统失控时，烧钱速度比单 agent 快一个量级。
第六，把计数做成常驻的，不是一次性的。 提示词改一次、模型换一次、加一个 agent，消耗曲线就变了。一次性测完就扔，三个月后你又不知道钱花在哪了。
七、按条件落到具体选择
综合架构、token 开销和维护状态，选型可以收敛成这样：
- 有循环、有分支逻辑、需要生产级可观测性、团队协作、失败代价高 → LangGraph。它对执行流的控制更精细，支持持久化的长时运行工作流与 human-in-the-loop，含 checkpointing、streaming、human-in-the-loop 原语。控制粒度细带来的直接好处就是 token 花得明白。
- 一天内要出可用原型、流程基本线性 → CrewAI。上手门槛最低，Flows 也让它在可预测的生产负载上比几年前有更多余地。
- 单 agent 加一两个工具就能解决 → 回到第一节，先别上多智能体框架。
不存在「唯一最好」这回事：CrewAI 原型门槛最低，LangGraph 生产上最经打，两者服务的是不同阶段的需求。原型阶段用 CrewAI 验证想法、生产阶段迁到 LangGraph，也是一条合理路线，只是要提前知道迁移是有成本的。
顺带提一下互操作性，这会影响你以后接工具生态的自由度：CrewAI 已加入 A2A 支持；另有 OpenAgents 声称是唯一原生同时支持 MCP 与 A2A 的框架——「声称」两个字要保留，这条没有独立核实过。协议侧的背景可以看 MCP 协议是什么和 Agent 协议生态对比。
八、诚实说局限
这篇能给的和不能给的，得说清楚。
不能给的是具体倍数。 你会在一些文章里看到「A 框架比 B 省百分之多少」这类数字，绝大多数没有说明测试任务、模型、上下文长度和并发设置。同一个框架，任务从「三步线性流程」换成「带五轮反馈环的调研」，消耗能差出一个量级。脱离场景的倍数没有参考价值，所以这里只给排序和成因，不给数字。
排序本身也有前提。 上面引用的维度排序来自第三方评测，不同评测者的测试方法、版本、任务设计都不一样，换一批人测出来的顺序完全可能不同。它可靠的部分是与架构推理一致的那部分，不可靠的部分是任何试图精确化的解读。
框架不是成本的唯一变量。 提示词写得啰嗦、上下文不做裁剪、所有子任务都用旗舰模型，这几件事任何一件的影响都可能盖过框架差异。换框架之前，先确认这三样已经处理过了，否则你换了框架也只是把浪费换个地方发生。
版本会变。 本文提到的维护状态、功能加入时间等，都是截至 2026-07 的公开信息，各项目的路线图随时可能调整。真正下决定前，去各自的官方仓库和文档确认一遍当前状态，别拿任何一篇文章（包括这篇）当最终依据。
小结
多智能体框架的 token 开销由架构范式决定：对话式互相复述上下文，图式可以精确规定每个节点带什么，中间还有角色流水线这一档。第三方评测的口径里 LangGraph token 效率最好、AutoGen 开销最大，这和它们的控制粒度差异是同一件事的两面。AutoGen 已进入维护模式，新项目选型时要把这条算进去，但存量项目不必恐慌迁移。别照搬旧文章对 CrewAI 的判断，Flows 之后它在生产负载上的定位已经变了。最重要的一条仍然是：先确认你是不是真的需要多智能体，再去比谁更省。