我叫Shlok，是Greptile的一个软件工程师。我们最近构建了一个代码审查器，它不仅审查拉取请求，而且还实际运行代码并向您展示出了什么问题。1976年，迈克尔·法根在IBM发表了一篇论文，介绍了正式的代码检查。开发者会打印出代码清单，坐在一起，逐行阅读代码。今天，我们仍然在屏幕上查看差异。然而，AI工具使这个过程更快，虽然大多数工具仍然只是阅读代码。这种方法对于很多错误有效，这些错误在代码中显而易见。问题是，还有一类错误在代码中根本不会显示；它们在程序运行时存在。想想需要特定状态序列的逻辑错误、页面加载后出现的UI回归或需要真实请求的竞争条件。您可以完美地阅读差异，但仍然完全错过这些类型的错误。静态代码审查有一个上限。它可以推断出代码所表达的意思，但不能告诉您代码做了什么。TREX（意为“测试、运行、执行”）是Greptile对这一上限的回应：在代码审查中直接构建的执行层。协调代理而不浪费上下文。TREX最初是Greptile的一个完全独立的产品，作为一个生成并运行测试的独立代理。我们希望由此发现错误，但并没有。生成测试并不是发现错误的同一活动。当单独的TREX代理试图编写测试时，这些测试与用户尝试做的事情没有相关性。这造成了不必要的噪音，并且也错过了边缘情况。从事后看来，这听起来很明显，但我们花了比预期更长的时间来吸取这个教训。我们构建这些代理的出发点是希望它们各自拥有自己的上下文窗口。这也意味着两个代理是独立运行的，没有共享知识。它们经常重叠，重复探索代码库的同一部分，而彼此并不知道对方已经发现了什么，最终导致计算资源的浪费。明显的解决方案似乎是将它们合并成一个代理。我们尝试过，但遇到了另一个问题：单个代理处理完整的审查时负担过重。在启动服务、截屏和运行测试之间，一个代理管理的上下文过于庞杂。解决方案是让TREX共享与主Greptile审查器相同的上下文，而不是完全作为一个独立产品存在。这是我们第一次从一个代理内部管理多个代理。与两个独立代理不同，这意味着TREX不需要从头开始。它继承了Greptile审查器代理已经发现的内容，拥有自己的上下文窗口，并被限于它被请求调查的特定问题。Greptile审查器代理充当协调者。它读取差异，识别值得调查的问题，并为每个问题启动一个专门的TREX代理，所有这些都并行运行。TREX代理可以利用协调者代理的权限、计算资源和知识。一个很好的例子是隐藏在身份验证门后的UI功能。在本地测试需要设置环境、处理身份验证、将功能标志设置为正确状态。子代理独立完成所有这些，并带着渲染功能的屏幕截图返回。TREX的第一个版本以项目符号的方式输出发现，列出测试了什么和发生了什么。这是一个合理的起点，但提供的信息不足。阅读像“测试了结账流程，发现失败”的项目符号的代理或人工审查者不会觉得它很有用。他们无法判断在过程中哪里出现了问题。如果测试失败，它是设置的问题？断言问题？环境问题？我们发现早期版本的代理有时会虚构它测试的彻底程度，声称尝试了它没有尝试过的事情。项目符号让我们无法验证。解决方案是为每个TREX发现的项目符号列表提供多模态的文物集：屏幕截图、日志、API跟踪、执行脚本。每种模态覆盖了故事的不同部分。对于特定问题，有一个全面的测试情况是重要的。第一个让我们感到“哇”的文物是视频。如果您推动一个动画变化，TREX可以捕捉到它播放的视频。您可以确切地看到动画的样子，而无需打开本地环境。文物也需要是可信的。每个文物都必须为审查者提供足够的信息，使他们可以自行验证运行的情况。屏幕截图、日志、跟踪和脚本都有，以便某个人或下游代理可以查看确切发生的事情并进行确认。差的证据比没有证据更糟。文物之所以重要，特别是对下游代理，就是同样的原因，教师要求学生展示他们的工作。