研究提案 v4：面向代码审查治理的 Agent-Dominated Contributor 检测

一句话结论
我不建议把题目做成“识别 AI 账号然后拒绝它们”。更值得做、也更符合 ICSE/FSE taste 的版本是：
构建一个面向代码审查治理的 contributor-level risk model，识别 agent-dominated contributors，并研究它如何支持 maintainer triage、review prioritization 与质量风险缓解。

为什么现在值得做
2026 年这波研究已经清楚表明：AI coding agents 不再只是代码补全，而是在真实 GitHub 工作流里批量产出 PR、改 build、改测试、改文档，且大量 PR 会被 merge；但社区仍然缺一个 contributor-level 的治理视角。我们知道 agent PR 在增长，却还缺一个稳健的方法回答：哪些贡献者账号已经高度 agent-dominated？维护者应如何据此调整审查策略？

0. 先补背景：现在 SE4AI / agentic software engineering 的前沿到底到哪了？

这一步不是为了堆 related work，而是为了先判断这个题是不是站在社区主线上。

0.1 现在前沿已经不再是“agent 会不会写代码”，而是“agent 如何进入真实仓库工作流”

2026 年初这批论文最明显的共同点，是研究对象已经从 benchmark 上的 snippet 生成，转向了 真实 GitHub 仓库、真实 PR、真实 review、真实 post-merge 结果。

代表工作 1：AIDev: Studying AI Coding Agents on GitHub

arXiv: http://arxiv.org/abs/2602.09185v1
关键点：构建了 932,791 个 agent-authored PR 的大规模数据集，覆盖 116,211 个仓库与 72,189 个开发者。
启发：社区已经从“能不能研究”进入“能大规模研究”的阶段；数据基础设施开始成型。

代表工作 2：Agentic Much? Adoption of Coding Agents on GitHub

arXiv: http://arxiv.org/abs/2601.18341v1
关键点：估计 coding agents 在 GitHub 的 adoption 已达到 15.85%–22.60%，且 adoption 已跨越项目成熟度、语言与组织边界。
启发：agent 使用不再是边缘现象，而是已经足够大到影响开源协作结构。

0.2 研究重心正在从“是否采用”走向“采用后会发生什么”

代表工作 3：Comparing AI Coding Agents: A Task-Stratified Analysis of Pull Request Acceptance

arXiv: http://arxiv.org/abs/2602.08915v1
关键点：不同 agent 在不同任务类型上的 PR 接受率显著不同；任务类型比 agent 名称本身更能解释 acceptance。
启发：agent 影响不是均匀的，必须分任务、分层看。

arXiv: http://arxiv.org/abs/2602.00164v1
关键点：大量未合并 fix-related PR 的根本问题不是“维护者反 AI”，而是测试失败、问题已被别人提前修掉等工作流摩擦。
启发：真正值得研究的是 review/maintenance bottleneck，而不是抽象地争论 AI 好不好。

0.3 社区已经开始把质量与治理拉到前台

代表工作 5：AI builds, We Analyze

arXiv: http://arxiv.org/abs/2601.16839v1
关键点：agent-authored build code 中存在明显的 maintainability / security smell，但 61%+ 的 Agentic-PR 仍被合并。
启发：build / workflow / config 是 agent 进入仓库后一个高风险、但容易被忽视的层。

代表工作 6：Beyond Bug Fixes: Post-Merge Code Quality Issues in Agent-Generated Pull Requests

arXiv: http://arxiv.org/abs/2601.20109v1
关键点：merge success 并不等于 post-merge quality 安全，代码 churn 归一化后仍能看到稳定的质量风险。
启发：单看 merge/close outcome 太粗；需要更接近 review governance 的视角。

代表工作 7：What to Cut? Predicting Unnecessary Methods in Agentic Code Generation

arXiv: http://arxiv.org/abs/2602.17091v1
关键点：agentic PR 中有一部分函数会在 review 里被删掉，模型可达到 87.1% AUC。
启发：reviewer 的真正痛点不是“agent 会不会写”，而是 agent 先写出大量代码，reviewer 被迫去判断哪些该删。

0.4 与 SE4AI 更深的连接：仓库级指令、技术债与安全传播都已经开始成为问题

代表工作 8：On the Impact of AGENTS.md Files on the Efficiency of AI Coding Agents

arXiv: http://arxiv.org/abs/2601.20404v1
关键点：AGENTS.md 这类 repo-level instruction artifact 会显著改变 agent runtime 与 token use。
启发：仓库已开始出现“为 agent 准备”的配置制品，说明开发流程结构正在变化。

代表工作 9：“TODO: Fix the Mess Gemini Created”

arXiv: http://arxiv.org/abs/2601.07786v1
关键点：开发者会在 comment 中明确承认 AI 参与与遗留技术债。
启发：self-disclosure 是一个可用于 contributor-level labeling 的真实信号。

代表工作 10：AI Code in the Wild

arXiv: http://arxiv.org/abs/2512.18567v1
关键点：已经出现 file/function 级别的 AI-generated code detection pipeline，并揭示 AI code 在 glue/tests/docs 中更集中，在核心逻辑与安全关键配置中较少。
启发：repo / contributor 层面的 detection 已经有了下层零件，但还没有上升到治理层。

0.5 我的判断：现在最有发表潜力的切入点，不是再证明“agent 使用在增长”，而是研究

谁在被 agent 主导？
这种主导如何改变 review 负担与质量风险？
维护者如何基于这一信息调整治理策略？

这就把题目从 adoption study，抬到了更像 software engineering governance 的层面。

1. 从前沿倒推：什么样的 proposal 更像 ICSE/FSE 的 taste？

如果用一个很挑的 ICSE/FSE reviewer 的眼光看，这个题目要成立，至少要同时满足四个条件：

不是“AI 很热，所以研究 AI”
而是解决 maintainer / review workflow 的真实痛点。
不是“做一个 AI detector”
而是提出一个可验证、可解释、可服务治理的 measurement / modeling problem。
不是简单分类器比赛
而是要回答 contributor-level 风险与 repository governance 之间的关系。
最终 punchline 要是软件工程 insight
例如：哪些 contributor profile 真会放大 review 负担，哪些治理机制能抵消这种风险。

因此，这个题如果要做对，应该从一开始就把 framing 写成：

Detecting agent-dominated contributors for repository governance and review triage.

而不是：

Detecting whether a GitHub account is AI.

2. 四轮迭代

下面是我按“15 分钟一轮”的思路做的四轮收缩。重点不是装作时间流逝，而是明确记录 proposal 是如何一步步从一个直觉想法，收缩成更像顶会味道的研究设计。

Iteration 1 / v1：从直觉想法到可研究问题

v1 的原始想法

最直觉的版本是：

能不能检测一个 GitHub 账号是不是被 agent 主导，从而帮助维护者提前识别低质量 PR 来源？

这个版本有现实痛点，但如果直接拿去写 proposal，会有三个明显问题：

问题定义太粗：账号不是 AI / 非 AI 二元体，而是长期混合体。
太像 moderation / policing：容易被 reviewer 质疑 fairness 与 ethics。
研究价值不够硬：如果只做“检测器”，会更像工具 demo，而不是 SE insight。

v1 的第一次重写

因此 v1 的目标应该改成：

定义 contributor-level agent dominance，并研究它是否能作为 review risk triage 的有用信号。

这一下，题目的重心就从“识别 AI 账号”转向了三个更稳的问题：

contributor 的 agent dominance 怎么 operationalize；
它与 PR/review/post-merge outcome 有什么关系；
它如何支持 maintainer triage，而不是简单封杀。

v1 的核心变量

Exposure：Contributor Agent Dominance

不是二元标签，而是连续变量。可由四类信号组成：

Explicit trace
- agent-authored PR / commit 比例
- co-author / generated-by / tool signature
- self-disclosure（PR、comment、review）
Behavioral signals
- PR size、file spread、跨 repo burstiness
- review 后大比例删除
- 高频 feature/fix PR 但解释很少
Artifact signals
- AI-likely file/function 占比
- boilerplate/template density
- build/config/docs/test 中的 agent 渗透
Workflow signals
- merge latency
- follow-up fix ratio
- reviewer intervention intensity

Outcomes

先别贪多，v1 先盯住三个 outcome：

PR 是否被 merge / reject / remain open
review 后删除/大改强度
post-merge 质量代理（如 follow-up fix / smell density）

v1 的主问题

RQ1：能否构建 contributor-level 的 Agent Dominance Score？
RQ2：高 ADS 的 contributor 是否对应更高 review burden？
RQ3：维护者是否能基于 ADS 做更有效的 triage？

v1 的不足

这一版的问题是：虽然更像研究问题了，但仍然太像“构建一个 predictor 然后看有没有用”。
还缺一个更硬的 SE 主贡献。

Iteration 2 / v2：把问题从“分类器”收缩成“治理信号是否有效”

v2 的核心转向

ICSE/FSE 审稿人未必会被“我们做了一个账号级 detector”打动。更可能的质疑是：

so what？即使你预测得不错，这个分数为什么对软件工程实践真的有意义？

所以 v2 的核心重写是：

不是证明我们能识别 agent-dominated contributors，而是证明：如果维护者忽略 contributor-level agent dominance，他们就会系统性低估 review burden 与 post-merge 风险。

这一下，模型从工具变成了 measurement contribution 的一部分。

v2 的论文主张雏形

在 agentic software engineering 时代，PR-level signal 不足以刻画 review risk；contributor-level agent dominance 提供了一个跨 PR 的风险汇总层，能够补足 maintainer 仅看单个 PR 时的盲区。

为什么这个主张更强

因为现在已有工作大多停在：

PR acceptance
PR deletion
post-merge quality
code-level AI detection

但还很少工作问：

同一个 contributor 持续以 agent-heavy 模式工作时，会不会对仓库治理产生可累积的结构性影响？

这就更像 SE 论文里的“missing layer”。

v2 的分析框架

Baseline A：只看 PR-level features

PR size
changed files
task type
tests changed
fix/documentation labels

Baseline B：加入 contributor-level agent dominance

explicit trace ratio
contributor review-deletion history
contributor post-merge fix history
contributor agent-heavy layer distribution

如果 B 明显优于 A，并且能解释 maintainer triage 的误差来源，那么论文就有一个很清楚的结论：

只看单个 PR 不够，必须看 contributor-level governance profile。

v2 的不足

这版已经更像论文，但 reviewer 还是可能问：

你到底是 prediction paper，还是 empirical SE paper？
你是要做 better classifier，还是要发现新现象？

所以 v3 要继续压缩：把“prediction”降格为手段，把“治理结构差异”抬成主发现。

Iteration 3 / v3：从 predictor 论文压缩成 empirical governance paper

v3 的关键判断

真正更像 ICSE/FSE 的写法不是：

我们做了一个 contributor-level agent detector。

而是：

GitHub 仓库正在出现一种新的 contributor governance challenge：同一贡献者会在一段时间内以高度 agent-dominated 的方式持续提交 PR，这种模式会显著改变 review burden、合并风险与 post-merge 后果。

检测模型只是为了让这个现象可测。

v3 的主问题重写

RQ1：Contributor-level agent dominance 能否被公开 GitHub 痕迹稳定测量？

关注的是 measurement validity，不是追求一个万能 detector。

RQ2：高 agent-dominance contributors 的 PR 在 review burden 上是否呈现稳定差异？

例如：

更高的 review deletion ratio
更多 changes requested
更长 merge latency
更频繁的 follow-up fix

RQ3：这种差异主要由哪些任务层或代码层驱动？

这里要承接前沿工作里已经出现的分层现象：

docs/tests/build/config/glue/core logic

RQ4：哪些 repository governance 机制能缓解这种 contributor-level 风险？

例如：

mandatory review
CI gate
CODEOWNERS
branch protection
smaller PR norms

这版的核心 SE insight

如果结果支持，论文的 punchline 可以长这样：

contributor-level agent dominance 是一个可测、且跨 PR 稳定的 contributor attribute；
它与 review burden / post-merge risk 显著相关；
风险并非均匀分布，而主要集中在某些任务层或代码层；
强治理仓库可以显著吸收这类风险。

这已经比“做个检测器”强很多。

v3 仍然缺的东西

还差最后一步：把 novelty 锚得更尖。
也就是 reviewer 最想听到的那句：

你到底揭示了一个什么以前没被清楚量化过的结构？

Iteration 4 / v4：最终稿——把 novelty 锚定到“贡献者层治理盲区”

v4 的最终核心判断

我认为这题最值得投稿的版本，不是“谁是 AI 账号”，也不是“如何拒绝低质量代码”，而是：

现有 agentic software engineering 研究主要在 PR / commit / file / function 级别刻画 AI 参与，但忽略了 contributor-level 的治理盲区：维护者面对的不是独立 PR，而是会持续以 agent-heavy 模式贡献的一类 contributor。

也就是说，论文真正要补上的，是一个新的分析层级。

v4 的最终论文标题建议

标题 A

Research Proposal: Detecting Agent-Dominated Contributors for Review Triage and Repository Governance

标题 B

Who Really Needs a Closer Review? Measuring Contributor-Level Agent Dominance on GitHub

标题 C

From Agentic PRs to Agent-Dominated Contributors: A Repository Governance Perspective

如果按 ICSE/FSE taste，我最推荐 标题 C，因为它清楚表达了：

不是停在 agentic PR
而是向 contributor governance 提升一层

3. 最终 proposal（v4）

3.1 研究问题

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

目标不是做完美识别，而是提出一个 Contributor Agent Dominance Score (CADS)，并验证它在公开 GitHub 痕迹上是否稳定、可解释、可复现。

RQ2. Do agent-dominated contributors impose higher review burden than contributors with low agent dominance?

关注的不是单纯 merge rate，而是 maintainer 真正的负担：

review deletion ratio
changes requested
merge latency
reviewer discussion length
reopen / rework / resubmission patterns

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

例如：

docs
tests
build / workflow / config
glue code
core logic

以及：

feature
fix
refactor
documentation
maintenance

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

重点看 repository governance 是否能吸收 contributor-level 风险，而不是把责任都推给 contributor 本人。

3.2 研究对象与数据来源

数据基础

优先基于 AIDev 做主样本，因为它目前是最强的公开 agent-authored PR 数据基础设施。

AIDev（2602.09185）中的 agent-authored PR 与 contributor traces
star > 100 的 curated subset，方便获取更丰富的 review / comment / issue / commit 信息
GitHub API / GH Archive 补足 repository-level governance metadata

采样范围

为了更像一篇可完成的论文，不建议一开始扫全 GitHub。建议：

优先聚焦 public repositories with active PR workflow
限制在若干主语言（例如 Python / JavaScript / TypeScript）
选择具有明确 review 记录的仓库
时间窗口锁定在 2025H1–2026Q1，覆盖 coding agent adoption 的关键跃迁期

对照组

除了高 agent-trace contributor，还需要：

same-repo matched contributors
same-language matched contributors
similar activity-level contributors

否则很容易把“高产开发者”误判成“高 agent dominance”。

3.3 Contributor Agent Dominance Score (CADS)

设计原则

CADS 不应该是黑箱二分类器，而应是多维、可解释的 contributor profile。

CADS 由四部分组成

(1) Explicit Trace Score

agent-authored PR ratio
explicit tool mention ratio
co-author / generated-by / bot signature ratio
self-disclosure in comments / reviews / PR bodies

(2) Behavioral Agent-Likeness Score

median PR size
touched file count
cross-repo burstiness
reviewer deletion ratio
feature/fix-heavy high-throughput contribution pattern

(3) Artifact AI-Likelihood Score

AI-likely file/function ratio
template / boilerplate density
layer-specific AI-likelihood (docs/tests/build/core)

(4) Workflow Risk Score

follow-up fix ratio
post-merge smell increase
changes-requested frequency
review latency under control variables

为什么不用单一标签

因为 contributor 真实状态更可能是：

human-led with occasional AI help
AI-assisted
human-supervised agent-heavy
agent-dominated

连续分数 + profile 比硬标签更符合真实工作流，也更利于治理解释。

3.4 方法设计

Phase 1：高精度 labeling

先用 explicit traces 构造高 precision seed。

正样本：

AIDev 中高置信 agent-authored contributors
有明确 tool trace / self-disclosure 的 contributors

负样本：

matched same-repo contributors with no trace
经人工检查的 likely human-led contributors

Phase 2：contributor-level aggregation

把 PR / commit / review / comment / post-merge outcome 聚合到 contributor 层，形成 CADS。

Phase 3：risk modeling

比较只看 PR-level features 与加入 contributor-level CADS 后，对以下 outcome 的解释力是否提升：

merge / reject / open
review deletion intensity
changes requested
follow-up fix
post-merge smell density

Phase 4：governance interaction analysis

研究 repository governance 变量是否调节 CADS 与 outcome 之间的关系：

CODEOWNERS
branch protection
CI strictness proxy
reviewer count
maintainer centralization

3.5 预期贡献

C1. A new governance-level measurement layer

现有工作大多停在 PR / commit / file 级别。本文向上补出 contributor-level agent dominance 这一治理层。

C2. Empirical evidence that contributor-level agent dominance matters for review burden

如果结果成立，论文将证明： 维护者真正面对的是 contributor pattern，而不是孤立 PR。

C3. A differentiated, non-binary view of AI participation

不是“AI contributor / human contributor”，而是把 contributor 放到 human-led → AI-assisted → agent-heavy → agent-dominated 的连续谱上。

C4. Governance implications for maintainers

论文不只告诉社区“这个现象存在”，还会告诉社区：

哪些 contributor profile 需要更严格 review
哪些仓库治理机制能抵消 agent-heavy contributor 带来的风险

3.6 为什么这题有 so what？

这是这份 proposal 最不能糊弄的地方。

对维护者

如果研究成立，维护者可以不必靠直觉判断“这个账号看起来像 AI”，而能基于更可解释的 contributor profile 来做 triage：

要求更小 PR
强制测试
强制 maintainer review
不对某类 contributor 开启 auto-merge

对平台

GitHub 或类似平台可以把 contributor-level governance 视角纳入 review tooling，而不是只做 PR-level summarization。

对 SE 社区

这项工作把 agentic software engineering 从“AI 产出的 artifact 质量”推进到“AI 改变开源协作治理结构”。这比单纯比较 acceptance rate 更接近未来几年的核心问题。

对软件供应链与开源生态

如果 contributor-level agent dominance 与 build/config/workflow 层风险强相关，那么它会自然连接到：

供应链暴露面
依赖与 CI 风险
自动化仓库的维护脆弱性

这能把题目从 code review 一路接到更长期的安全与治理问题。

3.7 风险与失败条件

风险 1：CADS 可能只是 activity proxy

如果最终 CADS 与 activity size 高度共线，那贡献就会大打折扣。

应对：

matched controls
same-repo / same-language comparisons
churn normalization
ablation study

风险 2：explicit trace recall 太低

如果太多真实 agent 使用没留下痕迹，measurement validity 会被质疑。

应对：

明确 CADS 是 observable dominance，不是假装捕获所有 agent use
用 weak supervision 扩展，但不夸大 label purity

风险 3：容易滑向“AI policing”

如果 framing 不慎，会被批评成鼓励歧视 AI 使用者。

应对：

明确目标是 triage 和 governance，而不是封禁
重点研究 mitigation，不是 rejection
在 ethics 中讨论误伤与 fairness 问题

风险 4：只得到“高 CADS contributor 的 PR 更大”这种平庸结论

这会让论文缺乏记忆点。

应对：关键不是证明 PR 更大，而是证明：

contributor-level 视角补足了 PR-level 的治理盲区；
风险集中在哪些层；
哪些治理机制可以缓解。

3.8 Ethics 与审稿雷区

必须正面回应以下问题：

误伤 human contributors
非英语母语者、新手、高产维护者都可能被误判为 agent-heavy。
不要把 AI 使用道德化
研究目标不是“排斥 AI”，而是更好地分配 review attention。
避免身份标签化
最好输出 risk profile / governance recommendation，而不是公开给 contributor 贴“AI account”标签。

这部分写得不好，审稿时很容易被揪住。

3.9 我对这个 proposal 的最终判断

如果要沿着“优秀的、可以出成果的思路”往下做，我认为这个方向最值得保留的版本是：

从 agentic PR 继续往上走一层，提出 contributor-level agent dominance 这一治理视角，并研究它与 review burden、post-merge risk 以及 repository governance 的关系。

这是因为它同时满足几件事：

踩在前沿主线上：直接承接 AIDev、adoption、PR acceptance、post-merge quality、AI code detection 这波 2026 前沿工作。
有清楚的 SE 味道：不是做 detector 炫技，而是研究开源仓库治理结构如何被 agent 改变。
有很强的 so what：对 maintainer triage、平台设计、review policy、供应链风险都能给出后续落点。
可连续出成果：先做 measurement + empirical paper，后面还能接 mitigation、tool support、policy 评估。

如果真往 ICSE/FSE taste 去打，我会把最终卖点压成一句：

现有 agentic software engineering 研究主要在 PR 与 artifact 层面理解 AI 参与，但维护者面对的真正治理对象是 contributor；忽略 contributor-level agent dominance，会系统性低估 review 负担与代码合并后的风险。

这句话够清楚，也够像一篇顶会实证 SE 论文的主轴。

4. 参考文献线索（本 proposal 实际依赖的前沿）

AIDev: Studying AI Coding Agents on GitHub
http://arxiv.org/abs/2602.09185v1
Agentic Much? Adoption of Coding Agents on GitHub
http://arxiv.org/abs/2601.18341v1
Comparing AI Coding Agents: A Task-Stratified Analysis of Pull Request Acceptance
http://arxiv.org/abs/2602.08915v1
Why Are AI Agent Involved Pull Requests (Fix-Related) Remain Unmerged?
http://arxiv.org/abs/2602.00164v1
What to Cut? Predicting Unnecessary Methods in Agentic Code Generation
http://arxiv.org/abs/2602.17091v1
AI builds, We Analyze: An Empirical Study of AI-Generated Build Code Quality
http://arxiv.org/abs/2601.16839v1
Beyond Bug Fixes: An Empirical Investigation of Post-Merge Code Quality Issues in Agent-Generated Pull Requests
http://arxiv.org/abs/2601.20109v1
On the Impact of AGENTS.md Files on the Efficiency of AI Coding Agents
http://arxiv.org/abs/2601.20404v1
“TODO: Fix the Mess Gemini Created”: Towards Understanding GenAI-Induced Self-Admitted Technical Debt
http://arxiv.org/abs/2601.07786v1
AI Code in the Wild: Measuring Security Risks and Ecosystem Shifts of AI-Generated Code in Modern Software
http://arxiv.org/abs/2512.18567v1

这是四轮迭代后的 v4。相较最初“识别 AI 账号然后拒绝低质量代码”的直觉版本，v4 已经把题目收缩成更符合 ICSE/FSE taste 的实证软件工程 proposal：不再把目标写成 policing，而是把贡献锚定在 contributor-level governance blind spot；不再把 detector 当主角，而是把它作为测量 contributor agent dominance 的手段；最终研究问题则落到 maintainer 真正关心的 review burden、post-merge risk 与 governance mitigation 上。