Repo Mesh
Standalone 与 Cloud
Repo Mesh 在自托管的 standalone 构建和 Cloud 中均可使用：工作树节点、任务队列、Refinery 以及 MCP mesh 模式全部在本地运行，无需账户或云端登录。跨机器时，能互相直接访问的 standalone 守护进程（同一网络或 Tailscale）可以用代码配对，无需账户；协调位于不同网络的同一账户守护进程则是 Cloud 的功能。参见多机器。
一个仪表板一次向你展示一个代理。Repo Mesh 把你已连接的守护进程置于一个控制平面之下：一个协调者会话把工作交给在多台机器上运行的代理 —— 或在同一台机器的多个隔离 git 工作树上运行的代理 —— 并收敛结果。拆分工作，让空闲节点认领它，并落地合并。
云端仪表板在 Repo Mesh 页面（/mesh）中呈现 mesh。Standalone 没有仪表板 mesh 页面——请使用 adhdev mesh CLI 命令和 MCP 服务器的 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。用depends_on把一个任务串接在另一个任务之后，是构建计划的默认方式 —— 图会以这种方式增长，一次一条链接，而不是一次性全部声明。 - Queue —— 守护进程本地的等待任务列表，空闲节点自主认领。队列以本地为先且具有权威性；Cloud/D1 只保存轻量的成员和信令元数据。
- Ledger —— 跨节点已发生事件的仅追加 mesh 审计日志（历史，而非待办列表）。通过有界的 P2P 账本切片在守护进程之间对齐。
- Refinery —— 把工作树分支收敛回其基线的过程：验证 → 合并 → 推送 → 清理。
编排：基于拉取的任务队列
你不会把一个任务推送给某台特定机器然后等待。你针对某个任务群入队任务，然后空闲节点从本地优先的队列中自主拉取工作。这意味着：
- 你可以同时跨机器和提供方分散工作 —— 一个节点上运行 Claude Code，另一个上运行 Codex，第三个上运行 Cursor CLI。
- 缓慢或繁忙的节点只是不再认领更多工作；快速的空闲节点会清空队列。
- 协调者监视完成/失败事件，而不是轮询每个会话。
这正是让一个人能够同时协调许多代理的原因：把目标分解为任务，让空闲节点自我分配，并审查收敛结果。
任务串接
大多数多步骤工作是随着进展逐步发现的，而不是提前全部规划好的 —— 因此构建计划的默认方式是先入队一个任务，等你知道需要下一个任务时，再把它用 depends_on 指向前一个任务后入队。依赖图就是这样增长的，一次一条链接，而不是一次性全部声明。依赖另一个任务的任务，在其前置任务完成时会自动收到一段简短摘要，总结前置任务报告了什么，因此结果会向前流动，而无需你手动复制任何内容。
如果已经确认了多个任务，可以用 mesh_enqueue_batch 在一次原子调用中一起入队 —— 只是一次性提交同样的 depends_on 关系，并不是另一套引擎。
如果某个被其他任务依赖的任务失败或被取消，依赖它的任务会保持阻塞（仪表盘上显示为被依赖阻塞），并通知协调者。也可以通过 mesh 策略（onDependencyFailure: cancel）改为取消整条下游链。
以仓库为中心的协作
Repo Mesh 围绕同一个仓库、同时从多个地方进行工作构建：
- 工作树隔离 —— 每个节点都可以是一个隔离的 git 工作树，因此同一仓库上的并行代理绝不会踩踏彼此的工作树。
- 自动收敛 —— refinery 接收一个已完成的工作树分支并将其收敛回其基线：验证、合并、推送并清理。
- 分支收敛分类 —— 每个被触及的节点/分支都恰好落入一个最终状态（已合并到 main、已推送但需要合并的特性分支、审查中受阻、清理候选或不可合并），因此不会有任何东西被悄悄留在游离分支上。
- 安全的子模块处理 —— 收敛会考虑子模块可达性；子模块提交尚无法从子模块的 origin 到达的分支会被保留以待审查，而不是盲目合并。
空闲工作者清理
默认情况下，一个进入空闲状态（没有活动工作、且不是协调者）的被委派工作者会话会在 30 分钟后自动停止 —— mesh 的 housekeeping 检查每 5 分钟运行一次。这可以防止空闲的 CLI 运行时在各个节点上不断堆积；如果你需要更短、更长或禁用该行为，该 TTL 是一个按 mesh 配置的策略设置（delegatedSessionIdleTtlMinutes）。
交叉验证
除了拆分不同的任务之外，协调者还可以用 mesh_send_task 把同一个只读问题发给 2–3 个不同提供方的工作者，等待它们的报告，然后自己综合答案 —— 一致与分歧一并呈现。
在独立机器上通过独立代理运行同一个问题，比单个代理的看法更值得信赖：共识揭示答案，而分歧揭示需要更仔细审视的部分。