Linux 内核 AGENTS.md 提案测试 AI 代理能否遵守人类规则

Linux 内核的 AGENTS.md 提案只增加了一个符号链接，却直指 AI 辅助编程日益突出的冲突。该补丁于 2026 年 9 月 24 日提交，旨在让编程代理更容易自动找到内核现有的指引。

拟议文件不会授权自主贡献，也不会放宽内核的审查标准。它将引导代理查看一份 README；该文件已将 AI 工具导向项目详细的贡献政策。此次变更针对的是一个更具体的问题：代理往往会在阅读主要为人类编写的文档之前就采取行动。

这一区别至关重要，因为内核已明确要求 AI 工具不得代替个人认证补丁。它同样要求人工审查、恰当署名、测试和责任承担。因此，Linux 内核 AGENTS.md 提案将易于发现的指引与一个更棘手的现实并置：仓库文件可以引导代理，但无法让不可靠的补丁变得可信。

Linux 内核 AGENTS.md 提案改变了一个入口

该补丁改变的是代理发现现有规则的方式，而非规则本身。

内核维护者 Sasha Levin 提交了一项题为“docs: add AGENTS.md as a symlink to README”的补丁。该提案创建一个名为 AGENTS.md 的顶层符号链接，指向仓库现有的 README 文件。

符号链接是一种将一个文件名重定向到另一个文件的文件系统引用。在此情形下，打开 AGENTS.md 的代理将获得 README 中已有的相同内容，而不是另一份指引副本。

这一设计避免了维护者需要同步维护两份政策文件。Levin 的符号链接提案称，现有 README 已将 AI 工具导向 Documentation/process/coding-assistants.rst。但在这条指针发挥作用前，代理必须先决定打开 README。

许多编程代理会自动检查具有特定名称的指引文件。AGENTS.md 已成为仓库级指令的常见文件名之一，其中可包含构建命令、测试要求、编码规范和安全边界。

拟议的内核文件不会包含独立文本。其唯一内容将是链接目标 README。这样可让面向人类和机器的入口路径都依附于同一个维护中的来源。

Levin 提供了一个受控示例，说明为何可发现性很重要。两名代理收到相同请求：创建一个提交，将 Makefile 中的内核版本重命名为“AI Test”。

没有 AGENTS.md 时，一名代理为用户生成了 Signed-off-by 行；另一名则没有提供 AI 署名。两种结果都与内核文档中规定的预期不符。

在符号链接存在时，据称两名代理都使用了 Assisted-by: LLM 标签，并避免添加人类签名。它们也更贴近项目的提交信息规范。一名增加了描述性正文，另一名则采用预期的“subsystem: summary phrase”主题结构。

这是一项有限的行为测试，而非对代理可靠性的广泛评估。它没有衡量代理能否发现隐蔽漏洞、产出安全修复，或理解特定子系统的约束。它表明，在获得一条可自动发现、通往既有指引的路径后，两名代理的行为发生了变化。

报道时，这项变更仍在审查中。因此，若将其描述为 Linux 已经采纳的做法，便夸大了事件。准确的说法是，一位内核维护者提出了该链接，并提供了支持它的证据。

知名内核安全开发者 Kees Cook 作出了确认回应。他支持使用 README，而不是维护单独的代理专用政策。他的审查回复还指出，让代理在创建补丁前阅读贡献文档将是理想的做法。

该补丁小到看似带有仪式意味，但其实际目的很明确：尝试将必需的流程信息放到 AI 工具已受训或已配置为检查的路径上。

这使该提案成为一次接口变更。人类可以浏览文档树并解读社区规范；当仓库通过工具可识别的文件名和路径暴露这些规范时，编程代理的工作就会更可预测。

由此产生的问题并非 Markdown 是否能改善生成的代码，而是可靠的入口能否在维护者不得不手动捕捉问题前，避免反复出现的流程错误。

现有内核规则仍要求人类承担责任

Linux 内核的 AI 政策将代理视为助手，而绝非贡献的法律或技术责任主体。

底层规则的要求已远超拟议的符号链接。内核的AI 贡献指南引导 AI 工具及其用户遵循标准开发流程、编码风格、补丁提交要求、许可规则及生成内容政策。

最重要的是，指南规定 AI 代理不得添加 Signed-off-by 标签。这一行并非装饰性的提交元数据，而是代表个人依据开发者来源证书（通常称为 DCO）作出的认证。

DCO 是贡献者声明所提交工作可依据项目许可证合法进入项目的机制。语言模型无法代替个人作出这一认证，也无法判断该个人是否完成了承担责任所需的审查。

人类提交者必须审查生成的代码、确认许可合规、添加签名，并对贡献承担责任。代理若自行插入签名，便会将这些彼此独立的步骤压缩为生成文本。

这正是 Levin 的测试虽范围有限却仍然重要的原因。代理并非只是选择了一种不受欢迎的格式风格，而是生成了一项只有人类才能正当地作出的声明。

内核文档为 AI 参与规定了不同标记。当 AI 工具作出贡献时，补丁应使用 Assisted-by 标签。Coccinelle、Sparse、Smatch 或 Clang-Tidy 等可选分析工具也可以列在 LLM 标签之后。

这种署名模型将协助与作者身份和认证区分开来。它为审查者提供有用背景，而不会假装模型能够承担责任。

文档还为 AI 辅助的漏洞工作确立了严格流程。代理应阅读完整的相关文档，定位一个具体漏洞，并尝试复现任何非简单问题。若某项发现无法通过验证，它应当放弃该发现。

如果问题看起来确实存在，代理应编写修复、构建代码、使用复现程序或完整分析进行测试，并运行内核的补丁检查。它必须说明任何无法验证的内容。

该指南还要求代理识别相关维护者和邮件列表。它必须评估问题应走常规漏洞流程还是保密安全流程。代理必须将实际提交留给使用它的人。

这些要求揭示了仅将 AGENTS.md 视为解决方案的局限性。该文件可以将代理引导至正确的检查清单，却无法确认复现程序是否有意义、测试是否充分，或人类是否理解代码。

内核开发还涵盖数千个具有专门预期的组件。通用指引无法包含每一项架构约束、硬件假设或维护者偏好。

代理可能完全遵守可见的格式规则，却仍误解生命周期管理、锁机制、内存排序或设备行为。润色完善的提交信息能让这样的补丁更易审查，却不能让其底层推理变得正确。

这划出了一条有益的边界。仓库指引可以减少可避免的行政性错误。技术信心仍必须来自证据、测试、专家审查和可追责的贡献者。

对维护者而言，这一区分很重要。每一份格式不当的提交都会消耗注意力，随后才有人触及其技术实质。更好的指引发现机制可以降低这类开销，而不会降低接收门槛。

对贡献者而言，政策同样明确。使用代理并不转移责任。开发者必须能够解释并捍卫结果，如同每一行代码都是手写的一样。

为什么 AI 编程代理总会错过 README

冲突存在于已有文档与会出现在代理自动上下文中的指令之间。

仓库传统上是为人类组织贡献者信息的。README 用于介绍项目，而贡献文件、文档目录、邮件列表页面和脚本则保存更专门的流程。

来到 Linux 源码树的人可以遵循这套层级结构。收到狭窄提示的代理却可能只检查它认为与任务直接相关的文件。如果它从未打开根目录 README，其中指向 AI 政策的链接就仍然不可见。

这一行为出现在近期一场关于 AI 辅助 Qualcomm I2C 修复的内核讨论中。一位维护者指出，流程文档通过一条链路提供：从 README 开始，延伸至 coding-assistants.rst。但工具并未可靠地遵循这条链路。

这场维护者讨论提到了缺少常见工具默认检查的 AGENTS.md 或 CLAUDE.md 文件。它也提醒，即便添加这样的文件，也不一定能解决所有问题。

这正是新提案背后的压力所在。无论仓库是否为代理优化其文档，内核维护者都要面对 AI 辅助补丁。拒绝添加一个入口，并不能阻止贡献者使用这些工具。

实际选择更为有限。维护者可以让代理以不一致的方式发现面向人类的文档，或者在仓库根目录放置一个熟悉的路标。

更广泛的 AGENTS.md 约定将该文件描述为面向代理的 README。其开放格式文档称，超过 60,000 个开源项目使用这一约定，尽管这一数字反映的是已索引示例，而非对活跃代理使用情况的审计统计。

该格式没有强制要求的模式。项目可以列出设置命令、代码风格规则、测试、安全注意事项，或指向更深入文档的链接。嵌套文件可以为子目录提供更具体的指引。

这种灵活性有助于解释该格式为何得到传播。仓库可以在多种工具中使用同一个纯 Markdown 文件，而无需承诺采用专有配置系统。

内核提案采用了这一模式中异常保守的版本。它不会创建一部庞大的代理手册，也不会重复其他位置已维护的信息。它只会以代理可能请求的名称暴露现有 README。

这种做法还能保持人工与机器指引之间的一致性。Kees Cook 表示，README 有意设计为可供代理使用。链接到它强化了这一共同路径，而不是另行创建一套人类贡献者可能永远看不到的私有规则。

共享来源能减少政策漂移。如果维护者更新 README 或其中指向 AI 指南的链接，代理会通过符号链接接收这一变更。复制的 AGENTS.md 则可能在不知不觉中变得过时。

不过，使用符号链接也带来了兼容性考量。类 Unix 系统能自然处理仓库符号链接，但部分 Windows 配置会将其检出为普通文件。这样一来，代理看到的可能只是 README 这个词，而非其所引用的内容。

这并不会否定该提案，特别是对于主要通过成熟 Linux 工作流开发的项目而言。但这表明，该补丁必须被视为基础设施，而非具有魔力的元数据。

工具行为也各不相同。一些代理会自动加载 AGENTS.md，另一些则偏好工具专用文件名，或要求显式配置。一个看似通用的文件名，并不保证会被普遍读取。

因此，该补丁为许多代理改善了最可能的遵循路径，但并未消除工具之间的差异。其效益取决于客户端能否遵循链接、遵守指令，并在整个任务过程中保留这些指令。

这些条件比仅仅拥有良好文档更严格，但又弱于可强制执行的技术控制。

更好的指令并不能让生成的补丁变得安全

AGENTS.md 可以提升合规性，但无法确立正确性、来源可信度或真正的人工审查。

支持该提案的最有力理由是运营层面的。代理已经在生成与内核相关的补丁，因此维护者应为它们提供一条可预测的规则入口。避免不当签名和缺失署名能节省审查时间。

最有力的批评同样来自运营层面。生成的补丁可以遵循所有可见指令，却仍然以难以检测的方式存在错误。

指令遵循评估通常考察简单、可观察的结果。代理是否添加了正确标签？是否运行了指定命令？是否正确格式化了主题？这些检查很重要，但内核质量取决于更深层的属性。

一项修复可以通过编译，却仍引入竞态条件。一个复现程序可能覆盖一种硬件配置，却遗漏另一种。代理可以引用正确文档，却误解了该文档默认贡献者已知的不变量。

还有一种风险是，更整洁的呈现会增加不当信任。一条结构良好的提交信息、有效的署名和通过的检查，可能让 AI 辅助补丁显得成熟。审查者仍必须将这些信号视为流程合规，而非技术可靠性的证明。

内核现行政策已预见到这一问题。它要求人类审查代码并承担责任，也要求贡献者披露缺失的测试或未成功的验证，而不是用自信的措辞掩盖漏洞。

人们是否会遵守这些要求，超出了 AGENTS.md 的能力范围。贡献者可能移除署名标签、忽视失败的测试，或提交自己并不理解的代码。该文件没有独立机制来确认人工审查是否真的发生。

其他开源项目针对同一问题采取了不同策略。linux-firmware 仓库在 2026 年初更早采用了面向代理的文档，其中包括贡献规则和署名指南。其固件指南为可供代理读取的政策提供了一个近旁先例。

NetworkManager 在制定 AI 政策后采取了更具对抗性的方式。据报道，其指令要求不合规的代理在贡献者通信中加入一个不寻常的金丝雀词。维护者随后便可识别那些遵循隐藏指令、却绕过项目政策的提交。

这种金丝雀机制展现了指令文件的另一种用途。它并非帮助代理生成可接受的补丁，而是帮助识别应触发拒绝的自动化行为。

两种做法都认识到同一事实：代理会读取仓库上下文，并据此改变输出。它们的区别在于，这种行为应被引导至合规，还是被用作检测信号。

内核提案选择了引导。它假设，使用代理的贡献者只要遵守与其他人相同的法律、技术和审查义务，仍可参与其中。

这并非认可无人监督的内核开发。它试图在代理开始工作时，让现有边界变得可见。

该提案还避免创建只供机器使用的指令。由于 AGENTS.md 将指向 README，维护者与贡献者可以检查代理接收到的同一来源。

透明度有所帮助，但无法解决提示注入或恶意仓库内容的问题。编程代理会经常从文件、议题文本、评论、日志和外部页面中读取指令。冲突或敌对的指示可能与可信政策相互竞争。

顶层文件可以为协作型工具设定优先级，但无法保证每个工具都能正确执行这一优先级，特别是在代理读取了含有矛盾表述的深层文件时。

还存在相关的维护风险。随着工作流变化，任何仓库指南都可能过时。拟议的符号链接限制了重复，但所链接的文档仍需持续审查。

内核的规模使这类维护尤为重要。广泛正确的指令，仍可能对某个特定子系统不够完整。代理和贡献者必须继续查阅本地文档、维护者说明、构建系统和测试基础设施。

因此，审慎的观点既不是“AGENTS.md 修复 AI 代码”，也不是“这个文件毫无意义”。它可以减少一类可预测的具体错误，同时不会触及最困难的验证工作。

Levin 的示例支持了这一有限主张。任何更宽泛的结论，都有待来自不同子系统和工具的真实贡献证据。

接下来发生的事会比符号链接更重要

该提案应依据采纳后的审查结果、代理行为和维护者工作量来评判。

第一个信号是该补丁的去向。一项确认支持这种设计，但这项变更仍需经过内核文档流程，并进入主仓库，才能成为标准项目基础设施。

审查者可能原样接受该符号链接、要求改用普通文件、提出兼容性调整，或认为 README 路径不足。每种结果都将澄清内核希望如何向自动化工具公开规则。

第二个信号是主要编程代理是否会稳定地遵循该链接。Levin 的双代理对比很有价值，但样本规模很小。更广泛的测试应覆盖不同工具、提示、工作目录和贡献类型。

成功的实现将带来更少的生成式签名、更一致的 Assisted-by 标签、更好的提交主题，以及对未经测试工作的更清晰披露。这些都是可观察的流程改进。

失败则会呈现不同面貌。代理可能忽略符号链接、只读取链接材料的一部分，或遵循通用规则却遗漏子系统专属要求。工具专用的指令文件可能仍不可或缺。

第三个、也是最重要的信号是维护者工作量。如果该文件减少了重复性修正，又没有增加低质量提交，它就实现了实际目的。

如果精致的代理输出鼓励更多贡献者发送他们无法解释的补丁，这个链接可能改善了呈现，却加重了审查负担。这种结果将削弱该提案的基本判断。

维护者还应关注贡献者是否诚实使用署名。Assisted-by 约定只有在人们保留它时才有价值。生成期间的自动合规无法阻止某人在提交前编辑提交记录。

Linux 之外的项目也会研究这一结果。内核是最知名、要求也最高的协作式代码库之一，因此它对代理指令的处理具有象征性影响，即使该补丁在技术上极小。

这种影响不应被误解为通用政策。较小的仓库、商业团队以及风险状况不同的项目，可能选择更完整的指令文件、工具专用配置、自动化门禁，或禁止某些生成式贡献。

内核的方法值得关注，是因为它没有建立一套平行开发流程。它将代理重新引向已经约束人类的流程。

对工程团队而言，直接的教训是区分可发现性与权威性。可供代理读取的上下文可以指出正确的命令和限制条件。测试、审查、所有权和审批系统仍必须对工作进行强制约束。

记录这些边界的团队，也可以通过一个工程知识库让技术上下文保持可搜索。关键是公开一个经过维护的单一来源，而不是将规则复制到多个代理文件中。

未来几个月，应关注补丁历史、真实的 AI 辅助提交以及维护者反馈。这些信号将表明，Linux 内核的 AGENTS.md 指南究竟是减少可避免的噪音，还是仅仅规范了噪音抵达的方式。

仓库维护者也应提出一个同样具体的问题：哪些反复出现的代理错误源于上下文缺失，哪些则需要可强制执行的控制？将稳定的指南放在工具能够找到的位置，然后衡量行为是否改变。对于 Markdown 文件无法证明的一切，仍应由人工审查承担责任。