最近我让三个 Claude Code 同时干活。一个修 bug一个写新功能一个帮我整理文档。然后他们就打起来了。不是真的打架是 Git 层面的那种打架——文件冲突、脏工作区、commit 历史变成一坨巨大的屎。我和你们一样一开始觉得这根本不是问题。AI 写代码嘛一回开一个终端跑完一个 Agent 再跑下一个排队来呗能有什么冲突但你想过没有。当你真的把 Agent 当成团队成员来用的时候它就一定会产生团队协作才有的问题。而我们的版本控制工具Git在设计之初就没想过未来会有 AI agent 这种东西。这篇文章就是我在这个坑里滚了半个月之后总结出来的一套东西。Git 在 Agent 时代破了四个大洞第一个洞Git 只记结果不记想法Git commit 能精确告诉你「改了什么」但从来不告诉你「为什么这么改」。人类工程师至少会在 commit message 里解释一下背景。但 agent 不会。它可能跨了十几个模块探索、试错、改写、回滚最后留下一个看起来合理但你根本不知道它脑子里怎么想出来的 diff。更恐怖的是 agent 的两个极端提交习惯要么一个 commit 塞几千行。功能、测试、重构、格式化、文档全混在一起。reviewer 看一眼就想吐。要么碎片化到令人发指。fix typo、update file、try again……commit 历史变成了流水账零语义价值。这两种都不行。第二个洞脏工作区像垃圾场Agent 的探索过程比人类快太多。未提交的临时文件、格式化变更、测试 fixture、调试代码和真实的业务修改全混在一起。你可能遇到过这种场景agent 跑了一个下午你回来看工作区一个git status刷出 40 个文件。哪个是核心变更哪个是副作用哪个是 agent 瞎折腾出来的临时文件根本看不出来。而且更致命的——多个 agent 如果在同一个工作目录里跑它们会互相踩到对方的改动。你以为 agent A 在修 bugagent B 在写测试井水不犯河水。结果 agent A 顺手改了某个共享 utilagent B 也改了同一个文件然后你的代码就变成了薛定谔的正确。第三个洞合并没有冲突 ≠ 能跑Git 的 merge 是文本层面的——只要没有行级冲突就认为合并成功。但 agent 不这么思考。一个 agent 改了某个接口的语义另一个 agent 同时在旧语义下新增了调用点。两个 branch 各自通过测试合并的时候 Git 说「没冲突搞定」。然后服务就挂了。这就好比两个人同时改一个房子的水电图。一个人把水管改粗了另一个人在旧尺寸上定做了接头。图纸上看不出来冲突但装上去就漏水。多 agent 并发的时候这种情况比单 agent 开发高出一个数量级。第四个洞巨型提交让排查形同虚设你的服务出了 bug。非常熟练地跑了一个git bisect二分搜索定位到了问题 commit。然后你发现这个 commit 改了 40 个文件1500 行 diff。你 bisect 了个寂寞。这就是 agent 一次性产出巨型 diff 的死循环审查质量急剧下降 → 出问题很难回滚 →git revert会撤掉太多无关改动 →git bisect定位到了也排查不完。五件事让你的 Agent 协作不打架我翻了 TRAE 技术团队写的一篇长文然后结合自己这半个月的实际踩坑总结出五件「只要你做了就立刻见效」的事。第一件事让你的 Agent 写「带身份证」的 commit每个 commit 必须包含三个 trailerAgent-Task: PROJ-234 - Add refresh token support to auth service Agent-Model: claude-opus-4-6 Agent-Decision: Used 7-day sliding window over fixed expiry for better UX这三个字段的意思分别是Agent-Task这段代码是哪个任务产生的能追溯到原始 promptAgent-Model用的哪个模型不同模型的质量天差地别出问题才知道哪个模型产的代码需要重点关注Agent-Decisionagent 自己做的关键设计决策及理由这就是 Git 原生的 commit trailer 机制。Signed-off-by、Co-authored-by你知道吧跟那个一样。你可以直接git log --format%(trailers:keyAgent-Task,valueonly)查所有 agent 产生的提交。说人话就是给你的代码做个溯源二维码。哪段代码、哪个 agent、用的什么 prompt、做了什么决策——一条链路清清楚楚。第二件事Checkpoint Commit——打存档你玩过单机游戏吧打 BOSS 之前先存个档这不用我教。Agent 干长任务也是这个道理。在完成关键节点的时候做一个检查点提交完成数据模型/接口定义 → commit完成核心逻辑实现 → commit完成测试编写 → commit完成文档更新 → commit每个 checkpoint 以[WIP]开头。好处太明显了任务中断了可以从最近的 checkpoint 恢复不用从头再来。reviewer 也可以分段审查每个 commit 就是一个可理解的语义单元。最后开 PR 之前用git rebase -i把这些[WIP]commit 整理成干净的 atomic commit。这件事 agent 自己也能做。直接甩给它这句话帮我整理当前分支的提交历史。分析哪些 [WIP] commit 属于同一个逻辑变更给出一份整理方案确认后执行 rebase。第三件事git worktree——一人一间房这是最硬核的一条也是解决「多 agent 互相踩」问题的最彻底手段。git worktree add ../agent-task-234 -b agent/PROJ-234-refresh-token git worktree add ../agent-task-301 -b agent/PROJ-301-pg-migration一个 agent 一个 worktree。每个 agent 有自己独立的工作目录不会互相干扰工作区状态。但它们共享同一个.git目录分支管理还是统一的。不是多个 clone。多个 clone 的问题是你要维护多个独立的.git目录push/pull 的时候容易出岔子。worktree 共享一个.git轻量、干净、零运维负担。在多 agent 编排脚本里给每个子任务指定工作目录参数指向对应 worktree 路径就行。agent 完成跑路之后git worktree remove ../agent-task-234干净利落。第四件事AGENT.md——Agent 的「员工手册」你公司有员工手册吧Agent 也要有。在项目根目录放一个AGENT.mdagent 每次启动都会读取。把你的 Git 规范写进去它就会遵守。最低成本让规范生效的方式没有之一。里面至少要有这些东西分支命名规则agent/task-id-description绝对不能直接 push maincommit 必须包含 Agent-Task、Agent-Decision trailer不能提交的东西API key、.env、node_modules、大二进制文件超过 15 分钟的任务要做 checkpoint commitPR 必须用指定的模板我后面会放一个完整的可以直接用的版本。第五件事PR 模板——人机交接的界面人类 reviewer 面对 agent 写的代码最大的痛苦是什么不知道 agent 在想什么。所以 agent 开 PR 的时候必须填写以下内容## Task Description ## Key Design Decisionsagent 做的关键设计决策及理由 ## Alternatives Considered考虑过但没采用的方案 ## Known Limitations / Follow-up Tasks ## Review Guidance建议 reviewer 重点看哪里这不是给 agent 增加负担是给人类 reviewer 省命。两个新玩具jj 和 GitButler如果你觉得上面这些东西都是「在 Git 的旧衣服上打补丁」那下面这两个工具可能会让你眼前一亮。它们都不替换 Git底层用的还是 Git 仓库跟 GitHub、GitLab、现有 CI 完全兼容。Jujutsujj它把你工作区本身当成了一个 commitjj 最骚的地方是你的工作区永远是已提交状态。不需要git add不需要git commit。你改代码的那一刻它就自动是一个 commit 了。这有什么好处agent 的探索过程自动被记录不存在「未提交的临时文件丢失」的风险。而且 jj 有一个叫 change ID 的东西——不管你反复改同一个变更多少次change ID 始终不变。相当于 GitHub PR 的编号和具体 commit SHA 的关系。还有jj split如果你的 agent 把 bugfix 和格式化改动混在了一个工作区里jj split打开交互式编辑器让你选哪些 hunk 归第一个 commit剩下的自动成第二个。还有jj op undo撤销任意操作。整个工作流的无限 undo。GitButler先干活再分类GitButler 的核心叫虚拟分支Virtual Branches。传统 Git 是「先切分支再做事」。GitButler 是「先做事再分类」——你直接改文件然后按 hunk 粒度把变更分配给不同分支。多 agent 场景下每个 agent 绑定一个虚拟分支它们甚至可以在同一个工作目录里跑GitButler 自动把变更归类。直接拿走一个开箱即用的 AGENTS.md上面这些坑我都踩过。commit 历史乱成一锅粥、两个 Agent 互相踩对方的文件、reviewer 看着巨型 PR 骂娘、git bisect定位到问题 commit 但里面是个大杂烩……每一条都是真实的血泪。所以我把这些规范直接写成了一份 AGENTS.md。你只需要把这个文件丢到项目根目录。Agent 每次启动都会自动读取然后就会按照分支命名规则切分支、每个 commit 带 Agent-Task trailer、15 分钟以上的任务自动做 checkpoint commit、开 PR 的时候填完整模板。不需要配什么复杂的东西。就一个 Markdown 文件复制粘贴你的 Agent 协作范式就切过来了。AGENTS.md 下载地址AGENTS.md说人话就是——以前你的 Agent 是散兵游勇有了这个文件它们就是一个能打配合的团队。写在最后说实话上面这些规范和方法与其说是给 agent 的不如说是给我们自己的。Agent 可以写代码但它不会天然理解什么叫「干净的提交历史」什么叫「可回滚的变更」什么叫「未来的你会感谢现在的你」。这些东西以前是靠工程师的经验和团队文化在维持。但在 agentic coding 里它们必须被写下来、工具化、自动化。核心就三点隔离。一个 agent 一个 worktree独立的工作空间。透明。每个 commit 都知道是谁、用什么 prompt、为什么这么改。自动化。用 CI、hook、模板守住质量底线不靠人的自觉。Git 不会因为 agent 而终结。但 Git 的使用纪律确实被逼到了一个前所未有的高度。以上既然看到这里了如果觉得不错随手点个赞、在看、转发三连吧如果想第一时间收到推送也可以给我个星标⭐谢谢你看我的文章我们下次再见。