让通用 Agent 审代码，用久了会摸出几种固定的不对：改动一大，它审着审着就"选择性失明"，只挑几个文件看；报出来的问题位置对不上，说的行号在改动行下面十几行；同一个仓库同一类改动，这周报三条，下周一条都不报，问它为什么也说不清。
根子不在模型身上，在于纯语言驱动的流程没有硬约束。选哪些文件、按哪套规则审、评论落在哪一行，全靠模型临场发挥，而临场发挥就是会飘。
Open Code Review 换了个分工方式：这些"绝对不能出错"的环节交给确定性工程代码，模型只负责真正需要判断的部分。它原名是阿里集团内部官方的 AI 代码审查助手，在内部跑了两年多，服务过数万名开发者，今年才开源出来。命令行叫 ocr，Apache-2.0 协议。
是什么
它是命令行工具，读 Git diff，把改动文件交给配好端点的 LLM Agent，产出带行号的审查意见。Agent 不是只能看 diff，它能读整个文件、在仓库里搜索、把其他改动文件拉进来做上下文，所以审得比"只看这一行"深。
除了增量审查，还有 ocr scan 做全文件扫描，刚接手一个不熟悉的仓库、或者一批没有有意义 diff 的目录，用这个审。仓库当前 3.7 万 Star、2683 Fork，当前版本 v1.12.7，2026 年 9 月 19 日还有提交。
核心优势
分工是它最值钱的地方。确定性层干四件事：精确判断哪些文件要审、哪些该过滤掉；把相关文件捆成一个审查单元（项目举的例子是把 message_en.properties 和 message_zh.properties 绑在一起），每个捆作为一个子 Agent 独立跑、上下文隔离，所以在超大 changeset 上也稳，而且天然能并发；用模板引擎按文件特征匹配规则，比"在提示词里写一段规则说明"稳定得多；另外还有独立的评论定位模块和评论反思模块，专门拉高位置准确度和内容准确度。模型这边只保留两件擅长的事：动态决策、动态取上下文。
基准数据摆在这里。项目方建了 AACR-Bench：50 个热门开源仓库、200 个真实 PR、10 种编程语言，由 80 多位资深工程师交叉校验出 1505 个标准缺陷。同一个 Claude-4.6-Opus 模型下，Open Code Review 的 F1 是 25.10%，通用编码 Agent 是 11.57%；精度 33.90% 对 7.23%；平均一次审查 1 分 23 秒对 13 分 06 秒；平均 Token 消耗 385K 对 5664K。换 Qwen3.8-Max 那组是 F1 23.00%、334K Token；Codex 配 GPT-5.5 那组 F1 8.36%。
它主动放弃了召回率。这一点项目写得很直白：通用 Agent 的召回是 28.90%，它只有 20.00%。README 里的解释是"刻意用精度换噪声"，因为审查环节真正的稀缺资源是人的注意力。报五条都是真的，比报二十条里十九条是误报有用得多。但这也意味着它不能当你唯一的防线。
不配模型端点也能跑。委派模式让它只跑确定性的部分：ocr delegate preview 先把审查计划打出来给你看，ocr delegate rule src/main.go src/handler.go 把匹配到的规则集交给宿主 Agent，由宿主用自己的模型完成审查。你要是已经在用 Claude Code、Codex、Cursor、Kimi Code 或 OpenCode，等于白拿一套编排逻辑，不用再开一个 API key。
工程配套是齐的。CI 集成给了 GitHub Actions、GitLab CI、GitFlic CI、Gerrit 的现成配方；有 MCP Server 可以往审查 Agent 里挂外部工具；有会话回放浏览器，能把某条评论标成"已修复"或"忽略"并在你处理时先把它们收起来；还有 OpenTelemetry 遥测。OpenSSF Best Practices 拿了 Gold 认证。
怎么用
前置要求只有一条硬的：Git 版本不低于 2.41，因为 diff 生成、代码搜索、仓库操作都靠它。
装完 ocr 就在全局 PATH 里了。先配模型：ocr config provider 选内置服务商或者自己加一个，ocr config model 挑模型，交互界面会顺手测一遍连通性。
然后在项目目录里跑审查。审工作区里已暂存、未暂存和未跟踪的改动，直接 ocr review；审特性分支相对主干的改动，用 ocr review --from main --to feature-branch（走 merge-base 模式）；审单个提交用 ocr review --commit abc123。中途断了可以 ocr session list 找回会话，加 --resume 接着跑。
要接流水线就让它出 JSON：ocr review --format json --output result.json。它支持任何 OpenAI 兼容或 Anthropic 端点，也支持 Ollama、vLLM 这类自建服务。
不是没有槽点
召回率是明摆着的短板。20% 的召回意味着大量真缺陷它不报，而报告看起来还很干净。这种"安静的漏"比误报更需要警惕。要全面扫一遍，还是得叠一个高召回的方案。
基准是自建的。AACR-Bench 由项目方发布，测的也是项目方自己的工具，4.7 倍精度这个差距是在人家定义的"什么算一条缺陷"上量出来的。README 里那个对照的通用 Agent 本来是做全部编码工作的，被拉来考它并不专精的科目，赢是合理的，但别把倍数当绝对结论。
它还得你养。不开委派模式就得自己配端点、自己承担 Token 成本，385K 一次已经比通用的省很多，但不是零。审查规则想贴合团队自己的规范（内部编码约定、框架特定陷阱），得按路径和类型自己维护规则库，这部分中文生态的现成沉淀还不多。
积压还不小。98 个未关 issue 加 133 个待合 PR，迭代很快，光一个发布日附近就有八个以上提交，说明这是个真正在往前跑的项目。反过来也说明稳定性和边界情况还在打磨，上生产前建议先在一个仓库里跑两周，看看噪声水平你能不能接受。
跟同类怎么比
对"直接用通用 Agent 审"。这类方案的强项是泛化：什么都不用配，让它读仓库它就读。代价是贵、慢、不稳定，大改动还容易漏。Open Code Review 的关系更像"专用工具 + 通用工具的补充"——日常 PR 走它，季度性的全面体检再让通用 Agent 扫一遍。
对商业审查服务。托管类服务的优势是开箱即用、有人替你调，缺点是不能接自己的模型、代码要过第三方、按量计费。Open Code Review 可以完全跑在自己的机器和自建端点上，代价是运维在你这边。
对自己写提示词脚本。自己写的好处是完全可控，坏处是每次模型提示词微调一下结果就变，而且大型 changeset 上跑不稳。它的价值几乎全在那层确定性工程上——文件打包、规则匹配、位置校准，这些用提示词是补不齐的。
一句话判断：如果你的团队每天都在合 PR、又已经为 Token 花了不少钱，值得拿它跑一轮对照，数一数"报出来你确实会去改的条数"，这个数字比基准表里的百分比更有说服力。
项目地址：https://github.com/alibaba/open-code-review
官方网站：https://open-codereview.ai
标签：#OpenCodeReview #代码审查 #AI编程工具 #CLI #阿里开源 #Apache2
你们团队审代码时更在意"报得准"，还是宁可多报几条自己筛？