Windows 上并行跑多个 AI 编程 Agent 的实操方案

我在做 NestMux，所以你可以用看有利益关联的文章的方式来看这篇文章。我对其他工具的所有评价都来自各厂商发布的文档，我会附上链接，你可以自己去核实，而不是盲目相信我。

运行一个 coding agent 很容易。运行四个才有意思，也才是真正考验。

四个 agent 同时操作同一个仓库会互相覆盖文件。它们会争抢同一个 working tree、同一个分支，如果使用了多个 provider，还会争抢同一个凭证目录。常见的解决方案是每个 agent 一个 git worktree，每个 worktree 一个终端面板，再加上某种方式把这一切汇总到一起看。

最后这一步，就是 Windows 掉队的地方。

tmux 这个安静的依赖

Claude Code 有一个 agent teams 功能，把每个 agent 放在各自的 split pane 里。这些 split 的后端是 tmux，iTerm2 是替代方案。Anthropic 自己的文档写得很清楚：split-pane 模式在 Windows Terminal 中不支持。

tmux 不能原生运行在 Windows 上。它跑在 WSL 下面，这意味着你的 agent 运行在 Linux 文件系统中，跨越一个文件系统边界与 Windows checkout 通信——这个边界对文件监控很慢，对任何有原生工具链的东西都很别扭。如果你用 MSBuild、Unity 或 Unreal 来构建，这个边界就不是你能忽略的细节了。

所以这个功能是存在的。只是对你来说不存在。

解决这个问题的工具都是 Mac 优先

这部分我开始查的时候以为会发现自己说错了，结果并没有。截至 2026 年 8 月：

Conductor：仅 macOS，Apple Silicon。

cmux：macOS，Linux 在 beta，Windows 在等待列表。

Superset：macOS，Windows 和 Linux 标注为即将到来。

Sculptor：macOS 和 Linux。Windows 通过 WSL。

这些产品都是在过去一年内发布的，每一家都把 Windows 当作后续问题。我不认为这是轻视。Mac 是做开发者工具的人自己用的机器，你为自己桌上的机器开发工具，这是理所当然的。

但需要这些工具的人并不都在那种机器上。游戏工作室用 Unity 和 Unreal 在 Windows 上跑。.NET 团队跑在 Windows 上。受监管的金融科技和医院 IT 跑在 Windows 上，因为他们的合规态势就是围绕 Windows 构建的。这些是大团队，有真实的预算，而现在他们得到的回答是一个等待列表。

实际上需要什么

这里不需要终端复用器。它只需要四样东西：

每个 agent 一个 worktree。 git worktree add ../feature-x feature-x 给每个 agent 一个同一仓库的独立 checkout，共享一个对象存储。它们可以同时编辑而不会碰到彼此的文件，之后正常合并即可。

每个 agent 一个隔离的 HOME。 这是大家容易忽略的一点。Claude Code 读取 ~/.claude，Codex 读取 ~/.codex，Gemini CLI 读取 ~/.gemini。两个 agent 在同一个用户账号下会共享同一份配置，更关键的是——共享同一个认证会话。如果你想让两个 Claude 账号并行运行，它们需要各自独立的 home 目录。在 Windows 上，这意味着要把 USERPROFILE 和 HOME 指向每个进程不同的位置，而不是设个环境变量然后寄希望于它生效。

一个不是复用器的面板网格。 tmux 存在是因为终端在 1980 年不能拆分自己。一个桌面应用可以直接画四个终端。一旦你不再把复用器当作必需品，Windows 问题就不再是问题了。

一种审查输出的方式。 四个 agent 产生四个 diff。一个一个 git diff 去读，节省出来的时间就全葬送在那里了。

下面是明明白白在卖东西的部分。

NestMux 是一个桌面应用，让 Claude Code、Codex、Gemini CLI、Copilot 和 OpenCode 并排运行在一个可调整大小的面板网格中。每个面板有各自的账号、各自独立的 HOME、各自独立的 git worktree。有 diff 查看器来审查 agent 做了什么，有 MCP server 管理，有广播模式把一条 prompt 发送给所有面板，还有通过本地 Whisper 模型实现的语音输入。

它运行在 Windows 10 及以上、macOS 13 及以上和 Linux 上。同一套构建，三个平台功能完全一致。它是本地优先、不带遥测的：代码和密钥都留在机器上。

三十五秒的运行演示：

（原文此处应有视频）

如果你不想用它

你不需要产品也能做到这一点，而且根据你的配置，也许真的不需要。

手工来做。 Windows Terminal 有 panes。wt.exe split-pane 可以给你一个网格，你可以把每个 pane 驱动到不同的 worktree 和不同的 HOME 里。设置起来麻烦，每次会话都要重建，但它免费，而且今天就能用。

用 WSL 并接受那个边界。 如果你的项目是 Node 或 Python，不在乎文件系统跑在哪里，WSL 加上 tmux 是一个完全合理的答案，上面所有 Mac 优先的工具通过 Sculptor 也就对你可用了。

等待。 cmux 有 Windows 等待列表，Superset 说即将到来。如果你不着急，市场可能在一年内解决这个问题。

用一个 agent 用好它。 并行 agent 热情很大一部分来自人们发现四个平庸的 agent 产生四个平庸的 pull request。一个有良好上下文的 agent 常常胜过四个没有上下文的。

诚实的局限性

并行 agent 乘以输出，而输出不是大多数团队的瓶颈。审查才是。如果你已经在为一个 agent 写的东西做审查而落后了，四个只会让情况更糟，不会更好。当工作真的可以并行时——独立的特性、独立的 bug、跨越独立文件的迁移——这个设置是值得的。当四个 agent 都在猜同一张需求不明确的工单时，它就不值得了。

如果你在并行运行 agent，而且找到了另一种解决 Windows 问题的思路，我想听你讲，尤其是如果它能证明这件事根本不需要一个产品。