多子 Agent 何时越少越好：并行收益递减实战手册 · 干货攻略

  • 链接: https://x.com/omarsar0/status/2095256315476000817
  • 分类: x-tips
  • 来源: X @omarsar0
  • 作者: Jay
  • 更新: 2026-09-17

这是什么

多子 Agent 并行存在收益递减边界——当并发子 Agent 数量超过某个阈值后，增加更多 Agent 不仅无法继续提升效果，反而会因协调开销、Token 浪费和上下文重叠导致整体效率下降。

核心反直觉结论：

  • 时间可能节省，成本几乎必然增加：并行子 Agent 节省的是wall-clock时间，但总 Token 消耗通常是单 Agent 的 5–15 倍。
  • 2–4 个是实践甜点：Anthropic 内部评估明确指出 2–4 个并发子 Agent 是大多数任务的最优区间，LangChain Deep Agents 文档亦有相同建议。
  • 超过阈值后"互相查作业"：每个子 Agent 的输出都要由父 Agent 读取、推理、整合；子 Agent 越多，父 Agent 的整合 Token 开销越大，且容易产生重复工作或冲突结论。

来源分享者 @omarsar0（Omar Sánchez）是 AI 工程领域活跃的独立研究员，以梳理长文摘要和架构分析著称。

为什么值得关注

多 Agent 系统是 2025–2026 年最热门的 Agent 架构方向，很多团队的第一反应是"越多 Agent 越强"。然而这个直觉是错的，原因有三：

1. 子 Agent 有固定启动开销 每个子 Agent 启动时需要加载系统提示词、工具定义和上下文——实测中位数为 24,858 个 Token（Ranjan Kumar, 2026 年 2 月），即便任务本身消耗的 Token 少于这个数字，spawn 出来的子 Agent 也是净亏损。Anthropic 的研究显示，多 Agent 系统总 Token 消耗是普通单轮对话的约 15 倍。

2. 父 Agent 的整合成本随子 Agent 数量线性增长 每个子 Agent 返回后，父 Agent 必须：读取结果 → 推理其正确性/完整性 → 判断是否需要继续分配 → 整合进最终答案。这个过程在子 Agent 超过 4 个后基本不再减少总工作量，却持续消耗父 Agent 的上下文窗口。

3. 协调失败会抵消并行收益 arXiv 2605.09104 的 OrchBench 模拟研究（2026年5月）发现：随着协调失败累积，并行执行产生收益递减——当 Agent 之间需要共享状态或交叉验证时，冲突和重复工作快速侵蚀并行带来的时间收益。

核验过程

本攻略引用了以下来源的交叉验证：

来源 关键数据
Anthropic 官方研究系统 blog 并行工具调用将研究时间缩短 90%；多 Agent 系统消耗约 15× 普通对话 Token 量；2–4 个并发 Agent 为实践甜点
Ranjan Kumar (2026) "Subagents: How to Run Parallelism Inside a Single Agent Session" 三个并行子 Agent 比单个顺序执行消耗更多 Token；Anthropic 指引建议 2–4 个子 Agent 为最优；超过此区间协调开销超过收益；中位启动开销 24,858 Token
Inngest Blog "Three sub-agent patterns you need for your agentic system" 子 Agent 为父 Agent 上下文减少 90%+ Token；但"时间节省了，成本没有"——并行≠省钱
arXiv 2605.09104 OrchBench (2026) "Additional agents are most useful when the working state exceeds one context window; once it fits, coordination can become pure overhead."
AlphaSignal/The 45% Trap analysis 单 Agent 准确率低于 45% 时多 Agent 有正收益；高于该阈值后增加 Agent 产生负收益（收益递减+协调税）
LangChain Deep Agents 官方文档 确认 mode: "fork" 子 Agent 已内置（>=0.7.13），用于需要继承父对话历史的场景；同步子 Agent 默认 mode: "isolated"

原帖声称与官方来源的对应关系：

  • "超过 2 个并发子 Agent 必然互相查作业导致 Token 浪费" → ✅ 有多个来源支撑（Inngest、OrchBench、Ranjan Kumar 均支持收益递减结论）
  • "forked subagent 是 LangChain deepagents 已内置的 context engineering 技巧" → ✅ 官方文档确认（mode: "fork"，>=0.7.13）

上手步骤：判断何时用、怎么用并行子 Agent

Step 1：判断任务类型

任务类型          → 推荐子 Agent 数量
─────────────────────────────────────────
独立研究/搜索      → 2–3 个并行（每个独立工作，无状态共享）
代码审查          → 2 个并行（不同视角，如安全+性能）
需要继承上下文     → 用 forked subagent（mode: "fork"）
需要交叉验证       → 谨慎，1–2 个足够；超过 2 个协调成本快速上升
单一连贯创作       → 不用子 Agent，一个 Agent 即可

Step 2：LangChain Deep Agents 启用 forked subagent

当子 Agent 需要看到父 Agent 的完整对话历史时（不只是任务描述）：

from deepagents import create_deep_agent, SubAgent

# 默认 isolated：不继承父对话历史
# mode="fork"：继承完整 conversation + system prompt
forked_researcher = SubAgent(
    name="researcher",
    model="claude-sonnet-4-20250514",
    tools=[web_search, browser],
    mode="fork",  # 关键：继承父上下文
)

agent = create_deep_agent(
    model="claude-sonnet-4-20250514",
    subagents=[forked_researcher],
)

Step 3：设置硬性上限防止过犹不及

from langchain.agents import AgentExecutor

executor = AgentExecutor(
    agent=agent,
    tools=tools,
    max_iterations=3,      # 单 Agent 步数上限
    max_subagent_calls=3,  # 子 Agent 调用上限（防过度分解）
)

Step 4：计算是否值得 spawn

经验法则：任务预计消耗 < 15,000 Token 时，不值得 spawn 子 Agent（启动开销会超过收益）。如果任务较大、需要多个工具调用或多领域知识，子 Agent 才可能有正收益。

坑与适用边界

❌ 常见误区：

  1. 把子 Agent 当万能解：任务简单、Token 消耗小时 spawn 子 Agent 是净亏损。
  2. 认为并行就省钱：并行节省的是时间（wall-clock），但总 Token 成本几乎必然更高。
  3. 超过 4 个子 Agent：协调失败概率显著上升，且父 Agent 整合成本超过并行节省的时间。
  4. forked 和 isolated 混用时忽略上下文膨胀：forked 模式会把父 Agent 的完整历史带给子 Agent，如果父历史很长，每个 forked 子 Agent 都会复制这些 Token。

✅ 适用场景： - 任务可以真正并行（无状态依赖） - 每个子 Agent 工作量 > 20,000 Token - 需要多领域独立探索（法律+财务+技术尽调） - 需要用多个模型/工具交叉验证同一问题

⚠️ 不适用场景： - 任务本身很简单（< 5 分钟工具调用） - 需要 Agent 间实时协调 - 最终输出需要高度连贯（多 Agent 整合质量不稳定）

一句话结论

多子 Agent 并行不是越多越好——2–4 个是甜点，核心价值是上下文压缩和时间并行，而非节省 Token；超过阈值后协调税会吃掉所有收益，LangChain Deep Agents 的 forked subagent（mode="fork"）是当前最成熟的上下文继承方案。