【AI代码测评】OpenCodeReview 架构拆解：确定性工程与 Agent 如何分工

OpenCodeReview 架构拆解：确定性工程与 Agent 如何分工

专栏：《AI 代码评审实战：从 Diff 到 Agentic Review》04/12

← 上一篇 · 专栏目录 · 下一篇 →

👤 个人主页：zzz_2368

🧪 系列主题：Agent 评测｜从结果、轨迹到持续迭代

🔥 热门专栏：Agent | 小z的碎碎念 | Java后端 | Agent 评测

📚 本系列内容：围绕"如何评测和改进 AI 代码评审能力"的技术专栏。

它不是泛泛讲"AI 帮你 Review 代码"，而是更偏工程化、方法论和实战复盘，重点讨论 AI Code Review 里最容易被忽略的几个核心问题

资料核验日期：2026-08-12。本文基于 OpenCodeReview 开源仓库、文档源、项目论文和用户提供的公众号原文。项目方效果数据均按"项目方披露"处理。

文章目录

[OpenCodeReview 架构拆解：确定性工程与 Agent 如何分工](#OpenCodeReview 架构拆解：确定性工程与 Agent 如何分工)
- [1. 原始材料先做事实分层](#1. 原始材料先做事实分层)
- [2. 为什么要把评审拆成两种工作](#2. 为什么要把评审拆成两种工作)
- [3. 一条简化的 OpenCodeReview 流程](#3. 一条简化的 OpenCodeReview 流程)
- [4. 文件筛选：覆盖率从模型调用前开始](#4. 文件筛选：覆盖率从模型调用前开始)
- [5. 文件分组与子 Agent：用分治控制上下文](#5. 文件分组与子 Agent：用分治控制上下文)
- [6. 规则匹配：把团队知识放到正确位置](#6. 规则匹配：把团队知识放到正确位置)
- [7. 工具调用：让 Reviewer 从读 Diff 变成调查](#7. 工具调用：让 Reviewer 从读 Diff 变成调查)
- [8. Reflection：第二次判断不是自动正确](#8. Reflection：第二次判断不是自动正确)
- [9. 位置校验与结构化输出](#9. 位置校验与结构化输出)
- [10. 这套架构真正要验证什么](#10. 这套架构真正要验证什么)
- 结论
- 参考资料

OpenCodeReview 最值得研究的地方，不是它又封装了一次大模型 API，而是它提出了一个很具体的系统边界：评审流程中可确定的部分用工程代码保证，必须理解语义和动态调查的部分交给 Agent。

这比"写一段更强的 Review Prompt"更接近真实工程问题。

1. 原始材料先做事实分层

用户提供的文章介绍了 OpenCodeReview 的内部来源、使用规模、有效评论率、位置准确率和 Benchmark 表现。这些数据有参考价值，但目前属于项目方披露，本专栏没有阿里内部日志，也没有完成同条件独立复现，因此不能写成行业通用结论。

可以确认的公开事实包括：

项目已在 GitHub 开源；
仓库提供 CLI、配置、规则、MCP、工具、Viewer、遥测和多种集成文档；
项目论文描述了规则引导调度、工具调用、文件级子 Agent 和独立 Reflection；
AACR-Bench 提供公开数据与评测代码。

需要验证的问题则是：这些设计在不同仓库、模型和预算下能提升多少 Precision、Recall 与稳定性。

2. 为什么要把评审拆成两种工作

一次 PR Review 包含大量确定性动作：

枚举变更文件；
排除 lock、vendor、构建产物和生成代码；
计算 Diff 行号；
根据路径选择规则；
限制单次上下文和并发；
把评论映射回代码平台；
保存运行状态、日志和成本。

这些工作不需要模型"发挥"。让 Agent 自己决定是否看完所有文件，反而会引入遗漏和不可预测性。

但另一部分工作很难写成固定规则：

这个输入是否会穿过多层调用触发异常？
修改是否违背了某个业务不变量？
为验证猜想应该搜索哪个符号、文档或测试？
同一段代码在当前上下文中是合理权衡还是缺陷？

这些任务需要语义推理和动态工具调用，适合交给 Agent。

3. 一条简化的 OpenCodeReview 流程

根据仓库文档和论文，可以将其抽象为：
#mermaid-svg-tLAkZKB7rjDyM2rL{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-tLAkZKB7rjDyM2rL .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-tLAkZKB7rjDyM2rL .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-tLAkZKB7rjDyM2rL .error-icon{fill:#552222;}#mermaid-svg-tLAkZKB7rjDyM2rL .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-tLAkZKB7rjDyM2rL .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-tLAkZKB7rjDyM2rL .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-tLAkZKB7rjDyM2rL .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-tLAkZKB7rjDyM2rL .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-tLAkZKB7rjDyM2rL .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-tLAkZKB7rjDyM2rL .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-tLAkZKB7rjDyM2rL .marker{fill:#333333;stroke:#333333;}#mermaid-svg-tLAkZKB7rjDyM2rL .marker.cross{stroke:#333333;}#mermaid-svg-tLAkZKB7rjDyM2rL svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-tLAkZKB7rjDyM2rL p{margin:0;}#mermaid-svg-tLAkZKB7rjDyM2rL .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg-tLAkZKB7rjDyM2rL .cluster-label text{fill:#333;}#mermaid-svg-tLAkZKB7rjDyM2rL .cluster-label span{color:#333;}#mermaid-svg-tLAkZKB7rjDyM2rL .cluster-label span p{background-color:transparent;}#mermaid-svg-tLAkZKB7rjDyM2rL .label text,#mermaid-svg-tLAkZKB7rjDyM2rL span{fill:#333;color:#333;}#mermaid-svg-tLAkZKB7rjDyM2rL .node rect,#mermaid-svg-tLAkZKB7rjDyM2rL .node circle,#mermaid-svg-tLAkZKB7rjDyM2rL .node ellipse,#mermaid-svg-tLAkZKB7rjDyM2rL .node polygon,#mermaid-svg-tLAkZKB7rjDyM2rL .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-tLAkZKB7rjDyM2rL .rough-node .label text,#mermaid-svg-tLAkZKB7rjDyM2rL .node .label text,#mermaid-svg-tLAkZKB7rjDyM2rL .image-shape .label,#mermaid-svg-tLAkZKB7rjDyM2rL .icon-shape .label{text-anchor:middle;}#mermaid-svg-tLAkZKB7rjDyM2rL .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-tLAkZKB7rjDyM2rL .rough-node .label,#mermaid-svg-tLAkZKB7rjDyM2rL .node .label,#mermaid-svg-tLAkZKB7rjDyM2rL .image-shape .label,#mermaid-svg-tLAkZKB7rjDyM2rL .icon-shape .label{text-align:center;}#mermaid-svg-tLAkZKB7rjDyM2rL .node.clickable{cursor:pointer;}#mermaid-svg-tLAkZKB7rjDyM2rL .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-tLAkZKB7rjDyM2rL .arrowheadPath{fill:#333333;}#mermaid-svg-tLAkZKB7rjDyM2rL .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-tLAkZKB7rjDyM2rL .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-tLAkZKB7rjDyM2rL .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-tLAkZKB7rjDyM2rL .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-tLAkZKB7rjDyM2rL .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-tLAkZKB7rjDyM2rL .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-tLAkZKB7rjDyM2rL .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-tLAkZKB7rjDyM2rL .cluster text{fill:#333;}#mermaid-svg-tLAkZKB7rjDyM2rL .cluster span{color:#333;}#mermaid-svg-tLAkZKB7rjDyM2rL div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-tLAkZKB7rjDyM2rL .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-tLAkZKB7rjDyM2rL rect.text{fill:none;stroke-width:0;}#mermaid-svg-tLAkZKB7rjDyM2rL .icon-shape,#mermaid-svg-tLAkZKB7rjDyM2rL .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-tLAkZKB7rjDyM2rL .icon-shape p,#mermaid-svg-tLAkZKB7rjDyM2rL .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-tLAkZKB7rjDyM2rL .icon-shape .label rect,#mermaid-svg-tLAkZKB7rjDyM2rL .image-shape .label rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-tLAkZKB7rjDyM2rL .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-tLAkZKB7rjDyM2rL .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-tLAkZKB7rjDyM2rL :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} Git Diff / PR
文件筛选
文件分组与规则匹配
文件级 Review Agent
搜索/读取/调查工具
候选评论
独立 Reflection
位置校验与结构化输出
CLI / Viewer / CI / Agent

如果发布平台不支持 Mermaid，可以将它转换成图片。重点不在节点名称，而在职责分离：枚举、调度、校验和输出尽量确定；调查和判断保持动态。

4. 文件筛选：覆盖率从模型调用前开始

通用 Agent 做 Review 时，一个常见失败是只抽查几份文件。它可能因为上下文预算、工具调用策略或提示词理解，提前认为"已经足够"。

OpenCodeReview 把变更文件列表交给工程逻辑处理。这并不保证每个缺陷都被发现，但至少让"哪些文件进入评审、哪些被排除"可以检查。

这也暴露出配置风险：如果过滤规则写错，系统会稳定地漏掉文件。因此应把最终文件清单纳入日志，并在 CI 中保留。确定性工程的优势是可重复，错误也会可重复。

5. 文件分组与子 Agent：用分治控制上下文

项目材料提到将相关文件组成评审单元，再由隔离的子 Agent 处理。例如同一功能的资源文件、接口与实现、代码与测试，可以在同一个包中分析。

分治带来三种潜在收益：

每个 Agent 的上下文更聚焦；
大变更可以并发执行；
单个 Agent 失败不必丢掉全部结果。

它也有明显代价：跨分组缺陷可能被切断。一个权限问题可能横跨 Controller、Service、DAO 和配置文件，如果分组策略没有把它们关联起来，每个子 Agent 都只能看到局部正确性。

因此"文件级并行"不是天然优于"全局 Agent"，而是一种覆盖、成本和跨文件推理之间的权衡。更成熟的做法可能需要先做仓库级风险扫描，再为高风险分组补充共享背景或二次调查。

6. 规则匹配：把团队知识放到正确位置

一份全局规则文件如果包含 Java、Go、SQL、前端、安全和业务规范，模型会收到大量无关信息。OpenCodeReview 强调根据文件特征匹配规则，其价值是减少注意力噪声。

可以把规则分成四层：

text 复制代码

全局规则：安全、数据、错误处理、禁止事项
语言规则：Java / Go / TypeScript 的通用约束
路径规则：payments/**、auth/**、migration/**
任务规则：当前 PR 的验收标准与已知风险

规则匹配能保证"该给的规则被加载"，不能保证模型一定正确执行。团队仍需要用带已知违规的样例测试规则效果。

7. 工具调用：让 Reviewer 从读 Diff 变成调查

Agentic Review 与普通文本 Review 的关键区别，是模型可以在产生评论前主动调查：搜索符号、读取文件、查看调用方、对照测试或执行受限工具。

GitHub Copilot Code Review 在 2026 年公布 Agentic 架构，也强调工具调用和完整仓库上下文；GitHub 随后的效率更新提到使用 grep、rg、glob、view 等文件工具降低分析成本。这说明行业方向正在从"一次性把上下文塞给模型"转向"让 Agent 按需要检索"。

但工具越多，权限面越大。只读搜索与执行任意 shell 命令不是同一风险级别。评审默认应使用最小权限：只读仓库、禁用密钥、限制网络、限定命令、设置超时。

8. Reflection：第二次判断不是自动正确

OpenCodeReview 设计了独立 Reflection，对候选评论再检查。它可能过滤三类问题：

评论与实际代码不一致；
缺乏足够证据；
正确但没有操作价值。

Reflection 的价值类似"生成者与评审者分离"。但如果两个阶段使用相同模型、相同错误上下文和相近提示词，它们也可能共享盲点。评测时应比较：无 Reflection 与有 Reflection 的 Precision、Recall、成本、延迟分别如何变化，而不是只统计过滤数量。

9. 位置校验与结构化输出

PR 评论必须落在有效 Diff 行，否则再正确也无法写回代码平台。位置映射适合由程序处理：统一文件路径、确认行号属于变更区、标记无法定位的仓库级意见。

结构化评论至少应包含：

json 复制代码

{
  "file": "src/payment/service.ts",
  "line": 87,
  "severity": "high",
  "category": "correctness",
  "claim": "并发更新可能覆盖余额变化",
  "evidence": "read-update-write 之间没有版本检查",
  "suggestion": "增加乐观锁并补充并发测试"
}

这是示意格式，不代表项目的真实 Schema。它说明一个原则：事实主张、证据和修复建议应分开，便于机器校验和人工复核。

10. 这套架构真正要验证什么

如果准备在团队试用，不要先问"它用了几个 Agent"，而应验证：

变更文件清单是否完整且可见；
排除规则是否误伤业务文件；
分组是否切断关键跨文件关系；
工具调用是否找到了与评论相关的证据；
Reflection 降低多少误报，又损失多少 Recall；
位置映射在重命名、删除和大 Diff 中是否稳定；
同一 PR 多次运行的结果波动多大；
每个有效缺陷的成本是否可接受。

结论

OpenCodeReview 的工程价值在于明确了模型与系统的分工：模型不是文件调度器、行号计算器和权限管理器，它应该把有限推理预算花在代码语义和风险调查上。

这套设计方向合理，但项目方数据、论文实验与具体团队收益必须分开。下一篇将进入实践：如何从文档和仓库出发完成第一次 Review，同时避免伪造"我已经成功运行"的教程叙述。

参考资料

Alibaba：OpenCodeReview 仓库
Alibaba：OpenCodeReview 中文文档源
OpenCodeReview：论文
AACR-Bench：论文
GitHub：Copilot Code Review Agentic Architecture
GitHub：Analysis depth and efficiency updates

感谢阅读，记得点赞、关注、收藏，欢迎各位评论区交流！！！