Copilot上线堆叠会话与PR

GitHub 把 Agent 的多任务开发正式搬进 PR 流程

GitHub 在 2026 年 7 月 30 日为 GitHub Copilot app 引入堆叠会话，并宣布堆叠拉取请求进入公开预览。两项能力组合起来后，开发者可以让多个 Copilot Agent 分别处理代码库中的不同任务，再把存在依赖关系的修改组织成一组有顺序的 PR，而不是等一个大任务全部完成后才提交一份难以审查的巨型变更。

堆叠会话是指多个 Agent 会话分别运行在独立 Git 工作树和分支中，同时允许后续会话建立在前一项工作的基础上。它解决的是 Agent 如何拆任务、隔离上下文和并行执行的问题。

堆叠 PR 是指一组按照依赖关系排列的拉取请求，其中后一个 PR 基于前一个分支，而不是全部直接指向主分支。它解决的是多项相关改动如何分批审查、持续集成和合并的问题。

这不是一次模型能力升级，而是一次工程组织能力升级。GitHub 没有公布新的代码生成跑分，也没有声称单个任务的生成速度提高了多少；真正的变化在于，Copilot 开始接管过去需要开发者手动维护的分支、工作树、提交、PR 依赖和 CI 状态，让编程 Agent 从“帮我完成这件事”走向“同时推进这几件事”。

堆叠不是把几个 PR 放进同一个列表

堆叠 PR 的核心价值是把一项大型改造切成多个可独立理解、但有明确先后关系的小型变更。假设团队要把一个旧项目从自建身份认证迁移到统一认证框架，完整任务可能同时涉及底层接口、服务端适配、数据迁移、前端登录流程和测试更新。

传统做法通常会走向两个极端。第一种是把全部修改塞进一个 PR，最终出现几十个文件和数千行差异，审查者很难区分架构调整、机械替换与业务逻辑变化；第二种是人工维护多个相互依赖的分支，开发者要反复变基、更新目标分支并提醒审查者按照正确顺序查看。

堆叠 PR 把这项改造表达成一条依赖链，例如：

1. PR 1：定义新的认证接口和公共类型。
2. PR 2：基于 PR 1 接入服务端认证逻辑。
3. PR 3：基于 PR 2 修改前端登录流程。
4. PR 4：基于前述改动补充迁移脚本和端到端测试。

每个 PR 都可以只讨论一个相对清晰的问题，而整组 PR 又保留完整的演进顺序。审查者不必在一份巨型差异中寻找逻辑边界，Agent 也不必把整个代码库改造塞进一个持续膨胀的上下文窗口。

GitHub 此次更新的重要之处在于，堆叠结构不再只是少数高熟练度团队依靠命令行和约定维护的工作流。堆叠 PR 进入 GitHub 公开预览后，分支依赖、PR 审查和合并流程开始成为平台原生对象；Copilot app 则进一步把 Agent 会话和这些对象连接起来。

多会话并行，终于不等于多开几个聊天窗口

GitHub Copilot app 是一个面向 Agent 驱动开发的桌面应用，它把任务分配、代码修改、PR 生命周期和 GitHub 仓库操作集中到同一个工作区。按照 GitHub Copilot app 官方文档，每个并行会话都有专用的 Git 工作树和分支，因此多个 Agent 不会直接在同一个本地目录中争抢未提交文件。

独立工作树是这套并行机制真正有用的技术基础。普通聊天窗口即使同时打开多个对话，最终仍可能修改同一份工作区；一个 Agent 刚改完依赖文件，另一个 Agent 就可能覆盖它，测试结果也难以对应到准确的代码状态。独立工作树相当于为每名 Agent 分配一张单独的工作台，它们共享同一个仓库历史，却各自拥有隔离的文件状态和分支。

Copilot app 当前提供 3 种会话模式：交互式、计划模式和 Autopilot。交互式模式强调开发者与 Agent 往返协作；计划模式要求 Agent 先给出实施方案，再由用户批准；Autopilot 则允许 Agent 以更高自主性推进任务。开发者还可以为不同会话选择不同模型和推理强度，而不是让所有任务都使用同一种昂贵或缓慢的配置。

这种设计让任务调度开始比单次提示词更重要。修复文案、补充单元测试一类低风险任务，可以交给响应更快的模型；涉及架构边界、并发状态或数据库迁移的任务，则适合使用更强的推理模型，并先在计划模式下确认方案。开发者真正管理的不再是一段长对话，而是一组成本、风险和依赖关系不同的工作单元。

三种工作流的差别，不只是同时开几个 Agent

GitHub 的新方案把独立并行与依赖堆叠放到了同一个工作面上，但两者并不等价。没有代码依赖的任务适合完全并行，例如修复三个互不相关的页面；共享底层接口的任务则适合组成堆栈，先确定基础层，再让上层会话基于它继续工作。

| 工作方式 | 任务隔离 | 依赖管理 | 审查粒度 | CI 与合并 | 成本与适用场景 | |---|---|---|---|---|---| | 单个 Agent、单个 PR | 1 个工作区和分支 | 主要依赖上下文记忆 | 容易形成大型 PR | 通常只跑 1 条完整变更链 | 操作最简单，适合小修复 | | 多个独立 Agent 会话 | 每个会话拥有独立工作树和分支 | 适合无依赖任务，相关改动仍需人工协调 | 可拆成多个平行 PR | 各 PR 独立运行 CI | 吞吐量更高，适合互不影响的任务 | | 堆叠会话与堆叠 PR | 每个会话隔离，同时保留分支继承关系 | 用 PR 顺序表达代码依赖 | 每个 PR 聚焦一个逻辑层 | 需要按依赖顺序验证和合并 | 组织成本更低，适合重构、迁移和大型功能 |

堆叠工作流并不会让所有任务获得线性加速。一个上层 PR 如果依赖尚未稳定的底层接口，Agent 即使提前完成代码，也可能在底层修改后重新适配；四个会话同时运行，也不意味着总工期必然缩短到原来的四分之一。

真正能够并行的是研究、脚手架搭建、测试编写和相互独立的实现工作。真正必须串行的是接口定稿、关键迁移步骤以及依赖前序代码才能验证的集成测试。GitHub 此次更新提高的是任务编排上限，而不是消除软件工程中的客观依赖。

对旧代码库改造尤其有用

旧代码库现代化是堆叠会话最合适的应用场景之一。GitHub 官方博客展示的案例正是使用堆叠会话和 PR 改造旧项目，因为这类工程通常包含大量机械变更，也夹杂少量风险很高的语义调整。

大型升级最怕把不同性质的改动混在一起。以升级前端框架为例，依赖版本调整、配置格式迁移、组件 API 替换、状态管理重构和快照更新可以分别交给不同会话；其中纯机械替换可以并行推进，基础配置与公共组件则组成堆栈，避免上层任务基于错误的接口假设继续生成代码。

小型 PR 也更适合人类发现 Agent 的系统性错误。如果 Agent 在公共类型中误解了一个可空字段，审查者可以在堆栈底部立即拦截，而不是等这项误解扩散到几十个调用点后，再从一个庞大 PR 中逐一回滚。

这套机制同样适合测试先行的任务拆分。一个会话可以补齐现有行为测试，第二个会话修改底层实现，第三个会话处理上层调用；只要分支依赖清楚，团队就能看到每一步究竟改变了什么，而不是只得到 Agent 声称“测试已经通过”的最终结果。

Agent 的瓶颈从写代码转向审代码

并行 Agent 会显著增加待审查变更的产生速度。过去一名开发者可能一次只维护 1 个主要任务，现在可以同时启动 3 个甚至更多会话，但人类理解业务约束、验证风险和批准合并的速度不会同步增长。

堆叠 PR 缓解了审查压力，却没有消除审查责任。它把一份难以阅读的大变更拆成若干小变更，使问题更容易定位；与此同时，审查者仍然需要理解整条堆栈的最终状态，特别是跨 PR 才出现的权限漏洞、事务边界和性能回退。

CI 资源也可能成为新的隐性成本。多个 PR 如果分别触发完整测试套件，同一组基础代码可能被重复构建和验证；堆栈底部一旦变化，上层 PR 又可能需要重新运行检查。GitHub 此次公告没有提供 CI 用量下降、任务延迟缩短或 Agent 吞吐量提升的统一数字，因此不能把“支持并行”直接解读成“开发效率按会话数倍增”。

价格方面，GitHub 没有在此次公开预览公告中给出堆叠 PR 的单独收费标准，也没有公布堆叠会话对应的新增固定费用。实际使用成本仍会受到 Copilot 订阅方案、所选模型、推理强度、AI credits 消耗以及 GitHub Actions 工作量影响，团队在扩大并发前应先观察单位任务的会话消耗与 CI 次数。

云端 Agent 与本地 Agent 的边界更加清楚

Copilot 云代理是在 GitHub Actions 驱动的临时环境中自主执行开发任务的 Agent。根据 GitHub Copilot 云代理文档，它可以研究仓库、制定计划、创建分支、修改代码、运行测试并选择创建 PR，每一步还能通过提交和日志被团队查看。

IDE 里的 Agent 模式则更像坐在开发者身边操作当前工作区。它适合高频、同步、需要即时反馈的本地修改，但分支创建、推送、PR 描述和团队协作往往仍需要额外操作。Copilot app 加上堆叠 PR 后，GitHub 正试图把这些分散步骤收进一个以任务和 PR 为中心的控制台。

这种变化意味着 IDE 不再是 Agent 工作流唯一的中心。开发者可以在本地处理需要亲自调试的核心逻辑，同时让后台会话补测试、整理类型、升级依赖或修复相邻模块，最后在 GitHub 的 PR 层统一审查结果。

GitHub 真正想做的是 Agent 调度台

GitHub Copilot 的竞争重点正在从代码补全质量转向开发流程控制权。模型生成一段函数已经很难形成长期壁垒，谁能可靠地连接仓库上下文、任务系统、分支、CI、代码审查和权限体系，谁才更有机会成为团队默认的 Agent 入口。

GitHub 在这一层拥有天然优势。仓库、Issue、分支、PR、Actions 和团队权限本来就在 GitHub 上，Copilot app 不需要重新发明一套项目状态，也不需要依赖开发者手动把上下文复制到聊天窗口。其代价则是工作流会更深地绑定 GitHub 的平台对象，使用其他代码托管和 CI 系统的团队未必能获得同样完整的体验。

堆叠 PR 也不是 GitHub 发明的新概念。长期维护大型代码库的团队早已使用 stacked diffs 或 stacked changes 缩小审查单元，真正的新意是 GitHub 将其原生化，并让 Copilot Agent 直接参与堆栈的创建和推进。原本偏高手向的分支管理技巧，正在变成普通开发者可以通过图形界面使用的默认能力。

现在值得用，但不值得全自动合并

堆叠会话与堆叠 PR 是目前 Agent 编程产品中更接近真实团队开发的一次更新。它没有用新的模型跑分吸引注意，而是承认软件开发的关键难题从来不只是生成代码，还包括拆分任务、表达依赖、保留过程、运行验证和控制合并风险。

公开预览阶段最值得尝试的是边界明确的中型任务。依赖升级、测试补齐、旧接口迁移、跨目录重构和多阶段功能开发，都能较好体现堆叠的价值；涉及生产数据删除、权限系统重写或不可逆迁移的任务，则不应因为 Agent 能并行工作就降低人工审批标准。

团队还需要为并行 Agent 建立新的容量限制。与其一次启动十几个任务并制造审查积压，不如限制活跃堆栈数量，为每个堆栈指定负责人，并要求底层 PR 通过审查后再扩大上层实现。Agent 的并发能力越强，任务队列和合并纪律就越重要。

GitHub 此次更新释放出的信号很明确：下一阶段的编程 Agent 不再只比较谁写得更快，而要比较谁能同时推进更多工作，又不把代码库变成无法审查的混乱现场。堆叠会话负责提高产出吞吐量，堆叠 PR 负责维持变更秩序；两者合在一起，才是 Agent 从结对助手走向开发调度系统的关键一步。

参考来源

• GitHub Copilot 官方产品页：介绍 Copilot 在 GitHub、IDE、CLI 与 Agent 工作区中的整体能力。
• GitHub Copilot app 官方文档：说明并行工作区、3 种会话模式、模型选择与 PR 生命周期管理。
• GitHub Copilot 云代理官方文档：说明云代理的运行环境、任务流程，以及它与 IDE Agent 模式的区别。