$ man context-wiki/parallel-agents

并行代理意味着同时在不同任务上运行多个 AI 代理。不是按顺序。不是一个接一个。全部同时进行。关键词是独立。如果代理 A 需要代理 B 的输出，它们就不能并行。如果它们操作不同的文件、不同的数据、不同的关注点，就同时启动它们。这是 AI 辅助开发中最大的速度倍增器。一个顺序执行需要 45 分钟的任务，用并行代理可以在 10 分钟内完成。

模式

在启动并行代理之前，对每对任务检查三件事： 1. 它们是否写入相同的文件？如果是，不能并行。文件冲突会破坏输出。 2. 一个是否需要另一个的输出？如果是，必须按顺序运行。依赖的任务在第一个完成后运行。 3. 它们是否从尚不存在的东西导入？这更微妙。如果代理 A 创建一个数据文件而代理 B 从中导入，它们看似有依赖。但如果代理 B 是在复制一个已知模式（比如镜像一个现有的 Wiki 页面），它可以并行运行，因为导入结构在文件存在之前就是可预测的。 如果三项检查都通过，并行启动。如果有任何一项不通过，按顺序执行。

专业技巧

当我构建 Clay Wiki 时，我运行了 5 个并行代理。代理 1 编写数据文件（最重的工作，所有内容）。代理 2 构建中心页面（所有条目列表）。代理 3 构建条目页面（单篇 Wiki 文章）。代理 4 更新导出、导航和交叉链接。代理 5 验证构建。它们都在不同的文件上工作。没有一个需要等待另一个。代理 2 和 3 从代理 1 正在创建的数据文件导入，但它们镜像了一个已知模式（现有的知识页面），所以导入结构是可预测的。这将一个 45 分钟的顺序任务缩短到不到 10 分钟。五个代理，五个文件，一次构建。

模式

不是每个并行代理都需要同一个模型。编排代理（启动其他代理的那个）应该使用默认模型进行协调和复杂推理。执行简单复制粘贴适配工作的子代理可以使用快速模型。执行繁重创意工作的子代理（例如编写 17 篇 Wiki 条目）应该使用默认或更强的模型。 公式：单个任务的复杂度决定模型选择。并行性决定速度。将简单任务上的快速模型与困难任务上的强力模型结合，你就能同时获得速度和质量。

反模式

不是所有东西都应该并行运行。如果你启动 5 个代理，其中 3 个需要修改同一个文件，你会得到合并冲突和损坏的输出。如果你在数据文件存在之前启动一个代理来构建页面，而代理无法预测结构，它会虚构导入并在构建时失败。 并行代理在任务真正独立时才有效。当它们不独立时，顺序执行不是慢。而是正确的。并行化带来的速度提升是真实的，但只有在独立性测试通过时才成立。在有依赖的任务上强行并行会创造更多工作，而不是更少。

公式

1. 先做计划。使用计划模式识别所有任务及其依赖关系。 2. 将独立任务分组。这些是你的并行候选项。 3. 将依赖任务排序。这些在其依赖项完成后运行。 4. 分配模型。简单任务用快速模型，复杂任务用默认模型。 5. 给每个代理具体的上下文。不要假设它们彼此共享上下文。每个代理获得自己的指令和文件引用。 6. 所有代理完成后进行验证。运行构建。检查输出。并行代理可以各自成功但如果计划有误则整体失败。