AI Agent时代的代码质量：从人工审查到质量门禁

liumuhui 3小时前阅读数 1 #区块链

在人类历史的大部分时间里，我们通过代码评审来评估代码质量：有人阅读你写的代码，确保它干净、周到、快速、易于理解，且测试良好。对 agent 而言，这种方法很难扩展；代码量实在太大，任何人都无法通读。因此，越来越多的质量检查必须发生在 agent 周围的 harness、环境和操作系统之中。我依然会阅读和评审代码，但在哪些环节可以放心地以约束作为检查手段，我会非常审慎。

软件质量现在取决于你围绕 agent 设置的约束

Guillermo 的清单是一个很好的检验，看你是否承受得起跳过阅读的代价。注意，每一个“是”实际上都在说明风险有多低——没有用户、一次性代码、原型。一旦风险升高，就必须有人阅读代码。如果不是你在每个 diff 上亲自阅读，那就必须是约束在起作用。

约束通过向 agent 的提议施加测试和确定性约束，来界定系统被允许做什么。正是通过设置并维护这些约束，我们才能构建出可靠交付高质量生产级软件的循环，即使 agent 每天创造数十万甚至数百万个变更。

我们把这些约束称为质量门禁（quality gates），它们形式多样。

它们包括传统的单元测试、属性测试和验收测试，也包括变异测试——生成代码的变体，用同一套测试去运行，确保没有人偷偷引入我们漏掉的 bug。它们还包括圈复杂度、行长度等代码质量指标，有助于保持代码的可读性。

两个人可能在“要不要读代码”上意见相左，但对机制的描述却能达成一致。Guillermo 会读，Bob 完全不读。两人描述的都是一条考验之路——区别只在于这条路上是否坐着一个真人（我不赞同 Bob 的其他观点）。

在决定系统会接受哪些提议、并将它们作为代码变更加以应用方面，约束同样扮演着重要角色。当一个变更提议从运行 agent 的解释器流转到 agent controller，再走向生产环境时，我们已经对它做了足够的检查，足以确信它可以安全发布，而且变更的影响完全在 agent 的范围之内。

agent 可以提出任何提议。你的约束决定一个提议是否足够安全、正确、范围得当且有用，从而可以发布

这个模型带来了很多，但也遗漏了不少环节，这些遗漏如今值得深思。问题之一在于自主性：agent 可能出色地执行自己的意图，但在信息缺失、或它们尝试做的事情含糊不清时，仍可能失败。这一点既适用于任务本身，也适用于任务被 harness、环境和其他组件参数化的方式。

人类未能交付优秀代码的许多原因，同样会落在 agent 身上：脆弱的环境经不起脚本驱动的压力、非确定性构建、权限缺失、测试薄弱。这促使我们追求一个更好的环境：为 agent 提供可信的反馈，允许低损害的失败模式，让成功更容易一步一步积累起来。

我们追求的环境：真实的工作、可信的反馈、低损害的失败

另一个重要问题是信任。我们不能因为现代 agent 足够聪明和健壮，就把意图轻率地交给它，而不去检查正确性。我们从信任出发，但信任必须靠努力赢取。

约束塑造工作、提供反馈并守护生产边界

关于如何在系统周围构建验证结构，我们有很多种建模方式。

根据我的经验，与其只依赖单元测试，不如为约束配备一组范围更广、但经过精心挑选的检查。其理念是每项检查都有明确的职责，范围从类型安全、性能一直到后期的安全扫描。人们也可以定义自己的约束，包括由 ESLint 这类 lint 工具强制执行的架构规则。这些工具中很多都内置了 Hook（Hook），可以在出问题时用来引入 agent 或人工介入。

就目前而言，agent 的输出是有用还是垃圾，很大程度上取决于运营该循环的团队的技能

AI 带来了海量的代码生成和极快的速度，但这也意味着人类越来越难以逐一审查每个变更。你必须反过来有意识地规划人的注意力投向何处。如果你在一个原本以机器速度运行的系统里加入人工检查环节，不要惊讶于生产力会受影响。人类的注意力稀缺而宝贵，我们应该主动把它引导到那些最微妙、最需要人类判断的问题上。只有当约束的自动化护栏被突破时，才应引入下游的人工介入。

人类的“代码评审”将变得非常不同

正确性是一个重要维度，但你可能还关心其他维度，比如可维护性、性能、安全性、效率和可理解性。正如正确性可以分解为多种信号类型，质量的其余方面也是如此。约束设置了多少固然重要，但更重要的是它们是否足够有挑战性，足以达到我们对质量和生产就绪的标准。

软件质量是重要性各异的信号集合，而非单一指标

背压可以由许多工具实现：编译器拒绝无效代码、测试失败、安全策略拦截不良实践、CI 拒绝部署。理想情况下，背压应贯穿整个循环，而不是等所有工作结束后才做一次孤立的评审。

Dex Horthy 对同一循环的图示，来自《Why Software Factories Fail》。绿色框代表他的论点：就目前而言，人工评审应该回到循环之中，而不是被循环取代。

约束与背压在坏工作变成问题之前将其拦下

如果变更的量太大，超出我们工具的消化能力，导致约束无法施行，会发生什么？我们最终会建立一个队列，依赖一个以人类速度运转的验证系统。为了扩展规模，我们希望尽可能多地把工作推进验证循环，贯穿全过程，而不是等到最后。如果能在自动化检查上扩展，我们就能提高整个交付系统的速度和吞吐量。如果验证循环的空间用尽，我们就需要做下面几件事之一。

首先，我们可以扩展验证系统，创造更多容量来约束并驳回新进来的变更。其次，我们可以降低 agent 生成新变更的速度，让验证能赶上工作量。第三，我们可以降低质量门槛，让验证不像原本那样强烈地回推。从扩展的角度看，我们需要准备好同时做这所有的事情。同时，我们也不该忽视一个事实：在某些方向上解除约束，我们实际能完成更多。也许我们可以提供成群的 agent 开发者或自动化软件工厂来创建变更，无需等待我们对每一个变更逐一评审，从而提高 agent 生成变更的速度。

在某些地方，我们可能想给予 agent 更多自由，只要在其他地方保持更严格的约束。通过在我们最关心的地方施加更严格的约束，就能在不牺牲质量的前提下最大化吞吐量。做这些决策时，选项很多。最明显的是，我们不得不在质量的各个维度之间做权衡。正如我们所强调的，安全性非常重要，但我们也必须在交付安全性和按时交付产品之间进行权衡。存在一个光谱，从一端以创新为导向，到另一端以质量为导向。在此过程中，我们必须做出选择，确定自己希望处在光谱的哪个位置。

我们希望把来自环境和系统的清晰反馈传递回我们的 agent 或团队，让人们能够专注于品味、意图和架构等更主观的问题。如果我们能帮助人类待在约束的安全范围内，就能避免他们费力去排查问题出在哪里。

软件质量不只是正确性，还包括可维护性、良好的性能、安全性、效率和易理解性。所有能帮助我们达到这些标准、保持生产顺畅的约束，都会在交付管道中产生背压。

我们需要深思熟虑：在哪些地方施加强约束，在哪些地方移除或放宽约束。在能够同时服务这两个目标的地方，就施加强约束。如果它们没有服务其中任何一个目标，就不要支持它们。同时准备好视情况提高或降低标准。请记住：正是软件系统中不同位置上的这些约束，让软件质量能够被强制执行。

我们应该在最能服务这一双重目的的地方施加强约束，并考虑移除或放宽那些无法很好服务任何一个目的的约束。我们还应该准备好根据需要上移或下调质量门槛。事实上，正是软件系统中各个位置上的这些约束，给质量装上了牙齿。许多情况下，我们可以通过部署新工具或强化现有工具，创造更多背压和约束。所有这些都可以用来驳回大多数变更请求。我们希望在整条管道中构建它们。

我们不想等到管道末端，那时 CI 系统只会简单地告诉我们：不修复问题，就不允许部署。我们希望尽可能早地使用这些信号，通过每一条可能的途径。这个系统中最终的约束，是我们对自己施加的约束：为构建并运行该系统所做出的决策和行动负责。但就像所有其他约束一样，我们需要审慎权衡：希望自己的判断在多大程度上发挥约束、背压和最终检查的作用。