Github 过时了！如何让 20 年前为“人类协作”设计的 Git，适配如今“Agent 编排”驱动的代码爆发
过去二十年，Git 与 GitHub 解决的是同一个问题：
人类如何在同一份代码上协作。
今天，问题换了一个主语。
不是“人类与人类”的协作，而是“人类与一群 Agent”的协作。
当你同时跑三个、五个、十个 Agent：一个修 UI、一个做性能、一个补测试、一个改文档——代码产出从“线性增长”变成“爆发式喷涌”。
这时候你会突然发现：Git 没坏，但 Git 的默认交互范式开始不够用了。
Git 没过时，过时的是我们对 Git 的默认用法
说“Git 过时了”其实是一种情绪表达。
真正过时的是那套默认假设：
- 你在一个工作目录里做一件事
- 你有一个清晰的“正在做的改动”
- 你把改动放进 index
- 你提交一个原子 commit
- 你开一个 PR
这套假设在“一个人 + 一个任务”的年代很优雅。
但在 Agentic workflow 里，你的真实状态更像：
- 同一时刻有多个任务在推进
- 每个任务都跨文件、跨层
- 每个任务都在持续生成新的候选修改
你最常见的痛苦，不是 merge conflict。
而是“我现在到底在改哪件事？这些改动分别属于哪个 Agent？我怎么把它们拆开、组合、审阅、回滚？”
最先崩掉的不是分支，是 index
很多人把 Git 的痛点理解成“分支管理复杂”。
但在多 Agent 并行时，真正先崩的是 index（暂存区）这套交互。
因为 index 的设计隐含了一个前提：
你能把“当前改动”组织成一个清晰的集合。
当改动来自多个 Agent、多个目标、多个速度不同的循环时，index 很快就变成一个垃圾桶：
你不是在“暂存”，你是在“捡碎片”。
于是工程师会用两种方式自救：
- 频繁切分分支
- 或者上 worktree（甚至多 repo 副本）
这两种都能解决隔离，但代价是把“心智负担”从代码转移到了版本控制本身。
AI 时代的版本控制，应该默认支持“并行”
你给我一个很好的素材：这篇微信文章提到 GitButler。
它背后的动机我认为一句话就能概括：
把版本控制从“单线程的人类编辑器”，升级成“多线程的 Agent 调度台”。
这类工具看上去在做 UI，实际上在做一件很硬的事：
把并行工作变成一等公民。
例如文章里提到的三点（我用更工程化的语言翻译一下）：
- 并行分支：同时维持多个“任务上下文”，避免你靠手动 worktree 做隔离
- 堆叠 PR：把一个大目标拆成一串可审阅、可回滚、可重排的依赖链
- 面向 Agent 的元数据：让“这段改动是谁生成的、意图是什么、需要什么验证”可以被机器读懂
堆叠 PR 不是新技术，是在 AI 时代变成了刚需
堆叠 PR（stacked PRs）这套方法并不新。
Graphite 的文章用一个很直观的比喻：像搭乐高一样，先有一个基础分支，再一块一块往上叠，每块都是小 PR。
过去你做 stacked PR，是为了“更快审阅、更快合并”。
现在你做 stacked PR，是为了“让 Agent 的喷涌式产出保持可控”。
因为 Agent 最擅长的不是一次性写对。
它最擅长的是：
快速生成多个候选，然后让你选择、验收、再迭代。
堆叠 PR 的价值恰好在于：
它把“候选集”变成一条可操作的链。
你可以重排、可以删掉中间某一段、可以把上层的工作继续往前推进，而不必等底层完全落地。
GitHub 也在朝“多 Agent 编排”靠近
如果你觉得这只是第三方工具的炒作，可以看看 GitHub 自己在做什么。
GitHub Blog 在 2026-04-01 提到 Copilot CLI 的 /fleet：用一个 orchestrator 把目标拆成多个 work items，并行派发给多个 subagents 执行。
注意这件事的信号意义：
“并行”正在从工程师的手工技巧，变成产品的默认能力。
一旦开发的生产方式变成了 orchestrator + 多 agent，版本控制也必须从“记录人类编辑历史”，变成“管理机器生成变更流”。
让 Git 适配 Agent 编排，你需要的是一套新默认值
我不觉得未来会是“Git 被替代”。
更像是：Git 仍然是底层存储与传输协议，但上层交互需要升级。
如果你现在就想让团队在不换底层的情况下适配 Agent 编排，我建议从四个新默认值开始。
默认一：任务上下文先于分支
分支是实现细节。
你真正需要的是“上下文隔离”：
- 这个变更属于哪个目标
- 属于哪个 agent / 哪个指令
- 对应什么验收标准
当这些信息缺失时，你的 PR 审阅会退化成“看 diff 祈祷”。
默认二：小步提交先于完美提交
在 Agent 时代，完美不是一次性写出来的。
完美是筛选出来的。
所以 commit/PR 的粒度应该更小、更可回滚、更可重排。
堆叠 PR 就是在工程上承认这一点。
默认三：验证是第一等公民
当代码生成变便宜，最贵的是验证。
版本控制系统需要帮助你把验证挂到变更上：
- 这次改动需要跑哪些测试
- 需要哪些 review checklist
- 需要哪些风险扫描
否则你会陷入“改动很多，但没人敢合”的状态。
默认四：机器可读的变更元数据
人类可以靠感觉把事情捋顺。
但当你同时 orchestrate 多个 agent，你需要让系统可读：
- 变更意图
- 依赖关系
- 责任归属
- 可回滚边界
这不是写给人看的注释。
这是给调度系统看的控制面。
结语
Git 的诞生来自一个很现实的工程问题。
今天我们面对的也是同一种现实：
生产方式变了，协作对象变了，默认工作流必须变。
你当然可以继续用“20 年前的人类协作工作流”硬扛。
你也可以把版本控制当作一个“Agent 编排系统的底座”，重新设计它的交互层。
如果说过去的 Git 是为了让人类协作不崩。
那么接下来的版本控制，要解决的是：
让“人类 + 一群 Agent”协作不崩。
参考
- 微信文章：a16z领投GitHub联创新公司GitButler
- GitHub Blog：Run multiple agents at once with /fleet in Copilot CLI（2026-04-01）
- Graphite：How to use stacked PRs to unblock your entire team（stacked PRs 解释与动机）
- Sapling SCM（Meta 的版本控制客户端，强调 stacking 与规模化工作流）
- Git（初始发布 2005-04-07）