让 AI 审代码，常见的做法是把 diff 贴给一个通用的编程 Agent，再配一段提示词。改动一多，它容易只看其中几个文件；报出来的问题，行号也可能对不上；同一段提示词稍微改几个字，结果就换了一个样。
Open Code Review 是阿里巴巴开源的命令行审查工具，命令叫 ocr（Apache-2.0 协议）。官方说它最初是阿里内部的 AI 代码审查助手，两年里服务过数万名开发者，发现过数百万个代码缺陷，之后才整理成开源项目。
这篇按官方仓库当前的 README 整理：它和“直接让 Agent 审”有什么不同、怎么安装和配置、几条常用命令分别审什么、委托模式是什么，以及官方评测数据该怎么读。
它解决的三个问题
README 把通用 Agent 做代码审查时的毛病归成三类：
| 问题 | 表现 |
|---|---|
| 覆盖不完整 | 改动文件多的时候，Agent 会“偷懒”，只审一部分文件 |
| 位置漂移 | 报出的问题，行号或文件引用和真实代码位置对不上 |
| 质量不稳定 | 靠自然语言写的 Skill 很难调试，提示词稍有变化，效果就会有明显波动 |
官方给出的判断是：纯语言驱动的架构，对审查流程没有硬约束。所以它的做法是把流程拆开，一部分交给确定性的工程逻辑，一部分才交给 Agent。
工程管死，Agent 管活
“确定性工程”这一侧，负责那些不能出错的步骤：
- 精确选文件：由程序决定哪些文件要审、哪些要过滤，保证重要改动不被漏掉；
- 文件打包：把相关文件合成一个审查单元，比如
message_en.properties和message_zh.properties放在一起。每个单元由一个独立上下文的子 Agent 审查，改动很大时也比较稳，天然支持并发； - 规则匹配：按每个文件的特征匹配审查规则，让模型只看和它相关的规则，减少无关信息；
- 定位与反思：由独立的评论定位模块和反思模块校正评论的位置和内容。
Agent 这一侧负责需要动态判断的部分：针对审查场景调过的提示词，以及从大量线上调用记录里提炼出来的专用工具集。审查时 Agent 可以读完整文件、搜索代码库、查看其他改动文件来补充上下文，所以给出的不只是对着 diff 的表面意见。
安装和配置
前置条件
需要 Git 2.41 或更高版本。Open Code Review 用 Git 生成 diff、搜索代码和做仓库操作。
安装
npm install -g @alibaba-group/open-code-review
装完后全局可以使用 ocr 命令。官方还提供安装脚本、GitHub Release 二进制和从源码构建几种方式，见官方安装文档。
配置模型
除了后面要讲的委托模式，审查之前必须先配置一个大模型：
ocr config provider
ocr config model
第一条用来选择内置服务商或者添加自定义服务商，第二条给当前服务商选模型。交互界面会带你填服务商、API Key 和模型，并自动测试连通性。命令行配置、环境变量和自定义服务商的写法，见官方配置文档。
常用命令
进入你的项目目录后，几种审查范围对应几条命令：
| 想审什么 | 命令 |
|---|---|
| 工作区里所有已暂存、未暂存和未跟踪的改动 | ocr review |
| 某个分支相对 main 的改动（从分叉点算起） | ocr review --from main --to feature-branch |
| 单个提交 | ocr review --commit abc123 |
| 整个仓库或某个目录的整文件扫描 | ocr scan，或 ocr scan --path internal/agent |
| 看有哪些历史会话 | ocr session list |
| 把结果存成文件 | ocr review --format json --output result.json |
几点值得注意：
- 分支审查和单提交审查如果中途中断，可以用
ocr session list找到会话编号，再在原命令后加--resume加上会话编号继续；整文件扫描中断后同样用--resume恢复； ocr scan审的是完整文件，不依赖 diff 和 Git 历史，适合接手一个不熟悉的代码库，或者审一个没有有意义 diff 的目录；- 官方建议，让 AI 宿主 Agent 去调用
ocr时，用--format json --output result.json把结果存成文件，再去读文件。
委托模式：让你的编码 Agent 自己审
如果你已经在用 Claude Code、Codex、Cursor 之类的编码 Agent，Open Code Review 提供了接入它们的插件。接入之后，有两种执行方式：
- 默认模式：由 OCR 用它自己配置好的大模型来审；
- 委托模式：由你的编码 Agent 用它自带的大模型来审。OCR 只负责选文件和解析规则，不需要你给 OCR 配置 API Key。
委托模式的命令是 ocr delegate preview，以及给定文件后解析规则的 ocr delegate rule 加文件路径。
README 目前列出的集成包括 Claude Code、Codex、Cursor、Kimi Code、OpenCode、QCA Forward，以及兼容 Skill 的 Agent。在 CI/CD 里，官方文档提到支持 GitHub Actions、GitLab CI、GitFlic CI 和 Gerrit。具体插件的安装步骤，以官方文档和仓库里的插件说明为准。
官方评测数据怎么读
README 里的评测基于一个真实世界的代码审查基准：50 个热门开源仓库、200 个真实 Pull Request、10 种编程语言，由 80 多位资深工程师交叉验证，一共标注了 1,505 个真实问题。数据集叫 AACR-Bench，公开在 Hugging Face 上。
官方的结论是：和通用 Agent（Claude Code）使用同一个底层模型时，Open Code Review 的 Precision（报出的问题里有多少是真缺陷）和 F1 明显更高，token 消耗只有大约九分之一，审查也更快。
官方同时明确写了一个代价：Recall（真实缺陷被找出来的比例）比通用 Agent 低，这是有意地用召回换精度，目的是少一些误报噪声。
所以更稳妥的读法是：这是项目方自己公布的基准结果，它的取舍是“少报一点、报得准一点”。如果你的团队更怕漏掉缺陷、不太在乎误报，需要自己在真实项目上试一试再决定。
和 AIGoCode 一起用时要注意什么
先说清楚边界：ocr 是独立的命令行工具，它自己要配置一个大模型服务商。选择自定义服务商时，Base URL、API Key 填什么、支持哪些协议，要以 Open Code Review 官方配置文档为准。
如果打算用 AIGoCode 的 Key，建议这样做：
- 先在模型目录确认你的分组支持哪个协议、哪些模型，具体怎么看可以参考AIGoCode 模型目录怎么选：先看协议、工具和计价再发请求；
- 配置时填写控制台里显示的 Base URL 和 Key，配置过程中的连通性测试没通过，就先回到AIGoCode 常见问题里对照检查；
- 审查会读取完整文件、搜索代码库，一次大改动的审查调用次数不会少。第一次跑大范围审查之前，可以先在小分支上试，再用AIGoCode 额度消耗比预期快：如何核对一次任务的用量里的方法核对用量。
总结
Open Code Review 的思路是把“选哪些文件、怎么分组、套哪些规则、评论落在哪一行”这些不能出错的事交给程序，只让 Agent 做真正需要判断的部分。上手的最短路径：用 npm 安装，ocr config provider 和 ocr config model 配好模型，在项目里先跑 ocr review 看工作区改动；再按需要换成分支、提交或整文件扫描，已经在用编码 Agent 的话，可以试试委托模式。
参考链接
- Open Code Review 官方仓库：https://github.com/alibaba/open-code-review
- 官方网站和文档：https://open-codereview.ai
- 安装文档：https://open-codereview.ai/docs/installation
- 配置文档：https://open-codereview.ai/docs/configuration
- 委托模式：https://open-codereview.ai/docs/delegate
- CI/CD 集成：https://open-codereview.ai/docs/cicd