用通用 Agent 做代码评审，用久了会发现三个稳定的毛病：改动一大就偷偷只挑几个文件看；报出来的问题位置对不上，行号漂移；同一个仓库，换个提示词质量就上下跳。
阿里巴巴的 open-code-review（简称 OCR）就是冲着这三条去的。它不是又一个评审提示词包，而是一个命令行工具，核心主张写在 README 里：把"绝对不能出错的步骤"交给工程逻辑，把"需要临场判断的部分"留给模型。
这套东西在阿里内部当了两年官方 AI 评审助手，按官方说法服务过数万名开发者、发现过数百万缺陷，之后才开源。仓库目前约 5.07 万星（2026-11-14 用 GitHub API 读取，50,747），Apache 2.0。
它怎么分工
先把职责切开，这是全文的骨架：
| 环节 | 谁负责 | 为什么 |
|---|---|---|
| 选哪些文件要审、哪些过滤 | 工程逻辑 | 漏一个关键改动，后面全白费 |
| 把相关文件打成一个评审单元 | 工程逻辑 | 比如 message_en.properties 和 message_zh.properties 必须一起看，拆开就丢上下文 |
| 给每个文件匹配哪些规则 | 工程逻辑（模板引擎，不是让模型自己挑） | 规则稳定、可预测，也顺带压掉信息噪音 |
| 评论定位、评论反思 | 独立模块 | 专门治"行号漂移"和"说得像但不对" |
| 怎么读代码、要哪些上下文、调用哪些工具 | 模型 | 这才是模型真正擅长的地方 |
其中两个细节值得展开。一是文件打包后每个包跑独立子 Agent，上下文隔离，天然支持并发——这是它在超大 changeset 上还能稳定覆盖的原因。二是工具集是"场景定制"的，官方说这套工具是从生产调用链里统计出来的：哪些工具被频繁调用、哪些被重复调用、加一个新工具对整条链路有什么影响，据此剪出评审专用的一套，而不是把通用 Agent 的满配工具箱直接搬过来。
怎么跑
前置条件只有一个：Git 2.41 以上。安装走 npm，全局命令是 ocr：
npm install -g @alibaba-group/open-code-review
ocr config provider # 选内置供应商或自建
ocr config model # 选模型，会自动测连通性然后按场景选模式：
ocr review # 工作区：已暂存 + 未暂存 + 未跟踪
ocr review --from main --to feature-branch # 分支区间（merge-base）
ocr review --commit abc123 # 单个提交
ocr scan --path internal/agent # 整文件扫描，不依赖 diff
ocr review --from main --to feature-branch --resume <session-id> # 断点续跑
ocr review --format json --output result.json # 给上层 Agent 用的结构化输出
ocr delegate preview # 委派模式：让宿主 Agent 自己评审ocr scan 这个模式容易被忽略，但很实用：接手一个没有像样 diff 的老仓库、或者想摸清某个目录，全文件扫描比 diff 评审有意义得多。
还有一个不常见的设计：委派模式（delegate）。这时 OCR 只负责选文件和解析规则，真正评审的是你已经在用的编码 Agent，用的是它自己的模型和额度，不需要给 OCR 单独配 key。对已经有 Claude Code、Codex 订阅的人来说，这条路径省事。
它自己给的基准，该怎么看
官方建了个叫 AACR-Bench 的评测集：50 个热门开源仓库、200 个真实 PR、10 种语言，由 80 多位资深工程师交叉标注，得到 1,505 条标准答案。在这个集子上的结论是：
- 和通用 Agent（点名对比 Claude Code）用同一个底层模型时，Precision 和 F1 明显更高；
- token 消耗只有对方的约 1/9，评审更快；
- Recall 比通用 Agent 低，而且官方明说这是刻意的取舍——宁可少报，不要用噪音淹没人。
这个取舍值得单独讲一句：评审工具的价值不在"找出多少条"，而在"报出来的有多少条是真的"。一个报 40 条、其中 5 条有用的工具，实际成本比报 8 条、全部有用的工具更高，因为前 35 条要花人的时间去否掉。所以 Recall 低不必然是缺点，但前提是你有别的机制兜住漏报。
要打的折扣也得说清楚：这是厂商自建基准、自测自评，虽然标注是外包给 80 多位工程师做的，但选题、规则、对比配置都由自己定。它证明的是"这套架构在这个集子上有效"，不是"在你的代码库上更好"。
能不能塞进现有流程
这块做得比多数开源工具细：
- 编码 Agent 插件：Claude Code、Codex、Cursor、Kimi Code、OpenCode 都有对应安装方式，形态是斜杠命令加技能；
- CI 集成：GitHub Actions、GitLab CI、GitFlic CI、Gerrit；
- MCP Server：可以让评审 Agent 调外部工具；
- Session Viewer：浏览器里回放一次评审，能把评论标成已修或忽略，工作过程中先藏起来；
- OpenTelemetry：接自己的可观测体系。
该信多少
- 本文读的是 README 与官方文档链接，没有安装、没有跑过任何一次评审，所以不构成实测结论。
- "服务数万开发者、发现数百万缺陷"是官方自述，没有可核对的第三方数据。
- 基准里的对比对象、提示词、工具配置都由官方设定，换配置结论可能变。
- Git 2.41 是硬门槛；
ocr scan和delegate的实际表现本文无法验证。
一句话判断
过去一年大家做 AI 评审，做法基本是"写一段很长的提示词，祈祷模型照做"。OpenCodeReview 的贡献不是模型更强，而是把不该由模型决定的东西拿走了——选文件、配规则、定位置，这些交给确定性的代码，模型只负责读和判断。这个分工听起来朴素，但它正好解释了为什么纯提示词方案在真实仓库上总是忽好忽坏。
来源
- alibaba/open-code-review（README、基准说明；50,747 星，最后提交 2026-11-14，Apache 2.0）
- 官方文档（CLI、配置、委派模式、CI 集成）
说明：星数由 GitHub API 于 2026-11-14 读取；本文未安装或运行该工具，内容为官方文档解读。