子 Agent 并发的效率上限：什么时候加人反而更慢
用过 Claude 多 Agent 框架之后，第一个直觉往往是：并发数越多越快。
起 5 个 agent 写 5 个脚本，明显比串行快。那起 20 个呢？50 个？
现实不是这样的。并发 agent 和线程池一样，存在一个效率拐点，超过之后加 agent 不仅不再加速，反而可能让整个任务变慢。
一、并发加速比：从线性到平台期
理论上，N 个 agent 并行跑 N 个独立任务，应该是 N 倍加速。但实际测下来大致是这张表：
| 并发数 | 加速比 | 主要瓶颈 |
|---|---|---|
| 1–3 | 近线性（~3x） | 无明显瓶颈 |
| 3–8 | 良好（~5–7x） | API 队列开始轻微排队 |
| 8–15 | 递减（~8–10x） | Rate limit + orchestrator context 膨胀 |
| 15+ | 平台期 | API RPM 硬上限，主 agent context 吃撑 |
换句话说，3–8 个 agent 是性价比最高的区间，再往上收益递减，到 15 个以上几乎就是在原地踏步。
二、四个真正的限制因素
1. API 速率限制（Rate Limit）
Anthropic 按 org 维度限制 RPM（requests per minute）和 TPM（tokens per minute）。
并发越多，同时打出去的请求越多，越快触碰上限。触顶之后请求开始排队，等待时间抵消了并发带来的收益。
这是最硬的物理上限，除非升配额，否则无法绕过。
团队使用同样受影响。 org 配额是全团队共享的，不是按人头分配。你跑一个 10 agent 的任务，同事同时跑一个 5 agent 的任务，加起来 15 个并发请求，共同消耗同一个配额——效果和你自己起 15 个 agent 完全一样。团队规模越大、使用时间重叠越多，互相"抢配额"的感受就越明显。
应对方法有两个：一是向 Anthropic 申请提升 org 配额（按实际用量申请，通过率较高）；二是给密集任务加重试退避（exponential backoff），避免触顶后持续堆积请求。
2. Orchestrator Context 膨胀
每个子 agent 完成任务后，会把结果 summary 写回主 agent 的 context。
大约 10 个以上的 summary 进来之后，主 agent 的 context 就开始"吃撑"：
- 推理变慢
- 对早期信息的注意力下降
- 调度决策质量开始退化
这是一个容易被忽视的隐性瓶颈——任务本身没问题，是主 agent 先撑不住了。
3. 任务粒度太小
并发 agent 有固定的 spawn overhead：初始化、上下文加载、调度本身都需要消耗时间。
如果每个子任务本身只需要 10–20 秒，overhead 反而成了主导。这时候并行不仅没有加速，实际耗时比串行更长。
经验法则：单个子任务预期执行时间 < 30 秒，不值得 spawn。
4. 文件 I/O 冲突（反过来说：无冲突就能充分并行）
这条是好消息：只要各 agent 写不同的文件，就不需要串行，可以完全并行。
冲突出现在多个 agent 写同一个文件、同一个数据库表、同一个状态时。设计任务时把写入目标隔离开，是最简单的并发优化手段。
三、实践经验：按任务类型选并发数
不同类型的任务，最优并发数差异很大：
3–5 个：文件创建类任务的黄金区间
每个 agent 负责一个独立文件（脚本、组件、模块），互不干扰，加速比接近线性，orchestrator 压力低。
8–10 个：研究类任务的上限
多个 agent 并行搜索、抓取、总结不同主题。这类任务读多写少，context 压力相对小，可以推到 10 个左右。
15 个以上：必须分批（Wave）
如果任务量确实很大，正确做法是分批：Wave 1 跑完之后再起 Wave 2，而不是一口气并发 20 个。否则 orchestrator 自己成为瓶颈，所有 agent 都在等主 agent 调度。
四、小结
并发 agent 不是越多越好，它遵循和分布式系统一样的规律：
- 存在硬上限（API rate limit）
- 存在软上限（orchestrator context）
- 任务太小时并发反而有害
- 写入隔离是消除冲突最简单的办法
设计多 agent 任务时，先问：任务能不能隔离？单任务够不够大？orchestrator 要接收多少 summary？
这三个问题想清楚，并发数自然就有了答案。大多数情况下，3–5 个认真设计过的子 agent，比 20 个随手起的更快、更稳。