基于Git的AI编码代理协调层
Loom是一个构建在Git之上的协调层,专为多个AI编码代理同时工作而设计。它通过工作树隔离、意图租赁和集成验证门来防止冲突,确保代理不会互相覆盖文件,并在出现重叠时提前警告。适用于代理集群,但不适用于人类正常PR或单一任务竞赛。
Loom是一个专为多个AI编码代理设计的协调层,基于Git构建,旨在解决代理同时工作时常见的文件覆盖和冲突问题。其核心思想是,在代理开始工作前通过“意图租赁”机制检测潜在冲突,而非等到合并或CI阶段才发现问题。
在没有Loom的情况下,如果两个Claude Code会话同时操作同一个仓库,代理A花费40分钟和约20万token重写src/auth/,代理B则清理登录流程,结果B最后完成,其编辑覆盖了A的工作,测试套件在提交时变红,需要第三个会话花费大量token诊断。而使用Loom时,代理A首先租赁src/auth/**,代理B询问Loom后看到该租赁,自动选择不相交的范围或等待,冲突在开始时通过一次工具调用报告,而不是在预算耗尽后。
Loom为每个任务创建独立的Git工作树,确保两个线程不会物理上覆盖彼此的编辑。代理在编辑前必须声明一个意图租赁,包含机器可读的目标和文件通配符。如果两个租赁重叠,系统会在声明时发出警告,让代理自行调整范围或等待。这种设计使得昂贵的冲突协调从频繁变为罕见。
除了隔离和协调,Loom还提供集成功能。主线仅通过绿色验证和人工审批门前进。当主线和一个线程都修改了同一文件时,系统会拒绝着陆并提示“主线已移动,请变基”,而不是静默覆盖。死代理的线程会变成“孤儿”,附带目标、验收标准和几秒前的检查点,任何其他代理都可以认领并继续工作。
Loom通过Git隐藏引用同步状态,无需额外服务器。它支持多人协作,通过loom sync交换状态。代理可以使用MCP工具与Loom交互,例如申请租赁、提交检查点、提议着陆等。Loom不适用于人类正常PR工作流或多个代理竞争同一任务的情况。它假设每个代理处理不同的任务。
此外,Loom提供了桥接模式来控制Git历史粒度:默认使用squash模式,每个编织一次提交;stitches模式将每个检查点作为提交;both模式则同时保留压缩提交和线程分支。验证是在整个仓库的临时副本中进行的,带有硬超时,红色永远不会着陆。大型文件(超过8MiB)会被跳过,并可以在stitch结果中看到。删除操作被视为一等公民,记录为墓碑。
总之,Loom将冲突检测从事后移到事前,是管理多代理协作的高效工具。它不取代Git,而是作为其上的协调层。