阿里巴巴开源AI代码审查工具，解决LLM审查漏审、位置漂移问题

[开源分享] Open Code Review 阿里巴巴内部打磨两年的 AI 代码审查助手的开源版本，用 Go 编写的 CLI 工具（命令名 ocr），读取 Git diff，让 LLM Agent...

[开源分享] Open Code Review 阿里巴巴内部打磨两年的 AI 代码审查助手的开源版本，用 Go 编写的 CLI 工具（命令名 ocr），读取 Git diff，让 LLM Agent 带着专用工具去审查代码，输出行级精确定位的审查意见，把 “代码审查” 做到工程化、可复现。 github.com/alibaba/open-c… 通用 Agent（如 Codex\Claude Code + Skills）做代码审查的三大顽疾，这也是这个项目架构要解决的： 1. 漏审：大变更集下 Agent 会“偷懒”，只挑部分文件看； 2. 位置漂移：报出的问题和实际代码行对不上； 3. 质量不稳定：纯自然语言驱动，prompt 微调就会引起质量波动。 根因诊断是：纯语言驱动的架构对审查过程缺少硬约束。这个诊断直接催生了它的核心设计。 核心架构：确定性工程 × Agent 混合 多阶段流水线，每个阶段用独立的、短的 prompt 模板（位于 internal/config/template/prompts/）： 1. Grouping：先让 LLM 把变更文件按语义聚成审查组（接口与实现、中英文 properties 文件等打包），每组最多 10 个文件 2. Plan：规划风险点与工具调用策略 3. Main Review：Agent 挂载工具进行实际审查，产出意见 4. Re-location：独立的定位模块，从 diff 中反向提取意见对应的确切代码片段——这就是“位置不漂移”的工程保证 5. Review Filter：事实核查模块，只删除被 diff 证实有误的意见。其 prompt 里有一段很精彩的偏置说明：“保留错误意见只浪费审阅者几秒钟，删掉正确意见则永远无人知晓”——宁可漏删，不可误删 6. Memory Compression：超长会话时压缩对话历史，配合 session 恢复机制 Agent 可调用的工具只有 7 个（internal/tool/definitions.go）：file_read、file_read_diff、file_find、code_search、code_comment（提交意见）、task_done，外加 MCP 动态工具扩展。工具集极简，是从大规模生产轨迹中提炼的——每个工具都有明确职责边界，这与通用 Agent 的“百宝箱”思路形成鲜明对比。 文件分组后由子 Agent 并发审查（internal/agent/ 有完整的 worker pool、预算控制、指纹去重、断点恢复实现），既隔离了上下文又控制了 token。 规则体系：注意力的精细分配 内置 52 份规则文档（internal/config/rules/rule_docs/），通过 system_rules.json 的 glob 路径映射精确匹配：Java 文件用 java.md，MyBatis mapper XML 用 mapper_dao_xml.md，GitHub Workflows、Cargo.toml、protobuf 各有专属规则。 规则本身写得相当克制且实用。以 Java 规则为例：线程安全部分明确列出只在什么情况下报（check-then-act 竞态、非原子复合操作、双重检查锁缺陷）和什么情况下不许报（方法内局部变量、只读操作、已有正确同步）——这正是压低误报率的关键。规则还内嵌了工具调用指引，比如“用 code_search 确认该方法是否涉及数据库操作”再报循环内查询。用户可通过自定义路径过滤扩展规则。 自建 AACR-Bench 的评测结果 在自建的 AACR-Bench 上评测（50 个热门开源仓库、200 个真实 PR、10 种语言、80+ 资深工程师标注 1505 个问题，数据集公开在 Hugging Face）。 结论：相同底层模型下，Precision 和 F1 显著高于通用 Agent，token 消耗仅约 1/9，速度更快；但 Recall 刻意偏低：宁缺毋滥，少报不误报。 “我们召回率更低”也被直接写进 README 里，这对代码审查场景确实是正确的取舍。 💬 0 🔄 0 ❤️ 1 👀 243 📊 1 ⚡