先看它是什么
阿里巴巴把内部孵化的代码评审工具 Open Code Review 以 Apache 2.0 许可证开源，仓库位于 GitHub 的 alibaba 组织下。它是一个命令行工具，命令名为 ocr，核心工作只有一件：读取 Git 变更，返回行级精确的结构化评审意见。它可以接入任何兼容 OpenAI 或 Anthropic 接口的模型端点，也就是说模型侧是开放的。
据项目说明，这套工具在阿里内部已经运行了两年，服务过数以万计的开发者，累计识别出数以百万计的代码缺陷，内部采用率超过 30%，执行过超过 100 万次真实评审任务。开源版本在 2026 年 9 月 11 日前后被开发者社区集中关注，当时的仓库数据约为 22,389 个星标、1,665 个复刻、约 150 位贡献者，并持有 OpenSSF Gold 徽章，版本迭代频率以数天计。需要说明的是，上述采用数据来自项目自述，未见独立审计，截至目前，其在阿里之外的独立使用数据与第三方复现结果，官方及行业暂未披露更多细节，后续将持续跟进迭代动态。
通用 Agent 做评审的三个失效模式
这个项目之所以值得看，是因为它明确反对一种当下流行的做法：把一个通用编程 Agent 直接指向一个 pull request，让它做评审。项目说明里点出了这种做法的三个具体问题。
其一是覆盖不全。变更集一大，Agent 就倾向于「抄近路」，只挑部分文件看，剩下的被跳过。其二是位置漂移。报告出来的问题经常对不上实际代码，行号或文件引用会偏。其三是质量不稳。纯自然语言驱动的评审没有硬约束，提示词稍微一改，结果就可能大幅波动。项目把根因归为架构层面：语言驱动的流程缺少对评审过程的强制约束，于是每一次运行都像一次即兴发挥。
基准数据把「噪声」量化了出来：在测试运行中，通用 Agent 每一轮会提出 4,351 到 5,980 条意见，而 Open Code Review 提出 728 到 889 条。当机器人九成以上的提示都是误报时，评审者就会停止信任它——这解释了为什么这个项目把精确率当作核心优化目标，而不是覆盖率。
混合架构：工程管硬约束，Agent 管判断
Open Code Review 的核心思路是把评审拆成两半：确定性工程负责那些绝不能出错的环节，Agent 负责需要判断的部分。
工程逻辑提供三类硬保证。文件选择精确决定哪些文件需要评审、哪些应当过滤，确保重要改动不被漏掉；智能分束把相关文件打包成一个评审单元——例如把英文与中文的属性文件绑在一起——每个分束作为独立的子 Agent 运行、上下文隔离，在超大变更集上保持稳定，并天然支持并发；规则匹配按文件特征把评审规则对应上去，用模板引擎而非自然语言来匹配，比语言驱动的规则引导更稳定、更可预测。此外，独立的定位与反思模块会在意见发布前，分别核对「位置是否对」与「内容是否对」。
Agent 则被保留在它最擅长的地方：读取完整文件、检索代码库、查看相关变更，然后决定要标记什么。项目说明提到，它使用的工具集是从大规模生产数据的工具调用轨迹里提炼出来的，包括调用频率分布、单个工具重复率、以及新增工具对整个调用链的影响，最终形成一套面向代码评审的专用工具集，比通用工具包更稳定。
基准与数字
阿里为此自建了一个基准，名为 AACR-Bench，来自 50 个开源仓库、200 个真实 pull request，覆盖 10 种编程语言，包含 1,505 个问题，由 80 多位资深工程师核对。按照项目公布的对照：在同一个底层模型（Claude-4.6-Opus）下，Open Code Review 的精确率为 33.90%，而通用 Agent 为 7.23%，约为 4.7 倍；同时每次评审消耗约 385K Token，而通用 Agent 为 5,664K，约为九分之一，并且完成得更快。
项目也承认一项让步：它的召回率更低。这被明确定义为有意为之的取舍——用更少的误报，换取漏掉稍多一些真实缺陷。内置规则集覆盖空指针风险、线程安全、跨站脚本与 SQL 注入等类型，横跨 10 种语言。以 Go 规则集为例，它读起来像一份资深评审者的清单：被忽略的错误、接口中的类型化 nil、sync.Mutex 的复制、生命周期超出持有者的协程，以及一节针对不可信输入拼接 SQL 的安全检查。规则里甚至明确要求 Agent 不要重复报告 go vet 与 Staticcheck 已经覆盖的问题。
「精确率优先」是不是对的
这个取舍是否合理，取决于团队当前的痛点。如果让人头疼的是误报太多、评审者不再看机器人意见，那么一个更窄、误报更少的 Agent 就值得引入。反过来，如果团队担心的是漏掉缺陷，那么精确率优先的方案并不合适，因为它主动降低了召回。
把这件事说得更直白一点：AI 评审的价值不在于它提出了多少条意见，而在于有多少条意见值得人花时间读。当一个工具每轮提出近六千条意见时，它的实际产出接近噪声；而当它每轮提出八百条、其中三分之一的精确率时，人的阅读负担才回到可控范围。这是一个关于「信噪比」而非「智能程度」的工程判断。
接入方式与生态
工具提供多种接入方式。它既可以在终端直接运行，也可以作为 CI 步骤，或者作为插件嵌入 Claude Code、Codex、Cursor 与 OpenCode。它还提供一种委托模式：由宿主编程 Agent 使用 Open Code Review 的文件选择与规则逻辑来执行评审，无需额外配置模型密钥。CI 侧支持 GitHub Actions、GitLab CI 与 Gerrit，评审结果可输出 JSON 供流水线消费。此外还有 ocr scan 命令，无需 Git 历史即可审查整个仓库或指定目录，适合接手陌生代码库时做初步审计。
中立思辨
需要冷静看待几件事。其一，AACR-Bench 是项目自建、自测、自发布的基准，README 未指向独立复现，33.90% 与 7.23% 这组对照应当作为方向性参考。其二，内部采用数据（数万开发者、数百万缺陷、30% 采用率）来自项目自述，没有第三方审计，开源版本本身的独立使用数据尚待积累。其三，精确率优先意味着漏报会更多，对安全敏感或合规要求高的代码库，可能需要与覆盖率优先的工具配合使用。其四，规则集的质量决定了这个方案的上限。模板化规则比自然语言稳定，但也更依赖规则作者的领域经验，规则的维护成本会随语言与框架数量增长。其五，把工具集从生产轨迹里提炼出来是一种务实的做法，但它同时也把阿里内部的评审习惯带了进来，其他团队的偏好未必一致。其六，作为一层 Harness，它与底层模型存在耦合，换模型后规则与工具集是否需要重新调优，项目尚未给出明确说明。
趋势研判
短期，代码评审 Agent 的竞争会从「谁的模型强」转向「谁的约束设计好」，精确率与 Token 效率会成为可比较的公开指标；中期，如果「确定性工程加 Agent 判断」的混合架构被更多工具采用，评审类 Agent 可能从通用编程 Agent 里独立出来，形成专用品类；长期，代码评审可能成为 CI 流水线里的标准一环，与静态分析、类型检查并列，而人的角色上移到对高价值意见的判断与规则集的维护。
对工程团队来说，这个项目最值得借鉴的不是它的具体规则，而是它的方法论：先想清楚哪些环节绝不能出错，用确定性逻辑把它们锁住，再把剩下的判断交给模型。这个思路适用于所有以「准确性」为首要目标的 Agent 场景，而不只是代码评审。