LaneGate：面向 AI 编码代理的 Git 编排框架

随着 Claude Code、Codex、aider 等 AI 编码代理被越来越多地接入真实项目，多个代理在同一代码库并行修改所带来的冲突与误合并风险也愈发突出。近期在 Hacker News 上亮相的开源工具 LaneGate 给出了一套以 Git 为底座的「工作车道 + 合并闸门」方案：每个工单对应一条独立 git worktree，文件级别的 touches 锁防止代理越权改动，合并前还要经过可配置的守卫与人工审核才能进入主干。

核心思路：工单即真相源

LaneGate 把每个任务建模为仓库内的一份 Markdown 工单（位于 .lanegate/tickets/TICK-xxx.md），用 YAML frontmatter 声明 touches 与 close_criteria。代理通过 lanegate next 领取下一份工单，lanegate start 创建对应 worktree 与分支，完成后调用 lanegate complete 进入评审流程，最终由 lanegate merge 合入 main。工单规格与评审结论默认提交到 Git，因此整套协作状态是仓库原生、可审计的；执行日志、锁与 worktree 则留在本地的 .lanegate/ 目录。

合并前的「守卫」机制

与多数同类工具相比，LaneGate 强调「pre_merge 守卫针对的是合并后的结果，而不是单一分支」：两个工单各自通过校验、合并后却互相破坏的情况，会在这里被拦截——主分支被重置回合并前状态，工单被退回评审阶段，避免在主干留下带病提交。开发者还可以配置自定义脚本、测试或 semgrep、gitleaks、pip-audit 等安全扫描作为 pre/post 钩子。

内置 MCP 与主流代理兼容

工具内置 MCP（Model Context Protocol）支持：执行 lanegate mcp 即可将工单生命周期命令暴露为原生工具，供 Claude、Cursor 等兼容代理直接调用，无需通过 shell。文档中明确列出的兼容执行器包括 Claude Code、Codex、aider，以及可通过 Ollama 接入的本地模型。

安全边界与已知限制

LaneGate 在 README 中坦率列出了当前的能力边界：

• 它提供的是 Git 层面的隔离与 diff 审查，并不在 OS 层沙箱化代理；代理仍以宿主机用户身份运行，拥有完整文件系统与网络权限。
• 文件锁仅在单机单 checkout 内生效，跨机器或跨克隆无法互斥。
• touches 列表是「实践中的协调边界」，不是语义依赖分析：改不同文件仍可能通过共享 API、类型或 schema 互相影响。

官方建议在涉及生产代码的仓库里启用 default_human_review: final，让每一次合并都先经过人工 diff 检查再放行。整体而言，LaneGate 适合那些已经让多个 AI 代理并行跑在本地仓库、又担心「半成品被自动合入」或「两个代理互相覆盖修改」的团队。