Tessl 博客：审查不是瓶颈，风险才是

一个 AI 软件工厂可以在人类还没审完上一个变更之前，就生成一个变更、运行测试并打开一个拉取请求。队列不断增长。审查看起来像是瓶颈，因为工作正是在这里停下来的。但更难的问题藏在这个队列背后：什么才能让我们放心地让这个变更继续推进，而无需有人逐行阅读？

回答这个问题需要的不仅仅是一个更好的审查者。它需要一个能够预防某些错误、展示结果、识别重大决策并控制故障的系统。这些才是一个智能体能够赢得行动权限的条件。

为什么审查感觉像是瓶颈

审查同时承担着多项职责。我们要求审查者发现缺陷、解读意图、检查架构、留意安全问题，并判断一个变更是否可以安全发布。当 AI 增加了代码的供给，所有这些责任都汇聚到同一个批准按钮上。增加审查智能体或许能清掉一部分队列，但它让底层的决策原封不动：考虑到可能出问题的地方，多少信心才算足够？

一个干净的 diff 本身无法回答这个问题。对授权逻辑的一行改动，可能比对一个内部报表工具的大规模重构带来更大的风险。即使是正确的代码，在遇到生产数据、意外流量或依赖项行为异常时也可能引发麻烦。更仔细地阅读有帮助，但它无法确立软件运行所依赖的每一个条件。

对于 AI 工厂而言，有用的转变是从审查每一个 diff 转向验证结果和证据，把更深入的审查留给那些后果值得如此对待的决策。这种转变需要四类控制。每一类回答一个不同的问题，且没有任何一类可以替代其他所有类。

首先让错误更不容易发生。测试、静态分析、安全检查与策略检查应作为工厂正常执行的一部分运行。架构约束应尽可能可强制执行：允许的依赖方向、受限的接口，以及敏感操作周围的边界。智能体上下文中的一条指令，弱于智能体无法意外绕过的约束。

审查智能体和对抗性智能体可以挑战一个实现、搜索缺失的用例并探查假设。它们需要有与编码智能体持不同意见的空间，包括访问原始意图以及报告未解决关切的方式。智能体之间的一致只有在它们做了有意义且彼此不同的工作时才是有用的证据。多个智能体重复同一个假设并不会让它更安全。

隔离执行给工厂提供了一个在不暴露生产系统或凭据的情况下进行探索的地方。受限的权限和一次性环境限制了错误工具调用所能触及的范围。这些控制共同在变更到达发布决策之前提高了胜算。它们仍然留下一个残余问题：这个变更是否完成了所要求的事情？

一个通过的测试套件确立的是该套件所检查的内容。它并不会自动确立所请求的结果已经交付。验收场景应将原始意图与可观察的行为连接起来：用户现在能做什么、哪个故障用例被修复，以及哪些现有行为必须保持不变。前后对比证据尤其有用，因为它让所声称的改进变得可检查。

独立的验证代理应针对运行结果评估这些场景，并能访问需求本身，而不仅仅是实现代理对其工作的描述。根据变更的不同，证据可能包括测试结果、API 响应、失败用例的重放，或用户流程的视频。视频可以展示某个工作流成功，但它本身无法证明访问控制是正确的。证据必须与主张相匹配。

工厂应组装一个证据包，将其与意图以及正在考虑发布的精确版本关联起来。这为自主决策提供了可追溯的依据，也为人类提供了比一条自信的完成消息更有用的东西。审查随后可以聚焦于证据是否支持结果、哪些内容仍未测试，以及这种不确定性是否可以接受。

同样的证据在系统的不同部分可以支持不同的决策。对内部仪表板的变更和对支付授权的变更不应仅仅因为都通过了测试就继承相同的发布策略。工厂需要关于系统关键性、客户暴露面、数据敏感性以及故障影响范围的上下文。

依赖关系与被编辑的组件同样重要。一个被众多服务使用的小型工具可能比一个消费者很少的较大服务更具影响。依赖中心性、共享基础设施和下游行为有助于揭示局部错误可能扩散到何处。事件历史补充了仅凭代码仓库可能缺乏的上下文：脆弱的集成、反复出现的故障模式，以及先前假设已被证明不可靠的领域。

可逆性也属于这一评估。回退代码并不一定能撤销数据迁移、外部交易或暴露给错误客户的信息。风险分类应考虑操作的后果和可用的恢复路径。当这种上下文缺失时，工厂有理由收窄其权限或请求人工判断。

有韧性的架构应位于自主性讨论的前列。如果一次错误的变更就能让整个服务宕机，那么架构就让每次发布都成为高风险决策。隔离边界和单元可以将故障限制在有限的人群中。断路器可以防止陷入困境的依赖耗尽调用方。这些特性决定了工厂犯错的空间有多大。

功能标志和渐进式暴露让变更在触达所有人之前先触达小范围受众。速率限制和配额约束了自动化操作可能造成的损害。经过测试的降级方案和回滚路径提供了恢复手段，而自动回滚可以缩短从检测到回归到将其控制住之间的时间。每种机制都需要与故障相匹配：关闭某个功能只有在确实能阻止有害行为时才有帮助。

监控和自动恢复完成了闭环。工厂需要与用户结果和运行限制相关联的信号，以及停止、回滚或升级的明确条件。这些恢复机制也需要验证。代理不应因为存在纸面上的回滚程序就获得更多自主权；它应因为系统已证明能够检测并控制相关故障而获得自主权。

自主权是针对具体决策授予的：编辑代码、合并变更、将其暴露给客户、修改数据或恢复服务。每一项权限都会消耗组织对不确定性和失败的容忍度。四项控制让这一决策变得具体：出错的概率有多大，结果证据有多强，失败会在哪里产生影响，以及在恢复之前可能造成多大损害？

工厂可能会自动将一个经过充分测试的变更发布到一个隔离单元，观察结果，并在约定范围内扩大暴露范围。涉及敏感数据或不可逆操作的变更可能需要更强的验证和人工决策。这种区别来自行动周围的后果和控制。来自智能体的单一置信度分数无法涵盖所有这些。

人类仍然负责设定这些限制，并随着证据的积累重新审视它们。成功的运行、险情和事故应有助于决定权限在哪里扩展或收缩。这创造了一条通往自主权的实用路径：授予有边界的权限，观察发生了什么，并改进那些为下一步提供依据的控制。

对AI软件工厂的下一个改进可能是更好的测试、更清晰的验收场景、依赖关系图或更小的故障边界。这些投资可以消除目前导致每个变更都被送交审查者的不确定性。它们还能在审查遗漏某些东西时让系统更安全，而审查最终会遗漏。

AI工厂不会通过让审查变得完美来实现自主。它们会通过让错误可存活来实现自主。