AI-Chain
AI 应用 程式碼審查 AI Agent 开发者工具 Go

OpenCodeReview：用 Deterministic × Agent 混合架构，让 AI Code Review 更可控

分享:
OpenCodeReview：用 Deterministic × Agent 混合架构，让 AI Code Review 更可控
# OpenCodeReview：用 Deterministic × Agent 混合架构，让 AI Code Review 更可控 AI Code Review 最难的问题，通常不是「模型能不能看懂程式码」，而是每一次 review 是否都能稳定地看完该看的档案、把问题标在正确位置，并且让团队能在成本与噪音之间取得可接受的平衡。Alibaba 开源的 [OpenCodeReview](https://github.com/alibaba/open-code-review) 选择了一条务实路线：让 deterministic engineering 负责不能出错的流程约束，再让 agent 负责需要判断与取上下文的部分。 这个设计使它不只是「把 diff 丢给 LLM 的 CLI」，而是一个可以接到本机工作区、CI/CD、GitHub Actions 以及 coding agent 的 code review 工具。本文会从架构、实际使用方式与限制三个角度拆解它，并说明为什么「工程护栏与 agent 分工」可能比单纯堆叠更长 prompt 更适合程式码审查。 ## 先看查证结果 截至 2026-09-17 23:06 UTC，GitHub API 显示 OpenCodeReview 有 34,626 颗 stars、2,461 个 forks；最近一次 push 为 2026-09-17。专案使用 Go，授权为 Apache-2.0，并提供 npm package 与跨平台 release binary。以上数字会随 GitHub 即时变动，本文只把它们当作本次选题时的快照。 - GitHub： - 最新 release 查证： - npm package： ## 本文阅读路线 1. 先理解 deterministic engineering 与 agent 的责任边界。 1. 再用 `ocr review`、`ocr scan` 与 `ocr delegate` 对照三种执行模式。 1. 最后从 CI、成本、召回率与资料治理角度评估它是否适合导入。 ## OpenCodeReview 解决的是哪一层问题？ 一般的 AI review skill 往往以自然语言描述流程：读 diff、找 bug、回报档案与行号。这种方式很快能做出 prototype，但在大型变更上容易出现三种不稳定：部分档案没有被看完、问题位置漂移，以及 prompt 稍微变动就造成输出品质波动。 OpenCodeReview 的核心取舍，是把 review 流程拆成两层： - **Deterministic engineering**：决定哪些档案需要 review、哪些档案应排除、如何把相关档案分组，以及如何做规则匹配。这些是程式逻辑可以明确保证的事情。 - **Agent**：在已经整理好的 review unit 中进行动态判断，读取完整档案、搜寻 repository、取得其他变更档案的上下文，最后产生 review finding。 这个边界很重要。模型不再单独负责「记得所有流程」，而是被放在它比较擅长的区域：理解语意、追踪上下文，以及判断某段程式是否有实际风险。 ## 四个让 review 更可控的工程护栏 ### 1. 先做精确的档案选择 工具不直接要求 agent 自己决定整个 review 范围，而是先透过 Git diff 与 repository 操作找出应处理的档案。这可以降低大型 changeset 被模型跳过一部分的风险，也能把排除规则集中在可测试的程式码中。 ### 2. 相关档案分组，再平行处理 OpenCodeReview 会把有关联的档案组成 review unit，例如不同语系的 properties 档案可以放在同一组。每一组交给隔离的 sub-agent，形成 divide-and-conquer 的处理方式。这种分组同时服务两个目标：保留必要上下文，以及避免单一 prompt 无限制膨胀。 ### 3. 用规则匹配缩小模型注意力 专案内建依档案特征匹配 review rules 的机制，并支援多种语言与设定档格式。与把所有规则放在一段自然语言指示相比，template-engine-based 的匹配方式更容易重现，也更容易针对特定档案类型检查。 ### 4. 把定位与反思拆成独立模组 AI 找到问题不代表它能把 comment 放在正确的 diff 行上。OpenCodeReview 另外处理 comment positioning 与 comment reflection，让「问题内容是否成立」与「应该显示在哪里」不必完全交给同一次模型输出。 这些设计不会让 AI review 变成形式化验证，也不能保证零误报；它们的价值是把容易失控的流程改成可观测、可测试、可重跑的步骤。 ## 三种使用模式 ### 模式一：直接 review Git 变更 先安装 npm launcher： ```bash npm install -g @alibaba-group/open-code-review ``` 进入专案后，第一次使用要设定 LLM provider 与 model： ```bash ocr config provider ocr config model ``` 接着可以依工作情境选择 review 范围： ```bash # 审查 staged、unstaged 与 untracked changes ocr review # 审查两个 branch 之间、从 merge-base 开始的变更 ocr review --from main --to feature-branch # 审查单一 commit ocr review --commit abc123 ``` 如果中途中断，专案有 session 概念可以列出并恢复工作： ```bash ocr session list ocr review --from main --to feature-branch --resume ``` ### 模式二：做整个档案或目录的 scan 当目标不是某个 PR，而是第一次接手陌生 repository、或要审查没有明确 Git diff 的目录，可以使用 `ocr scan`： ```bash # 扫描整个 repository ocr scan # 只扫描指定目录或档案 ocr scan --path internal/agent # 恢复被中断的 scan ocr scan --resume ``` `review` 与 `scan` 的差异，是前者以变更范围为中心，后者以档案内容为中心。导入团队流程时，这两者应分开设计 budget 与执行频率：每个 PR 的 review 需要低延迟，整个 codebase 的 scan 则更适合排程或人工触发。 ### 模式三：把选档与规则交给 coding agent OpenCodeReview 也提供 delegation mode：由既有的 coding agent 执行 review，但仍由 OCR 负责档案选择与规则解析： ```bash ocr delegate preview ocr delegate rule src/main.go src/handler.go ``` 这种模式的意义不是再造一个 agent，而是把 review 的可重现部分抽出来，让 Claude Code、Codex、Cursor、Kimi Code、OpenCode 或其他 skill-compatible agent 共享同一套选择与规则逻辑。对已经有 coding agent 的团队来说，这通常比要求大家各自维护一份 review prompt 更容易治理。 ## 从 CLI 走进 CI/CD 专案根目录的 `action.yml` 提供 GitHub Action，能把 OpenCodeReview 接到 PR review 流程。Action 的输入包括 LLM endpoint、model、认证资讯、review language、timeout、concurrency、规则档，以及是否上传 JSON 结果与 stderr artifact 等设定。 实务上可以分成两阶段导入： 1. **观察期**：先输出 JSON、保存 artifact，只把 finding 放到 summary 或报告中，让团队量测误报率与平均延迟。 1. **门禁期**：确认规则、模型与 budget 稳定后，再依严重度把部分 finding 发布成 inline comment，并保留人工覆核。 这里不宜一开始就把 AI finding 当成硬性 merge blocker。OpenCodeReview README 自己也把 benchmark 的重点描述为偏高 precision、较低 recall 的取舍；这表示它更像「降低 review 噪音的辅助层」，而不是取代测试、静态分析器与资深工程师判断的单一闸门。 ## Benchmark 要怎么读？ README 公布的 AACR-Bench 包含 50 个热门开源 repository、200 个真实 Pull Request、10 种程式语言，以及 80 多位资深工程师交叉验证的 1,505 个标注问题。专案宣称，在相同底层模型下，相较于一般用途 agent，OpenCodeReview 有更高的 precision 与 F1，约使用九分之一的 token，并能更快完成 review；同时 recall 较低，这是刻意偏向减少噪音的设计。 这些是专案 README 的自述结果，不是本文独立重跑的实验。阅读时应特别注意三件事：测试资料是否符合自己的语言与 repository、模型与 prompt 是否相同，以及 precision/recall 与团队真正关心的修复成本是否一致。最可靠的做法，是拿自己过去已由人工确认的 PR 建立小型 replay set，再比较 false positive、漏报、延迟与 token 成本。 ## 内部实作与扩充面 从 repository 结构可以看出，OpenCodeReview 并非单一 CLI 档案： - `cmd/opencodereview`：Cobra CLI、provider 设定、review、scan、delegate、session 与输出格式。 - `internal/diff`：Git diff 解析、hunk 与 comment relocation。 - `internal/agent`：review unit 分组、档案选择与 agent 执行。 - `internal/scan`：全档案扫描的 batch、budget、provider 与 resume 逻辑。 - `internal/llm`：OpenAI-compatible、Anthropic、Bedrock 等 LLM client 与 retry 边界。 - `internal/mcp`：MCP client 与外部工具整合。 - `internal/session`：review session、历史与结果保存。 - `internal/telemetry`：OpenTelemetry metrics 与 traces。 `go.mod` 显示专案以 Go 1.25.5 建置，并直接依赖 Anthropic SDK、OpenAI SDK、MCP Go SDK、Cobra 与 OpenTelemetry。这种拆分让它有几个适合工程团队的扩充点：可以加入新的 provider、调整规则与档案 allowlist、替换输出或 telemetry exporter，而不必把所有逻辑塞进 prompt。 ## 导入前的限制与风险 ### LLM 设定与成本仍然是必要前提 一般模式需要先设定 provider 与 model，review 内容也会送往设定的 LLM endpoint。API key 不应写进 repository 或 CI log；应使用 secret manager，并先确认程式码、设定档与个资能否送到该 provider。若采用 delegation mode，则可由外部 coding agent 执行模型部分，但仍要理解该 agent 的资料流与权限。 ### 高 precision 不等于完整覆盖 偏向少噪音的工具可能漏掉部分真实问题。安全性、资料库 migration、权限边界等高风险变更，不应只靠 AI review。应与 compiler、unit test、SAST、dependency scanning 及人工审查并用。 ### Token budget 与延迟需要实测 分组与平行处理能改善大型变更的稳定性，但每个 review unit 仍可能触发多轮 tool use。导入时要记录每次 review 的档案数、token、wall-clock time、重试次数与人工确认结果，再设定 concurrency、timeout 和 max token budget，而不是直接套用预设值。 ### 专案仍在快速演进 本次查证时最新 release 为 v1.12.5，且 repository 在近期仍有更新。CLI flags、provider 行为与整合方式可能快速变化；正式导入应锁定版本，并把 upgrade 放进可回滚的 CI 变更流程。 ## 结语：把 agent 放在它擅长的地方 OpenCodeReview 值得注意的地方，不只是它能用 LLM 写 code review comment，而是它把「流程正确性」与「语意判断」拆开：档案选择、分组、规则匹配、定位与 session 管理由工程程式负责；模型则集中处理上下文理解与动态决策。 这是一个适合 AI 工程化的设计讯号：当 agent 要进入 CI/CD，不要只问模型够不够聪明，也要问哪些步骤可以被 deterministic 地约束、测试与重跑。对想把 AI review 从一次性 demo 推进到团队流程的人，OpenCodeReview 提供了一个值得研究的 Go 实作案例；但是否适合正式挡 PR，仍应以自己的 replay set、成本资料与人工确认结果作最后判断。 ## 查证来源 - [OpenCodeReview README](https://github.com/alibaba/open-code-review/blob/main/README.md) - [GitHub repository metadata API](https://api.github.com/repos/alibaba/open-code-review) - [Review CLI source](https://github.com/alibaba/open-code-review/blob/main/cmd/opencodereview/review_cmd.go) - [Scan CLI source](https://github.com/alibaba/open-code-review/blob/main/cmd/opencodereview/scan_cmd.go) - [Agent grouping source](https://github.com/alibaba/open-code-review/blob/main/internal/agent/grouping.go) - [Git diff relocation source](https://github.com/alibaba/open-code-review/blob/main/internal/diff/relocation.go) - [GitHub Action definition](https://github.com/alibaba/open-code-review/blob/main/action.yml) - [Go module manifest](https://github.com/alibaba/open-code-review/blob/main/go.mod)