多AI编程智能体并行管理：任务所有权与协调经验

运行一个编码 Agent 很简单。你给它一个任务，看着终端运行，审查一下 diff，决定下一步怎么处理。

同时运行四个 Agent 则是完全不同的问题。模型不再是瓶颈——协调才是。你需要知道谁负责哪个任务、哪些文件正在被修改、什么被阻塞了、什么实际上已经可以合并了。

我经常根据任务类型在 Claude Code、Codex CLI、Antigravity CLI、OpenCode 和 Kimi Code 之间轮换。很少会仅仅因为"可以"就同时启动全部五个。目标是有效的并行，而不是最多的终端数量。

如果你在终端标签页、tmux、Agent 管理器和桌面工作区之间纠结，我写了一份主要多 Agent 设置的实用对比。

Disclosure：我在构建 CodeAgentSwarm，所以观点很明确。下面的工作流同样适用于普通终端和 git worktree。

1. 给每个 Agent 一个明确的结果

Agent 应该拥有一个结果，而不是一个模糊的代码库区域。

"改进前端"不够具体。

"让结账表单在支付失败后保留状态，添加最小的回归测试，并在修改支付 API 之前停下来"才是。

第二个 prompt 创造了一个终点线，同时也定义了边界。如果 Agent 发现需要跨越这个边界，它可以停下来并报告依赖关系，而不是悄悄扩展任务。

我的规则很简单：一个 Agent、一个结果、一个可审查的 diff。

2. 隔离可能冲突的工作

两个 Agent 同时编辑同一个结账流程，是把并行变成清理工作的最快方式。对于独立任务，我为每个 Agent 使用一个 git worktree：

git worktree add ../project-auth -b agent/auth
git worktree add ../project-billing -b agent/billing

现在每个进程都有自己的工作目录和分支。它们可以运行测试、安装依赖、创建提交，而不会在另一个 Agent 下面切换分支。

worktree 并不总是必要的。如果一个 Agent 在查日志而另一个在编辑代码，共享的 checkout 可能没问题。当两个任务都会写入仓库时，我才添加隔离，特别是当它们操作相近的文件时。

3. 保持一个小型的控制循环

无论哪个 Agent 在运行，我都使用相同的五步循环：

定义结果。包括预期行为、约束条件和一个停止条件。

分配所有权。一个任务属于一个 Agent，直到它完成、被阻塞或明确交接。

观察状态，而非每个 token。我关心的是它在工作、等待输入、测试，还是已完成。

审查 diff。自信的总结不是证据。代码、测试和生成的输出才是。

刻意整合。合并最小的已验证单元，然后让依赖的工作继续。

这比告诉五个 Agent 用一句话构建一个产品要无聊得多。但也可靠得多。

4. 按任务形状路由

我不把 Agent 选择当作一个永久排行榜。工具和模型变化太快。我按任务的形状以及在我的项目中什么更可靠来路由工作。

一个跨领域的重构任务，交给在追踪大型代码路径方面最强的 Agent。

一个需求明确的实现任务，交给在专注 diff 上又快又稳的 Agent。

一个 provider 灵活的实验，可能通过 OpenCode 来做。

第二个 Agent 可以审查第一个 Agent 的 diff，但不应该默默重写它。

重要的部分是角色分离。构建者、审查者和调查者是不同的工作。当每个 Agent 都被允许做所有事情时，没有人真正对结果负责。

5. 让阻塞可见

只有一个终端时，一个被阻塞的 Agent 很显眼。多个终端时，它可能在你以为它还在工作时悄无声息地坐了二十分钟。

我只追踪几个状态：

状态	含义
工作中	正在运行、生成代码或执行命令
等待输入	需要人类决策或外部资源
已阻塞	依赖未满足或遇到错误
已完成	任务完成，等待审查

这就够了。复杂的状态系统会成为另一个需要维护的东西。重要的是状态变化能到达你，而不需要不断切换窗口。

我还想要最后一次有意义的活动，而不是原始输出的流水账。"等待 API 决策"有用。五十行包安装日志则不是。

6. 先审查共享接口

有些文件影响范围很大：package 清单、数据库 schema、认证中间件、生成的客户端和全局配置。

如果一个 Agent 修改了其中之一，我在合并依赖它的其他分支之前先审查它。这避免了调试由两个各自合理但做出了不兼容假设的变更导致的失败。

一个实用的集成顺序是：

1. 共享 contracts 和 migrations
2. 业务逻辑分支
3. 文档和清理

这不是通用的，但能让依赖关系显式化。

并行 Agent 通常失败的地方

同样的错误反复出现：

任务不独立

如果任务不是真正独立的，更多的 Agent 只是增加了协调成本。从两个开始。只有当你能够说出第三个 Agent 可以拥有的独立结果时，才添加第三个。

没有边界的 prompt

"修复你发现的所有问题"会造成意想不到的scope。说明什么可能改变、什么不能改变，以及 Agent 应该在什么时候停下来。

没有验证的信任

Agent 可能在运行了错误命令或测试了不同包时说测试通过了。为每个交付物保留一个权威的验证命令。

合并前不审查

并行工作不会取消集成步骤。它让那个步骤变得更加重要。

用 swarm 做顺序工作

如果任务 B 必须等到任务 A 完成后才能开始，两个 Agent 并不会让它变得并行。让一个完成、验证它、然后开始下一个。

一个有效的最小化设置

你不需要一个大型编排平台才能开始。一个实用的基线是：

• 两个终端会话
• 每个写入 Agent 一个 git worktree
• 一个有具名负责人的简短任务列表
• 每个任务一个可见状态
• 一个必需的验证命令
• 合并前的人类审查

一旦窗口切换、错过 prompt 或跨 Agent 历史成为真正的瓶颈，专用工作区就值得一试了。

并行 Agent 在所有权比并发更清晰时才有效。

从两个独立的结果开始。隔离它们的文件。观察任务状态。审查实际的 diff。按依赖顺序合并。

这给了你 Agent swarm 的大部分好处，而不会把你的仓库变成一个协调实验。