release-gate

release-gate

面向 AI 系统的独立准入控制器。

Release-Gate 将代码级 Agent 风险、外部评估、运行时跟踪、治理证据、验证结果和人工审批整合为可审计的 PROMOTE / HOLD / BLOCK 决策，无需团队替换生成这些证据的工具。

PROMOTE 表示候选版本符合声明的发布策略，并包含决策所列的证据和差距。它绝不代表发布是安全的。

 code-level agent risk     SARIF from your scanner, or release-gate's own ──┐
 external evaluations      promptfoo, ProofAgent, red teams, eval harnesses ─┤
 runtime traces            OpenTelemetry, Langfuse, Arize-Phoenix ───────────┤   one candidate state,
 verification results      tests, provers, model checkers ───────────────────┼─▶ one claim graph,      ─▶ PROMOTE / HOLD / BLOCK
 governance evidence       governance.yaml, the pinned AIBOM ────────────────┤   one declared policy      + the Admission Report
 human approvals           reviews and approvals of this exact candidate ───┘

它所处的位置

以下工具各自回答不同的问题。Release-gate 将其他工具的结果作为注明来源的证据读取，并回答最后一个问题。

工具	它回答的问题
Linter	代码写得好吗？
SAST	代码是否包含已知的漏洞模式？
Guardrail	是否应允许这次实时交互？
Evaluator	Agent 在这些测试中的表现如何？
Observability	系统运行时发生了什么？
Release-Gate	证据是否能证明这个确切的候选版本符合其发布策略？

它不会重新运行、重新评分或替换其中任何工具。promptfoo 的结果仍归 promptfoo 所有，扫描器的发现仍归扫描器所有；Admission Report 会说明哪些证据由 release-gate 自行生成，哪些来自其他工具。它自己的 Agent 代码扫描器只是其中一个证据生成方，并非产品本身。

决策说明

	含义
PROMOTE	候选版本凭借所列证据符合声明的发布策略，且策略接受所列的差距
HOLD	有事项必须由人员先行解决，并明确指出该事项以及可用于解决它的证据
BLOCK	违反策略：检查失败、存在有效反例，或出现策略要求拦截的矛盾

未知绝不等于通过。每项决策都会说明未评估的内容，而且关于发布其他状态的证据不适用于当前状态。决策由声明的策略和证据确定，具有确定性。可以让模型读取证据，但模型的解读不会决定结果。

工作原理

flowchart LR
  subgraph own["Release-gate's own checks"]
    direction TB
    o1["AST / taint scan"] ~~~ o2["PR diff"] ~~~ o3["governance"] ~~~ o4["trace validation"] ~~~ o5["loop sim, agent score"]
  end
  subgraph ext["Your tools"]
    direction TB
    e1["evals, red teams"] ~~~ e2["traces, SAST"] ~~~ e3["proofs, reviewers"]
  end
  sem["Semantic verifier<br/>bounded questions<br/>UNKNOWN on any failure"]
  case["AssuranceCase<br/>claims, evidence, assumptions,<br/>contradictions, counterexamples,<br/>failed branches, coverage, independence"]
  own --> case
  ext --> case
  sem -. "a reading, never a verdict" .-> case
  case --> policy{"declared<br/>policy"} --> out["PROMOTE / HOLD / BLOCK"]

不变原则。 Release-Gate 可以生成证据、接收证据、规范化证据、比较证据、对有界证据进行语义解读，并判定证据是否符合策略。它绝不能假装一个模型、一个扫描器、一个评估器、一个分数或一次成功测试就能确立普遍真理。

每项声明最终都有一个状态，而声明的策略会规定哪些状态可以准入：

flowchart LR
  ev["the evidence<br/>on one claim"] --> claim{"a claim"}
  claim -- "a valid counterexample<br/>(outranks any support)" --> c["CONTRADICTED"]
  claim -- "a bound proof, or two<br/>independent groups of checks" --> e["ESTABLISHED"]
  claim -- "support short of that" --> s["SUPPORTED or<br/>PARTIALLY_SUPPORTED"]
  claim -- "only support about<br/>another state" --> u["UNSUPPORTED"]
  claim -- "inconclusive or unreadable" --> k["UNKNOWN"]
  claim -- "nothing bears on it" --> n["NOT_ASSESSED"]

分数不会作为输入，同一会话中同一测试的副本只计一次。 ARCHITECTURE 将每个方框映射到对应代码。tests/test_product_invariant.py 会执行不变原则的每个条款。

试用

pip install release-gate
release-gate assure your-run.jsonl        # no config file, no YAML, no account

它适用于 OpenTelemetry 跟踪、Langfuse 导出、promptfoo 结果，或 release-gate 自身的记录格式：系统会检测数据结构，无需声明。你会得到一个判定、需要人工查看的内容，以及可以解决问题的方式。

在流水线中，发布声明和流水线生成的所有内容会共同决定结果：

release-gate assure release.jsonl --evidence evidence/ \
  --methodology [email protected] --admission

退出码 0 表示 PROMOTE，10 表示 HOLD，1 表示 BLOCK。CI templates 涵盖 GitHub Actions、GitLab、Jenkins、CircleCI 和 Azure Pipelines。

release-gate 自身的检查也是证据。系统会像读取任何工具的输出一样读取 pr、verify、loop-sim 和 agent-score 的 --json 输出。下面是一个凭自身表现获准发布的示例，以及一条调用了治理文件禁止的工具的跟踪：

# examples/evidence/first-party/verify.json was written by
#   release-gate verify governance.yaml --trace trace.json --iteration 2 --cost 0.06 --json
release-gate assure examples/agents/02-release-promoted.jsonl \
  --evidence examples/evidence/first-party/verify.json \
  --methodology [email protected] --admission

  Decision     BLOCK
               BLOCK under [email protected] and rg-resolution@1: 2 blocking condition(s) established — RG-CONTRA-002 (contradictions, on rg-trace:run-2291); RG-VERIF-002 (claim_status, on rg-trace:run-2291)

阻止发布的原因是跟踪检查失败，而不是验证器自身的 ROLLBACK。系统会记录这个判定，但不会据此决定任何事项。

无需预先安装：将一次运行拖入浏览器演示——它运行的就是同一引擎，三个示例运行所用的文件与 examples/assurance/ 中的文件逐字节相同。

也可以运行示例。在六种工具、一次发布、一个决策中，五种工具都报告了好消息，但决策仍然保持原样，原因也会一并打印出来。五次 Agent 运行涵盖 OpenTelemetry 跟踪、promptfoo 评估、破坏性迁移、研究型 swarm，以及一次获准发布的运行：

python examples/demo-admission/run_demo.py
cd examples/agents && ./run-all.sh

每个示例的演示内容 →

产品的验收测试也是一个示例。一次企业级发布，全流程演示展示了如何在各种证据中，准入工具会转移资金的 AI 生成代码。它回答发布负责人提出的每个问题，并展示任何评分、模型判断或测试数量都不能推翻其中包含的反例：

python examples/acceptance/run_acceptance.py

---

扫描器或评分无法做到的三件事

1. 将机器处理结果整理为人能看懂的清单

两百万条记录无法审核。对两百万条记录做出的评分也无法审核——它只是一个数字，代替了从未做出的判断。

release-gate 会返回需要人工处理的有限条目集，这些条目取决于决策实际依赖的声明：

	不同的生产者	查看记录数	证据	声明	需要人工处理
一个 Agent，一项操作	4	7	6	0	1 项
10,248 个工作进程	10,254	2,287,133	10,258	2,420	13 项，其中 7 项不可丢弃

表中的每个数字都由测试套件测得，并非手动填写——与实现不符的声明会导致测试失败。

关键程度取决于声明图中的可达性，而非数量：一个 Agent 只输出过一次的声明，其重要程度与 400 个 Agent 讨论过的声明完全相同。

清单更短，不代表案例更好。 这是代码中的一项属性，系统不可能返回其他结果；因为解读此表时最危险的误区，就是认为数字越小越好。这也可能意味着检测能力变差了。

2. 每个判定都会说明自己没有检查的内容

这是大多数工具会跳过的部分。未说明自身覆盖范围的通过结果，和根本没有检查过的通过结果无法区分。

WHAT WAS ASSESSED
  [    assessed]  input_integrity: the input file was hashed by release-gate
  [    assessed]  record_mapping: 6 of 6 record(s) mapped; 0 skipped
  [NOT_ASSESSED]  execution_reconstruction: no execution graph was reconstructed
  [NOT_ASSESSED]  replication: no verification attempt names a target
  [NOT_ASSESSED]  adversarial_review: no verifier set out to disprove this

NOT_ASSESSED 是一项一等答案，在整个引擎中都与“我们检查了，但什么也没发现”明确区分。UNKNOWN 也是如此，检查结果为反驳也与尚未解决的检查区分开来。将这些情况混为一谈，就会让缺口看起来像是万事无虞。

3. 保持待处理状态时，会返回工作单

只会说不的关卡只是个唠叨者。每个条目都会说明如何解决：

[BLOCK]    RG-ACT-001    'execution_reconstruction' is stated as NOT_ASSESSED
             → supply the run's trace or tool-call log

[ADVISORY] RG-PROV-002   all evidence traces to a single producer
             → add evidence from an independently-operated producer

这个清单可供机器读取（--json），因此下一次 Agent 运行可以直接去获取证据，无需人工重新阅读案例来查明缺少了什么。

---

它不会告诉你什么

它不会告诉你某个版本安全，不会告诉你某个结果保证正确，也不会 告诉你这个关卡无法攻破——针对引擎本身运行了 20 次攻击，其中一次被记录为 NOT_DEFENDED，并说明了是什么对它进行了限制。它不会告诉你某个案例毫无争议、 幻觉问题已解决，或某位专家已被取代：输出列出的是需要人工介入的事项。

每项拒绝都由代码中的属性保证，无法返回其他内容。 docs/POSITIONING.md 列出了每一项，并注明了 强制执行它的代码行。

---

使用 Python

import release_gate as rg

case = rg.create_case(objective="Deploy generated migration", subject=migration)
case.add_execution(trace)                       # the steps, or a native trace
case.add_verification(test_result, method="TEST_SUITE", outcome="PASSED",
                      verifier="ci://pytest", against_subject=True)

decision = case.finalize()     # PROMOTE / HOLD / BLOCK, with its coverage attached
print(decision.required_evidence)

同样的四次调用，既能承载一个 Agent 的迁移，也能承载一万名工作者参与的研究 运行。这不是两个共用名称的产品，而是同一条代码路径：346 个引擎函数 为两者所共用，占单 Agent 路径涉及的全部函数的 87%。

---

配置

运行无需任何配置。方法论负责将结构转化为 判定——没有方法论时，release-gate 会报告它能看到的所有结构性问题，并暂缓放行， 因为“这是否足够？”是一个领域问题，擅自给出答案就等于声称遵循了一个它并不具备的标准。

release-gate assure --list-methodologies
release-gate assure run.jsonl --methodology [email protected]

一个输入，四把标尺，四种答案——每种都指出了缺少什么：

方法论	判定	未满足项
(无)	HOLD	METHODOLOGY_REQUIRED
[email protected]	BLOCK	无执行记录
[email protected]	HOLD	仅有结构性发现
[email protected]	BLOCK	机器校验、假设、独立性

组织配置（--config）会在此基础上叠加你自己的标准，且只能收紧要求。方法论、 解决策略（--resolution-policy：确立一项主张需要什么，反例会产生什么影响） 和组织配置共同构成了声明的发布策略，PROMOTE 将依据该策略进行评估。每项内容都会 记录到案例中。

📖 完整演练：输入、输出和配置项 →

---

决策依据

上述准入决策就是最终产物。以下内容生成或承载其证据，每项都有单独的文档说明：

外部证据	评估、红队测试、SAST、形式化验证、评审、行为评估和遏制演练，均通过一份有文档说明的契约提供。只读取并注明来源，绝不重新运行
追踪与评估数据摄取	原位读取 OpenTelemetry · Langfuse · Arize-Phoenix · promptfoo：无需定制文件，也无需新增插桩
Agent 代码扫描	Release-gate 自有的证据生成器，用于识别代码层面的 Agent 风险：通过 AST 和污点分析，检查模型输出是否到达 eval/pickle、检索文本是否进入提示词，以及 LLM 循环是否未设上限。使用自己的包含 93 个案例的语料库进行测量
release-gate pr	对拉取请求引入的内容给出一个判定：仅关注新增的 Agent 风险；显示继承的技术债，但绝不以此设为门禁
Release-gate 的其他检查	PR 差异分析（pr）、追踪验证（verify --trace）、循环模拟（loop-sim）和 Agent 评分（agent-score）。其 --json 输出作为证据，由 assure --evidence 像读取任何生成器的输出一样读取；这些工具自身的判定和评分只会被记录，不参与决策
语义验证	可选。由一个模型或一组相互独立的模型读取规则无法处理的证据。其解读会被记录，但绝不参与决策；意见不一致时交由人工处理
签名证据	生成器为其输出签名（release-gate sign、DSSE / in-toto）。assure --trusted-keys 会根据受信任的生成器名称，将每个签名与对应密钥进行核验；签名验证失败的证据不会被读取
部署时检查	release-gate deploy-check 会将正在运行的内容与准入决策认可的状态进行比较。凡是未证明匹配的内容都无法通过
事故与演练	生产故障会成为反例，后续每个版本都必须作出回应。记录在案的停机开关演练（containment/1）是“可以暂停”的依据
多样性严格模式	--resolution-policy diversity-strict@1：关键声明需要两组相互独立的检查提供支持；共用同一提供方的检查算作一组；此外，还需要由作者以外的人进行一项检查
证据包	evidence-pack 会生成 JSON、Markdown 和 HTML。封存案例（--case-output）采用内容寻址，且可验证。除非你为其签名，否则这些内容均未签名
GitHub Action · MCP 服务	在 Action 中使用 command: assure；使用 pip install 'release-gate[mcp]'
基准测试	分别测量扫描器、保障层和语义提供方。保障语料库不会公布一个笼统的精确率数字，因为对其中大多数案例来说，精确率并不是有意义的衡量指标

---

文档

演示与集成指南	输入、输出和配置
定位	每项声明，以及用于落实该声明的规则
架构	引擎的组成方式
参考	完整的命令与功能参考
变更日志	发布历史
贡献指南 · 安全

开发

git clone https://github.com/VamsiSudhakaran1/release-gate
cd release-gate && pip install -e '.[dev]'
pytest -q

许可证

MIT — 详见 LICENSE。