并行执行：墙钟时间减少 80%，零额外成本

当协调者在一条响应中发出多个 Task 工具调用时，SDK 并行执行它们。这是多 agent 系统中影响最大、工作量最小的优化——而且免费。同样的 API 调用、同样的 token、同样的成本。只是更快。

机制和算术

一条协调者响应中的多个 Task tool_use block → 并行执行。总延迟 = max(agent 时间)，不是 sum。

• 串行：3 个 agent × 30s = 90s
• 并行：max(30s, 30s, 30s) = 30s

规模化的生产数据：每天 200 个查询，每个 5 个 agent：

• 串行：200 × 125s = 25,000s ≈ 7 小时/天
• 并行：200 × 25s = 5,000s ≈ 1.4 小时/天
• 节省：5.6 小时/天（80% 减少），API 成本完全相同

串行反模式：诊断特征

如果 3 个独立 agent 各耗时约 30s 而总时间约 90s，你就是串行执行。3 倍模式是明确无误的。协调者每轮只发一个 Task 而不是在一条响应中发全部三个。修复：在一条响应中发出所有独立的 Task 调用。

并行只适用于独立任务

一个线性依赖链（OCR → NLP → 校验 → 增强）不能并行化。每个阶段需要上一阶段的输出作为输入。NLP 和 OCR 并行意味着 NLP 在没有 OCR 文本的情况下启动——要么失败要么产出垃圾。

规则：独立的并行，依赖的串行。 跨文档并行（同时处理文档 A 和文档 B），不要跨有依赖的流水线阶段并行。

依赖图调度

混合依赖的复杂任务图需要多阶段调度：

任务: A(独立), B(独立), C(依赖A),
      D(依赖B), E(依赖C+D), F(独立)

阶段 1: A + B + F  (全部独立 → 并行)
阶段 2: C + D      (依赖满足 → 并行)
阶段 3: E          (所有依赖满足 → 运行)

关键洞察：

• F 在阶段 1 启动，不是更晚——它是独立的，没有理由等
• D 不等 A——D 依赖 B 不依赖 A。B 完成就立刻启动
• E 等 C 和 D——只在两个依赖都满足时启动
• 总时间：max(A,B,F) + max(C,D) + E——关键路径最优

协调者通过 agentic 循环自然处理：为独立任务发出并行 Task 调用（阶段 1），接收结果，为新解锁的任务发出并行 Task 调用（阶段 2），以此类推。

混合的独立和依赖

一个客户请求需要：账单检查（独立）、物流状态（独立）、退款计算（依赖两者）。

第 1 轮：在一条响应中发出账单 + 物流 Task 调用 → 并行执行 第 2 轮：收到两个结果 → 发出退款 Task 调用，附带合并结果

总时间：max(账单, 物流) + 退款。优于串行（账单 + 物流 + 退款）。

并行执行中的部分失败

三个 agent 并行运行。两个成功完成，一个超时。怎么办？

正确：收集 2 个成功结果，记录超时及结构化错误上下文，然后决定——单独重试失败的 agent（如果时间允许）或带显式缺口注解继续处理部分结果。

错误：丢弃全部 3 个结果（浪费已完成的工作）、无限等待（阻塞一切）、重试全部 3 个（在已成功的 agent 上浪费算力）。

协调者保留已完成工作的价值，同时处理失败。这和 K1.2.1 的部分失败原则应用在并行执行上是一样的。

不需要外部基础设施

并行执行不需要消息队列、线程池或 async 框架。当协调者在一条响应中发出多个工具调用时，SDK 原生处理它。不需要开发者管理的并发。

一句话总结： 在一条协调者响应中发出所有独立的 Task 调用实现并行执行——零额外成本减少 80% 墙钟时间，但只适用于独立任务。用多阶段调度尊重依赖链，通过保留已完成结果来处理部分失败。