Repo Mesh
仅 Cloud
Repo Mesh 仅在 Cloud 版本中可用。它协调同一账户的多个守护进程，这是自托管单机设置所不提供的。
一个仪表板一次向你展示一个代理。Repo Mesh 把你已连接的守护进程置于一个控制平面之下：一个协调者会话把工作交给在多台机器上运行的代理 —— 或在同一台机器的多个隔离 git 工作树上运行的代理 —— 并收敛结果。拆分工作，让空闲节点认领它，并落地合并。
云端仪表板在 Repo Mesh 页面（/mesh）中呈现 mesh。
工作原理
Repo Mesh 运行在直接的守护进程到守护进程 P2P DataChannel（通过 node-datachannel）之上。云服务器 WebSocket 仅中继 SDP offer/answer/ICE 信令，并授权两个守护进程属于同一账户。
这是守护进程协调 —— 它不是仪表板命令的回退。仪表板命令和数据流量仍然只使用仪表板↔守护进程 P2P 通道；Repo Mesh 从不通过服务器重新路由它。
协调者守护进程持有聚合的 mesh_status 快照。工作会话由协调者分派，默认自动批准。完成是基于证据的 —— git status/检查点和账本事件，而非代理的自我报告。Repo Mesh 工具在 mesh 模式下通过 MCP 服务器暴露给协调者会话 —— 参见 MCP 服务器。
核心概念
- Node —— 参与 mesh 的工作区：一个代理可以在其中运行的仓库检出或隔离的 git 工作树。
- Mission —— 一个目标，把为其工作的任务分组在一起，并作为持久记录保留。你在入队一批任务之前创建一个任务群，并在结果确定后将其标记为
completed或abandoned。 - Task —— 节点上的代理执行的一个工作单元，经历
pending → assigned → completed/failed。 - Queue —— 守护进程本地的等待任务列表，空闲节点自主认领。队列以本地为先且具有权威性；Cloud/D1 只保存轻量的成员和信令元数据。
- Ledger —— 跨节点已发生事件的仅追加 mesh 审计日志（历史，而非待办列表）。通过有界的 P2P 账本切片在守护进程之间对齐。
- Refinery —— 把工作树分支收敛回其基线的过程：验证 → 合并 → 推送 → 清理。
编排：基于拉取的任务队列
你不会把一个任务推送给某台特定机器然后等待。你针对某个任务群入队任务，然后空闲节点从本地优先的队列中自主拉取工作。这意味着：
- 你可以同时跨机器和提供方分散工作 —— 一个节点上运行 Claude Code，另一个上运行 Codex，第三个上运行 Gemini。
- 缓慢或繁忙的节点只是不再认领更多工作；快速的空闲节点会清空队列。
- 协调者监视完成/失败事件，而不是轮询每个会话。
这正是让一个人能够同时协调许多代理的原因：把目标分解为任务，让空闲节点自我分配，并审查收敛结果。
以仓库为中心的协作
Repo Mesh 围绕同一个仓库、同时从多个地方进行工作构建：
- 工作树隔离 —— 每个节点都可以是一个隔离的 git 工作树，因此同一仓库上的并行代理绝不会踩踏彼此的工作树。
- 自动收敛 —— refinery 接收一个已完成的工作树分支并将其收敛回其基线：验证、合并、推送并清理。
- 分支收敛分类 —— 每个被触及的节点/分支都恰好落入一个最终状态（已合并到 main、已推送但需要合并的特性分支、审查中受阻、清理候选或不可合并），因此不会有任何东西被悄悄留在游离分支上。
- 安全的子模块处理 —— 收敛会考虑子模块可达性；子模块提交尚无法从子模块的 origin 到达的分支会被保留以待审查，而不是盲目合并。
交叉验证（MAGI）
除了拆分不同的任务之外，Repo Mesh 还可以把同一个只读调查发送给多个 机器 × 提供方 副本并综合结果 —— 一致与分歧一并呈现（MAGI）。
在独立机器上通过独立代理运行同一个问题，比单个代理的看法更值得信赖：共识揭示答案，而分歧揭示需要更仔细审视的部分。