阿里开源 Open Code Review：确定性流水线 + LLM Agent 的代码审查工具

原文来源：alibaba/open-code-review — 阿里巴巴把内部使用两年的 AI 代码审查助手开源为 Open Code Review：用确定性流水线加 LLM Agent 的混合架构做行级代码审查，Apache-2.0 协议。

用 Claude Code 这类通用 Agent 做代码审查，很多人应该都碰过三个难受的地方：改动一多，Agent 就开始"偷工减料"，挑几个文件看完就交差；报出来的问题经常对不上位置，行号飘掉；质量不稳定，提示词稍微一变，结果就起伏很大。

Open Code Review（命令行里叫 ocr）是阿里巴巴针对这几个问题做出来的方案：把公司内部用了两年的 AI 代码审查助手开源。内部版本在这两年里服务了数万名开发者，找出过数百万个代码缺陷，验证过规模之后才孵化成开源项目。项目用 Apache-2.0 协议，目前 GitHub 上约 2.3 万 star。

它的工作方式

基本流程不复杂：读 Git diff，把改动的文件交给一个可配置的 LLM，这个 Agent 带工具调用能力，可以读完整文件、搜代码库、查看其他改动文件补上下文，最后产出行级精确的结构化审查意见——不是只看 diff 表面的那种。除了审 diff，它还有一个 ocr scan 模式，可以不依赖 Git 历史直接扫全文件，适合用来审计陌生的代码库。

真正有意思的是架构上的分工。它把整个流程拆成两块：

确定性流水线负责那些不该交给模型现场决策的环节：

• 文件过滤，确保重要改动不会被漏掉；
• 智能打包，把相关文件归成一个审查单元（比如 message_en.properties 和 message_zh.properties 会绑在一起），每个包交给一个带隔离上下文的子 Agent，属于分而治之——大改动集上更稳，也天然支持并发审查；
• 细粒度规则匹配，按文件特征去匹配审查规则，把信息噪音在源头砍掉。官方认为这种基于模板引擎的规则匹配，比纯自然语言描述的规则指引更稳定、更可预测；
• 独立的评论定位模块和反思模块，专门用来修正意见的位置和内容。

Agent 只负责它擅长的部分：动态决策和动态上下文检索。它的提示词和工具集都是为代码审查场景调过的——工具集是从大规模生产数据的调用轨迹里蒸馏出来的，包括调用频率分布、单个工具的重复率、新工具对整条调用链的影响，最终得到一个比通用 Agent 工具箱更稳的专用工具集。

这个分工直接回应了开头那三个痛点：覆盖不全、位置漂移、质量波动，本质都是"让模型自由发挥"带来的不确定性。

装起来用

依赖很简单：Git 2.41 或更高版本，因为 diff 生成、代码搜索和仓库操作都靠 Git。

npm install -g @alibaba-group/open-code-review

装完 ocr 命令就可以全局使用了（也提供安装脚本、GitHub Release 二进制和源码编译）。用之前得先配一个 LLM：

ocr config provider   # 选内置供应商，或自己加一个
ocr config model      # 给当前供应商挑一个模型

交互式界面会引导你选供应商、填 API Key、配模型，然后自动测一遍连通性。常用命令如下：

ocr review                                   # 工作区模式：已暂存、未暂存、未跟踪的改动一起审
ocr review --from main --to feature-branch   # 分支区间：审 feature 分支从 main 分叉后的改动
ocr review --commit abc123                   # 审单个提交
ocr review --from main --to feature-branch --resume <会话 ID>   # 恢复被中断的区间审查
ocr scan                                     # 全文件扫描整个仓库
ocr scan --path internal/agent               # 只扫某个目录或文件
ocr review --format json --output result.json   # 结果落盘，适合给宿主的编码 Agent 读

Delegation 模式值得单独说：它让本地的编码 Agent 自己来做这次审查——OCR 只负责挑文件、解析规则，用你自己的 LLM，不需要配 OCR 的 API Key。命令是 ocr delegate rule src/main.go src/handler.go。如果你的团队已经在用 Claude Code、Codex、Cursor 或 OpenCode，这条路能省掉一套额外的模型账单。

集成面铺得挺宽：Claude Code、Codex、Cursor、OpenCode 都有插件（斜杠命令或可调用的审查 skill），CI 侧支持 GitHub Actions、GitLab CI、GitFlic CI 和 Gerrit，另外还有 MCP Server、能在浏览器里回放审查会话的 Session Viewer，以及 OpenTelemetry 遥测。

基准数据，以及该注意的地方

官方放出了一个自建基准 AACR-Bench：50 个热门开源仓库、200 个真实 Pull Request、10 种编程语言，由 80 多位资深工程师交叉验证出 1505 条标注问题，数据集在 Hugging Face 上公开。

官方给出的结论是：在同一个底层模型下，Open Code Review 的精确率和 F1 明显高于通用 Agent（点名对比的是 Claude Code），同时 token 消耗只有对方的约 1/9，审查速度更快。但有一项是主动放弃的——召回率低于通用 Agent，README 里说这是刻意的取舍，用"少吵"换"多准"。

这个取舍值得展开。它意味着这款工具的设计取向是降低误报，让每一条报出来的意见都更值得点开看，代价是有些真问题它不会提。放到 CI 里，这个取向是合理的：没有人愿意被一堆假警报训练成见到通知就划走。但如果你的团队把它当成"兜底的最后一道防线"，指望它不漏，那它会让你失望。

另外要提醒的是，上面这些数字来自官方自建、自评的基准。它公开了数据集，这一点比只给一个数字强，但独立验证还是得自己跑一遍——尤其你用的是基准没覆盖的小众语言或偏门技术栈时，规则匹配的效果未必和基准一致。最后一个常规问题：它要把改动后的代码发给 LLM，如果代码不能外流，务必先确认供应商的合规边界，或者走自建的模型端点。

适合谁

如果你想要的是"少量但精准"的审查意见、想压低 token 账单、或者想把审查接进 CI 做一道固定关卡，这套工具的设计方向对得上，Delegation 模式对已经在用编码 Agent 的团队尤其省事。如果你需要的是"尽量别漏"，或者在意完全离线的自主可控审查，它现在不是这个定位，得自己评估规则集和基准数据是否够用。

项目地址：github.com/alibaba/open-code-review，文档在 open-codereview.ai。