如何构建代码审查智能体：从基础流水线到五大架构优化

如何构建代码审查智能体：从基础流水线到五大架构优化

原文：How to build a code review agent | 作者：Daksh Gupta | 日期：2026-10-09

📝 摘要

在 AI 生成代码爆发式增长的背景下，数千家科技企业（如英伟达与 Coinbase）每天将超过 1% 的 GitHub PR 交由代码审查智能体进行前置防护。Greptile 联合创始人 Daksh Gupta 基于其大规模审查实战经验，深度剖析了自研 AI 代码审查系统的核心架构与演进挑战。文章首先指出了基于通用模型搭建朴素审查沙盒时必然踩中的五大痛点（漏报难测、缺乏代码库全局上下文、单次审查成本高昂、频繁挑刺以及审查意见不一致），随后系统性提出了五大架构优化策略：利用历史缺陷数据集开展爬山评测（Hillclimbing）、通过异构模型反转（Model Inversion）消除作者与审查器的同源盲区、利用代码库 Wiki 与事故遥测集成构建深度上下文、借助沙盒运行与计算机操作（Computer Use）开展自主端到端动态测试，以及基于子任务分层路由模型以大幅削减 90% 推理开销。

📋 术语表

英文	中文	说明
codebase indexer	代码库索引器	自动化扫描、分析并维护全代码库架构语义与跨仓库知识 Wiki 的索引系统
computer use	计算机操作	大模型通过视觉识别直接驱动屏幕、鼠标点击与键盘输入以模拟真实用户操作的能力
FDE (Forward Deployed Engineer)	前线部署工程师	深入客户现场协助定制化部署、基础设施调优与环境接入的专业工程师
hillclimbing	爬山评测 / 爬山法	借助带缺陷标签的历史 PR 基准集，通过微调 Prompt 与配置使检出率逐步提升的闭环评测方法
model inversion	模型反转 / 异构模型审查	识别代码作者所用的大模型（如 Claude），并刻意选用异构竞争模型（如 GPT/Codex）进行审查以打破同一模型盲区的策略
second order effects	二阶效应 / 间接连锁影响	局部代码变更对当前文件以外的外部系统、契约或下游依赖所引发的非显式副作用
dev server	开发服务器	在沙盒容器中启动的应用本地测试服务，用于模拟真实运行时并捕获运行时异常
false positive	误报 / 假阳性	AI 审查器指出了实际上代码逻辑完全正确或无影响的伪缺陷
MCP gateway	MCP 网关	汇聚企业内部文档、Jira、Linear 等多方数据源的模型上下文协议服务网关
token cost	Token 成本	智能体在多轮上下文交互、大批文件阅读与代码推理中消耗的 API 费用

---

正文（双语对照）

Adapted from a talk I gave at AIE NYC in October 2026

本文改编自作者于 2026 年 10 月在纽约人工智能工程师大会（AIE NYC）上所作的专题技术演讲。

My name is Daksh. I’m one of the cofounders of Greptile. We build agents that review and test pull requests, catching logic and security bugs before merge.

我是 Daksh，Greptile 的联合创始人之一。我们致力于构建能够自动审查与测试 Pull Request（PR）的智能体，在代码合并之前精准截获业务逻辑漏洞与安全缺陷。

图 1：构建 AI 代码审查智能体（Building an AI code review agent）

Thousands of companies like Nvidia and Coinbase use Greptile to check their changes before merge. To give you a sense of scale, more than 1% of PRs on GitHub go through Greptile each day.

如今，包括 Nvidia 和 Coinbase 在内的数千家企业都在使用 Greptile 在代码合并前执行自动检查。为了让大家直观感受这套系统的运转体量：每天 GitHub 上有超过 1% 的 Pull Request 都会经由 Greptile 进行流水线审查。

图 2：每天 GitHub 上超过 1% 的 PR 经由 Greptile 审查（More than 1% of GitHub PRs）

There are three main reasons companies choose Greptile.

企业之所以选择 Greptile，主要源于三大核心技术优势：

1. First, codebase context: Greptile is very good at indexing large codebases, so it can catch complex bugs that are not in the diff but second order effects of the diff.

2. Second, Greptile runs your code: most code review agents are really just using frontier models to read the code to find bugs. Greptile actually installs your dependencies and spins up a dev server in a sandbox, clicks around, mocks API inputs, pressure tests endpoints to find things that AI alone could never catch.

3. Third, we’re really good at allocating inference. We use the right-sized model, both frontier and open source, for each subtask of the code review and testing process. We also give agents an array of specialized tools to check code. By doing this, we can get better results than pure Codex or Claude Code review at a tenth of the cost.

4. 第一，全局代码库上下文（Codebase context）：Greptile 极其擅长对大型复杂代码库建立索引，因此它不仅能发现直接写在 diff 行内的浅层错误，更能准确捕获不在当前变更行内、而是由该变更所引发的**二阶连锁反应（Second order effects）**隐蔽缺陷。

5. 第二，Greptile 会真正运行你的代码：市面上绝大多数代码审查智能体本质上只是丢给前沿模型进行静态文本阅读来挑刺。而 Greptile 会在沙盒中真实安装项目依赖并启动开发服务器（Dev Server），模拟端到端点击、构造 Mock API 输入、对核心接口执行压力测试，从而揪出纯粹靠模型静态阅读绝不可能发现的运行时深层隐患。

6. 第三，我们极其擅长推理资源的高效分配（Allocating inference）：在代码审查与测试全流程的各个细分子任务中，我们合理选配体量最恰当的模型（兼顾前沿旗舰模型与开源轻量模型）。同时，我们为智能体配备了一整套专职代码检查工具链。借助这套组合拳，我们能够以纯 Codex 或纯 Claude Code 审查方案仅十分之一的极低成本，取得显著优异的审查效果。

图 3：为什么企业选择 Greptile（Why Greptile）

Every now and then, however, companies have very specific needs that we’re not well set up to serve yet. In those situations, they decide to build their own internal code review solution.

然而，每隔一段时间，总会有部分企业提出非常特异化的定制诉求，超出了我们现成标准化产品的承载范围。在这些场景下，他们往往会决定在团队内部自研一套专用的代码审查解决方案。

When they do - we like to help them with it, completely for free. We get to learn a lot from the process about how we can serve customers like them in the future. They get our expertise in building great review agents.

每当客户决定自研时，我们都非常乐意提供协助——而且完全免费。在这个协同自研的过程中，我们得以深入了解这类客户的特殊痛点，从而在未来更好地优化产品；而客户也能直接吸收我们在构建顶尖审查智能体上沉淀的核心技术专长。

Today, I am going to share some of that expertise with you. This is going to be helpful for two types of people:

1. You work at a large company and want to build your own AI code review tool
2. You are choosing an AI code review tool for your company and want to know how they work so you can make a more educated decision.

今天，我将把这些核心经验毫无保留地分享出来。这篇总结将对以下两类工程师带来实质帮助：

1. 你在大厂工作，正计划亲手打造团队内部的 AI 代码审查工具；
2. 你正在为公司技术团队选型商业 AI 代码审查工具，希望彻底弄清其底层运转机理，从而做出更具前瞻性与技术底气的采购决策。

图 4：本文适合哪些读者（Who this is for）

Alright, let’s dive right in.

话不多说，让我们直入主题。

基础工作流：极简沙盒流水线

At the core, you will need some type of sandbox running an agent. It will receive webhooks from GitHub when there are new pull requests ready for review. You can use Codex or Claude Code for this, or something like Pi or OpenCode if you want to be model-agnostic. It will analyze the changes, detect bugs, and post comments back to GitHub.

从核心机制来看，你首先需要搭建一个能够运行智能体的隔离沙盒环境。每当 GitHub 上有待审查的新 PR 发起时，沙盒会接收对应的 Webhook 触发通知。在智能体底层，你可以选用 Codex 或 Claude Code；如果你希望保持对具体底层模型的解耦中立，也可以采用类似 Pi 或 OpenCode 这类模型无关的开源智能体底座。它负责分析代码变更、侦测潜在缺陷，并将审查批注回写发推至 GitHub。

图 5：基础工作流架构（Basic workflow）

You can probably build this in a day.

只要动作够快，搭建这么一套最小原型（MVP）大概只需要一天时间。

You will notice a couple of things go wrong:

1. It will miss a lot of bugs, and you won’t know what it’s missing (it will be hard to evaluate and improve it)
2. It won’t deeply understand your codebase and product, particularly if it spans multiple repos
3. It will be very expensive (at least $3-5,upto$10-20 per run, and it will be run 2-3 times per PR)
4. It will make a lot of nitpicky comments which will annoy engineers
5. It will keep finding new bugs every time you run it instead of reporting everything at once

然而一旦实际上线跑起来，你立刻会遭遇一连串严重的工程阵痛：

1. 漏报严重且两眼一抹黑：它会遗漏大量关键 Bug，更致命的是你根本无法获知它到底漏了哪些（系统极难被科学评测与持续迭代改进）；
2. 无法深入理解代码库与业务逻辑：尤其是当业务架构横跨多个代码仓库（Multi-repo）时，它完全掌握不了全局脉络；
3. 审查账单高得惊人：单次运行的 Token 开销至少需要 3 至 5 美元，高的时候甚至达到 10 到 20 美元，而且每个 PR 通常会被反复推送触发 2 到 3 次；
4. 充斥着琐碎挑刺（Nitpicking）：不断就无伤大雅的命名或格式喋喋不休，极大消耗一线工程师的耐性与好感；
5. 审查结果缺乏一致性：每次重复运行都会莫名其妙冒出全新的异样发现，而不是一次性给出全面而稳定的确定性反馈。

图 6：朴素沙盒跑起来后的常见问题（Then you run it）

Let’s address all of these one by one.

接下来，让我们针对上述顽疾逐一攻克拆解。

优化 1：提示词调优与爬山评测

图 7：优化提示词（The prompt）

The lowest hanging fruit is to make the prompt better. You can instruct it to look for specific types of bugs, and also specifically tell it not to make nitpicky comments.

最容易上手的突破口是持续打磨系统提示词（Prompt）。你可以明确指令智能体聚焦排查特定类型的典型缺陷，并严厉禁止发表那些细枝末节的挑刺意见。

You can get quite far with this, but it’s surprisingly hard to evaluate if your improvements are working. Evaluating review agents is very hard because true bugs are very rare.

优化 Prompt 确实能取得肉眼可见的进展，但令人意外的是，要科学验证你的改动究竟是变好了还是变差了，难度超乎想象。评测代码审查智能体之所以极其艰难，根本原因在于：在真实的日常研发提交中，真正的实质性 Bug 本身就是极低概率的稀缺样本。

图 8：真正的 Bug 极为罕见（Bugs are rare）

No single company has enough PRs moving through to be able to iterate the agent’s performance. Greptile has the advantage of having millions of PRs going through it every month, so we can monitor and detect if our changes are improving the rate of bugs being caught or not. One way you can improve your mileage is by building a dataset of historic PRs with a diversity of bugs and hillclimb those.

没有任何一家单独的公司能够拥有足够密集的 PR 流水来仅凭日常流量快速试错智能体能力。Greptile 的独特优势在于每月有数百万个真实 PR 穿流而过，因此我们能够以大数法则严密监测改动是否真正提高了真实 Bug 的检出率。而对于自研团队来说，破局的最有效途径是：沉淀一套涵盖丰富多样缺陷类型的历史真实 PR 基准数据集，基于这套固定基准集开展持续的爬山法（Hillclimbing）评测迭代。

图 9：构建历史缺陷 PR 评测数据集进行爬山评测（A dataset of historical PRs）

优化 2：模型反转与同源审查盲区破除

If your company uses Claude to code, and you used Claude models for review, they will miss a lot of bugs. This is because the author and reviewer will have similar blind spots. As an example, Claude models are twice as likely as GPT models to introduce n+1 errors, and are also around twice as likely to miss them during review.

如果你的公司工程师主要使用 Claude 系列模型来辅助编写代码，而你在代码审查智能体中同样调用 Claude 模型，系统将会漏掉大量致命 Bug。这是因为代码编写者与审查者处于同一个模型体系时，天然共享了完全一致的认知盲区。举个直观的实证数据：Claude 系列模型在编码时引入数据库 N+1 查询隐患的概率约为 GPT 系列模型的两倍；而在随后的代码审查中，它漏检这类 N+1 缺陷的概率同样是 GPT 的两倍左右。

You should consider using Codex models to review Claude’s code and vice versa.

因此，在工程架构上，你应该坚决采用异构策略：使用 Codex / GPT 模型来审查 Claude 生成的代码，反之亦然。

This is easy if your company only uses one coding model. If everyone is on Claude, use GPT models in your review agent.

如果你的团队技术栈比较单一，落地这一步非常简单：只要全员都在用 Claude 编程，就在审查流水线中统一部署 GPT 模型。

In case you use multiple, you’ll have to develop a router/classifier that can detect the author’s model and flip the review model.

但如果团队内部既有使用 Claude 的也有使用 Codex 的，你就必须构建一个智能路由器/分类器：根据提交特征自动识别作者所使用的基座模型，并动态翻转（Flip）选用另一家不同模型家族的对立模型执行审查。

图 10：作者与审查者选用异构模型（Different author, different reviewer）

In our research on model inversion, bug catch rates go up ~10% when you do this. That number might seem small, but every additional bug that doesn’t reach your customers is a big deal.

根据我们在模型反转（Model Inversion）维度的专项技术研究，仅仅通过颠倒编写与审查模型，系统对真实 Bug 的捕获率就直接提升了约 10%。这个百分比乍看可能不算夸张，但对于企业级软件而言，少让任何一个潜在 Bug 溜进线上打扰真实客户，都意味着巨大的商业与工程价值。

图 11：Greptile 实测模型反转使 Bug 检出率提升约 10%（Higher bug catch rate in Greptile’s research）

Greptile of course does model inversion out of the box.

当然，Greptile 在商业产品中早已内置了开箱即用的模型反转机制。

优化 3：代码库上下文索引与 Wiki 注入

In spite of everything, your review agent will likely not understand your codebase. This will lead it to make false positive comments, or more importantly, entirely miss complex chained bugs. A common example is auth bypasses, which are often introduced by accident and catching them requires a pretty intricate understanding of how auth works in the application.

即便解决了模型与 Prompt 问题，你的审查智能体依然极大概率看不懂整个代码库的宏观架构。这种上下文盲区会导致两大恶果：要么疯狂误报虚假意见，要么对复杂的链式级联 Bug 完全视而不见。最典型的例子是权限绕过漏洞（Auth bypasses）：这类问题往往是在细微修改中不经意引入的，要识别它，前提是审查器必须对整套应用中鉴权与权限校验的底层运作脉络有极其精细的全局认知。

图 12：代码库上下文至关重要（Codebase context）

The review agent will also not fully understand intent. Sometimes code is perfectly correct but either does the wrong thing, or an incomplete thing.

审查智能体往往还难以真正理解开发者的业务意图（Intent）。很多时候，一段代码在语法和局部逻辑上完美无瑕，但它要么执行了错误的业务逻辑，要么少做了至关重要的一半配套处理。

图 13：看似正确的代码可能正在做完全错误的事（Correct code can still do the wrong thing）

You can resolve this in two steps:

• build an MCP gateway to give it access to your docs and your Jira, Linear, docs etc.
• build a codebase indexer

解决上下文与意图难题，需要分两步走：

• 搭建 MCP（模型上下文协议）网关：让智能体能够按需查阅公司内部的技术文档库，以及 Jira、Linear 等工单系统中的产品需求背景与验收标准；
• 构建代码库索引器（Codebase indexer）：对整个代码库的调用关系图与模块架构进行深度解析与语义索引。

图 14：补全两大部分上下文信息（Two pieces of context）

Building a codebase indexer is pretty involved. One way to do it is to have agents crawl your codebase periodically and maintain some type of wiki. This is roughly what Greptile does.

构建一个高质量的代码库索引器是一项极具挑战的系统工程。一种行之有效的实现方案是：让专门的扫描智能体定期爬取遍历你的全量代码库，持续维护一份结构化的内部知识 Wiki。这大体上正是 Greptile 底层所采用的工程范式。

You should also track reverts and incidents and store them in your wiki. This way your review agents will know what has gone wrong in the past, and prevent mistakes from being repeated. This involves building some type of integration layer with your telemetry stack.

不仅如此，你还应当主动追踪系统历史上发生的所有代码回滚（Revert）与线上故障事故（Incident），并将复盘沉淀同步写入这份 Wiki。这样一来，审查智能体就能清晰掌握过去团队曾经踩过的血泪教训，从而严防历史悲剧在新的 PR 中重演。这通常需要在流水线与内部生产遥测平台（Telemetry stack）之间构建一层深度集成管道。

You can inject this wiki into the agent’s sandbox, allowing it to go in with an understanding of the codebase and the product, leading to more bugs caught and fewer false positives.

在执行代码审查时，只需将这份凝练的代码库与事故 Wiki 预先注入到智能体的沙盒环境中，便能赋予审查器对当前项目架构与业务产品逻辑的深刻理解，从而捕获更多深层隐患，并显著削减误报率。

图 15：为智能体注入随时可查的代码库知识 Wiki（A wiki the agent can use）

优化 4：自主动态测试与端到端模拟验证

Imagine you wanted to build a system to catch UI bugs in a web application. Maybe you want to make sure certain buttons are not hidden when the site is opened on an iPhone. In theory, you could shove the React diff into a very smart model, let it spin for a bit, and tell you if the code is buggy. A much better way to do this is to spin up a dev server, open a browser, and use computer use to click through every path, ensuring it works.

设想一下：如果你想搭建一套系统来捕获 Web 应用程序中的 UI 交互缺陷——例如确保某个关键功能按钮在 iPhone 移动端视口下不会被意外遮挡或截断。在理论上，你可以把整段 React 组件变更的 diff 强行塞进某个顶尖大模型，让它绞尽脑汁琢磨一阵，然后告诉你这段代码是否存在渲染缺陷。然而，一种远为可靠得多的工程做法是：直接在沙盒里拉起开发服务器（Dev server），打开无头浏览器，借助计算机操作能力（Computer use）逐一模拟点击每条交互路径，在真实运行环境下亲眼确认它是否正常工作。

图 16：按钮在 iPhone 上真的能点吗？（Does the button work on an iPhone?）

Fortunately, frontier models are quite good at computer use. The parts you’ll need to build are:

1. Very good dev boxes which can be configured to make it easy to quickly spin up a PR branch to test it
2. A mapping of codebase sections to testable user flows

幸运的是，当今的前沿旗舰模型在计算机操作能力（Computer use）上已经表现得相当出色。要跑通这套自动化动态验证，你需要构建两大核心基础设施：

1. 极度敏捷的开发沙盒机（Dev boxes）：具备高度可配置性，能够在数秒内迅速拉取 PR 分支环境并一键启动应用服务；
2. 代码模块与可测试用户旅程的映射图谱（User flow mapping）：能够精准识别改动涉及哪些业务流，并指引智能体执行对应的交互测试。

For the former, we went with large configurable VMs, but even so we usually need FDEs from our team to go in and help customers set up these VMs.

针对沙盒运行环境，我们选择了大规模弹性配置的虚拟机（VM）。即便技术已经相当成熟，在实际工程落地时，我们团队的前线部署工程师（FDE）通常依然需要深入介入，协助客户量身配置这些定制化虚拟机底座。

For the latter, we use our knowledge base, where Greptile tracks the flows related to each part of the codebase. You should be able to use AI to produce this.

而针对用户旅程映射，我们借助自研的知识库系统（Knowledge base）持续跟踪记录与代码库各个模块紧密关联的用户行为流。在自研场景中，你完全可以借助 AI 离线生成并维护这套映射拓扑。

图 17：支撑动态测试需构建的两大组件（Two things to build）

优化 5：子任务模型分层路由与推理降本

If you do all of the above, you’ll start to see good results, but each review run will likely cost you anywhere from $2to$20 in token costs. Since your reviewer is likely to run on every push to a PR branch, this can add up pretty quickly.

如果你把前面的优化全部做完，确实能看到令人振奋的审查质量提升。但紧接着你就会被账单惊呆：每次审查运行的 Token 费用大概在 2 美元到 20 美元不等。考虑到工程师每次向 PR 分支推送提交都会触发一次审查，团队一个月的 API 支出会迅速累积成一个天文数字。

图 18：每次审查运行高昂的 Token 成本（Token costs per review run）

Fortunately, reviewing and testing a PR is made up of a pretty consistent set of subtasks. That means you can pick the perfect model for each subtask and drastically reduce costs and maintain/improve performance vs. using only frontier models.

所幸的是，对 PR 进行代码审查与动态测试，本质上是由一系列非常标准化、确定性的子任务流水线组合而成的。这意味着你完全可以为流水线中的每个独立子任务精准匹配最合适体量的模型——相较于自始至终无脑调用昂贵的前沿旗舰大模型，这种分层混合路由架构能够在保质甚至提效的同时，将综合推理成本断崖式打下来。

图 19：为各细分子任务选用相称的模型（A model for each subtask）

As an example, much of the token use in review is file reads. A majority of the files read are clearly not relevant to the change, but the model only discovers this after reading the file. Using a very light and cheap model for this can greatly reduce the cost of file reads, and a narrower, higher signal set of files can then be passed into the frontier model.

举个最典型的例子：在代码审查过程中，巨额的 Token 消耗其实都砸在了「阅读上下文文件」上。而在被读取的大量候选文件中，绝大多数在读完之后才被证明与本次变更毫无实质关联。如果先选用极其轻量、廉价的小模型来专门负责这层宽表阅读与初筛，就能以极低代价剔除海量噪音文件，最终只将收敛后高信噪比的核心上下文精准喂给前沿旗舰大模型。

图 20：大幅减少前沿模型对无关文件的无效阅读（Fewer irrelevant file reads）

A great code review agent combines codebase context, testing, reliable evaluations, and the right model for each task to catch bugs efficiently.

一个真正优秀的企业级代码审查智能体，绝非单一模型的简单封装，而是将代码库全局上下文、运行时动态测试、确定性的科学评测集以及因题制宜的精准模型分层路由深度熔铸为一体，从而以极高确定性与极致工程效率，将缺陷彻底扼杀在合并之前。