open-code-review 委派模式Delegation Mode实战指南宿主 AI 智能体驱动、OCR 侧零 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-reviewopen-code-review下文简称 OCR的**委派模式Delegation Mode**将代码审查拆解为两个边界清晰的阶段OCR 只负责确定性的工程任务——文件筛选、规则解析与排除逻辑而真正的代码审查推理交给宿主 AI 智能体如 Claude Code、Codex、Cursor 等利用其自身的 LLM 能力完成OCR 侧完全不调用任何 LLM、不需要配置任何模型端点。本指南将围绕官方文档 委派模式同见 英文版讲解该模式的使用场景、Skill/命令安装方式、完整的五步工作流、全部子命令与共享标志并结合仓库源码delegate_cmd.go、rulegroup.go、SKILL.md深入说明其底层实现原理读完即可在自己的订阅型 AI 编程智能体上落地一套无需额外 API Key 的代码审查流程。委派模式的核心思想OCR 只做脚手架推理交给宿主智能体OCR 的常规审查模式ocr review、Agent Skill、Claude Code slash 命令中LLM 调用发生在 OCR 进程内部OCR 从文件选择、规则加载到逐文件审查、结果输出全流程主导。而委派模式反其道而行之OCR 端不需要 LLM 端点它输出的是一份审查规格说明review spec——即该审查哪些文件、每个文件适用什么规则——由宿主智能体拿着这份规格使用自己的模型与工具完成实际审查。这一设计在 delegate_cmd.go 的命令描述中被明确为 Output review spec for host-agent delegation (no LLM required)其底层实现也印证了这一点executeDelegatePreview调用 internal/agent/preview.go 中的agent.Preview注释明确说明它 returns structured preview data without dispatching any LLM calls且不会创建会话、清单或 runner不会在 OCR 主目录留下未完结的 JSONL 会话文件executeDelegateRule调用delegate.GroupRules完成规则解析与分组同样零 LLM 参与从 delegate_cmd.go 的loadDelegateContext可以看到委派命令只加载仓库上下文、规则解析器、文件过滤器与背景上下文不触碰任何 provider/model 配置。换句话说委派模式下 OCR 退化为一个纯粹的确定性工程组件这使它成为订阅型 AI 编程智能体生态中的理想补充订阅费已经包含了宿主智能体的 LLM 额度无需再为代码审查单独购买 API Key。何时使用委派模式委派模式专门面向基于订阅的 AI 编程智能体——如 Claude Code、Codex、Cursor、Open Code、Qoder 等——这类智能体的订阅中已捆绑了 LLM 能力。使用委派模式而非单独为 OCR 配置模型端点可以直接复用宿主智能体已有的订阅额度来完成审查。官方文档给出了三个典型适用场景复用订阅额度你的 AI 编程智能体采用订阅制希望用已有额度做代码审查不想额外配置 API Key 或模型只想要工程脚手架只需要 OCR 提供文件过滤、规则解析、排除逻辑等确定性能力所有 LLM 推理由宿主智能体承担自建智能体流水线你正在搭建自己的审查管道需要结构化输入文件清单 规则来驱动自定义的审查环节。前置要求委派模式唯一的硬性前提是ocrCLI 已安装which ocr || npm install -g alibaba-group/open-code-review不需要任何 LLM 配置——无论是ocr config set …还是环境变量都无需设置因为委派模式下 OCR 永远不会在自己这一侧调用 LLM。安装 Skill 或命令委派模式的使用入口有两种形态Claude Code 的 slash 命令以及适用于任意智能体的 Skill。Claude Code —— 命令在仓库中该命令的源文件位于 plugins/open-code-review/claude-code/commands/delegate-review.md。安装到当前项目的.claude/commands目录mkdir -p .claude/commands cp plugins/open-code-review/claude-code/commands/delegate-review.md .claude/commands/安装后即可在 Claude Code 中以 slash 命令触发。该命令文件定义了完整的委派工作流先ocr delegate preview确定审查范围无参数时默认为 workspace 模式即已暂存 未暂存 未跟踪文件用户传--commit/-c或--from/--to时原样透传再ocr delegate rule取规则最后按 mode/ref 信息用 git 取 diff 并逐文件审查重点只针对变更行 行提意见。任意智能体 —— SkillOCR 为委派模式提供了官方 Skill清单文件位于 skills/open-code-review-delegate/SKILL.md元数据声明name: open-code-review-delegate、version: 1.0.0、许可为 Apache-2.0。安装方式二选一# 通过 skills 工具安装 npx skills add alibaba/open-code-review --skill open-code-review-delegate # 或手动复制清单到 Claude 的 skills 目录 cp -R skills/open-code-review-delegate ~/.claude/skills/Skill 的 frontmatter 中compatibility字段同样强调不要求配置 LLM 端点委派模式在 OCR 侧是无 LLMLLM-free的。五步工作流委派模式的运行时流程分为五步预览、取规则、取 diff、逐文件审查、输出报告。前两步由ocr delegate完成后三步由宿主智能体借助 git 与自身能力完成。Step 1preview —— 确定要审查什么ocr delegate preview [--from ref --to ref] [--commit hash] [--exclude patterns]输出包含四类关键信息mode—— 审查模式workspace/range/commit引用元数据ref metadata——from、to、commit、merge_base供后续构造 git 命令可审查文件清单—— 路径、状态status、新增/删除行数被排除的文件—— 附带排除原因。常用调用方式场景命令工作区改动ocr delegate preview分支对比ocr delegate preview --from main --to feature单个提交ocr delegate preview -c abc123模式的判定逻辑在源码中有精确对应。delegate_cmd.go 的reviewMode()按优先级判定--commit非空则为commit模式否则--from与--to均非空则为range模式其余情况为workspace模式。而 shared_flags.go 的validateDiffMode负责校验这三种模式互斥--from/--to与--commit不能同时使用且--from必须搭配--to反之亦然。文本输出格式delegate_cmd.go为结构化 Markdown# Files (N reviewable / M total) - mode: range - from: main - to: feature - merge_base: hash - total_insertions: N - total_deletions: M - internal/agent/agent.go [modified] 123/-45 - foo.bin [added] 1/-0 (excluded: binary)~~被排除的文件以删除线标记并注明原因。排除原因由 preview.go 的whyExcluded依次判定二进制文件binary、用户规则排除user_rule、不受支持的扩展名extension、默认排除路径default_path、已删除文件deleted。Step 2rule —— 获取文件的审查规则ocr delegate rule path1 path2 ...把 Step 1 输出的可审查路径传进来。输出按规则内容分组规则相同的文件归入同一组避免重复输出同样的规则文本。分组的底层实现在 internal/delegate/rulegroup.goGroupRules以source|pattern|text三元组作为分组键——只有当两个文件的规则来源custom/project/global/system、匹配的 glob 模式与解析后的规则文本三者完全一致时才归入同一组即使规则文本相同但来源或匹配模式不同也会分成不同组从而保证每组携带的 Source/Pattern 元数据对该组内所有文件都准确。文本渲染则由 format.go 的RuleGroupsMarkdown完成输出形如### Rule Group N: source / pattern的 Markdown 小节包含适用文件列表与规则正文。Step 3取 diff拿到 mode 与 ref 元数据后直接使用 git 取每个文件的 diff无需 OCR 介入range 模式preview 会提供merge_basegit diff merge_base..to -- pathcommit 模式git show commit -- pathworkspace 模式git diff HEAD -- path # 已跟踪文件 cat path # 新增的未跟踪文件整个文件都是新代码直接读取Step 4逐文件审查对每个可审查文件取该文件的 diffStep 3以 Step 2 得到的对应规则组作为审查清单checklist进行充分深入的审查必要时借助上下文探索工具。Step 5输出报告按严重级别对每条发现分类Critical/High—— 缺陷、安全问题、数据丢失风险。必须报告Medium—— 性能隐患、错误处理不足、可维护性问题。带上下文报告Low—— 风格问题、细微建议。除非有明确价值否则静默丢弃。Skill 清单 SKILL.md 对输出格式做了更严格的规定每条评论应包含path相对路径必填、content评论文本必填、start_line/end_line新文件中的行号范围可选、category枚举bug / security / performance / maintainability / test / style / documentation / other、severity枚举critical / high / medium / low。汇总时必须覆盖每一个 preview 文件并给出total_files、reviewed_files、skipped_files、coverage_rate被跳过的文件必须附具体原因。若用户要求 review and fix则直接修复 High/Critical 问题、描述需要人工介入的 Medium 修复、跳过 Low 项。子命令与共享标志参考子命令命令用途ocr delegate preview输出可审查文件清单与 mode/ref 元数据ocr delegate rule path...解析审查规则并按内容分组输出delegate命令本身还有别名ddelegate_cmd.go即ocr d preview、ocr d rule均可用。共享标志两个子命令注册了完全一致的共享标志见 shared_flags.go 的registerDelegateFlags标志说明--from refrange 模式的源引用--to refrange 模式的目标引用-c, --commit hash单提交模式--repo path仓库根目录默认当前工作目录--rule path自定义 rule.json 路径--exclude patterns逗号分隔的排除模式gitignore 风格与 rule.json 中的 excludes 合并-b, --background text业务上下文-B, --background-file path从 Markdown 文件读取业务上下文优先级高于-b--max-git-procs n最大并发 git 子进程数默认 16-f, --format text\|json输出格式智能体集成时用jsondelegate 模式不支持 sarif校验逻辑shared_flags.govalidateDelegateOptions会拦截非法组合例如同时指定--from/--to与--commit或--format取值不是text/json。另外 delegate_cmd.go 中还会调用validateReviewRefs做引用选项注入ref-option injection的安全校验。JSON 输出面向智能体集成的结构化格式当-f, --format json时preview 与 rule 分别输出带版本号的 JSON。preview的 schemadelegate_cmd.go为schema_version固定为1、mode、repository、from、to、commit、merge_base、background均为可选字段未提供时省略total_files、reviewable_count、excluded_count、total_insertions、total_deletionsreviewable_files与excluded_files数组每项含path、status、insertions、deletions被排除项带exclude_reason。rule的 schemadelegate_cmd.go为groups数组每组含group_id、source、pattern、files、rule解析后的规则全文。注意版本兼容性SKILL.md 明确指出--format标志自ocrv1.9.0 起可用Skill 与 CLI 可以各自独立升级。如果带--format json的命令报错unknown flag: --format说明 CLI 版本过旧——去掉该标志用文本输出继续即可但不要把文本输出当 JSON 解析或臆造缺失的 schema 字段程序化集成若强依赖schema_version等 JSON 字段则必须要求支持 JSON 的 CLI 版本用ocr --version确认后通过npm install -g alibaba-group/open-code-review升级。关键实践细节与注意事项OCR 侧绝无 LLM 调用—— 委派模式的所有智能都来自宿主智能体这是该模式与常规模式最本质的区别规则按内容分组—— 共享同一规则的文件归并到一组避免重复输出每次调用可传任意数量的路径改动很大时分批取规则即可工作目录很重要——ocr delegate作用于当前目录下的 Git 仓库可用--repo /path覆盖workspace 模式包含未跟踪文件—— 对这类文件应直接cat读取而不是用git diff覆盖率是强制的—— 每个reviewable_files条目最终要么标记为已审查要么明确跳过并说明原因不得静默遗漏workspace 模式下同一路径可能出现两次—— 当暂存的删除之后紧接着一个未跟踪的重建时preview 会以(path, status)作为清单标识区分这两条记录大改动分批审查—— 按共享规则组与 diff 体量分批进行发现第一个 High 级问题后不要停下背景上下文有硬性上限——--background-file同时受两个独立限制原始文件不得超过 1 MiB且净化后的内容不得超过 8000 字符任一超限都会中止命令。遇到该限制时不要静默截断源文件应先总结原始材料保留需求、约束、验收标准等审查关键信息再将摘要以 shell 安全的方式作为单个参数传入注意$()、反引号、引号、变量引用仍可能被求值不要把不可信的摘要文本直接放进双引号 shell 模板中并省略原来的--background-file以免重复加载失败若无法忠实总结则干脆不传背景审查时直接读取原始材料。与其他集成模式的对比OCR 官方文档将委派模式与其他两种集成方式并列模式谁调用 LLM适用场景Agent SkillOCR智能体调用ocr reviewOCR 主导完整审查流程Claude Code 命令OCRClaude Code 中的 slash 命令OCR 主导审查委派模式宿主智能体OCR 提供脚手架智能体主导审查三者的选择要点很清晰如果希望审查流程由 OCR 全权托管、只关心最终评论结果选 Agent Skill 或 Claude Code 命令如果希望宿主智能体用自己的订阅额度、自己的推理风格来驱动审查并且只需要 OCR 提供文件筛选与规则解析则选委派模式。委派模式也让自建审查管道成为可能——preview与rule输出的结构化规格无论是文本还是 JSON都可以直接作为自定义智能体管道的输入。总结委派模式是 open-code-review 面向订阅型 AI 编程智能体生态设计的一条轻量集成路径ocr delegate preview输出审查范围与 mode/ref 元数据ocr delegate rule输出按内容分组的规则清单宿主智能体据此用 git 取 diff、逐文件审查并按严重级别输出报告——整个过程 OCR 侧零 LLM 配置、零 API 开销。其确定性工程能力文件筛选、排除逻辑、规则解析在 delegate_cmd.go、preview.go 与 rulegroup.go 中均有可验证的源码实现配合 SKILL.md 提供的结构化输出协议与边界约束非常适合在 Claude Code、Codex、Cursor 等订阅制智能体中开箱即用地复用订阅额度完成代码审查。【免费下载链接】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），仅供参考 open-code-review 委派模式（Delegation Mode）实战指南：宿主 AI 智能体驱动、OCR 侧零 LLM 的代码审查工作流
open-code-review 委派模式Delegation Mode实战指南宿主 AI 智能体驱动、OCR 侧零 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-reviewopen-code-review下文简称 OCR的**委派模式Delegation Mode**将代码审查拆解为两个边界清晰的阶段OCR 只负责确定性的工程任务——文件筛选、规则解析与排除逻辑而真正的代码审查推理交给宿主 AI 智能体如 Claude Code、Codex、Cursor 等利用其自身的 LLM 能力完成OCR 侧完全不调用任何 LLM、不需要配置任何模型端点。本指南将围绕官方文档 委派模式同见 英文版讲解该模式的使用场景、Skill/命令安装方式、完整的五步工作流、全部子命令与共享标志并结合仓库源码delegate_cmd.go、rulegroup.go、SKILL.md深入说明其底层实现原理读完即可在自己的订阅型 AI 编程智能体上落地一套无需额外 API Key 的代码审查流程。委派模式的核心思想OCR 只做脚手架推理交给宿主智能体OCR 的常规审查模式ocr review、Agent Skill、Claude Code slash 命令中LLM 调用发生在 OCR 进程内部OCR 从文件选择、规则加载到逐文件审查、结果输出全流程主导。而委派模式反其道而行之OCR 端不需要 LLM 端点它输出的是一份审查规格说明review spec——即该审查哪些文件、每个文件适用什么规则——由宿主智能体拿着这份规格使用自己的模型与工具完成实际审查。这一设计在 delegate_cmd.go 的命令描述中被明确为 Output review spec for host-agent delegation (no LLM required)其底层实现也印证了这一点executeDelegatePreview调用 internal/agent/preview.go 中的agent.Preview注释明确说明它 returns structured preview data without dispatching any LLM calls且不会创建会话、清单或 runner不会在 OCR 主目录留下未完结的 JSONL 会话文件executeDelegateRule调用delegate.GroupRules完成规则解析与分组同样零 LLM 参与从 delegate_cmd.go 的loadDelegateContext可以看到委派命令只加载仓库上下文、规则解析器、文件过滤器与背景上下文不触碰任何 provider/model 配置。换句话说委派模式下 OCR 退化为一个纯粹的确定性工程组件这使它成为订阅型 AI 编程智能体生态中的理想补充订阅费已经包含了宿主智能体的 LLM 额度无需再为代码审查单独购买 API Key。何时使用委派模式委派模式专门面向基于订阅的 AI 编程智能体——如 Claude Code、Codex、Cursor、Open Code、Qoder 等——这类智能体的订阅中已捆绑了 LLM 能力。使用委派模式而非单独为 OCR 配置模型端点可以直接复用宿主智能体已有的订阅额度来完成审查。官方文档给出了三个典型适用场景复用订阅额度你的 AI 编程智能体采用订阅制希望用已有额度做代码审查不想额外配置 API Key 或模型只想要工程脚手架只需要 OCR 提供文件过滤、规则解析、排除逻辑等确定性能力所有 LLM 推理由宿主智能体承担自建智能体流水线你正在搭建自己的审查管道需要结构化输入文件清单 规则来驱动自定义的审查环节。前置要求委派模式唯一的硬性前提是ocrCLI 已安装which ocr || npm install -g alibaba-group/open-code-review不需要任何 LLM 配置——无论是ocr config set …还是环境变量都无需设置因为委派模式下 OCR 永远不会在自己这一侧调用 LLM。安装 Skill 或命令委派模式的使用入口有两种形态Claude Code 的 slash 命令以及适用于任意智能体的 Skill。Claude Code —— 命令在仓库中该命令的源文件位于 plugins/open-code-review/claude-code/commands/delegate-review.md。安装到当前项目的.claude/commands目录mkdir -p .claude/commands cp plugins/open-code-review/claude-code/commands/delegate-review.md .claude/commands/安装后即可在 Claude Code 中以 slash 命令触发。该命令文件定义了完整的委派工作流先ocr delegate preview确定审查范围无参数时默认为 workspace 模式即已暂存 未暂存 未跟踪文件用户传--commit/-c或--from/--to时原样透传再ocr delegate rule取规则最后按 mode/ref 信息用 git 取 diff 并逐文件审查重点只针对变更行 行提意见。任意智能体 —— SkillOCR 为委派模式提供了官方 Skill清单文件位于 skills/open-code-review-delegate/SKILL.md元数据声明name: open-code-review-delegate、version: 1.0.0、许可为 Apache-2.0。安装方式二选一# 通过 skills 工具安装 npx skills add alibaba/open-code-review --skill open-code-review-delegate # 或手动复制清单到 Claude 的 skills 目录 cp -R skills/open-code-review-delegate ~/.claude/skills/Skill 的 frontmatter 中compatibility字段同样强调不要求配置 LLM 端点委派模式在 OCR 侧是无 LLMLLM-free的。五步工作流委派模式的运行时流程分为五步预览、取规则、取 diff、逐文件审查、输出报告。前两步由ocr delegate完成后三步由宿主智能体借助 git 与自身能力完成。Step 1preview —— 确定要审查什么ocr delegate preview [--from ref --to ref] [--commit hash] [--exclude patterns]输出包含四类关键信息mode—— 审查模式workspace/range/commit引用元数据ref metadata——from、to、commit、merge_base供后续构造 git 命令可审查文件清单—— 路径、状态status、新增/删除行数被排除的文件—— 附带排除原因。常用调用方式场景命令工作区改动ocr delegate preview分支对比ocr delegate preview --from main --to feature单个提交ocr delegate preview -c abc123模式的判定逻辑在源码中有精确对应。delegate_cmd.go 的reviewMode()按优先级判定--commit非空则为commit模式否则--from与--to均非空则为range模式其余情况为workspace模式。而 shared_flags.go 的validateDiffMode负责校验这三种模式互斥--from/--to与--commit不能同时使用且--from必须搭配--to反之亦然。文本输出格式delegate_cmd.go为结构化 Markdown# Files (N reviewable / M total) - mode: range - from: main - to: feature - merge_base: hash - total_insertions: N - total_deletions: M - internal/agent/agent.go [modified] 123/-45 - foo.bin [added] 1/-0 (excluded: binary)~~被排除的文件以删除线标记并注明原因。排除原因由 preview.go 的whyExcluded依次判定二进制文件binary、用户规则排除user_rule、不受支持的扩展名extension、默认排除路径default_path、已删除文件deleted。Step 2rule —— 获取文件的审查规则ocr delegate rule path1 path2 ...把 Step 1 输出的可审查路径传进来。输出按规则内容分组规则相同的文件归入同一组避免重复输出同样的规则文本。分组的底层实现在 internal/delegate/rulegroup.goGroupRules以source|pattern|text三元组作为分组键——只有当两个文件的规则来源custom/project/global/system、匹配的 glob 模式与解析后的规则文本三者完全一致时才归入同一组即使规则文本相同但来源或匹配模式不同也会分成不同组从而保证每组携带的 Source/Pattern 元数据对该组内所有文件都准确。文本渲染则由 format.go 的RuleGroupsMarkdown完成输出形如### Rule Group N: source / pattern的 Markdown 小节包含适用文件列表与规则正文。Step 3取 diff拿到 mode 与 ref 元数据后直接使用 git 取每个文件的 diff无需 OCR 介入range 模式preview 会提供merge_basegit diff merge_base..to -- pathcommit 模式git show commit -- pathworkspace 模式git diff HEAD -- path # 已跟踪文件 cat path # 新增的未跟踪文件整个文件都是新代码直接读取Step 4逐文件审查对每个可审查文件取该文件的 diffStep 3以 Step 2 得到的对应规则组作为审查清单checklist进行充分深入的审查必要时借助上下文探索工具。Step 5输出报告按严重级别对每条发现分类Critical/High—— 缺陷、安全问题、数据丢失风险。必须报告Medium—— 性能隐患、错误处理不足、可维护性问题。带上下文报告Low—— 风格问题、细微建议。除非有明确价值否则静默丢弃。Skill 清单 SKILL.md 对输出格式做了更严格的规定每条评论应包含path相对路径必填、content评论文本必填、start_line/end_line新文件中的行号范围可选、category枚举bug / security / performance / maintainability / test / style / documentation / other、severity枚举critical / high / medium / low。汇总时必须覆盖每一个 preview 文件并给出total_files、reviewed_files、skipped_files、coverage_rate被跳过的文件必须附具体原因。若用户要求 review and fix则直接修复 High/Critical 问题、描述需要人工介入的 Medium 修复、跳过 Low 项。子命令与共享标志参考子命令命令用途ocr delegate preview输出可审查文件清单与 mode/ref 元数据ocr delegate rule path...解析审查规则并按内容分组输出delegate命令本身还有别名ddelegate_cmd.go即ocr d preview、ocr d rule均可用。共享标志两个子命令注册了完全一致的共享标志见 shared_flags.go 的registerDelegateFlags标志说明--from refrange 模式的源引用--to refrange 模式的目标引用-c, --commit hash单提交模式--repo path仓库根目录默认当前工作目录--rule path自定义 rule.json 路径--exclude patterns逗号分隔的排除模式gitignore 风格与 rule.json 中的 excludes 合并-b, --background text业务上下文-B, --background-file path从 Markdown 文件读取业务上下文优先级高于-b--max-git-procs n最大并发 git 子进程数默认 16-f, --format text\|json输出格式智能体集成时用jsondelegate 模式不支持 sarif校验逻辑shared_flags.govalidateDelegateOptions会拦截非法组合例如同时指定--from/--to与--commit或--format取值不是text/json。另外 delegate_cmd.go 中还会调用validateReviewRefs做引用选项注入ref-option injection的安全校验。JSON 输出面向智能体集成的结构化格式当-f, --format json时preview 与 rule 分别输出带版本号的 JSON。preview的 schemadelegate_cmd.go为schema_version固定为1、mode、repository、from、to、commit、merge_base、background均为可选字段未提供时省略total_files、reviewable_count、excluded_count、total_insertions、total_deletionsreviewable_files与excluded_files数组每项含path、status、insertions、deletions被排除项带exclude_reason。rule的 schemadelegate_cmd.go为groups数组每组含group_id、source、pattern、files、rule解析后的规则全文。注意版本兼容性SKILL.md 明确指出--format标志自ocrv1.9.0 起可用Skill 与 CLI 可以各自独立升级。如果带--format json的命令报错unknown flag: --format说明 CLI 版本过旧——去掉该标志用文本输出继续即可但不要把文本输出当 JSON 解析或臆造缺失的 schema 字段程序化集成若强依赖schema_version等 JSON 字段则必须要求支持 JSON 的 CLI 版本用ocr --version确认后通过npm install -g alibaba-group/open-code-review升级。关键实践细节与注意事项OCR 侧绝无 LLM 调用—— 委派模式的所有智能都来自宿主智能体这是该模式与常规模式最本质的区别规则按内容分组—— 共享同一规则的文件归并到一组避免重复输出每次调用可传任意数量的路径改动很大时分批取规则即可工作目录很重要——ocr delegate作用于当前目录下的 Git 仓库可用--repo /path覆盖workspace 模式包含未跟踪文件—— 对这类文件应直接cat读取而不是用git diff覆盖率是强制的—— 每个reviewable_files条目最终要么标记为已审查要么明确跳过并说明原因不得静默遗漏workspace 模式下同一路径可能出现两次—— 当暂存的删除之后紧接着一个未跟踪的重建时preview 会以(path, status)作为清单标识区分这两条记录大改动分批审查—— 按共享规则组与 diff 体量分批进行发现第一个 High 级问题后不要停下背景上下文有硬性上限——--background-file同时受两个独立限制原始文件不得超过 1 MiB且净化后的内容不得超过 8000 字符任一超限都会中止命令。遇到该限制时不要静默截断源文件应先总结原始材料保留需求、约束、验收标准等审查关键信息再将摘要以 shell 安全的方式作为单个参数传入注意$()、反引号、引号、变量引用仍可能被求值不要把不可信的摘要文本直接放进双引号 shell 模板中并省略原来的--background-file以免重复加载失败若无法忠实总结则干脆不传背景审查时直接读取原始材料。与其他集成模式的对比OCR 官方文档将委派模式与其他两种集成方式并列模式谁调用 LLM适用场景Agent SkillOCR智能体调用ocr reviewOCR 主导完整审查流程Claude Code 命令OCRClaude Code 中的 slash 命令OCR 主导审查委派模式宿主智能体OCR 提供脚手架智能体主导审查三者的选择要点很清晰如果希望审查流程由 OCR 全权托管、只关心最终评论结果选 Agent Skill 或 Claude Code 命令如果希望宿主智能体用自己的订阅额度、自己的推理风格来驱动审查并且只需要 OCR 提供文件筛选与规则解析则选委派模式。委派模式也让自建审查管道成为可能——preview与rule输出的结构化规格无论是文本还是 JSON都可以直接作为自定义智能体管道的输入。总结委派模式是 open-code-review 面向订阅型 AI 编程智能体生态设计的一条轻量集成路径ocr delegate preview输出审查范围与 mode/ref 元数据ocr delegate rule输出按内容分组的规则清单宿主智能体据此用 git 取 diff、逐文件审查并按严重级别输出报告——整个过程 OCR 侧零 LLM 配置、零 API 开销。其确定性工程能力文件筛选、排除逻辑、规则解析在 delegate_cmd.go、preview.go 与 rulegroup.go 中均有可验证的源码实现配合 SKILL.md 提供的结构化输出协议与边界约束非常适合在 Claude Code、Codex、Cursor 等订阅制智能体中开箱即用地复用订阅额度完成代码审查。【免费下载链接】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），仅供参考