opendrs

opendrs：PR 影响范围分析器与安全自动批准风险评分

为每个拉取请求提供经过校准的 0-1 风险评分，让经过 AI 审查且影响范围较小的 PR 自动获批并进入合并队列，而高风险 PR 仍由人工审核。

如今，AI Agent 编写和审查代码的速度已经快过人类阅读代码的速度，因此人工审查成了瓶颈。大多数拉取请求风险较低，少数 PR 却造成了大多数事故。opendrs 会评估每个 PR 的影响范围和风险：变更涉及哪些内容、有多少文件依赖这些内容、所改文件的历史、作者经验、缺失的测试以及关键路径。它利用你自己的 git 历史记录中的信号，将这些因素转化为 0-1 评分。然后由团队设定策略。例如，得分低于 0.3 且通过 AI 审查（Claude、CodeRabbit、Copilot 或任何检查运行）的 PR 会获批并进入合并队列，或自动合并。风险较高的 PR 仍由人工审核。这种方法参考了 Meta 的 Diff Risk Score（DRS）；opendrs 是一个独立的开源实现，可在任何 git 仓库中运行，无需托管服务。

目录： 安装 · 快速开始 · 工作原理 · 功能 · 结果 · CLI 和 MCP · 文档 · 限制 · 与其他工具的比较 · 相关先例

安装

使用方式	命令	详情
GitHub Action	uses: error-path/opendrs@v0 (Marketplace)	添加评论、标签，并可选择批准和合并。GitHub Action 参考
CLI	npx @error-path/opendrs score	CLI、MCP 服务、Claude Code 插件和 Agent 技能
MCP 服务（任意 Agent）	npx -y @error-path/opendrs mcp	工具：score_diff、explain_file_risk、list_hotspots、suggest_reviewers
Claude Code 插件（技能加 MCP 服务）	/plugin marketplace add error-path/opendrs，然后运行 /plugin install opendrs@opendrs
Agent 技能（Claude Code、Cursor、Codex 等）	npx skills add error-path/opendrs	skills/opendrs/SKILL.md
Docker（通过 stdio 提供 MCP 服务）	docker build -t opendrs . && docker run -i --rm -v "$PWD:/repo" opendrs	将要评分的仓库挂载到 /repo

网站和指南：error-path.github.io/opendrs。

快速开始

为当前分支相对于默认分支的变更评分。无需配置或 API 密钥：

npx @error-path/opendrs score

你将获得评分、等级（绿色、黄色或红色）、影响评分的信号及其依据，以及策略判定。--json 会输出完整结果，--fail-above 0.6 会使命令在评分高于阈值时以 1 退出。

要为每个拉取请求评分，请添加 .github/workflows/opendrs.yml（或运行 npx @error-path/opendrs init）：

name: opendrs
on:
  pull_request:
    types: [opened, synchronize, reopened, ready_for_review, labeled, unlabeled]
permissions:
  contents: read
  pull-requests: write
  checks: read
jobs:
  opendrs:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
        with:
          fetch-depth: 0   # required: the score reads past commits and authors
      - uses: error-path/opendrs@v0

此配置只会添加评论和标签。默认分支上的 .opendrs.yml 中启用批准功能后，才会开始自动批准；请参阅如何自动批准低风险 PR和 GitHub Action 参考。

工作原理

flowchart LR
  diff["git diff<br/>merge-base...head"] --> signals
  hist["git history"] --> signals
  graph["import graph"] --> signals
  llm["LLM judge<br/>(optional)"] --> signals
  signals["Signals<br/>each with evidence<br/>and provenance"] --> model["Logistic model<br/>score = sigmoid(b + Σ w·x)"]
  model --> tier["Tier<br/>green / yellow / red"]
  tier --> policy["Policy<br/>blocks, size cap, unknowns,<br/>AI review, sampling"]
  policy --> decision["auto-approve<br/>deferred-review<br/>waiting-ai-review<br/>human-review"]

1. 信号。 每个信号提供方都会读取差异、历史记录和导入图，并生成特征：大小、变更的分散程度、受影响文件过去的修复和回退记录、作者对这些文件的熟悉程度、复杂度、影响范围（传递依赖方）、关键路径以及缺失的测试。每个信号都会记录其获取方式（observed、derived、inferred 或 unknown）及其依据。所有信号
2. 模型。 逻辑回归会将这些特征转化为概率。每个信号的贡献值 w·x 都会报告出来，让你了解 PR 得分的原因。开箱即用时，权重是人工设定的先验值；opendrs calibrate 会根据你的代码库拟合权重。 校准与回测
3. 等级。 得分会映射为绿色、黄色或红色，与 Meta 的门槛保持一致。阈值可以是绝对分数，也可以是你自身历史记录中的百分位数。
4. 策略。 有序规则会根据得分作出决策。策略与安全护栏

opendrs 在 PR 工作流中的位置

如今，一个 PR 往往会在人工查看前经过两轮 AI 审查。这两轮审查能发现局部缺陷：拼写错误、缺少空值检查、明显的差一错误。等到人工打开 PR 时，这些工作已经完成，剩下的则是设计和架构方面的判断，而此时掌握的上下文比以往更少。opendrs 正是为这一刻打造的：它会告诉最终审查者该 PR 需要多少关注，并指出最多五项架构和历史事实——例如模块之间新增的导入、遭到破坏的公共契约、通常会与某个文件一起变更但本次 PR 未涉及的文件——这些事实既不会显示在编辑器中，也不会出现在 AI 审查评论里。请参阅负责人简报。

功能

功能	作用	默认状态	文档
风险信号	大小、差异、文件历史、作者经验、复杂度、影响范围、关键路径、测试、语言	开启	信号
校准和回测	根据你的历史记录拟合权重，并衡量在拦截 5 / 10 / 50 % 时的捕获率	按需运行	校准
硬性拦截和安全护栏	拦截路径、二进制文件、子模块、自我修改防护、抽样、过期审批检查	开启	策略
自动审批	AI 审查通过后，批准绿色 PR，然后自动合并或加入合并队列	关闭	自动审批指南
LLM 评审器	将每个代码块归类为安全或风险类别；只能提高评分	关闭	LLM 评审器
requireSafe 门槛	仅当评审器以足够的置信度判定每个代码块均安全时，才自动审批	关闭	LLM 评审器
按来源配置策略	人类、机器人或 AI Agent 提交的 PR 各自采用更严格的绿色门槛、每日上限和跟踪记录	关闭	策略
延后审查	略高于绿色门槛的 PR 立即合并，之后再进行合并后审查	关闭	策略
合并延迟	符合条件的 PR 在审批前等待一段时间，以便人类否决	关闭	策略
冻结时段	在周末或高峰日期暂停或收紧自动审批	关闭	策略
内容拦截列表	新增行匹配正则表达式时，将 PR 转交给人类处理	关闭	配置
审查者分配	邀请排名前三的专家之一审查高风险 PR	在 Action 中开启	策略
热点	按静态风险对文件排序	按需运行	CLI 和 MCP
审查摘要	对优先阅读的代码块排序、提供固定检查问题、安全略读列表和硬性规则原因——适用于 claude-code-action、Bugbot、CodeRabbit（有限支持）、Copilot 和 Codex（粘贴使用）的配方	开启	LLM 评审器、CLI 和 MCP
事件反馈	opendrs feedback 记录事件以供校准	按需运行	校准

所有设置均位于 .opendrs.yml 中，并从基分支读取，因此 PR 无法放宽自身的门槛： 配置参考。

结果

基准测试	结果	详情
ApacheJIT（15 个 Apache Java 项目，官方 2017–2019 测试年份；因 apache/hadoop 没有正标签而将其排除）	校准后的 opendrs：AUC 为 0.823；在风险最高的 30 % 中捕获了 67 % 的缺陷提交，与基于经典 JIT 指标的回归模型相当（0.821、66 %）	ApacheJIT 测试结果
使用 LLM 评审器的 ApacheJIT（Claude Sonnet 5，抽样测试 800 个提交）	置信度为 8 时，评审器判定为全部安全的提交中有 5.3 % 存在缺陷，基准比例为 25.5 %	使用结构化 LLM 评审器
27 个公开代码库（先校准，再回测）	在首次运行的 9 个代码库中，校准模型在留出的提交上均优于默认先验	基准测试结果

CLI 和 MCP

命令	作用
opendrs score	对 merge-base(base, head)..head 评分
opendrs explain <file>	查看文件的历史记录、修复、作者、依赖方和路径策略
opendrs hotspots	按静态风险对文件排序
opendrs calibrate / opendrs backtest	根据你的历史记录拟合模型；比较默认模型和校准后的模型
opendrs feedback	在 .opendrs/incidents.jsonl 中记录事件
opendrs init	写入带注释的 .opendrs.yml 和仅含注释的工作流
opendrs mcp	运行 MCP 服务

标志、退出代码、MCP 工具和 Agent 技能：CLI、MCP 服务、Claude Code 插件和 Agent 技能。

文档

页面	适合在以下情况下阅读
自动批准低风险 PR	逐步设置基于风险的审批关卡
GitHub Action 参考	查阅输入、输出、权限、分支规则和定期扫描
策略与安全护栏	准确了解 PR 获批或未获批的原因
配置参考	修改 .opendrs.yml
风险信号	查看 opendrs 衡量哪些内容以及如何衡量
PR 的影响范围有多大？	了解影响范围
LLM 评审器	启用可选的 LLM 评审器或 requireSafe 关卡
将评审摘要提供给 LLM 评审者	将 opendrs 的发现呈现给 Claude Code、claude-code-action、Bugbot、CodeRabbit、Copilot 或 Codex
负责人摘要	了解最终人工评审者会看到什么：优先级、评审者，以及架构和历史事实
校准与回测	让模型适配你的仓库并选择阈值
基准测试结果	查看 opendrs 如何对公开仓库的风险进行排序
实验	查看我们尝试过什么，以及哪些方法行不通
CLI、MCP 服务、Claude Code 插件和 Agent 技能	在本地或通过 Agent 运行 opendrs
已知限制	了解 opendrs 无法看到什么
与其他工具比较	在 opendrs 和其他 PR 风险工具之间做出选择
更新日志	查看每个版本的变更

限制

• 默认权重并未针对你的代码进行拟合。 请先运行 backtest 再信任这些权重；积累了足够的历史数据后，再运行 calibrate。
• 标签只是事故的替代指标，而小型仓库的数据不稳定。
• 评分不等于代码评审。 它估算的是发生事故的可能性，而不是变更是否正确。

完整列表请参阅：已知限制。

与其他工具比较

如果你想要	使用
一个基于你自己的历史数据衡量风险、可批准或合并低风险 PR，且无需托管服务的风险关卡	opendrs
让 LLM 评判每个 PR 并作为关卡	PR-Agent 的自动批准、Merge Steward 或 MergeShield Risk Check；opendrs 的可选 LLM 评审器只能提高评分
在团队计划的 Cursor 云端内审批	Cursor 审批 Agent
对代码发表评论	AI 评审者（Claude Code、CodeRabbit、PR-Agent），并在其运行后运行 opendrs

完整对比（包括各工具的评分方式和运行位置）请参阅 error-path.github.io/opendrs/alternatives.html。

先前研究与致谢

• Meta 的 Diff Risk Score。 Diff Risk Score：由 AI 驱动、具备风险意识的软件开发 （Engineering at Meta，2025）以及 Abreu 等人，加快发布速度并降低风险：在发布部署中使用大模型（2024）。特征集、分级门槛以及按 X% 门槛捕获指标均源自这项研究。opendrs 与 Meta 无关联。
• Meta 的 RADAR。 Adams 等人，在 Meta 自动化低风险代码审查 （2026）：这篇论文提出了结构化的大模型审查器（包含安全和风险类别）、按来源制定的策略（每日上限、历史记录）、延迟审查、合并延迟以及内容屏蔽列表。 hotspots 和审查者分配相关的 Meta 研究成果：Mockus 等人，“Metrics Driven Reengineering and Continuous Code Improvement at Meta”（ASE 2025）；Paraspatki 等人，“Code Reviewer Recommendation for High Risk Diffs at Scale”（FSE Companion 2026）；Rigby 等人，改进代码审查者推荐（TOSEM 2025）。
• 基准与同行研究。 Keshavarz 和 Nagappan，ApacheJIT （MSR 2022），数据集 bench/apachejit/ 的评分所依据的研究；Sayedsalehi、Rigby 和 Mockus，DRS-OSS（2025），基准引用了这项开源大模型研究的结果。
• 即时缺陷预测与 SZZ。 Mockus 和 Weiss，“Predicting risk of software changes”（2000）；Śliwerski、Zimmermann 和 Zeller，“When do changes induce fixes?”（2005）；Kamei 等人，“A large-scale empirical study of just-in-time quality assurance”（2013）。变更级特征和 SZZ 风格的标注均遵循这些研究成果。
• REA（morluto/rea）。opendrs 采用 REA 的证据优先方法：每个结论都会标记为已观察、已推导、已推断或未知，且绝不会将未知视为安全。它也遵循 REA 的分层设计，将领域类型、提供方、共享引擎和轻量适配器分开。

许可证

MIT