OpenCodeReview CI/CD 集成完全指南在 GitHub Actions 与 GitLab CI 中自动化 PR/MR 代码审查【免费下载链接】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-reviewOpenCodeReviewCLI 命令ocr是一套「确定性流水线 LLM Agent」的混合架构代码审查工具。本文以官方 CI/CD 集成文档为核心完整讲解如何在每次 Pull Request / Merge Request 上自动运行 OCR从 GitHub Actions 与 GitLab CI 两份开箱即用的流水线配方入手覆盖核心命令的参数语义、密钥与 Action inputs 配置、常见自定义场景与排障并结合仓库源码揭示评论回帖与幂等机制的底层实现。读完你既能「复制粘贴」落地一套自动化审查也能按需定制触发方式、规则文件、并发与预算并理解为什么 OCR 在 CI 中必须以--format json --audience agent的方式运行。一、CI/CD 集成的工作原理一种模式两个平台实现官方仓库examples/目录随上游源码附带两份可直接复制使用的流水线配方——一份用于 GitHub Actions一份用于 GitLab CI。它们都是同一核心命令的薄包装该核心命令的完整定义见 CLI Reference。无论哪个平台所有配方都遵循同一个六步模式在 PR / MR 事件上触发——新建的 Pull Request、更新的 Merge Request或一条手动的/open-code-review评论都会启动任务。在 Runner 上安装ocr——典型命令为npm install -g alibaba-group/open-code-review。CI Runner 是临时的所以每次运行都会重新安装。通过 CI Secrets 配置 LLM——用ocr config set写入 endpoint、token、model。CI 环境中没有可回退的持久化~/.opencodereview配置。以范围模式range mode运行审查并输出机器可读结果使 stdout 成为一份干净的 JSON 信封ocr review \ --from origin/base-branch \ --to origin/head-branch \ --format json \ --audience agent--format json产出可解析的负载--audience agent抑制进度行。下文每个配方消费的都是这份 JSON 信封。解析 JSON 并遍历comments[]。通过平台的审查 API 把评论回帖到 PR / MR——没有有效行号信息的条目文件级发现会被折叠进一条摘要说明而不是以内联方式发布如果内联批量 API 拒绝了请求回帖步骤还会回退为一条普通摘要评论。始终有两类凭证参与其中OCR 用来生成发现的LLM 凭证以及回帖步骤用来评论的PR/MR 写权限 token。GitHub 配方通过GITHUB_TOKEN免费获得后者GitLab 推荐显式的GITLAB_API_TOKEN但内置的CI_JOB_TOKEN会作为 fork MR 的回退它可以通过/discussions发布讨论——为保证可靠性官方仍推荐使用专用 token。二、核心命令语义范围模式、JSON 信封与退出码CI 中所有配方的核心都是ocr review。根据 CLI Reference 的定义该命令会解析 Git diff、按语义对变更文件分组、为每个组派发一个子 Agent、收集审查评论并输出。范围模式Range ModeCI 审查永远使用范围模式而不是默认的工作区模式ocr review --from main --to feature-branchOCR 会计算merge-base(main, feature-branch)..feature-branch因此只审查特性分支引入的差异而不是分支之后落到main上的无关变更。三种模式互斥传--from/--to、--commit、或都不传工作区模式三选一混用是硬错误。这正是 CI 场景下「只评论本次提交引入的问题」的关键保证。JSON 信封结构ocr review --format json --audience agent--audience agent彻底抑制进度行stdout 只输出最终 JSON即便用默认的--audience human[ocr]进度行也会走 stderr因此ocr review --format json result.json的 stdout 始终是单一 JSON 文档。顶层字段字段说明statussuccess、completed_with_warnings、completed_with_errors或skipped。llm解析后的 LLM 身份。规范化后的model始终存在provider仅在显式配置了命名 provider 时出现。message可选。人类可读摘要如No comments generated. Looks good to me.。summary可选。运行聚合files_reviewed、comments、total_tokens、input_tokens、output_tokens、elapsed等。skipped运行省略该字段。comments始终存在可能为空。每条含path、content、start_line、end_line、existing_code、suggestion_code、thinking等字段。warnings可选。一个或多个子 Agent 失败时出现每条描述受影响的文件与错误。session_id可选。持久化审查运行上出现可传给ocr review --resume session-id。resume可选。在恢复的运行上出现含resumed_from、rerun_files等。当没有文件符合审查条件时JSON 模式输出skipped信封让调用方区分「没有变更」与「没有发现」两种情形。关键标志速查标志默认说明--from ref/--to ref—范围模式起止引用计算merge-base(from, to)..to。--format fmttexttext、json、sarifSARIF 2.1.0 报告供 GitHub Code Scanning 使用。--audience whohumanagent抑制进度输出只打印最终摘要/JSON。--background text—需求/业务上下文注入 plan 与主提示词--background-file path优先级更高。--concurrency n8并行审查的文件组数量上限。--timeout minutes15每组截止时间0禁用按 effort 轮数线性缩放low/medium/high 对应 15/30/45 分钟。--effort levelmedium审查强度预设low1 轮、medium2 轮、high3 轮。--rule path—自定义 JSON 规则文件覆盖项目级与全局rule.json。--max-tokens-budget n0不限总输入输出 token 上限超限后停止派发部分结果仍会发布。--max-git-procs n16并发 git 子进程数上限。退出码码含义0审查完成可能 0 条评论也可能带非致命警告。1致命错误——标志错误、无法解析 LLM endpoint、所有子 Agent 均失败等。非致命警告单个子 Agent 失败、文件超 token 阈值等在 JSON 模式下进入warnings数组。三、GitHub Actions 集成上游工作流位于 examples/github_actions/ocr-review.yml。工作流做了什么同时监听pull_request_targetopened、synchronize、reopened和issue_comment事件后者的评论正文以/open-code-review或open-code-review开头时触发——这让评审者可以随时在 PR 上评论来按需重跑 OCR。使用pull_request_target而非pull_request是为了让 fork 仓库发起的 PR 也能拿到 secretsOCR 只读取 diff不执行 PR 中的任何代码因此这是安全的。为防恶意触发issue_comment触发还通过author_association限定为 MEMBER / OWNER / COLLABORATOR且排除 Bot 用户。通过npm install -g alibaba-group/open-code-review安装用ocr config set写入配置然后以分支范围模式运行核心命令。解析 JSON 信封通过 GitHub Pull Request Review API 把每条发现以内联审查评论的形式回帖没有行号信息的评论折叠进摘要正文。若批量提交失败则回退为逐条发布并在摘要评论中呈现统计信息。工作流还通过concurrency组做了巧妙设计见 ocr-review.yml匹配事件共享每 PR 的ocr-pr_number组并cancel-in-progress: true新审查取消同一 PR 的旧审查不匹配的评论落入唯一的noop-run_id组立即跳过且不干扰进行中的审查——避免了「一条普通评论杀掉正在运行的审查」的经典问题。安装把工作流放进你的仓库mkdir -p .github/workflows curl -o .github/workflows/ocr-review.yml \ https://raw.githubusercontent.com/alibaba/open-code-review/main/examples/github_actions/ocr-review.yml必需的 secrets在Settings → Secrets and variables → Actions下设置Secret必需说明OCR_LLM_URL是LLM API endpoint例如https://api.openai.com/v1/chat/completions。OCR_LLM_AUTH_TOKEN是LLM API 认证 token。该 CI secret 会被传给ocr config set llm.auth_token。OCR 直接读取的环境变量是OCR_LLM_TOKEN不是OCR_LLM_AUTH_TOKEN。OCR_LLM_MODEL否模型名。没有默认值——必须显式设置。OCR_LLM_USE_ANTHROPIC否使用 Anthropic Claude 模型时设为true。GITHUB_TOKEN由 GitHub 自动提供工作流声明了pull-requests: write权限以便发布审查评论。注意OCR_LLM_MODEL与OCR_LLM_USE_ANTHROPIC通常以 Variablesvars.*而非 Secrets 存放。工作流启动时还会执行ocr config set llm.extra_body {thinking: {type: disabled}} 关闭 thinking-mode 请求以兼容不支持该字段的各类 LLM provider。若你的 provider 需要保留 thinking-mode请删除这一行。Action inputs完整参数表上游工作流通过uses: alibaba/open-code-reviewmain把审查委托给仓库根目录的可复用复合 Actionaction.yml。除上述凭证外这些 inputs 用于微调审查本身放在 action 步骤的with:下Input默认说明effort传给ocr review --effort的强度预设low、medium、high不区分大小写。空值保持 CLI 默认已配置的值或 medium。需要 OCR v1.10.0 或更新版本旧版本上 Action 会以清晰的错误提前失败。max_tokens_budget传给ocr review --max-tokens-budget的总 token 上限输入输出。空值或0表示不限。超限后派发停止被跳过的文件报告为failed(budget)部分结果仍发布审查以 0 退出。llm_reasoning_effort面向支持可调reasoning_effort请求字段的模型如 GLM-5.x、OpenAI reasoning 模型的推理深度minimal、low、medium、high、max不区分大小写。通过llm_extra_body合并进请求体因此兼容所有已发布的 CLI 版本llm_extra_body中显式的reasoning_effort键优先于此 input。空值默认不发送。仅适用于 OpenAI 兼容协议——Anthropic API 会拒绝未知请求体字段因此该协议下 Action 会快速失败Anthropic 的 thinking 请通过显式llm_extra_body键控制。stream_progressfalsetrue时把实时的[ocr]进度行流式输出到工作流日志人类受众走 stderr而不是静默到运行结束。仅影响展示stderr 仍会捕获到文件用于 artifacts 与评论回帖。需要 OCR v1.9.8 或更新版本。llm_auth_header—自定义认证头名称映射到OCR_LLM_AUTH_HEADER。llm_extra_headers—额外请求头KV,KV映射到OCR_LLM_EXTRA_HEADERS。llm_extra_body{thinking: {type: disabled}}LLM 请求的 extra_body JSON。没有对应环境变量通过ocr config set llm.extra_body写入。languageEnglish审查输出语言通过ocr config set language写入。llm_timeout300LLM 请求超时秒映射到OCR_LLM_TIMEOUT。review_task_timeout15每个文件/并发任务的超时整数分钟1–120校验严格action.yml 中会做前导零归一化与范围检查。github_token${{ github.token }}回帖评论用的 GitHub token。ocr_versionlatestnpm 版本说明符要求 v1.9.6 或更新安装后会解析实际版本并做版本门禁v1.9.6 底线、effort 需 v1.10.0、stream_progress 需 v1.9.8。review_concurrency—传给ocr review --concurrency。background—传给ocr review --background。rule—传给ocr review --rule的自定义规则 JSON 文件路径。sticky_summarytrue摘要维度。true时原地更新已有摘要评论粘性而不是每次运行发新评论。incrementalfalse增量维度。true时只追加与既有 bot 审查评论 (path, line range) 不重叠的内联评论历史评论永不删除非破坏性。incremental_overlap_threshold0.6增量模式判断多行评论是否重叠的 IoU 阈值两条单行评论同处一行即算匹配单行 vs 多行永不匹配。review_comment_batch_size50单次 createReview 调用中打包的内联评论数上限生产环境曾在一次请求中发布 71 条后失败50 处于 GitHub 软性建议内。route_severity_below可选严重度阈值把等于或低于它的发现从内联评论路由到 PR 摘要fail-open绝不丢弃发现。如low只路由低严重度medium路由 medium 与 low。route_categories逗号分隔的类别列表bug、security、performance、maintainability、test、style、documentation、other从内联评论路由到 PR 摘要。可与route_severity_below组合。checkpoint_rangefalse跨推送检查点。true时完整跑完的运行会把覆盖到的 head 记录在粘性摘要评论中下次运行只审查checkpoint..new head而非merge-base..new head。Fail-closed任何存疑情形摘要缺失、base 移动、配置变化、检查点不是新 head 的祖先等都回退为全量审查。要求sticky_summary。full_reviewfalse即使启用checkpoint_range也强制一次全量审查reasonmanual_full_review用于从 merge-base 重审而不关闭检查点。base_ref/head_sha—从非 PR 事件如issue_comment调用时覆盖 base ref 与 head SHA。node_version24actions/setup-node 的 Node.js 版本。upload_artifactstrue把原始 JSON 结果与 stderr 上传为工作流 artifacts必须是带引号的字符串true/false因为步骤按字符串比较判断。完整 input 列表含 posting 模式sticky_summary/incremental、severity/category 路由与跨推送检查点见 action.yml。自定义以下都是对你刚复制的ocr-review.yml的编辑。背景上下文--background是杠杆最高的单个标志——尤其当 PR 标题遵循feat(auth): add OAuth2 support这样的语义约定时效果最佳- name: Run OCR review env: PR_TITLE: ${{ github.event.pull_request.title }} BASE_REF: ${{ github.base_ref }} HEAD_REF: ${{ github.head_ref }} run: | ocr review \ --background $PR_TITLE \ --from origin/$BASE_REF \ --to origin/$HEAD_REF \ --format json --audience agent安全要点PR 控制的值要通过env:传入而不是把${{ }}直接插值进run:。GitHub 会在 shell 解析该行之前文本级替换${{ }}因此包含 shell 元字符的 PR 标题或分支名会在你的 Runner 上被执行。自定义规则用--rule传入项目专属规则文件- name: Run OCR review env: BASE_REF: ${{ github.base_ref }} HEAD_REF: ${{ github.head_ref }} run: | ocr review --rule ./my-rules.json \ --from origin/$BASE_REF \ --to origin/$HEAD_REF规则文件 schema 见 Review Rules。并发默认 8 个并行子 Agent每个文件组一个。大 PR 上降低并发以避免触达 LLM provider 的速率限制ocr review --concurrency 5 \ --from origin/$BASE_REF \ --to origin/$HEAD_REF触发模式默认工作流在 PRopened以及以/open-code-review或open-code-review开头的评论上触发。两种常见调整在更多 PR 生命周期事件上运行例如新提交推送时重新审查on: pull_request: types: [opened, synchronize, reopened, ready_for_review]使用不同的评论关键字if: | github.event_name pull_request || (github.event_name issue_comment github.event.issue.pull_request startsWith(github.event.comment.body, /review))github.event.issue.pull_request检查确保评论是在 PR 上而非普通 issue。固定 OCR 版本默认工作流安装最新发布版。固定版本- name: Install OpenCodeReview run: npm install -g alibaba-group/open-code-review1.0.0在可复用 Action 中则通过ocr_versioninput 传入版本说明符例如ocr_version: 1.8.8。以 GitHub App 身份回帖默认审查评论来自github-actions[bot]。要以品牌 bot如OpenCodeReview Bot身份回帖把GITHUB_TOKEN换成 GitHub App installation token在Settings → Developer settings → GitHub Apps → New GitHub App创建应用。禁用 webhook本用例不需要。在Repository permissions下授予Pull requestsRead and writeContentsRead-only用于获取 diffMetadataRead-only必需在应用设置页生成私钥并下载.pem文件记下同一页的App ID。把应用安装到你要审查的仓库。Installation ID出现在安装后 URL 中如https://github.com/settings/installations/12345→ ID 是12345。在Settings → Secrets and variables → Actions下添加三个 secretSecret值GITHUB_APP_IDApp ID。GITHUB_APP_PRIVATE_KEY.pem文件完整内容包括-----BEGIN RSA PRIVATE KEY-----和-----END RSA PRIVATE KEY-----行。GITHUB_APP_INSTALLATION_IDInstallation ID。铸造 token 并在回帖步骤使用- name: Get GitHub App Token id: app-token uses: actions/create-github-app-tokenv1 with: app-id: ${{ secrets.GITHUB_APP_ID }} private-key: ${{ secrets.GITHUB_APP_PRIVATE_KEY }} - name: Post review comments to PR uses: actions/github-scriptv7 with: github-token: ${{ steps.app-token.outputs.token }} script: | # ...existing post script...上传发现到 GitHub Code ScanningSARIF--format sarif会把 SARIF 2.1.0 报告写到 stdout。把它管道到文件并用 CodeQL 的upload-sarifaction 上传让发现出现在Security → Code scanning下- name: Run OCR review env: BASE_REF: ${{ github.base_ref }} HEAD_REF: ${{ github.head_ref }} run: | ocr review \ --from origin/$BASE_REF \ --to origin/$HEAD_REF \ --format sarif --audience agent results.sarif - uses: github/codeql-action/upload-sarifv3 with: sarif_file: results.sarifSARIF 是机器可读格式OCR 会在 stdout 上抑制进度行results.sarif只包含报告。注意--preview不支持--format sarif——要生成报告请跑完整审查或ocr scan。SARIF 报告在仓库中由 cmd/opencodereview/sarif.go 生成并有对应测试覆盖。排障症状原因 / 修复Cannot find merge-basecheckout 步骤用了浅克隆但范围模式审查需要完整历史。上游工作流在actions/checkout上设置了fetch-depth: 0——编辑文件时请保留该设置。Failed to parse OCR outputOCR_LLM_URL或OCR_LLM_AUTH_TOKEN缺失或错误。重新检查Settings → Secrets and variables → Actions下的值。审查评论落在错误的行上通常意味着从审查开始到评论发布之间 diff 发生了偏移。此时回帖脚本会回退为普通 issue comment——无需处理。注意OCR_DEBUG环境变量目前尚未实现——设置OCR_DEBUG: 1无效。要获得详细输出可检查工作流写入的原始审查 JSON 与 stderr/tmp/ocr-result.json与/tmp/ocr-stderr.log见排障节或本地运行ocr review。四、GitLab CI 集成上游流水线位于 examples/gitlab_ci/.gitlab-ci.yml配套的回帖脚本为 examples/gitlab_ci/post_review.py。流水线做了什么在merge_requests事件上触发所有 MR 事件——创建、更新、重开。在node:20镜像中运行安装 OCR、通过ocr config set配置然后以 MR diff 模式运行核心命令。用内联的 Python 脚本解析 JSON 信封把每条发现作为 GitLab Discussion内联在 diff 上回帖使用 MR 的versionsendpoint 计算正确的base_sha/start_sha/head_sha以保证精确定位。无法内联发布的评论回退为普通 MR note最后以一条摘要 note 收尾。使用resource_group: mr-review-$CI_MERGE_REQUEST_IID保证同一 MR 的流水线串行interruptible: true允许新流水线取消旧的。安装把流水线放进仓库根目录curl -o .gitlab-ci.yml \ https://raw.githubusercontent.com/alibaba/open-code-review/main/examples/gitlab_ci/.gitlab-ci.yml如果你已有.gitlab-ci.yml并想保留它可以把配方放到其他路径并用include:引入include: - local: ci/ocr-review.gitlab-ci.yml必需的 CI/CD 变量在Settings → CI/CD → Variables下设置变量必需掩码说明OCR_LLM_URL是否LLM API endpoint URL。OCR_LLM_AUTH_TOKEN是是API 认证 token。该 CI 变量会被传给ocr config set llm.auth_token。OCR 直接读取的环境变量是OCR_LLM_TOKEN不是OCR_LLM_AUTH_TOKEN。OCR_LLM_MODEL否否模型名。没有默认值——必须显式设置。GITLAB_API_TOKEN否是带apiscope 的项目 / 个人 / 组访问 token。可选——缺失时如 fork MR用内置的CI_JOB_TOKEN作为回退。为可靠性推荐使用专用GITLAB_API_TOKEN。可选的 LLM provider 变量还有OCR_LANGUAGE、OCR_LLM_AUTH_HEADER、OCR_LLM_EXTRA_HEADERS、OCR_LLM_TIMEOUT后者被 OCR 从环境变量原生读取无需ocr config set审查行为变量有OCR_REVIEW_CONCURRENCY、OCR_BACKGROUND、OCR_RULE发布行为变量与 GitHub Action 对齐含OCR_STICKY_SUMMARY、OCR_INCREMENTAL、OCR_INCREMENTAL_OVERLAP_THRESHOLD、OCR_ROUTE_SEVERITY_BELOW、OCR_ROUTE_CATEGORIES、OCR_FAIL_ON_SEVERITY在注释中完整列出见 .gitlab-ci.yml。GitLab 拒绝长度小于 8 个字符的变量因此llm.use_anthropic在流水线中被硬编码为false。要使用 Anthropic Claude 模型请直接编辑脚本。流水线启动时也会执行ocr config set llm.extra_body {thinking: {type: disabled}} 以兼容不支持该字段的 LLM provider。若你的 provider 需要保留 thinking-mode请删除该行。快速 bot 命名技巧对于 Project Access Token 与 Group Access Tokentoken 的名称会显示在 MR discussions 旁边。把 token 命名为OpenCodeReview Bot是给审查者品牌化的最快方式无需任何额外配置——当你不需要下文「以服务账号身份回帖」中更持久的设置时非常方便。自定义以下都是对你刚复制的.gitlab-ci.yml的编辑。背景上下文把 MR 标题传给--background——标题遵循feat(auth): add OAuth2 support语义约定时尤其有效script: - | ocr review \ --background $CI_MERGE_REQUEST_TITLE \ --from origin/$CI_MERGE_REQUEST_TARGET_BRANCH_NAME \ --to ${CI_COMMIT_SHA} \ --format json --audience agent注意这里--to使用CI_COMMIT_SHA而非源分支名以保证 same-repo 与 fork MR 都能正确解析源提交。自定义规则与并发与 GitHub Actions 配方相同的标志——--rule传项目规则文件--concurrency限制并行子 Agent默认 8script: - | ocr review --rule ./my-rules.json --concurrency 5 \ --from origin/$CI_MERGE_REQUEST_TARGET_BRANCH_NAME \ --to ${CI_COMMIT_SHA}规则 schema 见 Review Rules。固定 OCR 版本script: - npm install -g alibaba-group/open-code-review1.0.0也可以利用流水线注释中定义的OCR_VERSION变量如1.8.8或~1.8使审查可复现。避免每次推送都重新审查only: [merge_requests]会在每次MR 更新时触发长生命周期 MR 会烧掉大量 LLM token。GitLab 没有原生的「仅在创建时」事件因此推荐模式是在运行审查前检测已存在的 OCR notes发现则直接退出。把ocr review调用替换为 Python 包装import json, os, sys, urllib.request GITLAB_URL os.environ.get(CI_SERVER_URL, https://gitlab.com) PROJECT_ID os.environ[CI_PROJECT_ID] MR_IID os.environ[CI_MERGE_REQUEST_IID] API_TOKEN os.environ[GITLAB_API_TOKEN] url ( f{GITLAB_URL}/api/v4/projects/{PROJECT_ID} f/merge_requests/{MR_IID}/notes?per_page100 ) req urllib.request.Request(url, headers{PRIVATE-TOKEN: API_TOKEN}) with urllib.request.urlopen(req) as resp: notes json.loads(resp.read().decode()) if any(OpenCodeReview in n.get(body, ) for n in notes): print(OCR already reviewed this MR. Skipping to save tokens.) sys.exit(0) # ...otherwise call ocr review ... as usual and write the JSON to # the file the posting step expects.之后要强制重新审查删除 MR 上之前的 OCR notes——下一次流水线运行看不到 OCR notes 就会继续。自托管 GitLab无需改代码。回帖脚本读取CI_SERVER_URLGitLab 在每个 runner 上自动设置因此开箱即用地对接你自己的实例。只需确保GITLAB_API_TOKEN由你的自托管实例签发而不是gitlab.com。以服务账号身份回帖默认情况下审查 discussions 显示为GITLAB_API_TOKEN的拥有者。换成项目级服务账号以获得品牌化 bot 身份如OpenCodeReview Bot在Project → Settings → Service Accounts → New service account创建服务账号。你选择的名字如OpenCodeReview Bot就是显示在 MR discussions 旁边的名字。在Settings → Members → Invite member邀请它加入项目。搜索服务账号名并分配Developer或Maintainer——两者都具备发布 discussions 的权限。在Settings → Service Accounts → (账号) → Add new token签发访问 token。必需 scopeapi。立即复制 token——GitLab 只展示一次。在Settings → CI/CD → Variables中替换 token 值——用服务账号的 token 覆盖现有GITLAB_API_TOKEN保持变量名不变。排障症状原因 / 修复Cannot find merge-baseRunner 使用了浅克隆。上游流水线设置GIT_DEPTH: 0强制完整克隆——编辑文件时请保留。回帖时API error 403GITLAB_API_TOKEN缺少apiscope、不是项目成员或在自托管环境中由其他实例签发。用apiscope 重新签发并在Settings → CI/CD → Variables重新添加。Failed to parse OCR outputOCR_LLM_URL或OCR_LLM_AUTH_TOKEN错误。重新检查Settings → CI/CD → Variables下的值。内联评论落在错误的行上GitLab 的内联 discussion 要求精确的 SHA 匹配回帖脚本获取versions元数据以得到正确的base_sha/start_sha/head_sha。若某条发现仍无法锚定则回退为普通 MR note。流水线会把原始审查 JSON 写入.ocr/ocr-result.json、stderr 写入.ocr/ocr-stderr.logpost_review.py 会在解析失败时把 stderr 贴到 MR 摘要上。可在调试步骤中 cat 查看 OCR 返回了什么script: - cat /tmp/ocr-result.json - cat /tmp/ocr-stderr.log另外GitLab 流水线会通过 dotenv artifact.ocr/ocr-stats.env向下游任务暴露OCR_COMMENTS_{TOTAL,INLINE,SUMMARY,ROUTED,SKIPPED,FAILED}与OCR_SUMMARY_URL便于在后续任务中做质量门禁或统计。五、源码级原理评论回帖与幂等机制GitHub 与 GitLab 两个平台的回帖逻辑并非临时脚本而是有严格测试支撑的工程实现——GitHub 侧为 scripts/github-actions/post-review-comments.js2657 行由action.yml的actions/github-script步骤注入github/context/core依赖运行GitLab 侧为 examples/gitlab_ci/post_review.py1548 行仅依赖标准库json/urllib可在任何 stock python3 镜像上运行。两者行为刻意对齐几个核心机制值得了解粘性摘要sticky summary摘要正文内嵌!-- ocr-summary --标记后续运行按标记找到旧摘要并原地更新而不是每次发新评论避免 MR 上摘要堆积。增量模式incrementaltrue时只追加与既有 bot 评论 (path, line range) 不重叠的内联评论重叠判断用 IoU多行评论默认阈值 0.6历史评论永不删除保证非破坏性。批量回帖单次createReview最多打包 50 条内联评论review_comment_batch_size超过则分顺序批次提交——源码注释记录了一次请求发 71 条导致 GitHub Server Error 的生产事故这正是默认 50 的由来。severity/category 路由类别枚举bug、security、performance、maintainability、test、style、documentation、other与严重度排序criticalhighmediumlow在两侧脚本中保持一致策略解析失败时安全回退到「不路由」fail-open绝不丢发现。行号失效回退没有有效行号信息的发现文件级结论永远以「No line information provided」标注折叠进摘要内联批量 API 拒绝时回退为逐条发布或普通 MR note。GitLab 侧还会用versionsendpoint 计算精确 SHA并在 400 行解析失败时分类到 diff 清单决定 drop-vs-keep。跨推送检查点checkpoint_range配置指纹LLM URL、模型、协议、语言、extra_body、effort、预算、规则文件内容哈希、OCR 版本等 18 个维度做 SHA-256 摘要存入粘性摘要下次运行据此决定只审checkpoint..new head还是回退全量——任何配置变化都会使检查点失效保证绝不带着旧规则审新提交详见 action.yml 的Resolve review range步骤。这套「解析 JSON → 分类 → 幂等回帖」的职责被刻意放在平台脚本层而非ocr二进制内部见 post_review.py 的模块 docstring因此同样的机制也能平移到 Gerrit、Gitee、Bitbucket 等其他平台仓库examples/目录还提供了 gerrit_ci、codeup_ci、gitflic_ci、bitbucket_pipelines 等参考实现。六、延伸阅读CLI Reference——两份流水线消费的 JSON 输出格式定义适合从零编写自己的 CI 脚本。Configuration——OCR 认可的每一个环境变量与配置键。Review Rules——自定义规则文件 schema。ocr-review.yml 工作流示例 与 .gitlab-ci.yml 流水线示例——可直接复制的完整配方。action.yml——可复用复合 Action 的完整 input/output 契约。【免费下载链接】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），仅供参考