引言“通用 Agent 做代码审查的问题不是它看不出 bug而是它不知道该看哪里看完了把行号搞错还用了 9 倍的 token。”这是「每日一个开源项目」系列的第 181 篇。今天的项目是Open Code Review—— 阿里巴巴将内部 AI 代码审查工具开源的成果2026 年发布在开源之前已在阿里内部服务了数万名工程师“识别了数百万代码缺陷”。市面上用 LLM 做代码 review 的工具不少但大多数是把 diff 直接扔给大模型然后等输出。Open Code Review 的出发点不同它有一套混合架构——确定性工程管道处理绝对不能出错的事文件选取、位置定位、规则匹配LLM Agent 只处理需要动态判断的部分。结果是相同的底层模型精确率和 F1 值更高token 消耗约为通用 Agent 的 1/9。18,100 颗 Star1,200 个 ForkApache 2.0。你会学到什么混合架构的设计逻辑为什么把确定性和Agent分开ocr review增量审查和ocr scan全文件审计的差异Delegation 模式让你自己的 Agent 跑审查不需要 OCR 的 API keyBenchmark 数据与 Claude Code 作为通用 Agent 的对比GitHub Actions 集成和三个 SLA 审查级别AI 生成代码的特有缺陷检测前提知识有 Git 工作流经验branch、diff、PR了解 CI/CD 的基本概念用过 Claude Code 或类似 AI 编程工具会有帮助项目背景从内部工具到开源Open Code Review 不是为了开源而造的新项目而是阿里巴巴内部实际运行多年的工具对外发布。这个区别很重要它的设计决策来自真实的规模化运营经验而不是从零开始的想象。在内部版本里这套系统服务了数万名工程师识别了数百万代码缺陷真实处理了生产级别的代码库复杂度通用 Agent 做代码 review 的问题把 diff 直接扔给 Claude Code 或 GPT 做代码 review有几个系统性的弱点问题表现文件覆盖不完整Agent 自主决定看哪些文件可能遗漏关键的跨文件依赖位置漂移行号标注不准确comment 落在错误的位置质量不稳定同样的 diff 不同次运行问题严重程度的判断差异大token 消耗高通用 Agent 会读取大量不必要的上下文这些问题的根源是通用 Agent 为了灵活性把所有决策都交给 LLM 动态处理包括那些本来可以用确定性代码精确处理的部分。核心架构混合设计Open Code Review 的设计哲学让确定性的事情用确定性的方式处理让 Agent 只处理真正需要动态判断的部分。Git 变更 ↓ [确定性层] ├── 精确文件选取不遗漏、不多选 ├── 智能 Bundle 分组相关文件聚合成独立子 Agent 上下文 ├── 模板引擎规则匹配NPE、线程安全、XSS、SQL 注入等 └── 外部定位 反射模块精确行级注释位置 ↓ [Agent 层] ├── 场景专调的 prompt 和工具集 ├── 基于生产 tool-call trace 分析优化 └── 动态上下文检索和工具调用 ↓ 代码审查结果精确行级注释确定性层负责从 git 变更里精确选取所有需要审查的文件把相关文件打包成独立的 Bundle每个 Bundle 在独立上下文里处理分而治之用模板引擎匹配常见缺陷规则而不是每次都让 LLM 从头判断确保输出的行号标注精确不产生位置漂移Agent 层负责基于生产环境的 tool-call traces 分析和优化过的 prompt需要跨文件推理的复杂判断动态工具调用这个分工的结果精确率更高确定性层避免了 LLM 的随机性token 更省Agent 只处理真正复杂的部分。Benchmark 数据Open Code Review 团队构建了一套基准测试数据来自50 个开源仓库200 个 PR10 种编程语言1,505 个标注问题由 80 名工程师人工标注与使用相同底层模型的 Claude Code通用 Agent 模式对比指标Open Code ReviewClaude Code通用 AgentPrecision精确率更高较低F1 值更高较低Recall召回率较低刻意取舍较高Token 消耗~1/9基准关于 Recall 的取舍Open Code Review 刻意把 Recall 设计得低于通用 Agent这不是缺陷而是权衡——宁可少报 bug也不要用大量噪音淹没真正的问题。对于 CI/CD 流水线来说高精确率和低噪音比高召回率更实用。Token 消耗的实际含义同样的 100 个 PROpen Code Review 消耗的 token 约等于通用 Agent 的 11%。在 CI/CD 里每个 PR 都触发审查的场景下这个差异直接决定了工具能不能用——一个月的 API 费用差了将近 10 倍。两种审查模式ocr review增量审查最常用基于 git diff只审查变更部分# 审查当前工作区的改动staged unstagedocr review# 审查特定分支范围ocr review--frommain--tofeature/new-auth# 审查单个 commitocr review--commitabc1234# 指定输出格式ocr review--outputjson ocr review--outputsarif# 可导入 GitHub Securityocr scan全文件审计不依赖 git 历史直接审查文件内容# 审查指定目录ocr scan--pathinternal/# 审查单个文件ocr scan--pathsrc/auth/handler.go# 输出 HTML 报告ocr scan--pathsrc/--outputhtml适合场景接手别人的代码库做安全审计、老项目的代码质量摸底、没有 git 历史的代码片段审查。Delegation 模式这是 Open Code Review 里最有意思的设计之一。传统模式OCR 的 Agent 层使用你配置的 LLM API需要 Anthropic/OpenAI key来执行审查。Delegation 模式OCR 只负责确定性层文件选取、Bundle 分组、规则解析把审查任务委托给你已有的 AgentClaude Code、Codex、Cursor 等用那个 Agent 自己的 LLM 来跑。# 预览 delegation 计划看 OCR 打算怎么拆分任务ocr delegate preview# 针对特定文件生成规则描述供 Agent 审查ocr delegate rule src/main.go src/handler.go为什么有用你已经有 Claude Code 订阅或 API key不需要为 OCR 单独配置另一个 keyOCR 的确定性层做了文件选取和规则解析你的 Agent 只需要做真正的理解和判断整合到已有的 Agent 工作流里不需要切换工具GitHub Actions 集成三十秒配置每个 PR 自动触发审查name:AI Code Reviewon:[pull_request]jobs:review:runs-on:ubuntu-lateststeps:-uses:actions/checkoutv4-uses:raye-deng/open-code-reviewv1with:sla:L2# 审查深度L1 / L2 / L3threshold:60# 质量分低于 60 则 failgithub-token:${{secrets.GITHUB_TOKEN}}三个 SLA 级别级别说明适用场景L1快速结构检测不需要 AI快速 PR、低风险变更L2加入语义分析和 embedding常规功能开发L3完整 LLM 深度扫描跨文件一致性、逻辑 bug 检测、置信度评分核心路径、安全敏感代码AI 生成代码的专项检测Open Code Review 在 GitHub Marketplace 里定位为首个专为 AI 生成代码构建的 CI/CD 质量门针对 AI 编程工具的特有输出模式做了专项检测缺陷类型具体表现幻觉 import引用了不存在的包实时验证 npm/PyPI/Maven过时 API训练数据里有但已废弃的方法上下文窗口产物跨多个文件的逻辑矛盾过度工程不必要的抽象和死代码安全反模式硬编码密钥、eval()使用这些问题传统 linter 基本发现不了但在 AI 生成的代码里出现概率显著高于人工编写的代码。支持语言TypeScript/JavaScript、Python、Java、Go、Kotlin6 种。安装和配置安装# npm推荐npminstall-galibaba-group/open-code-review# 要求 Git 2.41git--version配置 LLMocr config provider# 交互式配置选择 Anthropic / OpenAI / 自定义兼容接口通过.ocrrc.yml精细配置sla:L3ai:embedding:provider:ollamamodel:nomic-embed-textllm:provider:ollama# 支持本地 Ollamamodel:qwen3-coder# 任何 OpenAI 兼容的模型第一次运行# 在你的 git 仓库里cdmy-project# 审查当前改动ocr review# 查看会话支持断点续传ocr session list项目地址与资源GitHub: alibaba/open-code-review官网/文档: open-codereview.aiGitHub Marketplace: Open Code Review Actionnpm:alibaba-group/open-code-review总结Open Code Review 的核心贡献是证明了一件事在代码审查这个特定场景里用工程手段约束 LLM 比让 LLM 自由发挥效果更好。通用 Agent 做 code review 的问题不是 LLM 能力不够而是把所有决策都交给 LLM 本身就引入了不必要的随机性和 token 浪费。把文件选取、行号定位、规则匹配这些有确定答案的事情用确定性代码处理LLM 的注意力才能集中在真正需要理解和判断的地方。这个设计思路值得推广不是怎么让 AI 做得更好而是哪些部分本来就不该让 AI 做。这是很多 AI 工具在规模化应用中反复撞墙后才得出的结论阿里巴巴把内部踩过的坑打包进来一起开源了。探索 PrimeSkills —— 精选 AI Agent 与技能的市场每一个都经过真实企业工作流验证去掉浮夸留下真正有用的。欢迎访问我的个人主页发现更多有价值的见解和有趣的产品。