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

引言

"通用 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 只处理真正需要动态判断的部分。

css 复制代码

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 Review	Claude 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，只审查变更部分：

bash 复制代码

# 审查当前工作区的改动（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 历史，直接审查文件内容：

bash 复制代码

# 审查指定目录
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 来跑。

bash 复制代码

# 预览 delegation 计划（看 OCR 打算怎么拆分任务）
ocr delegate preview

# 针对特定文件生成规则描述，供 Agent 审查
ocr delegate rule src/main.go src/handler.go

为什么有用：

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

GitHub Actions 集成

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

yaml 复制代码

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 种）。

安装和配置

安装

bash 复制代码

# npm（推荐）
npm install -g @alibaba-group/open-code-review

# 要求 Git >= 2.41
git --version

配置 LLM

bash 复制代码

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

通过 .ocrrc.yml 精细配置：

yaml 复制代码

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

第一次运行

bash 复制代码

# 在你的 git 仓库里
cd my-project

# 审查当前改动
ocr review

# 查看会话（支持断点续传）
ocr session list

项目地址与资源

🌟 GitHub : alibaba/open-code-review
🌐 官网/文档 : open-codereview.ai
🏪 GitHub Marketplace : Open Code Review Action
📦 npm : @alibaba-group/open-code-review

总结

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

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

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

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

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

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

引言

你会学到什么

前提知识

项目背景

从内部工具到开源

通用 Agent 做代码 review 的问题

核心架构：混合设计

Benchmark 数据

两种审查模式

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

ocr scan：全文件审计

Delegation 模式

GitHub Actions 集成

三个 SLA 级别

AI 生成代码的专项检测

安装和配置

安装

配置 LLM

第一次运行

项目地址与资源

总结

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

`ocr scan`：全文件审计