当任务从"调一个工具"升级到"调一串工具"，真正的分水岭不是模型能不能写出函数调用，而是它能不能看懂依赖。本轮追踪 BFCL V3、τ-bench/τ2-bench、AgentEval、GAP 四个基准的最新结论，叠加生产环境的失败率数据，发现一个被严重低估的事实：Agent 工作流天生是 DAG（有向无环图），错误会沿依赖链复合放大。AgentEval 的消融实验显示，仅仅显式建模步骤间的依赖关系，无需换模型、无需改提示词，就能单独贡献 +22% 的准确率。与此同时，生产环境的工具调用失败率长期稳定在 12-18%，链长每加一跳，终端成功率就按指数衰减。本轮拆解六类框架/范式在"多步串行依赖编排"这一高阶维度上的真实表现，并给出依赖建模与熔断的工程模板。
| 栈/范式 | 依赖表达 | 并行调度 | 循环检测 | 链路可观测 | 代表实现 |
|---|---|---|---|---|---|
| 纯循环 ReAct | 隐式（靠上下文） | 无 | 无 | 差 | 早期 LangChain Agent |
| OpenAI Agents SDK v2 | 编排器隐式 | 原生并行 | 无 | 中 | OpenAI Agents SDK |
| LangGraph 显式状态图 | 显式 DAG 边 | 节点级并行 | 可编码 | 强 | LangGraph |
| CrewAI 流程编排 | 顺序/层级声明 | 任务级 | 弱 | 中 | CrewAI |
| AutoGen/AG2 对话式 | 隐式（消息序） | 群聊并发 | 无 | 中 | AutoGen |
| GAP/依赖感知编排器 | 显式依赖图 | 依赖感知自动并行 | 强（静态） | 强 | 学术原型 + ADK |
直觉上，"多步工具调用"被当成一条流水线 A→B→C→D，但真实的业务任务几乎从不是线性的。一个典型的差旅任务：查天气、查航班、查酒店三者互相独立（可并行），但"订机票"依赖"查航班"的结果，"发确认邮件"又依赖"订机票"和"订酒店"两者都成功。这就构成一个有向无环图——既有可并行的扇出分支，也有必须串行的汇聚依赖。
AgentEval 论文（arXiv 2604.23581）的核心论断正是："Agent 工作流本质上是 DAG，错误会沿依赖链复合放大。"这句话的杀伤力在于它点破了评估盲区：传统 NLP 评测用端到端通过率，但 DAG 里中间一个节点错了，下游所有节点都会被污染，端到端数字会严重低估真实缺陷分布。所以评测多步工具能力，第一性原理是按依赖图逐节点打分，而不是只看最后一步对不对。这也是为什么 BFCL V3、τ-bench 都在 2026 年从单轮评测全面转向多轮多步——单轮 80%+ 的光环，掩盖了链路深处的系统性塌方。
Berkeley 的 BFCL V3（gorilla.cs.berkeley.edu）最大的进步是引入了 Multi-Turn & Multi-Step Function Calling，把评测从"给定上下文选对工具"推进到"工具结果回灌后还要继续正确推理"。在 V3 之前，BFCL 把函数调用分为 simple、multiple、parallel、parallel-multiple 四档，顶级模型在前三档普遍 85% 以上；V3 加入多轮后，排行榜立刻出现明显分层——能扛住"调用→拿到结构化返回→基于返回做下一次调用"这条链的模型，比只能做单轮的少了一大截。
断崖的根源是状态延续：每一跳的输出要作为下一跳的输入参数，模型必须在上下文里准确提取上一步返回的字段（订单号、SKU、时间戳），并把它填进下一个工具的入参。任何一个字段名漂移、类型错配（把字符串 ID 当成数字）、嵌套层级取错（取了 data 而非 data.items[0].id），整条链就断了。这与本系列早前测过的"传参即失真"在多步场景下被指数级放大——单步 5% 的参数失真，五步链路的终端保真度只剩 0.95⁵≈77%。BFCL V3 的价值，就是把这条衰减曲线摆到了台面上。
τ-bench（Sierra Research，taubench.com）设计了一个 Tool-Agent-User 三角：用户用自然语言提需求，Agent 要在零售/航空客服场景里查政策、调工具、必要时反问用户，最终满足任务。它的 τ2 版本引入了"用户模拟器"，让评测变成动态对抗——用户会追问、会补充信息、会纠正，Agent 必须在多轮里持续编排工具。
这个三角的失真点在两条边上：意图→工具这条边，用户的口语化需求（"我上周买的那件能退吗"）要被翻译成精确的工具调用序列（查订单→查退货政策→判金额→发起退货），中间任何一步理解偏差都会导致调错工具；工具→用户这条边，工具返回的原始 JSON 要被转译成人类可读的回复，且不能丢失关键约束（如"退款将在 3-5 工作日到账"）。τ-bench 的严苛之处在于它强制执行领域政策——Agent 不能瞎编退货规则，必须先用工具查到政策再行动。这直接淘汰了大量"会调函数但不读返回值就继续编"的伪工具能力。τ2-bench 进一步把零售和航空两个领域的政策复杂度都拉满，成为 2026 年衡量真实编排能力的事实标准之一。
AgentEval 最值得工程团队抄走的结论是那个消融实验：DAG 依赖建模单独贡献 +22% 准确率。这意味着不换模型、不调提示词、不改工具定义，仅仅是把"步骤之间的依赖关系"显式记录下来用于评测和调度，就能拿到两成以上的提升。这个数字之所以惊人，是因为它指向一个反直觉的事实——很多 Agent 失败不是模型不够聪明，而是框架没把依赖关系暴露给模型，导致模型要么重复调用已完成的步骤，要么在依赖未满足时就强行调用下游工具。
工程上的迁移很直接。一个最小的依赖感知调度器只需要三样东西：每个工具声明它的 depends_on（前置工具 ID 列表）、produces（输出的产物键名）、consumes（输入的产物键名）。调度器据此做拓扑排序，前置全部完成的工具才进就绪队列，产物按键名注入下游入参。下面是一个极简的依赖图编排伪代码：
# 依赖感知的多步工具编排器（核心逻辑）
def run_dag(tools: list[Tool], ctx: dict) -> dict:
ready = [t for t in tools if not t.depends_on]
while ready:
batch, ready = pick_parallel_ready(ready) # 无相互依赖的可并行
results = parallel_call(batch, ctx) # 并行执行就绪工具
ctx.update(flatten(results, key=t.produces for t in batch))
ready = [t for t in tools
if t not in done and all(d in ctx for d in t.consumes)]
return ctx
这段代码同时解决了三个老问题：天然识别真并行（无依赖的一起跑）、防止跳步（依赖未满足不调度）、产物按键名注入（消除字段漂移）。这就是那 +22% 的工程化身。
GAP（Graph-based Agent Planning，arXiv 2510.25320）把上面的思路推到了极限：它在规划阶段就构建工具依赖图，依赖感知的编排同时提升执行效率和正确率。GAP 的关键洞察是——很多看似"并行"的工具调用，其实是串行幻觉。模型一口气吐出三个工具调用，框架如果无脑并发执行，其中两个其实依赖第一个的输出，结果就是并行跑出两份垃圾数据，再靠模型自己圆谎。
这和本系列早前测过的"伪并行税"是同一类问题的不同切面：伪并行税聚焦的是"批调用本身的开销与误用"，而依赖感知视角补充的是——并行只有在依赖图确认无环无前驱时才成立。GAP 的做法是在执行前对工具调用集合做静态依赖分析：如果调用 B 的参数引用了调用 A 的返回，就强制 B 排到 A 之后；只有真正无依赖的调用才允许同批并发。agentmarketcap 的数据显示，正确的并行工具调用能让多步 Agent 延迟下降 40-70%——但前提是依赖判断不能错，错一处并行就变成错一处串行幻觉，延迟没省下来反而引入数据错乱。
tianpan.co 的一篇 2026 分析点出了一个隐蔽的故障模式——循环工具依赖死锁。场景是 Agent 在长链路里形成了一个隐藏的环：A 调用 B 拿数据，B 又需要 C，C 反过来需要 A 的某个产物。表面上每个工具调用都"合理"，但 orchestrator 的调度队列里，第四个调用一直处于"等待前置产物"状态，永远拿不到锁，整个 Agent 静默卡死，既不报错也不超时。
死锁之所以凶险，是因为它不抛异常。普通工具调用失败会返回错误码，框架至少能走重试或降级（本系列"报错即乱投医"测过的恢复四态）；但死锁是工具根本没被执行，队列里永远 pending，Agent 看起来像在"思考"实则已僵死。工程上的对策是在调度器里加一个硬约束：对工具依赖图做拓扑排序时，若发现环就立即拒绝执行并上报，绝不允许运行时才发现。一个最小的环检测可以在构建 DAG 时用 DFS 三色标记法完成，复杂度 O(V+E)，成本极低但能挡掉整类静默故障。LangGraph 这类显式图编排框架天然支持这种静态校验，而纯循环 ReAct 和对话式编排（AutoGen 群聊）则完全没有这层保护。
agentmarketcap 在 2026 年的生产数据分析里给出了一个让所有 Agent 团队心惊的数字：生产环境 Agent pipeline 的工具调用失败率长期稳定在 12-18%。这个数字单看每跳似乎可接受，但放进依赖链里就面目可憎。假设单跳成功率是 85%（即失败率 15%），一条五跳的串行链路，终端成功率只有 0.85⁵≈44%——超过一半的任务在链尾失败。如果是必须全部成功的强依赖链，这个衰减是致命的。
这就是依赖税的数学本质：串行依赖把单点失败率指数化。它和生产环境的两个现实叠加后更糟：一是工具本身有真实失败率（外部 API 限流、超时、数据缺失），二是很多框架的重试策略是"原地重试三次"，对瞬态错误有效，对结构性错误（参数错配、权限不足）只会白白烧 token。正确的对策是分层熔断：瞬态错误（5xx、超时）指数退避重试；结构性错误（4xx、参数校验失败）立即失败并上报，不重试；链路级则设置"终端成功率阈值"，当一条链的预估成功率低于阈值（如 60%）时，干脆拒绝执行或转为人工兜底，而不是任由它在链尾爆炸。这与本系列"一崩全崩：级联失效五栈熔断"在工具链场景的具体落地。
把六栈拉通看，2026 年的多步工具编排已经分裂成两派哲学。图编排器派以 LangGraph 为代表，要求开发者显式声明节点和边，依赖关系是一等公民，天然支持拓扑排序、并行调度、环检测和步骤级可观测，代价是上手成本高、灵活性受限。代码编排器派以 OpenAI Agents SDK v2、CrewAI 为代表，用普通 Python 代码写编排逻辑，模型自己决定调什么工具，框架在背后做并行优化，灵活但依赖关系隐式、可观测性弱、容易踩死锁。
两派的选择不是技术优劣，而是任务结构化程度的函数。当任务是固定的业务流程（理赔审批、订单履约、合规检查），依赖关系清晰且稳定，图编排器的显式 DAG 能把那 +22% 的依赖建模红利吃满，且上线后故障可定位；当任务是开放探索（研究调研、代码生成），依赖关系动态生成，代码编排器的灵活性更值钱，但必须额外补上环检测和步骤级 trace。Google 的 ADK（adk.dev）试图折中——"从 prompt 和工具调用起步，再长成多智能体图编排"，本质是让开发者按需从代码派平滑迁移到图派。对大多数团队的建议是：先用代码编排器快速验证业务闭环，一旦链路超过 4-5 跳或开始频繁出现静默卡死，就果断迁移到图编排器，把依赖关系显式化，这是用工程确定性换模型不确定性的唯一正道。
flowchart TD
U[用户意图] --> P[意图解析/规划]
P --> DAG{构建工具依赖图}
DAG -->|无依赖·可并行| T1[查天气]
DAG -->|无依赖·可并行| T2[查航班]
DAG -->|无依赖·可并行| T3[查酒店]
T2 --> T4[订机票]
T3 --> T5[订酒店]
T1 -.天气恶劣则熔断.-> FB[降级/人工兜底]
T4 --> AGG[产物按键名汇聚 ctx]
T5 --> AGG
AGG --> T6[发确认邮件]
DAG -.环检测.-> CHK{拓扑排序有环?}
CHK -->|是| DEAD[拒绝执行·上报死锁]
CHK -->|否| EXEC[依赖感知调度]
T6 --> R[结果转译回用户]
classDef fail fill:#fde2e2,stroke:#c0392b,color:#c0392b;
classDef safe fill:#e8f5e9,stroke:#2e7d32;
class FB,DEAD fail;
class EXEC,AGG safe;
图中最关键的两条暗线：环检测（拒绝死锁）和天气熔断（链路级降级），正是上文 +22% 依赖建模红利与 12-18% 失败率复合放大的工程兜底点。没有这两条暗线的编排器，就是任由依赖税按指数收割你的终端成功率。
depends_on / produces / consumes，上线前做静态环检测。把 AgentEval 的 DAG 步骤级评估接入 CI，逐节点追踪成功率。[!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 等场景全覆盖。