SQLite发布AGENTS.md：明确拒绝AI生成代码，开辟专属Bug论坛

文章正文

SQLite项目近日在其代码仓库中新增了一份 AGENTS.md 文件，明确表态：不接受AI Agent生成的代码。话说回来，由于AI生成的Bug报告大量涌入，SQLite论坛不得不专门开辟一个新的Bug论坛来应对。这一事件折射出开源项目在AI时代面临的全新挑战。

SQLite的AGENTS.md说了什么

五天前，SQLite在GitHub仓库的master分支中提交了一份 AGENTS.md 文件。有意思的是，这份文件并非用于指导SQLite自身的开发流程，而是专门面向那些将AI Agent指向SQLite代码库的外部开发者。

文件中有两条核心声明：

关于Pull Request： SQLite不接受未经事先协议或缺乏法律文书的Pull Request。所有贡献必须将代码置于公共领域（public domain）。不过，SQLite的人类开发者愿意审阅简洁、编写良好的PR，将其作为概念验证（proof-of-concept），然后由团队自行重新实现这些改动。

关于AI生成代码： SQLite明确不接受Agent生成的代码。但项目欢迎附带可复现测试用例的Agent Bug报告，也欢迎以文档目的提交的补丁或PR来展示可能的修复方案。

从"目前不接受"到"不接受"：态度的强化

一个耐人寻味的细节是，AGENTS.md 文件最近的一次提交专门移除了"(currently)"这个词。原文从"SQLite does not (currently) accept agentic code"改为"SQLite does not accept agentic code"，提交信息写道："Strengthen the statement about not accepting agentic code"（强化关于不接受Agent代码的声明）。

这个微小的改动传递了一个明确信号：SQLite团队对AI生成代码的立场不是暂时性的权宜之计，而是一个经过深思熟虑的长期决策。去掉"目前"二字，意味着他们不打算在可预见的未来改变这一政策。

AI Bug报告泛滥：被迫开辟新论坛

与代码贡献政策同样值得关注的是SQLite论坛正在经历的"AI洪水"。大量AI生成的Bug报告涌入SQLite论坛，质量参差不齐，严重干扰了正常的社区讨论。

开源维护者的精力耗尽（burnout）问题早在AI时代之前就已是业界公认的危机。Linux基金会和GitHub的多项研究显示，大多数关键开源项目仅由极少数核心维护者支撑，他们在处理Issue、审查PR、回应用户的过程中承受着巨大压力。AI生成内容的大规模涌入正在加剧这一问题：自动化工具可以在数秒内生成一份看似合理的Bug报告或补丁，但维护者仍需花费数小时来验证其有效性。

为了应对这一局面，SQLite团队做出了一个务实的决定：将AI生成的Bug报告分流到一个全新的 SQLite Bug Forum。SQLite的创始人 D. Richard Hipp 正在这个新论坛上逐一处理这些问题，并通过一系列提交修复代码库中的相关Bug。

这说明了一个有趣的矛盾：AI生成的Bug报告虽然给社区带来了噪音，但其中确实包含有价值的发现。SQLite将AI Bug报告分流到独立论坛的做法，本质上是一种"注意力保护机制"——通过物理隔离来防止低信噪比内容污染核心社区的讨论空间，同时保留从中提取真实价值的可能性。SQLite的应对策略是分流而非封堵——承认AI在发现Bug方面的价值，但通过隔离来保护主社区的讨论质量。

开源项目的AI治理困境

法律与质量的双重考量

SQLite拒绝AI代码的原因至少有两层。

首先是法律层面：SQLite采用公共领域（Public Domain）授权，这是开源世界中最为彻底的一种知识产权放弃方式——不同于MIT、Apache等许可证，公共领域意味着完全放弃版权，任何人可以无限制地使用、修改和分发代码，无需署名或保留许可证声明。为确保法律严密性，SQLite要求所有贡献者签署专门的法律文书。而AI生成代码的版权归属问题，目前在全球主要司法管辖区均悬而未决：美国版权局已明确表示纯AI生成内容不受版权保护，但"人机协作"作品的边界仍模糊不清。接受AI生成代码可能意味着引入版权状态不明的内容，这对一个以法律严谨性著称的项目而言是不可接受的风险。

其次是质量层面：SQLite并非普通的开源数据库项目。作为全球部署量最大的数据库引擎，它被估计运行在超过一万亿个设备上，内置于每一部iPhone、每一台Android手机、每一个Chrome浏览器以及Windows、macOS操作系统中。SQLite的测试套件包含超过九千万个测试用例，测试代码的行数是源代码本身的数百倍，代码覆盖率接近100%。这种极端的工程文化，使得团队对任何外部代码贡献都保持高度审慎——他们需要理解每一行代码背后的意图，而不仅仅是验证其功能正确性。

AGENTS.md会成为开源项目的新标准吗？

随着以Cursor、GitHub Copilot Workspace、Devin为代表的Coding Agent工具快速普及，越来越多的开源项目可能需要制定类似的政策。这类工具能够自主浏览代码仓库、理解项目结构、生成代码并提交Pull Request，大幅降低了向开源项目贡献代码的门槛——但也带来了大量低质量自动化贡献涌入的副作用。

AGENTS.md 这一文件名本身就很有意味——它与 CONTRIBUTING.md（面向人类贡献者的指南）形成对照，专门为AI Agent设立行为规范。其命名逻辑与 robots.txt 有异曲同工之妙：后者告诉网络爬虫哪些页面可以抓取，前者则告诉AI Agent哪些行为被项目接受。这一文件格式目前尚无统一标准，但SQLite的实践可能推动社区形成共识。

我们或许正在见证一个新惯例的诞生：开源项目不仅需要告诉人类贡献者如何参与，还需要明确告诉AI Agent什么可以做、什么不可以做。

总结

SQLite的做法展现了一种成熟的AI治理思路：不是一刀切地拒绝所有AI参与，而是精细地划定边界。接受AI发现的Bug，但不接受AI写的代码；欢迎AI作为概念验证工具，但最终实现必须由人类完成。这种"AI辅助、人类把关"的模式，可能是当前开源项目应对AI浪潮最务实的策略。

核心要点

• SQLite在代码仓库中新增AGENTS.md文件，明确声明不接受AI Agent生成的代码，但欢迎附带可复现测试用例的AI Bug报告
• 最新提交移除了"currently"一词，将立场从"目前不接受"强化为"不接受"，表明这是长期政策而非临时措施
• 由于AI生成的Bug报告大量涌入，SQLite被迫开辟专门的Bug论坛进行分流管理
• SQLite的策略体现了精细化的AI治理思路：接受AI发现Bug的价值，但坚持代码必须由人类开发者实现
• AGENTS.md可能成为开源项目应对AI Agent的新标准文件，与传统的CONTRIBUTING.md形成互补