Agentic Code Quality

Agentic Code Quality - 由 Addy Osmani 撰写 - Elevate

Agentic Code Quality

代码质量现在取决于你为代理设置的约束条件。

Addy Osmani

2026年8月8日

在人类历史的大部分时间里，我们通过代码审查来评估代码质量：有人会阅读你写的代码，确保其整洁、周到、高效、易于理解且测试良好。但对于代理来说，这种方法难以扩展；代码量太大，任何人都无法逐一阅读。因此，越来越多的质量检查必须在代理周围的框架、环境和操作系统中完成。我仍然会阅读和审查代码，但我会非常谨慎地选择在哪些地方设置约束条件作为检查。

如今，软件质量取决于你为代理设置的约束条件。

说到质量，代理正在编写你的代码。Sonar 为你提供了质量门禁，使代码可以上线。我曾让一个编码代理构建了一个精美的应用，然后让另一个代理对其进行审查——两次。两次审查结果不一致，重新运行后得到了第三个答案。你不能用抛硬币的方式来决定是否合并代码。Sonar 对每个提交都运行相同的完整检查：深度跨文件分析、风险分布地图，以及对所有人类和代理都适用的统一质量门禁。尝试使用 Sonar。由 Sonar 赞助。

约束条件通过向代理的提议施加测试和确定性限制，定义了系统被允许执行的操作。正是通过设定并维护这些约束条件，我们构建了可靠的循环，即使代理每天生成数十万甚至数百万次更改，也能持续交付高质量的生产软件。

我们将这些约束条件称为质量门禁，它们有多种形式。包括传统的单元测试、属性测试和验收测试。包括突变测试，我们生成代码的变体，运行相同的测试，并确保没有人偷偷引入我们遗漏的漏洞。还包括代码质量指标，如循环复杂度和行宽，这些指标有助于保持代码的可读性。约束条件还在系统接受和应用哪些提议作为代码更改方面发挥着重要作用。当一个更改提议从运行代理的解释器传递到代理控制器，再传递到生产环境时，我们已经对其进行了足够的检查，确信其可以安全上线，且更改的影响完全在代理的范围内。

Guillermo 的清单是一个很好的测试，判断你是否可以承担跳过阅读的后果。请注意，每个“是”实际上都是在说明风险有多低——没有用户、一次性代码、原型。一旦风险提高，就有人必须阅读代码。如果在每次代码差异中都不是你本人，那就必须是这些约束条件。

代理可以提出任何建议。你的约束条件决定了这些建议是否足够安全、正确、范围明确，并对你和你的团队来说是有价值的，从而可以被部署。

这个模型虽然提供了很多功能，但也遗漏了许多关键部分，这些缺失之处值得我们今天深入思考。其中一个问题是自主性：智能体可能在信息完整且任务明确时表现良好，但当信息缺失或任务本身存在歧义时，它们可能会失败。这种现象既可能出现在任务本身，也可能出现在由框架、环境和其他组件对任务进行参数化定义时。人类在交付高质量代码时经常遇到的许多问题，智能体也可能面临：脆弱的环境无法承受脚本驱动的压力测试、不可确定的构建过程、权限缺失、测试薄弱等。这促使我们构建一个能为智能体提供可靠反馈、允许低损害失败模式、并能逐步积累成功的环境。

我们追求的环境应让智能体能够真正开展工作，获得可信赖的反馈，并在失败时造成最小损害。

另一个重要问题是信任。我们不能盲目地将意图交给即使再智能和稳健的现代智能体，而不进行正确性验证。我们从信任开始，但这种信任必须经过严格验证才能建立。

一些约束在工作开始前就会影响工作方式，另一些则在智能体执行过程中提供反馈，还有一些决定其输出是否能够跨越生产边界。

我们有许多方法可以建模如何在系统周围构建验证结构。

在我的经验中，为约束条件设置一组更全面但经过精心挑选的检查，比单纯依赖单元测试更有帮助。其核心思想是每个检查都有明确的职责，这些职责可以涵盖从类型安全和性能到后期安全扫描的各个方面。人们也可以定义自己的约束条件，包括像ESLint这样的代码检查工具可以执行的架构规则。许多工具都内置了钩子功能，当出现问题时可以用来引入智能体或人工干预。

目前，有用智能体输出与低质量输出之间的差异，很大程度上仍取决于操作循环的团队技能水平。

AI为我们带来了高产量的代码生成和快速开发，但这也可能意味着人类难以审查每处变更。此时必须有意识地引导人类的注意力。如果在以机器速度运行的系统中加入人工检查环节，不要惊讶这会降低生产效率。人类的注意力稀缺而宝贵，我们应该主动将其引导到那些需要我们判断的复杂问题上。只有在自动化约束检查失败时，才应引入后续人工处理。

未来的"代码审查"将呈现出截然不同的形态

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

软件质量不是一个单一指标。把它看作一组对你们团队具有不同重要性的信号集合更合适。

反向压力可以通过多种工具实现：编译器拒绝无效代码、测试失败、安全策略阻止不良实践、CI拒绝部署等。理想情况下，这种机制应贯穿整个流程，而不是仅在所有工作完成后的最后一步进行审查。

约束和反压机制让代理在问题发生前就能发现不良工作

如果我们无法应用约束，因为变更量超过了工具的处理能力，最终会构建出一个队列，并依赖以人类速度运行的验证系统。为了实现扩展，我们希望在整个流程中尽可能多地将工作推入验证循环，而不是等到最后才处理。如果我们能在自动化检查中实现扩展，就能提升整个交付系统的速度和吞吐量。如果验证循环的空间耗尽，我们需要采取以下几种措施之一。首先，可以扩展验证系统，创造更多容量来约束并反向推动进入的变更。其次，可以降低代理生成新变更的速度，使验证系统能够跟上工作量。第三，可以降低质量标准，使验证系统减少对变更的反向压力。从扩展角度看，我们需要准备好采取所有这些措施。同时，我们不应忽视这样一个事实：在某些方向上解除约束，实际上可能让我们完成更多工作。例如，通过提供大量代理开发人员或自动化软件工厂，我们或许能提高代理生成变更的速度，无需等待我们逐一审查每个变更。

在某些领域我们可能需要给予更多自由度，只要在其他领域保持更严格的约束。通过在最关注的领域设置更严格的约束，我们可以在不牺牲质量的前提下最大化吞吐量。在这些决策过程中存在许多选择。最明显的是，我们必须在质量的不同维度之间进行权衡。正如我们强调的，安全性非常重要，但我们也不得不在交付安全性和按时交付产品之间做出取舍。从创新导向到质量导向存在一个光谱，我们最终需要在光谱中选择一个位置做出决策。

我们希望从环境和系统向代理或团队发送清晰的反馈，使人们能够专注于品味、意图和架构等更主观的考量。如果我们能帮助人类始终保持在安全约束范围内，就能避免他们需要耗费大量精力去判断哪里出了问题。

软件质量不仅包含正确性。软件质量还包括可维护性、良好的性能、安全性、效率以及易于理解性。所有帮助我们满足这些标准并保持生产流程顺畅的约束，都会在交付管道中产生反压。

我们需要就强约束的应用位置做出明确决策，也要决定在哪里移除或放松约束。在同时服务于这两个目标的领域应用强约束。如果约束无法服务于其中一个或两个目标，就不应支持它们。要准备好根据具体情况提高或降低标准。请记住，软件系统不同阶段的这些约束，正是使软件质量可执行的关键所在。

我们应该在最适合发挥双重作用的地方施加严格约束，并考虑移除或放宽那些未能有效实现任何目标的约束。我们也应随时准备根据需要调整质量标准。实际上，这些分布在软件系统各处的约束才是质量真正具有约束力的关键所在。在许多情况下，我们可以通过部署新工具或强化现有工具来创造更多反向压力和约束。所有这些措施都可以用来抵制大多数变更请求。我们希望在整个流程中构建这些机制，而不是等到流程末端，让CI系统仅仅告诉我们必须修复问题才能部署。我们希望尽可能早地利用这些信号，通过所有可能的路径进行干预。这个系统中的终极约束，是我们对自己所做决策和行动的坚持，这种自我约束需要我们对自身判断的限制程度做出深思熟虑的权衡，既要作为最终的检查点，也要发挥反向压力的作用。

质量体现在我们为代理设置的约束上。因此，当你思考自己应用的质量问题时，请参考这个论述，制定属于你的约束驱动计划。

本文经Pangram 4评估为100%人工撰写。提醒你，如果需要设置质量门禁的起点，Sonar提供了一个相当不错的解决方案。