Agent Framework 应该怎么选？从多组公开 Benchmark 看性能、成本与工程边界

Agent Framework 正在迅速变成一个拥挤的市场。LangGraph、CrewAI、OpenAI Agents SDK、Google ADK、PydanticAI、Agno、AutoGen、Semantic Kernel 等框架都在提供 Agent Loop、Tool Calling、Memory、Workflow、Multi-Agent 以及 Human-in-the-Loop 等能力。对于真正准备落地 Agent 的团队，一个越来越现实的问题是：到底应该选哪个框架？

最常见的选型方式是看功能表，比如这个支持 Memory、那个支持 Multi-Agent；这个有 Workflow、那个支持 MCP，再对比 GitHub Star，最后各写一个 Demo。但这些指标很难回答真正重要的问题：不同 Agent Framework 是否会影响最终任务效果？更复杂的编排是否真的能提高准确率？不同框架的 Token、延迟和开发成本差多少？一个 Benchmark 表现好的框架，在生产环境里是否依然值得选择？

2026 年以来，开始出现一批针对 Agent Framework 本身的系统性研究，从运行效果、开发难度、架构开销和开源维护等角度提供了公开数据。本文选取四组研究进行交叉分析，如下表所示。

表1：本文使用的四组公开研究

这些研究实验设计并不完全一致，因此不能简单拼成“Agent Framework 排行榜”，但放在一起可以看到一个更重要的趋势：Agent Framework 的竞争正在从“谁提供更多能力”，转向“谁能以更低系统成本，让模型稳定发挥已有能力”。

一项 2026 年研究在统一使用 GPT-5.2 的条件下，对 22 个 Agent Framework 在 BBH、GSM8K 和 ARC 上进行了测试，共运行 16,495 个任务。为了控制变量，研究统一了模型、Prompt、Temperature 和执行环境，并采用相同的两 Agent 结构：一个 Agent 负责执行，一个 Agent 负责验证和修正。

部分结果如下：

表2：部分 Agent Framework 在统一推理任务上的准确率

最值得注意的不是排名，而是一个更关键的事实：12 个主流框架的平均准确率集中在 74.57%～75.94%，最大差距约 1.4 个百分点。这意味着在模型、Prompt 和任务一致的情况下，Framework 本身并不会显著改变模型的推理能力。

原因也很直接：Agent Framework 主要负责的是 Agent Loop、Tool 调用、State 管理、多 Agent 协调、Retry 和 Context 管理。这些机制决定的是模型如何被组织和使用，而不是改变模型本身拥有什么能力。因此，单纯问“哪个框架准确率最高”本身就不是一个特别好的问题。真正值得关注的是：为什么同样的模型进入不同 Framework 之后，有时表现几乎相同，有时却会突然相差几十个百分点？答案更多来自系统执行过程，而不是推理能力本身。

当大部分正常运行的框架准确率非常接近时，极端差异往往来自系统失控。

一个典型案例是 Camel。在上述实验中，它的 BBH 测试运行超过 11 天仍未完成，GSM8K 也运行约 73 小时后没有结束。研究者分析日志后发现，一个核心问题是 uncontrolled context growth：Memory 和历史交互不断累积，系统又反复尝试压缩和重组 Context，导致 Prompt 持续膨胀，Token 和 API Call 越来越多，但真正有效的任务推进却非常有限。此时问题已经从：“模型能不能回答这个问题？”变成了：“框架能不能阻止 Context Management 自己变成新的任务？”

AutoGen 暴露的是另一类问题。它在 ARC 上仍达到 90.94%，但 BBH 和 GSM8K 分别只有 24.08% 和 4.55%。实验中观察到复杂任务产生了大量迭代式 Agent Interaction。更多 Agent Turn 同时意味着更多 API Request、更长 Prompt 和更高的失败概率。不过，这并不能直接说明 AutoGen 本身能力较弱。这项实验给不同框架统一套用了“两 Agent：执行 + 验证”的结构，而不是针对每个框架采用其最佳实践。因此更合理的解释是：不同 orchestration pattern 与 framework execution semantics 结合后，会产生截然不同的系统行为。

更极端的案例来自 Upsonic。在部分任务中，它累计消耗约 478 万 Token，成本约 1434 美元。真正的问题并不是某一次模型调用特别昂贵，而是出现了这样的循环：

Extraction Failure → Retry → Context 增长 → Prompt 变长 → 再次失败 → 再次 Retry

Memory 和 Execution Trace 又持续进入后续 Context，于是一个原本局部的格式错误，被 Agent Loop 不断放大。

这也解释了为什么 Agent 系统的成本结构和传统软件系统很不一样。在 16,495 个任务中，这项研究累计记录约 10.86B Input Tokens、685,443 次 API Request、约 3154 美元成本和 575 小时运行时间。大量 Token 并不是消耗在最终回答上，而是消耗在反复进入模型的 Context、Memory、Tool Schema、System Instruction 和 Execution Trace 中。

但如果只观察正常完成任务的框架，差距反而没有那么夸张：多数集中在约 4～6 秒/任务、0.14～0.18 美分/任务。PydanticAI、OpenAI Agents 等处于较优区间，CrewAI 成本较低，LangGraph 延迟相对更高。因此，Agent Framework 的成本差异并不是简单线性的。系统正常运行时，框架之间可能只差几十个百分点；一旦 Agent Loop、Retry 或 Context Management 失控，差距就可能迅速放大到数量级。

MAFBench 的受控实验进一步证明，这并不只是少数实现 Bug 导致的偶然现象。在控制模型和任务变量后，研究发现仅 Framework Architecture 的差异，就可能造成超过 100 倍的 Latency 差异、约 30% 的 Planning Accuracy 波动，以及 Coordination Success 从 90% 以上下降到 30% 以下。原因在于 Orchestration 本身会创造新的 decision point。原本模型只需要解决业务任务；进入 Agent Framework 后，还可能需要不断判断：是否调用 Tool、调用哪个 Tool、参数是否符合 Schema、是否委派给其他 Agent、是否 Retry、State 是否一致、任务是否完成，以及是否应该退出 Loop。

这可能比“框架功能越多越好”更值得作为选型原则。

运行性能之外，还有另一个很难忽略的变量：

开发者到底能不能把框架正确用出来？

一个使用 LangGraph 三年的工程师和第一次接触 LangGraph 的工程师，即使底层模型完全一样，也可能写出完全不同的 Agent。

ADK Arena 尝试用 LLM-as-a-Developer 的方式控制这个变量。研究让统一的 Coding Agent 阅读不同 Framework 的文档和源码，自行完成：

Explore → Write → Validate → Debug → Repair

之后再把生成出来的 Agent 放入 SWE-bench、τ²-bench、MCP-Atlas 和 TerminalBench 等任务中测试。

整个研究覆盖 51 个 Python Agent Framework、204 个 Framework × Benchmark 组合，并生成了 408 个 Agent。其中只有 232 个 Agent 成功通过完整构建验证，整体通过率约 57%；不同框架生成单个 Agent 的成本约在 0.6～3.4 美元之间，相差约 5.6 倍。需要注意的是，这里的“通过”还不是指 Benchmark 做对了。它仅仅意味着：Developer 成功使用这个框架写出了一个真正可以运行的 Agent。因此，它衡量的实际上是过去很少被量化的一项指标：Framework Learning Cost 和 Development Cost。这背后同时包含 API Surface、Documentation、Framework Complexity 和 Debug Difficulty。

更有意思的是，ADK Arena 还发现：即使 Framework 相同、Execution Model 相同，只是换一个 Developer 编写 Agent，最终 Benchmark 结果也可能相差几十个百分点。例如，同样是 LangGraph，同样使用 GPT-5.4 Nano 执行，不同 Developer 生成的版本在 TerminalBench 上可以从约 16% 提升到 36%；其他框架也出现了类似现象。因此所谓 Framework Performance，实际上更接近：Framework × Implementation × Model，而不是 Framework 单独决定的结果。

这也是为什么一个框架“支持 Memory、Multi-Agent、Workflow”并不意味着系统自动获得这些能力。功能只有在正确进入 Agent Loop 和执行路径之后，才会真正变成任务能力。

如果准备把 Agent Framework 放入生产环境，仅比较 Accuracy、Token 和 Latency 仍然不够。还有一个很现实的问题：

今天跑得起来的框架，三年后还能不能稳定维护？

一项 2026 年研究分析了 AutoGen、CrewAI、Haystack、LangChain、Letta、LlamaIndex、Semantic Kernel 和 SuperAGI 八个大型开源 Multi-Agent 项目。样本包含 42,267 次 Unique Commit 和 4,731 个最终通过代码修改解决的 Issue。其中：

• 40.8% 的 Commit 属于功能增强，
• 27.4% 属于 Bug 修复，
• 24.3% 属于适配性修改。

在 Issue 中，Bug 占约 22%，Infrastructure 问题约占 14%，Agent-related 问题约占 10%。不同项目的问题修复时间也存在明显差异，从不到一天到十余天不等。这组数据提醒我们：Benchmark 回答的是“今天能不能跑”，维护数据回答的是“出了问题以后有没有人修”。而 Agent Framework 面临的外部变化比一般软件框架更加剧烈：模型 API 在变，Tool Calling Schema 在变，MCP 在变，Provider 在变，Agent abstraction 本身也在快速演进。所以 Framework Selection 本质上也是一个长期工程依赖决策。一个 Benchmark 分数略高、但生态不稳定的框架，未必比一个性能稍低、但迭代路径和兼容性更可控的框架更适合企业。

综合这些公开研究，我并不建议做一个从第一名排到第十名的“Agent Framework 总榜”。

更合理的方法，是先判断你的系统究竟需要多少复杂度。

如果任务本质上只是：

LLM → Tool → LLM → 输出

那么应该首先考虑轻量 Agent SDK，例如 OpenAI Agents SDK、PydanticAI。此时增加复杂 Graph、Multi-Agent 或长期 State 可能并不会带来足够收益，反而增加 Failure Surface。

如果任务需要明显的 State Transition、Conditional Branch、Checkpoint、Human Approval 或长任务恢复，那么 LangGraph 这类显式 Graph abstraction 的价值会开始体现。它最大的优势不是让 Agent 更聪明，而是让复杂执行路径变得显式、可控。

如果业务天然存在角色分工，比如研究、内容生产、市场分析或跨专业协同，CrewAI 的 Agent、Crew 和 Flow 抽象会更加自然。但这里必须判断：不同 Role 是否真的拥有不同工具、知识或职责边界，而不只是同一个模型换了几套 Persona。

对于已经深度依赖 Google Cloud 和 Gemini 的团队，Google ADK 的生态整合价值往往比几个百分点的 Benchmark 差异更加重要。

如果希望同时获得 Agent、Team、Workflow，以及统一 Runtime 和治理能力，则可以进一步考察 Agno 这类更加平台化的方案。它减少的是自行拼接 Agent Infrastructure 的工作，但相应也意味着更大的 API Surface 和平台复杂度。

AutoGen 仍然是研究 conversational multi-agent orchestration 的重要样本，但对于今天新建的生产系统，还应该额外考虑其项目生命周期和 Microsoft 后续 Agent Framework 的迁移方向。

因此真正合理的选型顺序应该是：

先问单 Agent 能不能完成，再问是否需要 State，再问是否真的需要 Multi-Agent，最后才选择 Framework。

到了最后这一步，真正值得比较的指标已经不是 Feature List，而是：

• Task Success Rate、
• P50 / P95 Latency、
• Input / Output Token、
• Tool Call Success Rate、
• Retry Count、
• Context Growth、
• Failure Recovery、
• Human Intervention Rate，
• 以及开发和 Debug 工作量。

综合多组公开研究，可以得到三个相对稳定的结论。

第一，主流成熟框架之间的纯推理准确率差距并没有想象中那么大。

在统一 GPT-5.2 和两 Agent 实验条件下，12 个框架的平均准确率集中在 74.57%～75.94%，最大差距只有约 1.4 个百分点。

第二，真正能够把差距放大到数量级的，是 Orchestration Failure。

Context Growth、Retry、Memory、Agent Communication 和 Planning 的实现差异，可能让一个原本正常的任务变成长时间运行和高 Token 消耗；MAFBench 进一步表明，Framework Architecture 本身就足以显著改变 Planning 和 Coordination Reliability。

第三，Framework Performance 并不是 Framework 自己决定的。

ADK Arena 显示，同一个 Framework、同一个 Execution Model，仅仅因为 Agent Implementation 不同，就可能产生几十个百分点的结果差异。

因此，在实际选型中，我不会从“LangGraph、CrewAI、Agno、OpenAI Agents 谁最强”开始。

我会先定义真实 workload，确定完成任务所需要的最小可行编排复杂度，然后选择两到三个框架进行 PoC。

因为 Agent Framework 的核心价值并不是让模型凭空获得新的智力。

未来 Agent Framework 的竞争重点也不会只是 Feature 数量。

真正重要的问题会变成：

谁能够让复杂 Agent 系统的失败边界更清晰、更可观察，也更可控。

参考文献

1. ADK Arena: Agent Development Kit Benchmarking Study./benchmarking-study, 2026.
2. Agentic Frameworks for Reasoning Tasks./frameworks-study, 2026.
3. MAFBench: Multi-Agent Framework Benchmark for Orchestration Systems./orchestration-benchmark, 2026.
4. Multi-Agent AI Systems Open Source Study./open-source-analysis, 2026.