Addy Osmani 谈 Agentic 代码质量：用约束和质量门管住智能体写码

O'Reilly Radar· Addy Osmani·2026-10-15 18:54· 2 小时前AI 评分56

智能体代码质量

AI 导读

Addy Osmani 在 O'Reilly Radar 发文指出，智能体生成的代码量已超出人工逐行评审的可扩展范围，软件质量应转向依赖围绕智能体设置的约束和质量门，包括单元测试、变异测试、复杂度指标和架构规则等。文章讨论了自主性和信任两大问题，主张把人类注意力集中在最需要判断的细微问题上，并给出扩展验证循环的三种方式：扩容验证系统、降低智能体变更速率或调整质量标准。文中含 Sonar 赞助内容。

正文

以下文章最初发表于 Addy Osmani 的 Elevate 博客 ，经作者许可在此转载。

在人类历史的大部分时间里，我们通过代码评审来评估代码质量：有人阅读你写的内容，确保它整洁、周到、快速、易懂且测试良好。对于智能体来说，这种方法难以扩展；代码太多，任何人都读不完。因此，越来越多的质量检查必须发生在智能体周围的测试框架、环境和操作系统中。我仍然阅读和评审代码，但对于哪些地方可以放心地以约束作为检查，我非常审慎。

软件质量如今取决于你围绕智能体设置的约束。

Speaking of quality, agents are writing your code. Sonar gives you the quality gates to make it shippable. I had a coding agent build a slick app, then asked an agent to review it - twice. The reviews disagreed, and a re-run gave a third answer. You can’t gate a merge on a coin flip. Sonar runs the same complete check on every commit: deep cross-file analysis, a map of where the risk lives, and a quality gate that holds every human and agent to one bar. Try Sonar. Sponsored by Sonar. — **说到质量，智能体正在编写你的代码。** **Sonar** **为你提供质量门，让它可交付。** 我让一个编码智能体构建了一个漂亮的应用，然后让一个智能体来评审它——两次。两次评审结果不一致，重新运行又给出了第三个答案。你不能靠抛硬币来决定是否合并。Sonar 在每次提交时运行同样完整的检查：深度跨文件分析、风险分布图，以及一个让所有人和智能体都遵循同一标准的质量门。 **试用 Sonar。** *由 Sonar 赞助。*

约束通过用测试和确定性约束来检验智能体的提案，从而界定系统被允许做什么。正是通过设置和维护这些约束，我们构建出能够可靠交付高质量生产软件的循环，即使智能体每天产生数十万乃至数百万次变更。

我们称这些约束为质量门，它们有多种形式。包括传统的单元测试、属性测试和验收测试。包括变异测试，即我们生成代码的变体，用同样的测试运行它们，确保没有人偷偷引入我们遗漏的 bug。还包括围绕代码质量的指标，如圈复杂度和行长，帮助保持可读性。约束在系统接受哪些提案并将其作为代码变更应用方面也发挥着重要作用。当一个变更提案从运行智能体的解释器移动到智能体控制器并最终进入生产环境时，我们已经对它做了足够多的检查，确信它可以安全交付，且其变更影响完全在智能体的范围内。

Guillermo's list is a good test for whether you can afford to skip reading. Notice that every "yes" is really a statement about how low the stakes are: no users, throwaway code, prototype. Once the stakes go up, something has to read the code. If it isn't you on every diff then it has to be the constraints. — Guillermo 的清单是检验你能否负担得起跳过阅读的好方法。注意，每一个“是”实际上都是在说明风险有多低：没有用户、一次性代码、原型。一旦风险升高，就必须有东西来阅读代码。如果不是你在每个 diff 上阅读，那就必须是约束。

智能体可以提出任何提案。你的约束决定一个提案是否足够安全、正确、范围合理且有用，从而让你和你的团队可以交付。

这个模型提供了很多，但也遗漏了很多部分，而这些遗漏在今天值得思考。一个问题是自主性；智能体可能很好地应用其意图，但当信息缺失或它们试图做的事情含糊不清时，可能会失败。这既适用于任务本身，也适用于它如何被测试框架、环境和其他组件参数化。人类未能交付优秀代码的许多原因，与智能体可能做的情况相同：在脚本驱动的压力下无法支撑的脆弱环境、非确定性构建、缺失的权限以及薄弱的测试。这促使我们构建一个更好的环境，为智能体提供可信赖的反馈，允许低损害失败模式，并使逐步积累成功变得更容易。

Autonomy is earned by passing verification loops, not granted by the model

我们追求的环境是：智能体可以在其中做真正的工作，获得可信赖的反馈，并且失败时不会造成太大损害。

另一个重要问题是信任。我们不能轻信地将意图交给即使像现代智能体这样聪明且稳健的东西，而不检查正确性。我们从信任开始，但它必须通过努力赢得。

The software factory: intent enters, agents implement, evidence decides what ships

有些约束在工作开始前就塑造了工作。其他约束在智能体工作时提供反馈。还有一些决定其输出是否能跨越生产边界。

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

根据我的经验，为你的约束设置一组更广泛但有意选择的检查，而不是仅依赖单元测试，会有所帮助。其理念是每个检查都有明确的职责，范围可以从类型安全和性能到后期安全扫描。人们也可以定义自己的约束，包括像 ESLint 这样的 linting 工具可以强制执行的架构规则。许多这些工具都有内置钩子，可以在出问题时引入智能体或人类。

目前，有用的智能体输出与垃圾输出之间的许多差异仍然归结为操作循环的团队的技能。

AI 为我们提供了大批量代码生成和速度，但这也可能意味着人类更难审查每一个更改。你必须有意地决定他们的注意力去向。如果你在一个以机器速度运行的系统里加入人工检查，不要惊讶这会影响生产力。人类的注意力稀缺且宝贵，因此我们应该主动将其引导到那些需要判断力的最微妙问题上。只有当约束的自动护栏失效时，才应引入下游人类。

未来的“代码审查”将看起来非常不同。

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

软件质量不是单一指标。把它看作对你和你的团队具有不同重要性的一系列信号。

背压可以通过许多工具来实现：编译器拒绝无效代码、测试失败、安全策略阻止不良实践、CI 拒绝部署。理想情况下，它存在于整个循环中，而不是作为所有工作最后的一次性审查。

约束和背压让智能体在不良工作成为问题之前就将其捕获。

如果我们无法施加约束，因为变更量超出了我们工具所能消化的范围，会发生什么？我们最终会构建一个队列，并依赖一个以人类速度运行的验证系统。为了扩展，我们希望尽可能多地将工作推入整个验证循环中，而不是等到最后。如果我们能在自动化检查范围内扩展，我们就能提高整个交付系统的速度和吞吐量。如果验证循环中没有空间了，我们需要做以下几件事之一。第一，我们可以扩展验证系统，创造更多容量来约束和回推传入的变更。第二，我们可以降低智能体生成新变更的速率，以便验证能够跟上工作量。第三，我们可以降低质量标准，使验证不会像原本那样强力回推。从扩展的角度来看，我们需要准备好做所有这些事情。与此同时，我们不应止步于认识到，在某些方向上解除约束实际上可以让我们完成更多工作。也许我们可以通过提供智能体开发者集群或自动化软件工厂来加快智能体生成变更的速度，从而无需等待我们逐一审查每个变更。

而在某些地方，我们可能希望给它们更多自由，只要我们在其他地方保持更严格的约束。通过在我们最关心的地方提供更严格的约束，我们可以在不牺牲质量的情况下最大化吞吐量。在这些决策中，有许多选项。最明显的是，我们必须在不同维度的质量之间进行权衡。正如我们所强调的，安全性非常重要，但我们也必须在交付安全性和按时交付产品之间进行权衡。从一端以创新为中心到另一端以质量为中心，存在一个谱系。在这个谱系的某个位置，我们必须做出选择。

我们希望将来自环境和系统的清晰反馈发送回我们的智能体或团队，以便人们可以专注于更主观的品味、意图和架构问题。如果我们能帮助人类保持在约束的安全范围内，我们就可以避免他们费力去弄清楚哪里出了问题。

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

我们需要深思熟虑地决定在哪里施加严格约束，在哪里移除或放宽约束。在同时服务于这两个目标的地方施加严格约束。如果它们不能服务于其中一个或两个目标，就不要支持它们。准备好根据情况提高或降低标准。并记住，软件系统中不同位置的这些约束，正是使软件质量可强制执行的关键。

我们应该在最能发挥这种双重作用的地方施加严格约束，并考虑移除或放宽那些对两种目的都不太有用的约束。我们还应该准备好根据需要上下调整质量标准。实际上，软件系统各处的这些约束正是让质量真正有威慑力的东西。在许多情况下，我们可以通过部署新工具或强化已有工具来制造更多反向压力和更多约束。所有这些都可以用来抵制大多数变更请求。我们希望在整条流水线中构建它们。我们不想等到流水线末端，那时我们的 CI 系统只会告诉我们，不解决问题就不允许部署。我们希望尽可能早地、通过一切可能的途径利用这些信号。这个系统中最终的约束，是我们对自己施加的约束：要为我们为构建和运营该系统所做的决定和行动负责。但像所有其他约束一样，我们需要深思熟虑地权衡：我们想让自己的判断在多大程度上进行限制、施加反向压力并充当最终检查。

质量存在于我们围绕智能体所设置的约束之中。因此，当你思考自己应用的质量时，请拿这个问题陈述，制定出你自己的约束驱动计划。

来源：O'Reilly Radar · oreilly.com