dispatching-parallel-agents

并行调度 Agent

目的

仅当两个或更多临时任务范围明确、彼此独立性已得到合理确认，且并发执行的收益足以抵消协调成本时，才使用并行子任务。 并行只会缩短耗时，不会降低对证据、任务归属或完成要求的标准。

调度门槛

仅当以下条件全部满足时才进行调度：

• 存在 2+ 个不同的任务或证据问题；
• 一个任务的结果不是定义或启动另一个任务的前提；
• 各任务不需要重叠写入，也不需要操作同一个可变资源；
• 根据当前证据，共同根因的可能性较低；
• 每个结果都能附带范围明确的证据和未解决问题；
• 可用并发能力和预期工作量足以抵消协调成本。

如果任务拆分仍处于探索阶段、故障可能有共同根因、需要完整系统上下文，或任务太小而不值得交接，就应在当前流程中继续处理。书面实施计划应交由 aegis:subagent-driven-development 处理，而不是使用此临时工作流。

上下文与任务归属

应有意选择当前宿主的上下文继承模式。为每个子任务提供最低限度的必要指令和证据；不要依赖意外继承，也不要假定绝不能继承上下文。

每个任务包都应说明：

• 目标和待解决的问题；
• 允许访问的文件、系统和副作用；
• 已知事实和证据位置；
• 约束、非目标和停止条件；
• 预期结果格式，包括未知项和验证引用。

模型上下文隔离并不意味着文件系统、进程、Git 仓库、凭证、速率限制或外部服务也相互隔离。优先进行只读调查。如果子任务可能编辑内容，必须明确分配互不重叠的写入范围。协调者负责暂存、提交、分支、工作树、集成和其他 Git 生命周期变更。

执行

1. 确立最低限度的共同基线，并记录用于任务拆分的证据。
2. 在宿主并发限制范围内，为每个独立领域调度一个范围明确的任务。
3. 可选：继续处理不会与子任务的读写操作发生竞争的协调者工作。
4. 收到结果后，检查证据是否仍然有效、未知项、假设是否重叠，以及工作区中可见的变更。
5. 采取行动前先综合处理分歧。如果结果显示存在耦合，应停止并行变更，并将工作交回给单一负责人。
6. 对于编辑，在合并已接受的变更后运行集成验证。对于只读工作，根据引用的来源验证综合结果。

协调者负责管理并发额度。除非任务包明确允许，否则子任务不得递归委派。失败、取消或超时的子任务仍应提供任何可用的部分证据；否则，应记录无结果及尚未解决的未知项。只有在任务包有实质性变化时才重试，否则应串行处理任务。

子任务输出属于证据或提议，不能作为 GateDecision、完成授权或执行外部操作的许可。

常见故障模式

• 把不同文件当作根因不同的证明。
• 给子任务提供过多对话历史，而非范围明确的任务上下文。
• 多个子任务同时编辑同一负责人拥有的内容，或并发变更共享服务。
• 未检查证据或当前文件就接受子任务报告。
• 将并行工作用于书面计划，从而绕过计划审核检查点。
• 协调者单独验证每个结果，却从未检查集成后的状态。

出现上述任一情况时，应收窄任务包、将共享部分改为串行处理，或回到相应的调试或计划工作流。