OpenCode Review 委托模式Delegation Mode实战指南让宿主 Agent 用自己的 LLM 完成代码审查【免费下载链接】open-code-reviewFast, efficient, battle-tested at Alibabas scale. Hybrid architecture code review tool: deterministic pipelines LLM Agent, precise line-level comments, built-in multi-language ruleset (NPE, thread-safety, XSS, SQL injection), OpenAI Anthropic compatible.项目地址: https://gitcode.com/GitHub_Trending/op/open-code-review本文档为委托模式Delegation Mode的完整技术指南。委托模式是 OpenCode ReviewOCR为订阅制 AI 编码 Agent 设计的一种集成方式OCR 只负责文件筛选、规则解析等确定性工程实际的代码审查推理由宿主 Agent如 Claude Code、Codex、Cursor、Open Code、Qoder借助其自身的 LLM 订阅额度完成OCR 侧完全不调用任何 LLM 端点。读完本文你将掌握ocr delegate preview/ocr delegate rule两个子命令的完整用法、共享 flag 的语义与限制、JSON 输出契约以及如何把委托模式接入自己的 Agent 工作流。什么是委托模式OCR 做脚手架Agent 做审查在 OCR 的三种集成模式中委托模式是唯一一种「LLM 调用方」不在 OCR 侧的模式模式谁调用 LLM典型使用场景Agent SkillOCRAgent 调用ocr reviewOCR 驱动完整审查流程Command (Claude Code)OCRClaude Code 中的斜杠命令OCR 驱动审查委托模式Delegation Mode宿主 AgentOCR 提供脚手架Agent 驱动审查委托模式的设计动机非常直白如果你已经在使用按订阅付费的 AI 编码 Agent那么与其再为 OCR 单独配置一套模型端点ocr config set …或环境变量不如直接复用宿主 Agent 已有的订阅额度。OCR 退居幕后只输出两份「审查规格」review specocr delegate preview—— 决定审什么输出审查模式、ref 元数据和可审查文件清单ocr delegate rule path...—— 提供审查依据为文件清单解析出按内容分组的审查规则。从源码结构看委托模式在 cmd/opencodereview/delegate_cmd.go 中被实现为delegate命令下的两个子命令其 Long 描述直接点明了设计意图“Output review spec for host-agent delegation (no LLM required)”。何时使用委托模式委托模式针对以下三类场景设计你的 AI 编码 Agent 是订阅制希望复用已有配额做代码审查——无需额外 API Key 或模型配置你只想让 OCR 提供工程脚手架文件过滤、规则解析、排除逻辑LLM 推理全部交给宿主 Agent你在构建自定义 Agent 流水线需要一个结构化的输入文件清单 规则来驱动自己的审查步骤。前置条件只需安装ocrCLI无需任何 LLM 配置which ocr || npm install -g alibaba-group/open-code-review委托模式在 OCR 侧从不调用 LLM因此不需要ocr config set …也不需要设置任何模型相关的环境变量。这一点在 skills/open-code-review-delegate/SKILL.md 的compatibility字段中有明确声明“Does NOT require a configured LLM endpoint — delegation mode is LLM-free on the OCR side”。安装 Skill / CommandClaude Code —— Command 方式mkdir -p .claude/commands curl -o .claude/commands/delegate-review.md \ https://raw.githubusercontent.com/alibaba/open-code-review/main/plugins/open-code-review/claude-code/commands/delegate-review.md安装后Claude Code 中即可通过该命令触发委托模式。命令的 manifest 位于 plugins/open-code-review/claude-code/commands/delegate-review.md其中内置了完整的五步工作流指引先ocr delegate preview拿到模式/ref 元数据再ocr delegate rule获取规则清单然后按模式构造 git diff 命令逐个文件审查最后按严重级别分类并自动修复 High/Medium 问题。任意 Agent —— Skill 方式推荐使用 skills CLI 安装npx skills add alibaba/open-code-review --skill open-code-review-delegate也可以手动拷贝 manifestcp -R /path/to/open-code-review/skills/open-code-review-delegate ~/.claude/skills/Skill 的完整定义在 skills/open-code-review-delegate/SKILL.md它是一个纯指令型 skill不依赖任何外部工具调用只是把「预览 → 取规则 → 取 diff → 审查 → 报告」这一套协议写清楚让宿主 Agent 照着执行。工作流五步完成委托审查Step 1Preview —— 确定要审查什么ocr delegate preview [--from ref --to ref] [--commit hash] [--exclude patterns]输出内容包括mode—— workspace / range / commit 三种之一ref 元数据—— from、to、commit、merge_base可审查文件清单—— 路径、状态、增删行数被排除文件—— 附排除原因。常用调用方式场景命令工作区改动ocr delegate preview分支对比ocr delegate preview --from main --to feature单个提交ocr delegate preview -c abc123模式判定逻辑从 delegate_cmd.go 的reviewMode()实现可以看到三种模式的优先级是commitrangeworkspace只要提供了--commit就是 commit 模式否则若--from与--to同时给出则是 range 模式两者都没有则为 workspace 模式。对应的组合校验在 delegate_helpers_test.go 的TestValidateDelegateOptions中覆盖from缺to、to缺from、commit 与 range 混用都会被拒绝。merge_base 的计算range 模式下mergeBase()见 delegate_cmd.go通过diff.NewProvider计算两个 ref 的合并基点并写入输出。这个merge_base正是 Step 3 构造git diff命令的关键参数其他模式下它为空字符串。安全性loadDelegateContext在加载上下文时会调用validateReviewRefs拒绝 ref 选项注入见 delegate_cmd.go防止通过--from/--to/--commit注入恶意参数。无副作用保证preview 既不运行也不落盘审查会话。测试 delegate_exec_test.go 中的TestExecuteDelegatePreviewCreatesNoSession专门断言preview 之后~/.opencodereview/sessions目录不会被创建——因为 preview 阶段根本没有打开持久化。Step 2获取文件规则ocr delegate rule path1 path2 ...把 Step 1 输出的可审查路径作为参数传入。输出按规则内容分组共享同一条规则的文件会归入同一组避免重复输出。分组算法位于 internal/delegate/rulegroup.go 的GroupRules它要求sourcecustom/project/global/system、matched pattern、规则文本三者完全一致才归为同一组以source\x00pattern\x00text作为分组 key。也就是说两条规则文本完全相同但来源不同的文件例如分别命中项目规则和系统默认规则会留在不同的组从而保证每组内Source/Pattern元数据对每个文件都准确。Markdown 输出由 internal/delegate/format.go 的RuleGroupsMarkdown渲染每个组以### Rule Group N: source / pattern标题开头列出适用文件后给出#### Content规则正文组之间以---分隔。对应的渲染断言见 internal/delegate/format_test.go。Step 3获取 Diff根据 Step 1 的 mode / ref 信息直接用 git 取 diffRange 模式preview 输出中提供了 merge_basegit diff merge_base..to -- pathCommit 模式git show commit -- pathWorkspace 模式git diff HEAD -- path # 已跟踪文件 cat path # 新增的未跟踪文件注意 workspace 模式下preview 会把未跟踪文件一并纳入清单对于这些文件git diff 拿不到内容直接读取文件本身即可整个文件都是新代码。Step 4逐个文件审查对每个可审查文件获取其 diffStep 3对照其所属 Rule Group 的规则正文Step 2作为审查清单结合上下文探索工具进行彻底审查只评论变更行 行。审查维度建议覆盖正确性、安全性、性能、错误处理、并发、可维护性。对于大型变更按共享规则与 diff 大小分批处理不要在发现第一个 High 级问题后就停止。Step 5报告按严重级别分类每个发现Critical/High—— bug、安全问题、数据丢失风险。必须报告Medium—— 性能隐患、错误处理缺口、可维护性问题。带上上下文报告Low—— 风格 nit、小建议。除非明显有价值否则静默丢弃。Skill 对输出格式有更严格的要求见 SKILL.md每条评论应遵循path / content / start_line / end_line / category / severity字段结构其中category取值于bug, security, performance, maintainability, test, style, documentation, otherseverity取值于critical, high, medium, low。报告前必须核对每个 preview 文件都已覆盖reviewed 或带原因的 skipped并在总结中给出total_files、reviewed_files、skipped_files、coverage_rate。子命令参考命令用途ocr delegate preview列出可审查文件 mode/ref 元数据ocr delegate rule path...按内容分组的审查规则解析两个子命令共享同一套 flag 注册逻辑registerDelegateFlags见 cmd/opencodereview/shared_flags.go。共享 FlagsFlag说明--from refrange 模式的源 ref--to refrange 模式的目标 ref-c, --commit hash单提交模式--repo path仓库根目录默认当前目录 cwd--rule path自定义 rule.json 路径--exclude patterns逗号分隔的排除模式-b, --background text业务上下文-B, --background-file path从 Markdown 文件读取业务上下文优先于-b--max-git-procs最大并发 git 子进程数默认 16源码注册于 shared_flags.go-f, --format text\|json输出格式Agent 集成请用json几点需要注意的语义细节--background-file优先于-b测试 delegate_exec_test.go 的TestLoadDelegateContext_BackgroundFile验证了同时传入两者时文件内容胜出、内联文本被忽略。背景上下文有双重上限原始文件不得超过 1 MiB净化后的内容不得超过 8000 字符任一超限都会中止命令。正确的恢复姿势是先总结再重试不要静默截断源文件而是把原文总结成保留需求、约束、验收标准的精简文本作为单个 shell 安全参数传入或用新的小文件传入并且不要再传--background-file若无法忠实总结就直接省略 OCR 背景在审查时自行阅读原文。--format json需要ocrv1.9.0如果preview/rule报unknown flag: --format说明 CLI 版本过旧去掉该 flag 改用文本输出继续跑完委托流程即可不要解析文本当 JSON也不要为其他错误去掉 flag 重试。需要schema_version等 JSON 字段的程序化集成应先用ocr --version确认版本必要时npm install -g alibaba-group/open-code-review升级。这个降级与升级策略在 SKILL.md 的 Troubleshooting 一节有完整说明。sarif格式不被委托模式支持validateDelegateOptions只接受text与json见 delegate_helpers_test.go 中{sarif format not supported by delegate, ..., true}用例flag 的 completion 也只提供这两个枚举值。JSON 输出契约Agent 集成要点给 Agent 集成时使用--format json。preview的输出封套定义于 delegate_cmd.go字段包括schema_version—— 当前为1常量delegateSchemaVersionmode—— workspace / range / commitrepository、from、to、commit、merge_base、backgroundtotal_files、reviewable_count、excluded_counttotal_insertions、total_deletionsreviewable_files[]/excluded_files[]—— 每个条目含path、status、insertions、deletions被排除的条目还带exclude_reason。rule的输出封套delegate_cmd.go包含schema_version与groups[]每组含group_id、source、pattern、files、rule。测试 delegate_exec_test.go 对 JSON 契约做了断言JSON 数组必须是非 null 的空数组reviewable_files/excluded_files不能为 nullfiles同样必须序列化为[]而不是null方便下游程序化消费。writeDelegateJSON使用带缩进、不转义 HTML 的编码器输出保证可读性。与其他集成模式的取舍回到开头的对比表三种模式的本质区别在于「谁在调用 LLM」Agent Skill 模式OCR 驱动完整审查ocr review由 OCR 调用 LLM需要配置模型端点Claude Code Command 模式斜杠命令形式同样是 OCR 驱动审查且带自动修复能力委托模式OCR 只做确定性工程LLM 推理完全由宿主 Agent 承担OCR 侧零 LLM 配置。如果你的团队已经在使用订阅制 AI 编码工具且希望审查逻辑与主开发 Agent 保持同一套「智能」委托模式是最省配置的集成路径如果希望审查独立于任何特定 Agent、可复现可审计则应选择 OCR 自驱的 Agent Skill 或 Command 模式。更详细的对比可参见 Agent Skill 与 Command (Claude Code) 两篇文档。【免费下载链接】open-code-reviewFast, efficient, battle-tested at Alibabas scale. Hybrid architecture code review tool: deterministic pipelines LLM Agent, precise line-level comments, built-in multi-language ruleset (NPE, thread-safety, XSS, SQL injection), OpenAI Anthropic compatible.项目地址: https://gitcode.com/GitHub_Trending/op/open-code-review创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 OpenCode Review 委托模式（Delegation Mode）实战指南：让宿主 Agent 用自己的 LLM 完成代码审查
OpenCode Review 委托模式Delegation Mode实战指南让宿主 Agent 用自己的 LLM 完成代码审查【免费下载链接】open-code-reviewFast, efficient, battle-tested at Alibabas scale. Hybrid architecture code review tool: deterministic pipelines LLM Agent, precise line-level comments, built-in multi-language ruleset (NPE, thread-safety, XSS, SQL injection), OpenAI Anthropic compatible.项目地址: https://gitcode.com/GitHub_Trending/op/open-code-review本文档为委托模式Delegation Mode的完整技术指南。委托模式是 OpenCode ReviewOCR为订阅制 AI 编码 Agent 设计的一种集成方式OCR 只负责文件筛选、规则解析等确定性工程实际的代码审查推理由宿主 Agent如 Claude Code、Codex、Cursor、Open Code、Qoder借助其自身的 LLM 订阅额度完成OCR 侧完全不调用任何 LLM 端点。读完本文你将掌握ocr delegate preview/ocr delegate rule两个子命令的完整用法、共享 flag 的语义与限制、JSON 输出契约以及如何把委托模式接入自己的 Agent 工作流。什么是委托模式OCR 做脚手架Agent 做审查在 OCR 的三种集成模式中委托模式是唯一一种「LLM 调用方」不在 OCR 侧的模式模式谁调用 LLM典型使用场景Agent SkillOCRAgent 调用ocr reviewOCR 驱动完整审查流程Command (Claude Code)OCRClaude Code 中的斜杠命令OCR 驱动审查委托模式Delegation Mode宿主 AgentOCR 提供脚手架Agent 驱动审查委托模式的设计动机非常直白如果你已经在使用按订阅付费的 AI 编码 Agent那么与其再为 OCR 单独配置一套模型端点ocr config set …或环境变量不如直接复用宿主 Agent 已有的订阅额度。OCR 退居幕后只输出两份「审查规格」review specocr delegate preview—— 决定审什么输出审查模式、ref 元数据和可审查文件清单ocr delegate rule path...—— 提供审查依据为文件清单解析出按内容分组的审查规则。从源码结构看委托模式在 cmd/opencodereview/delegate_cmd.go 中被实现为delegate命令下的两个子命令其 Long 描述直接点明了设计意图“Output review spec for host-agent delegation (no LLM required)”。何时使用委托模式委托模式针对以下三类场景设计你的 AI 编码 Agent 是订阅制希望复用已有配额做代码审查——无需额外 API Key 或模型配置你只想让 OCR 提供工程脚手架文件过滤、规则解析、排除逻辑LLM 推理全部交给宿主 Agent你在构建自定义 Agent 流水线需要一个结构化的输入文件清单 规则来驱动自己的审查步骤。前置条件只需安装ocrCLI无需任何 LLM 配置which ocr || npm install -g alibaba-group/open-code-review委托模式在 OCR 侧从不调用 LLM因此不需要ocr config set …也不需要设置任何模型相关的环境变量。这一点在 skills/open-code-review-delegate/SKILL.md 的compatibility字段中有明确声明“Does NOT require a configured LLM endpoint — delegation mode is LLM-free on the OCR side”。安装 Skill / CommandClaude Code —— Command 方式mkdir -p .claude/commands curl -o .claude/commands/delegate-review.md \ https://raw.githubusercontent.com/alibaba/open-code-review/main/plugins/open-code-review/claude-code/commands/delegate-review.md安装后Claude Code 中即可通过该命令触发委托模式。命令的 manifest 位于 plugins/open-code-review/claude-code/commands/delegate-review.md其中内置了完整的五步工作流指引先ocr delegate preview拿到模式/ref 元数据再ocr delegate rule获取规则清单然后按模式构造 git diff 命令逐个文件审查最后按严重级别分类并自动修复 High/Medium 问题。任意 Agent —— Skill 方式推荐使用 skills CLI 安装npx skills add alibaba/open-code-review --skill open-code-review-delegate也可以手动拷贝 manifestcp -R /path/to/open-code-review/skills/open-code-review-delegate ~/.claude/skills/Skill 的完整定义在 skills/open-code-review-delegate/SKILL.md它是一个纯指令型 skill不依赖任何外部工具调用只是把「预览 → 取规则 → 取 diff → 审查 → 报告」这一套协议写清楚让宿主 Agent 照着执行。工作流五步完成委托审查Step 1Preview —— 确定要审查什么ocr delegate preview [--from ref --to ref] [--commit hash] [--exclude patterns]输出内容包括mode—— workspace / range / commit 三种之一ref 元数据—— from、to、commit、merge_base可审查文件清单—— 路径、状态、增删行数被排除文件—— 附排除原因。常用调用方式场景命令工作区改动ocr delegate preview分支对比ocr delegate preview --from main --to feature单个提交ocr delegate preview -c abc123模式判定逻辑从 delegate_cmd.go 的reviewMode()实现可以看到三种模式的优先级是commitrangeworkspace只要提供了--commit就是 commit 模式否则若--from与--to同时给出则是 range 模式两者都没有则为 workspace 模式。对应的组合校验在 delegate_helpers_test.go 的TestValidateDelegateOptions中覆盖from缺to、to缺from、commit 与 range 混用都会被拒绝。merge_base 的计算range 模式下mergeBase()见 delegate_cmd.go通过diff.NewProvider计算两个 ref 的合并基点并写入输出。这个merge_base正是 Step 3 构造git diff命令的关键参数其他模式下它为空字符串。安全性loadDelegateContext在加载上下文时会调用validateReviewRefs拒绝 ref 选项注入见 delegate_cmd.go防止通过--from/--to/--commit注入恶意参数。无副作用保证preview 既不运行也不落盘审查会话。测试 delegate_exec_test.go 中的TestExecuteDelegatePreviewCreatesNoSession专门断言preview 之后~/.opencodereview/sessions目录不会被创建——因为 preview 阶段根本没有打开持久化。Step 2获取文件规则ocr delegate rule path1 path2 ...把 Step 1 输出的可审查路径作为参数传入。输出按规则内容分组共享同一条规则的文件会归入同一组避免重复输出。分组算法位于 internal/delegate/rulegroup.go 的GroupRules它要求sourcecustom/project/global/system、matched pattern、规则文本三者完全一致才归为同一组以source\x00pattern\x00text作为分组 key。也就是说两条规则文本完全相同但来源不同的文件例如分别命中项目规则和系统默认规则会留在不同的组从而保证每组内Source/Pattern元数据对每个文件都准确。Markdown 输出由 internal/delegate/format.go 的RuleGroupsMarkdown渲染每个组以### Rule Group N: source / pattern标题开头列出适用文件后给出#### Content规则正文组之间以---分隔。对应的渲染断言见 internal/delegate/format_test.go。Step 3获取 Diff根据 Step 1 的 mode / ref 信息直接用 git 取 diffRange 模式preview 输出中提供了 merge_basegit diff merge_base..to -- pathCommit 模式git show commit -- pathWorkspace 模式git diff HEAD -- path # 已跟踪文件 cat path # 新增的未跟踪文件注意 workspace 模式下preview 会把未跟踪文件一并纳入清单对于这些文件git diff 拿不到内容直接读取文件本身即可整个文件都是新代码。Step 4逐个文件审查对每个可审查文件获取其 diffStep 3对照其所属 Rule Group 的规则正文Step 2作为审查清单结合上下文探索工具进行彻底审查只评论变更行 行。审查维度建议覆盖正确性、安全性、性能、错误处理、并发、可维护性。对于大型变更按共享规则与 diff 大小分批处理不要在发现第一个 High 级问题后就停止。Step 5报告按严重级别分类每个发现Critical/High—— bug、安全问题、数据丢失风险。必须报告Medium—— 性能隐患、错误处理缺口、可维护性问题。带上上下文报告Low—— 风格 nit、小建议。除非明显有价值否则静默丢弃。Skill 对输出格式有更严格的要求见 SKILL.md每条评论应遵循path / content / start_line / end_line / category / severity字段结构其中category取值于bug, security, performance, maintainability, test, style, documentation, otherseverity取值于critical, high, medium, low。报告前必须核对每个 preview 文件都已覆盖reviewed 或带原因的 skipped并在总结中给出total_files、reviewed_files、skipped_files、coverage_rate。子命令参考命令用途ocr delegate preview列出可审查文件 mode/ref 元数据ocr delegate rule path...按内容分组的审查规则解析两个子命令共享同一套 flag 注册逻辑registerDelegateFlags见 cmd/opencodereview/shared_flags.go。共享 FlagsFlag说明--from refrange 模式的源 ref--to refrange 模式的目标 ref-c, --commit hash单提交模式--repo path仓库根目录默认当前目录 cwd--rule path自定义 rule.json 路径--exclude patterns逗号分隔的排除模式-b, --background text业务上下文-B, --background-file path从 Markdown 文件读取业务上下文优先于-b--max-git-procs最大并发 git 子进程数默认 16源码注册于 shared_flags.go-f, --format text\|json输出格式Agent 集成请用json几点需要注意的语义细节--background-file优先于-b测试 delegate_exec_test.go 的TestLoadDelegateContext_BackgroundFile验证了同时传入两者时文件内容胜出、内联文本被忽略。背景上下文有双重上限原始文件不得超过 1 MiB净化后的内容不得超过 8000 字符任一超限都会中止命令。正确的恢复姿势是先总结再重试不要静默截断源文件而是把原文总结成保留需求、约束、验收标准的精简文本作为单个 shell 安全参数传入或用新的小文件传入并且不要再传--background-file若无法忠实总结就直接省略 OCR 背景在审查时自行阅读原文。--format json需要ocrv1.9.0如果preview/rule报unknown flag: --format说明 CLI 版本过旧去掉该 flag 改用文本输出继续跑完委托流程即可不要解析文本当 JSON也不要为其他错误去掉 flag 重试。需要schema_version等 JSON 字段的程序化集成应先用ocr --version确认版本必要时npm install -g alibaba-group/open-code-review升级。这个降级与升级策略在 SKILL.md 的 Troubleshooting 一节有完整说明。sarif格式不被委托模式支持validateDelegateOptions只接受text与json见 delegate_helpers_test.go 中{sarif format not supported by delegate, ..., true}用例flag 的 completion 也只提供这两个枚举值。JSON 输出契约Agent 集成要点给 Agent 集成时使用--format json。preview的输出封套定义于 delegate_cmd.go字段包括schema_version—— 当前为1常量delegateSchemaVersionmode—— workspace / range / commitrepository、from、to、commit、merge_base、backgroundtotal_files、reviewable_count、excluded_counttotal_insertions、total_deletionsreviewable_files[]/excluded_files[]—— 每个条目含path、status、insertions、deletions被排除的条目还带exclude_reason。rule的输出封套delegate_cmd.go包含schema_version与groups[]每组含group_id、source、pattern、files、rule。测试 delegate_exec_test.go 对 JSON 契约做了断言JSON 数组必须是非 null 的空数组reviewable_files/excluded_files不能为 nullfiles同样必须序列化为[]而不是null方便下游程序化消费。writeDelegateJSON使用带缩进、不转义 HTML 的编码器输出保证可读性。与其他集成模式的取舍回到开头的对比表三种模式的本质区别在于「谁在调用 LLM」Agent Skill 模式OCR 驱动完整审查ocr review由 OCR 调用 LLM需要配置模型端点Claude Code Command 模式斜杠命令形式同样是 OCR 驱动审查且带自动修复能力委托模式OCR 只做确定性工程LLM 推理完全由宿主 Agent 承担OCR 侧零 LLM 配置。如果你的团队已经在使用订阅制 AI 编码工具且希望审查逻辑与主开发 Agent 保持同一套「智能」委托模式是最省配置的集成路径如果希望审查独立于任何特定 Agent、可复现可审计则应选择 OCR 自驱的 Agent Skill 或 Command 模式。更详细的对比可参见 Agent Skill 与 Command (Claude Code) 两篇文档。【免费下载链接】open-code-reviewFast, efficient, battle-tested at Alibabas scale. Hybrid architecture code review tool: deterministic pipelines LLM Agent, precise line-level comments, built-in multi-language ruleset (NPE, thread-safety, XSS, SQL injection), OpenAI Anthropic compatible.项目地址: https://gitcode.com/GitHub_Trending/op/open-code-review创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考