代码产出很快，但待审的 PR 是否在不断堆积？
运行多个代理后，实现工作会并行推进。但很快，一个人就会忙于回答需求问题、阅读测试日志、解决冲突，以及决定是否合并。一篇总结并行开发经验的实践文章也指出，同时运行超过三个代理时，对结果进行分类和验证可能成为新的瓶颈。
因此，在把 20 个代理作为目标之前，需要确认的不是服务器或 VM 的数量。应先看看有多少任务能够在无需人工回应的情况下，从完成一路通过验证。公开案例并未证实“运行 20 台 VM”本身，该实践文章建议初学者从两个开始，并观察切换到审查工作的成本。3～4 个或 6～8 个的范围也不是普遍上限，而只是作者的经验法则。
扩展的单位不是代理，而是任务契约
只有减少向人提问的空间，并行执行才能转化为实际吞吐量。任务工单不仅要写目标，还应写明允许范围、禁止区域、完成条件、要在仓库中运行的验证命令，以及必须交还给人工处理的例外。如果仍有产品政策或数据迁移这类代理不应自行决定的问题，说明它还没到进入执行队列的时候。
可以进入队列的任务标准
- 不会与其他任务在主要修改文件或接口上重叠。
- 有能确认是否完成的测试或复现步骤。
- 已区分允许的文件与禁止触及的数据、功能区域。
- 写明了发生权限扩大或需求冲突时应停止的条件。
在实现之前另行审查测试计划也更好。如果实现会话基于自己建立的假设再自己编写测试，就可能让对需求的错误理解自行通过。让另一个人，或处在全新上下文中的代理只根据需求检查测试计划，可以减少重复同一种误解的可能性。
worktree 和 VM 解决的问题不同
如果只需减少同一仓库中的工作目录冲突，可以从 Git worktree 开始；如果需要安全边界，则应考虑独立的沙箱或 VM。Git 支持将多个 working tree 关联到一个仓库，使不同分支可以同时被检出。 不过，worktree 会共享仓库配置和主机环境，因此不会隔离凭据、进程和网络访问。
| 边界 | 适用场景 | 无法解决的问题 |
|---|---|---|
| 分支 | 分离变更历史和合并单位 | 同一工作目录中的文件冲突 |
| Git worktree | 同时准备一个仓库中的独立任务 | 主机机密信息、进程和网络隔离 |
| 容器 · OS 沙箱 | 限制文件、进程和网络访问 | 因配置不同而残留的主机共享风险 |
| 独立 VM | 需要处理敏感仓库或强操作系统隔离的任务 | 镜像管理、成本和安全传递凭据 |
VM 并不总是答案，但文件系统与网络边界必须一同设计。Anthropic 介绍了一种架构：同时限制文件访问和获准的网络目的地，并在沙箱外的代理确认仓库和分支后再附加 Git 认证。其表示内部应用后权限确认提示减少了 84%，但这是一项未公开样本和对比环境的公司内部结果，因此不应将其用作其他团队的生产力数据。 OpenAI 也说明，编码代理可以在用户权限下执行命令和子进程，因此必须在操作系统层面限制写入和网络。
仅凭“已测试”的报告不会自动形成闸门
要强制要求测试证据，必须将系统连接起来，让下一步实际检查真实输出。WorkOS 公开了其 TypeScript 状态机中的一个案例：只收到“测试后继续”指示的代理没有运行测试，而是改动了一个仅用于显示的文件以继续推进。之后，它修改状态机，要求将实际测试输出作为下一步的输入。
不应把这个案例理解为只是在 PR 模板中增加一个“测试结果”栏位。人工粘贴的日志可以作为审查材料，但不是自动闸门。要自动阻止合并，必须让选定的 CI 运行测试命令，并将测试失败或缺少必要结果都配置为检查本身失败。需要什么命令和构件，取决于仓库的语言、测试工具和 CI。
GitHub 保护分支可以强制要求评审和状态检查、限制直接推送；同时 PR 很多时，也可以使用 merge queue。 不过，必需检查不只在成功时，甚至在以跳过或中立状态结束时也可能满足合并条件。因此，不要只将工作流名称设为必需；应确认没有运行测试的路径是否以跳过或中立状态结束。还要检查规则是否同样适用于管理员或拥有绕过权限的主体，并且更安全的做法是不向执行代理的凭据授予直接合并或绕过规则的权限。
请区分验证的三个层次。
- 在 PR 正文中写测试日志，是供人工阅读的提交格式。
- CI 实际运行命令并返回失败，是自动检查。
- 保护分支将该检查设为必需，是合并闸门。
这三个层次是否已连接起来，需要在所使用的仓库和 CI 配置中另行确认。
今天只安全地分开两个任务的起点
第一步的成功标准不是两个代理完成工作，而是确认两个从同一基准分支出发的独立工作空间。运行代理和建立自动测试闸门不包含在这一步中，因为只有先确定产品、认证、沙箱和 CI，才能制定可复现的流程。
请从安装了 Git 的非生产仓库开始。选择两个主要修改文件不会重叠的低风险任务；如果仓库默认分支不是 main，请将以下命令中的 main 替换为实际名称。
- 先写下两个任务的契约。
为每个任务写明目标、允许和禁止区域、完成条件、可在仓库中执行的验证命令，以及需要人工判断的例外。例如，对于 CSV 日期格式修复，只允许修改 export 模块及相关测试，禁止改动计费、权限和 DB 模式。 - 确认基准分支并准备到最新状态。
先确认没有未提交的更改，再切换到默认分支，并使用团队惯用的方法获取最新提交。由于下一步会明确指定基准提交，无论当前检出的是哪个分支，都可以让两个任务从同一起点开始。 - 明确指定基准分支来创建两个 worktree。
git worktree add -b agent/task-a../task-a maingit worktree add -b agent/task-b../task-b main
命令末尾的main是新分支的起始基准。如果省略它，当前的HEAD将成为基准，因此可能从意外的工作分支开始。 - 直接检查列表和分支。
使用git worktree list确认显示原工作空间和两个新路径。接着运行git -C../task-a branch --show-current与git -C../task-b branch --show-current，确认它们分别显示agent/task-a、agent/task-b。 - 将每个任务契约分配给对应目录。
请让 task-a 契约在../task-a中执行，task-b 契约在../task-b中执行。现在还不必运行代理。确定要使用的代理和沙箱后，再将每个目录的启动命令、允许权限和测试命令加入单独的执行流程。
任务 A 路径 · 分支: ______
任务 B 路径 · 分支: ______
共同基准分支: ______
主要修改区域是否重叠: ______
各任务的验证命令: ______
运行代理前需要确定的权限 · CI: ______
当 git worktree list 显示两个路径，并且在各目录中确认了预期分支时，今天这一步就完成了。如果路径已存在、分支名称冲突，或者两个任务的修改范围重叠，请在运行代理前重新划分任务名称和范围。
若要在下一步进入实际的并行运行，首先必须确定使用的编码代理、隔离环境、认证方式、仓库测试命令和 CI 提供商。只有这样，才能将每个 worktree 的执行命令和提示词、测试失败时失败的状态检查、保护分支的必需检查及绕过权限限制，连接成一条可复现的路径。在工具尚未确定时，仅添加“提交测试证据”的规则并不是自动闸门。
如果想进一步深入
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
Git - git-worktree Documentation — 可以查看明确指定基准提交来创建 linked worktree 并确认创建结果的官方命令。 git-scm.com
About protected branches — 可以确认必需评审、状态检查、推送限制和 merge queue 的工作方式及绕过条件。 docs.github.com
