引言：一个让所有 Agent 使用者头疼的问题
假设你现在需要让 AI Agent 完成一个复杂的工程任务——比如重构一个大型项目：需要同时分析架构、修改多个模块、编写测试、更新文档。这看起来是一个可以拆解为多个并行子任务的工作。
你面临一个选择：
- 方案 A：让一个 Agent 串行完成所有步骤。
- 方案 B：拆分成多个子 Agent，各自负责一个子任务，并行执行。
两个方案听起来都有道理。但在实际使用中，你会发现：方案 A 容易让 Agent "走神"，方案 B 则容易让整个流程"失控"。 这不是理论推演，而是大量真实使用后得出的切身体会。
这篇文章，就来深入分析这个矛盾，并探讨在当前框架局限下，如何做出更合理的取舍。
单 Agent 模式：上下文越长，质量越差
让一个 Agent 从头到尾完成一个包含多个步骤的复杂任务，是最直觉的做法。但当任务步骤超过一定数量后，问题会逐步显现。
注意力衰减：Lost in the Middle
这是大语言模型的一个已知局限。当上下文长度增加时，模型对中间部分的注意力会显著衰减——开头和结尾的信息被优先处理，而中间的关键指令则容易被"遗忘"。
在 Agent 场景中，这意味着：当你在对话开头给出了详细的任务规划，Agent 在执行到第三、第四步时，可能已经偏离了最初的约束条件。它会"忘记"你在第 10 条消息中设定的某个边界规则，或者重复执行某个已经完成的操作。
上下文窗口被"历史负担"占满
Agent 在每一步执行中都会产生工具调用结果、思考过程、输出内容。这些内容会持续累积在上下文窗口中。当任务进行到中后期，上下文已经被早期的执行痕迹占满，Agent 可用的"推理空间"反而越来越小。
实际表现是：同一个 Agent，在任务的第 15 步时，明显不如第 3 步时"聪明"。 它开始做出低质量的决策，甚至重复犯错。
串行执行的效率问题
这一点相对次要，但确实存在：当任务本身包含多个独立的子任务（比如同时修改 5 个文件），串行执行在时间上是低效的。不过，比起质量问题，效率问题通常不是主要瓶颈。
多 Agent 并行模式：木桶效应与控制力缺失
既然单 Agent 有注意力问题，那拆分成多个子 Agent 并行执行，似乎是一个合理的解决方案。每个子 Agent 只关注一个独立的小任务，上下文干净，注意力集中。
理论上很美好，但实践中会遇到另一个维度的问题。
整体稳定性取决于最弱的一环
当多个子 Agent 并行执行时，整个任务的完成质量取决于所有子 Agent 中最不稳定的那一个。这在本质上是一个串联系统的可靠性问题——整体成功率是各环节成功率的乘积。
如果每个子 Agent 独立完成任务的成功率是 85%，那么 3 个子 Agent 全部成功的概率只有 61%。子任务越多，整体失败的概率就越高。
子 Agent 卡住时的处理困境
这是目前多 Agent 并行模式中最棘手的现实问题。当某个子 Agent 进入死循环、产出异常结果、或长时间无响应时，当前主流框架的处理方式几乎只有一种：
中断主 Agent → 加入提示词引导 → 重新运行整个流程。
这意味着，即使只有一个子 Agent 出了问题，你也需要让所有正在运行的子 Agent 一起停下来。之前其他子 Agent 已经正确完成的工作，可能也要重新执行。
控制力的严重不对等：主 Agent vs 子 Agent
这是当前多 Agent 框架最核心的短板。主 Agent（你直接对话的那个 Agent）拥有完整的交互能力：你可以随时中断它、修改它的指令、给它提供额外上下文、纠正它的方向。
但子 Agent 呢？在绝大多数框架中，子 Agent 一旦启动，就进入了一个"黑盒"状态：
| 控制能力 | 主 Agent | 子 Agent |
|---|---|---|
| 单独中断 | 支持 | 不支持 |
| 中途注入提示词 | 支持 | 不支持 |
| 实时查看执行状态 | 完整日志 | 有限或不可见 |
| 出错后定向重试 | 支持 | 需重启整个流程 |
| 修改执行策略 | 随时可改 | 启动后不可改 |
这种控制力的不对等，使得多 Agent 并行模式在实际使用中变得非常"脆"——你无法对过程中的问题做精细干预，只能"全停重来"。
当前主流框架的局限性分析
这个问题不是某个框架的缺陷，而是当前整个 Agent 生态的普遍现状。
子 Agent 的可观测性不足
主流框架（包括 OpenAI Codex、Cursor、Claude Code、Amp、OpenCode 等）在子 Agent 的设计上，普遍采用"状态隔离"的架构——子 Agent 拥有独立的上下文环境，与主 Agent 不共享执行状态。
这种设计的初衷是合理的：防止子 Agent 之间相互干扰，保持各自的上下文纯净。但副作用是，主 Agent（以及使用者）很难实时获知子 Agent 的执行细节。你通常只能在子 Agent 完全执行完毕后，才能看到它的最终输出。
精细控制的工程矛盾
从工程角度看，要让主 Agent 能够实时干预子 Agent，意味着：
- 需要建立子 Agent 与主 Agent 之间的双向通信通道。
- 主 Agent 需要维护所有子 Agent 的执行状态快照。
- 需要支持"暂停-修改-恢复"的执行模型，这在当前基于无状态 API 调用的架构下实现成本很高。
这是一个真实存在的工程权衡：状态隔离带来了简洁的架构，但牺牲了精细控制的能力。 目前几乎所有框架都选择了前者。
一个值得注意的信号
部分框架已经开始尝试解决这个问题。比如，有些框架支持在子 Agent 执行过程中向其注入"额外指令"（尽管通常要等子 Agent 当前步骤完成后才能生效），也有些框架在探索"子 Agent 事件流"的可观测性方案。但这些尝试仍处于早期阶段，距离真正实现"对子 Agent 的控制力等同于主 Agent"还有相当距离。
实践建议：在局限下如何做得更好
既然当前框架存在这些局限，作为使用者，我们可以从以下几个维度进行应对。
判断标准：何时单 Agent，何时拆子 Agent
一个简化的决策框架：
- 用单 Agent：当任务步骤之间有强依赖关系，后一步的输入依赖前一步的输出；或者任务总步骤较少（3-5 步以内），不会导致上下文过载。
- 拆子 Agent：当任务包含多个相互独立的子任务，且每个子任务本身有足够的复杂度，需要干净的上下文环境。
一个关键原则：宁可让单 Agent 多执行几轮（通过中途注入提示词来维持注意力），也不要轻易拆分成多个子 Agent。 除非任务规模已经明显超出单 Agent 的能力边界。
控制子任务的粒度
如果你决定使用子 Agent，任务拆分粒度的控制至关重要。粒度过细会导致子 Agent 数量过多，放大稳定性问题；粒度过粗则失去了拆分的意义。
经验法则：每个子 Agent 的任务应该是一个完整的、可独立验证的工作单元，执行时间控制在单 Agent 注意力不会衰减的范围内。 通常，3-5 个并行子 Agent 是一个相对可控的规模。
"主 Agent 编排 + 子 Agent 执行 + 主 Agent 兜底"模式
这是目前实践中相对稳健的工作流模式：
- 主 Agent 做编排：由主 Agent 分析任务、制定计划、拆分子任务。
- 子 Agent 执行独立任务：每个子 Agent 只负责执行一个明确定义的子任务。
- 主 Agent 做验收和兜底：子 Agent 完成后，由主 Agent 检查输出质量，处理集成问题，修补子 Agent 的遗漏。
这种模式的核心思想是：把"判断"和"决策"留在主 Agent，只把"执行"下放给子 Agent。 这样即使子 Agent 出了问题，主 Agent 仍然可以基于完整的上下文做出正确的补救决策。
对框架改进的期望
从使用者角度，我们期望未来的 Agent 框架在以下方面做出改进：
- 子 Agent 的实时可观测性：能够像查看主 Agent 一样，实时查看子 Agent 的思考过程和执行状态。
- 子 Agent 的中途干预能力：支持在子 Agent 执行过程中暂停、注入提示词、修改执行策略，而不需要终止它。
- 子 Agent 的定向重试：当某个子 Agent 失败时，只需要重新执行该子 Agent，而不是重启整个流程。
- 子 Agent 状态的持久化：子 Agent 的执行结果（包括中间状态）应该可以被保存和恢复，避免"全停重来"的浪费。
这些能力一旦实现，多 Agent 并行模式的实用性将会有质的提升。
结语
多 Agent 子任务编排的困境，本质上是一个控制力与并行度的权衡问题。
单 Agent 模式拥有最好的控制力——你可以随时干预、引导、纠正——但代价是注意力分散和上下文过载。多 Agent 模式理论上拥有更高的并行效率和更干净的上下文——但代价是控制力的严重削弱。
在当前的技术条件下，务实的做法是优先使用单 Agent，只在任务明确适合拆分时才使用子 Agent，并通过"主 Agent 兜底"的模式来弥补子 Agent 控制力的不足。
这不是一个完美的解决方案，但它是在当前框架成熟度下，最稳健的实践策略。随着 Agent 框架在子 Agent 控制能力上的逐步完善，这个矛盾终将得到缓解。而在那之前，理解这个矛盾的本质，并在使用中做出合理的取舍，是每一个 Agent 使用者需要掌握的核心技能。