GitHub Copilot 把「堆叠会话」和「堆叠 PR」绑在一起:Agent 编码工作流的下一个默认形态

2026 年 7 月 30 日,GitHub 在官方博客介绍了 Copilot App 的新功能「堆叠会话 (Stacked Sessions)」与「堆叠 PR (Stacked Pull Requests)」。这不是简单的多会话支持,而是把会话与 PR 两个层面同时做了「链式」抽象——一个会话接一个会话、一个 PR 接一个 PR,直到落地到主干。

这到底是什么

先理清两个概念:

• 堆叠会话:在同一个仓库里开出一串任务,每个会话可以基于前一个会话的成果继续工作,Plan 模式给出计划,每个会话都是独立可执行的单元。
• 堆叠 PR:一个 PR 链,每个 PR 把目标分支设成上一个 PR 所在的分支,最终形成一个有序的链,最后落地到主干。

过去这两个东西是分离的:你在 IDE 里让 Copilot 跑一长串任务,得自己手动合并上下文;你写 PR 链,得自己手动维护 base 分支。GitHub 现在把它们打通——

「堆叠会话」会自动产出对应的「堆叠 PR」。

Cassidy Williams 的真实改造

GitHub 的开发者关系负责人 Cassidy Williams 写了一篇亲历式的博客,讲她用这套功能改造了一个 2014 年的老个人项目。

这个项目原本用 React 15、Less、react-bootstrap,她过去试过手工现代化,但「太大太乱,榨不出价值」放弃了。这次她把仓库扔进 Copilot App:

1. 第一步:在 Plan 模式里给 Claude Opus 4.8 一段提示词,讲要全拆 Less、考虑 Tailwind、清理无障碍与响应式。模型给了一份计划,然后 GPT-5.5 做 Rubber Duck 复审,几轮来回敲定。
2. 第二步:实际跑出来发现,因为她误把分支从 main 切到了旧的 dev,工作流卡住。她让 Copilot 换分支重做,之前的规划没浪费——系统把她的样式决策原样迁移到 dev 分支。
3. 第三步:改造到一半发现 react-bootstrap 自身引用了过时的 findDOMNode 和 componentWillReceiveProps,她在 Plan 模式里问「拆掉 react-bootstrap 还是升级」,模型建议整库替换。
4. 第四步(关键步骤):她不想把 react-bootstrap 替换混进同一个大 PR 里——这是她明确点名「scope creep」的反模式。她用一句提示词让 Copilot:
   • 把现有工作的 PR 提了;
   • 在这个 PR 之上开一个新的「堆叠会话」,专门做 react-bootstrap 替换,继承之前的上下文;
   • 自动产生一个对应的堆叠 PR 指向原 PR 的分支。

最终屏幕上同时看到三个层叠节点:第一个失败的 PR、成功的 PR、react-bootstrap 替换的草稿 PR。她在博客里写「THIS WAS SO COOL. Stacked sessions and stacked pull requests? Is this the future? YES.」

这个设计为什么重要

从工作流上看,堆叠会话+堆叠 PR 把三件事同时解决了:

• 避免巨型 PR:开发者抗拒 review 数千行的单一 PR,但 AI 编码时代特别容易产生这种 PR。堆叠强制把 PR 按自然边界切片。
• 保留会话上下文:过去每个会话是孤岛,新一轮要重新解释「我要做什么」。堆叠会话自动继承上下文,新会话不需要重新铺垫。
• PR 链自动同步:base 分支关系不需要开发者手动维护,合并一个 PR 自动让下一个 PR 的 base 前移。

对应到 2026 下半年 AI coding 工具的竞争格局,这把 Copilot 从「编辑器插件」往「PR 协作平台」挪了一步。Cursor、Codex CLI、Claude Code 都还在「单会话」层面打转,GitHub 直接在 PR 这个开发者已经熟悉的协作单元上加了 AI 原生抽象。

几个细节

• 覆盖范围:这篇博客面向所有 Copilot 套餐用户,但堆叠 PR 仍是 GitHub 平台的存量功能(原本就有),Copilot App 的堆叠会话是新增。
• 支持的模型:Cassidy 用了 Claude Opus 4.8 + GPT-5.5 Rubber Duck 复审,说明堆叠会话不绑定单一模型,可混用。
• 触发入口:Copilot App 主界面,Plan 模式里给出计划后系统会自动建会话节点。
• 风险点:开发者必须主动要求「把后面的工作做成单独 PR」,否则模型倾向于把所有变更塞进一个 PR。GitHub 没默认行为,需要提示工程配合。

实际场景的判断

Cassidy 的案例是个人小项目,但她点出的两个反模式——「巨型 PR」「会话上下文丢失」——是所有 AI coding 团队都在踩的坑。堆叠会话+堆叠 PR 不是唯一解法(也有用 git worktree 自己做 PR 链的工具,如 Graphite、Spruce),但 GitHub 的优势是把它做进了官方仓库抽象,不需要第三方集成。

我的判断:这套工作流对「AI 编码 + 长任务」场景是显著的范式转移。下一步看 Cursor、Codex、Claude Code 是否跟进——如果半年内大家都加堆叠抽象,说明 2026 H2 的 AI coding 工具竞争会从「模型谁能跑更长的任务」转向「工作流如何把长任务拆给人类 review」。

参考:

• GitHub 官方博客: https://github.blog/ai-and-ml/github-copilot/stacked-sessions-and-pull-requests-in-the-github-copilot-app
• Copilot App 介绍: https://github.com/features/ai/github-app
• 堆叠 PR 文档: https://gh.io/stacks