当智能体编写代码时，谁掌握部署权限？

在软件开发生命周期的下游环节，人工审查从来都不是一种有效的控制手段，无论是对质量还是对安全而言都是如此。当团队试图借助智能体工程构建自主软件工厂时，这种反模式就变得无法忽视了。

最好的代码审查，是你和其他人坐在同一个房间里，就架构、最佳实践等获得反馈，并把它当作一次学习经历。一旦把这些内容规范化，你就只希望工具能捕捉与质量、安全、标准、代码异味、架构等相关的问题。机器最擅长确定性检查，而事实是，这些工具覆盖了运行良好的代码审查中发现的大多数重大问题。例如，对代码异味、密钥扫描、编码标准、架构规则和验收测试运行自动化检查。

把人们聚到一个房间里，共同决定团队希望如何定义系统架构、希望如何转化和捕获客户验收标准，这非常有帮助。但之后你可以使用变异测试等工具来验证行为，并启动一个新的子智能体，对照验收标准验证已实现的内容。人的判断应放在讨论标准、架构、如何定义验收标准以及需要应用哪些质量、安全和其他检查的房间里。然后把工具和策略规范化为代码，并作为强化后的部署流水线的一部分运行它们。

智能体把薄弱的关卡变成了瓶颈

如果人工审查一直都是失效的，为什么现在它变得重要得多？随着构建者采用智能体工程并考虑构建自主软件工厂，这种反模式就变得无法忽视了。过去，人类写代码的速度足够慢，以至于无效的关卡不那么明显。更重要的是，人们从“审查每一处变更就是在做正确的事”这一信念中获得安慰。这已不再成立。鉴于智能体生成代码的数量和速度，人工审查成了一个主要瓶颈。团队要么敷衍了事地审查，要么任由队列不断增长，同时让人工审查每一处变更。一份哈佛工作论文发现，拉取请求增加了约23%，合并时间增加了约49%，而Faros AI 的 2026 年报告发现，拉取请求审查时间的中位数增加了441%。由此产生的积压不是人员配置问题。你无法扩展人工关卡。你要替换它。而智能体工程引入了一类新的信任边界检查，我们需要加以考虑。

智能体有创作权而无授权

当智能体编写代码时，谁能做什么？你可以让智能体整天编写、提议和推荐。但你不能赋予智能体在生产环境中实际执行任何操作的权限。可以这样理解：智能体有创作权而无执行权。创作是编写代码、测试和问题，并提出修复方案。执行权是部署并发布到生产环境。智能体可以编写任何内容，但不能发布任何内容。正如你绝不应让人类手动执行部署步骤一样，你也绝不应让智能体进行部署。部署流水线（即 CI/CD 流水线）拥有部署到生产环境的权限。开发者和智能体可以请求人工审查，你的检查也可以。但代码存在之后的每一次审查都应视为缺陷，并追根溯源，弄清为什么这类变更需要人工介入。答案往往是你可以在流水线中添加的一项检查。如果不是，那就问一问：在代码存在之前，人工能否做出这个判断。不可逆的操作仍然需要人工，因此这种审批就变成了流水线在行动前要检查的事项。然后跟踪那些什么都没发现的审查，以及跳过审查、后来出问题的变更。你希望审查更少，变更失败率下降。

把智能体读到的一切都视为不可信

想象一个智能体，它读取问题、日志、工单和评论，然后据此行动。每一项都是潜在的攻击面。设想一份缺陷报告里埋藏着一条指令，要求添加一个依赖并提交。人类可能会略过，而智能体会执行这条指令。这不是理论。2026 年初，一名研究人员展示，Cline 的 GitHub 仓库中一个恶意的问题标题可以使其分诊智能体从攻击者的 fork 安装一个包。该智能体没有发布密钥，也不需要。它可以污染与夜间发布任务共享的构建缓存，而该任务的发布令牌同样适用于生产发布。据该研究人员称，另一名行为者随后利用同一路径窃取了 Cline 的 npm 令牌，并在 2 月发布了一个未经授权的版本。解决方案是把智能体读到的一切都视为不可信。确保智能体接触的任何东西都不会通向值得窃取的东西：没有密钥，没有令牌，不与任何能够发布的东西共享状态。Cline 还移除了分诊智能体，但结构性修复是从所有会发布的流程中移除缓存。攻击发生后，它把 npm 发布迁移到 OIDC，不再有可被窃取的长期令牌。

流水线必须赢得密钥

Cline 的发布流水线持有密钥，而它并不是系统中最受保护的东西。流水线只有成为最受保护的东西，才能赢得密钥。用哈希固定每一个输入，包括 action、依赖和镜像，绝不与不可信任务共享缓存。通过 OIDC 给它一个短期的部署身份。拒绝其他所有主体对生产环境的写访问，包括人类和智能体。

流水线也是代码，所以智能体也会生成对流水线的变更。这些智能体会对照规范进行检查，确保权限不偏离意图。人类在规范中一次性设定流水线定义，检查将验证每一项提议的变更。这些变更的检测在流水线之外、在其无法触及的账户中进行。如果某项生产变更无法提供经证实的证据证明是流水线产生的，它就失败。

流水线根据行为和意图做出决定

凭借流水线所拥有的权限，它需要判断系统行为是否符合客户意图。它通过将系统行为与文档化的客户验收标准进行比对来做出这一判断。人的工作从审查代码转变为定义该意图。

要衡量行为，你可以使用变异测试。变异测试向源代码中引入小缺陷，然后确认你的测试确实能捕获它们。代码覆盖率是测试作秀，而它产生的变异分数则提供了证据。

要确立意图，一个独立的验证器使用其自身的上下文，依据文档化的验收标准检查系统。判断是概率性的，而流水线中的关卡是确定性的。每一条标准都必须有证据地通过。变异测试是在检查测试是否准确，而验证器是在检查你是否在构建正确的东西。

一次决定，每次都运行

人不能掌握钥匙，因为下游审查从来都不是有效的控制手段，也无法跟上智能体的步伐。智能体也不能，因为一个被污染的输入就能骗它去做坏事。所以你和你的团队在一个房间里决定一次，将其编纂成文，然后在流水线中以同样的方式每次运行。谁拿到钥匙？不是智能体。不是人。是流水线。