复杂任务很少是一条直线。它们更像一棵树：一个目标分叉成若干彼此独立的子问题，每个子问题又需要单独的探查、验证和结论。但大多数 AI 对话工具只给了你一根线——一个会话、一个上下文、一次只做一件事。本文谈谈这根线在哪里断裂，以及为什么有界的子 Agent 并行能让真实工作显著加速。
线性聊天的瓶颈
在线性聊天里，所有工作都挤在同一个上下文窗口里。你让模型排查一个 bug，它读了五个文件、跑了三条命令、又顺手看了一眼日志——这些内容全部堆进同一段历史。等它终于要给结论时，早期的关键证据可能已经被挤出视野，或者被无关的中间输出稀释。
更糟的是顺序性。即使三个子任务互不依赖，线性会话也只能一个接一个地做。第二个任务必须等第一个彻底结束，哪怕它们读的是完全不同的目录。时间成本线性叠加，上下文却越用越脏。
什么任务适合拆分
不是所有任务都该并行。判断标准很简单：子任务之间是否真正独立。
适合拆分的特征包括：
- 多个目标互不依赖，谁先完成都不影响别人。
- 每个子目标需要各自的探查路径和独立证据。
- 汇总只发生在最后一步，而不是过程中频繁交换中间状态。
不适合拆分的，是那些严格串行的任务：B 必须拿到 A 的输出才能开始，或者所有步骤共享同一份不断演化的状态。强行并行这类任务只会制造冲突和重复劳动。
代码库排障示例
设想一个回归 bug：某个接口偶发返回 500，可能出在请求校验、数据层、或缓存失效任意一处。线性做法是顺着一条假设往下挖，错了再回头。
并行做法是同时派出三个子 Agent，各自带一个明确假设：一个去读校验中间件并复现边界输入，一个去查数据层的连接与事务边界，一个去验证缓存的过期与并发写。三条线各自读自己的文件、跑自己的命令、得出自己的结论，互不污染上下文。主 Agent 只需收集三份结论，交叉比对，定位真正的根因。原本要串行试错半天的排查，被压缩成一轮并发探查。
研究任务示例
研究类任务天然适合扇出。比如要评估三个候选库的取舍，每个库都需要读源码、看 API 设计、查实际用法。把每个库交给一个独立子 Agent，它只专注一个目标、返回压缩后的结论，而不是把整份源码倒进主上下文。主 Agent 拿到的是三份对齐的摘要，可以直接横向对比，而不必亲自翻完所有材料。
有界并行的必要性
并行不是越宽越好。无界地派发会拖垮机器、撞上速率限制、并让彼此触碰同一批文件时互相覆盖。关键词是有界：用一个固定容量的池来调度子任务，输入顺序保留，超出的排队等待。
把并行度想成一条受控的流水线，而不是一次无节制的爆发。它要宽到能吃满独立工作，又要窄到不会自相踩踏。
有界还意味着失败可隔离。一个子任务报错，只影响它自己那条支线；独立的分支照常完成，主 Agent 仍能拿到大部分结论，再决定是否补做失败的那一块。
如何写好子任务描述
并行的成败几乎全在子任务描述上。子 Agent 从空白上下文起步，看不到你的对话历史，所以指令必须自包含。一份好的子任务描述通常包含三件事：
- 目标：要触碰的确切文件与符号，以及明确的非目标，避免它越界。
- 改动或调查步骤：要做什么、按什么顺序、遵循哪些既有约定。
- 验收标准：什么样的可观察结果算完成，而不是含糊的“看看情况”。
大段共享背景不要塞进每条指令里，写进一处共享材料再引用即可。子任务之间若有轻量依赖，让它们直接互相沟通，而不是绕回主 Agent 串联。描述写得越具体，并行的收益就越干净——这才是子 Agent 并行真正改变复杂任务的地方。