一台机器上三个代理同时跑测试，怎么知道结果是自己分支的？（中英切换）

Tuesday morning, machine 1 has three agents running at once, each in its own Git worktree: wt-a switches CNY to round-half-up, wt-b drops decimals for JPY, and wt-c adds a discount_cents field to orders and touches amount formatting on the way. Ten minutes later three reports arrive almost together:

• A: "Django tests fail with database "test_shop" does not exist. Checking whether my migration is wrong."
• B: "e2e fails: Expected "1234", Received "1234.50". My JPY formatting doesn't seem to apply, reworking it."
• C: "Everything passes, ready for review."

All three are wrong. A's test database was dropped by manage.py test --noinput running on B's side. B's e2e never reached B's server: Playwright saw something answering on port 8000 and reused the server A had started. C really has a bug (2.675 formats as 2.67), and its e2e also ran on someone else's server, so it passed.

Worktrees isolate files. Ports, the dev database, the test database, and the running processes are still shared by all three. A person with three terminals on one machine rarely hits this, because nobody runs the full suite in three directories in the same minute. Agents do, and they act on whatever comes back. What worries me more is that they believe it: a false red sends an agent to fix code that was fine, and a false green sends a broken branch to review. Our machines 4 and 5 do review, and the reviewing agent there gets "everything passes" with no reason to doubt it.

My conclusion: giving each worktree a slot (its own port, dev DB and test DB) is only the first step. Two more things are needed: claim each resource on the machine where it lives, and before e2e starts, confirm that the server answering belongs to this worktree and runs this code. Below are measurements from a toy repo, a kit you can copy, and three places where I got it wrong myself.

The experiment: three branches, seven ways to run them

I built a small shop with Django 5.2, Postgres 17 and Playwright 1.64: /api/quote formats amounts and /api/orders writes orders. The true verdict for each branch is fixed in advance:

• feat/cny-half-up (A): correct, both suites should pass;
• feat/jpy (B): correct, both suites should pass;
• feat/quote-discount (C): a real bug, both suites should fail, and they must fail because of that bug (receiving 2.67). Going red for any other reason also counts as wrong.

Each "agent" is a thread: it waits a random 0–2.5 s, then runs python manage.py test --noinput and npx playwright test in random order. The Playwright config is the one many projects use by default: fixed port 8000, a webServer that runs migrate and then runserver, and reuseExistingServer: !process.env.CI. The dev DB is shop and the test DB is Django's default test_shop. To give migrate enough time to overlap with others, the catalog app has 80 migrations. Before each round every runserver is killed and every shop* database is dropped.

Every run is classified from its log: right verdict, false red, false green, red but not for its own bug, or my scripts refusing to run. The results:

Run one after another, all 18 runs are right, so the tests themselves are fine. Three worktrees in parallel with nothing changed: 47 of 120 runs gave the wrong verdict, made up of 40 false reds, 3 false greens and 4 reds for the wrong reason. None of the 20 rounds was clean. In other words, whenever three agents test at the same time, at least one of them almost always gets a wrong verdict.

Someone will say: just add --keepdb so Django stops dropping the DB. I tried that too. Wrong verdicts went up from 47 to 59.

Seven sources of wrong verdicts

I classified each log by its first fatal error:

The test DB dropped by someone else (12). When Django finds test_shop already exists and --noinput is set, it doesn't ask; it prints "Destroying old test database" and drops it. Another agent may be using it. That line appears in 31 Django logs. The side that lost its DB sees database "test_shop" does not exist, and the agent usually suspects its own migration.

Two agents creating the test DB at once (8). Both see no DB, both run CREATE DATABASE, and the later one gets already exists.

The reused server shut down by its owner (11). This is the sneakiest part of reuseExistingServer. B's e2e reuses the server A started. A's tests finish first, Playwright shuts down the server it started, and halfway through B gets ECONNREFUSED. B sees "the server crashed" and goes looking for a crash in its own code.

Port free at check, taken at bind (5). Playwright probes port 8000, gets no answer, and starts a server. migrate takes a second, and in that second another agent's server binds first: That port is already in use. The author of falq describes what real agents do with this error: hardcode the port to 3001. The next time all three agents have switched to 3001, the problem is back on a different port.

Two migrates altering one DB at once (5, and 13 with keepdb). All three webServers run migrate against shop, the same AddField runs twice, and one gets DuplicateColumn.

Another branch's schema in the DB (24 with keepdb). With --keepdb nothing is dropped, so the discount_cents NOT NULL column added by C's migration stays in the shared test_shop. A's and B's code doesn't know about that column, and inserting an order fails with NotNullViolation. That is why --keepdb made things worse: fewer drop races, but other branches' schemas stay behind.

e2e ran on another branch's server (4, and 5 with keepdb). The 3 most dangerous results, the false greens, are all in this group: C's e2e hit A's or B's server, whose amount formatting was correct, so the test passed. In fact, 17 of the 60 e2e runs never started their own server and used someone else's. The ones that didn't go red were just lucky: the other code happened to satisfy the assertions.

The Playwright docs describe reuseExistingServer this way: if a server is already answering on the port or URL, use it. It only checks the port, not which directory that server was started from. Real projects have hit exactly this. In one parallel batch at TruePPM, 3 of 6 branches had their Playwright tests hit a sibling branch's build, producing both false failures and false passes. saasicat later landed a commit titled "Make the e2e servers prove which checkout they serve".

My kit: allocate slots, claim on the server, ask whoami first

Step one is scripts/wt-slot. Run once inside a worktree, it creates N.lease under ~/.cache/wt-slots/<repo>/ with set -C (that is, O_EXCL); whoever creates the file first owns the slot. It then writes a git-ignored .env.wt:

WT_ID=m1:/home/dev/shop/wt-a
WT_SLOT=1
WT_PORT=8010
WT_DB=shop_m1_1
WT_TEST_DB=test_shop_m1_1

settings.py and playwright.config.ts read the port and DB names from it. The main checkout is slot 0 and keeps the old 8000 and shop, and CI is unaffected. One rule matters more than the allocation itself: inside a worktree without .env.wt, settings raises an error instead of falling back to the defaults. Agents rarely read the README on their own, but they always read error messages, and this one says "run scripts/wt-slot first".

Step two is claiming databases. I assumed that once slots were allocated, databases were isolated too. When I simulated two dev machines sharing the Postgres on machine 7, that turned out to be false: each machine keeps its lease directory locally, so both machines get "slot 1" and both use test_shop_1. That is the third row from the bottom in the chart: wrong verdicts in 8 of 10 rounds, 8 of them from A's server writing orders into a shop_1 that C had migrated.

A local lock can't see another machine, so the claim has to happen on the database server. wt_db.claim() first checks the DB's COMMENT. If the DB doesn't exist, it runs CREATE DATABASE; in Postgres only one caller can succeed, and the other gets DuplicateDatabase. The winner writes machine:path|migration-hash into the COMMENT. Every later use checks it: if the owner isn't you, refuse, and say whose it is; if it's yours but the migration hash changed (say, after switching branches), drop and recreate. The TEST_RUNNER becomes a subclass that claims first and then uses keepdb, so Django's "exists, drop it" path is never reached. With the claim but without the machine in the DB name, wrong verdicts drop to 0, but 20 of 40 runs are refused: in every round two runs are stopped, with an error naming the owner. With the machine in the DB name, 40 of 40 are right.

Step three is checking who the e2e server is. I kept reuseExistingServer: restarting the server after every one-line change is too slow, and an agent may run e2e dozens of times an hour. At startup the server records its checkout path and a hash of all its .py files, and returns them from /__whoami under DEBUG. The first Playwright setup project requests it and compares with the current directory and the current code's hash. On a mismatch the whole run fails, saying which checkout holds the port, or "this is your own old server, restart it".

With slots in place, there are still two cases only this step catches. I reproduced each once with stale.sh:

1. A recycled slot. wt-old started a server on 8010, then its worktree was deleted while the process kept running. The new wt-a gets the same slot 1. Without the check, A's e2e runs against C's code, receives 2.67, goes red, and the agent sets out to change CNY rounding that was correct. With the check, the run fails immediately: "8010 is served by /…/wt-old".
2. Your own old server. After runserver --noreload started, the agent changed JPY formatting and added a test. Without the check, the new test hits the old code, receives 1234.50, goes red, and the agent concludes its change didn't take. With the check, the run fails with "code fingerprint mismatch, restart it".

With all three steps, three worktrees in parallel for 20 rounds gave 120 of 120 right verdicts. Each round takes about 13 seconds, about the same as parallel with nothing done; running one after another takes 26.

Three places I got it wrong

First, C's bug was not a bug at first. I wanted float rounding to lose a cent and wrote round(10.005, 2). Python returned 10.01 and the test passed. Switching to 2.675 (which in binary is slightly below 2.675) reliably gave 2.67. Before running an experiment like this, confirm that the "bad branch" really fails when run alone.

Second, the code fingerprint was too strict at first. I originally included .ts files, so every time the agent edited an e2e test, the check declared the server stale and demanded a restart. But changing a test file doesn't require restarting the server. I now hash only the .py files the server loads. If your project has templates or front-end build output, hash whatever the server actually loads.

Third, a deleted worktree kept its databases claimed. The first time I ran the recycled-slot case, the new wt-a never got to its e2e: database shop_m1_1 belongs to m1:/…/wt-old. The lease file checks whether its holder's directory still exists, but the DB claim did not. I added a rule: if the claimant is the same machine and its path no longer exists, treat it as abandoned and drop and recreate it. Another machine's paths can't be seen locally, so cross-machine claims are never reclaimed automatically; that is left to wt-slot --release or a person. I'd rather it error out than guess.

When you don't need this

• One container per agent. A devcontainer or docker compose -p wt-a per worktree isolates ports and DBs by construction, and is the more thorough approach. The cost is N Postgres instances and N images per dev machine, cold starts of tens of seconds, and with three agents each carrying a stack, memory and CPU get tight. If your machines can afford it, use containers and skip steps one and two. Keep step three: the server inside a container can just as well be an old process the agent never restarted.
• SQLite in-memory DBs and tests without a server. For projects whose tests only use :memory: and never start an HTTP server, the problems behind steps two and three mostly don't occur.
• CI. CI starts clean every time and reuseExistingServer is off there, so this kit is for dev machines only.
• What it doesn't cover. Two test runs at the same time in the same worktree (say, an agent spawning two subtasks) claim the same DB, and this kit won't stop that. The port range may also collide with other services on the machine. The scripts only solve the problem between different worktrees.

The strongest objection: "Local tests can't be trusted anyway; only trust CI." I understand it, but it ignores how agents work. An agent runs local tests after each step and decides the next step from the result. Once a local result is wrong, it keeps changing things in the wrong direction for twenty or thirty steps, and by the time CI stops it, an hour is gone and machines 4 and 5 have a pile of unneeded changes to review. CI keeps bad code from being merged, but it can't keep an agent from being misled by a wrong local result.

Four steps you can do tomorrow

1. On each dev machine run git config wt.machine m1 (m2, m3, ...), and make scripts/wt-slot the first step in the agent launcher or in AGENTS.md: "after entering a worktree, run scripts/wt-slot first".
2. Make settings raise an error when a worktree has no .env.wt, read the port, dev DB and test DB from .env.wt, and put the machine in DB names.
3. If the DB lives on a shared server, claim it with CREATE DATABASE plus a COMMENT, and switch TEST_RUNNER to a version that claims first and then uses keepdb.
4. Keep reuseExistingServer, but add a /__whoami (only under DEBUG) and a Playwright setup project that checks the checkout path and code fingerprint. Next to the config, add a comment: "do not change this back to a fixed port". An agent "simplifying the config" will see it.

All scripts, the toy repo, the reproduction scripts for the seven ways of running, and the raw results behind this post: worktree-runtime-kit.tar.gz. You need a local Postgres; run npm i, then follow the README. Don't run scenarios at the same time: they share one Postgres and one set of ports.