AutoGPT 开源治理新实验：用 AGENTS.md 和四道门控，把 AI 拉取请求变成可用 PR

当 AI 智能体开始大批量向开源项目提交代码时，维护者的第一反应往往是关闭 PR。但 AutoGPT 的维护者走了一条不一样的路：他们没有拒绝 AI，而是把 AI 提交当作一种新的工作流来管理。

这个转变的起点是一个朴素的发现——AI 智能体不会主动阅读项目里的文档。无论贡献指南写得多么详细，绝大多数 agent 提交 PR 时根本不读 CONTRIBUTING.md。

AGENTS.md：给 AI 看的说明书

AutoGPT 的解决方案是把指令放在 agent 一定会读到的地方：每个代码目录旁放一份 AGENTS.md 和技能文件，作为 AI 智能体的「现场手册」。位置比内容更重要，因为 agent 不会主动跳转。

这种做法的思路很简单：人类读 README，agent 读 AGENTS.md。把两类读者分开处理，比强迫一套文档同时服务两类用户更现实，也更容易维护。

四道门控：把 PR 关进流程里

文件问题解决后，维护者设置了四道门：强制 PR 模板、明确测试计划、CI 覆盖率门槛、CLA 签名。前三道把「质量不达标」的 PR 拦下来，最后一道用流程差异区分人类与 agent。

CLA 之所以能充当「人类探测器」，是因为它需要浏览器登录和 OAuth 流程，而大多数 AI agent 跑在命令行环境里，不会主动完成这一步。维护者通过 CLA 状态，自然区分出哪些 PR 来自人类、哪些来自机器。

这一套组合拳的结果是：AutoGPT 的 agent PR 从最初的「完全不可用」，变成了现在的「可用但不符合路线图」。后者意味着代码本身能跑、测试能过，但维护者还要判断它是否符合项目方向。

对中文开发者的启示

对国内独立开发者和中小团队来说，这套机制的门槛并不高。AGENTS.md 几乎可以照搬 README 的结构改写，CI 覆盖率门槛在 GitHub Actions 里也很容易配置。真正需要投入的是流程设计：明确什么样的 PR 算「通过」，谁来审核 AI 提交。

对企业用户而言，这种治理方式提示了一个新问题：当 AI 开始批量生产代码补丁时，代码审查的瓶颈不再是写代码，而是分流和筛选。开源治理的工具箱，可能需要先一步更新。

后续值得观察的是：是否会有更多项目跟进 AGENTS.md 规范；CLA 作为「人类探测器」是否会因为 OAuth agent 普及而失效；以及类似机制能否从开源项目迁移到企业内部代码库。