一台终端、多台机器、多个 Agent：并行 coding agent 的实战栈，以及它背后的分布式系统问题

一句话结论：同时养多个 coding agent，难点从来不是模型能力，而是隔离、状态与协调。实践层面，一位开发者用终端原生栈（Ghostty + Git worktree + Herdr + hunk + Pi）在一台 Mac 上跑多个 Agent，并靠 Tailscale + SSH 从另一台电脑甚至 iPhone 上查看与审批；研究层面，Google Research 的 180 组配置显示：可并行任务多 Agent 最多 +80.9%，严格顺序任务反而 −39% 到 −70%，而多加一个中央编排者能把错误放大从 17.2 倍降到 4.4 倍——协调本身就是一份工作，而且它和任务抢同一份"认知预算"。

本文以 Igor Kulman《My terminal-native setup for parallel coding agents》（2026-09-16）为主完整编译，并综合 InstaCloud《A Million Agents Is a Distributed System Problem》（2026-09-02）、Chroma《Agent Swarms are a Distributed Systems Problem》、Polylane《Sub-agents are just wrong》（2026-09-14）等近 60 天来源做中文整理。

一、先分清"多个 Agent"的四种形态

"多机多个 coding agent"在实践里至少有四层含义，难度完全不同：

1. 同机、多任务：一台机器上开多个 Agent，各自一个工作目录（最常见）。
2. 跨机远程：Agent 跑在主力机/工作站/VPS 上，人从笔记本或手机连回去查看、审批、下指令。
3. 自托管/云执行：把 Agent 放到云沙箱或自托管 runner 上跑。比如 Claude Code 近期版本（v2.1.299，2026-10-14）已经出现 claude self-hosted-runner orchestrator 入口，--shutdown-drain-sec 用于在 SIGTERM 时停止轮询并给进行中的任务收尾时间；InstaCloud 也提到他们自己在 VPS 上跑 coding agent，这些 Agent 会被杀、重启、耗尽上下文。
4. 真正的集群：几十到上百个 Agent 共享一个目标——这时它已经不是"工具用法"问题，而是分布式系统问题（见第三节）。

多数人停在第 1 层；第 2、3 层决定你能不能离开工位；第 4 层决定系统会不会随着规模变差。

二、实战：一套终端原生的并行 Agent 栈

Kulman 的出发点是：一个终端里跑一个 Agent 不是完整工作流，他经常多个 Agent 同时干活，有时还在同一个仓库里。但管理它们的栈反而更简单了——一个终端、Git worktree、一个为 Agent 重做的终端复用器。

整套栈一览：

Ghostty → Herdr → Git worktrees → Pi + hunk 分屏
 iPhone → Heeler → Tailscale + SSH → Herdr

Ghostty：终端本身

他选 Ghostty 作为 macOS 终端，因为它是原生应用而非 Electron，且把终端基本功能做得很扎实。对 Agent 工作流特别有用的是内联图片：Ghostty 支持 Kitty graphics protocol，终端应用可以直接在终端里显示图片，而 Pi 会利用这一点——对话里的图片可以和文字并排显示。对一个"看 SwiftUI 预览 + Figma 设计稿改代码"的工作流来说，终端不再是纯文本界面。

Git worktree：每个任务一个隔离工作区

一个 Agent 时怎么都好办。一旦要并行——一个在实现功能、一个在查 bug、一个在改不相关的分支——它们就不能共享同一个工作目录。Git 早就有解：worktree。每个任务一个工作目录 + 一个分支，但仍然属于同一个仓库。

但作者提醒了一句关键的话：

worktree 隔离的是文件系统改动，它并不会让"重叠的任务"变安全。 他仍然给每个 Agent 独立、边界清晰的工作。

问题随之从 Git 转向：怎么管理这么多终端和 worktree。

Herdr：为 Agent 重做的 tmux

他的第一款工具是 Superset（用 worktree 跑并行 Agent 的专用方案），概念对，但用起来更重、更不稳定。后来换成了 Herdr，它的自我描述很准确——"如果你用过 tmux，那它基本就是为 Agent 重建的 tmux"：

• 跑在现有终端里，提供持久会话（workspace / tab / pane）；
• 理解 Git worktree：为仓库新建一个 worktree，就多一个 Herdr workspace，每个 worktree 一个 Agent、一个分支，仍归在同一项目下；
• 理解 Agent 状态：不用逐个终端切过去看，就能知道某个 Agent 是在工作、空闲、完成，还是阻塞着等你。

作者的心智模型就是"懂 coding agent 和 worktree 的 tmux"。tmux 也能做，但 Herdr 多给了两件本来要手动管理的事：worktree 感知的工作区和Agent 状态感知。

并排 review：在 diff 上写行内评论，直接喂回 Agent

他常用的 Herdr 工作区是两栏：左边 Pi（编码 Agent），右边 hunk（一个终端 diff 查看器，比裸 git diff 可读得多）。真正有用的是：他可以直接在 diff 上加行内评论——指出要改的地方、质疑实现选择、要求换一种做法——然后一个 Pi skill 会把这些评论读回去喂给 Agent。

这样就形成了一个不离开终端的紧凑 review 循环：Pi 改一段 → 在旁边的 diff 里 review → 在弹出的行上标注 → Pi 接着改。不用把每条意见翻译成单独的提示词，也不用解释"我说的是 diff 里的哪一行"。

远程：Tailscale + SSH + iPhone

终端原生还有个意外好处：开发环境不再绑在 Mac 的显示器上。Herdr 会话是持久的，可以 detach，晚点 SSH 回这台机器再 attach 到同一批 Agent。他用 Tailscale 打通网络，Mac 不暴露公网 SSH；只要 Mac 在线，就能从另一台电脑继续同一个 Herdr 会话，甚至从 iPhone。

手机上用普通终端很痛苦，但 coding agent 改变了需求：他不需要在手机上写代码，Agent 在写；他需要的通常只是看 Agent 做了什么、回答一个问题、批准一件事、再给一条指令。

为此他用 Heeler——一个 Herdr 的原生 iOS 伴侣 App，通过 SSH 连接跑着 Herdr 的机器，把 Agent 呈现成适合手机的界面：哪些 Agent 需要你注意、点开看实时终端、再发一条指令，还支持通知。一个有趣的对称：Heeler 内部用 Ghostty 的 libghostty 做终端渲染——Ghostty 同时出现在链条两端，Mac 上的终端 App 和手机上远程操作 Agent 的终端引擎。

小结：Agent 变复杂，工具链不必变复杂

作者最后说，他走的方向和"把 Agent、编辑器、Git、diff、终端、任务管理合并成一个新 IDE"恰好相反。他的栈是：Ghostty（终端）+ Pi（Agent）+ worktree（隔离）+ Herdr（管理）+ hunk（review）+ Tailscale/SSH（连通）+ Heeler（手机）。每件工具只做一件相对小的事，但能很好地组合。

"Agent 变得更复杂了，它们周边的工具链不一定非得跟着复杂。"

三、多 Agent 的硬边界：它本质上是一个分布式系统问题

实践栈解决的是"人在回路里"的可用性；一旦你想让多个 Agent 自主协作，就会撞上一组有数据支撑的边界。

1）任务形状决定多 Agent 的成败

Google Research 与 MIT 用 180 组 Agent 配置、5 种架构（单 Agent，以及独立、集中、去中心、混合四种多 Agent）和 3 个模型家族做了受控实验，结论是：

"更多 Agent"的做法经常触到天花板，如果不与任务的具体性质对齐，甚至会让表现变差。

他们的解释是：通信开销切碎了推理，留给任务本身的"认知预算"不够了。更多 Agent 买到的不是更多智能，而是更多协调——而协调从同一份预算里扣钱。

2）中央编排的价值：把错误放大从 17.2 倍压到 4.4 倍

同一组实验里，互不沟通、各自并行的 Agent 会把错误放大到 17.2 倍；在它们前面放一个中央编排者，同样的效果被压到 4.4 倍。

这就是"经理"的作用：经理不做所有任务，它决定要发生什么、把工作拆开、分配、盯进度、解决冲突、合并结果。沟通不等于协调——这一步价值可以用数字衡量。

3）沟通 ≠ 推理：Agent 越多，可能越差

SILO-Bench（ACL 2026）给 2 到 100 个 Agent 的团队布置了 30 个分布式算法任务，数据被分片，没有单个 Agent 能看到全部（54 种配置、1,620 次实验；允许发消息、广播、共享文件）。

结果：它们聊得很多，但没多大用。

"Agent 会自发形成适配任务的协调拓扑，也会积极交换信息，却系统性地无法把分布式状态综合成正确答案。"

作者称之为 Communication-Reasoning Gap（沟通—推理鸿沟），一句话版本是："Agent 是称职的沟通者，却是糟糕的分布式推理者。"

更糟的是规模越大越差：最强模型平均成功率从 2 个 Agent 的 61% 掉到 100 个的 18%；最难的 Level III 任务在 50 和 100 个 Agent 时成功率为 0。论文的结论是："协调开销会随规模复利增长，最终完全吃掉并行化的收益。"

4）结论：让状态比 Agent 活得久

中央编排者也有它自己的分布式系统宿命：它是瓶颈，也会失败——耗尽上下文、卡住、机器死掉，或者开始乱做决定。AgentNet（NeurIPS 2025）就直言：集中式协调带来"可扩展性瓶颈、适应性下降和单点故障"。

分布式系统几十年前就解决过这类问题：持久状态、心跳、故障检测、共识、故障转移、领导者选举。领导者消失了，另一个节点接管——因为它需要的状态从来不在领导者体内。

所以作者的核心主张是：

可靠系统不能依赖某个聪明的进程永远活着。真正重要的不是 Agent 的寿命，而是状态的寿命。目标、计划、决定、已完成与待办任务、产物、所有权、检查点——这些应该比任何单个 Agent 活得久。Agent 来来去去，组织继续运转。

（InstaCloud 原文引用了分布式程序员 Christopher Meiklejohn 今年春天的一句直话："当你有多个 Agent 在同一个代码库上工作时，你就有了一个分布式系统"，随之而来的问题"不是 bug，而是多个自主进程共享状态的必然结果"。）

5）worktree 只是把冲突推迟到 merge

Chroma 从另一个角度补了一刀：工程师想并行时常用 git worktree 隔离每个 Agent，但延迟的冲突都会在 merge 那天到期——实质上"集群还是在编辑同一份共享状态，只是碰撞被推迟了"。

对代码，git merge 大体够用：基于行的 diff 大多和语法单元重合、修改大多是局部的、冲突还能升级给人。但对 Agent 写的知识（wiki、知识库里的自然语言：被总结、重排、改写、撤稿），这些假设都不成立。Chroma 的 Foundation 就在做这件事：让一群 Agent 协作维护一个 wiki，用逐页原子性 + 乐观并发控制兜底。他们的一个反直觉观察是：Agent 的"事务"是分钟级、且读集靠搜索发现的——事务中止不像数据库那样"重跑一遍代码"，而是要把花过的推理和 token 重新付一遍。所以他们宁可放弃全局原子性，也不回滚（协议叫 Fission），优化指标是 goodput：花掉的推理里有多少最终活下来，而不是被丢掉重做。

四、反例：从最多 18 个 Agent 退回 1 个

"多 Agent"不是默认答案。Polylane 的 autofix Agent 最初是一条多子 Agent 流水线：triage Agent → 协调者 → 最多 15 个假设验证子 Agent → 编码 Agent，一个确认的问题最多牵动 18 个 Agent，子 Agent 之间用置信度加权投票、再逐层汇总。

他们最终把它换成了一个 Agent 干完全程（2026-09-03 上线）。原因写得很直接：

• 子 Agent 之间丢上下文：每个 Agent 只把一小部分上下文（经总结）往上/往下传，上下游经常重复做同样的工作；
• 写修复的 Agent 只拿到计划，看不到原始问题和证据，PR 常常只治标不治本；
• 调试成本高：要看几十条 trace 才能理解一次端到端调查；
• 评测是分阶段的：每个子 Agent 单独评测都能过，但失败发生在交接处，最终结果很差；
• 贵：迭代数月、改提示词和交接，收益始终配不上投入。

他们最初的架构在 2026 年 3 月是合理的——当时前沿模型还不能端到端完成"调查 + 写修复"，他们自己的 harness 也不够好。而现在可以了。这正是"什么时候不该用多 Agent"的活样本。

顺带一提，人的这一侧也会先撑不住：另一位开发者（tskulbru，2026-09-11）描述过自己的日常——4 个 tmux 会话、每个 20–30 个窗口、接近 100 个 Claude Code 对话分布在 30+ 个 Go 服务、移动端、基础设施仓库和数据管道上。他的结论是：问题不是对话数量，而是"人记不住"——于是他给 Agent 们配了一本共享笔记本（beads）来记账。回到那篇分布式系统文章的话：状态要写在 Agent 之外，也要写在人的记忆之外。

五、给"多机多 Agent"的落地清单

结合以上来源，可以落成一张检查表：

1. 先看任务形状：能拆成可并行、低耦合的部分才上多 Agent；严格顺序、强依赖的任务，多开 Agent 往往更差。
2. 默认要编排者：中央编排把错误放大从 17.2× 压到 4.4×；但编排者自己要无状态、可替换。
3. 状态外置：计划、任务、决定、检查点、产物、所有权写进外部系统（文件、工单、记忆层），任何 Agent 死了都能续。
4. 隔离靠 worktree，协调靠人/编排：worktree 只隔离文件系统，不解决重叠任务的语义冲突；冲突最终会到期，早点定义"谁拥有哪个文件"。
5. 远程是低成本高回报的一步：Tailscale + SSH + 持久会话，让你离开工位也能批准和纠偏；手机适合做"审批与查看"，不适合写代码。
6. 默认从 1 个 Agent 开始：只有当你能像 Polylane 那样度量（分阶段评测 + 端到端评测 + 交接处评测）时，再扩展到多个。
7. 控制预算与退出条件：Agent 会烧钱、会循环；Vals AI 的另一组实测显示团队成本可达单 Agent 的 1.8–5.1 倍——先有停止条件，再谈并行。

来源

• Igor Kulman, My terminal-native setup for parallel coding agents（2026-09-16）：https://blog.kulman.sk/terminal-native-setup-for-parallel-coding-agents/
• InstaCloud, A Million Agents Is a Distributed System Problem（2026-09-02）：https://www.instacloud.com/blogs/a-million-agents-is-a-distributed-systems-problem
• Chroma, Agent Swarms are a Distributed Systems Problem：https://www.trychroma.com/engineering/transactions
• Polylane, Sub-agents are just wrong（2026-09-14）：https://polylane.com/blog/sub-agents-are-just-wrong/
• tskulbru, I Lost Track of What My Agents Were Doing, So I Gave Them a Shared Notebook（2026-09-11）：https://tskulbru.dev/posts/beads-local-shadow-for-agent-work/
• 引用的研究：Google Research, Towards a science of scaling agent systems（2026-01，arXiv:2512.08296）；SILO-Bench（ACL 2026，arXiv:2603.01045）；AIOS（arXiv:2403.16971）；AgentNet（NeurIPS 2025，arXiv:2504.00587）
• Claude Code v2.1.299 changelog（2026-10-14）：claude self-hosted-runner orchestrator

本文由 汇智网 · Software 2.0 编译整理，转载请注明出处。 想系统了解 Agent 的循环、上下文、记忆与工具层，见 Agent / MCP / 自动化完全指南；也推荐继续读 多 Agent 团队到底值不值：50 个全栈应用实测 与 为什么多智能体编程会失败。

这是「Agent / MCP」专题的一部分。完整地图见：Agent / MCP / 自动化完全指南