1. Agent 让“大 PR”问题变得更严重了#

传统人工开发里，一个 PR 变得过大通常是渐进发生的。

你先改一个模块，再发现接口要调整，再补几个测试，最后 UI 也跟着改。

等准备提交时才发现：

1
26 files changed
2
+1847 / -612

Coding Agent 不一样。

它可以在一轮任务里极快地完成跨层修改：

1
需求分析
2
  ↓
3
搜索仓库
4
  ↓
5
改 schema
6
  ↓
7
改 API
8
  ↓
9
改 service
10
  ↓
11
改 UI
12
  ↓
13
补 test
14
  ↓
15
跑 lint / build

从 Agent 视角看，这是一条连续任务链。

从 Reviewer 视角看，却可能是六个不同的评审问题被压进同一个 diff。

例如一个“给聊天应用增加商品搜索”的任务，可能同时包含：

• 数据模型；
• seed data；
• API validation；
• search endpoint；
• chat grounding；
• loading / empty / error states；
• 产品引用卡片 UI。

这些内容虽然都属于同一个 Feature，但它们并不属于同一个认知单元。

因此真正的问题不是：

1
Agent 有没有完成整个 feature？

而是：

1
Reviewer 能不能在有限注意力里证明每个变化都正确？

2. Code Review 的瓶颈是“认知工作集”#

Review 一个 PR 并不是逐行检查代码有没有语法错误。

真正困难的是 Reviewer 需要在脑内建立一个临时模型：

1
旧系统怎么工作？
2
这次为什么改？
3
有哪些新增状态？
4
数据从哪里来？
5
接口契约变了吗？
6
异常路径是什么？
7
测试覆盖了什么？
8
有没有引入跨模块副作用？

PR 越大，这个临时模型越难维持。

可以把它理解成一种 review working set。

如果一个 PR 同时要求 Reviewer 记住：

1
数据库 schema
2
+ API 参数校验
3
+ service abstraction
4
+ React state
5
+ cache invalidation
6
+ Playwright 测试

那不是“多看几行代码”的问题，而是 Reviewer 必须不断在不同抽象层之间切换。

这也是为什么 1000 行改动不一定只是 100 行改动的十倍评审成本。

认知切换会让成本非线性上升。

3. Stacked PR 的核心不是“多个 PR”，而是依赖结构显式化#

Stacked PR 经常被简单理解成：

把一个大 PR 拆成几个小 PR。

这还不够准确。

真正关键的是：这些 PR 之间有明确顺序和依赖关系。

例如：

1
main
2
 ↓
3
L1: feat/catalog-data
4
 ↓
5
L2: feat/search-api
6
 ↓
7
L3: feat/chat-grounding
8
 ↓
9
L4: feat/grounded-ui

这里每一层都不是独立平行分支。

L2 依赖 L1，L3 依赖 L2，L4 依赖 L3。

于是整个 Feature 被重新表示成：

1
Feature = 一条可验证的依赖链

而不是：

1
Feature = 一个巨大 diff

这对 Coding Agent 特别重要，因为 Agent 本身非常擅长做依赖分析和任务分解。

4. 为什么 Agent 比人更适合维护 Stack？#

过去很多团队不愿意用 stacked PR，并不是因为不知道“小 PR 更好”，而是因为维护起来麻烦。

传统人工流程里需要不断处理：

1
branch A 更新
2
→ branch B 要 rebase
3
→ branch C 又依赖 B
4
→ review 修复进入 A
5
→ 后面全部同步

于是很容易变成：

1
review 更轻松
2
但 branch management 更痛苦

Coding Agent 恰好能吃掉这一类机械成本。

它可以负责：

• 维护依赖顺序；
• 自动 rebase / restack；
• 检查每层 CI；
• 根据底层 review 修改同步后续层；
• 更新 PR description；
• 重新跑受影响测试；
• 提醒 stack 中哪一层变得 stale。

换句话说，人类真正不擅长的 stacked PR 运维，反而正好是 Agent 很擅长的确定性工作。

所以 Agent 并不是让 stacked PR 过时，而可能让 stacked PR 第一次真正变得低成本。

5. 一个更适合 Agent 的任务分解方式#

我不会直接告诉 Agent：

1
实现完整商品搜索功能

然后期待它最后自动生成一个漂亮 PR。

更可靠的 Harness 应该先要求生成 change graph。

例如：

1
Goal: 商品搜索
2

3
Dependency graph:
4

5
Data model
6
  ↓
7
Search service
8
  ↓
9
API endpoint
10
  ↓
11
Chat integration
12
  ↓
13
UI citation state

然后再根据几个规则决定是否应该拆层。

1
Data owner → L1
2
Backend owner → L2
3
Frontend owner → L3/L4

1
L1 → unit test / schema validation
2
L2 → API contract test
3
L3 → integration test
4
L4 → browser / visual test

1
PR 越小越好

1
每个 PR 恰好对应一个可独立理解的 change unit

6. 我更关心“Review Surface”，而不是 LOC#

传统 PR 规模经常用 lines changed 衡量。

例如：

1
small < 200 LOC
2
medium < 500 LOC
3
large > 1000 LOC

但 Agent 时代我更想引入一个概念：

Review Surface。

它不只是行数，而是 Reviewer 需要同时理解多少种变化。

例如两个 PR 都是 400 行。

PR A：

1
新增一个独立 parser
2
+ parser unit tests

PR B：

1
改数据库字段
2
+ 改 API
3
+ 改 auth
4
+ 改 UI
5
+ 改缓存策略

它们的 LOC 相近，但评审难度完全不同。

可以粗略把 review surface 表示成：

1
Review Surface
2
≈ changed modules
3
× abstraction layers
4
× behavior paths
5
× ownership boundaries

这不是严格数学公式，但比单看 LOC 更接近现实。

7. Coding Agent 的任务成功率应该把“可评审性”算进去#

现在很多 Agent benchmark 只判断：

1
tests passed ?

或者：

1
issue resolved ?

但企业实际采用 Agent 时，还有一个关键指标：

1
这个 patch 是否容易被安全地接受？

我会增加几项指标。

1
Agent A：一次写 1800 行，测试全绿
2
Agent B：拆成 4 层，每层验证清晰

8. Stack 中每一层都应该有自己的 CI Gate#

Stacked PR 最大的风险之一，是大家把所有验证都推到最顶层。

这样底层 PR 看起来虽然小，但并不能证明自身正确。

更合理的是：

1
L1
2
  → unit tests
3
  → type check
4
  → schema validation
5

6
L2
7
  → inherited L1
8
  → API contract tests
9

10
L3
11
  → inherited L2
12
  → integration tests
13

14
L4
15
  → inherited L3
16
  → Playwright / visual verification

这里一个非常重要的原则是：

每层负责证明自己新增的风险。

底层已经验证过的事实，不需要 Reviewer 在每一层重新从零证明。

这也是 stack 能降低认知成本的原因。

9. Review 顺序为什么通常应该 bottom-up？#

GitHub 的官方文章提到一个很实用的阅读方式：可以先从 Stack 顶部理解最终目标，但具体 Review 应该从底层往上。

原因很简单。

假设：

1
L4 UI
2
依赖 L3 chat integration
3
依赖 L2 API
4
依赖 L1 data model

如果 L1 的数据模型设计就是错的，那么直接 Review L4 的 UI 细节价值有限。

底层稳定以后，上层的语义才有可靠基础。

因此更合理的流程是：

1
先理解 top-level intent
2
       ↓
3
Review L1
4
       ↓
5
Review L2
6
       ↓
7
Review L3
8
       ↓
9
Review L4

对于 Agent 生成的改动，这一点更关键。

Agent 很可能在最初错误假设上继续构建大量后续代码。

越早在底层阻断错误，浪费越少。

10. Agent 应该什么时候自动拆 Stack？#

不是所有任务都值得 stacked PR。

我会给 Harness 设置一些触发条件。

例如满足任意两三项时自动进入 decomposition mode：

1
changed files > 10
2
estimated diff > 500 LOC
3
跨越 3 个以上目录
4
涉及 DB + API + UI
5
需要多个 reviewer ownership
6
存在明确依赖链
7
预计任务时间 > 30 min

然后 Agent 输出：

1
Proposed stack:
2
L1: foundation
3
L2: backend behavior
4
L3: integration
5
L4: UI

由人或 policy 选择是否接受。

这比等 PR 已经膨胀到 2000 行再人工要求“请拆一下”高效得多。

11. Stack 不是 Micro-PR 狂热#

有一种错误实践是：

1
一个函数一个 PR
2
一个类型一个 PR
3
一个测试一个 PR

这样会让依赖链变得比代码本身还复杂。

正确拆分应该满足一个基本条件：

每层都能够用一句话解释“为什么它自己就是一个完整的变化”。

例如：

1
L1: 建立商品数据模型与查询接口
2
L2: 暴露搜索 API 并完成参数校验
3
L3: 让 Chat 基于真实搜索结果生成回答
4
L4: 增加引用卡片与错误状态 UI

每一句都对应一个明确的行为边界。

如果你无法描述某层的独立价值，它可能只是机械切片，而不是工程切片。

12. 对 Agent 来说，Stack 还是一种 Context Management#

这个角度我认为特别值得重视。

如果 Agent 一次处理整个 2000 行 Feature，它自己的上下文也会越来越脏：

1
数据库决策
2
+ API schema
3
+ UI state
4
+ 测试日志
5
+ review feedback
6
+ browser output

而 stacked workflow 可以天然帮助 Agent 分隔工作集。

例如：

1
L1 Agent context
2
只关注 data layer
3

4
L2 Agent context
5
继承 L1 contract
6
但不需要保留 L1 的所有探索日志
7

8
L3 Agent context
9
只需要 API contract + chat code

这和 subagent / context pruning 的逻辑非常接近。

所以 stacked PR 不只是 Git 分支管理技巧，也可以成为 Agent context boundary。

13. 一个我会采用的 Coding Agent Stack Harness#

如果自己设计，我会把流程做成：

1
User Goal
2
   ↓
3
Repository Analysis
4
   ↓
5
Change Graph
6
   ↓
7
Stack Planner
8
   ↓
9
┌──────────────┐
10
│ L1 Executor  │ → verify → commit
11
└──────┬───────┘
12
       ↓
13
┌──────────────┐
14
│ L2 Executor  │ → verify → commit
15
└──────┬───────┘
16
       ↓
17
┌──────────────┐
18
│ L3 Executor  │ → verify → commit
19
└──────┬───────┘
20
       ↓
21
Stack Submit
22
   ↓
23
Human Review Bottom-up

每一层 Agent 都只拿：

1
原始 goal
2
+ 当前 layer specification
3
+ 上一层的稳定 contract
4
+ 当前相关代码

而不是完整保留所有历史工具结果。

这会明显减少 context drift。

14. 怎么做一次 A/B 实验？#

如果你团队已经在用 Coding Agent，可以选 10 个真实中型 Feature 做对照。

1
总 diff
2
CI failure 次数
3
review time
4
review comments
5
返工次数
6
最终 merge 时间

1
每层 diff
2
每层 CI
3
底层修改传播次数
4
review time
5
总 merge time

1
Time to first review
2
P50 review duration
3
P90 review duration
4
Reviewer correction rate
5
Total human attention time

15. 真正应该优化的是 Accepted Change Throughput#

Coding Agent 很容易让团队关注一个危险指标：

1
Generated LOC / day

这个指标几乎必然会暴涨。

但组织真正想要的是：

1
被验证、被接受、能安全上线的变化数量

也就是我更愿意叫：

Accepted Change Throughput。

可以粗略表示成：

1
Generated Changes
2
× Verification Quality
3
× Reviewability
4
× Acceptance Rate

如果生成速度提高 5 倍，但 Reviewability 降低一半、返工率翻倍，最终收益不会有想象中那么大。

Stacked PR 的价值，就在于它不是提高“写代码速度”，而是在修复 Agent 时代最容易被忽略的后半段吞吐。

16. 一个适合个人项目的轻量版本#

个人开发者没有多个 reviewer，也不一定需要完整 gh stack 流程。

但仍然可以借鉴同样的设计。

例如一个较大 Feature，先让 Agent按顺序做：

1
Commit 1: data / types
2
Commit 2: core behavior
3
Commit 3: UI
4
Commit 4: tests / polish

每个 commit 都保持：

1
可构建
2
可验证
3
说明清楚

即使最终只提交一个 PR，review / rollback / bisect 都会轻松很多。

所以 stacked thinking 的价值并不依赖团队规模。

17. 我对 Agent-native Git 工作流的判断#

过去 Git 工作流主要是围绕“人写代码”设计的。

Agent 时代会逐渐出现新的基础动作：

1
Task decomposition
2
Dependency graph
3
Layered branch creation
4
Automated restack
5
Per-layer CI
6
Review-aware context
7
Change propagation

这些动作很可能最终会成为 Coding Agent Harness 的标准能力。

模型只负责生成代码还不够。

真正成熟的 Agent 应该知道：

1
这次改动是不是太大？
2
应该怎样拆？
3
哪些改动属于同一风险边界？
4
哪一层应该先验证？
5
review feedback 应该影响后面哪些层？

这才是从“AI code generator”进入“AI software engineer”真正需要的工程能力。

结语#

Coding Agent 的最大优势，是能够极快地跨越仓库完成复杂修改。

它最大的风险，也来自同一个地方：它太容易一次做太多。

当生成代码不再昂贵以后，下一阶段真正稀缺的资源会变成：

1
Reviewer attention
2
Verification bandwidth
3
Change isolation
4
Trust

Stacked PR 的意义不是回到“慢慢写代码”，而是让高速生成的改动重新获得清晰结构。

所以以后我判断一个 Coding Agent 是否成熟，不会只看它能不能一次完成 2000 行 Feature。

我更关心：

它能不能主动把一个大任务拆成一组有依赖顺序、每层可独立验证、可被人类快速理解的变化？

当 Agent 开始优化这个问题时，AI Coding 才真正开始进入团队工程效率，而不只是代码生成速度比赛。

参考资料#

• GitHub Engineering — Turn one giant AI-generated pull request to a reviewable stack, 2026-08-04: https://github.blog/engineering/turn-one-giant-ai-generated-pull-request-to-a-reviewable-stack/
• GitHub Docs / GitHub CLI — stacked pull request 与 gh stack 相关官方资料
• GitHub Changelog — Copilot CLI 近期 subagent / task management 与 agent workflow 更新

本文中的 Review Surface、Accepted Change Throughput、自动拆层触发条件与 Harness 结构属于基于 GitHub 官方 stacked PR 机制做出的工程分析，并非 GitHub 官方 benchmark 或强制实践。文中没有虚构团队性能数据。