TREX：一款运行你的代码的AI代码审查工具

# 构建 TREX：面向 AI 代码审查的代码执行与工件生成 来源：https://www.greptile.com/blog/trex-code-execution 我是 Shlok，Greptile 的软件工程师。我们最近构建了一个代码审查工具，它不仅能审查拉取请求，还能实际运行代码并向你展示哪里出了问题。 1976 年，Michael Fagan 发表了一篇论文 (https://ieeexplore.ieee.org/document/5388086)，在 IBM 引入了正式的代码审查流程。开发者们会打印出代码清单，围坐在一个房间里，逐行阅读代码。 如今我们仍然在屏幕上阅读 diff。AI 工具让这个过程变得更快，尽管大多数工具仍然只是阅读代码。这种方法对于很多漏洞——那些在代码中显而易见地暴露自身的漏洞——是有效的。 问题在于，有一整类漏洞根本不会在代码中显现；它们只有在程序运行时才会出现。比如需要特定状态序列的逻辑错误、页面加载后才会出现的 UI 回归，或者需要真实请求的竞态条件。你可以完美地阅读 diff，但仍然完全错过这些类型的漏洞。 静态代码审查是有天花板的。它可以推理代码说了什么，但无法告诉你代码做了什么。TREX (https://www.greptile.com/trex)（代表 "Test, Run, Execute"）是 Greptile 对这一天花板的回应：一个直接内置于代码审查中的执行层。 ## 编排智能体而不浪费上下文 TREX 最初是作为一个完全独立于 Greptile 的产品开始的，是一个独立生成并运行测试的智能体。我们希望漏洞能因此浮出水面。但并没有。生成测试与发现漏洞并非同一回事。当独立的 TREX 智能体尝试编写测试时，这些测试与用户实际要做的事情并不相关。这造成了不必要的噪音，同时也遗漏了边缘情况。事后看来这很明显，但我们花了比预期更长的时间才学到这一课。 我们将这些智能体设计为独立的，假设这样能让每个智能体拥有自己的上下文窗口。但这也意味着两个智能体各自运行，互不共享知识。它们常常重叠，重复探索代码库的相同部分，而彼此都不知道对方已经发现了什么，最终导致计算资源的浪费。 明显的修复办法似乎是将它们合并成一个智能体。我们试过了，然后遇到了另一个问题：处理完整审查的单个智能体不堪重负。从启动服务、截取屏幕截图，到运行测试，一个智能体要管理的上下文太多了，难以干净利落地处理。 解决方案是让 TREX 共享主 Greptile 审查器 (https://www.greptile.com/agent) 的上下文，而不是作为一个完全独立的产品存在。这是我们第一次在智能体内部管理智能体。与两个独立的智能体不同，这意味着 TREX 不需要从头开始。它继承了 Greptile 审查器智能体已经发现的上下文，拥有自己的上下文窗口，并且其范围限定在它被要求调查的特定问题上。 Greptile 审查器智能体扮演编排器的角色。它读取 diff，识别值得调查的问题，并为每个问题启动一个专用的 TREX 智能体，所有智能体并行运行。这些 TREX 智能体拥有编排器智能体的自由、计算资源和知识。 一个很好的例子是隐藏在认证门禁后的 UI 功能。在本地测试它意味着要设置环境、处理认证、将功能开关置于正确的状态。一个子智能体会自行搞定所有这些，然后带着呈现该功能的截图返回。 架构图展示前后对比：独立智能体审查 PR 与编排器智能体生成并行的 TREX 子智能体，附带沙箱化执行和工件输出 TREX 的第一个版本将发现结果输出为要点列表，列出测试了什么以及发生了什么。这是一个合理的起点，但提供的信息不够充分。 一个智能体或人类审查者读到诸如“测试了结账流程，发现失败”这样的要点，会觉得没什么用。他们无法判断流程中哪里出了问题。如果测试失败，是设置的问题？断言的问题？还是环境问题？我们发现早期的智能体有时会编造它测试得多么彻底，声称自己做了某些实际并未尝试的事情。要点列表让我们无法验证。 解决方法是为每个 TREX 发现结果补充一个多模态的工件集：截图、日志、API 追踪、执行脚本。每种模态都覆盖故事的不同部分。针对特定问题测试过的所有内容有一个全面的视图才是真正重要的。 第一个让我们惊叹的工件是视频。如果你提交了一个动画变更，TREX 会捕获它的播放视频。你可以确切地看到动画的样子，而无需打开本地环境。 工件还需要值得信赖。每个工件都必须给审查者足够的信息来自行验证运行结果。截图、日志、追踪和脚本都在那里，以便人类或下游智能体可以精确查看发生了什么并确认。糟糕的证据比没有证据更糟糕。 工件之所以重要，尤其是对于下游智能体，原因与老师要求学生展示解题步骤是一样的。这类似于小学数学：在展示步骤之前，你无法知道你的答案哪里错了。智能体也是一样。如果工件展示了一切测试步骤如何得出结论，智能体就能精确识别哪一步出了问题。没有这个追踪，它只有答案，而答案无法告诉你该在哪里修复。 如果 TREX 发现了漏洞，它会在 PR 上变成一条评论。如果它运行了一个功能并且一切正常，这会被记录到摘要中，作为该变更确实经过测试的证据。并非每次运行都需要发现问题才有用。 图示展示单个 TREX 发现结果与其工件集的映射：问题被发送到 TREX 子智能体沙箱，输出附带证据的发现结果，包括日志、截图和视频 模型提供商之间的前沿竞赛进展迅速。某个月在代码任务上领先的模型下个月就可能落后。围绕任何单一提供商的 API 紧密构建意味着当排名变化时需要重建。这不是一个可行的长期战略。 从一开始，我们就设计的 TREX 围绕一个模型无关的框架，允许在前沿模型之间热切换而无需重建。这种灵活性比大多数人预期的更深：主智能体和子智能体可以使用不同的提供商。我们可以在同一次审查中运行多个模型。这使得我们很容易根据内部评估，在任何特定时间点选择最佳的模型。 我们当前的评估涉及测量召回率（例如，捕获了多少真实漏洞，对照开源 PR 或客户数据中已被处理的评论来衡量）和精确率（例如，跨运行的一致性：如果你两次审查同一个 PR，是否发现大致相同的一组问题？）。 我们刻意将延迟在评估中的优先级降低。等待审查的开发者宁愿多等一会儿得到一个准确的答案，也不愿得到一个快速但不可信的答案。 我们使用的开源评估框架的性能与原生提供商框架相当。模型无关并没有带来有意义的质量损失——在测试之前你如果问我，我对此并不自信。 TREX 的差异化不在于它运行的是哪个模型。而在于模型周围的基础设施：代码库索引、编排、工件生成、评估框架。我们不需要将智能作为一个差异化因素，因为智能会持续进步。Greptile 的工作是构建框架、架构和工件流水线，这些才在实践中发挥作用。 每次 TREX 审查都会启动一个一次性的沙箱化环境：每个审查一个隔离的计算实例，毫秒级启动，运行完成后销毁。这些环境启动快速、正确隔离执行，并且可以运行真实项目；不仅仅是针对模拟对象的单元测试，而是带有实际依赖的实际服务。许多漏洞只有端到端才会出现。 每次都从零开始会太慢。因此我们依赖可复用的基础镜像和每个仓库的快照。一个仓库可以克隆一次，捕获，然后恢复。每次审查仍然会获取确切的 PR 提交并在执行开始前轮转凭据。缓存加速了设置，而不会将过时状态冻结到环境中。包含太少内容的缓存会慢；包含太多内容的缓存会变得“闹鬼”。TREX 需要有用的那种：足够热以快速移动，足够新以值得信赖。 沙箱是让工件值得信赖的原因。当 TREX 报告某个页面渲染出现布局损坏时，你知道代码实际上是在真实环境中运行的。这与“代码看起来可能会渲染出布局损坏”是不同的说法。 这些组成部分——子智能体架构、工件验证标准、沙箱化执行环境和评估框架——并非独立的功能。它们是一个系统。编排器识别出值得运行的问题。沙箱让运行安全且快速。工件流水线使结果足够值得信赖以便采取行动。评估框架确保合适的模型在执行工作。每个部分都让其他部分更有价值。最终生成的审查是一个可复现的实验，附带了证据。 我们的愿景比现有的代码审查更大。目标是创造一个没有漏洞的世界。为此，我们不再仅仅将自己视为一个代码审查工具。我们希望成为一个验证套件：一个端到端的层，模仿工程团队几十年来所做的事情，但自动化并运行在每次 PR 上。TREX 是迈向这一愿景的又一步。 **尝试 TREX (https://app.greptile.com/#trex)**