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

冬奇Lab 2026-08-09 0 阅读8分钟

引言

"通用 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 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，只审查变更部分：

# 审查当前工作区的改动（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

---

项目地址与资源

• 🌟 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 与技能的市场，每一个都经过真实企业工作流验证，去掉浮夸，留下真正有用的。

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