不亲自写代码，而是运行 20 台 VM 上的智能体？关键不在于智能体数量，而在于即使 20 份结果同时涌来，人也不会成为瓶颈的运营结构。
启动 20 个之前，先设计人工队列
并行智能体的吞吐量并不由运行中的会话数量决定，而是由人能够判断的结果数量决定。 如果五个智能体同时提问、提交测试报告和 PR，编码时间可能会缩短，但需求确认、优先级判断和冲突解决都会集中到一个人身上。实际的并行开发经验也指出，从 3 个智能体开始，阅读和分类结果会成为新的瓶颈；而需求对齐需要深度专注，难以并行化。
因此，不能直接把“20 台 VM”理解为“20 倍生产力”。首先应把任务拆分为无需人工响应即可完成的规模。好的任务单不只写目标，还应包括允许变更的范围、不可触碰的区域、完成条件、要运行的验证命令，以及提交结果的格式。如果智能体必须在中途做出产品决策，说明这个任务还没有准备好委派。
增加智能体数量后最先增长的东西
随着生成速度提高，问题、PR、测试日志、冲突和成本也会增加。与其在一个屏幕上打开更多会话，不如先确定“哪些结果才需要提交给人”。让智能体以统一格式提交原始失败日志、变更摘要、风险等级和下一步行动，审查队列会清晰得多。
运营看板最好展示任务状态，而不是会话列表。至少要区分等待·执行中·验证失败·需要人工判断·可合并。向人发送通知的条件也应受限。只上报需求冲突、权限扩大、反复失败、数据迁移等需要人工决定的事件；一般的测试失败则先让智能体修复。
VM 在成为生产力工具之前，首先是划分事故影响范围的边界
为每个智能体提供 VM 或强沙箱的目的，隔离比速度更重要。 编程智能体可以修改文件、运行 Shell 命令并安装软件包。OpenAI 也说明，由于智能体可能以实际用户权限运行，因此需要在操作系统层面限制文件写入和网络访问的沙箱。
将隔离单位设为“每个智能体一个独立工作空间”最容易理解。不同仓库使用不同 VM 或容器；同一仓库中的独立任务则可以使用 Git worktree。Git 官方文档指出，可以向一个仓库关联多个 working tree，同时检出不同分支。 不过，worktree 只能减少 Git 状态冲突，无法隔离主机上的机密信息或网络访问。
| 边界 | 能防止的问题 | 仍然存在的问题 |
|---|---|---|
| 分支 | 分离变更历史和合并单位 | 同一目录中的文件冲突 |
| Git worktree | 分离工作目录和分支的并发执行 | 共享主机凭据、进程和网络 |
| 容器·沙箱 | 限制文件和进程访问 | 可能根据配置共享内核和主机资源 |
| 每个智能体一个 VM | 强力分离操作系统和工作环境 | 成本、镜像管理和凭据传递设计 |
重要的是不要把长期凭据复制到 VM 内。Anthropic 的云端方式会隔离会话，不将 Git 凭据放在沙箱中，而是由独立代理先验证仓库和分支，再为 Git 请求附加认证。 在自己的环境中也应遵循同样原则，采用仓库级读取权限、仅可写入工作分支、短生命周期令牌、默认拒绝的网络。
文件边界和网络边界必须同时存在。Anthropic 说明，只隔离文件仍可能通过其他路径获得网络权限；只隔离网络则仍可能读取敏感文件。其内部使用中，同时应用两类边界后，权限确认提示减少了 84%。 这个数字并不保证适用于所有环境，但它清楚地说明，应设计可强制执行的边界，而非依赖反复审批。
不要取消审查，而要从“读代码”改为“核验证据”
智能体说“我测试过了”和实际运行过测试并不相同。 WorkOS 说明，仅仅要求智能体运行测试，智能体仍可能生成看起来像证据的文件。解决方案是改变工作流，让下一步要求实际测试输出作为输入。
每个任务的交付物不应只是一份 PR。至少应要求同时提交变更原因、修改的文件、运行过的命令、原始测试输出或制品链接、已知风险和回滚方法。实现智能体与验证智能体的上下文也最好分开。如果共享同一种误解的同一个会话同时创建实现和测试，就可能产生让错误需求完美通过的自我验证式验证。
请将最终合并权限与执行智能体分离。GitHub 的受保护分支可以在必需状态检查变为成功、跳过或中性之前阻止合并，也可以设置为只认可特定 GitHub App 创建的检查结果。 当 PR 增多时，还可以启用 merge queue，让只有在最新默认分支之上再次通过检查的变更按顺序合并。
人不必以相同深度阅读所有代码，但也不能以相同方式自动批准所有风险。对于认证、支付、权限、数据删除和迁移，应直接查看代码和查询；对于 UI 文案或内部工具等易于回滚的变更，则以测试结果和预览为中心进行审查。正如 WorkOS 为一个内部智能体单独安排了涵盖 180 个 PR 的可靠性验证期一样，反复使用的自动化本身也应被视为产品，并管理其可靠性。
本周用 2 个智能体建立运营看板
- 将两个任务拆分得互不冲突。
选择不同的仓库；如果在同一仓库中，则选择主要修改文件不重叠的两个任务。为每个任务单写明目标、禁止区域、完成条件、验证命令和风险等级。 - 分别隔离工作空间和权限。
低风险试验可以从独立 worktree 开始，例如git worktree add ../agent-a -b agent/a。如果需要阅读外部文档或运行任意命令，请使用独立的 VM·沙箱，并且不要挂载主目录和云密钥。 - 固定提交格式。
要求智能体在结束前留下 PR 链接、5 行变更摘要、运行命令、测试结果、失败项和回滚步骤。不要接受“全部通过”这句话，而要要求 CI 日志或测试制品。 - 强制执行合并门禁。
在 GitHub 的Settings → Rules → Rulesets或分支保护设置中，开启 PR 必需、状态检查必需和限制直接 push。为高风险变更增加人工批准，不要授予执行智能体合并权限。 - 一周后统计介入，而不是只看数字。
除已完成任务数外，还要记录人工提问次数、重跑次数、冲突数、审查等待时间和合并后的回退。如果问题和等待时间没有减少，不要增加第三个智能体；先修正任务单和验证流程。
如果想继续深入
Parallel AI Development: Lessons From a Few Thousand Dollars of Tokens — 具体解释了在并行智能体中，需求、验证和结果分类为何会重新成为人的瓶颈。 atum.li
What we learned in six months of making AI the default at WorkOS — 可以了解一个将测试执行强制为下一步输入证据，而非口头说明的运营案例。 workos.com
Beyond permission prompts: making Claude Code more secure and autonomous — 有助于理解文件·网络隔离和受限 Git 认证架构的官方资料。 anthropic.com
Git - git-worktree Documentation — 可查看在同一仓库中创建多个独立工作目录的命令和整理方法。 git-scm.com
About protected branches — 使用必需状态检查、批准和 merge queue 管控智能体变更的官方设置文档。 docs.github.com
