多 Agent 写代码，Git 协作流程怎么改

多 Agent 开始提交代码、修复 CI、更新依赖后，团队可能先遇到一个比合并冲突更难处理的问题：代码产出增加了，人工审查能力却没有同步增加。dev.to 的这篇文章结合作者团队的自动化实践，讨论如何调整 Git 协作流程，把工作区隔离、提交纪律和变更来源追踪补齐。

目前能确认什么

作者的判断是，先出问题的是围绕 Git 建立的工作流程。他们团队遇到的麻烦包括：审查积压、修 Bug 时夹带重构、提交信息缺少修改原因，以及多个 Agent 在同一工作区互相干扰。

节选给出的做法很具体：每个 Agent 使用独立的 Git worktree，每项任务使用独立分支。worktree 可以让同一仓库拥有多个工作目录，共享对象存储，但各自操作文件。它能隔离工作现场，却不能消除两个任务同时修改同一模块产生的冲突，任务仍需合理拆分。

提交也要更严格：一次只包含一个逻辑改动，记录任务关联、Agent 身份和验证结果；使用独立的机器人身份，并限制权限、保护共享分支。Git trailers 是提交消息尾部可解析的结构化字段，可以承载这些来源信息。

摘要提到分级审查，但节选恰好在这一部分开头截断，具体分级规则尚不清楚。

我的判断

接入更多 Agent 之前，团队应先明确每类改动由谁审、审到什么程度。

否则，生成速度越快，待审队列越长，大改动越容易被草率放行。工作区隔离解决操作干扰，小提交降低审查和回滚成本，两者都不能替代质量判断。

来源记录也要区分「写了什么」和「证实了什么」。提交里出现验证结果，只代表留下了一项声明；是否关联可检查的 CI 记录，仍需流程保证。

至于哪些改动可以自动放行、敏感模块如何升级审查、谁对最终合并负责，现有节选没有交代。不能据此认定作者已经提供了一套完整的自动审批方案。