# 同题不同答：六框架方差税实测
## 概述
把同一条任务（Researcher→Analyst→Writer 三段流水线）在五个框架里各跑九遍、用本地 Qwen3-14B 消除网络抖动，结论令人意外：**输出质量极差只有 0.56 分（9.31 到 9.87），但运行方差极差达到 4.5 倍（标准差 0.10 对 0.45），端到端延迟差 6 倍，token 消耗差 4 倍。** 智力是模型的活，方差才是框架的活。选框架选的不是"答得多好"，而是"同样的问题，第二次还能不能给出差不多的答案、会不会重复扣款、崩溃后能不能精确接上"。这层隐性成本——方差税——才是 2026 年生产级 Agent 的真正分水岭。
## 六框架方差与开销对比
| 框架 | 多步准确率 | 单任务成本 | 单次token | 质量σ（方差） | 副作用语义 | 重启恢复 | 调试器(1-5) |
|------|-----------|-----------|----------|--------------|-----------|---------|------------|
| LangGraph v1.2 | 94% | $0.08 | 8,823 | 低（0.10级）| 恰好一次+幂等 | 1.8-2.4s | 4.5 |
| OpenAI Agents SDK | 90% | $0.11 | 8,676 | 中 | 至多一次(自写) | 12-22s | 4.0 |
| Google ADK 0.9 | — | — | — | 中 | 至少一次 | 3.1-4.0s | 3.5 |
| CrewAI v1.14 | 87% | $0.12 | 27,684 | 中高 | 无内置 | 不支持 | 2.5 |
| AG2/AutoGen | 91% | $0.45 | 10,793 | 高（0.45）| 无内置 | 事件回放 | 3.0 |
| Strands v1.34 | 89% | $0.10 | — | 由模型主导 | 手动 | 手动 | OTEL |
注：质量σ、token、延迟来自同一受控基准（45 次评测、本地模型、9 次重复）；准确率与成本来自 2026 Q1 聚合基准。跨基准口径不同，看相对排序而非绝对值。
## 一、质量悖论：模型出智力，框架出方差
这是整组数据最反直觉的一条。用 LLM 评判官给五框架打分，最高 MS Agent 9.87，最低 Agents SDK 9.31，**极差仅 0.56**。把同一框架跑九遍，方差（标准差）的极差却是 4.5 倍——MS Agent 的 σ 只有 0.10，AutoGen 的 σ 高达 0.45，意味着同一输入的输出可能在满分 10.0 和 8.6 之间来回横跳。
结论一句话：**决定"答得好不好"的是底座模型，决定"答得稳不稳"的是编排框架。** 当所有人都在比谁的准确率高 1 个百分点时，真正掏空生产预算的是那 0.45 的方差——因为它逼你套上重试、校验、人工兜底三层外壳，每一层都在烧 token、烧延迟、烧工程人月。方差税是复利税：方差越高，补偿层越厚，补偿层越厚，单任务成本越高。
## 二、方差即死刑：σ=0.10 与 0.45 的现实代价
为什么 0.45 的方差在生产里近似死刑？把它换算成可观测的工程动作就明白了。假设业务要求输出质量稳定在 9 分以上才能入库：
- σ=0.10（MS Agent/LangGraph 这类确定性编排）：均值 9.4，几乎不会跌破阈值，无需兜底。
- σ=0.45（AutoGen 群聊式协商）：均值 9.4 也会偶尔掉到 8.6，必须挂一道 LLM 复核闸门。这道闸门意味着**每个正常任务要多跑一次完整推理**，成本翻倍。
更狠的是评测稳定性。方差大的框架，评测集跑两遍分数能差一截，导致你根本分不清"是我改了提示词导致回归"还是"框架本身在抖"。这就是为什么不少团队把 AutoGen 原型推进生产后，又悄悄退回 LangGraph——不是答得不好，是答得没法预测。**方差不是质量问题，是可工程化问题。**
## 三、副作用语义：四档交付保证，决定能不能上账本
方差最致命的下游后果，是副作用不可控。iotdigitaltwin 的 24 小时存活基准（Workload 3：200 步审阅，第 100 步强杀容器）把框架分成四档语义：
- **恰好一次（exactly-once）**：LangGraph。PostgresSaver 存第 99 步全状态，重启从第 100 步续，配合幂等键，即便模型重跑，下游数据库、Slack、消息队列每个副作用只发生一次。这是计费级、审计级、合规级的交付保证。
- **至少一次（at-least-once）**：Google ADK。3-4 秒能恢复，但写路径要应用层去重，否则同一条会写两次。
- **至多一次（at-most-once，自写）**：OpenAI Agents SDK。无原生检查点，靠你自己每步持久化、重启时重建，实测 12-22 秒，且高度依赖你写的代码质量。
- **无内置**：CrewAI。内存模型，崩溃即丢全部进度；AG2 走事件回放但同样不保证副作用幂等。
LangGraph 恰好一次的代码骨架：
```python
from langgraph.graph import StateGraph, START, END
from langgraph.checkpoint.postgres import PostgresSaver
from typing import TypedDict
class ReviewState(TypedDict):
step: int
findings: list
last_doc_id: str
def review_step(state):
doc = fetch_next_doc(state["last_doc_id"]) # 幂等键 = doc.id
return {"step": state["step"]+1,
"findings": state["findings"]+[classify(doc)],
"last_doc_id": doc.id}
def should_continue(s): return "review_step" if s["step"]<200 else END
g = StateGraph(ReviewState)
g.add_node("review_step", review_step)
g.add_edge(START, "review_step")
g.add_conditional_edges("review_step", should_continue)
app = g.compile(checkpointer=PostgresSaver.from_conn_string("postgresql://..."))
# 同一 thread_id 重跑，容器死在第100步也从100续，findings 不丢
```
## 四、非幂等原罪：LLM 采样即不可复现
需要破除一个幻想：**没有任何框架能在模型层做到真正恰好一次。** LLM 调用本身因采样（temperature/top-p）而非幂等——同一句话问两遍，模型给两个答案。这是物理限制，不是框架偷懒。
关键区分在于：**方差不可消除，但方差可被隔离在"模型层"，不让它泄漏到"副作用层"。** LangGraph 的价值不是让模型变得确定，而是在模型与副作用之间插一道"检查点步计数器 + 幂等键"的阀门——模型可以抖，可以重跑，但"扣款、发消息、写库"这些有外部影响的动作，每个只发生一次。而 CrewAI 这类无检查点的框架，模型抖动直接泄漏成副作用抖动：崩溃重启可能重复发邮件、重复扣费。
这条直接决定训练营该怎么讲：**别教"如何让 Agent 更准"，教"如何让 Agent 的副作用可幂等"。** 后者才是企业付费的痛点——金融、医疗、法务场景里，一次重复扣款就够买全年 LangSmith 订阅。
## 五、持久化即一致性：检查点是方差税的对冲工具
把方差税和上一节的副作用语义拼起来，会发现一个被低估的等式：**检查点 = 一致性的物理载体。** 没有检查点的框架，方差没有边界；有检查点的框架，方差被关在第 N 步的笼子里。
具体到成本：LangGraph 每步检查点占 4-12KB 磁盘，ADK 6-18KB，CrewAI/OpenAI 则无（in-memory 或无）。这点磁盘开销换来的是"崩溃只丢一步"的粒度保证。对比 OpenAI Agents SDK 只在对话轮边界持久化、CrewAI 默认什么都不存——崩溃粒度从"丢一步"退化到"丢整轮"甚至"丢全部"。
LangGraph 的检查点还能做时间旅行调试：从任意检查点回退重放。这对定位"方差到底在第几跳放大"至关重要。方差税的对冲，本质就是为每一步买单留下存证。**省检查点是伪节约**：省下的几 KB 磁盘，换来的是崩溃后无法解释、无法回滚的方差黑洞。
## 六、调试器税：回放能力决定回归成本
方差的存在让"回归检测"成为日常动作，而调试器决定检测成本。iotdigitaltwin 用 1-5 分评估三件事：trace 完整度、回放支持、时间旅行状态检查。
- **LangSmith + LangGraph：4.5 分**。每个节点写完整 trace（输入态、输出态、提示词、补全、token、延迟），一键回放，时间旅行内建。代价是收费。
- **OpenAI Traces UI：4.0 分**。展示工具调用、handoff、模型轮次，回放到 response 级，时间旅行有限。
- **Google Cloud Trace：3.5 分**。通用分布式追踪，LLM 特化（提示词 diff、token 成本叠加）需另接 Vertex Experiments。
- **CrewAI（仅 OpenTelemetry）：2.5 分**。能把 trace 接进 Honeycomb/Datadog，但 span 默认不带 LLM 上下文。
实测经验：**调试器差 1.5 分，约等于每个提示词回归多花 2-3 倍工程人时。** 一年下来，调试器税远超框架的 token 开销税。"先优化调试器，再优化 token"——这是方差高发环境下唯一对的排序。
## 七、词税膨胀：角色剧本每轮重注
方差税还有一个隐形放大器：token 膨胀。同一三段流水线，MS Agent 用 7,006 token，CrewAI 用 27,684 token，**差近 4 倍**。根因是 CrewAI 的 role/goal/backstory 三件套每个轮次都要重新注入——一段 200 token 的人物小传，跑 10 轮就是 2000 token/任务。
iotdigitaltwin 的每步开销数据印证同一规律：LangGraph 80-140 token/步，OpenAI 40-90，ADK 120-200，CrewAI 160-260。换算成钱：GPT-4o-mini 上 1 万次/日，框架开销差约 $36/月；换 Claude Opus 4.1 后端，同样负载差到 $3600/月。**框架开销在高端模型上呈线性放大。**
更致命的是 prompt 缓存。LangGraph 和 OpenAI Agents SDK 产出缓存友好的稳定前缀；CrewAI 因为角色小传位置逐轮漂移，前缀失效，缓存几乎用不上。token 税和缓存税叠加，CrewAI 在长任务上的真实成本账单会比基准数字还难看。
## 八、控制权与简洁的张力：方差的设计哲学源头
六框架的方差差异，根子在设计哲学。两条路线：
- **模型驱动派（Strands、Claude Agent SDK）**：把规划、路由、停止全交给模型，框架只给 Model/Tools/Agent 三个原语。极简，但方差完全由模型决定，框架无从收口。Strands 连状态都"故意"做得轻——它的极简是特性，代价是持久化要你自己接 DynamoDB。
- **图驱动派（LangGraph）**：用状态图把执行路径钉死，节点是纯函数，边是条件谓词。啰嗦、学习曲线陡（团队普遍 1-2 周才上手），但方差被图的确定性压住，副作用可幂等。
OpenAI Agents SDK 取中间路线：handoff 链式交接，代码最短、延迟最低，但 handoff 不跨容器重启持久化——简洁的代价是耐久性悬崖。CrewAI 选了角色抽象，原型最快（<50 行起一个多智能体），代价是"原型之后的所有东西"（耐久、可观测、工具纪律）都要自己补。**方差税不是 bug，是每条设计路线主动选择的代价。**
```mermaid
flowchart LR
U[同一输入] --> M[模型层:采样非幂等
方差不可消除]
M --> Q{框架有检查点+幂等?}
Q -->|无 CrewAI/AG2| LEAK[方差泄漏到副作用
重复扣款/重复消息]
Q -->|有 LangGraph| GATE[步计数器+幂等键
方差被关进笼子]
GATE --> SAFE[恰好一次副作用
可上账本]
LEAK --> TAX[方差税×重试×兜底
成本复利膨胀]
SAFE --> PROD[生产可交付]
```
## 推荐方案
按"方差点"而非"功能点"选框架，是 2026 年唯一划算的选型逻辑：
- **能跑超过 15 分钟、或要扛容器重启的场景**：默认 LangGraph。恰好一次副作用是能用钱买到的最便宜的保险，自定义代码补不出这个差距。Klarna、Uber、LinkedIn 都在用它跑大规模生产不是偶然。
- **纯 GCP + Vertex 推理**：Google ADK。集成省下的工程量是实打实的，至少一次语义对绝大多数负载够用。
- **<10 工具、<5 分钟会话、只用 OpenAI 模型的聊天助手**：OpenAI Agents SDK。延迟最低、代码最短，但要清醒知道它没有原生检查点，跑长了得自写。
- **黑客松、内部工具、原型演示**：CrewAI。最快出活，但**现在就定好迁移日期**——两季度内大概率要迁去 LangGraph，因为 token 税和方差税会吃掉原型红利。
- **复杂多轮协商、写代码-评审-执行闭环**：AG2。群聊模式擅长这类，但要为 0.45 的方差预算一道复核闸门。
- **纯 AWS + Bedrock，工具数上千**：Strands。它的语义检索能在 6000+ 工具里动态召回，是工具过载场景的唯一解。
通用铁律三条：第一，**day-one 就接 OpenTelemetry**，事后补 trace 比重写还痛；第二，**按线程设成本预算并强制执行**，别指望模型自律；第三，**把框架写成自己领域模型上的一层薄壳**——自定义 Step/Decision/ToolResult 类型，框架只做胶水。18 个月内你至少会换一次框架，领域层能活下来，方差税就不会重收第二遍。
变现落点很清晰：**"副作用幂等化"训练营**比"Agent 准确率提升"训练营好卖十倍，因为前者对应审计、合规、计费等真金白银的痛点；后者对应的是模型升级就能免费拿到的红利。把"如何让你的 CrewAI 原型扛住第一次崩溃"做成产品化迁移服务，是 2026 下半年最确定的细分市场。
## 参考来源
1. [Benchmarking 5 AI Agent Frameworks: Performance, Cost, and Consistency — n1n.ai / dev.to](https://explore.n1n.ai/blog/benchmarking-5-ai-agent-frameworks-performance-cost-consistency-2026-02-16) — 45 次受控评测、本地 Qwen3 消除网络抖动，提供质量极差、token、延迟与标准差(σ=0.10 vs 0.45)的核心方差数据。原始来源 dev.to/lukaszgrochal。
2. [Agent Framework Benchmark: LangGraph, OpenAI SDK, Google ADK, CrewAI (2026) — IoT Digital Twin PLM](https://iotdigitaltwinplm.com/ai-agent-frameworks-benchmark-langgraph-openai-google-adk-2026/) — 4 工作负载、50 次 p50、强杀容器恢复测试，提供冷启动、token/步开销、检查点大小、副作用语义(exactly/at-least/at-most-once)与调试器 UX 评分。
3. [2026 AI Agent Framework Showdown: LangGraph vs CrewAI vs AG2 vs Claude SDK vs Strands vs OpenAI — QubitTool](https://qubittool.com/blog/ai-agent-framework-comparison-2026) — 六框架架构与编程模型横评，提供多步准确率(94%/87%等)、单任务成本($0.08-$0.45)、47M+ 月下载量与版本信息(v1.14/v0.12/v1.34)。
> [!tip] 51学通信知识星球
> **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。
> **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。
> **当前规模**：5200 篇主题 / 990 个回答，198 元/年。
> **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。
> **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。
