导读

文献来源：Detecting AI Coding Agents in Open Source: A Validated Multi-Method Census of 180 Million Repositories. arXiv:2606.24429v1，2026-06-23；署名：Arsham Khosravani、Audris Mockus；链接：https://arxiv.org/abs/2606.24429。

这篇论文关心一个很近的问题：AI coding agent 到底只是聊天框里写代码，还是已经进入开源软件供应链，像一个隐身同事一样提交 commit、开 PR、改配置？

研究使用 World of Code 覆盖 1.8 亿以上 Git 仓库，提出多层检测框架：配置文件扫描、commit message 分析、author identity 匹配、bot signature lookup，并把 agent traces 分为 4 类。

关键数字非常抓人：单一方法会严重漏检。以 Claude Code 为例，多方法检测识别 850,157 个 commits，而常见 bot account lookup 只找回 28,154 个，约 3.3%，相当于 30 倍相对召回差距。

论文还显示，到 2025 年，AI-agent attributed commits 月度规模超过 320,000；Claude Code 在 17,295 个项目中出现 886,122 个 commits。更麻烦的是，PR census 会漏掉 79% commit-detected Claude Code adopters，几乎漏掉 Codex adopters。

研究背景与目的

过去一年，AI 写代码的讨论常停留在两个极端：一种说它只是更聪明的自动补全，另一种说程序员岗位马上被端走。真正有意思的问题其实更工程化：这些工具有没有留下可测量的痕迹？它们是以 PR、commit、配置文件、机器人账号，还是某种混合方式进入仓库？

开源软件供应链是一个天然实验场。仓库有提交历史，有 commit message，有配置文件，有 bot 账号，有 PR。只要检测方法足够细，就能看见 AI agent 从“对话窗口里的帮手”变成“版本历史里的参与者”的过程。

但论文开场就指出一个麻烦：AI coding agents 的痕迹很分散。某些 agent 通过专用 bot 账号出现，某些把签名藏在 commit message 里，某些只留下 CLAUDE.md、AGENTS.md 或 .cursor 之类配置文件，某些通过 PR 平台被记录。只盯一个入口，就像只看公司门禁记录来判断谁在工作，远程办公的人全没了。

这就是研究提出 multi-method census 的原因。它不是想证明某个工具“赢了”，而是先把观察口径变清楚：不同检测通道看到的不是同一群 agent，也不是同一种工作。没有口径，所有规模数字都容易变成噪声。

对普通开发者和团队来说，这个问题很现实。AI 代码进入仓库后，审查责任、测试覆盖、许可证风险、凭据暴露、维护归属都会跟着变。真正的问题不是“AI 会不会写代码”，而是“它写进来的代码，我们能不能看见、理解并治理”。

文献官网来源截图：arXiv 页面保留题名、署名和 arXiv 编号，用于核对本文来源。

研究方法

研究基于 World of Code 数据，覆盖超过 1.8 亿 Git 仓库。它没有依赖单一平台 API，而是从大规模版本历史出发，检测多类 AI coding agent traces。这种做法适合回答供应链层面的规模问题，因为 commit 是软件项目的底层轨迹。

论文把检测方法分成多层：配置文件扫描可以发现项目是否引入 agent 相关规则或工作流；commit-message regex 可以抓到自动生成签名或 co-authorship trailer；author identity 匹配可以识别特定账号或邮箱；bot-signature lookup 则对应平台上较显眼的机器人痕迹。

研究还把 traces 分为 4 类行为类型。这个 taxonomy 很关键，因为“AI 参与”不是单一动作：有的 agent 直接提交代码，有的只被配置好但还没活跃，有的通过 PR 出现，有的在 commit 文本里留痕。分类能避免把“装了配置文件”和“实际提交代码”混为一谈。

为了防止规则检测自嗨，论文使用 495 个 hand labels 做验证，并报告 Wilson confidence intervals。也就是说，规则不是随手写几个关键词就开扫，而是要在人工标注样本上检查精度区间。对大规模观测研究，这一步决定数字有没有可信度。

研究还把 commit census 与独立 PR census（AIDev）对照。这个对照非常聪明，因为它直接检验不同通道是否看到同一批 agent 活动。结果显示，两者相当不重合，说明任何单一渠道都会把现实压扁。

论文原文插图 Figure 1 裁图：多方法 AI-agent 检测框架，展示配置文件、commit message、身份匹配和 PR census 等通道如何共同构成观察口径。

主要发现

论文的核心发现之一是：单一检测方法会大漏。Claude Code 的例子很典型，多方法检测找出 850,157 个 commits，而 bot account lookup 只找回 28,154 个，约 3.3%。如果只用机器人账号做研究，就会把大量在普通 commit 通道里的 AI 活动当成不存在。

到 2025 年，commit-attributed agents 的月度提交量已经超过 320,000。这个数字不是在说每个 commit 都质量高，也不是在说 AI 已经接管开源，而是说明 AI agent 的活动规模已经足以进入供应链治理视野。以前像空气，现在像脚印，虽然还需要分辨脚印是谁踩的。

Claude Code 的规模尤其突出：886,122 个 commits，覆盖 17,295 个项目。它还在配置文件层面呈现强存在感，例如 CLAUDE.md、.claude/ 目录等。配置文件有点像项目给 AI 留的“工作守则”，即使还没看到实际提交，也说明项目已经给 agent 腾出了位置。

PR census 与 commit census 的断裂很有意思。论文显示，PR census 会漏掉 79% commit-detected Claude Code adopters，并几乎漏掉 Codex adopters。这意味着看 GitHub PR 只能看到一部分“云端代理工作流”，看 commit 又会看到更多编辑器内、命令行内、直接提交的工作流。

不同部署渠道还对应不同工作类型。PR-deployed cloud agents 更容易显出 feature work，commit-deployed in-editor agents 更容易显出 maintenance work。这个结论很重要：如果只看 PR，会误以为 agent 主要在做功能开发；如果只看 commit，又可能低估云端代理的任务形态。

论文的 Figure 1 展示了多方法检测框架：不同 traces 被接入同一个分类体系。这个图像很像一张机场安检图：有的人走人工通道，有的人走自助闸机，有的人从工作人员入口进来。要数清楚人流，不能只盯一个门。

Figure 2 的月度趋势说明 agent activity 在多个 snapshot 中快速上升。趋势图的价值不是精确预言未来，而是提示工具扩散正在从个别 demo 变成版本历史中可见的群体现象。对安全、合规和工程管理来说，这已经不是茶水间闲聊。

Table 1 汇总 12 类 agent 的检测结果，展示不同工具在配置、commit、PR 等通道上的分布差异。表格告诉我们，所谓“AI 编程工具采用率”不是一个数字能说完，而是要先说明检测口径：你数的是项目配置、实际 commit、PR，还是机器人账号？

一个容易被误解的点是：检测到 AI trace 不等于代码质量更好或更差。论文研究的是可观测痕迹和规模，不是做 bug benchmark。把它读成“AI 写的代码都危险”或“AI 已经比人强”都不严谨。它更像供应链地图，先告诉你河流从哪里流进来。

真正值得团队马上思考的是治理接口。既然 AI commits 可以通过多种渠道进入仓库，就需要在代码审查、CI、许可证扫描、凭据检测、依赖安全和 commit metadata 中加入更清楚的标注策略。看不见的同事并不一定坏，但看不见的生产变更一定难管。

论文原文插图 Figure 2 裁图：月度 AI-attributed commit volume 趋势，呈现 agent 活动从零散痕迹变为可规模观测现象。

论文原文表格 Table 1 裁图：12 类 AI coding agents 在不同检测通道中的 prevalence，说明单一口径会系统性漏检。

结论与意义

这篇论文把 AI coding agent 从体验层讨论推进到供应链观测层。它提供的不是又一个排行榜，而是一套更稳妥的观察方法：多通道、分类、验证、与独立数据源对照。

对开发团队来说，结论不是“禁用 AI”或“全面拥抱 AI”，而是先建立可见性。哪些仓库用了 agent 配置，哪些 commit 带有 agent 痕迹，哪些 PR 来自云端工具，哪些维护任务由 agent 参与，只有看见之后才能谈流程。

对平台和研究社区来说，这篇文章也提醒，AI 软件工程的证据不应只来自问卷或工具厂商数据。版本历史本身就是重要资料，但它需要足够细的检测方法，否则会把沉默采用当成不存在。

局限性与未来方向

局限首先是检测规则不可避免会跟工具演化赛跑。Agent 签名、配置文件名、commit message 习惯都可能变化；今天有效的规则，未来可能漏掉新模式，也可能把某些人工约定误判为 agent trace。

其次，论文衡量的是可观测痕迹，不等于完整真实使用。开发者可能让 AI 写代码但手动改写 commit message，也可能复制粘贴后不留下任何工具痕迹。这类“无痕采用”仍很难被仓库级数据捕捉。

第三，规模不等于影响。320,000+ monthly commits 说明活动已经大，但每个 commit 的复杂度、风险、质量、审查强度不同。一个改 README 的 commit 和一个改身份认证逻辑的 commit，不能只按数量相加。

未来研究需要把检测与质量、安全和维护结果连接起来：AI trace 是否关联更多测试、更多回滚、更多漏洞修复，或更多低风险维护？只有把“谁写了”与“写得怎样、带来什么后果”连起来，AI 编程的讨论才会从热闹走向工程判断。

参考文献

Detecting AI Coding Agents in Open Source: A Validated Multi-Method Census of 180 Million Repositories. arXiv:2606.24429v1. 2026.

World of Code corpus and AIDev PR census are used in the paper for multi-channel comparison.