12 - 代码审查 Agent¶

项目背景与目标¶

某研发团队每周产生 800+ Pull Request，人工 Code Review 成为瓶颈：资深工程师每周花 10+ 小时审查，审查质量参差不齐，且常聚焦风格问题而忽略安全与设计缺陷；新人 PR 等待审查平均 8 小时。企业希望构建自动代码审查 Agent，在 PR 提交时自动分析变更、检查规范、扫描安全漏洞、给出结构化审查意见，将人工审查聚焦于架构与业务逻辑，使 PR 平均等待时间降至 2 小时，安全漏洞上线前拦截率 ≥ 90%。

核心目标： 1. PR 自动审查覆盖率 100%，平均审查时间 < 2 分钟 2. 规范违规定位准确率 ≥ 85% 3. 安全漏洞检出率 ≥ 90%（含 OWASP Top10） 4. 误报率 < 15%，减少审查疲劳

预期价值：加速 PR 流转、统一代码质量、前置安全防线、释放资深工程师时间。

需求分析¶

用户角色与场景 - 提交者：提交 PR 后获取自动审查意见并修复 - 审查者：聚焦 Agent 标记的重点与架构问题 - 安全团队：监控漏洞趋势与误报优化

功能需求列表 - PR 变更分析与差异理解 - 编码规范检查（命名、复杂度、注释） - 安全漏洞扫描（SQL 注入、XSS、硬编码密钥、依赖漏洞） - 设计与坏味道识别（重复代码、过长函数、循环依赖） - 测试覆盖检查（变更是否含对应测试） - 结构化审查评论（按文件/行定位） - 严重度分级与阻断合并（Critical 阻断） - 误报反馈与学习优化

非功能需求 - 性能：单 PR 审查 < 2 分钟 - 准确性：低误报率，避免审查疲劳 - 可用性：99%，PR 不因 Agent 故障阻塞 - 集成：GitHub/GitLab/Webhook

约束条件：不可阻塞紧急修复（hotfix 白名单）；私有代码不外传。

技术选型说明¶

层次	技术选择	选型理由
Agent 框架	LangGraph	多检查器编排与结果聚合
LLM	Qwen2.5-Coder-32B	代码理解与建议生成
静态分析	SonarQube + Semgrep	确定性规则检查
安全扫描	SAST（Semgrep）+ SCA（依赖）	双轨覆盖
后端	Python + Webhook	事件驱动
部署	K8s 私有化	代码不出企业

架构设计¶

flowchart TD
    PR[PR Webhook] --> AGENT[审查 Agent]
    AGENT --> DIFF[变更分析]
    DIFF --> PARA[并行检查器]
    PARA --> S1[规范检查 SonarQube]
    PARA --> S2[安全扫描 Semgrep]
    PARA --> S3[LLM 设计审查]
    PARA --> S4[测试覆盖检查]
    PARA --> S5[依赖漏洞 SCA]
    S1 --> AGG[结果聚合]
    S2 --> AGG
    S3 --> AGG
    S4 --> AGG
    S5 --> AGG
    AGG --> SEV{严重度判定}
    SEV -->|Critical| BLOCK[阻断合并]
    SEV -->|其他| COMMENT[行级评论]
    COMMENT --> PR

核心是「变更分析 + 并行多检查器 + 结果聚合分级」。静态分析（SonarQube/Semgrep）做确定性规则检查，LLM 做语义级设计与坏味道审查，两者互补。结果按严重度分级，Critical 阻断合并，其余以行级评论呈现。

关键模块实现思路¶

模块1：变更分析与上下文构建¶

思路：解析 PR diff，识别变更文件、新增/修改/删除行、变更函数；提取变更函数的完整上下文（含调用方）供 LLM 审查，避免只看 diff 误判。
关键点：LLM 审查需看完整函数而非仅 diff，否则易漏跨行问题。

模块2：多检查器并行¶

思路：
规范检查：SonarQube 规则（复杂度、命名、重复）。
安全扫描：Semgrep 自定义规则覆盖 OWASP Top10。
LLM 审查：聚焦设计缺陷、坏味道、潜在逻辑错误。
测试检查：变更函数是否有对应测试变更。
关键点：各检查器独立并行，结果带文件/行定位。

模块3：LLM 设计审查¶

思路：将变更函数完整代码 + 上下文交给 LLM，按预设审查清单（单一职责、错误处理、并发安全、性能）输出问题与建议；要求引用具体行。

示意：

def llm_review(func_code, context, checklist):
    prompt = f"审查清单:{checklist};函数:{func_code};上下文:{context}"
    findings = llm.parse(prompt)  # [{severity, line, issue, suggestion}]
    return filter_low_confidence(findings)

模块4：结果聚合与严重度分级¶

思路：合并各检查器结果，去重（同一行多检查器报同类问题）；按 Critical/High/Medium/Low 分级；Critical 阻断合并并 @提交者，其余发评论。
关键点：误报率高会致审查疲劳，需对 LLM 结果做置信度过滤与误报库匹配。

核心流程详解¶

流程1：常规 PR 审查¶

提交者创建 PR，触发 Webhook
Agent 解析 diff，并行运行 5 类检查器
聚合结果：2 个规范问题 + 1 个潜在 SQL 注入
SQL 注入判为 Critical → 阻断合并 + 评论定位
提交者修复后重新推送，Agent 复审通过

流程2：hotfix 白名单¶

hotfix 分支 PR 触发，命中白名单
Agent 仅做安全扫描不阻断，评论以建议形式发出
允许合并，事后安全团队复核

部署与优化建议¶

部署架构：Webhook 服务无状态；检查器按类型独立扩缩；LLM 复用推理平台。
性能优化：大型 PR 按文件分片并行审查；静态分析增量扫描仅变更文件。
成本控制：静态分析覆盖确定性规则，LLM 仅审查高风险变更函数。

常见问题与解决方案¶

误报多 → 建立误报库，LLM 结果与误报库匹配过滤；收集开发者反馈持续优化。
大 PR 审查慢 → 按文件/函数分片并行；超限 PR 提示拆分。
阻断影响紧急上线 → hotfix 白名单不阻断，事后复核。

扩展方向¶

历史趋势分析：统计团队代码质量趋势与高频问题。
自动修复建议：对部分问题直接生成修复 PR。
跨仓库架构治理：检测循环依赖与跨层调用。