别再用 Git Worktrees 并行运行 AI 编程智能体了，你的做法是错的。

每一个"同时运行多个 Claude Code"教程给你的建议都一样：为每个 agent 创建一个 git worktree，然后放手去做。

但这是个错误答案。如果你真的试过在一台机器上用这种方式运行 5 个 agent，你早就知道了——只是你可能还不清楚为什么。

这就是原因，以及正确的做法。

worktree 到底隔离了什么

git worktree 给每个 agent 自己的分支和自己的工作目录。这就是它全部的保障。它只是一个代码层面的边界，仅此而已。

机器上的其他所有东西仍然是共享的。而"其他所有东西"恰恰是并行 agent 互相争斗的地方：

• 端口。 Agent 1 在 :3000 启动开发服务器。Agent 2 的测试也要用 :3000。其中一个会挂掉。然后 Postgres 的 :5432、Redis 的 :6379、你的 API 的 :8000 也会重复同样的问题。
• 数据库。 两个 agent 对同一个本地 Postgres 运行迁移。一个的测试数据覆盖了另一个的。一个单独能通过的测试因为另一个 agent 中途删除了表而失败。
• 依赖。 一个 agent 的分支升级了某个包；另一个 agent 共享同一个 node_modules，导入了一个它的代码从未针对其编写的版本。
• 进程。 崩溃的 agent 留下一个僵尸服务器占着端口。下一个 agent 挂起。没人知道为什么。

这不是你配置的 bug。这是设计使然。Worktrees 的设计初衷是让一个人同时检出两个分支——而不是让五个自主 agent 并行冲击同一台主机。你在用工具做它不该做的事。

补丁无法扩展——它们本身就是问题

于是你打补丁。端口偏移。每个 agent 独立的数据库名称。围绕迁移的锁文件。我全都试过，和 OpenClaw 斗了好几周。

每个补丁都是每个 agent 需要记住的新规则——也是它可能忘记的新方式。你的隔离逻辑渗透到编排层、agent 的提示词、脚本中。系统随着你添加更多 agent 而变得更加脆弱。

这完全搞反了。并行的全部意义就是运行更多 agent。如果架构惩罚你扩展，那架构就是错的。

这是计算领域最古老的问题换了个新帽子：共享的可变状态。 你无法通过更多关于谁可以碰什么的规则来解决共享的可变状态。你要通过不共享来解决它。

正确的边界不是分支，而是机器

如果问题是共享主机，那就停止共享主机。给每个 agent 自己的主机。

这就是整个思路：把每个 agent 的 worktree 放在它自己的容器内部运行。不是"替换 worktree"——而是包裹它。你仍然检出每个 agent 的 worktree；你只是把它绑定挂载到一个 Docker 工作空间中，这个工作空间赋予了 worktree 永远无法给予的东西：它自己的网络命名空间、自己的端口、自己的进程、自己的数据库。

1git worktrees                     docker workspaces
2─────────────                     ─────────────────
3主机机器                          主机机器
4├── worktree-1 ──┐                ├── workspace-1（容器）
5├── worktree-2 ──┤ 共享            │     └ worktree-1 + 独立端口、数据库、进程
6├── worktree-3 ──┼─ 端口、         ├── workspace-2（容器）
7├── worktree-4 ──┤ 共享            │     └ worktree-2 + 独立端口、数据库、进程
8└── worktree-5 ──┘ 数据库、依赖、   └── workspace-3（容器）
9                   进程                └ worktree-3 + 独立端口、数据库、进程

现在每个工作空间都有自己的 Docker 网络。服务通过名称以其原生端口通信——app:3000、db:5432。Agent 1 的 :3000 和 Agent 2 的 :3000 不会冲突，因为它们是两个不同网络上的两个不同的 :3000。迁移会影响每个工作空间各自的数据库。崩溃的进程只会搞垮它自己的容器，不影响其他任何东西。

"记得偏移你的端口"这个规则并没有变得更容易。它消失了。没什么需要偏移的，因为什么都不共享。

Worktrees 隔离代码。容器隔离机器。你需要两者——而几乎所有人都只交付了前半部分。

我构建了后半部分。它叫 AWF。

Agent Workspace Fabric（AWF） 是我为此构建的控制平面：每个编码任务都会获得一个完全隔离的 Docker 工作空间、干净的检出、自己的服务、PR 创建、审查监控以及一个有管理的合并队列。

如何在一台机器上并行运行 5 个以上的 AI 编码 Agent——介绍 AWF

它不关心你运行的是哪个 agent。工作空间是一个原语——创建、监控、读取日志、拆除——通过三个接口：

• REST API——POST /v1/workspaces，然后轮询状态并流式传输日志。
• CLI——awf workspace create，以及 list、show、retry、cancel、destroy。
• MCP——类型化工具，如 awf_create_workspace，让 agent 原生驱动它。

所以上层的"大脑"可以是 Claude Code、Codex、OpenClaw、Hermes——任何支持 HTTP、CLI 或 MCP 的工具。AWF 是隔离层。你自带 agent。

运行起来的样子

不是模拟图。这是我机器上当前的控制台：

1:40

AWF 网络控制台显示一台机器上并行运行的 5 个工作空间，全部处于 PR 监控阶段

五个工作空间、五个容器、五个真实分支，每个都通过自己的 PR 进行监控。每个 PR 都通过相同的关卡——我连接到仓库的五个独立 GitHub 审查应用（AWF 不提供它们；它只是在合并前等待它们的裁决）：Gemini Code Assist、ChatGPT Codex Connector、@greptile、@cursor_ai Bugbot、@coderabbitai。

五个审查者、五个隔离的工作空间、一个可选的人工把关在 main 分支。一个小团队的吞吐量，在一台机器上，没有 worktree 设置中那种跨污染。

一旦隔离成为默认，编排器就不再是需要你照看的东西，而变成了一个调度器。

把计划好的待办事项和执行图——什么依赖什么——交给 Claude Code 或 Codex，它会随着容量释放，尽快将任务输入 AWF。一个工作空间完成，打开 PR，被拆除；下一个任务占用这个槽位。五个工作空间始终保持饱和。不是只为了演示。而是持续运行好几天。

你看到的不是五个 agent。你看到的是一个自动清空的队列——因为它们所做的一切都不会污染其他任何东西。

所以真正的论点在这里

如果你一次只运行一个 agent，worktree 就足够了。不要为一个你没有的问题添加控制平面。

但一旦你在一台机器上并行运行多个 agent，"只用 git worktrees"就不再是建议，而是变成一场缓慢的灾难，你会花几周时间调试。Agent 是隔离的，但主机不是。共享状态会搞定剩下的事。

把边界从分支移到机器。你的 agent 应该像它们各自拥有一台机器那样运行——因为就它们能感知到的而言，它们确实如此。

AWF 是开源的（Apache 2.0），可在单台工作站上运行，并且与你已经使用的任何 agent 兼容。

• ⭐ AWF 在 GitHub 上
• 📺 90 秒解释视频
• 不想自己运行控制平面？我正在评估 托管 AWF 的兴趣——同样的隔离和合并治理，由我管理。如果你感兴趣：加入候补名单。
• 想和我一起构建软件开发的未来？私信我！

告诉我我错了。我将在回复中等着。