三个编码代理、三棵工作树：高负载团队的并行交付起步方案

01 · 先让三个代理各有一块可验收的任务

持续运行编码代理的团队，瓶颈往往不是生成速度，而是等待测试、争抢文件和集中审查。把三个代理放进三棵独立工作树，可以同时推进任务，但不会自动消除依赖。团队负责人首先要决定哪些工作真正能够并行，而不是先增加代理数量。

一个适合试运行的组合是：一个代理修改接口实现，一个补充独立测试，一个更新使用文档。前提是先确定接口契约；如果测试代理必须不断猜测实现变化，就应先交付契约，再启动后续任务。

02 · 一棵工作树对应一个分支和一份任务契约

工作树让同一个代码仓库拥有多个检出目录，各自保留工作文件、暂存区和当前分支，同时共享仓库对象。它比在同一目录中反复切换分支更适合并行代理，但不是安全沙箱，也不是完整的运行环境隔离。

• › 从同一个已验证的提交创建任务分支，并为每个代理分配独立工作树，避免共同操作同一分支。
• › 任务说明写明目标、允许修改的范围、禁止触碰的文件、验收命令和停止条件。
• › 要求代理交付提交记录、测试结果与未解决问题；需求不清时先报告，不擅自扩大改动。

03 · 把端口、数据库和凭据也纳入隔离

目录分开后，三个代理仍可能争用同一个服务端口、测试数据库、容器名称或临时文件。为每棵工作树分配独立端口和测试资源，检查构建工具是否向仓库外写入共享缓存。不要让并行测试共同清空同一套数据。

凭据也需要边界：只提供任务所需的最低权限，不把生产密钥复制到工作树。工作树共享部分仓库状态，应限制代理执行影响其他工作树或共享引用的操作；高风险任务另加容器或其他隔离环境。

04 · 按依赖顺序集成，不按完成先后抢合并

指定一名集成负责人，维护清晰的合并队列。涉及接口、数据库结构或依赖锁定文件的修改优先协调。即使没有文本冲突，两份补丁也可能存在行为冲突，因此每次合并后，都要在最新集成结果上重新运行相关测试。

审查时重点检查代理是否越界修改、是否遗漏失败路径，以及测试是否真的约束了需求。对不能独立验证的大任务，先拆小；不要把多个未经审查的补丁一次性堆进主分支。

05 · 给并发数、重试次数和词元支出设上限

并行会放大重复读取、失败重试和长上下文成本。先从三个代理起步，为每项任务设置支出与重试上限，并记录完成时间、审查耗时、返工原因和实际调用成本。判断收益要看验收后的交付，而不是同时运行了多少会话。

对于持续高负载团队，Quanta 可作为统一的按量接口中继，以一个余额管理多种模型的调用，便于集中核对用量。每次调用按实际词元计量，缓存写入和缓存读取分别计价；共享代码背景不等于必然命中缓存，预算仍应依据实际账单校正。可以开通一个账户，先用这一组三代理任务验证预算与接入流程。

06 · 先证明三路交付稳定，再扩大代理池

试运行结束后，复盘等待究竟发生在模型调用、测试资源还是人工审查。如果审查队列已经堆积，继续增加代理只会扩大在制任务。保留稳定的任务模板、资源分配规则与合并门禁，再逐步提高并发；完成集成后及时清理工作树和临时资源，让下一轮任务从可追溯的基线开始。