GitHub 这次没有只发布一个新的 AI 聊天入口。它把 stacked pull requests 推到公开预览，又在 Copilot App 的案例里展示 stacked sessions 怎样把一个老项目改造拆成连续的会话和 PR。几乎同一时间，Vercel Sandbox 增加了多 Linux 用户和 group 目录。两件事放在一起看，变化很具体：AI 可以并行写更多代码，但团队必须把它重新压回可审查的层、可解释的权限和可回滚的顺序里。
大改动被拆成有顺序的小改动
GitHub 对 stacked pull requests 的定义很直接：一组有顺序的 PR，每一层只承载一段聚焦改动，上一层合并或变更后，上面的层会继续跟随。它给出的入口是 GitHub CLI 扩展：
gh extension install github/gh-stack
这不是把分支管理包装成新名词。关键在评审界面和合并语义。评审者可以只看当前层的 diff，通过 stack map 理解它在整组变更中的位置；准备好时，可以合并整个 stack，也可以只落一部分。GitHub 还说明，已有的 branch protection 和 required checks 仍然约束进入 main 的内容，merge queue 支持会分阶段推出。
Copilot App 的案例补上了工作流细节。一个前端现代化任务先从样式和依赖升级开始，测试中发现 react-bootstrap 迁移会扩大范围，于是新的会话被堆在原有会话之上，形成单独的后续 PR。这个例子有价值，不是因为它证明 agent 能一次性修完老项目，而是因为它承认一次性修不完。AI 写代码后，范围失控会更容易发生，stack 的作用就是把范围重新切小。
并行 agent 需要文件系统隔离
Vercel 的 Sandbox 更新解决的是另一半问题：多个 agent 可以在同一个 Sandbox 里并排运行，但每个 agent 是独立 Linux 用户，有自己的 home 目录；需要协作时再通过 group 打开共享目录。官方示例里的角色很朴素，coder 和 reviewer 不是两个 UI 标签，而是两个系统用户。
这个边界很重要。只靠分支或 PR 栈，仍然无法回答 agent 在执行时能看到哪些文件、能改哪些路径、谁能读临时产物。多用户 Sandbox 把问题推进到操作系统层：默认互不可读写，需要共享时显式加到 group。对于要跑自动修复、审查、测试复现的团队，这比单纯把几个 agent 放到同一容器里可靠得多。
评审瓶颈会转到人
Martin Fowler 网站上的 Rachel Laycock 文章把这个变化说成开发者角色的转移：当 agent 能更快地产生执行结果，稀缺资源会变成人的注意力。文章提到一些工程师会并行运行八个、十个甚至十二个 agent，而瓶颈很快变成谁来分配上下文、判断结果、决定是否继续迭代。
这也是 stacked PR 和 Sandbox 隔离真正该服务的目标。团队不需要把每个 agent 输出都当成同等重要的完整方案，而要把它们变成可以排队、可以拒绝、可以局部合并的工作单元。一个健康流程应该让评审者回答四个问题：这一层的目的是什么，依赖哪一层，测试是否覆盖当前 diff，执行环境有没有越过它该有的目录边界。
今天可以照着做的检查
如果团队已经在用 Copilot、Codex 或自建 coding agent，可以先把流程改成四步。第一，任何超过一个主题的 agent 任务都先拆 stack，禁止把迁移、重构和新功能塞进同一个 PR。第二，每个 PR 层写清楚上一层依赖和本层验收条件。第三，给并行 agent 分独立用户或独立工作区，只有需要交换产物的目录进入共享 group。第四，合并顺序由人决定，不让 agent 自己把上层改动静默重排。
这套做法不会让 AI 生成的代码天然正确。它的价值更低调：当 agent 开始同时推进多个方向时，团队还能看见每一层为什么存在，也能在某一层坏掉时停下来，而不是面对一个难以审查的大 PR。