一天一个开源项目

开源项目第181期：Open Code Review — 阿里巴巴内部锤炼的 AI 代码审查工具，token 消耗仅为通用 Agent 的 1/9

阿里巴巴将内部大规模 AI 代码审查工具开源。服务过数万名工程师、识别数百万代码缺陷后对外发布。核心是混合架构：确定性工程管道负责文件选取、Bundle 分组、规则匹配，LLM Agent 负责动态决策。与通用 Agent（如 Claude Code）相比，同一模型下精确率和 F1 更高，token 消耗约为 1/9。支持 review（git diff）和 scan（全文件审计）两种模式，支持 delegation 模式让你自己的 Agent 执行审查，支持 GitHub Actions / GitLab CI / Gerrit 集成。18.1k Stars，Apache 2.0。

·约 9 分钟阅读·Developer Tools
open-sourcecode-reviewAICLIhybrid-architectureGitHub-ActionsCI-CDAlibabaGoLLMdeveloper-toolssecurity

引言

"通用 Agent 做代码审查的问题不是它看不出 bug，而是它不知道该看哪里，看完了把行号搞错，还用了 9 倍的 token。"

这是「每日一个开源项目」系列的第 181 篇。今天的项目是 Open Code Review —— 阿里巴巴将内部 AI 代码审查工具开源的成果，2026 年发布，在开源之前已在阿里内部服务了数万名工程师，"识别了数百万代码缺陷"。

市面上用 LLM 做代码 review 的工具不少，但大多数是把 diff 直接扔给大模型然后等输出。Open Code Review 的出发点不同：它有一套混合架构——确定性工程管道处理"绝对不能出错的事"（文件选取、位置定位、规则匹配），LLM Agent 只处理需要动态判断的部分。结果是：相同的底层模型，精确率和 F1 值更高，token 消耗约为通用 Agent 的 1/9。

18,100 颗 Star，1,200 个 Fork，Apache 2.0。

你会学到什么

  • 混合架构的设计逻辑：为什么把"确定性"和"Agent"分开
  • ocr review（增量审查）和 ocr scan（全文件审计）的差异
  • Delegation 模式：让你自己的 Agent 跑审查，不需要 OCR 的 API key
  • Benchmark 数据：与 Claude Code 作为通用 Agent 的对比
  • GitHub Actions 集成和三个 SLA 审查级别
  • AI 生成代码的特有缺陷检测

前提知识

  • 有 Git 工作流经验（branch、diff、PR）
  • 了解 CI/CD 的基本概念
  • 用过 Claude Code 或类似 AI 编程工具会有帮助

项目背景

从内部工具到开源

Open Code Review 不是为了开源而造的新项目，而是阿里巴巴内部实际运行多年的工具对外发布。这个区别很重要：它的设计决策来自真实的规模化运营经验，而不是从零开始的想象。

在内部版本里，这套系统：

  • 服务了数万名工程师
  • 识别了数百万代码缺陷
  • 真实处理了生产级别的代码库复杂度

通用 Agent 做代码 review 的问题

把 diff 直接扔给 Claude Code 或 GPT 做代码 review，有几个系统性的弱点：

问题表现
文件覆盖不完整Agent 自主决定看哪些文件，可能遗漏关键的跨文件依赖
位置漂移行号标注不准确，comment 落在错误的位置
质量不稳定同样的 diff 不同次运行，问题严重程度的判断差异大
token 消耗高通用 Agent 会读取大量不必要的上下文

这些问题的根源是：通用 Agent 为了灵活性，把所有决策都交给 LLM 动态处理，包括那些本来可以用确定性代码精确处理的部分。

核心架构：混合设计

Open Code Review 的设计哲学：让确定性的事情用确定性的方式处理，让 Agent 只处理真正需要动态判断的部分。

Git 变更
    ↓
[确定性层]
  ├── 精确文件选取（不遗漏、不多选）
  ├── 智能 Bundle 分组（相关文件聚合成独立子 Agent 上下文）
  ├── 模板引擎规则匹配（NPE、线程安全、XSS、SQL 注入等）
  └── 外部定位 + 反射模块（精确行级注释位置）
    ↓
[Agent 层]
  ├── 场景专调的 prompt 和工具集
  ├── 基于生产 tool-call trace 分析优化
  └── 动态上下文检索和工具调用
    ↓
代码审查结果（精确行级注释）

确定性层负责：

  • 从 git 变更里精确选取所有需要审查的文件
  • 把相关文件打包成独立的 Bundle，每个 Bundle 在独立上下文里处理（分而治之）
  • 用模板引擎匹配常见缺陷规则，而不是每次都让 LLM 从头判断
  • 确保输出的行号标注精确，不产生位置漂移

Agent 层负责：

  • 基于生产环境的 tool-call traces 分析和优化过的 prompt
  • 需要跨文件推理的复杂判断
  • 动态工具调用

这个分工的结果：精确率更高（确定性层避免了 LLM 的随机性），token 更省（Agent 只处理真正复杂的部分）。

Benchmark 数据

Open Code Review 团队构建了一套基准测试，数据来自：

  • 50 个开源仓库
  • 200 个 PR
  • 10 种编程语言
  • 1,505 个标注问题（由 80+ 名工程师人工标注）

与使用相同底层模型的 Claude Code（通用 Agent 模式）对比：

指标Open Code ReviewClaude Code（通用 Agent）
Precision（精确率）更高较低
F1 值更高较低
Recall（召回率）较低（刻意取舍）较高
Token 消耗~1/9基准

关于 Recall 的取舍：Open Code Review 刻意把 Recall 设计得低于通用 Agent，这不是缺陷，而是权衡——宁可少报 bug，也不要用大量噪音淹没真正的问题。对于 CI/CD 流水线来说，高精确率和低噪音比高召回率更实用。

Token 消耗的实际含义：同样的 100 个 PR，Open Code Review 消耗的 token 约等于通用 Agent 的 11%。在 CI/CD 里每个 PR 都触发审查的场景下，这个差异直接决定了工具能不能用——一个月的 API 费用差了将近 10 倍。

两种审查模式

ocr review：增量审查（最常用）

基于 git diff，只审查变更部分：

# 审查当前工作区的改动（staged + unstaged）
ocr review
 
# 审查特定分支范围
ocr review --from main --to feature/new-auth
 
# 审查单个 commit
ocr review --commit abc1234
 
# 指定输出格式
ocr review --output json
ocr review --output sarif   # 可导入 GitHub Security

ocr scan：全文件审计

不依赖 git 历史，直接审查文件内容：

# 审查指定目录
ocr scan --path internal/
 
# 审查单个文件
ocr scan --path src/auth/handler.go
 
# 输出 HTML 报告
ocr scan --path src/ --output html

适合场景：接手别人的代码库做安全审计、老项目的代码质量摸底、没有 git 历史的代码片段审查。

Delegation 模式

这是 Open Code Review 里最有意思的设计之一。

传统模式：OCR 的 Agent 层使用你配置的 LLM API（需要 Anthropic/OpenAI key）来执行审查。

Delegation 模式：OCR 只负责确定性层（文件选取、Bundle 分组、规则解析），把审查任务委托给你已有的 Agent（Claude Code、Codex、Cursor 等），用那个 Agent 自己的 LLM 来跑。

# 预览 delegation 计划（看 OCR 打算怎么拆分任务）
ocr delegate preview
 
# 针对特定文件生成规则描述，供 Agent 审查
ocr delegate rule src/main.go src/handler.go

为什么有用：

  1. 你已经有 Claude Code 订阅或 API key，不需要为 OCR 单独配置另一个 key
  2. OCR 的确定性层做了文件选取和规则解析，你的 Agent 只需要做真正的"理解和判断"
  3. 整合到已有的 Agent 工作流里，不需要切换工具

GitHub Actions 集成

三十秒配置，每个 PR 自动触发审查：

name: AI Code Review
on: [pull_request]
 
jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - uses: raye-deng/open-code-review@v1
        with:
          sla: L2          # 审查深度：L1 / L2 / L3
          threshold: 60    # 质量分低于 60 则 fail
          github-token: ${{ secrets.GITHUB_TOKEN }}

三个 SLA 级别

级别说明适用场景
L1快速结构检测，不需要 AI快速 PR、低风险变更
L2加入语义分析和 embedding常规功能开发
L3完整 LLM 深度扫描：跨文件一致性、逻辑 bug 检测、置信度评分核心路径、安全敏感代码

AI 生成代码的专项检测

Open Code Review 在 GitHub Marketplace 里定位为"首个专为 AI 生成代码构建的 CI/CD 质量门"，针对 AI 编程工具的特有输出模式做了专项检测：

缺陷类型具体表现
幻觉 import引用了不存在的包（实时验证 npm/PyPI/Maven）
过时 API训练数据里有但已废弃的方法
上下文窗口产物跨多个文件的逻辑矛盾
过度工程不必要的抽象和死代码
安全反模式硬编码密钥、eval() 使用

这些问题传统 linter 基本发现不了，但在 AI 生成的代码里出现概率显著高于人工编写的代码。

支持语言：TypeScript/JavaScript、Python、Java、Go、Kotlin（6 种）。

安装和配置

安装

# npm（推荐）
npm install -g @alibaba-group/open-code-review
 
# 要求 Git >= 2.41
git --version

配置 LLM

ocr config provider
# 交互式配置：选择 Anthropic / OpenAI / 自定义兼容接口

通过 .ocrrc.yml 精细配置：

sla: L3
ai:
  embedding:
    provider: ollama
    model: nomic-embed-text
  llm:
    provider: ollama       # 支持本地 Ollama
    model: qwen3-coder     # 任何 OpenAI 兼容的模型

第一次运行

# 在你的 git 仓库里
cd my-project
 
# 审查当前改动
ocr review
 
# 查看会话（支持断点续传）
ocr session list

项目地址与资源

总结

Open Code Review 的核心贡献是证明了一件事：在代码审查这个特定场景里，用工程手段约束 LLM 比让 LLM 自由发挥效果更好。

通用 Agent 做 code review 的问题不是 LLM 能力不够，而是把所有决策都交给 LLM 本身就引入了不必要的随机性和 token 浪费。把文件选取、行号定位、规则匹配这些"有确定答案"的事情用确定性代码处理，LLM 的注意力才能集中在真正需要理解和判断的地方。

这个设计思路值得推广：不是"怎么让 AI 做得更好"，而是"哪些部分本来就不该让 AI 做"。这是很多 AI 工具在规模化应用中反复撞墙后才得出的结论，阿里巴巴把内部踩过的坑打包进来一起开源了。

探索 PrimeSkills —— 精选 AI Agent 与技能的市场，每一个都经过真实企业工作流验证，去掉浮夸，留下真正有用的。

欢迎访问我的个人主页，发现更多有价值的见解和有趣的产品。

← 返回博客列表