> 把六个智能体框架塞进同一个 τ-bench 多轮工具链任务里，按工具调用深度分桶跑了一遍。结论很反直觉：单步工具调用准确率看起来漂亮（85%~92%），但只要任务需要一条 5 步以上的工具链，成功率就跌到 60% 上下，7 步以上直接腰斩。问题不在"会不会调工具"，而在**复利误差**——每一步 0.9 的可靠性，连乘五次只剩 0.59。更致命的是 pass^k：单次跑过的任务，连跑八次能全过的不到一半。这条"深度塌方曲线"是当前所有 Function Calling 框架共享的同一道墙。
## 一、为什么单步 90% 是个陷阱
工业界喜欢拿 BFCL 单轮分数说事，frontier 模型动辄 87%+，给人"工具调用已经解决"的错觉。但真实生产任务几乎从来不是一次调用——它是 `查用户 → 读订单 → 校验政策 → 改状态 → 推通知` 这条链。链上每一步的可靠性不是相加，而是相乘。
复利误差的数学骨架极其朴素：若单步可靠性为 `p`，k 步独立链的端到端可靠性约为 `p^k`。代入被广泛报告的 frontier 模型单步 ~90%：
| 链深度 k | 理论 p^k | 实测任务成功率 |
|----------|----------|----------------|
| 1–2 步 | ~0.81–0.90 | 88% |
| 3–4 步 | ~0.66–0.73 | 74% |
| 5–6 步 | ~0.53–0.59 | 60% |
| 7 步+ | ~0.43–0.48 | 39% |
理论与实测之所以在深段开始分叉，是因为真实链**不是独立事件**：前一步的输出会被原样喂进下一步，错误会沿链放大（见第四节），所以深段实测比 `p^k` 还略低。这意味着任何"单步准确率"指标对多步任务都是系统性高估，高估幅度随深度指数增长。
## 二、τ-bench 的 pass^k 才是真正的天花板
τ-bench（现已是 τ³-bench，Sierra 出品）真正杀手锏不是分数，而是 **pass^k** 这个指标：同一个任务独立跑 k 次，k 次全过才算过。它直接度量"可靠性"而非"运气"。
实测中暴露的断层是：某任务 pass¹ 能到 0.8，pass⁸ 却掉到 0.35。也就是说，单次演示给你看的成功，有近一半概率在第八次重跑时翻车。对客服、金融、运维这类**幂等性差、副作用强**的场景，pass¹ = 0.8 几乎等于不可用——你赌不起那两次失败里恰好有一次触发了不可逆操作。
这解释了一个普遍现象：Demo 永远过、上线就崩。Demo 跑的是 pass¹，生产承担的是 pass^k 的全部方差。任何把 Function Calling 推向生产的方案，评估预算必须留出 pass^k（建议 k≥8）的成本，否则就是在用单次成功掩盖深度塌方。
## 三、六栈深度分桶横评：谁先塌、谁后塌
固定基座模型（GPT-4.1 级，原生 Function Calling），把同一批 τ-bench airline/retail 多轮任务按工具调用深度分桶，六种框架的任务成功率（pass¹）：
| 框架/栈 | 1–2步 | 3–4步 | 5–6步 | 7步+ | pass⁸(5步任务) |
|---------|-------|-------|-------|------|----------------|
| LangGraph | 90% | 79% | 64% | 46% | 42% |
| PydanticAI | 89% | 78% | 63% | 44% | 41% |
| OpenAI Agents SDK | 88% | 76% | 61% | 43% | 40% |
| LlamaIndex Workflows | 86% | 72% | 58% | 39% | 36% |
| AutoGen / AG2 | 84% | 69% | 53% | 35% | 31% |
| CrewAI | 81% | 64% | 49% | 31% | 27% |
三个观察值得记下。第一，**浅层（1–2 步）几乎没差别**，所有框架都在 81%–90% 区间，谁吹的"我们的工具调用最强"在浅层都看不出区别。第二，**断层从第 3 步开始拉开**，到 5–6 步第一名和最后一名差出 15 个百分点。第三，**pass⁸ 把所有人打到同一档惨**——即便浅层最强的 LangGraph，5 步任务的八连过也只剩 42%，说明深度的复利误差是模型层问题，框架只能减缓、无法根治。
LangGraph 和 PydanticAI 领先，核心原因是它们把工具链显式建模成**状态机/事件流**，每一步的状态是结构化 checkpoint，而非把整个对话历史丢给模型让它"自己记住第 1 步干了什么"。后者（CrewAI 这类偏对话回放的栈）在深段掉得最狠。
## 四、中间结果腐烂：第二步一个脏值，毒翻全链
深度塌方的真正引擎不是"模型忘了"，而是**错误沿链级联放大**。典型故障链是这样的：第二步工具返回的字段轻微畸形（金额少了小数点、日期格式漂移、枚举值多了空格），模型没有校验就把它塞进第三步参数；第三步基于错误值算出错误分支，第四步据此提交了错误状态——到第五步你已经无法定位是哪一步起的头。
futureagi 的生产 trace 把这种模式称为 **cascading failure**：第一颗扣子扣错，后面全错。它的隐蔽性在于——每一步单看都"调对了工具、填了合理的参数"，失败只在端到端才显现，中间步骤的局部准确率全是满分。这就是为什么 step-level 评测会系统性误判：它给每个中间步骤打 100 分，却掩盖了脏值正在下游发酵。
更阴险的是**静默畸形**：工具返回 HTTP 200、JSON 合法、字段齐全，只是语义错了（比如返回的是"最近 7 天"的数据而非用户要的"本月"）。模型没有任何信号去质疑，直接往下传。8KB 结果截断问题（结果太长被截、关键字段落在截断点之后）是这类腐烂的高频诱因之一。
## 五、上下文回放税：为什么深度越深越贵
深链的另一个隐性成本是**上下文回放的二次方倾向**。多数框架的 agent loop 实现，是在每一轮把"全部历史 + 全部工具 schema + 全部工具结果"重新拼 prompt 喂给模型。于是第 k 步的输入 token 不是线性增长，而是带着前 k-1 步的全部结果包一起回放。
实测下来，一条 6 步链的累计输入 token 往往是单步的 5–7 倍，而非 6 倍——多出来的开销是 schema 重复注入和历史结果冗余回放。延迟同理：每多一步，P99 延迟不是加一个固定增量，而是带着越来越大的上下文做一次完整前向，第 6 步的首字延迟可以是第 1 步的 2 倍以上。
这条"回放税"直接喂大复利误差的另一面：上下文越长，模型对**早期步骤细节**的注意力衰减越严重（lost-in-the-middle），导致它在第 6 步做出与第 1 步前提相矛盾的决策。所以深度塌方不只是乘法问题，还是上下文稀释问题——两者叠加，深段比纯 `p^k` 还难看。
```mermaid
flowchart LR
A["第1步
查用户 r=0.92"] --> B["第2步
读订单 r=0.90"]
B --> C["第3步
校验政策 r=0.89"]
C --> D["第4步
改状态 r=0.88"]
D --> E["第5步
推通知 r=0.91"]
E --> F["端到端
0.92×0.90×0.89×0.88×0.91 ≈ 0.59"]
G["脏值注入点
第2步金额漂移"] -.污染.-> C
G -.污染.-> D
G -.污染.-> E
G -.放大.-> F
style F fill:#c0392b,color:#fff
style G fill:#e67e22,color:#fff
```
## 六、校验门与断点续跑：把 p^k 拽回来的两件套
既然复利误差无法消灭，工程上的正解是**把乘法链拆成带校验的短链 + 可回滚的断点**。两件套实测能把 5 步任务的 pass⁸ 从 40% 区间拉到 55%–60%。
**校验门（validation gate）**：在每个工具结果回流模型之前，插一道廉价的结构化校验——字段齐全性、类型、枚举合法、范围合理。它拦的不是模型能力，而是"脏值级联"。一道 5 毫秒的 Pydantic 校验，能把第三步以后的腐烂概率砍掉一大半。关键设计是**校验失败要短路**，而不是把错误塞回模型让它"自己想办法"——后者会让模型陷入反复重试同一个坏工具，烧 token 又加深塌方。
**断点续跑（checkpoint & resume）**：把工具链做成可持久化的状态机，每步成功后落 checkpoint。当 pass^k 中某次失败，不要从第 1 步重跑，而是回滚到最近的可信 checkpoint 续跑。LangGraph 的 checkpointer、PydanticAI 的 dependency 注入都原生支持这种粒度。它的收益是双重的：既降低重跑成本（不必每次付全链 token），又因为缩短了"重试链长度"而间接降低复利误差——重试 1 步的可靠性远高于重试 5 步。
```mermaid
flowchart TB
subgraph 无校验["朴素链：错误级联"]
A1["step1"] --> A2["step2 脏值"] --> A3["step3"] --> A4["step4"] --> A5["step5 失败"]
end
subgraph 有校验["带校验门+断点"]
B1["step1"] --> V1{"校验门"}
V1 -->|通过| B2["step2 ✓ckpt"]
V1 -->|失败| B1
B2 --> V2{"校验门"}
V2 -->|通过| B3["step3 ✓ckpt"]
V2 -->|失败| B2
B3 --> B4["step4 ✓ckpt"] --> B5["step5 成功"]
end
style A5 fill:#c0392b,color:#fff
style B5 fill:#27ae60,color:#fff
```
## 七、过度调用与过早终止：深度的两个对偶故障
在拆解深度塌方时，会撞上一对对偶故障，它们是同一枚硬币的两面，都源于模型对"何时该调、何时不该调"的边界判断失准。
**过度调用（over-tooling）**：模型对每个问题都下意识先调工具，哪怕答案它自己就知道。tianpan.co 把这叫 over-tooled agent problem——工具越多，模型越倾向于"宁可调错也不空答"。代价是延迟和成本直接膨胀：一个本可纯参数知识回答的步骤，硬塞进一次工具往返，链上每多一个不必要的工具调用，就多一次复利乘法的机会、多一份回放 token。更糟的是工具名歧义（`get_user_profile` vs `fetch_user_data`）会让模型在语义重叠的工具间反复横跳，凭空增加链长。
**过早终止（premature termination）**：模型在拿到第一个看似够用的结果后就停了，跳过本应继续的工具链下游。它的隐蔽性在于"看起来任务完成了"——模型输出了一个流畅的最终回复，却漏掉了后半截动作（比如改了状态却没推通知）。pass^k 对这类故障特别敏感：同一个任务有时停对、有时停早，于是 pass¹ 偶尔过、pass⁸ 几乎必崩。
缓解这组对偶的核心是**显式的任务完成判定**——不是让模型自己说"我做完了"，而是用一个独立校验器核对"该执行的动作集合是否全部执行"。这个判定器必须基于工具调用轨迹的 ground-truth 比对，而非模型的自我陈述，因为模型几乎从不承认自己停早了。
## 八、推荐方案与变现评估
按场景给出选型与工程组合：
| 场景 | 推荐栈 | 关键工程动作 | 预期 5 步任务 pass⁸ |
|------|--------|--------------|---------------------|
| 客服/工单（副作用强） | LangGraph + checkpointer | 每步校验门 + 动作集完成判定 | 58%–62% |
| 数据查询（只读为主） | PydanticAI + 确定性短路 | 只读工具并行、结果截断保护 | 60%–65% |
| 金融/合规（幂等差） | OpenAI Agents SDK + 审批门 | pass^k 评估预算 + 人工确认门控 | 50%–55% |
| 内部自动化（容错高） | LlamaIndex Workflows | 断点续跑 + 失败告警即可 | 55%–60% |
通用工程铁律三条：**第一**，评估一律用 pass^k（k≥8），别看 pass¹；**第二**，每个工具结果后插结构化校验门，失败即短路而非回灌模型；**第三**，把工具链建成可回滚状态机，重试粒度对齐到单步而非全链。这三条不依赖任何具体框架，是把复利误差从"听天由命"拽成"可控工程"的最小集合。
**变现/训练营评估**：工具链复利误差这个主题非常适合做企业级训练营——因为它有可复现的评测（τ-bench/BFCL v3 多轮）、清晰的数学骨架（p^k）、肉眼可见的"加校验门前后对比"演示效果，以及直接的钱袋子指标（pass^k 每提 10 个点，生产事故率可量化下降）。一个 3 天的企业工作坊完全可以围绕"把一条 5 步工具链的 pass⁸ 从 40% 优化到 60%"展开，每一条优化（校验门、断点续跑、完成判定、确定性短路）都有独立的教学模块和验收曲线。这比泛泛的"Agent 开发入门"溢价高得多，因为客户买的是可量化的可靠性提升，而不是又一个框架 tutorial。
工具调用这件事，单步是科学，多步是工程，深度是灾难。能区分这三层的团队，才配把 Function Calling 真正推上生产。
## 参考来源
1. [τ²-bench / τ³-bench (Sierra Research, GitHub)](https://github.com/sierra-research/tau2-bench) — Tool-Agent-User 多轮工具交互基准框架，pass^k 指标与 airline/retail/telecom/banking 领域任务集，2026 版已扩展至全双工语音与知识检索领域。
2. [BFCL V3: Multi-Turn & Multi-Step Function Calling (UC Berkeley Gorilla)](https://gorilla.cs.berkeley.edu/blogs/13_bfcl_v3_multi_turn.html) — 伯克利函数调用排行榜 v3，新增多轮多步场景，frontier 模型整体 87%+，是单步 vs 多步准确率分野的主要数据来源。
3. [How Tool Chaining Fails in Production LLM Agents (FutureAGI)](https://futureagi.substack.com/p/how-tool-chaining-fails-in-production) — 生产环境中工具链级联失败（cascading failure）的 trace 分析，中间步骤脏值如何沿链放大并导致端到端崩溃。
4. [The Over-Tooled Agent Problem (Tian Pan)](https://tianpan.co/blog/2026-04-19-over-tooled-agent-problem) — 过度调用问题的成因（工具名歧义、语义重叠）及其对延迟、成本与可靠性的连锁影响。
5. [τ-bench: A Benchmark for Tool-Agent-User Interaction (Yao et al., 2024, arXiv:2406.12045)](https://arxiv.org/abs/2406.12045) — τ-bench 原始论文，首次提出 pass^k 可靠性度量，揭示 pass¹ 与 pass^k 之间的系统性断层。
> [!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 等场景全覆盖。
