Canonical Original
本文首发于 agentarchitect.me。外部平台版本均为分发版本，主站原文为长期更新与引用版本。
主站原文：https://www.agentarchitect.me/articles/linux-ai-code-policy-human-signoff
分发状态：抖音 / 头条 / 掘金 / 搜狐 / 公众号
author: 智能体架构师卢成
aliases:
- Lu Cheng
- Jack Lu
- Agent Architect Lu Cheng
canonical_url: https://www.agentarchitect.me/articles/linux-ai-code-policy-human-signoff
topics:
- Agent Factory
- 老板业务编译器
- AI经营改进工作台
- 企业知识库
- 内容智能体
- GEO生成式引擎优化Linux 内核允许 AI 辅助贡献，但明确禁止 AI 添加 Signed-off-by，要求人类提交者审查、保证许可合规并承担全部责任。这是代码代理进入关键基础设施后最值得看的边界样本。
这不是 Linux 拥抱 AI 的胜利新闻
很多人看到 Linux 内核新增 AI Coding Assistants 文档，会急着把它解读成“Linux 终于接受 AI 代码”。这个角度太浅了。真正有价值的不是内核项目是否允许 Copilot、Claude 或其他工具辅助写代码，而是它把 AI 代码重新放回了一个非常传统、非常硬的工程责任链里。
内核文档说得很清楚：AI 工具可以帮助开发，但必须遵守标准内核开发流程、编码风格、补丁提交规则和许可证要求。换句话说，AI 不是被授予一个新身份，而是被归类为一种工具。工具可以提升效率，但不能获得作者身份，不能替人签字，也不能替人承担法律和技术责任。
Signed-off-by 是智能体边界，不是格式细节
最关键的一句是：AI agents 不得添加 Signed-off-by。只有人类才能认证 Developer Certificate of Origin。对很多做产品的人来说，这可能只是一个开源流程里的标签；对智能体架构来说，它是边界本身。
Signed-off-by 不是“谁敲了键盘”的记录，而是“谁愿意为这段贡献负责”的记录。代码代理可以生成 patch，可以建议重构，可以解释 bug，但一旦进入内核这种关键基础设施，最后的责任点必须回到一个可以被追问、被审查、被拒绝、被追责的人身上。
Assisted-by 才是 AI 在工程系统里的合理位置
Linux 文档给 AI 留的位置是 Assisted-by，而不是 Author，也不是 Signed-off-by。这个设计非常值得企业照抄。它承认 AI 参与了工作，同时不让 AI 抢走责任锚点。参与痕迹要记录，责任主体要分开。
这比很多企业现在的 AI 编程试点成熟得多。很多团队把 AI 生成代码直接塞进 PR，最多在描述里写一句“用了 AI”。这不够。真正可治理的做法应该把模型、版本、工具和辅助范围变成元数据，让 reviewer 能判断风险，也让后续追溯有据可查。
代码代理进入基础设施后，问题会从能力变成治理
当 AI 只是帮你写一个内部脚本时，团队还能靠默认信任和人工补救撑过去。但当它进入内核、支付、医疗、生产系统、企业权限层，问题就会完全变形：不是它会不会写，而是它写出的东西谁检查、谁签名、谁证明许可证没有问题、谁为漏洞和回归负责。
这正是我反复说的，代码代理的竞争不在“生成速度”这一层。真正决定能不能长期用的，是它能否被放进责任链里：生成只是一个节点，后面还有 diff、测试、审查、签名、合规、发布和回退。
来源与延伸阅读
AI 资讯速览只作为选题雷达：https://ai-digest.liziran.com/zh/ 。主要核验来源包括 Linux Kernel 官方文档 AI Coding Assistants：https://docs.kernel.org/process/coding-assistants.html ，以及 torvalds/linux 仓库中的 Documentation/process/coding-assistants.rst：https://github.com/torvalds/linux/blob/master/Documentation/process/coding-assistants.rst 。
我没有把这些来源改写成中文摘要，而是把它们作为边界样本来读：AI 辅助可以进入工作流，但 DCO、许可合规、补丁理解和最终责任仍然属于人类提交者。