案例分析二：Data Analysis Agent 同时查询多个指标，为什么比串行下钻更适合“横向比较”？

场景背景

用户问，“昨天收入下降，到底是请求、曝光、点击还是 eCPM 出问题？”

如果 Agent 串行：

query request
 ↓
query impression
 ↓
query click
 ↓
query ecpm

每个 SQL 查询 1.5 秒。

总时间约：

6 秒

为什么可以并行？

这四个查询：

时间范围一致
维度一致
互不依赖

所以 Agent 可以一次输出：

query_metric(request)
query_metric(impression)
query_metric(click)
query_metric(ecpm)

Harness 并行执行。

结果

假设：

request：+1%
impression：-3%
click：-2%
ecpm：-32%

下一轮模型立即判断，eCPM 异常最明显。

再继续下钻：

按媒体查 eCPM

为什么不是所有查询都一开始全部并行？

因为后续：

按哪个媒体继续查？

依赖第一批结果。

所以合理结构是：

Batch 1：
request / impression / click / ecpm
并行

 ↓

Reason：
发现 ecpm 异常

 ↓

Batch 2：
按媒体查询 ecpm

这就是，分阶段并行。

数据分析场景更能说明为什么“并发”不等于“一次把所有可能查询全发出去”。第一阶段可以并发比较 request、impression、click、eCPM；只有确认 eCPM 最异常以后，第二阶段才值得继续按媒体下钻。

这种结构把并发和推理结合起来：同一阶段内独立任务并发，不同阶段之间继续保留 Observation 驱动的动态决策。 既节省等待时间，也避免大量无意义查询。

而不是，“所有可能 SQL 一次发完。”

后者会造成大量无意义查询。

复盘

并行 Tool Calling 的价值不是，一次做更多。

而是，在当前已经确定的独立动作集合中，减少等待时间。

这和 Agent 的动态决策并不冲突。

Agent 仍然每一阶段根据 Observation 决定下一批动作。

常见误区

误解： 并行 Tool Calling 就是一次让模型多返回几个 Tool，然后全部同时执行。
正解： 模型可以一次返回多个 Tool Call，但 Harness 仍然要判断这些动作是否真正独立。存在数据依赖、副作用冲突或共享资源竞争时，应该保持串行或分批执行。并发策略是执行层责任，不应该完全交给模型决定。真正的并行能力包含依赖判断、并发上限、错误隔离和结果聚合。

误解： 所有只读 Tool 都一定可以无限并发。
正解： 只读只说明不会直接修改数据，并不代表没有资源限制。100 个只读数据库查询可能打满连接池，1000 个 HTTP 请求可能触发限流，几十个大文件读取也可能占满 I/O。Harness 仍然需要 max_workers、Semaphore、Rate Limit 等并发上限。安全并发不仅看副作用，还要看系统资源。

误解： ThreadPoolExecutor 和 asyncio 谁更高级，就应该统一用谁。
正解： 两者适用场景不同。已有普通同步 I/O Tool，ThreadPoolExecutor 改造成本低；Tool 本身基于 async HTTP、异步数据库时，asyncio 更自然。不要为了异步而异步，也不要把同步阻塞函数直接塞进事件循环。正确选择取决于 Tool 的实现模型，而不是 API 看起来新不新。

误解： 并发任务有一个失败，就应该取消整批结果。
正解： Agent 场景通常更适合错误隔离。四个文件读取中一个不存在，其他三个结果仍然有价值。更稳的 Batch Result 应该逐条记录 success / error，并把整体 Observation 交回模型。只有任务语义要求“必须全部成功”时，才需要把部分失败升级成批次失败。否则会浪费已经获得的信息。

即使采用“必须全部成功”，也不能假装已经完成的副作用会自动回滚。多个只读查询可以简单判定批次失败；多个写操作如果要求原子性，需要数据库事务、补偿动作或专门的工作流协议，线程池本身不提供事务能力。

误解： 并发以后可以不需要 call_id，因为 Tool Name 已经能区分结果。
正解： 同一个 Tool 可能在一批中被调用多次，例如同时 read_file("A.py") 和 read_file("B.py")。完成顺序又可能不同，仅靠 Tool Name 无法准确关联请求与结果。唯一 call_id 能保证 Tool Call 和 Tool Result 一一对应，对 Provider 回传、Tracing、错误恢复都很重要。

误解： 并行 Tool Calling 改变了 Agent 的 Main Loop，本质上已经不是 Reason → Action → Observation。
正解： 本质没有变化，只是单数变成复数。串行是 Reason → Action → Observation → Reason，并行更像 Reason → Actions → Observations → Reason。Agent 仍然需要等待当前阶段的反馈，再决定下一阶段。并发只是优化执行效率，不会替代 Main Loop、State 和动态决策。