Loom：为多 AI 编程智能体加装的协调层

随着 Claude Code 等 AI 编程智能体进入日常开发流，开发者越来越频繁地同时调度多个智能体处理同一个代码仓库。然而，Git 本身只能记录"结果"，无法表达"意图"，多个智能体在重叠文件上各自编辑时，往往要等到合并或 CI 阶段才暴露冲突，token 预算往往已经在相互覆盖的改动中耗尽。Loom 想解决的就是这一痛点：把 Git 当作文件系统，把 Loom 当作"空中交通管制"。

核心思路：把冲突尽量前置

Loom 的核心赌注是「Git 在 token 花完之后才报告冲突，Loom 在 token 花之前就报告」。它围绕四个机制构建：

• 隔离：每个任务分配独立的 Git worktree，两个线程物理上无法互相覆盖对方编辑。
• 协调：开始编辑前，线程先声明一个 intent lease（机器可读的 goal + 文件 glob），重叠在声明阶段就发出警告，智能体可通过 MCP 自助切分工作面，无需人类把关。
• 集成：主线（fabric）只在 verify 通过且获得人类/同意门控后才推进，若 fabric 与线程同时改动同一文件，落地会被拒并提示"fabric 在你下面动过了——请 rebase"，从而保证主线永不出现红色状态。
• 恢复：智能体中途崩溃后，其线程会变成 orphan，附带 goal、验收标准和数秒前的 checkpoint，可被任意新会话认领，避免出现无人负责的脏 worktree。

Loom 明确表示它并不适合所有场景：不替代 Git、也不适合 N 个智能体争抢同一任务的"赛马"场景，那种情况需要 judge/tournament 框架，胜出者再通过 lease 落地。它也不是给慢节奏人类 PR 设计的——Git + GitHub 本身已经足够。

两分钟上手演示

以一个最小可复现的"灾难场景"为例：同一仓库开两个终端，A、B 同时对 greeting.txt 声明 lease 并各自编辑。

• A：loom lease "greet in french" greeting.txt，随后在自己的 worktree 中编辑。
• B：loom lease "greet louder" greeting.txt，Loom 立即返回 "TOE-STEP: 'greet louder' 与 'greet in french' 重叠" 的警告，但仍允许继续，且 B 进入的是另一份 worktree。
• A 先完成 loom stitch && loom propose，verify 通过后落地。
• B 再 propose 时，verify 仍为绿，但落地被拒："fabric moved under you on greeting.txt — rebase the thread and re-propose"。B 通过 loom rebase 合并双方改动后再 propose，即可把 A 的成果纳入而不是抹掉。

如果中途 kill 掉某个会话，loom status 会显示对应线程为 orphan，任意新会话可通过 loom adopt <thread-id> 接手其 goal、验收标准与 worktree，checkpoint 完整保留。

与 MCP 智能体的对接

Loom 通过 MCP 与 Claude Code 或任何兼容客户端集成，一行命令即可接入：claude mcp add loom -- loom mcp。智能体在编辑流程中通常按以下顺序调用工具：

• loom_status —— 查看当前在跑的线程、lease 与 orphan。
• loom_lease —— 声明目标与作用域，返回的 working_dir 即为该线程的 worktree，所有编辑都应 cd 至此目录进行；toe-step 警告也会在同一次响应中带回。
• loom_stitch —— 每隔若干次编辑调用一次，生成 checkpoint 并为 lease 续约。
• loom_propose —— 在一份临时副本中运行 verify，绿则请求人类确认后落地。

按官方说法，Loom 的价值随 writer 数量与编辑频率放大：两个谨慎慢节奏的开发者用不上它，但智能体集群（以及节奏类似的人类）正是它的目标用户。