阿里把审码的 AI 开源了，内部跑过数百万任务

原创

大白
大白

知白守黑1024

2026年9月30日 06:27
北京

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

AI 审代码早就不新鲜了——Claude Code、Cursor、Codex 都能干。但真正从大厂内部跑过数百万任务、把细节抠到\"注释精确到行\"再开源的，Open Code Review 算头一个。今天从它怎么解决通才 agent 的毛病、内部怎么跑、装起来怎么用，三层拆给你看。

一、它是什么

Open Code Review（命令行简称ocr）是阿里巴巴集团内部的官方 AI 代码评审助手，用了两年、服务过数万名开发者、跑过300 万+真实评审任务之后，孵化开源的项目。当前 GitHub4.2 万星、Apache-2.0 许可，官方评测F1 25.10%，社区相当认可。

它不是又一个\"让 LLM 看看 diff 给两句废话\"的工具，而是一个带工具调用能力、能读全文件、能搜代码库的 agent。把一个 PR 的改动喂给它，它能深入引用、追上下文，产出精确到行号的评审意见，甚至对没 diff 的陌生目录整体扫描。

官方数据：20K+ 内部活跃用户 · 3M+ 真实任务 · NPM 30 天下载 329K+ · token 成本 1/9 · AACR-Bench F1 25.10%

二、它补了通才 agent 的什么空当

用 Claude Code 这类通才 agent 带 skill 审代码，体验基本是这三类问题：

• 覆盖不完整

——改动一多，agent 就开始\"偷工减料\"，只挑部分文件看，漏掉重要的。
* 位置漂移

——报的问题经常对不上实际代码位置，行号、文件名飘到别处。
* 质量不稳定

——纯靠自然语言驱动的 skill 很难调试，prompt 稍微改一点，评审质量就大幅波动。

根子在一点：纯语言驱动的架构，缺少对评审过程的硬约束。

三、核心理念：确定性工程 × Agent 混合

Open Code Review 的思路很直白——把不能错的事交给工程代码，把需要动态判断的事交给模型，各干各最擅长的。

确定性工程——硬约束

• 精确文件选择

：哪些要审、哪些该过滤，由工程逻辑保证，不靠模型，重要改动不漏审。
* 智能文件捆绑

：把语义相关的文件并成一个评审单元（比如 message\_en 和 message\_zh 一起审），每组以独立上下文跑子 agent，大改动上更稳，还天然支持并发。
* 细粒度规则匹配

：按文件特征匹配对应的评审规则（NPE、线程安全、XSS、SQL 注入……几十种语言规则），让模型的注意力更聚焦，少受无关信息干扰。
* 外部定位与反思模块

：独立的\"注释定位\"和\"注释反思\"模块，系统性提升 AI 反馈的位置准确度和内容准确度。

Agent——动态决策

• 场景调优的 prompt

：为代码评审深度优化的模板，效果好还省 token。
* 场景调优的工具集

：从大规模生产数据的工具调用痕迹里萃取出来的极简工具集（读文件、搜代码、定位行号），比通用 agent 的工具箱更稳定、可预测。

一次 ocr review 的五段流水线 + 确定性/Agent 分工

四、一次评审在内部怎么跑

从你敲下回车到结果落屏，实际经过：diff 加载 → 五重门文件过滤 → 语义分组 → 并发子 agent → 评论输出。

五重门过滤

diff 加载后，每个文件依次过一道闸：二进制 → 用户 exclude → 用户 include（命中即保留）→ 扩展名白名单 → 内置测试文件排除。vendor/、node\\_modules/、target/ 这类噪声目录在更早的层就被剔掉，根本到不了过滤器。想不花 token 看全过程，一条命令：ocr review --preview。

语义分组

过滤后，OCR 先做一次GROUPING LLM 调用，注意——它只把文件元数据（路径、状态、增删行数）发给模型，不带 diff 内容，让它把语义相关的文件聚一组一起审。同一模块、接口与实现、i18n 变体、同目录协作文件都会被归到一起。每组最多 10 个文件，超过就拆开。

每组子 agent：plan + main 多轮

对每个文件组起一个子 agent 并发跑（默认并发 8 组）。大改动先进 plan 阶段做一次清单（阈值：单文件改动 50 行、或 2 个以上文件合计 100 行），小改动直接跳过 plan 进 main。main 循环里反复调用工具读文件、搜代码，默认最多 2 轮（--effort 可调 1~3 轮），后几轮会把已确认的发现当作\"已发现\"上下文传回，逼模型去找新问题。

记忆压缩

长工具调用循环会撑爆上下文窗口。OCR 用三分区策略——早先的\"冻结\"提示词保留、中段的压缩成摘要、最近的活跃轮次原样保留——在 token 用到 60% 时后台异步压缩、80% 时同步压缩，保证循环不断。

评论处理

每条评论经过：行号滑动窗口匹配定位 → 复杂 diff 上失败则用重新定位任务兜底 → main 循环后用 review-filter 把可证明是错的评审去掉 → 产出 text / JSON / SARIF 格式。

五、数据说话：同模型近乎翻倍

官方基准 AACR-Bench：50 个热门开源仓库、200 个真实 PR、10 种语言，80+ 高级工程师交叉标注出 1,505 个真实缺陷。同一个模型，套在 Open Code Review 框架和 Claude Code 框架里跑，差距非常直观：

官方基准图：三个框架同模型对比

几个关键结论：

• 同模型不同框架，F1 差 2 倍多

：Claude-4.6-Opus 在 Open Code Review 里 F1 25.10%、在 Claude Code 里只有 11.57%。
* 精度与召回是主动权衡

：Claude Code 框架召回率高、但精度崩得厉害（Qwen3.7-Max 召回 23.37%、精度掉到 8.23%），噪声多到没法用；Open Code Review 反其道，保精度、压噪声。
* 省 token 到骨子里

：同等任务 token 用量是 Claude Code 的1/9~1/15。
* 更快

：Open Code Review 最快整次评审 1 分 06 秒，多数方案在 1~8 分钟内。

六、装起来，跑起来

前置条件很简单：Git ≥ 2.41、Node.js ≥ 18、一个 LLM API key。

第 1 步 装 CLI（npm 一条命令）

BASH

全局安装，之后 ocr 命令可用npm install -g @alibaba-group/open-code-reviewocr version# 也在 macOS/Linux 可用 Homebrew：brew install open-code-review

第 2 步 配置一个 LLM

BASH

交互式：选 provider、填 key、选模型，自动测连通ocr config providerocr config model# CI / 无界面环境直接用非交互命令ocr config set provider            anthropicocr config set model               claude-opus-4-6ocr config set providers.anthropic.api\_key sk-ant-xxxxxxxxocr llm test

官方配置流程截图：选 provider → 填 key → 选模型 → 测连通

第 3 步 第一次评审

BASH

进任意 git 仓库cd path/to/your-repo# 评审全部未提交变更（默认工作区模式）ocr review# 评审 dev 分支相对 main 的所有改动ocr review --from main --to dev# 评审单个 commitocr review --commit abc123# 先看不花钱的预览ocr review --preview# 输出 JSON 给 CI 或上游 agentocr review --format json --audience agent > review.json

官方终端演示：读文件 → 搜代码 → plan → 输出带行号的建议

值得一提的还有两块：odelegate（委托模式）和scan（全文件扫描）。委托模式让你的 AI 编码 agent 用它自己的模型去审，OCR 只负责选文件和规则解析，你连 API key 都不用配——在 Claude Code、Codex、Cursor、Kimi Code、OpenCode 里装了插件就能用。scan 则不依赖 git 历史，直接整仓库或指定目录扫描，适合上手陌生代码库。

七、蓝队 & 开发者视角怎么看

它审的是质量，不是安全。这是最容易误读的点：别指望它替代安全工具去抓漏洞利用路径。它内置的多语言规则（NPE、线程安全、XSS、SQL 注入）既能当静态安全检查的补充，但主要价值在代码质量、可维护性、潜在 bug、安全写法这一类——放进 CI，让每个 PR 提交前都被 AI 过一遍。

从安全团队视角，更实用的姿势是把它接进每一处 CI，把「有人工渗透、有 SAST」变成「外加一层持续、免费的代码级审查」。

一句话总结

Open Code Review 不是又一个\"AI 看 diff\"，而是把确定性工程和 agent 的动态判断拆开重做——用工程代码硬约束文件选择、分组、定位这些不能错的部分，让模型只负责真正需要推理的部分。换来的是：同模型 F1 近乎翻倍、token 省到 1/9、注释精确到行、数据完全不出本地。

它是阿里内部跑过 300 万+ 任务、再托给社区的产物，Apache-2.0 随便商用。

想吃透它，别停在\"好用\"，去读它内部流水线和每一层取舍——那才是一个大厂把 AI 落地到工程里的真实姿势。