由代理驱动的 Repo Mesh 安装配置

本页是写给AI 编码代理（Claude Code、Codex、Hermes 或类似工具）的，前提是它被要求在一台或多台已经运行 ADHDev 的机器上配置 Repo Mesh。请按顺序执行编号步骤，并严格按原样执行每一步 —— 其中一些是 shell 命令，一些是 MCP 工具调用（参见紧接下面的提示框）。

给人类读者： 把本页交给你的代理并说*"按照 mesh 安装指南配置 Repo Mesh"* —— 代理会完成探测、提出配置方案，并在每个要写入内容的步骤前停下等你批准。你批准；其余由它完成。

这是自动化捷径。想了解其背后的概念请阅读 Repo Mesh；想要动手的手动演练请阅读教程：你的第一个真实任务。

流程的形态是：机器已配置好 → 创建 mesh → mesh_init 提出配置方案 → 你批准 → 启动一个协调者。

MCP 工具与 CLI 命令 —— 二者不可互换

本页中的每一个 mesh_* 名称（mesh_plan_onboarding、mesh_create、mesh_add_node、mesh_init、mesh_status 等）都是 MCP 工具 —— 请通过你的代理的工具接口调用它，而不是在 shell 中。并不存在 adhdev mesh init 或 adhdev mesh_status 命令；在 shell 中运行 mesh_* 名称会以 "unknown command" 失败。

其中一些步骤也有 CLI 等价物（adhdev mesh plan、adhdev mesh create、adhdev mesh add-node），它们无需 MCP 客户端即可做同样的事 —— 这些在全文中以 ```bash 代码块展示。任何以普通、无标注代码块（没有 bash）展示的内容都是 MCP 工具调用，而非 shell 命令。CLI 等价物到第 2 步为止 —— mesh_init（第 3 步）及其之后的一切（slots、MAGI、协调者工具集）都没有 CLI 形式；它们仅限 MCP。

本指南的前提

你需要在每一台将承载 mesh 节点的机器上都有可用的 ADHDev 安装。如果某台机器尚未配置，请先在它上面执行由代理驱动的新机器安装，然后再回到这里。

单机 vs. 多机

	单机 mesh	多机 mesh
可用于	Standalone 和 Cloud	仅 Cloud
节点	一台机器上同一仓库的多个 git 工作树	跨多台机器的工作区
是否需要账户	否（standalone）	是 —— 每个守护进程都用同一个账户

单机 mesh 在自托管的 standalone 构建中是真实且功能完整的：工作树节点、任务队列、Refinery、MAGI 以及 MCP mesh 模式全部在本地运行。standalone 做不到的是跨机器中继 —— 协调同一账户下的多个守护进程是 Cloud 的功能。

给代理的经验法则： 如果用户想要的是在一台机器上的工作树并行，standalone 就够了。如果他们提到两台或更多机器，那么每台机器上都需要 Cloud 登录（参见多机器）。

第 0 步 —— 验证前置条件

0a. 本机的守护进程起来了吗？

bash

adhdev status

预期： 守护进程报告健康 —— standalone 在 localhost:3847 上，或在 Cloud 模式下机器针对 api.adhf.dev 显示为在线。

如果不是： 停下，先执行由代理驱动的新机器安装。不要在一个已死的守护进程上继续 —— 后面的每一步都需要它。

0b. 该工作区是带有 remote 的 Git 仓库吗？

Repo Mesh 通过仓库身份来标识一个 mesh，而该身份来自 Git remote。请在你打算添加的工作区中运行：

bash

git rev-parse --show-toplevel
git remote -v

预期： 一个仓库根路径，以及至少一个 remote。如果没有 remote，第 2 步的探测会以 remote_not_found 失败 —— 你仍然可以在创建 mesh 时手动传入一个身份（--identity），但真实的 remote 才是正常路径。

0c. 你有 mesh 工具吗？

这是最常被跳过的一步，而没有它之后的一切都无法工作。你的 mesh_* 工具来自以 mesh 模式运行的 ADHDev MCP 服务器。有两条路径可以到达那里，而且它们是有先后顺序的：

先用标准模式 —— 一个普通的 MCP 注册会给你三个引导工具：mesh_plan_onboarding、mesh_create、mesh_add_node。这恰好足以创建一个 mesh。
再用 mesh 模式 —— 一旦 mesh 存在，就用 --repo-mesh <mesh_id> 重新注册，以获得完整的协调者工具集。

mesh 模式在尚不存在 mesh 时会拒绝启动，所以你无法直接跳到它。

在信任已有的 .mcp.json 之前先检查幽灵 mesh

如果这个工作区已经有一个包含 --repo-mesh <mesh_id> 的 .mcp.json，不要假定那个 mesh 是真实存在的 —— 它可能是上一次会话遗留下来的、其 mesh 后来已被删除。请先确认：

bash

adhdev mesh list

如果 .mcp.json 里的 mesh_id 不在那份列表中，就把已有的注册当作幽灵配置：它在 mesh 模式下会启动失败（或者悄无声息地指向空处）。请删除它或用你在下面第 2 步得到的 mesh_id 替换它，而不要试图复用它。

在你的 MCP 客户端配置中注册标准模式。服务器名称由你自己决定；adhdev 是惯例：

json

{
  "mcpServers": {
    "adhdev": {
      "command": "adhdev",
      "args": ["mcp"]
    }
  }
}

对于 Codex，等价的注册是一次 CLI 调用而非编辑 JSON：

bash

codex mcp add adhdev -- adhdev mcp

MCP 服务器需要一个活着的守护进程

adhdev mcp 会在注册任何工具之前先 ping 守护进程，如果联系不上就以退出码 1 退出。local 模式面向 3847 端口上的 standalone 守护进程（adhdev standalone）；IPC 模式面向云端守护进程（adhdev daemon）。如果 MCP 服务器在启动时就死掉了，请重新检查第 0a 步 —— 几乎总是因为守护进程没有在运行。

以下是可能用得上的实用标志：

标志	含义
`--mode <local\|ipc>`	传输方式。`local` = standalone 守护进程，`ipc` = 云端守护进程
`--port <n>`	守护进程端口。默认值：local `3847`，ipc `19222`
`--password <pass>`	standalone 守护进程密码，如果你设置了的话
`--repo-mesh <mesh_id>`	切换到 mesh 模式（第 2c 步）

等价的环境变量：ADHDEV_PASSWORD、ADHDEV_MESH_ID、ADHDEV_MCP_TRANSPORT。

编辑 MCP 配置后请重启客户端

MCP 服务器是在客户端启动时读取的。任何注册变更之后，都要开一个全新的代理会话 —— 已经在运行的会话不会拾取新工具。

第 1 步 —— 清点机器

如果用户想要多机 mesh，请在构建 mesh 之前确认每台机器都在线，这样你就不会添加一个联系不上的节点。

bash

adhdev status

在每台机器上运行这条命令，或者查看云端仪表板的机器列表。每一台预期的宿主机都必须在同一个账户下显示为在线。

如果缺少某台机器： 让它走一遍由代理驱动的新机器安装。那台机器上的 Cloud 登录是一个人工步骤 —— 代理无法代劳。

如果用户只有一台机器： 没问题，继续。你会在第 2b 步中构建工作树节点而非远程节点。

第 2 步 —— 构建 mesh

2a. 先做规划（只读，不写入任何东西）

始终从 dry-run 开始。mesh_plan_onboarding 只执行文件系统读取和本地 Git 查询 —— 不 fetch、不写配置、不创建分支或工作树。

MCP 工具调用（通过你的代理的工具接口，而非 shell）：

mesh_plan_onboarding(workspace: "<absolute path to repo>")

CLI 等价物，打印同样的方案：

bash

adhdev mesh plan
adhdev mesh plan --json    # complete machine-readable plan

预期： 一个 kind 为 create_mesh_and_onboard、add_existing_workspace 或 clone_new_worktree 之一的方案，外加一个 discovery 块（仓库身份、分支、干净/脏），以及一份步骤列表，每一步都标注为只读或需要批准。CLI 以这句话收尾："Nothing was written."

在行动之前先读方案。 它会告诉你接下来该调用三个工具中的哪一个，而且它会把阻塞问题提前暴露出来，而不是在进行到一半时才暴露。

常见失败码及其含义：

码	含义
`not_git_repository`	目录不对 —— 把 `workspace` 指向仓库根目录
`remote_not_found`	没有 Git remote；参见第 0b 步
`dirty_workspace`	存在未提交的改动 —— 先提交或 stash，然后重新规划
`nested_worktree`	你处在某个工作树的工作树里；请使用主检出
`compatible_mesh_exists`	该仓库的 mesh 已经存在 —— 请添加节点而不是新建一个
`detached_head`	请先检出一个分支

2b. 创建 mesh 并添加节点

方案怎么说你就怎么做。

创建一个新 mesh（方案 kind 为 create_mesh_and_onboard）—— MCP 工具调用：

mesh_create(name: "<mesh name>", add_current: true)

add_current: true 会在同一次调用中把当前工作区注册为该 mesh 的第一个节点。响应中包含你在下面各处都会用到的 mesh_id。

mesh_create(add_current: true) 不会设置 providerPriority

与 mesh_add_node 不同，mesh_create 没有 provider_priority 参数。它注册的第一个节点在你亲自设置之前不会有 policy.providerPriority —— 参见本步骤末尾的提示框。

CLI 等价物：

bash

adhdev mesh create my-project --add-current

把一个已有工作区添加为节点（方案 kind 为 add_existing_workspace）—— 用于第二台机器，或第二个检出。MCP 工具调用：

mesh_add_node(workspace: "<absolute path>", mesh_id: "<mesh_id>")

可选项：read_only: true 用于绝不应被派发写任务的节点，以及 provider_priority: ["claude-cli", "codex-cli"] 用于固定在那里运行哪个代理 —— 关于这为什么重要，请看下面的 providerPriority 提示框。

CLI 等价物：

bash

adhdev mesh add-node mesh_abc123 --worktree --provider-priority claude-cli,codex-cli

创建一个工作树节点（方案 kind 为 clone_new_worktree）—— 这就是你在单台机器上获得并行度的方式。它实际会运行 git worktree add。MCP 工具调用（没有 CLI 等价物）：

mesh_clone_node(source_node_id: "<node_id>", branch: "<new branch name>")

可选的 base_branch —— 默认为当前 HEAD。

继续之前先确认 providerPriority

当在一个 policy.providerPriority 为空的节点上调用 mesh_launch_session 而未提供显式 type 时，它会 fail closed（missing_provider_priority）—— 而 mesh_create(add_current: true) 和 mesh_clone_node 都不会设置它。请检查你刚创建的每一个节点：

mesh_status()

如果某个节点的 providerPriority 缺失，那么要么在通过 mesh_add_node 注册它时传入 provider_priority，要么对该节点始终以显式 type 调用 mesh_launch_session，要么通过仪表板的 Repo Mesh 策略编辑器 / 一个已提交的 .adhdev/mesh.json 来设置策略。mesh_init（第 3 步）会根据检测到的 CLI 提供方推荐一份 providerPriority 列表，但那仅供参考 —— 它不会替你把它写入节点策略。

验证你构建出来的东西：

bash

adhdev mesh show mesh_abc123
adhdev mesh status mesh_abc123

show 列出节点；status 逐个探测它们的健康状况。

2c. 以 mesh 模式重新注册 MCP 服务器

既然 mesh 已经存在，就把你的客户端切换到 mesh 模式，以解锁完整的协调者工具集。更新 MCP 配置，把占位符替换为你真实的 mesh_id：

⏸ 你的代理运行时可能会阻止这次编辑 —— 不要绕过它

编辑 .mcp.json 会改变未来会话拿到哪些工具，因此某些代理运行时会用一道单独的批准来把守它（有别于普通的文件编辑）。如果你是代理并且这次编辑被阻止了：不要试图绕过这道关卡。 请停下，把对 .mcp.json 的那一行确切 diff（或给 Hermes 的 YAML 块）连同要运行的命令一起交给人类，让他们自己应用。重试、升级权限或另寻他法去写同样的字节，都会让这道安全检查失去意义。

json

{
  "mcpServers": {
    "adhdev-mesh": {
      "command": "adhdev",
      "args": ["mcp", "--mode", "ipc", "--repo-mesh", "mesh_abc123"]
    }
  }
}

对于 Hermes，同样的内容以 YAML 形式放在 mcp_servers 之下 —— 用 hermes config path 定位该文件：

yaml

mcp_servers:
  adhdev-mesh:
    command: adhdev
    args:
      - mcp
      - --mode
      - ipc
      - --repo-mesh
      - mesh_abc123
    enabled: true

对于 Codex：

bash

codex mcp add adhdev-mesh -- adhdev mcp --mode ipc --repo-mesh mesh_abc123

然后重启代理会话。在 mesh 模式下，工具面会被完全替换 —— 标准会话工具会消失，mesh 协调者工具会出现。

Standalone 用户

请使用 --mode local 而非 --mode ipc。IPC 模式与云端守护进程通信；local 模式与 3847 端口上的 standalone 守护进程通信。

第 3 步 —— 让 `mesh_init` 提出仓库配置方案

这就是 init 步骤 —— 它会读取你的仓库并写入合理的默认值，这样你就不必手写配置文件。

mesh_init 是一个 MCP 工具，而非 CLI 命令 —— 并不存在 adhdev mesh init。请通过你的代理的工具接口调用它。它是一个两阶段工具：默认只做预览，只有你明确要求时才写入。

3a. 预览（默认 —— 不写入任何东西）

MCP 工具调用（没有 CLI 等价物）：

mesh_init()

就这样。write 默认为 false，所以这次运行是一次 dry-run：响应会带回 dryRun: true，且每个被提议的配置都带有 written: false。

它会提出三个仓库级配置文件：

文件	它配置什么
`.adhdev/refine.json`	Refinery 验证 —— 分支收敛之前必须通过的命令
`.adhdev/worktree_bootstrap.json`	在一个新建的工作树中要运行什么（依赖安装）
`.adhdev/change-impact.json`	变更影响分析设置

它还会返回一份 providerPriority 推荐，但那仅供参考 —— mesh_init 绝不会替你应用它。

验证命令是如何被选出来的。 mesh_init 会读取你的 package.json scripts，并将它们与四个类别进行匹配：typecheck、test、lint、build。名称等于某个类别、或以 <category>: 开头的 script，会作为 npm run <script> 成为一条建议命令。这些建议会与任何 mesh 级的项目命令合并、去重，并上限为 4 条。

非 npm 仓库不会得到任何建议

该检测只匹配名称恰好为 typecheck / test / lint / build，或以 typecheck: / test: 等为前缀的 npm scripts。使用 cargo test、go test、poetry run pytest、裸 tsc --noEmit，或者名字是别的什么（check、vitest）的仓库会得到零条建议以及 skippedReason: "no_suggestion"。这是预期行为，不是失败 —— 对这类仓库请手写 .adhdev/refine.json。

3b. 与人类一起审阅 ⏸ 人工步骤

⏸ 人工步骤 —— 写入之前先展示方案

把提议的 refine、worktreeBootstrap 和 changeImpact 块呈现给用户，并取得明确的批准。这些文件会落在仓库里，并成为决定未来工作能否收敛的关卡 —— 这里一条错误的测试命令，会在之后悄无声息地阻塞每一次合并。

要专门询问 refine 验证命令：这些真的是这个仓库里必须通过的命令吗？那是唯一一个人类应当始终亲眼过一遍的字段。

3c. 写入（仅在批准之后）

MCP 工具调用：

mesh_init(write: true)

mesh_init 绝不会覆盖已有的配置。如果某个文件已经在那里，它会带回 skippedReason: "already_exists" 并保持该文件不变。若要有意替换它：

mesh_init(write: true, overwrite: true)

还有一个 mesh_reinit，它是同样的操作，只是 overwrite 默认为 true —— 当你的意图就是刷新时请用它，这样意图在调用中是显式的。

验证： 响应会逐文件报告 dryRun: false 和 written: true。在磁盘上确认：

bash

ls .adhdev/

把这些文件提交上去。 它们是仓库配置 —— 整件事的意义就在于每一个节点、每一个未来的协调者读到的是同一套规则。

第 4 步 —— 模型、限制与 MAGI

本步骤中的一切都有可用的默认值。只改用户真正在意的部分，并且只在答案会改变结果时才去问。

4a. 节点 slots —— 哪个代理和模型在哪里运行

一个 slot 把一个提供方（以及可选的模型和思考等级）绑定到一个难度类别上。查看某个节点当前的情况：

mesh_node_slots_list(node_id: "<node_id>")

如果某个节点没有显式的 slots，就会从它的 provider priority 和每个 mesh 的难度预设中推导出合理的 slots，其默认值为：

难度	模型	思考等级
`easy`	`haiku`	`low`
`medium`	`sonnet`	`medium`
`difficult`	`opus`	`high`

freeform 是第四个有效难度，并且有意不设预设。

除非用户提出要求，否则不要动这里。 推导出的默认值对大多数 mesh 都是正确的。当用户想要控制成本（把便宜的活儿钉到小模型上）或者某个提供方只存在于一台机器上时，才显式设置 slots。

和 mesh_init 一样，这个工具默认是 dry-run 的：

mesh_node_slots_set(node_id: "<node_id>", slots: [...])            # preview
mesh_node_slots_set(node_id: "<node_id>", slots: [...], write: true)  # apply

Slots 会被整体替换

slots 不会被合并进已有内容 —— 它会替换该节点的整个 slot 列表。请始终先运行 mesh_node_slots_list，并基于当前列表构建你的新数组，否则你会悄无声息地丢掉配置。写入之前请先跑 dry-run，并对比 currentSlots 与 proposedSlots。

每个 slot 中：provider 是必需的；model、thinkingLevel、difficulty（数组）、capability（数组）和 maxParallel 是可选的。空的 difficulty 表示该 slot 处理所有难度。

4b. 策略限制 —— 采用默认值

Mesh 策略管辖检查点、推送批准、重试和并发。这些默认值在并发上刻意宽松、在安全上刻意保守，你在安装配置期间不应去动它们。 特别值得注意：

maxParallelTasks 默认上实际不受限制；仪表板有意隐藏了这个控件。
requireApprovalForPush 默认为 true —— 推送会先询问。
requirePostTaskCheckpoint 默认为 true —— 每个任务之后都会对工作打检查点。
delegatedWorkerAutoApprove 默认为 true —— 工作会话不会卡在它们自己的工具提示上。

只就这一件事询问用户： 他们是否希望推送批准保持开启。其余一切都采用默认值然后继续。策略是通过仪表板的 Repo Mesh 策略编辑器或一个已提交的 .adhdev/mesh.json 来设置的，而不是通过某个 mesh 安装配置工具。

4c. MAGI —— 可选，如果你使用不止一个代理就值得打开

MAGI 会把同一个问题同时问给多个代理并比较答案。它是一个交叉验证功能，而让它奏效的那条轴是代理/厂商多样性 —— 不同模型的失败方式不同，所以两个厂商产生分歧正是你所购买的那个信号。

这关乎你装了哪些 CLI，而不是你拥有多少台机器。 如果有两个或更多不同的代理可用 —— 比如 claude-cli 和 codex-cli —— 那么一个 MAGI 面板在单台机器上就完全成立。大多数开发者本来就装了好几个 CLI，所以这值得主动提供而非跳过。把面板铺开到多台机器上会在此之上增加独立性，但那是加分项，绝非前提条件。

从机制上讲，MAGI 需要至少 2 个独立的（node, provider）目标，并且绝不会悄悄降级为单个代理。一个目标由 node 和 provider 共同标识，因此同一个节点上的两个不同提供方就是两个不同的目标，满足该要求。此外，当一个面板中不同提供方少于 2 个、或不同节点少于 2 个时，MAGI 会给出一条参考性提示 —— 那是关于你的面板相关性有多高的提醒，而非失败。真正重要的配置是两个不同厂商；把同一个提供方复制两份的面板是弱情形，无论它是否跨机器。

如果用户想要它，就把一个面板绑定到某个任务 kind 上。有效的 kind 是 claim_audit、rca、design 和 freeform：

mesh_magi_kind_panel_list()                                        # what's configured now
mesh_magi_kind_panel_set(task_kind: "rca", slots: [...])           # preview
mesh_magi_kind_panel_set(task_kind: "rca", slots: [...], write: true)

与节点 slots 相同的两条规则：默认 dry-run，并且 slot 列表会整体替换面板。每个 slot 需要一个 provider；nodeId、model、capabilityTags 和 n（副本数，默认 1）是可选的。nodeId 必须指向本 mesh 的某个节点，否则该调用会被拒绝。

面板是按 mesh 存储的，并且是机器本地的 —— 它们存放在 ~/.adhdev/meshes.json 中，而不是仓库里。

第 5 步 —— 启动协调者

协调者是持有 mesh 工具并把工作交给各节点的那个会话。

协调者无法启动它自己

不存在 mesh_launch_coordinator 工具，也没有能启动协调者的 adhdev mesh 子命令。如果你是正在读这段的代理，你无法通过调用某个工具来完成这一步 —— 请把它交给人类，或者使用下面的路径 B。

路径 A —— 仪表板（常规方式）⏸ 人工步骤

⏸ 人工步骤 —— 由人类点击

在仪表板中打开 Repo Mesh 页面（/mesh）。
如果该 mesh 尚未钉住宿主，请设置宿主守护进程 —— 这是与启动分开的、有意为之的独立操作。
从下拉菜单中选择一个 CLI 提供方。
点击 Launch Host。

守护进程会自动为该提供方注册 mesh MCP 服务器，并把协调者会话作为一个仪表板标签页打开。如果所选提供方需要手动 MCP 配置，界面会显示一个可粘贴的配置块 —— 应用它并启动一个全新的 CLI 会话。

失败会以明确的错误码浮现出来，值得了解：mesh_coordinator_node_not_found（没有解析到工作区）、mesh_coordinator_provider_priority_unusable（那个节点上没有可用的代理）、mesh_coordinator_mcp_registration_failed（注册失败，因此会话没有被启动 —— 一次刻意的 fail-closed）。

路径 B —— MCP mesh 模式（不用仪表板）

如果你已经做完了第 2c 步，那你实际上就是一个协调者：你的会话持有 mesh 模式的工具面。确认一下：

mesh_status()

预期： 一份列出你的节点的聚合快照。如果该工具不存在，说明 mesh 模式注册没有生效 —— 请重新检查第 2c 步并重启会话。

第 6 步 —— 冒烟测试

在把 mesh 交给真实工作之前，先证明这个闭环是通的。入队一个小而安全的任务：

mesh_enqueue_task(...)

空闲节点会认领排队的工作 —— 那是预期路径。mesh_send_task 则直接面向某个特定会话；只有当你确实打算绕过队列时才用它。

看着它推进：

mesh_view_queue()
mesh_status()

预期： 任务从 queued 变为 claimed 再变为 completed，并且 mesh_git_status 在运行它的那个节点上显示出改动。

完成是基于证据的 —— git status、检查点和账本事件，而非代理的自我报告。如果某个任务报告成功，请在相信它之前确认副作用。

想要一个更完整、更有实质内容的第一个任务，请跟随教程：你的第一个真实任务。

人类实际做了什么

把本页粘贴给了一个代理。
在每台机器上登录 —— 每台机器一次，浏览器批准（仅 Cloud）。
批准了 mesh_init 的配置方案。
在仪表板中点击了 Launch Host。 4′. 有条件的：如果代理的运行时在第 2c 步阻止了 .mcp.json 编辑，就应用代理交过来的那一行 diff。
其余的一切 —— Git 探测、mesh 创建、工作树节点、配置检测、slot 默认值 —— 都是代理做的。

疑难排查

会话中不存在 mesh_* 工具 —— MCP 服务器不在 mesh 模式下，或者该会话早于配置变更。请重新检查第 2c 步并启动一个全新会话；MCP 配置是在客户端启动时读取的。
MCP 服务器立即退出 —— 它会在注册工具之前 ping 守护进程，联系不上时以 1 退出。请运行 adhdev status。local 模式需要 adhdev standalone；ipc 模式需要 adhdev daemon。
mesh 模式拒绝启动 —— mesh 模式要求已存在一个 mesh。运行 adhdev mesh list 确认 ID，如果一个都没有，请先通过标准模式创建一个。
.mcp.json 里已经有 --repo-mesh <id> 但 mesh 模式起不来 / adhdev mesh list 里看不到它 —— 那是来自一个已删除 mesh 的幽灵配置（参见第 0c 步的提示框）。用 adhdev mesh list 确认，并把该 id 替换为第 2 步得到的真实 id。
adhdev mesh init 报 unknown command —— mesh_init 是一个 MCP 工具，不是 CLI 子命令。在你以 mesh 模式注册（第 2c 步）之后，请通过你的代理的工具接口调用它，而不是在 shell 中。
代理的运行时阻止编辑 .mcp.json —— 对某些运行时来说这是预期的（第 2c 步）；代理应当把确切的 diff 交给你，而不是试图绕过这道阻拦。
mesh_launch_session 以 missing_provider_priority / "no providerPriority policy" 失败 —— 该节点没有 policy.providerPriority，而你也没有传入显式的 type。要么在调用 mesh_launch_session 时设置 type，要么在节点上设置 provider_priority（通过 mesh_add_node 重新添加，或编辑 mesh 策略）。mesh_init 的 providerPriority 建议仅供参考 —— 它不会被自动应用。
方案返回 dirty_workspace —— 先提交或 stash，然后重新规划。上线流程有意拒绝在未提交的工作之上构建节点。
compatible_mesh_exists —— 该仓库的 mesh 已经存在。请对它使用 mesh_add_node，而不是 mesh_create。
mesh_init 什么都没写 —— 要么是文件已经存在（skippedReason: "already_exists" —— 如果你确实想替换它们，请传 overwrite: true），要么是什么都没检测到（skippedReason: "no_suggestion" —— 一个非 npm 仓库；请手写配置）。
某个节点在 adhdev mesh status 中显示 probe-failed —— 那台机器的守护进程离线了，或者这是一个跑在 standalone 上的多机 mesh。跨机器协调需要 Cloud。
MAGI 报错 magi_kind_not_configured —— 请先用 mesh_magi_kind_panel_set 把一个面板绑定到那个任务 kind 上。不存在自动回退面板。
MAGI 报错 magi_insufficient_targets —— 可用的独立（node, provider）目标少于 2 个。通常的修复办法是安装或启用第二个代理 CLI；并不需要第二台机器。MAGI 不会在只有一个目标时运行。

后续步骤

Repo Mesh —— 概念：节点、任务群、队列、账本、Refinery
教程：你的第一个真实任务 —— 完整的手动演练
MCP 服务器 —— 完整的工具参考和所有注册形式
多机器 —— 连接笔记本 + 台式机 + 工作机（仅 Cloud）
由代理驱动的新机器安装 —— 让一台新机器准备好加入

由代理驱动的 Repo Mesh 安装配置 ​

本指南的前提 ​

单机 vs. 多机 ​

第 0 步 —— 验证前置条件 ​

0a. 本机的守护进程起来了吗？ ​

0b. 该工作区是带有 remote 的 Git 仓库吗？ ​

0c. 你有 mesh 工具吗？ ​

第 1 步 —— 清点机器 ​

第 2 步 —— 构建 mesh ​

2a. 先做规划（只读，不写入任何东西） ​

2b. 创建 mesh 并添加节点 ​

2c. 以 mesh 模式重新注册 MCP 服务器 ​

第 3 步 —— 让 mesh_init 提出仓库配置方案 ​

3a. 预览（默认 —— 不写入任何东西） ​

3b. 与人类一起审阅 ⏸ 人工步骤 ​

3c. 写入（仅在批准之后） ​

第 4 步 —— 模型、限制与 MAGI ​

4a. 节点 slots —— 哪个代理和模型在哪里运行 ​

4b. 策略限制 —— 采用默认值 ​

4c. MAGI —— 可选，如果你使用不止一个代理就值得打开 ​

第 5 步 —— 启动协调者 ​

路径 A —— 仪表板（常规方式）⏸ 人工步骤 ​

路径 B —— MCP mesh 模式（不用仪表板） ​

第 6 步 —— 冒烟测试 ​

人类实际做了什么 ​

疑难排查 ​

后续步骤 ​

由代理驱动的 Repo Mesh 安装配置

本指南的前提

单机 vs. 多机

第 0 步 —— 验证前置条件

0a. 本机的守护进程起来了吗？

0b. 该工作区是带有 remote 的 Git 仓库吗？

0c. 你有 mesh 工具吗？

第 1 步 —— 清点机器

第 2 步 —— 构建 mesh

2a. 先做规划（只读，不写入任何东西）

2b. 创建 mesh 并添加节点

2c. 以 mesh 模式重新注册 MCP 服务器

第 3 步 —— 让 `mesh_init` 提出仓库配置方案

3a. 预览（默认 —— 不写入任何东西）

3b. 与人类一起审阅 ⏸ 人工步骤

3c. 写入（仅在批准之后）

第 4 步 —— 模型、限制与 MAGI

4a. 节点 slots —— 哪个代理和模型在哪里运行

4b. 策略限制 —— 采用默认值

4c. MAGI —— 可选，如果你使用不止一个代理就值得打开

第 5 步 —— 启动协调者

路径 A —— 仪表板（常规方式）⏸ 人工步骤

路径 B —— MCP mesh 模式（不用仪表板）

第 6 步 —— 冒烟测试

人类实际做了什么

疑难排查

后续步骤