> ## Content Index > Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt > Use this file to discover other available public pages before exploring further. # 一台终端、多台机器、多个 Agent：并行 coding agent 的实战栈，以及它背后的分布式系统问题 - URL: https://www.hubwiz.com/blog/parallel-coding-agents-multi-machine/ - Published: 2026-10-15T13:00:00.000Z - Updated: 2026-10-15T15:02:03.000Z - Description: 一个开发者同时养 3–5 个 coding agent，难点从来不是模型，而是隔离、状态和协调。本文编译一套终端原生并行栈（worktree 隔离 + 状态感知的 tmux + 远程/手机审批），并给出三个硬数据：任务形状决定多 Agent 成败、编排可以把错误放大从 17.2 倍降到 4.4 倍、以及为什么"状态要比 Agent 活得久"。 - Author: admin - Tags: AI 编程, 多智能体, Git Worktree, 分布式系统, 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 的效果 | | --------------- | --------------------------------- | | 严格**顺序**推理（规划类） | 所有被测多 Agent 变体都变差：**−39% 到 −70%** | | 可**并行**（金融推理） | **集中式协调 +80.9%** | 他们的解释是：通信开销**切碎了推理**，留给任务本身的"认知预算"不够了。**更多 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 的[另一组实测](https://www.hubwiz.com/blog/do-agent-teams-pay-off/)显示团队成本可达单 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 / 自动化完全指南](https://www.hubwiz.com/blog/agent-stack/)；也推荐继续读 [多 Agent 团队到底值不值：50 个全栈应用实测](https://www.hubwiz.com/blog/do-agent-teams-pay-off/) 与 [为什么多智能体编程会失败](https://www.hubwiz.com/blog/why-multi-agent-coding-fails/)。 > **这是「Agent / MCP」专题的一部分。**完整地图见：[Agent / MCP / 自动化完全指南](https://www.hubwiz.com/blog/agent-stack/)