Killian Carlsen-Phelan：引导与验证编程智能体

我是 Sonar 的 Killian。Sonar 是独立的代码验证平台。我想把验证带进智能体编程循环：新会话开始时，智能体往往不了解项目约定、编码指南或架构规则。

当你让智能体添加 API 端点时，它必须先弄清现有端点如何工作。它可能很快找到上下文，也可能在整个代码仓库中反复搜索，消耗时间和 token。代码库已有的问题还可能被智能体当作模式重复使用。

如果新引入的问题没有被发现，维护代码质量就会变得困难。我们提出的方案是 Sonar Vortex：这个插件旨在让编程智能体动笔前获得项目上下文，并在工作过程中进行确定性检查。

在一段录制的示例中，智能体不到两分钟便完成了功能和测试，却在临时文件上引入安全问题。Vortex 标出问题并要求继续迭代。缺少的细节是明确的权限设置，测试或审阅者未必能发现。

Sonar 调查了 1,100 多名开发者。我引用的调查结果显示，96% 的受访者并不完全信任 AI 生成的代码，48% 会在推送前完整验证。这些是我展示的调查结果，并不代表所有团队的做法。

我的动画把智能体画成在文件网格中移动的球，下面的 token 计数不断增加。如果问题直到拉取请求审阅时才暴露，工作就会退回智能体，审阅者也必须重复检查。目标是缩短这个循环。

在智能体编写代码之前，Vortex 提供代码关系图和项目自身的标准，例如架构指南与获准使用的库。这些要求可以由项目自行设置，而不必在每个任务中重新寻找。

智能体编辑文件时，SonarQube 会进行快速检查。在这一轮结束前，系统还会要求它运行更深入的分析，包括跨文件数据流。发现问题后，智能体可以修改代码并再次运行检查。

我介绍了对常见编程智能体的支持，以及供其他或自定义智能体使用的可配置 MCP 客户端。这个工作流程希望把 SonarQube 的现有知识带进编程会话，而不是等到后续流水线阶段。

我报告说，Vortex 平均减少 36% 的 token 使用，尤其是在重构等任务中；用户的生产故障减少了 44%。这些数字是演讲中 Sonar 提出的说法，演讲没有说明研究设计。

SonarQube 传统上在流水线中分析安全、可维护性和数据流问题。Vortex 复用已有 CI 扫描的知识，让单文件检查可以结合项目其他部分的信息来理解。

在录制的任务中，会话检测到 Sonar CLI 和钩子系统，并启用了密钥检测。我说，这个插件旨在防止密钥泄露到 GitHub 和智能体上下文，而且我无需把 Sonar 指令粘贴进提示词。

请求的功能是把日志解压到临时文件、复用该文件，并添加测试证明它被复用。编写代码之前，智能体先询问 Sonar 相关类的位置以及适用的 Java 指南。

返回的上下文包括父子架构、现有模式和语言专属规则。团队也可以加入自己的要求。在我看来，任务开始时提供的上下文和引导，是影响智能体表现的重要因素。

智能体查看现有测试后开始实现。在演示中，我把这种有引导的阶段与另一种运行方式作比较：后者需要搜索代码仓库，才能找到相同信息。

智能体创建临时文件并添加测试，随后确认测试结果，对修改过的文件运行 Vortex 分析。我说，每当文件被添加或编辑时，这项分析都会自动触发。

我将确定性代码分析与让 AI 模型审查自己的输出区分开来。所谓确定性，是指对相同代码运行相同分析会得到相同结果。我把它描述为可以与另一层 AI 审查配合使用的机制。

分析返回六项发现：智能体识别出两项位于新写的代码行，四项位于已有代码。我解释，Vortex 要求修正新代码中的问题，同时把已有问题提示给用户了解。

其中一个新问题与默认临时目录中的日志文件有关；在服务器上，这个目录可能是共享的。智能体尝试修复，但下一次分析仍提示问题存在：规则要求明确设置权限。

在这个例子里，第一次修复依赖 Java 的默认设置；在 Mac 和 Linux 上，该默认设置仅允许所有者访问。Sonar 的规则采用更严格的要求，必须明确设置权限。智能体再次修改后，分析又运行了一遍。

我的重点是在编程会话中发现问题：此时变更范围仍然较小，不必等到下一轮审阅。智能体完成迭代后，在交回工作之前还会进行更深入的数据流分析。

最后，我总结了预期收益：减少审阅往返、更早修复问题，并为开发者腾出更多时间。演示展示的是工作流程；前面提到的可靠性和节省数字，则是公司报告的说法。