怎样减少并限制下游压力：Tool Cache、Parallelism 与 Pool Capacity

前置：如何降低模型与 Context 成本：Model Delegation 与 Cache
核心问题：并发从 10 加到 100 后为什么吞吐可能不升反降，Tool Cache、Parallelism 和 Connection Pool 应怎样一起看？

汇率查询可短 TTL；create ticket 不应做响应缓存来模拟创建。把并发从 10 提到 100 后 DB pool 仍 20，平均等待大增，因此吞吐未提升。

Mental Model

性能链路要拆分 queue、model、tool、network、serialization、generation；成本则按 token/model/tool/run budget 聚合，再反馈 routing/cache/capacity。

Tool Cache

Tool Result cache 只适合语义可复用、可接受短暂陈旧且没有写副作用的调用，并显式声明 cache key、TTL 与 staleness policy。写工具不能因为命中 cache 就“假装已经执行”；这会把性能优化变成 correctness bug。

Parallelism vs Downstream Capacity

并行提升 latency 的前提是下游有容量；超过连接池、rate limit 或 CPU 饱和点后会增加 queue/429/retry，反而更慢更贵。

Connection Pool Capacity

Pool 是昂贵连接的并发边界，应和 worker 数、平均 service time、下游最大连接数、timeout 一起规划。async task 数量可以远大于 pool size，但进入 DB/HTTP 临界区的并发必须受限；否则只是把等待从应用队列挪进 connection pool，吞吐并不会凭空增加。

用 Little's Law 看“并发越多为什么反而越慢”

假设数据库一次查询平均占用连接 200ms，pool size=20。理想情况下这个 DB 临界区的吞吐上限大约是：

text

20 connections / 0.2s ≈ 100 queries/s

如果应用突然启动 500 个 async task，并不会把数据库变成 500 并发；多出来的任务只是在 pool 前排队。如果 timeout 仍按“任务创建时”开始计算，大量请求甚至会在拿到连接前就超时，然后 retry 进一步放大压力。

因此性能调优应按瓶颈逐层设 admission：

text

Run concurrency
  ↓
Tool concurrency
  ↓
HTTP/DB pool
  ↓
actual downstream capacity

Cache 只对“可复用读取”削减进入这条链的请求量；Parallelism 只在下游有剩余容量时降低 wall-clock latency；Pool 则是保护昂贵连接的硬边界。这三个机制目标不同，不能把“提高 parallelism”当成通用性能开关。

自测

把 Tool 并发从 10 提到 100 后 DB pool 只有 20。系统真正瓶颈在哪里，继续加 parallelism 会发生什么？
什么 Tool 结果适合 cache，什么带动态状态或副作用的结果即使昂贵也不应直接复用？

怎样减少并限制下游压力：Tool Cache、Parallelism 与 Pool Capacity ​

Mental Model ​

Tool Cache ​

Parallelism vs Downstream Capacity ​

Connection Pool Capacity ​

用 Little's Law 看“并发越多为什么反而越慢” ​

自测 ​

Sources ​