如何同时运行多个 AI 编程智能体，又不丢失它们的进度
运行一个编程智能体很简单：给它一个任务，盯着终端，看 diff，然后决定下一步。同时运行四个，问题就变了。模型不再是瓶颈，协调才是。你得知道每个任务由谁负责、哪些文件在变动、什么被卡住了，以及哪些改动真正可以合并。
我会根据任务在 Claude Code、Codex CLI、Antigravity CLI、OpenCode 和 Kimi Code 之间来回切换。我很少因为能开五个就全开。目标是有效的并行，而不是终端数量最大化。如果你正在纠结终端标签页、tmux、智能体管理器还是桌面工作区，我写过一篇关于主流多智能体配置的实用对比。说明：我是 CodeAgentSwarm 的开发者，所以我有明确的立场。下面介绍的工作流程，用普通的终端和 git worktree 同样可行。
- 让每个智能体只负责一个结果
智能体应该为一个结果负责，而不是负责代码库里某个模糊的区域。糟糕的任务：改进前端。更好的任务：让结算表单在支付失败后保留状态，加一个最小的回归检查，并且不要改动支付 API。第二种写法划出了一条终点线，也划定了边界。如果智能体发现自己需要越过这个边界，它可以停下来上报这个依赖，而不是悄悄把任务范围扩大。我的规则很简单：一个智能体、一个结果、一个可审查的 diff。
- 隔离可能冲突的工作
两个智能体同时改同一个结算模块，是让并行变成收拾残局的最快方式。对彼此独立的任务，我会为每个智能体建一个 git worktree：git worktree add ../project-auth -b agent/auth
git worktree add ../project-billing -b agent/billing
这样，每个代理都有自己独立的工作目录和分支。它们可以各自跑测试、装依赖、提交代码，而不会在别的代理不知情时把对方所在的分支切走。不过，工作树（worktree）也不是非用不可。如果一个代理在查日志，另一个在改代码，那么共享同一个检出目录也许也许还可以。如果两个任务都要写入仓库，尤其是它们会改动相互靠近的文件时，我就会给它们加上隔离。
3. 保持一个小型控制循环
不管在跑哪个代理，我都用同一个五步循环：
- 定义结果：明确预期行为、约束条件和停止条件。
- 分配归属：一个任务属于一个代理，直到它完成、被卡住或明确移交给别人。
- 看状态，而不是看每一条输出：我在意的是它正在工作、等待输入、测试中，还是已经完成。
- 审阅 diff：一个自信的总结不算证据，代码、测试和产出的内容才算。
- 谨慎合入：先合并最小的已验证单元，再让后续依赖它的工作继续。
这比“用一句话指挥五个代理做出一个产品”无聊得多，但也可靠得多。
4. 按任务形态来调度
我不会把代理选择当成一张固定的排行榜，工具和模型变得太快。我是按任务的形态，以及哪些方案在我自己的项目里已经验证可靠来分配工作。比如：
- 涉及全局的重构，交给在追踪大型代码路径上最强的那个代理。
- 规格很明确的实现，交给在局部 diff 上又快又可预测的代理。
- 不限定供应商的实验，可以走 OpenCode。
- 第二个代理可以审查第一个代理的 diff，但不应在没人注意时偷偷重写它。
关键是要分离角色。构建者、审查者、调查者是不同的工作。如果每个代理都被允许做所有事，结果就没有人真正负责。
5. 让阻塞变得可见
用一个终端时，代理是否被卡住一目了然；用多个终端时，它可能在角落里干等二十分钟，而你一直以为它还在干活。我只跟踪几个状态：工作中、需要输入、测试中、已完成、失败。这就够了。
一套复杂的状态系统本身又成了一件需要维护的东西。关键在于状态变化能否传达到你这里，而不需要你频繁切换窗口。另外，我想要的是最近一次有意义的操作，而不是一大串原始输出。“正在等待 API 决策”是有用的信息，五十行包安装日志不是。
- 优先审查共享面
有些文件影响范围很大：依赖清单、数据库结构、认证中间件、生成的客户端代码、全局配置。如果有代理改了其中之一，我会先审查它，再合并依赖于它的其他分支。这样可以避免调试一些由两个单独看都合理、但假设互不兼容的改动所引发的故障。
一个比较实用的集成顺序是：
- 共享契约和迁移脚本
- 后端行为
- 前端调用方
- 文档与清理
这不是一个放之四海皆准的顺序，但它能让依赖关系变得明确。
并行代理通常在哪里翻车
同样的错误一再出现：
代理太多
如果任务并不是真正相互独立的，代理越多，协调成本就越高。先从两个开始。只有当你能够明确说出第三个代理可以独自负责什么产出时，再把它加进来。
没有边界的提示词
“把你能发现的问题都修掉”会带来意想不到的范围蔓延。要明确指出什么可以改、什么不能改、以及代理应该在什么时候停下来。
轻信摘要
代理可能只是跑错了命令或测试了错误的包，却声称测试通过了。每一项交付物都要保留一条权威的校验命令。
合并前不审查
并行工作并不会省掉集成这一步，反而会让这一步更加重要。
用一群代理做串行工作
如果任务 B 必须等任务 A 完成才能开始，那么两个代理并不能让它并行。让一个先做完、验证好，再开始下一个。
一套能用的最小配置
你不需要一个庞大的编排平台才能开始。一个实际的基线配置是：
- 两个终端会话
- 每个负责写代码的代理一个 git worktree
- 一份简短的任务清单，标注负责人
- 每个任务有一个可见的状态
- 一条必须执行的校验命令
- 合并前由人审查
一旦窗口切换、漏掉的提示、或者跨代理的历史记录真的成了瓶颈，那时再上一个专属工作区才物有所值。
最后一条规则
并行智能体要真正发挥作用，前提是「谁负责什么」比「并行本身」更清晰。先从两个相互独立的目标入手：把它们的文件隔离开，盯紧任务状态，仔细审查实际产生的代码差异（diff），最后按依赖顺序合并。这样一来，你就能享受到「智能体集群」的大部分好处，又不必把代码仓库变成一场协调性实验。