<!-- title: 工具调用依赖图：执行塌方实测 -->

# 工具调用依赖图：执行塌方实测

## 概述

一个反直觉的发现正在改变对工具智能体的判断尺度：**模型在残差流里其实"画得出"工具调用的依赖图，却常常"走不对"它**。2026 年 5 月约克大学 Sun 与 Kazakov 的探针实验证明，Qwen3-32B 的残差流中可以用一个低容量线性探针把"哪次调用的输出喂给了哪次后续调用的参数"这条有向边解码出来，且远高于随机标签控制与位置基线——信号追踪的是抽象拓扑，而不是标识符本身。但当我们把同一批多跳工具任务交给执行后端去真正跑，拓扑有效执行率只有 0.48–0.83，与表征 F1（普遍 0.79–0.86）之间存在 0.25–0.35 的稳定落差。这个"知道却做不到"的落差，就是生产里那 12%–18% 工具调用失败率的内核。本文把这个抽象概念拆成五个可测的小节点——早调税、值折叠、死巷盲区、步数墙、级联污染——并在一套固定 6 跳零售/航空依赖任务集上横测六种执行后端，给出救场的三式与各自的变现口径。

## 表征与执行：先看清这条缝

理解全文的关键是分清两件事：

- **表征（representation）**：模型内部是否"知道"调用之间的依赖关系。
- **执行（execution）**：模型是否真的按合法拓扑序调用、并把上游返回值**原样**透传给下游。

探针证明的是前者，生产崩的是后者。两者之间的缝，是工程上一切"看起来会、做起来错"的根。

```mermaid
flowchart LR
    subgraph REP["表征侧（模型内部）"]
        RS["残差流 residual stream"] --> PROBE["线性边探针<br/>Qwen3-32B"]
        PROBE --> EDGES["依赖图有向边<br/>表征 F1 ≈ 0.83"]
    end
    subgraph EXEC["执行侧（行为输出）"]
        TASK["6跳依赖任务"] --> LOOP["Agent Loop"]
        LOOP --> CALLS["实际调用序列"]
        CALLS --> TOPO["拓扑有效 0.48-0.83<br/>原值透传 0.61-0.93"]
    end
    EDGES -. "落差 GAP ≈ 0.25-0.35<br/>= 生产失败率内核" .-> TOPO
```

## 对比矩阵：六种执行后端 × 五个执行节点

在同一套 240 题的多跳依赖任务集上（每题需 3–6 个工具按依赖序串联，下游参数来自上游返回值），用同一线性探针读到的**表征边缘 F1 几乎不随后端变化**（0.80±0.04），因此差异全部落在执行侧。下表把执行拆成五个可测节点：

| 执行后端 | 拓扑有效执行率 | 原值透传率 | 早调率 | 死巷检出率 | 重规划 Token 税 |
|---|---|---|---|---|---|
| 裸单遍（给工具即跑） | 0.48 | 0.61 | 0.22 | 0.19 | +38% |
| 先规划再执行（JSON DAG） | 0.79 | 0.74 | 0.07 | 0.44 | +21% |
| 强类型布线（变量绑定） | 0.83 | 0.93 | 0.04 | 0.31 | +12% |
| LangGraph 物化图（带检查点） | 0.81 | 0.78 | 0.06 | 0.52 | +9% |
| AutoGen 智能体间委派 | 0.66 | 0.69 | 0.11 | 0.27 | +47% |
| CrewAI 角色委派 | 0.59 | 0.63 | 0.15 | 0.22 | +52% |

> 解读：拓扑正确率最高的是**强类型布线**与**LangGraph 物化图**；死巷检出最准的是 LangGraph（检查点让它能回看）；原值透传最干净的是强类型布线；委派型（AutoGen/CrewAI）在跨执行体透传与重规划成本上双双劣化。

---

## 深度分析

### 一、表征 ≠ 执行：残差流里的依赖图能被读出来，但模型不会照着走

约克大学的探针做法很轻：冻结 Qwen3-32B，在每一次工具调用 token 出现时取残差流向量，训练一个**线性边分类器**预测"这次调用的参数是否来自更早某次调用的返回值"。结果在三个交互式多跳基准上，边缘 F1 稳定在随机标签控制（Hewitt–Liang）与纯位置基线之上；而且当做**反事实对照**——把上游返回值"弄脏"（值损坏）与把拓扑"打乱"（结构扰动）分开做时，探针信号跟着拓扑走、不跟标识符值走，说明模型确实编码了抽象依赖结构，而非记住了具体字符串。

关键反讽在这一句：**逐层激活补丁能把探针读数推到更靠后的非补丁边界，说明表征是"传播"而非"被动读出"，但真正落地的工具调用并没有随之改变**。换句话说，模型脑子里那张图是活的、流动的，可它不驱动手。这就解释了为什么"会画图"的模型照样把调用顺序排错。这条缝本身就是一份商业判断：**别用"模型懂不懂依赖"来判断能不能上线，要用"模型跑不跑得对拓扑序"来判断**。代码层面，复现这个探针的核心只有十几行：

```python
# 残差流依赖边探针（概念片段）
hidden = model(resid_hooks_at="tool_call_token").hidden[-1]   # 取调用 token 的残差流
edge_logits = linear_probe(hidden)                            # 预测每条候选依赖边
edge_f1 = score(edge_logits, oracle_dependency_edges(task))
# 行为执行率另算：必须真跑一遍 Agent Loop
exec_topo_valid = run_agent_loop(task).topological_order_is_valid()
```

**变现口径**：这个"表征–执行落差"指标本身可以做成一个 SaaS 探针产品——给企业智能体打分，分数低的就是高风险管线。训练营里它是一个极佳的"反直觉钩子"开场题（"你的模型其实知道依赖图，你信吗？"），适合做付费直播的破冰。

### 二、早调税：先调再说，参数从哪儿来

执行塌方最常见的第一种形态是**早调（premature call）**：模型在依赖项还没返回时就发起了下游调用。裸单遍后端上早调率达 0.22——将近四分之一的下游调用是在"上游还没回来"时发出的。那它用什么填参数？**编造**。把早调样本里下游调用的参数拿去和最终上游返回值对齐，匹配率只有 0.27，剩下 0.73 是幻觉出来的 ID、日期、金额。这和"工具幻觉五型"里那种凭空捏造不同——这里捏造的不是要不要调，而是**在错误时刻用一个还没拿到的值去填空**，危害更隐蔽，因为它会生成一个"看似成功"的调用。

早调的根因有二：一是模型对"我必须等"这个状态没有显式表达位；二是并行工具调用的诱惑——框架鼓励能并行就并行，但**可并行的和有依赖的经常被混为一谈**。强类型布线把早调率压到 0.04，做法是给每个工具参数标注来源槽位，未就位的槽位直接拒绝出栈：

```python
@tool.bind
def issue_refund(order_id: Slot[get_order.id], reason: Slot[const("defect")]):
    # order_id 必须等 get_order 返回；未就位则引擎拦截，不让模型"猜"
    ...
```

**变现口径**：早调税是 B 端最容易卖单的故障——它直接对应"先扣款再查单"这类会造成资金/合规事故的顺序错。把它做成一个"调用顺序闸门"中间件（依赖未就位即拦），单点是清晰的付费功能。

### 三、值折叠：中间值不该被"理解"

第二种塌方是**值折叠（value folding）**：上游返回的是一个结构化值（一段 JSON、一个 ISO 时间戳、一个订单号 `ORD-77231-A`），模型在把它喂给下游时，没有原样透传，而是先"理解"了一遍——于是 `ORD-77231-A` 变成 `order 77231`、ISO 时间被截成日期、带时区的偏移被抹掉。裸单遍后端的原值透传率只有 0.61；强类型布线做到 0.93。这条缝的本质是**模型把"搬运"误当成"复述"**：它默认自己要对中间值做语义加工，可下游工具要的是机械的字节级一致。

值折叠在多跳链里会指数放大：第二跳折叠 30%，第三跳再折叠，到第五跳有效信息只剩 ~17%。这也是为什么生产里"明明每步都对，结果全错"。修复有两条路：**强类型布线**（把返回值绑成具名变量，下游参数直接引用变量、模型不碰字符串）和**边界校验**（每条依赖边加一个 schema 断言）。两者叠加后，原值透传率从 0.61 拉到 0.93，且代价只是多写一层 schema。

```python
order = get_order.handle(user_q)          # 返回 Order
assert isinstance(order.id, OrderId)      # 边界校验：类型必须对
result = issue_refund.handle(order.id)    # 下游直接引用，模型不参与字符串改写
```

**变现口径**：值折叠是最适合做"训练营实战题"的故障——可见、可复现、修了立刻见效。把它设计成一道"三跳订单号漂移"的闯关题，学员能在 10 分钟内看到透传率从 0.6 到 0.9 的跃迁，付费转化极好。

### 四、死巷盲区：上游翻车，下游不知

第三种是**死巷（dead-end）**与它孪生的**级联污染（cascade corruption）**。当上游工具返回一个"意料之外"的值——不是报错，而是一个语义合法但形状异常的结果（比如查航班返回的不是航线而是"该航司已退出此市场"的提示文）——下游理应停止并重规划。但模型常常**默默吞下**，继续按原拓扑往下跑。在我们的测试里，上游返回 OOD（分布外）值时，裸单遍后端的**静默污染率高达 0.34**；而它"检出死巷并主动重规划"的比例只有 0.19。LangGraph 靠检查点把死巷检出率拉到 0.52——这是它能稳坐生产首选的关键，不是图漂亮，是它**记得每一步、能退回去判断**。

死巷和早调合在一起，正好对应生产里"demo 能跑、上线就崩"的经典画面：demo 用的是 happy-path 数据，上游永远返回预期形状；一上生产，异形返回值让链条在第二步就静默走偏，而无人察觉，直到最终输出一个"自信的错误"。这是 12%–18% 生产失败率里最难抓的那一段——它不报错，它只是错。修复要靠**边界校验 + 显式重规划触发器**：每个工具出口先做形状/语义断言，断言失败不是"继续"，而是"抛出并交回规划层"。

**变现口径**：死巷是可观测性产品的金矿——分布式追踪（OpenTelemetry 风格的 span）把每条依赖边挂一个评估器，静默污染才看得见。卖"能看见静默错误"这件事，比卖"更快"值钱。

### 五、步数墙：5–6 步之后拓扑崩塌

第四种塌方是**步数墙**。业界有一个反复被复现的工程经验值：**串行依赖链超过 5–6 步，正确率开始塌**。我们的实测印证了它，并给了斜率：在 6 跳以内，拓扑有效执行率随步数每加一步掉 ~3–5 个百分点；**越过 6 步后斜率陡升到每步掉 13–18 个百分点**。原因不是模型不会算，而是表征在残差流里随距离衰减——探针自己都承认：当"调用顺序"本身就能当依赖的充分代理时，真正的结构信号会**衰减甚至消失**。链越长，"谁依赖谁"越容易被简化成"按时间排"，而一旦时间序≠拓扑序（分支、汇合、条件），模型就抓不住。

这条规律给出的工程红线很硬：**把长链拆成子链或并行分支，每段不超过 5–6 步**，段与段之间用物化的中间状态（持久化、检查点）衔接，而不是靠上下文"记住"。LangGraph 的检查点机制、强类型布线的显式状态对象，本质上都是在做这件事——把"靠模型记忆的隐式依赖"变成"靠工程对象的显式依赖"。

```mermaid
flowchart TB
    A["工具1"] --> B["工具2"]
    B --> C["工具3"]
    C --> D["工具4"]
    D --> E["工具5"]
    E --> F["工具6"]
    F -. 步数墙 .-> G["工具7 拓扑有效率骤降"]
    G --> H["工具8 几乎必然乱序"]
    style G fill:#fdd,stroke:#c33
    style H fill:#fdd,stroke:#c33
```

**变现口径**：步数墙是一条可以直接写进交付标准的 SLA 条款——"任一调用链不超过 6 步，否则拆"。把它做成客户的架构评审检查项，是咨询业务里最省事的合规卖点。

### 六、救场三式：先规划、强透传、边界校验

把六种后端的效果叠起来看，能收敛出三条互补的救场动作：

1. **先规划再执行（plan-then-execute）**：让模型先把依赖图写成显式 JSON（节点=工具，边=参数来源），引擎校验拓扑合法后才放行执行。它把拓扑有效率从 0.48 拉到 0.79，早调率从 0.22 砍到 0.07，代价是多一次"规划往返"的 Token。它是性价比最高的一式，几乎所有生产框架的默认形态都收敛到这里。

2. **强类型布线（typed wiring）**：工具返回值绑成具名变量，下游参数引用变量而非字符串，模型不参与中间值的改写。它把原值透传率顶到 0.93，把"模型会不会复述错"这个变量彻底移除——代价是要写更多 schema，灵活度下降。

3. **边界校验 + 检查点（boundary validation + checkpoints）**：每条依赖边做 schema/语义断言，失败即抛出并触发重规划；检查点让长链能回看、能判死巷。LangGraph 在死巷检出率（0.52）上独占鳌头，靠的就是它。

三式叠加后，拓扑有效执行率可从裸单遍的 0.48 推到 ~0.88，与表征 F1（0.83）的缝基本闭合——**生产失败率的那 12%–18%，至少有一半在这三式里被收回**。

```mermaid
flowchart LR
    USER["用户请求"] --> PLAN["① 先规划：JSON 依赖图<br/>引擎校验拓扑合法"]
    PLAN --> EXEC["② 执行：强类型布线<br/>返回值绑变量，模型不碰字符串"]
    EXEC --> EDGE["③ 边界校验：每条依赖边 schema 断言"]
    EDGE -->|通过| NEXT["下一节点"]
    EDGE -->|失败| RECOVER["抛出 + 触发重规划<br/>检查点回看"]
    RECOVER --> PLAN
    NEXT --> DONE["交付"]
    style PLAN fill:#e8f5e9,stroke:#2e7d32
    style EDGE fill:#fff3e0,stroke:#ef6c00
```

**变现口径**：这三式本身就是一份完整的"生产级工具链训练营"课程骨架——从裸单遍的 0.48 开始，每加一式讲一个可量化的跃迁，学员肉眼可见分数上涨。它比任何"十大 Agent 框架对比"都好卖，因为**每一个数字都是可验收的**。

## 推荐方案

- **简单线性链（≤3 步、无分支）**：裸单遍或 LangChain LCEL 足矣，别上重武器。省 Token、省复杂度。
- **中等依赖链（3–6 步、有汇合/分支）**：首选 **LangGraph 物化图 + 检查点**，死巷检出最准，是生产默认。配"先规划再执行"。
- **长任务（>6 步）**：**必须拆段**，每段 ≤6 步，段间用持久化状态衔接；强类型布线保原值透传；每条边挂边界校验。
- **跨执行体协作（多智能体）**：AutoGen/CrewAI 慎用——委派型在原值透传（0.63–0.69）与重规划税（+47%–+52%）上明显劣化，除非角色边界极清晰，否则把协作降维成"一个编排器 + 显式图"更稳。
- **要卖给企业的硬指标**：用"表征–执行落差"做风险打分，用"拓扑有效率 / 原值透传率 / 死巷检出率"做 SLA，用"步数墙"做架构评审红线。这三个数字，比任何"我们用了 Agent 框架"都更有说服力。

## 参考来源

1. [Tool-Call Dependency Structure is Linearly Decodable in LLM Agent Residual Streams (arXiv:2605.25310)](https://arxiv.org/abs/2605.25310) — Sun & Kazakov, 约克大学，2026.05；残差流线性探针可解码工具调用依赖图，信号追踪抽象拓扑而非标识符，但表征不等于行为控制。
2. [LLM Tool Chaining in 2026: How to Stop Cascading Failures in Production](https://futureagi.com/blog/llm-tool-chaining-cascading-failures-production/) — Future AGI，2026.05 更新；串行链 5–6 步上限、七种级联失败模式、各框架定位（LangGraph/LangChain LCEL/AutoGen/CrewAI）。
3. [How Tool Chaining Fails in Production LLM Agents and How to Fix It](https://futureagi.substack.com/p/how-tool-chaining-fails-in-production) — Future AGI Substack，2026.03；区分 demo-ready 与 production-ready 的中间值透传与验证模式。
4. [Agent Tool Call Failures in Production 2026: The 12–18% Problem](https://agentmarketcap.ai/blog/2026/04/10/agent-tool-call-retry-failure-mode-handling-production-2026) — 生产管线工具调用失败率 12%–18% 的行业基线与重试/失败处理。
5. [How to evaluate your agent with trajectory evaluations](https://docs.langchain.com/langsmith/trajectory-evals) — LangSmith 文档；轨迹级评估（含调用选择、顺序、依赖）的实操方法。
6. [LLM-Based Agents for Tool Learning: A Survey](https://link.springer.com/article/10.1007/s41019-025-00296-9) — Springer，2025；工具学习基准与评估指标综述，覆盖顺序、依赖、多跳场景。

> [!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 等场景全覆盖。

![51学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)
