在软件开发生命周期中，下游的人工审查从来都不是有效的控制手段，无论对质量还是安全而言都是如此。当团队试图借助智能体工程构建自主软件工厂时，这种反模式就变得无法忽视了。
最好的代码审查，是你和其他人坐在同一个房间里，就架构、最佳实践等获得反馈，并把它当作一次学习经历。一旦把这些都规范化，你就只希望工具能捕捉与质量、安全、标准、代码异味、架构等相关的问题。机器最擅长确定性检查，而事实是，这些工具覆盖了运行良好的代码审查中发现的大多数重大问题。例如，对代码异味、密钥扫描、编码标准、架构规则和验收测试运行自动化检查。
把人们聚到一个房间里，共同决定团队希望如何定义系统架构、希望如何转化和捕获客户验收标准，这非常有帮助。但之后你可以使用变异测试之类的工具来验证行为，并启动一个新的子智能体，对照验收标准验证已实现的内容。人的判断应当用在讨论标准、架构、如何定义验收标准，以及需要应用哪些质量、安全和其他检查的房间里。然后把工具和策略规范化为代码，并作为强化后的部署流水线的一部分来运行。
智能体把薄弱的关卡变成了瓶颈
如果人工审查一直都是坏的，为什么现在它变得重要得多？随着构建者采用智能体工程并考虑构建自主软件工厂，这种反模式就变得无法忽视了。过去，人类写代码的速度足够慢，以至于无效的关卡不那么明显。更有甚者，人们从相信自己在审查每一处变更就是在做正确的事中获得安慰。这已不再成立。鉴于智能体生成代码的数量和速度，人工审查成了主要瓶颈。团队要么退而求其次做粗略审查，要么任由队列增长，同时让人工审查每一处变更。一份 哈佛工作论文 发现拉取请求增加了约23%，合并时间增加了约49%，而 Faros AI 的 2026 年报告 发现拉取请求审查时间中位数增加了441%。由此产生的积压不是人员配置问题。你无法扩展一道人工关卡。你要替换它。而且智能体工程引入了一类新的信任边界检查，我们需要加以考虑。
智能体有创作权而无授权
当智能体编写代码时，谁能做什么？你可以让智能体整天编写、提议和推荐。但你不能赋予智能体在生产环境中实际做任何事情的权限。可以这样理解：智能体有创作权而无授权。创作是编写代码、测试和问题单，并提出修复建议。授权是部署和发布到生产环境。智能体可以写任何东西。它不能发布任何东西。正如你绝不应让人手动执行部署步骤一样，你也绝不应让智能体进行部署。部署流水线（又称 CI/CD 流水线）拥有部署到生产环境的权限。开发者和智能体可以请求人工审查，你的检查也可以。但要把代码存在之后的每一次审查都视为缺陷，并从根本上分析为什么这类变更需要一个人。答案往往是一个你可以添加到流水线中的检查。如果不是，那就问一问：在代码存在之前，一个人能否做出那个决定。不可逆的操作仍然需要人，因此这种审批成为流水线在行动前要检查的事项。然后跟踪那些什么也没发现的审查，以及那些跳过审查、后来出问题的变更。你希望审查更少，变更失败率下降。
把智能体读到的一切都视为不可信
想象一个智能体，它读取问题单、日志、工单和评论，然后据此行动。其中每一项都是潜在的攻击面。考虑一份错误报告，里面埋藏着添加一个依赖并提交它的指令。人可能会一眼扫过，而智能体会执行该指令。这不是理论。2026年初， 一名研究人员展示 ，Cline 的 GitHub 仓库中一个恶意的问题标题可以使其分诊智能体从攻击者的 fork 安装一个包。该智能体没有发布密钥。它也不需要。它可以污染与夜间发布任务共享的构建缓存，而该任务的发布令牌同样适用于生产发布。据该研究人员称，另一名行为者随后利用同一路径窃取了 Cline 的 npm 令牌，并在2月发布了一个未授权版本。解决方案是把智能体读到的一切都视为不可信。确保智能体接触的任何东西都不会通向值得窃取的东西：没有密钥，没有令牌，不与任何能够发布的东西共享状态。 Cline 也移除了分诊智能体，但结构性修复是从每个会发布的流程中移除缓存。攻击发生后，它把 npm 发布迁移到 OIDC，不再有可被窃取的长期令牌。
流水线必须赢得密钥
Cline 的发布流水线持有密钥，而它并不是系统中最受保护的东西。流水线只有成为最受保护的东西，才配得上持有密钥。用哈希锁定每一个输入，包括 action、依赖和镜像，并且绝不与不可信任务共享缓存。通过 OIDC 给它一个短期部署身份。拒绝其他所有主体对生产环境的写访问，包括人和智能体。
流水线也是代码，所以智能体也会生成对流水线的变更。这些智能体会对照规格进行检查，并确保权限不会偏离意图。人只需在规格中设定一次流水线定义，检查就会验证每一处提议的变更。对这些变更的检测发生在流水线之外、它无法触及的账户中。如果有一处生产变更无法提供经证实的证据证明是流水线产生的，它就失败。
流水线决定行为与意图
凭借流水线所拥有的权限，它需要判断系统行为是否符合客户意图。它通过对照有记录的客户验收标准检查系统行为来做出这一判断。人的工作从审查代码转变为定义该意图。
要衡量行为，你可以使用变异测试。变异测试向源代码中引入小的缺陷，然后确认你的测试确实能捕获它们。代码覆盖率是做样子的测试，而它产生的变异分数则提供了证据。
要确立意图，一个独立的校验器使用其自身的上下文，对照有记录的验收标准检查系统。这一判断是概率性的，而流水线中的关卡是确定性的。每一条标准都必须有证据地通过。变异测试是在检查测试是否准确，而校验器是在检查你是否在构建正确的东西。
一次决定，每次都执行
人不能掌握密钥，因为下游审查从来都不是有效的控制手段，也无法跟上智能体的步伐。智能体也不能，因为一个被污染的输入就能诱骗它去做一些恶意的事情。所以你和你的团队在一个房间里决定一次，将其编纂成文，然后在流水线中以同样的方式每次都执行。谁拿到密钥？不是智能体。不是人。是流水线。