open-code-review：阿里把打磨两年的内部 AI 评审器开源了，用确定性工程管住 LLM 的手

一、导读

AI 代码评审工具很多，但多数的做法是把 diff 扔给通用智能体自由发挥，结果要么漏审、要么评错位置、要么评出一堆噪音。阿里把内部用了两年、服务过数万开发者的官方 AI 评审助手孵化成了开源项目 open-code-review（CLI 命令叫 ocr），核心思路反过来：文件选哪些、怎么分组、覆盖率如何兜底，全部由确定性工程锁死，LLM 只负责它擅长的动态判断。官方基准上，同样的模型走这套流水线，F1 比通用 Agent 直评翻倍，token 消耗只有约九分之一。本文拆解它的混合架构、关键机制与适用边界。

二、项目速览

项目	信息
仓库	alibaba/open-code-review
定位	AI 驱动的代码评审 CLI（命令 `ocr`），源于阿里集团内部官方 AI 评审助手
语言 / 许可	Go / Apache-2.0
热度	约 50,500 star（截至 2026-11-14），当日 GitHub Trending 涨 206 星
活跃度	近 4 周约 54 次提交，11 月已发 v1.13.4 至 v1.13.9 共 6 个版本
模型接入	Anthropic、OpenAI Chat Completions、OpenAI Responses、AWS Bedrock 四类协议，自定义 Provider
集成面	Claude Code、Codex、Cursor、Kimi Code、OpenCode、GitHub Copilot CLI 插件；MCP Server；GitHub Actions / GitLab CI / Gerrit
基准数据	AACR-Bench：50 个开源仓库、200 个真实 PR、10 种语言、80+ 工程师交叉标注 1,505 个真实缺陷

三、为什么是它

11 月 14 日它在 GitHub Trending 日榜上以 206 星排进前列，总星突破五万。涨星动因可以归结为三点。

第一，出身不同。它不是社区创作的提示词包装，而是阿里内部跑了约两年的生产系统：README 的表述是服务数万名开发者、累计识别数百万个代码缺陷， OpenSSF 最佳实践计划给了 Gold 等级认证。工程化程度和纯提示词方案不在一个层面上——单仓库就有约 1,200 个源文件，测试文件占相当大的比重。

第二，恰好踩中了当前 AI 编码工作流的最大痛点。2026 年底，用 Claude Code、Codex 这类编码智能体的开发者已经非常多了，「让智能体顺手评审一下代码」是常见用法，但通用智能体评审有三个公认的毛病（README 也点名了）：大变更集会「偷工减料」选择性漏审；报出的问题位置漂移，行号对不上；提示词微调导致质量抖动。Hacker News 上一条 284 分的讨论里，大量团队在自建评审技能、抱怨商业工具（CodeRabbit、Cursor Bugbot）的定价与噪音，open-code-review 给出的是一个可以私有部署、自己选模型的工程化答案。

第三，它带了一份难得的中文大厂级基准。AACR-Bench 用 200 个真实 PR、1,505 个人工标注的真实缺陷做「金标准」，并把 Claude、GPT、Qwen、GLM、DeepSeek 在同一管线下的表现全部公开（详见架构原理一节的数字）。对一个评审工具来说，敢公开自己每个模型的 F1、精确率、召回率和耗时，本身就是稀缺动作。

四、架构原理

open-code-review 确定性工程 × LLM Agent 混合架构：Git diff 采集、确定性前置层、Agent 执行层与运行时底座四层结构

4.1 整体架构：确定性工程 × Agent 混合

open-code-review 的核心设计哲学是「不能出错的事交给工程逻辑，动态判断交给模型」。整条评审流水线分四层：

flowchart TB
    subgraph L1["确定性前置层（工程逻辑保证）"]
        A["Git diff 采集<br/>workspace / 分支区间 / 单提交"] --> B["确定性文件选择 selectFiles<br/>二进制·密钥路径·用户规则·扩展名·单文件大小五道门"]
        B --> C["LLM 语义分组 grouping<br/>文件级元数据 → 语义组（每组≤10 文件）<br/>失败自动回退逐文件"]
    end
    subgraph L2["Agent 执行层（模型动态决策）"]
        C --> D["风险预判 PLAN_TASK<br/>大变更组先做风险分析"]
        D --> E["主评审 main_task<br/>带工具的 Agent：读全文·搜代码·查关联文件<br/>每组独立子 Agent 并发执行（默认 8 并发）"]
        E --> F["评论定位与反思<br/>确定性重定位 + 模型辅助重定位 re_location_task<br/>评论后过滤过滤噪音"]
    end
    subgraph L3["运行时底座"]
        G["llmloop：模型请求·上下文压缩·轮次与 token 限额·请求身份"]
        H["RunManifest：封存覆盖清单<br/>selected 分母封死后不可扩大<br/>completed / reused / failed / waived 四分区"]
    end
    E -.-> G
    F -.-> H
    C -.-> H

四个层级的职责划分，从仓库的运行时设计文档可以直接读到：internal/llmloop 拥有模型请求、上下文压缩、取消、轮次与 token 限额、会话记录、请求身份与聚合指标；internal/reviewtask 适配评审与扫描配置，负责完成性校验、评论修复、确定性与模型辅助重定位、异步 worker 收集；internal/agent 负责选择、分组、预算估计；依赖方向严格单向：agent / scan → reviewtask → llmloop，评审循环本身不导入评审模板、diff 或工具。

4.2 确定性文件选择：五道门 + 纯函数

评审的第一步不是问模型「看什么」，而是工程逻辑直接决定。selectFiles 是一个纯函数——无输出副作用、不访问 git 或 LLM——对每个变更文件依次过五道门：二进制文件排除；内置密钥路径表排除（任何 include 通配都接纳不了凭据路径，这条门优先于用户规则）；用户 exclude/include 规则；扩展名白名单；默认排除路径模式。最后还有一道单文件 diff 大小门：一个文件的 diff 单独超过提示预算约 80% 就直接跳过，根本不进模型。

纯函数设计有个工程上的妙处：--preview（预览将评审哪些文件）和真实运行消费的是同一个选择结果，两者不会各自推导然后产生漂移——这正是通用 Agent 方案里「预览说评审 10 个文件、实际只审了 6 个」这类问题的解法，仓库注释里明确记录了这个修复（#782）。

4.3 LLM 语义分组：便宜的小模型干粗活，索引代替路径省 token

文件选出来之后怎么分组？这是评审质量的关键：把 message_en.properties 和 message_zh.properties 放在同一次评审里，模型才能发现两种语言版本不一致的缺陷。open-code-review 的做法是让 LLM 只看文件级元数据（不看 diff 内容）输出语义分组，有三个值得注意的实现细节：

其一，分组响应让模型返回文件索引而不是文件路径。源码注释算过账：一个索引只花几个输出 token，一个完整路径要花它全长的 token，改用索引后响应体积小了一个数量级，之前因补全上限截断导致整组回退逐文件的问题就此消失。

其二，层层兜底。LLM 分组失败自动回退逐文件派发；小变更集（文件数或变更行数低于阈值）干脆不做 LLM 分组，本地直接决定打包还是逐文件；每组硬上限 10 个文件，超出就切分；组内 diff 总 token 超预算同样降级拆分。任何一步失败都有确定性的退路，这正是「硬约束」的含义。

其三，每组是一个独立子 Agent，上下文隔离。默认 8 个文件 worker 并发，divide-and-conquer 的策略让超大变更集也能稳定评审——每个子 Agent 只看自己那组的 diff，互相不污染。

4.4 主评审与重定位：给模型装「回头看」的闭环

分组之后，满足风险阈值的组先跑一个额外的风险预判阶段（PLAN_TASK）：单文件变更达 50 行、或组内两个以上文件合计变更达 100 行就触发，先分析风险再动手评审，用延迟换质量。主评审（main_task）是带工具的 Agent 会话，模型可以读完整文件内容、搜索代码库、查看其他关联变更文件——这也是它和「只看 diff 表面」的轻量方案的实质区别。

评出来的评论还要过两道加工：一是评论定位与反思模块，先用确定性方式对齐行号，失败再走模型辅助重定位（re_location_task，运行时三个任务类型之一），系统性地解决「评论行号漂移」这个通用 Agent 的高发问题；二是评论后过滤（--no-filter 可跳过），用一次额外的 LLM 调用把明显误报筛掉——这解释了它为什么敢把精确率做卖点。

4.5 封存清单（RunManifest）：覆盖率不是口头承诺

评审工具最怕的是「静默漏审」：声称审完了，其实有一批文件因为各种原因根本没进模型。open-code-review 的解法是版本化的运行清单（RunManifest）：派发前的选择环节把每个计划评审的文件注册进 selected 集合，然后立即封存（seal）——封存之后再注册直接报错，覆盖率分母从此不可扩大。运行结束后，selected 集合被划分成四个互斥的终态分区：completed（完成）、reused（断点续跑复用）、failed（失败，带分类与原因）、waived（豁免），加上一份 excluded 集合（记录每个文件被哪道门排除）。运行的最终状态只从覆盖率集合推导，不是模型说了算。每个条目还带原始 diff 内容的指纹（fingerprint），断点续跑时用它做检查点匹配；规则配置整体哈希成 rule_config_sha256 进清单，保证「同一次运行用了什么规则」可审计。v1.13.9（2026-11-13 发布）还在清单里补记了被排除文件，让运行覆盖度更完整。

这套机制配合 --max-tokens-budget 总预算阀门构成完整的可靠性边界：预算检查发生在每轮 LLM 调用之前，超预算的组给最后一轮机会提交已有发现，不再派发新组，已产出的部分结果照常发布，跳过的文件在清单里如实标记为 failed(budget)。

4.6 规则系统：模板引擎匹配，而不是让模型自由心证

内置评审规则按语言拆成规则文档（Java、Go、Python、C#、Scala、Clojure 等持续增加，11 月还在新加 Starlark、C# 规则），用模板引擎按文件路径 glob 匹配注入——注释里明确说这是为了「让模型注意力聚焦、从源头消灭信息噪声」，比纯语言驱动的规则引导更稳定可预测。规则解析分四级优先：--rule 命令行参数最高，其次是仓库内 .opencodereview/rule.json，再次是用户全局配置，最后是内置系统规则；用户规则默认替换命中的系统规则，也可以设 merge_system_rule: true 叠加。规则层还有一个精巧的嗅探器：.m 扩展名在 MATLAB 和 Objective-C 之间二义，系统按文件第一个非空行判断——以 % 开头是 MATLAB，以 #import、@interface 或 C 风格注释开头则是 Objective-C，注释里连「不能放宽到裸 #，否则 Octave 会误判」这种边界都写清楚了。工具集也是按场景特调的：从大规模生产数据的工具调用轨迹里分析调用频次分布、每工具重复率后蒸馏出的专用工具集，比通用 Agent 工具箱在评审场景下更稳。

4.7 性能取舍与横向架构差异

这套架构的代价与收益在官方 AACR-Bench 上看得很清楚（2026-11-14 取自仓库基准图，Claude Code 为 v2.1.169、Codex 为 v0.140.0、OCR 为 v1.3.1）：

方案 / 模型	F1	精确率	召回率	平均耗时	平均 token
OCR / Claude-4.6-Opus	25.10%	33.90%（301/889）	20.00%	1m23s	385K
Claude Code / Claude-4.6-Opus	11.57%	7.23%（435/5980）	28.90%	13m6s	5,664K
OCR / Claude-4.8-Opus	17.90%	37.80%（176/465）	11.70%	1m6s	352K
Claude Code / Claude-4.8-Opus	14.13%	15.93%（191/1200）	12.70%	5m38s	2,062K
OCR / Qwen3.8-Max	23.00%	33.90%（262/774）	17.40%	5m14s	334K
OCR / GPT-5.5	21.00%	32.10%（234/728）	15.50%	2m51s	422K

同样的 Claude-4.6-Opus，走 OCR 流水线 F1 从 11.57% 提到 25.10%，token 从 5,664K 降到 385K（约十四分之一），耗时从 13 分钟降到 83 秒。值得注意的是精确率的构成：OCR 报 301 个问题、命中 301 个标注缺陷之外只多报了 588 个；Claude Code 直评报了 5,980 个、只命中 435 个——噪音差了一个数量级。而召回率的差距是设计使然：OCR 有意用召回换精确，README 原文说这是「favoring precision over noise」的取舍——评审场景里，误报的代价是开发者直接关掉工具。

五、应用场景

open-code-review 一次评审的端到端数据流时序：开发者终端、确定性流水线与 LLM Agent 池三条泳道协作

5.1 本地工作区提交前自审

痛点：提交前想自查一遍，但 git diff 几百行看不进去，或者通用智能体审一半漏一半。解决：workspace 模式一条命令覆盖暂存、未暂存与未跟踪变更，确定性选择保证没文件被静默跳过。最小示例：

npm install -g @alibaba-group/open-code-review
ocr config provider          # 交互式选 Provider、填 Key、自动测连通
cd your-project
ocr review                   # 评审工作区全部变更
ocr review --preview         # 只看会评审哪些文件，不调模型

收益：官方基准同款模型 F1 翻倍、token 省一个数量级；预览结果与实际评审完全一致。边界：untracked 文件也会被审，想收窄范围先选择性 stage；工作区模式不支持断点续跑（分支区间与单提交模式支持）。

5.2 CI/CD 里做 PR 门禁

痛点：商业评审 SaaS 按席位收费且代码要出内网，自建脚本又搞不定覆盖率和行号精度。解决：官方 GitHub Actions、GitLab CI、Gerrit 集成，评审结果可输出 SARIF 直接进 GitHub Code Scanning；机器人只改写自己的总结评论，不污染人工讨论。最小示例（本地验证 SARIF 输出）：

ocr review --from main --to feature-branch --format sarif --output result.sarif

收益：SARIF 格式意味着发现的问题直接出现在 GitHub PR 的文件级标注里；--max-tokens-budget 让 CI 跑批的成本上限可控，超预算的文件在运行清单里如实报 failed(budget) 而不是静默丢失。边界：CI 场景要给足超时——默认 effort medium 下每组超时 30 分钟；模型 API 走内网代理时需在 Provider 配置里显式设置。

5.3 给 Claude Code 等 Host Agent 装评审插件

痛点：已经在用 Claude Code / Codex / Cursor / Kimi Code，不想再配一套模型 Key。解决：安装对应插件后获得 /open-code-review:review 斜杠命令与技能；还有委托模式（delegation）——OCR 只负责它最强的确定性部分（选文件、配规则），评审本身由宿主智能体用自己已登录的模型执行，OCR 侧完全不需要 API Key。最小示例：

ocr delegate preview         # 预览委托模式下将派发的文件与规则
ocr delegate rule src/main.go src/handler.go

收益：硬约束的选择与规则解析直接改善了宿主智能体「漏审文件、规则乱配」的问题。边界：委托模式的质量取决于宿主智能体自身；两种模式的计费主体不同（OCR 自管模式走你配的 Provider，委托模式走宿主订阅），别混着算成本。

5.4 陌生代码库全量扫描

痛点：接手遗留系统或审计第三方代码，没有 diff 可看。解决：ocr scan 评审整个文件而非 diff，支持指定目录、按文件大小门控风险预判阶段、会话续跑。最小示例：

ocr scan --path internal/agent
ocr scan --resume <session-id>

收益：新接手一个目录就能拿到按严重级别（critical / high / medium / low）与类别（bug / security / performance / maintainability 等）分组的问题清单。边界：扫描模板的提示预算与评审不同（约 58,888 token，评审是 200,000），超大文件会被跳过；全量扫描 token 成本显著高于 diff 评审，建议按目录分批。

5.5 多语言团队沉淀自定义评审规则

痛点：团队有自己的硬性规约（参数判空、SQL 注入检查），通用工具不听指挥。解决：四级优先的规则体系 + ocr rules check 预检某个文件会命中哪条规则。最小示例（.opencodereview/rule.json）：

{
  "rules": [
    {
      "path": "**/*.java",
      "rule": "所有新方法必须校验必填参数是否为 null",
      "merge_system_rule": true
    }
  ]
}

收益：规则按 glob 精确注入对应文件的评审提示，模型注意力聚焦在规约上；整体规则配置进运行清单哈希，规则变更可追溯。边界：规则是按文件类型匹配的模板，跨文件的架构级规约（如分层依赖约束）不是它的强项，那是架构守护工具的领地。

六、快速上手

环境要求只有 Git ≥ 2.41 与 Node。三条命令完成首审：

npm install -g @alibaba-group/open-code-review
ocr config provider          # 选 Provider、填 Key、自动测连通
ocr config model             # 选模型
cd your-project && ocr review

配置也可以走环境变量或命令行直设（以 Anthropic 协议为例）：

ocr config set llm.url https://api.anthropic.com/v1/messages
ocr config set llm.auth_token <你的密钥>
ocr config set llm.model claude-opus-4-6
ocr config set llm.use_anthropic true
ocr llm test                 # 验证连通性

进阶开关三件套：--effort 控制评审轮次（low / medium / high 对应单组超时 15 / 30 / 45 分钟）；--concurrency 控制并发 worker 数（默认 8，撞限流就调低）；--background "业务上下文" 把本次变更的业务背景喂给评审，官方技能文档将其列为提升质量的首选手段。评审结果可用 Session Viewer 在浏览器里回放、逐条标记已修复或忽略。

七、横向对比

维度	open-code-review	Claude Code 直评 / Skills	CodeRabbit	Cursor Bugbot
形态	开源 CLI + CI 集成	通用编码智能体	商业 SaaS	商业 SaaS
评审架构	确定性流水线 × Agent 混合，封存清单保覆盖	纯语言驱动，无硬约束	云端管线 + 专有规则	云端管线
覆盖率保证	封存清单四分区，漏审可审计	无（大变更易漏）	平台侧统计	平台侧统计
数据边界	代码不出本机，模型端点自选	本地，模型自选	代码上云	代码上云
成本模型	自付模型 token（官方基准约 350-750K/次）	订阅额度（同模型约 2,000-5,700K/次）	按席位订阅	已从包月转向按次计费
可定制规则	四级优先 + merge 开源规则文档	靠提示词与 SKILL 文件	平台配置	平台配置

选型要点：要代码不出内网、要模型自选、要覆盖率可审计，OCR 是目前开源里工程化最完整的一个；要开箱即用的网页界面与团队协作面板，商业 SaaS 更省事；已重度使用编码智能体的团队，委托模式可以让 OCR 的确定性管线与现有订阅结合。

八、局限与风险

召回率是有意牺牲的。 官方基准上 OCR / Claude-4.6-Opus 召回 20%，意味着 1,505 个标注缺陷里它只能找出约 301 个。README 明说这是用召回换精确的取舍，但 HN 讨论里有相当多开发者持相反观点——「评审工具第一要务是别漏」。两种价值观没有对错，采纳前先想清楚你的场景怕漏还是怕吵。

基准是自报的。 AACR-Bench 由项目方自己构建与评测，数字来自官方 README 基准图，尚无独立复现。HN 用户 eranation 用另一个第三方基准（codereview.withmartian.com）抽测 10 个 PR 得出「召回约 74% 但精确率约 12%」的反差结果；维护者 lizhengfeng101 回应称测试版本一个关键工具调用异常导致误报率偏高，已在复现后修复。这场往返恰恰说明：不同基准、不同版本下结论可能反转，关键数字请以自己仓库的实测为准。

早期兼容性翻过车。 开源初期有用户报告 GPT-5.x 系列模型不可用（max_tokens 参数硬编码不兼容新接口），维护者公开致歉并推进 LLM 模块重构。项目发布仅数日就在 HN 登顶，部分代码「尚未完全打磨」是维护者自己承认的——尽管 11 月的发版节奏（6 个版本）显示修复很快，接入前仍建议先用 ocr llm test 验证自己的模型可用。

命名与生态位。 ocr 这个命令与「光学字符识别」的公共缩写撞车，HN 上已有吐槽；工具只覆盖 diff 级与文件级评审，需求管理、架构守护、自动修复编排仍需其他工具补位。

九、小结与行动建议

open-code-review 的价值不在「又一个 AI 评审工具」，而在它示范了智能体工程的一条通用方法论：把「必须不出错」的环节（选什么、怎么分组、覆盖率、预算、审计）从模型手里收回来做成确定性工程，模型只做动态判断。这套「硬约束 × Agent」的架构对任何要落地 LLM 应用的人都值得抄作业。行动建议：

先跑预览再跑评审：ocr review --preview 零成本看清选择与分组逻辑，再决定是否接进工作流。
用委托模式零成本试用：已有 Claude Code / Codex 的团队装插件走 delegation，不新增任何 API Key 就能对比效果。
按团队痛点调精确/召回旋钮：怕噪音用默认档并保留评论后过滤；怕漏可叠加 --no-filter 与自建规则双跑取并集。
把运行清单当 CI 产物：manifest 的覆盖四分区是现成的审计证据，接进发布流程做评审完成度门禁。
关注版本节奏再上生产：项目发版极快（11 月已 6 版），生产接入固定到一个已验证的小版本，避免追新踩兼容坑。

参考资料

alibaba/open-code-review 仓库与 README（含 AACR-Bench 基准说明）：https://github.com/alibaba/open-code-review （获取日期 2026-11-14）
官方基准数据图 imgs/benchmark-en.png（各模型 F1 / 精确率 / 召回率 / 耗时 / token 数字）：https://github.com/alibaba/open-code-review/blob/main/imgs/benchmark-en.png （获取日期 2026-11-14）
任务运行时设计文档 docs/task-runtime-phase-one.md（llmloop / reviewtask 职责划分与等价性验证）：https://github.com/alibaba/open-code-review/blob/main/docs/task-runtime-phase-one.md （获取日期 2026-11-14）
源码：internal/agent/grouping.go（语义分组与索引编码）、internal/agent/selection.go（确定性五道门）、internal/session/manifest.go（封存清单与覆盖分区）(获取日期 2026-11-14)
官方 SKILL 文档 skills/open-code-review/SKILL.md（工作流、预算与 PLAN 阶段阈值）：https://github.com/alibaba/open-code-review/blob/main/skills/open-code-review/SKILL.md （获取日期 2026-11-14）
AACR-Bench 数据集（Hugging Face，含 1,505 条标注缺陷明细）：https://huggingface.co/datasets/Alibaba-Aone/aacr-bench （获取日期 2026-11-14）
Hacker News 讨论（284 分，含独立测试争议与维护者回应）：https://news.ycombinator.com/item?id=48406358 （获取日期 2026-11-14）