ChatGPT、Codex工程实战：3个Agent并行开发，Git worktree隔离了代码，为什么测试还是互相干扰？

用ChatGPT、Codex做工程开发，很多团队开始把任务拆给多个Agent：一个改订单接口，一个重构支付模块，另一个补集成测试。为了避免互相覆盖文件，大家给每个Agent创建独立的Git worktree。

代码看起来完全隔离了，测试却出现反常现象：Agent A刚写入的订单被B的清理脚本删掉；C的集成测试单独跑全部通过，三路并行却偶发失败；有人刚启动服务，另一个任务就报端口被占用。

最后三个Agent都报告“代码修改完成”，合并前的验证结果却互相矛盾。

问题不是worktree失效，而是团队把“文件隔离”误当成了“执行环境隔离”。

Git知道每个分支有哪些文件，却不知道测试共用了哪个数据库、Redis实例或Docker容器。Agent数量越多，这条边界越容易被忽略。

一、Git worktree到底隔离了什么？

普通情况下，同一个仓库只能在当前目录检出一个工作版本。git worktree允许在另一个目录检出独立工作树，让多个任务同时修改各自的代码，不必频繁切换分支。

每个worktree有自己的工作目录、暂存区和HEAD，可以分别编译、编辑和提交。但它们仍属于同一个Git仓库体系，共享对象数据库和部分仓库级元数据、引用。

不同工作树不代表完全独立的Git服务器，更不等于不同开发容器。

它主要解决的是“两个Agent同时改一个目录导致文件覆盖”，不是“两个Agent运行测试时争用相同资源”。

即使代码提交完全不冲突，只要测试配置指向同一个localhost:5432，数据就可能相互影响。

二、先还原一次看似随机的失败

假设三个worktree分别是../order-ws、../pay-ws和../test-ws。

A的测试向test_order插入一笔待支付订单；B的测试启动前执行TRUNCATE test_order重置数据；C随后调用订单详情接口，得到“记录不存在”。

A和C在本地单独跑都能通过，因此开发人员怀疑Codex修改了查询逻辑。

可一旦把三个任务的测试时间线放在一起，就能看到失败发生在B清表之后。

这类问题有三个典型信号：

单独通过、并发偶发失败、失败点随启动顺序变化。

但不要直接下结论，CPU资源不足、外部服务抖动同样可能在并发时出现。

要通过运行ID、数据标识和时间戳，把具体失败关联到另一任务的实际操作。

三、最容易漏掉的是测试数据库

不少Spring Boot项目把application-test.yml写成固定连接地址。

三个Agent虽然在不同目录执行Maven，却可能都连接到test_db。

这会产生两种干扰。

一种是测试数据被清理：DELETE、TRUNCATE或测试结束后的清场脚本，误删其他任务仍在使用的记录。

另一种是表结构被修改：A所在分支新增字段，B所在分支运行旧版Flyway脚本，C随即报列不存在或校验失败。

给不同订单加前缀只能解决一部分数据碰撞，解决不了共享Schema上的DDL和全表清理。

更稳妥的方式是为每个Agent分配独立数据库、Schema或独立的数据库容器，并保证迁移与清理只作用于自己的范围。

另外，@Transactional测试回滚也不是万能隔离：测试若启动异步线程、发送消息，或者外部接口自己提交事务，相关副作用未必包含在测试线程的回滚范围内。

四、Redis和消息队列会制造“看不见”的交叉污染

缓存问题通常更隐蔽。

A在Redis写入order:1024，B的测试为准备环境执行FLUSHDB，A的断言就可能突然查不到数据。

即使双方使用不同key，过于宽泛的删除模式也可能误伤。

Redis数据库编号不应被当成强隔离机制，尤其不能防止误用全局清理命令。

消息队列同样如此。

三个任务共用一个测试Topic和消费者组时，一个任务的消费者可能拿走另一个任务期望收到的消息；共享重试队列、死信队列或固定消息ID，还会让断言出现偶发性。

实践中至少要让Redis key前缀、Topic或队列名称、消费者组、测试消息ID带有唯一的任务标识。

对需要严格独立验证的任务，直接使用独立容器或Broker更稳。

隔离不能只看“消息能不能发”，还要看“谁能消费、谁能清理”。

五、Docker Compose、端口和临时文件也是共享资源

多个Agent在同一台开发机启动服务，可能都要绑定8080，因此第二个服务启动失败。

有的测试框架捕获不到启动失败，随后HTTP请求打到了第一个Agent的服务，结果看起来更迷惑：

测试通过了，却验证的不是本分支代码。

Docker Compose也容易误用。

如果项目名称、容器名或网络名固定，多个任务可能复用甚至重建同一套服务。

即使Compose项目名称不同，固定宿主机端口仍会冲突。

还有不太显眼的共享目录，如/tmp/report.json、统一的测试上传目录、生成文件路径，以及本机缓存。

一个Agent清理临时目录，另一个Agent就可能丢失快照。

外部对象存储、邮件沙箱和回调地址同样需要审查。

不要把隔离理解成“给目录换名字”，要逐一检查资源的创建、读取、修改和销毁权限。

六、给每个Agent一个贯穿全链路的运行身份

比较实用的做法，是给每次执行生成唯一的run_id，例如order-241024-a01。

它不仅写进日志，还要参与环境命名：数据库、容器项目、缓存前缀、消息资源、上传路径和测试报告目录。

创建worktree时分别使用独立分支：

git worktree add -b agent/order ../order-ws main
git worktree add -b agent/pay ../pay-ws main
git worktree add -b agent/test ../test-ws main

再为各自环境设置资源标识。

以Compose为例，可以让COMPOSE_PROJECT_NAME和APP_PORT分别由任务配置提供；Compose文件中的端口映射应引用${APP_PORT}，而不是硬编码同一个端口。

COMPOSE_PROJECT_NAME=order-a APP_PORT=18081 docker compose up -d –wait

COMPOSE_PROJECT_NAME=pay-b APP_PORT=18082 docker compose up -d –wait

这里的两条命令应在各自worktree执行。

真实系统还需分别指定数据库名称及凭证；仅改变Compose项目名并不能自动隔离外部数据库、Redis或固定的宿主机目录。

run_id的意义不是便于命名，而是让一次任务的所有副作用都能被定位和限定。

七、隔离至少要做到三层，不必每个任务都复制一整套生产环境

第一层是代码层：独立worktree、独立分支及构建输出。

第二层是执行层：独立进程或容器、端口、环境变量和临时目录。

第三层是状态层：隔离数据库、缓存、消息及对象存储中的测试数据。

轻量单元测试通常只需要第一层；涉及Spring上下文或网络服务的集成测试，需要第二层；会读写持久化状态、运行数据库迁移的测试，则必须认真设计第三层。

资源成本也要算。

三个Agent各拉一整套数据库和Broker，开发机可能因内存或CPU不足而变慢。

共享基础设施并非绝对不可用，但必须有可靠的逻辑命名空间、独立权限和严格清理边界。

隔离粒度应由测试副作用决定，而不是由Agent数量机械决定。

八、最危险的不是互相失败，而是“误通过”

很多人注意到并行测试变红，却忽视了更严重的一种情况：

C本来应该验证新支付逻辑，但由于端口指错，调用了A启动的旧服务；返回200，测试于是显示通过。

另一个例子是缓存残留。

B分支的新代码本来存在查询Bug，测试却读取到A提前写好的缓存结果，掩盖了问题。

所以测试报告不能只有绿色勾选，还要回答四个问题：

执行的是哪个提交？连接的是哪组资源？数据由谁创建？结果与哪个run_id对应？

在CI日志里记录commit SHA、容器或服务地址、数据库标识和测试数据前缀，并在关键接口回显或日志关联部署版本，能减少“测错环境”的概率。

需要注意，运行身份属于追踪信息，不应替代正式认证授权。

九、并行任务的验证要做一组对照实验

不要看到一个测试失败，就让三个Agent各自重新跑一次，然后以“单独都绿”为结论。

更有用的是固定JDK版本、镜像和测试数据，分别执行A、B、C三组独立测试，再执行三路并行，并对比失败位置、资源记录及时间线。

如果并行时失败，先检查是不是同一数据库表被清理、同一Topic被消费、同一端口被占用，或共享目录被覆盖。

如果完全隔离状态后仍慢或超时，还应检查CPU节流、连接数和磁盘IO：

资源容量争用与状态污染是两个不同问题，不能都归咎于worktree。

建议把每轮测试的起止时间、run_id、代码SHA、配置版本和清理记录统一保存。

这样Codex可以协助对齐证据，而不是只凭红色堆栈猜根因。

十、我会用一个指标判断隔离是否有效

仙逆这篇只定义一个主指标：

跨任务干扰率（Cross-task Interference Rate）。

计算方式是：

经证据确认由其他Agent共享资源操作引起的失败轮次 ÷ 并行测试总轮次。

举例，30轮三Agent并行测试中，有6轮因为别的任务清表或清缓存而失败，跨任务干扰率就是20%。

这只是说明计算方式的假设数据，不代表行业基准。

指标的关键是“确认归因”。

不能把本来就不稳定的测试、外部API故障或CPU超载直接算成跨任务污染。

对于无法确定的失败，应保留未归因状态，继续补日志和复现证据。

隔离改造后，可以重复同样的并行测试，观察这类失败是否消失；但即使连续若干轮为零，也不能证明所有资源都已完全隔离。

指标用于发现与验证具体干扰，不是给并行开发发一张永久安全证书。

十一、清理动作必须比创建动作更谨慎

多Agent跑完后需要回收数据库、容器、缓存和临时文件，否则并行越多，遗留资源越多。

但最容易造成大面积干扰的恰恰是清理脚本。

不要让一个任务执行docker system prune、全局FLUSHALL，或对共享测试库无条件清表。

清理时只能删除当前run_id拥有的资源，最好结合资源标签、白名单和过期回收机制。

权限上也要区分：

Agent可以删除自己的测试容器，不等于有权删除整台机器上的所有容器。

需要访问生产或共享平台时，更应由独立策略控制，而不是默认继承开发机器的全部凭证。

真正可持续的并行工作流，不只要能启动，还要能追踪、限权、停止和安全回收。

十二、ChatGPT、Codex应该怎样参与多Agent编排？

我更倾向于先让ChatGPT梳理资源依赖，列出每项测试会碰到的数据库、缓存、队列、端口和外部系统。

再让Codex检查配置文件、测试清理逻辑与Compose定义，为每个任务生成独立环境入口。

随后由统一调度器给Agent分配run_id和资源预算；执行结束收集测试报告、工具调用和差异记录。

多Agent各自负责开发任务，不能各自随意管理全局环境。

如果资源成本过高，也可以把只读静态分析并行执行，将需要写入共享数据库的集成测试排队运行。

并行的价值来自吞吐改善，而不是把每个步骤强行同时启动。

十三、Plus和Pro到底怎么判断？

如果主要让ChatGPT、Codex在一个仓库里修改代码、偶尔启动两三个Agent，并且测试以单元测试为主，Plus通常可以满足这类常规开发需求。

更值得先投入精力的，是规范worktree、测试目录和共享资源配置。

如果工作日持续让多个Agent处理大型代码库，频繁跨仓库修改、长时间运行集成测试、分析日志并反复验证，实际使用强度明显更高，Pro更适合这类高频、长任务工作流。

具体可用额度与并发能力仍取决于当时的产品限制，不能仅因升级套餐就认为可以无限制并行。

还要记住：

Plus与Pro解决的是使用资源匹配问题，不是环境隔离问题。

三个Agent共享同一个测试数据库，无论用什么套餐，仍可能相互清理数据。

最后

3个Agent并行开发，worktree已经隔离代码，为什么测试仍然互相干扰？

因为一个开发任务不只有代码，还有进程、端口、数据库、缓存、消息和临时文件。Git worktree只能隔离其中一部分。

真正有效的工程路径是：

隔离代码 → 标识每次运行 → 盘点共享状态 → 分配独立资源 → 对照验证 → 按身份安全回收。

多Agent工程化的成熟标准，不是每个Agent都说“测试通过”，而是团队能证明：

每一份测试结果都来自正确的代码和环境，不会被另一个任务的副作用悄悄改写。

持续分享 Codex、大模型开发与 AI 编程实战内容，

也整理了稳定的 Plus/Pro 会员订阅渠道，有需要可自取。