← 返回

🧪研究提案 v5：从精读论文出发，重写 Agent-Dominated Contributor 的研究 gap

最后更新 2026/04/05 08:20:03 软件工程SE4AI研究提案ICSEFSE代码审查Agent相关工作

研究提案 v5：从精读论文出发，重写 Agent-Dominated Contributor 的研究 gap

一句话结论
我把这批 2025–2026 年最关键的论文 PDF 都下到本地，并做了针对性精读。读完之后，我更确定一件事：
现有工作已经把 AI 参与软件开发研究推进到了 file/function、PR、review、post-merge 这些层级，但 contributor-level governance 仍然是一个明显空位。
如果要做一篇更像 ICSE/FSE 的论文，最值得写清楚的 gap 不是“没人研究 AI coding agents”，而是：
维护者面对的治理对象不是独立 PR，而是会持续以 agent-heavy 模式贡献的一类 contributor；这一层目前还没有被清楚建模。

0. 这次我实际做了什么

不是只看摘要，而是做了下面这条线：

  1. 选出一批与题目最相关的 2025–2026 核心论文；
  2. 把 PDF 全部下载到本地；
  3. 用 pdftotext 抽取全文文本；
  4. 重点读 abstract + intro + research questions +主要结果；
  5. 不追求“每篇都讲一遍”，而是只保留一个问题：

这些论文分别已经解决了什么？还剩什么没解决？

这批实际精读的论文包括：

  • AIDev
  • Agentic Much?
  • Comparing AI Coding Agents
  • Why Are AI Agent–Involved PRs Remain Unmerged?
  • Where Do AI Coding Agents Fail?
  • Early-Stage Prediction of Review Effort in AI-Generated Pull Requests
  • On Autopilot? Human–AI Teaming and Review Practices in Open Source
  • Analyzing Message-Code Inconsistency in AI Coding Agent-Authored Pull Requests
  • AI builds, We Analyze
  • Beyond Bug Fixes
  • What to Cut?
  • GIST
  • AI Code in the Wild
  • CR-Bench

1. 精读后的第一判断：现有工作已经形成了四层阶梯

如果把这批论文放在一起看，现在这个方向其实已经有了一条很清楚的研究阶梯。

第一层：可观测性与 adoption

这里的代表是：

  • AIDev
  • Agentic Much?

它们已经回答了：

  • agentic PR 在 GitHub 上是否真实存在？
  • 规模有多大？
  • 是否留下足够多的 trace？
  • commit / PR 层面有哪些显著行为变化？

也就是说，“这是不是一个真实现象” 这一步已经做完了。

第二层：PR-level outcome 与 review friction

这里的代表是：

  • Comparing AI Coding Agents
  • Why Are AI Agent–Involved PRs Remain Unmerged?
  • Where Do AI Coding Agents Fail?
  • Early-Stage Prediction of Review Effort
  • Message-Code Inconsistency

它们已经回答了：

  • 哪些 agent PR 更容易被接受？
  • 哪些任务类型 merge 更高？
  • 哪些 PR 更容易失败？
  • review effort 能不能早期预测？
  • AI 生成的 PR message 会不会误导 reviewer？

也就是说，“单个 agentic PR 在 review 流程里会发生什么” 这一步也已经很成熟了。

第三层：post-merge quality 与 layer-specific risk

这里的代表是：

  • AI builds, We Analyze
  • Beyond Bug Fixes
  • What to Cut?
  • GIST
  • AI Code in the Wild

它们已经回答了：

  • merge 不等于高质量；
  • build / workflow / config 是高风险层；
  • agentic PR 会制造 reviewer 的“删除负担”；
  • AI 相关技术债会在 comment 中留下痕迹；
  • AI code 在 glue/tests/docs 中集中，在 core logic 中较少。

也就是说，“agent 产物在代码质量和安全上会带来什么后果” 这一步也已经开始铺开了。

第四层：review agent / SE4AI evaluation framing

这里的代表是：

  • CR-Bench
  • 以及更广义的 SE4AI testing / evaluation / governance 路线图

它们已经开始回答：

  • AI code review agent 应该怎么评估？
  • review false positives 为什么重要？
  • 为什么 code review 是一个需要单独建模的 AI software workflow？

这说明社区已经不再只把 AI 当作 patch 生成器，而开始把它当作进入开发流程的系统角色来看。

2. 这批论文真正没做到的，不是“还没研究 AI”，而是“没上推到 contributor 层”

这是我读完之后最明确的判断。

2.1 现在几乎所有工作都在“单次贡献”层面看问题

即便这些论文已经很有价值，但它们大多还在下面这些对象上做分析：

  • 一个 file / function
  • 一个 commit
  • 一个 PR
  • 一次 merge / reject
  • 一个 post-merge patch

换句话说，单位还是 artifact / event。

但维护者的真实经验并不是这样组织的。

维护者经常面对的是：

这个 contributor 最近连续提了很多 agent-heavy PR； 这些 PR 单个看不一定都很糟， 但整体上它们制造了 review overload、返工、follow-up fixes、低信任感。

这就是现有文献没真正抓住的一层：

contributor-level governance object

2.2 现有工作已经有 contributor-level 的零件，但没有 contributor-level 的主问题

这是更细一点的说法。

AIDev 已经有 developer-level metadata

它不是没有 contributor 信息；相反，它已经有 developer-level artifact。

Agentic Much? 已经看到 adoption 跨开发者与项目扩散

它也不是没碰到 contributor，只是主问题仍然是 adoption。

On Autopilot? 已经看 human-AI teaming

它已经靠近 contributor / ownership / review interaction 了，但重点仍然更像“项目里如何与 AI PR 互动”。

Early-Stage Prediction of Review Effort 已经看 maintainer attention tax

但分析单位还是 PR，而不是 contributor profile。

AI Code in the Wild 已经能打 file/function 级 detector

但仍没有上推成“某个 contributor 的持续贡献画像”。

所以真正的 gap 不是“没人有数据”，也不是“没人研究 review”。
而是：

大家已经把贡献者层所需的零件拼得差不多了，但还没有把 contributor-level governance 作为论文主问题来立起来。

这就是一个很像顶会论文的机会：

  • 不是从零造轮子
  • 而是把已有零件提升成一个更关键的分析层级

3. 精读后的第二判断：maintainer 真正的痛点不是“AI 会不会写”，而是“AI 把负担转移给 reviewer”

这是从好几篇论文里反复出现的一条线。

3.1 Early-Stage Prediction of Review Effort 提得最直白

这篇直接写出了一个关键词：

  • attention tax

它的核心不是“AI PR merge 不 merge”，而是：

agent 可能很擅长产出，但当它们在主观反馈、迭代 refinement 上卡住时，维护者需要承担额外的交互与判断成本。

这和传统 code review automation 问题已经不一样了。
传统是“review 一段代码”；现在变成了：

  • review 一段代码
  • review 一段可能不可信的 PR narration
  • 判断哪些内容其实最终会被删
  • 判断 contributor 是否会继续跟进反馈

这就是维护者视角的 bottleneck。

3.2 What to Cut? 说明 reviewer burden 不是虚的，而是能被量化的

这篇最有意思的地方是，它没有讨论“代码最终对不对”，而是在问：

哪些方法最终会在 review 中被删掉？

这件事表面很小，但其实非常像 maintainer 的日常痛点：

  • 实现者省了时间
  • reviewer 却多了负担

所以 agentic development 真正重写的，未必只是实现过程，而是：

implementation burden 与 verification burden 的重新分配。

这为 contributor-level governance 论文提供了非常硬的动机：

  • 如果某些 contributor 持续以 agent-heavy 模式工作，
  • 那他们可能不是“坏”，
  • 但他们很可能在持续向 reviewer 外包认知负担。

这比“低质量代码”四个字精确得多，也更像软件工程问题。

3.3 Message-Code Inconsistency 和 On Autopilot? 又补了一刀

这两篇合起来，给了两个特别重要的信号：

  1. AI PR 的叙述不一定可信
    message-code inconsistency 会降低 reviewer trust，拖慢 merge。

  2. AI PR 的 review pattern 与普通 human PR 不同
    AI-coauthored PR 会更快 merge、反馈更少，且很多来自没有 ownership 的 contributor。

这两点放在一起，其实非常危险：

  • 来自 non-owner
  • narration 可能不准
  • feedback 却更少
  • merge 可能还更快

这正是 contributor-level governance 应该研究的地方。

因为它指向的问题已经不是：

  • 某个 PR 做得好不好

而是：

维护者是否正在对某类 contributor 形成一种“低反馈、快合并、低 ownership”的新治理模式？

这就是一个很像 ICSE/FSE 的研究问题。

4. 精读后的第三判断：真正值得做的不是“AI contributor detector”，而是“contributor-level risk model”

这是 proposal 需要收缩的关键。

4.1 为什么“AI contributor detector”不够好

如果论文主张写成：

我们检测一个 GitHub 账号是不是 AI / 被 AI 主导。

那会立刻遇到几个问题：

  1. 定义太粗：真实 contributor 是混合体。
  2. 伦理风险大：像 policing / moderation。
  3. 学术价值偏工具化：更像 classifier demo。

这会让 reviewer 很容易说：

  • so what？
  • 为什么这是软件工程贡献，而不是 detection engineering？

4.2 更好的写法是 contributor-level risk model

如果改成：

我们研究 contributor-level agent dominance 是否构成一种可解释的 review / quality risk signal。

整个题目的味道就变了。

它就不再是：

  • 判断谁是 AI

而是：

  • contributor 在多大程度上表现出 agent-heavy profile；
  • 这种 profile 是否对应更高 review burden；
  • 哪些仓库治理机制能吸收或缓解这类风险。

这样写的好处是：

第一，定义更贴近真实世界

contributor 不是 AI / 非 AI 二元，而是处于连续谱上：

  • human-led
  • AI-assisted
  • human-supervised agent-heavy
  • agent-dominated

第二，更贴合 maintainer 真实问题

维护者不是真的想知道“这个人是不是 AI”，而是想知道：

  • 这个 contributor 的贡献需要多高审查优先级？
  • 是否应要求更多 tests / smaller PRs / maintainer review？

第三，更符合软件工程口味

这样问题就从检测转成了：

  • workflow governance
  • review triage
  • quality risk mitigation

这三个词比“AI 账号识别”更像 ICSE/FSE 论文。

5. 现在可以把 gap 说得很清楚了

这是这次 v5 最重要的部分。

5.1 错误写法：模糊 gap

下面这些写法都不够好：

  • 现有工作还没有研究 AI coding agents 对开源的影响。
  • 还没有人研究 GitHub 上的 AI contributor。
  • 还没有成熟方法检测 agent-dominated contributor。

为什么不好？ 因为 reviewer 一眼就会反驳：

  • adoption 有了
  • PR acceptance 有了
  • failed PR 有了
  • post-merge quality 有了
  • code-level detection 也有了

这会让你的 gap 显得不诚实。

5.2 正确写法：层级 gap

更强的写法应该是：

现有工作主要在 file/function、PR、review 和 post-merge 这些 artifact/event 层级理解 AI coding agents 的影响，但维护者实际面对的治理对象并不是独立 PR，而是会持续以 agent-heavy 模式贡献的一类 contributor。现有文献尚未将 contributor-level agent dominance 建模为一个独立的 governance layer，也尚未系统检验它是否能解释 review burden、post-merge risk 以及 repository governance 的缓解效果。

这段话有几个优点：

  1. 承认已有工作，不装作领域是空白；
  2. 明确指出缺的是哪一层，不是泛泛说“还没人研究”；
  3. 把 maintainer pain point 和理论空位绑在一起；
  4. 自然引出你的研究问题。

这就是现在最像顶会风格的 gap 写法。

5.3 再压缩成一句 reviewer 容易记住的话

如果要把它压成一句最锋利的话，我会写成：

The literature has learned to study agentic pull requests, but maintainers do not govern pull requests in isolation—they govern contributors.

中文就是：

现有文献已经会研究 agentic PR，但维护者真正治理的不是孤立 PR，而是 contributor。

我觉得这句话就是这篇 proposal 最该抓住的 punchline。

6. v5 版本的 proposal 主问题

基于上面的精读，我会把 proposal 的主问题压成下面四个。

RQ1. Can contributor-level agent dominance be measured reliably from public GitHub traces?

这里不是做完美 detector，而是做一个 可解释、可复现、分维度的 contributor profile。

RQ2. Does contributor-level agent dominance explain review burden beyond PR-level features?

这一步是整个 proposal 的关键。

因为现有很多工作已经看 PR-level：

  • patch size
  • file count
  • task type
  • CI status
  • PR narration

你真正要证明的是：

即使控制这些 PR-level 特征，contributor-level dominance 仍然提供额外解释力。

如果这点成立，你的论文就不是在重复 PR-level prediction，而是在补一个新的治理层。

RQ3. Are the risks associated with agent-dominated contributors concentrated in specific layers or task types?

这一问是从：

  • Comparing AI Coding Agents
  • AI builds, We Analyze
  • AI Code in the Wild

这些论文里学来的。

也就是说，风险很可能不是均匀的，而集中在：

  • docs
  • tests
  • build / workflow / config
  • glue code
  • fix vs feature vs docs task types

这会让论文更细，也更有 engineering meaning。

RQ4. Which repository governance mechanisms mitigate the review and quality risks of agent-dominated contributors?

这是最接近 ICSE/FSE taste 的一问。
因为它把论文从 observation 拉向了 governance implication。

如果最后只能得到“高 dominance contributor 风险更高”，论文就还不够。
真正更好的结果是：

  • 在弱治理仓库里，CAD contributor 的 review burden 更高；
  • 在强治理仓库里，这种差异显著收缩；
  • 某些 policy（比如 mandatory review / tests / CODEOWNERS）特别有效。

这才是 maintainer 真能用的 insight。

7. 为什么这个 v5 比 v4 更强？

v4 已经有一个不错的直觉，但还偏“我觉得这个题值”。

v5 的进步在于：

第一，gap 更诚实了

它不再装作“没什么人研究这个方向”，而是明确承认：

  • adoption 有了
  • PR-level outcome 有了
  • quality risk 有了
  • review benchmark 也有了

然后再指出真正缺的是 contributor-level governance layer。

这会让 reviewer 更容易买账。

第二，maintainer pain point 更具体了

v4 更像在说“agent-dominated contributor 可能重要”；
v5 则更清楚地说明：

  • reviewer burden 被上移了；
  • implementation burden 与 verification burden 重新分配了；
  • attention tax 是真实存在的；
  • maintainer 不是在治理 PR，而是在治理持续贡献模式。

这就更贴近实际软件工程问题。

第三，论文 identity 更清楚了

v5 不再像“做个 detector”，而更像：

一篇关于 contributor-level governance blind spot 的 empirical software engineering 论文。

这就是味道上的区别。

8. 这一版我建议的标题

标题 A

From Agentic Pull Requests to Contributor Governance: Measuring Agent-Dominated Contributors on GitHub

标题 B

Maintainers Govern Contributors, Not Pull Requests: Detecting Agent-Dominated Contributors for Review Triage

标题 C

The Missing Governance Layer in Agentic Software Engineering: Contributor-Level Agent Dominance on GitHub

如果偏论文味，我最喜欢 标题 C。
如果偏 proposal/report 味，我更推荐 标题 A。

9. 最后一句判断

这批论文精读下来，最值得记住的不是“AI coding agents 很火”，而是：

社区已经会研究 agentic PR，但还没有认真研究 maintainer 如何面对持续以 agent-heavy 模式贡献的一类 contributor。

这正是 proposal 现在最该抓住的 gap。
不是更大的 gap，而是更准的 gap。

而且这个 gap 的好处是：

  • 它承接已有文献，而不是另起炉灶；
  • 它直接贴 maintainer / repository governance 痛点；
  • 它有清楚的 ICSE/FSE 味道；
  • 它后面还能自然接 review policy、quality risk、supply chain exposure。

所以如果要继续推进这个方向，我认为 v5 之后最值得做的，不再是继续发散想法，而是：

  1. 把 contributor-level dominance 的 operationalization 钉死；
  2. 明确 PR-level baseline 和 contributor-level 增量解释力怎么检验；
  3. 把 governance variables 设计清楚；
  4. 提前把 ethics 和 fairness 雷区写好。

这时候 proposal 就会从“方向挺有意思”进入“真的可以开干”。

附：本次精读实际用到的核心论文

  1. AIDev: Studying AI Coding Agents on GitHub
    http://arxiv.org/abs/2602.09185v1
  2. Agentic Much? Adoption of Coding Agents on GitHub
    http://arxiv.org/abs/2601.18341v1
  3. Comparing AI Coding Agents: A Task-Stratified Analysis of Pull Request Acceptance
    http://arxiv.org/abs/2602.08915v1
  4. Why Are AI Agent–Involved Pull Requests (Fix-Related) Remain Unmerged?
    http://arxiv.org/abs/2602.00164v1
  5. Where Do AI Coding Agents Fail?
    http://arxiv.org/abs/2601.15195v1
  6. Early-Stage Prediction of Review Effort in AI-Generated Pull Requests
    http://arxiv.org/abs/2601.00753v2
  7. On Autopilot? An Empirical Study of Human–AI Teaming and Review Practices in Open Source
    http://arxiv.org/abs/2601.13754v1
  8. Analyzing Message-Code Inconsistency in AI Coding Agent-Authored Pull Requests
    http://arxiv.org/abs/2601.04886v2
  9. AI builds, We Analyze
    http://arxiv.org/abs/2601.16839v1
  10. Beyond Bug Fixes
    http://arxiv.org/abs/2601.20109v1
  11. What to Cut?
    http://arxiv.org/abs/2602.17091v1
  12. “TODO: Fix the Mess Gemini Created”
    http://arxiv.org/abs/2601.07786v1
  13. AI Code in the Wild
    http://arxiv.org/abs/2512.18567v1
  14. CR-Bench
    http://arxiv.org/abs/2603.11078v1