代码审查的下一站：TREX 让 AI 实际运行代码找 Bug，传统静态审查怎么看？
背景：代码审查遇到了新天花板
2026 年 6 月 17 日，Greptile 发布了一篇技术博客，详细介绍了他们内部构建的代码执行层 TREX（Test, Run, Execute 的缩写）。这篇博客在 Hacker News 上获得了 60 分和 11 条讨论。它的核心论点出乎意料地朴素：静态代码审查有天花板——它能推理代码说了什么，但无法告诉你代码实际做了什么。
这不是空话。当你的 AI 编码 Agent 每天生成几百行代码提交到 PR 时，代码审查正在成为团队的新瓶颈。传统 AI 代码审查工具（CodeRabbit、Greptile 经典版、GitHub Copilot Code Review）都是「读代码」——它们分析 diff、理解代码结构、指出潜在的问题模式。但你有没有遇到过这种情况：diff 看起来完美无缺，审查时人见人夸，部署到生产后却直接报错？
逻辑错误需要特定的状态序列才能触发；UI 回归问题只在页面完全加载后才出现；竞态条件需要真实的网络请求才能复现。这些 bug 在静态代码中永远看不见，它们在程序运行时才存在。
参评对象：两种路线
传统静态 AI 代码审查
主流 AI 代码审查工具——包括 Greptile 经典版、CodeRabbit、GitHub Copilot Code Review、阿里巴巴开源的 Open Code Review（1469⭐）——都遵循相同的原理：读取 diff → 分析代码结构 → 推理可能的错误 → 输出评论。
Open Code Review 的「确定性工程 + Agent」混合架构是目前静态审查路线的代表：确定性部分负责文件选择、规则匹配、位置修正，Agent 负责动态决策和上下文检索。这种方式能覆盖语法错误、类型不匹配、反模式、安全漏洞等大量问题。但它有一个根本的盲区——它无法验证代码是否真正运行正常。
执行验证式审查（TREX）
TREX 的核心区别只有一句话：它不止看代码，它运行代码。
每个 TREX 审查会启动一个一次性沙箱环境（独立的计算实例，毫秒级启动，审查结束后销毁）。这个沙箱不是跑几个单元测试 mock——它会运行完整的应用栈，安装实际依赖，启动真服务。许多 bug 只在端到端运行时才会暴露。
对比维度
1. 审查原理
| 维度 | 静态审查 | TREX（执行验证） |
|---|---|---|
| 数据源 | 代码文本（diff 内容） | 运行时行为 |
| 分析方式 | LLM 推理 + 规则匹配 | 实际执行 + 多模态证据 |
| 覆盖范围 | 代码层面的模式 | 运行时层面的行为 |
| 可验证性 | 靠 LLM 判断 | 有截图、日志、API 调用记录 |
2. 架构设计差异
静态审查工具通常是单 Agent 架构或简单的主从结构。Greptile 的 TREX 则采用了一个更有意思的架构。
Greptile 的主审查 Agent 充当编排器（Orchestrator）：它先读取 diff，识别出值得深入调查的问题，然后为每个问题生成一个独立的子 Agent，所有子 Agent 并行运行。每个子 Agent 都有自己的上下文窗口，但继承了编排器已经发现的信息，不会重复探索。
这个架构花了些时间才磨合好。最初 TREX 作为独立产品运行，一个 Agent 生成并运行测试，结果测试跟实际审查不相关，反而制造噪音。把所有功能塞进一个 Agent 也不行，上下文窗口被塞爆——启动服务、截屏、跑测试堆在一起管不过来。
最终方案是让 TREX 共享 Greptile 主审查 Agent 的上下文，而不是作为独立产品存在。这是他们第一次实现「Agent 管理 Agent」。
3. 输出形式与可信度
静态审查的输出是一条条代码评论：「这段代码可能有空指针风险」「这里缺少边界检查」。这些评论有用，但无法验证——你只能靠自己的经验来判断 LLM 说得对不对。
TREX 的输出是多模态证据集：每个发现都附带了截屏、日志、API 跟踪记录和执行脚本。如果 TREX 发现一个页面布局坏了，它给出的不是说「看起来布局可能有问题」，而是「代码实际渲染了，截图证明页面布局确实坏了」。
Greptile 团队提到 TREX 初期只输出要点列表，例如「测试了结账流程，发现失败」。问题在于——如果测试失败，是环境问题？断言问题？还是真 bug？要点列表不给审查者任何验证余地。后来改为每个发现附带完整证据包才建立了可信度。
4. 模型无关性与评估体系
静态审查工具通常与特定的 LLM 深度绑定。TREX 的设计从一开始就是模型无关的——主 Agent 和子 Agent 可以使用不同的提供商，一次审查中可以同时运行多个模型。主 Agent 使用最擅长代码理解的模型，子 Agent 使用最擅长执行和验证的模型。
Greptile 的评估体系主要衡量两个指标：
- 召回率（Recall）：实际捕捉了多少真实 bug
- 精确度（Precision）：同一 PR 审查两次，结果是否一致
他们有意优先精确度而非延迟——开发者宁愿多等一会儿得到一个可信的结果，也不愿快速得到一个不可信的答案。
5. 适用场景
| 场景 | 静态审查 | TREX |
|---|---|---|
| 语法/类型/样式检查 | ✅ 高效 | ✅ 也能做 |
| 安全漏洞扫描 | ✅ 强项 | ✅ 可运行时验证 |
| 代码反模式检测 | ✅ 强项 | ✅ 可补充 |
| UI 回归/布局问题 | ❌ 看不到 | ✅ 实际渲染截图 |
| 竞态条件/时序问题 | ❌ 看不到 | ✅ 实际运行复现 |
| 端到端功能验证 | ❌ 不能 | ✅ 完整应用栈 |
| 后端 API 行为验证 | ❌ 不能 | ✅ 真实请求 + 日志 |
| 快速反馈（<1 分钟） | ✅ 秒级 | ⏳ 分钟级 |
评分矩阵
| 维度 | 静态审查 | TREX（执行验证） |
|---|---|---|
| 覆盖广度 | ⭐⭐⭐⭐⭐ 几乎覆盖所有代码模式 | ⭐⭐⭐⭐ 运行时相关领域极强 |
| 深层 Bug 捕获 | ⭐⭐⭐ 只能推理 | ⭐⭐⭐⭐⭐ 实际运行 |
| 反馈速度 | ⭐⭐⭐⭐⭐ 秒级 | ⭐⭐⭐ 分钟级（含沙箱启动+执行） |
| 可信度 | ⭐⭐⭐ 靠 LLM 推理 | ⭐⭐⭐⭐⭐ 有证据链 |
| 误报率 | ⭐⭐⭐ 中高（纯推理） | ⭐⭐⭐⭐⭐ 低（因为实际运行） |
| 架构复杂度 | ⭐⭐⭐⭐⭐ 简单部署 | ⭐⭐⭐ 需要沙箱基础设施 |
| 成本 | ⭐⭐⭐⭐ 仅推理成本 | ⭐⭐⭐ 沙箱 + 推理 = 更高 |
| 技术门槛 | ⭐⭐⭐⭐⭐ GitHub 安装即用 | ⭐⭐⭐⭐ 需要仓库可构建 |
选型建议
如果你的团队：AI 编码 Agent 每天提交大量 PR，你担心「代码看起来没问题但上线就崩」——TREX 这种执行验证路线值得关注。它尤其适合：
- Web 前端项目：UI 回归、布局问题、交互流程验证——TREX 的截图和录屏证据对这类变更最有价值
- 后端 API 变更：验证实际请求响应、数据库操作行为，而非仅靠代码推理
- 端到端核心流程：支付、登录、注册等关键路径的运行时验证
如果你的团队：以代码质量规范、样式合规、安全扫描为主要诉求——静态审查工具完全胜任，且成本更低、反馈更快。
最实用的方案可能不是二选一，而是分层审查：
- 第一层：静态 AI 审查（秒级），覆盖语法、风格、常见反模式
- 第二层：执行验证（分钟级），覆盖运行时行为、端到端流程、UI 回归
总结
TREX 代表的不是对静态审查的否定，而是重要的路线扩展。自 1976 年 Michael Fagan 在 IBM 引入正式审查以来，我们一直在「读代码」——打印出来、逐行阅读、讨论差异。AI 让流程自动化了，但本质上还是「读」。
TREX 迈出了从「读代码」到「运行代码」的一步。正如 Greptile 的 Shlok Mehrotra 所说：「TREX 的差异化不在于模型，而在于架构：代码库索引、编排器、证据生成、评估框架——这些才是真正产生差异的地方。」
这种思路值得正在建设 AI 审查管线的团队借鉴。
参考链接：