周一早上，代码仓库里多了一份很“标准”的 Pull Request。

改动范围不大，测试全部通过，变量命名也符合项目规范。真正让审核者停下来的，是那段工整得有些反常的说明：问题背景、根因、修改内容、验证步骤和风险提示一项不少，连提交信息的句式都像从模板里复制出来的。

代码看不出明显差别，提交账号也是团队成员本人。这份改动究竟由谁完成，还有办法判断吗？

2026 年 8 月发布的预印本 AgenTag: Attribution of AI Coding Agents from Behavioral Fingerprints，分析了 33,580 个 AI 编程智能体提交的 PR，以及 6,618 个真人提交的 PR。论文得到的一个反常识结论是：真正暴露智能体身份的，主要不是代码，而是它描述代码的方式。

提交账号已经不能回答“谁写了代码”

过去追溯代码来源，通常先看提交者账号。但编程智能体进入本地开发环境以后，这条经验开始失效。

开发者可以让工具修改文件、运行测试并生成提交，最后仍然用自己的账号推送。平台看到的是一个真人账号，代码的主要生成者却可能是智能体。对于普通代码审查，这似乎只是工具选择；对于漏洞追踪、许可证审计、质量评估和研究数据统计，它会直接影响结论。

论文把一个 PR 拆成四类信息：

信息类型	具体内容	它记录了什么
PR 文本	标题与描述	提交者如何解释问题和修改
Commit Message	每次提交的说明	修改过程如何被组织和概括
Code Diff	新增、删除与修改的代码	最终产物发生了什么变化
行为特征	提交数量、改动规模等结构信息	完成任务时留下的操作模式

这不是只在几个固定工具之间做分类。研究还尝试识别从未见过的新智能体，并在只有少量样本的情况下把新工具加入识别范围。

近4万个PR给出了什么结果

AgenTag 使用的数据集包含五类编程智能体：OpenAI Codex、GitHub Copilot、Devin、Cursor 和 Claude Code。清洗后共有 40,198 个 PR，其中 33,580 个来自智能体，6,618 个来自人类。

论文首页已经把研究对象、数据规模和核心结论压缩进摘要。双语对照后，可以一边保留 PR descriptions、commit messages、code diffs 等原始术语，一边核对中文解释，避免把“行为指纹”误解成写在代码里的显式水印。

图 1 AgenTag 论文首页的双语对照效果，版式、摘要和术语位置保持对应

论文报告了三组值得关注的结果：

• 在已知智能体之间识别作者时，weighted F1 为 0.96，macro F1 为 0.84。
• 区分 AI 与人类提交时，balanced F1 为 0.89。
• 检测训练阶段没有出现过的智能体时，AUC 为 0.84。

这些指标不能被简化成“看一眼 PR 就能断定作者”。它们描述的是特定数据集、特征处理和实验划分下的模型表现。仓库类型、团队模板、语言习惯和工具版本变化，都可能让结果漂移。

但论文的消融实验指向了一个更稳定的问题：不同信息源的贡献并不平均。

最终代码反而没有提供多少身份信号

直觉上，不同智能体应该有不同的代码风格。有人偏爱提前返回，有人习惯拆小函数，有人会补充更多注释。只要分析抽象语法树、词法特征或代码嵌入，似乎就能找到作者。

论文的结果却显示，PR 描述和 Commit Message 几乎提供了全部归因信号，Code Diff 在多种表示方式下贡献都很有限。

原因并不神秘。

代码受到仓库规范、编程语言、格式化工具、静态检查和已有上下文的共同约束。同一个缺陷的合理修法通常只有几种，智能体生成的结果还可能经过开发者修改。最终进入 Diff 的代码，会被项目本身“压”进相近的风格。

沟通文本受到的约束要弱得多。不同工具对任务的概括顺序、标题结构、验证说明、风险措辞和提交粒度，可能长期保持稳定。它们像行为习惯，而不是明显的产品签名。

研究者还分层移除了 Generated with、工具链接、供应商模板和自报身份等显式标记。清理以后，归因能力仍然存在。这意味着模型不只是搜索某句暴露身份的话，也在利用更隐蔽的表达模式。

先记住一个区别：代码相似，不代表生产过程相同；文本有规律，也不等于已经证明作者身份。

这对代码审查意味着什么

如果团队只关心功能是否正确，作者归因似乎没有必要。但当智能体可以修改多个文件、执行命令并自动提交时，审查对象已经从一个 Diff 扩大成一条生产链。

至少有四类问题需要知道代码是怎样产生的。

1. 审查强度：智能体一次修改二十个文件，人工只改了最后两行，不能按普通小改动处理。
2. 问题追溯：线上故障出现后，需要知道是需求理解错误、模型生成错误，还是人工合并时引入了偏差。
3. 合规记录：部分项目需要记录外部工具、模型版本、输入材料和人工确认范围。
4. 效果评估：团队要比较不同工具的返工率，首先得避免把智能体提交错误地统计为纯人工提交。

因此，重点不应该是训练一个“AI 警察”，而是让提交过程主动留下足够的上下文。

给PR补一份最小来源记录

不必保存完整对话，更不应该把密钥和内部数据塞进 PR。对多数团队来说，下面几项已经足够支持审计。

change_provenance:
  ai_assisted: true
  tool: "TOOL_NAME"
  model: "MODEL_VERSION"
  scope:
    - "generated initial patch"
    - "generated tests"
  human_review:
    reviewer: "ACCOUNT"
    checks:
      - "diff reviewed"
      - "tests rerun"
      - "external calls checked"

这段记录不评价代码好坏，只回答三个问题：工具参与了什么、使用了哪个版本、人工复核覆盖了哪些环节。

实际落地时，可以把它收进 PR 模板，而不是依赖开发者自由发挥。字段要短，选项要明确。表单太长，最后往往只会得到一排机械勾选。

审查顺序也需要调整

过去的审查通常从 Diff 开始。引入编程智能体后，可以把顺序调整为：

任务来源
  ↓
智能体参与范围
  ↓
执行过的命令和外部访问
  ↓
Code Diff
  ↓
测试结果
  ↓
人工确认与合并

第一步先确认需求来自哪里，防止外部 Issue、网页或附件中的内容未经核验就进入执行流程。第二步确认工具实际改了什么。之后再看命令记录、代码和测试，才能把结果放回生产过程理解。

PR 描述仍然很有价值，但它应该是审查入口，不是事实来源。描述里写着“已完成全部测试”，审核者仍要查看测试命令、运行环境和输出记录。

不要把概率判断当成处罚证据

AgenTag 展示了行为指纹的可行性，也暴露了这类方法的边界。

团队统一 PR 模板后，人类与智能体的描述会越来越像；模型升级或提示词变化后，旧指纹也可能失效。开发者修改提交说明、压缩提交记录，都会改变可观察信号。训练数据中某些仓库特征，还可能被模型误当成工具特征。

因此，这类模型更适合做数据清洗、抽样审计和风险提示，不适合单独用于认定某位开发者隐瞒了工具使用。可信的来源记录应来自流程设计，而不是事后猜测。

阅读这篇英文论文时，我用 PDFTranslator 做了双语对照，主要核对实验表格、指标定义和消融结论。涉及数字的判断仍以原论文表格为准。

最后

这篇论文真正有意思的地方，不是它能猜出哪个智能体写了 PR，而是它提醒我们：当代码风格越来越接近，生产过程会成为更重要的审查对象。

AI 辅助开发并不天然降低代码可信度。缺少参与范围、执行记录和人工确认，才会让一份看似完整的 PR 变得难以追溯。

与其在提交以后寻找指纹，不如在提交以前留下来源。

参考资料

• Taher A. Ghaleb, AgenTag: Attribution of AI Coding Agents from Behavioral Fingerprints, arXiv:2608.00966, 2026-08-02。