代码审查 Agent 应该如何设计

代码审查 Agent 应该如何设计

1️⃣ 考察意图

面试官想看你能否设计一个实用的 Code Review Agent，而非只说"用 LLM 看代码"。刁钻点在于：很多人只答"检查代码风格和 Bug"，但说不出静态分析与 LLM 审查的结合方式、审查的优先级排序、以及如何避免"噪声过多导致开发者忽略"的问题。

2️⃣ 标准答

Code Review Agent 应采用"静态分析 + LLM 审查 + 知识检索"三层架构，分层过滤、精准报告。

1. 三层审查架构

第一层：静态分析（快速、确定性）

• 工具集成：ESLint（JS/TS）、Pylint（Python）、SonarQube（多语言）
• 检查项：语法错误、类型错误、代码风格、复杂度（cyclomatic complexity > 10 告警）
• 优势：100% 确定性、速度快（<1s）、无 token 消耗
• 输出：结构化问题列表（文件、行号、问题类型、严重级别）

第二层：LLM 审查（深度、语义级）

• 输入：代码 diff + 上下文（函数定义、调用关系）+ 静态分析结果
• 检查项：逻辑 Bug：空指针解引用、资源泄漏、竞态条件、边界条件遗漏
• 安全漏洞：SQL 注入、XSS、硬编码密钥、不安全的反序列化
• 设计问题：违反 SOLID 原则、过度耦合、缺少错误处理
• 可维护性：命名不清晰、函数过长（>50 行）、缺少注释 Prompt 设计：你是高级代码审查员。审查以下代码 diff，关注：1) 逻辑Bug 2) 安全漏洞 3) 设计问题。对每个问题给出：严重级别(P0/P1/P2)、具体位置、修复建议。只报告真实问题，不要报告风格偏好。输出：结构化审查报告（JSON 格式）

第三层：知识检索（项目特定）

• 输入：LLM 审查结果 + 项目最佳实践库 + 历史 Bug 数据库
• 检查项：与项目最佳实践不一致（如项目要求用 async/await 而非 Promise.then）
• 与历史 Bug 模式匹配（如"这个空指针模式与上个月的 Bug #1234 相同"） 实现：用 RAG 从项目文档和历史 Bug 中检索相似案例

2. 审查优先级排序

3. 关键设计决策

• 只报告真实问题：LLM 容易"过度报告"——把风格偏好当问题。在 prompt 中明确"只报告可能导致 Bug 或安全问题的代码，不要报告个人风格偏好"
• diff 而非全文件：只审查修改的代码（diff），而非整个文件。减少 token 消耗和噪声
• 上下文注入：给 LLM 提供函数定义、调用关系、类型定义等上下文，而非只看 diff。否则 LLM 可能误报"未定义变量"（实际定义在其他文件）
• 与开发者 Agent 不同的模型：避免同源模型的盲区。如 Developer 用 GPT-4，Reviewer 用 Claude

3️⃣ 答题模板（30 秒电梯版）

"三层架构：静态分析（ESLint/Pylint，快速确定性检查）→ LLM 审查（语义级Bug/安全/设计检查）→ 知识检索（项目最佳实践+历史Bug匹配）。优先级：P0安全/逻辑Bug阻断合并、P1设计问题建议修改、P2可维护性提示。关键设计：只报告真实问题（prompt明确不报告风格偏好）、只审查diff（减少噪声）、注入上下文（避免误报）、用与Developer不同的模型（避免盲区）。"

4️⃣ 高频追问 & 应对

追问 1：LLM 代码审查的误报率怎么控制？

三层控制：(1) Prompt 约束——明确要求"只报告可能导致 Bug 或安全问题的代码"，并给出正面/反面示例；(2) 置信度过滤——让 LLM 对每个问题给出置信度（0-1），只报告置信度 >0.7 的；(3) 人工校准——抽样 10% 的审查结果人工标注，计算精确率（目标 >80%），低于阈值时调整 prompt。实测：未经校准的 LLM 审查误报率约 30-40%，经过 prompt 优化和置信度过滤后降到 10-15%。

追问 2：Code Review Agent 能发现什么样的 Bug？有什么发现不了的？

能发现：(1) 常见 Bug 模式——空指针、资源泄漏、数组越界、整数溢出；(2) 安全漏洞——SQL 注入、XSS、硬编码密钥；(3) 并发问题——竞态条件、死锁（如果在 diff 上下文中有锁操作）。发现不了：(1) 业务逻辑错误——如"计算折扣时应该用乘法但用了除法"，LLM 不理解业务规则；(2) 跨文件依赖问题——如"修改了函数签名但没更新所有调用方"，需要全局分析；(3) 性能问题——如"O(n²) 算法在大数据量下慢"，需要理解数据规模。

追问 3：Code Review Agent 和 GitHub Copilot 的代码审查功能有什么区别？

区别：(1) 审查范围——Copilot 审查单文件内的问题，Agent 可以跨文件审查（通过 RAG 检索相关文件）；(2) 知识库——Agent 可以接入项目特定的最佳实践和历史 Bug，Copilot 用通用知识；(3) 集成深度——Agent 可以作为 CI/CD 的一个 stage，阻断不合格的 PR，Copilot 只在 IDE 中提示；(4) 可定制性——Agent 的审查规则可以通过 prompt 和知识库定制，Copilot 的审查逻辑不可控。

5️⃣ 避坑 · 常见错误答法

• ❌ "用 LLM 审查就行了，不需要静态分析" → ✅ "LLM 审查有误报率和 token 成本。静态分析先过滤掉确定性问题（语法、类型、风格），LLM 只审查语义级问题，效率更高。"
• ❌ "审查整个文件而非 diff" → ✅ "审查整个文件会产生大量噪声——已有代码的问题不是本次 PR 的责任。只审查 diff 聚焦变更内容，减少噪声和 token 消耗。"
• ❌ "Code Review Agent 可以替代人工审查" → ✅ "Agent 可以过滤 80% 的常见问题（语法、安全、风格），但复杂的设计问题和业务逻辑仍需人工审查。Agent 是'增强'人工审查而非'替代'。"

6️⃣ 简历呼应

• 如果你有 Code Review 项目：从"审查系统设计"切入，描述你实现的三层架构，给出精确率/召回率数据和节省的人工审查时间
• 如果你只做过代码审查：用"人工 Code Review 的问题"切入——人工审查容易遗漏安全漏洞、风格不一致、耗时较长，Agent 可以解决这些问题
• 如果你是校招：用 GPT-4 实现一个 Code Review Agent，在 GitHub PR 上测试，对比 Agent 审查和人工审查的一致性
• "Automated Code Review with Large Language Models" (Wadhawan et al., 2023)
• "CodeReviewer: Pre-Training for Automating Code Review" (Li et al., 2022)
• "GitHub Copilot for Pull Requests" (GitHub, 2023)