代码审查是 Agent 落地最自然的场景之一：输入是结构化的 diff，输出是结构化的评论，判据（这段代码有没有 bug）看起来也很明确。于是大量团队的做法是写一段比较长的提示词，把 diff 丢给一个通用编码 Agent，让它产出审查意见。
阿里开源的 Open Code Review 走了另一条路。它源自阿里内部的 AI 代码审查助手，据项目方说明已服务数万名开发者、发现数百万个缺陷，经过两年内部验证后才开源。它最值得看的不是提示词写得如何，而是它对**「哪些事不能交给模型」**的判断。
一、核心论点：把确定性还给代码
项目的设计哲学可以压缩成一句话：确定性工程负责绝不能错的步骤，Agent 负责动态决策与上下文检索。
拆开看，被划入「确定性」一侧的有四项：
| 确定性职责 | 解决什么问题 | 交给模型会怎样 |
|---|---|---|
| 精确文件选择 | 决定哪些文件必须审、哪些过滤 | 漏审，且漏审原因不可复现 |
| 智能文件捆绑 | 相关文件归组（如中英文资源文件） | 跨文件关联断裂，上下文错配 |
| 细粒度规则匹配 | 基于模板引擎匹配规则 | 规则命中随提示词漂移 |
| 评论定位与反思 | 独立模块校正位置与内容 | 评论指向错误行号 |
而划入「Agent」一侧的是两块：针对代码审查优化的场景化提示词模板（据项目方说明可降低 token 消耗），以及从生产数据中提炼出的场景化工具集。
这个划分的工程意义在于可归因性。当审查结果不理想时，你能区分是「文件选错了」（确定性问题，可修复）还是「模型判断错了」（概率性问题，不可修复），而不是面对一个黑箱输出猜测原因。
二、上手：三条命令的路径
安装走 npm，装完得到全局命令 ocr。前提是 Git 版本不低于 2.41。
npm install -g @alibaba-group/open-code-review
ocr config provider # 选择内置或自定义 provider
ocr config model # 为当前 provider 选模型配置是交互式的，会引导填 API key 并自动测试连通性。之后按审查范围选命令：
cd your-project
# 工作区模式：审查已暂存、未暂存、未跟踪的全部变更
ocr review
# 分支范围：审查 feature-branch 自 main 分叉以来的变更
ocr review --from main --to feature-branch
# 单个提交
ocr review --commit abc123两个容易被忽略但很实用的能力：
# 全文件扫描，不需要 git 历史，适合审计陌生代码库
ocr scan
ocr scan --path internal/agent
# 中断后恢复，长审查不必从头再来
ocr session list
ocr review --from main --to feature-branch --resume <session-id>输出格式上有一个设计值得注意：
ocr review --format json --output result.json把审查结果以 JSON 输出，明显是给宿主 Agent 消费的。这暗示了它的定位不是终端的终点，而是流水线中的一环。
三、AACR-Bench：一份像样的基准
工具类项目愿意公开基准并且公开数据集，本身就值得肯定。它公布的口径如下：
仓库数 50 个流行开源仓库
真实 PR 200 个
覆盖语言 10 种
问题标注 1505 个真实问题
标注方式 80+ 高级工程师交叉验证
数据集 AACR-Bench（已发布在 Hugging Face）对照通用 Agent（同底层模型）的关键结论：
| 指标 | 表现 |
|---|---|
| 精确率 / F1 | 显著更高 |
| Token 消耗 | 约为通用 Agent 的九分之一 |
| 审查速度 | 更快 |
| 召回率 | 更低（刻意权衡） |
九分之一 token 这个数字比精度提升更值得关注，因为它直接决定这套东西能不能放进 CI。如果审查一次 PR 的成本高到需要斟酌，那它只能作为按需调用的工具；成本降到九分之一，才有机会变成每次推送都跑的默认环节。
关于召回率更低，项目方的表述是刻意的取舍——优先精度而非噪声。这个取舍可以理解，但使用方必须自己算一遍代价：日常业务代码里误报让开发者疲劳、进而忽略全部评论，这确实是真实损失；但在支付、鉴权、加密这类路径上，一条漏报的代价远高于十条误报。同一个默认配置不可能同时适合这两种场景。
四、delegate 模式：从竞品变成增强层
如果团队已经在用 Claude Code、Codex 或 Cursor，最该看的是委托模式：
ocr delegate preview
ocr delegate rule src/main.go src/handler.go这个模式下 Open Code Review 不调用自己的 LLM，只负责文件选择与规则解析，实际审查交给宿主编码 Agent，因此不需要额外配置 LLM 端点，直接使用宿主已有的订阅。
这是一个聪明的定位。它把「要不要换掉现有工具链」这个高摩擦决策，换成了「要不要给现有工具加一层确定性前置」，后者几乎没有迁移成本。对已经为编码 Agent 付了订阅费的团队来说，这条路径的增量成本接近零。
CI 集成方面，仓库里有 GitHub Action 的 action.yml，支持 effort、max_tokens_budget（转发为对应的 CLI 参数）、stream_progress（默认关闭的实时进度输出）、以及 llm_reasoning_effort 等输入。max_tokens_budget 这个显式的预算参数值得单独表扬——把成本上限做成可配置项而不是任其浮动，是把它放进自动化流水线的前提。
五、什么时候该用，什么时候别用
适合的场景：仓库体量大、PR 数量多、审查人力是瓶颈；团队已经在用某个编码 Agent 并希望提升审查质量而不更换工具链；需要定期审计不熟悉的代码库（用 ocr scan 可以不依赖 git 历史）。
不适合的场景：以漏报为零为目标的合规或安全审查，低召回率会是硬伤；单体小项目、PR 一周几个，人工审查的收益仍然高于引入一套配置；需要审查非代码资产（文档、配置文件语义）的场景，规则集不覆盖。
接入前应当自己验证的三件事：在你的技术栈上跑一遍基准之外的真实 PR，量一下误报率能不能被团队接受；确认 effort 与 token 预算的实际分布，避免长 PR 上成本和延迟失控；检查内置规则集与你团队的规范是否冲突，冲突的规则要显式关掉而不是靠提示词压。
六、局限
第一，基准是自建的。AACR-Bench 由项目方发布，虽然包含了交叉验证与公开数据集两个加分项，但自建基准天然存在选择偏差，九分之一 token 这类对比数字应当在自家代码上复核。
第二，规则集的能力边界不完全透明。内置规则以 NPE、线程安全、XSS、SQL 注入等多语言问题为主，这些都是可形式化程度较高的缺陷类型；对架构层面的问题（抽象泄漏、边界划分错误、并发模型不一致）能覆盖多少，公开材料里没有明确说明，而这类问题恰恰是资深审查者最有价值的部分。
第三，不开源 LLM 时依赖 provider 质量。审查质量仍然受底层模型能力约束，混合架构解决的是稳定性与成本，不是判断上限。同模型下它比通用 Agent 更准，但换一个更弱的模型，天花板同样会降。
结语
Open Code Review 值得作为「Agent 工程化」的一个正面样本来看。它没有试图用一个更长的提示词去解决所有问题，而是先做了一次职责划分：把有确定答案的判断从模型手里拿走，交还给代码。
这个思路的适用面远不止代码审查。任何一个「Agent 表现不稳定」的场景，都值得问一遍同样的问题——这里面有多少步骤其实是有确定答案的，只是被顺手交给了模型？