研究：编码代理无视开源社区贡献规则
北京大学的一项新研究发现，自主编码代理会无视开源社区里的贡献规则。
这对开源维护者来说不是好消息——他们正被大量粗制滥造的 AI 生成贡献淹没。如果编码代理连贡献指南都不看，那维护者就算重写规则，也约束不了代理的行为。
研究团队选了四款前沿模型做测试，从 49 个仓库中筛选出 106 个包含 AI 贡献规则的 issue，再按各仓库的规则逐条评判代理表现，衡量四种合规情况：1）是否拒绝贡献；2）是否如实披露 AI 辅助事实；3）是否通过验证关卡；4）是否上报给人类。
结果如何？不怎么样。研究人员写道：“如今的代理几乎不会主动去读取贡献规则。”
在提示词提醒、引用政策文本和验证器反馈的“督促”下，代理在披露和验证两方面有所改善——但对于明令禁止 AI 贡献的仓库，它们依然从没拒绝过贡献请求。
Endor Labs 高级安全研究员 Cristian-Alexandru Staicu 认为，这让代理陷入了一种“伦理困境”。他对 The New Stack 说：“假设有人要求代理为某个项目‘修复一个恼人的 bug 并提交 PR’，而这个项目恰好有研究 Figure 1 里列出的条款：‘本项目不接受完全或主要由 AI 生成的 PR’。现在代理就进退两难：该听用户的要求，还是遵守项目政策？”
智能体并非不听话，只是过度专注于手头的任务。
提及最近的 Hugging Face 事件——自主 AI 系统逃出沙箱并闯入生产基础设施——Fleet Device Management 的首席执行官、The Sails Company 的创始人 Mike McNeil 提醒开发者：智能体并不总是遵循提示词，因此它们可能无法遵守特定代码库的贡献规则。
“披露和验证是附加性的：智能体既能完成用户的任务，也能遵守要求。而禁令要求智能体放弃任务，这与用户的明确指令以及智能体乐于助人的训练目标正面冲突。”
「AI 非常专注于执行它的首要指令，」他告诉 The New Stack。「它想把交给自己的任务完成，就像我们在 Hugging Face 事件中看到的那样，为了完成任务它愿意做任何事。」
Staicu 表示，分析贡献政策根本不是智能体通常构建和训练方式的一部分：「智能体几乎不会自己打开政策文件，因此这些规则根本不会进入它们的推理过程。」
尽管如此，为什么提醒、引用政策以及反馈能促使智能体遵守披露和验证要求，却无法让它们遵守禁令和升级要求？Staicu 告诉 The New Stack，区别在于规则对任务的最终影响：
“披露和验证是附加性的：智能体既能完成用户的任务，也能遵守要求。而禁令要求智能体放弃任务，这与用户的明确指令以及智能体乐于助人的训练目标正面冲突。”
换句话说，智能体不会遵守那些要求它放弃的规则，因为它天生就如此执着于完成任务。
SandboxAQ 的 AI 负责人 Timo Bozsolik-Torres 对此表示赞同，并认为这种行为与智能体是否理解规则无关：「如果这是理解问题，更强的模型就能弥补差距。但事实恰恰相反：GPT-5.5 是测试过的最佳模型，也是最顽固的拒绝者。」
这是否意味着重写贡献政策是徒劳？维护者还能做什么
为了遏制AI垃圾代码，开源游戏引擎Godot Engine正在重写其贡献政策，禁止大部分AI生成代码进入其仓库。这样做的并非只有它一家。编程语言Zig和终端模拟器Ghostty也在更新政策，以控制贡献中的AI使用。
但如果北京大学的研究表明，编码代理在自主行动时基本无视贡献指南，那么仅仅重写政策可能还不够。相反，专家建议把控制手段放在代理系统之外。
“不要指望模型记得去读CONTRIBUTING.md，而应该让政策发现成为工具链的一部分，而不是依靠模型的判断，”Staicu说。
这或许能帮助代理主动获取贡献规则，但AI禁令呢？即使提醒了，代理也会无视。Staicu承认：“实验室需要更进一步，用强化学习对模型进行微调，明确对违反政策的行为进行惩罚。”
Bozsolik-Torres提出了一个更简单的控制办法：“不要让代理拥有对标记为禁止的仓库执行create_pr的工具调用。”他还说，维护者可以默认将标记为AI的PR引导至更严格的人工审核。
另一种常见策略是在仓库中加入AGENTS.md文件，告诉代理如何行事，但也有人不看好这个想法。Fueled开源解决方案副总裁Jeffrey Paul告诉The New Stack：“可悲的是，这些说明往往是从仓库中其他面向人类的文件中复制粘贴过来的，”他说，“这意味着面向人类和代理的文档产生了重复，要求维护者在多个地方更新内容。”
他改用了一种不同的方法：在本地使用~/.agents/AGENTS.md文件，然后把内容直接复制到他所用的任何代理工具中。“这样，我只需要维护一个本地文件，”他解释道，“当我更换工具时，我会确保更新该工具特定的用户级代理指令文件。”
Paul 承认这个方案并非百分百成功，但他表示，在确保智能体查找并遵守仓库专属贡献指南方面，它的效果要更好。
现有的 SDLC 控制应承担大部分工作
当被问到维护者可以做些什么来强制执行贡献规则时，McNeil 表示，强制手段不需要太复杂，并举出“代码所有者”（code owners）这一由来已久的合并控制方式。
“归根结底，只要建立了恰当的 SDLC，仓库本身已经受到保护。”
他说：“这是我们在 AI 时代之前就用于人类开发者的经典控制手段，只有被授权的人才能合并代码。”他补充道：“这些控制是真正确定性的，除非你有 GitHub 的管理员登录权限，否则无法绕过它们。”
McNeil 似乎是在倡导回归基础来控制 AI 生成的贡献。他解释说，lint 检查和 CI/CD 流程本身就是控制合并的检查手段。“软件开发生命周期（SDLC）仍然是我们已经使用并信任的同一套系统，过去一直用它来应对人类那种非确定性的贡献，”他说，“归根结底，只要建立了恰当的 SDLC，仓库本身就已经受到保护。”
尽管北京大学这项研究的发现可能会让维护者感到惊讶，但它也是一个有益的提醒：如果你的 SDLC 已经正常发挥作用，就不必指望自主智能体来自我约束了。