产品多源确认76°

阿里开源 OpenCodeReview:确定性 pipeline 与 Agent 混合的 AI 代码审查工具

精选理由

阿里把内部跑了两年的代码审查工具开源了,用确定性 pipeline 管文件选择,token 消耗只有 Claude Code 的九分之一,还能当插件接进 Cursor。

阿里开源了内部使用两年的 AI 代码审查项目 OpenCodeReview,架构上由确定性工程 pipeline 处理文件选择、捆绑和规则匹配,Agent 只负责动态决策。项目内置约 54 个按语言和文件类型划分的规则文档,默认并发 8 个文件 worker,并通过独立的 re-location 和 reflection 模块校正评论落点漂移。官方自建基准 AACR-Bench 覆盖 50 个开源仓库、200 个真实 PR、1505 条标注问题,数据显示同模型下 Precision 和 F1 高于 Claude Code,token 消耗约为其 1/9,但 Recall 更低,属于以精度换噪声的权衡。项目提供 npm CLI、可移植 Agent Skill,以及面向 Claude Code、Cursor、Kimi Code 等平台的插件。贡献规范要求 AI 生成代码必须披露工具与模型,测试覆盖率门槛为 90%。

原文 · shao__meng

阿里把团队内部用了两年的官方 AI Code Review Skills 开源了,采用 “确定性工程 pipeline + AI Agent” 的混合架构,专门解决通用 Agent 做代码审查时 “漏审、定位漂移、质量不稳” 的老问题。 40.5K ✨ 开源项目 OpenCodeReview: github.com/alibaba/open-c… # 核心设计:确定性工程 pipeline × Agent 各司其职 确定性工程负责硬约束: · 精确文件选择:用代码决定哪些文件必须审、哪些要过滤,不依赖模型自觉; · 智能文件捆绑:把相关文件合成一个审查单元(例如 message_en.properties 和 message_zh.properties 捆绑),每个单元以上下文隔离的 sub-agent 运行,分治策略让超大变更集也稳,且天然支持并发(默认 8 个文件 worker); · 细粒度规则匹配:内置约 54 个按语言/文件类型的规则文档(Java、Go、TS/JS、Python、Rust、SQL/XML mapper、properties 等),用模板引擎而非自然语言把规则匹配到文件特征上,从源头消除信息噪声; · 外部定位与反思模块:评论的“落点”和“内容”分别由独立的 re-location 和 reflection 模块系统性校正,这正对“位置漂移”痛点。 Agent 负责动态决策: · 深度优化的场景 prompt(内部分为 plan → grouping → main → memory_compression → re_location → review_filter 多个任务模板,可在 internal/config/template/prompts/ 看到); · 从海量生产环境的 tool-call 轨迹(调用频率分布、单工具重复率、新工具对调用链的影响)反向蒸馏出的专用工具集,包括全文件读取、代码搜索、其他变更文件查阅等,比通用 agent 工具箱更小更稳。 # 能力面与生态集成 功能上覆盖:workspace/分支区间/单 commit 审查、断点恢复(ocr session)、全文件 scan(无 git 历史也能审计陌生代码库)、本地 Session Viewer 网页查看与回放、SARIF/JSON 输出、OpenTelemetry 可观测性、MCP Server 扩展。 作为 “Skills 生态” 级项目,它的形态相当完整:既提供 npm 全局 CLI,也提供可移植的 Agent Skill(skills/open-code-review/SKILL.md,带标准 frontmatter,可直接被兼容 skill 的 agent 加载),还有面向 Claude Code、Codex、Cursor、Kimi Code、OpenCode 等平台的插件,每种都封装成斜杠命令或可调用 skill。LLM 侧兼容 OpenAI、Anthropic、AWS Bedrock 三类协议,并可直接复用 Claude Code 的 ANTHROPIC_* 环境变量。 其中一个设计很巧妙:Delegation 模式(ocr delegate preview/rule)。此时 OCR 只做自己擅长的确定性部分(文件选择和规则解析)审查本身交给宿主 coding agent 的 LLM 执行,用户无需给 OCR 配任何 API key。这实际上是把“harness 能力”与“模型能力”彻底解耦。 # 工程质量:超出平均水准的部分 · 安全有正式的 Assurance Case(ASSURANCE_CASE.md):完整的威胁模型、四条信任边界、T1–T7 威胁逐条给出缓解措施,并按 Saltzer & Schroeder 设计原则和 OWASP Top 10 做了映射。细节经得起推敲:所有外部进程调用只限 git 且子命令硬编码、--end-of-options 防 flag 注入;Agent 读文件路径经 pathutil.WithinBase() 在符号链接解析前后双重校验;本地 Viewer 有 Host 白名单防 DNS rebinding + 严格 CSP。这类文档在一般开源项目里非常罕见。 · 贡献规范近乎严苛(AGENTS.md):使用 AI 必须在 issue/PR 中披露工具与模型、必须逐行理解 AI 生成的代码、禁止“AI 生成→反复修复→再修复”的循环、禁止把 commit 署名给 AI。源码强制英文(CI 有 english-check,连全角标点都查)、90% 测试覆盖率门槛、-race 与 govulncheck 每次 push 都跑、SPDX 头与 LF 行尾强制。 # Benchmark:数据情况 官方基准 AACR-Bench(已在 Hugging Face 开放)规模不小:50 个流行开源仓库、200 个真实 PR、10 种语言、80+ 资深工程师交叉验证出 1505 条标注问题。结论是同模型对比 Claude Code:Precision 和 F1 显著更高、token 消耗约为 1/9、速度更快。 需要指出两点:其一,Recall 低于通用 agent,README 自己承认这是“以精度换噪声”的刻意权衡,如果你最怕漏问题而非误报,可能不适合;其二,该基准由阿里自建,虽开放了数据集供社区复核,但独立第三方的复现结论目前还少,可以把它当作“有披露的、方向可信的参考”。 💬 3 🔄 1 ❤️ 2 👀 174 📊 4 ⚡