开源项目第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 只处理真正需要动态判断的部分。
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--frommain--tofeature/new-auth# 审查单个 commitocr review--commitabc1234# 指定输出格式ocr review--outputjson ocr review--outputsarif# 可导入 GitHub Securityocr scan：全文件审计
不依赖 git 历史，直接审查文件内容：
# 审查指定目录ocr scan--pathinternal/# 审查单个文件ocr scan--pathsrc/auth/handler.go# 输出 HTML 报告ocr scan--pathsrc/--outputhtml适合场景：接手别人的代码库做安全审计、老项目的代码质量摸底、没有 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为什么有用：
- 你已经有 Claude Code 订阅或 API key，不需要为 OCR 单独配置另一个 key
- OCR 的确定性层做了文件选取和规则解析，你的 Agent 只需要做真正的"理解和判断"
- 整合到已有的 Agent 工作流里，不需要切换工具
GitHub Actions 集成
三十秒配置，每个 PR 自动触发审查：
name:AI Code Reviewon:[pull_request]jobs:review:runs-on:ubuntu-lateststeps:-uses:actions/checkout@v4-uses:raye-deng/open-code-review@v1with:sla:L2# 审查深度：L1 / L2 / L3threshold:60# 质量分低于 60 则 failgithub-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（推荐）npminstall-g@alibaba-group/open-code-review# 要求 Git >= 2.41git--version配置 LLM
ocr config provider# 交互式配置：选择 Anthropic / OpenAI / 自定义兼容接口通过.ocrrc.yml精细配置：
sla:L3ai:embedding:provider:ollamamodel:nomic-embed-textllm:provider:ollama# 支持本地 Ollamamodel:qwen3-coder# 任何 OpenAI 兼容的模型第一次运行
# 在你的 git 仓库里cdmy-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 与技能的市场，每一个都经过真实企业工作流验证，去掉浮夸，留下真正有用的。
欢迎访问我的个人主页，发现更多有价值的见解和有趣的产品。