返回 ResolveAI 项目总览 · 交互图：AI · CAPABILITY · ADMISSION
配置好 API Key，向模型发出请求，得到 HTTP 200 和一段结构正确的 JSON——很多 AI 项目会在这里显示绿色状态：Provider 可用，模型已接入，功能可以上线。
但这三个结论其实不相等。
HTTP 200 只能证明某一次网络请求完成；JSON 能被解析，只能证明输出满足了形状要求；真正的业务能力还要回答另外几个问题：调用的是不是当前模型？使用的是不是当前 Prompt？输出有没有经过生产解析器？它能否在已知危险样本上正确弃权？最新一次同身份校准是通过还是失败？
ResolveAI 因此没有设置一个全局的“AI 已连接”开关，而是建立了一份能力目录。当前实现登记了运行时事实提取、运行时候选决策、失败模式复核、模式漂移、修复候选、独立质询、Case 诊断、诊断修复建议、评测草案和评测有效性分析等能力。每项能力分别声明输入输出合同、决策权限、Provider 策略、校准套件、风险等级和模型外控制。
这篇文章讨论的不是怎样发起一次模型请求，而是怎样判断一次模型请求是否有资格进入某条业务链路。
机制图：接口连通只是起点。能力必须绑定 model、host、prompt、suite 四维身份，并读取最新同身份校准结果；缺少证据时，运行时能力进入受控状态，离线治理能力默认阻断。
最小反例：昨天通过，今天还能用吗
假设 pattern-review 昨天在模型 A、Host A、Prompt v1、Suite v2 上校准通过。今天只把 Prompt 改成 v2，再次请求仍然返回 200。
如果系统只保存“这个模型曾经通过”，它会把昨天的证据借给今天的新执行条件。但 Prompt 已经改变，输出分布、引用方式和弃权边界都可能改变。昨天的通过不能证明今天的组合仍然可信。
再考虑一个更隐蔽的情况：同一个执行身份连续保存了两条记录，旧记录通过，新记录失败。如果代码只是寻找任意一条历史通过，就会在最新失败之后继续放行。界面仍是绿色，证据却已经反转。
这两个反例共同说明：校准不是模型名称的装饰字段，而是一条带身份和时间顺序的准入证据。
四维执行身份
ResolveAI 把模型能力的校准身份固定为四个维度：
model：实际请求的模型名称；host：Provider 端点或渠道身份；prompt：该能力使用的版本化 Prompt；suite：用来验证能力边界的固定校准集版本。
只有四项全部一致，历史记录才属于当前执行身份。换模型、切 Host、修改 Prompt 或升级 Suite，都意味着原证据不能直接继承。
这里的重点并不是“哈希越多越安全”，而是让每次放行都能回答：我们究竟验证过哪个执行条件。否则，团队看到的“能力通过”只是一个脱离上下文的标签。
NIST 的 AI Risk Management Framework 把测试、评估、验证和确认放在 AI 全生命周期中，而不是只在上线前做一次检查；其 Playbook 也强调，指标必须结合具体使用情境解释，不能停留在孤立模型分数上。NIST AI RMF 与 AI RMF Playbook提供的是方法论背景。ResolveAI 的四维身份不是对该框架的完整实现，而是我在这个实践项目中落下的一条可执行约束：校准结论必须和实际运行条件对齐。
不是所有能力都用同一种阻断方式
如果所有能力缺少校准就一律停机，运行时可用性会被离线证据链完全绑死；如果所有能力都允许降级运行，离线分析又可能在没有证明的情况下产生看似权威的结论。
因此能力合同还区分了三类执行性质：
runtime_critical：在线事实提取和候选决策。即使当前校准不足，也必须继续经过 Schema、确定性事实回退、Policy、Workflow 和 Guard，以guarded状态受控运行；governed_offline：模式复核、漂移检查、Case 诊断等治理任务。缺少当前身份通过证据时默认blocked，因为它们没有在线可用性的压力；proposal_only：修复候选和评测草案。即使获准调用，输出仍然只是草案，不能保存配置或批准发布。
这意味着“准入”并不是把模型升级成权威决策者。它只说明该能力可以在既定权限内参与流程。每项合同都明确保存 mayMutateConfiguration: false 和 mayRelease: false，最终配置写入和发布仍由模型外系统与人工流程拥有。
为什么运行时能力要求连续通过
运行时事实提取与候选决策还有一个额外要求：当前代码需要同一执行身份连续三轮通过固定校准，才把状态从 guarded 提升为 authorized。
这里的三轮不是统计意义上的稳定性证明，也不能推出线上正确率。它只是一个有限、透明的操作门槛，用来避免把一次偶然成功直接升级为“已经稳定”。如果最近一轮通过但连续证据只有 1/3，能力仍保持受控运行；如果最新一轮失败，连续通过计数立即归零。
真正的生产判断还需要代表性数据、样本规模、置信区间、长期漂移和真实业务结果。NIST 对 TEVV 的讨论同样强调，评估方法应根据具体目标和应用场景定制，而不是依赖一个适用于所有系统的万能分数。NIST TEVV 研究说明可以帮助理解为什么“连续三次通过”只能被表述为本项目的准入政策，不能被写成普遍可靠性结论。
最新失败为什么必须撤销旧成功
能力目录会按完成时间对校准记录排序，然后只读取当前四维身份下的最新证据。测试专门构造了“较早通过、较新失败”的情况，断言执行准入必须引用最新失败记录，并返回 calibration_failed，而不是继续寻找一个可以让页面变绿的历史成功。
这条规则保护的是证据单调性：新证据可以使旧结论失效，旧证据不能反过来覆盖新事实。
它同样适用于身份漂移。若当前找不到完全匹配的校准，但存在其他身份的历史通过，治理能力会显示为 stale，要求重新校准，而不是借用旧身份继续执行。
页面为什么需要同时展示状态、原因和动作
真实产品页面：Release Center 将运行证据、变更影响和发布边界集中展示。截图证明当前页面形态；具体能力准入算法由源码与聚焦测试证明。
一个状态标签本身并不能帮助运营人员行动。ResolveAI 的能力投影因此同时生成：
- 当前状态：
authorized、guarded、blocked或stale； - 当前身份：模型、Host、渠道、Prompt 与 Suite；
- 被引用的校准记录；
- 为什么处于这个状态；
- 下一步应该运行校准、检查 Provider，还是查看人工审核链。
这也是我对“可解释”的理解：不是让模型再生成一段解释，而是让模型外系统展示它依据了哪一条不可变证据、应用了哪一条确定性规则。
我刻意没有把什么写成已完成
第一，当前项目没有证明真实生产流量下的模型可靠性。固定校准和聚焦测试证明的是合同、排序、身份绑定和阻断语义，不是商业指标。
第二，连续三轮通过不是统计稳定性结论。它只是本地操作政策，没有代表性抽样和长期观测支持。
第三，当前能力目录属于应用层控制。企业环境仍可能需要外部模型网关、集中审计、凭证轮换、租户级限流、IdP 与 RBAC。
第四，Release Center 截图来自隔离数据环境。它证明页面能表达治理边界，不证明某个企业已经采用这套流程。
读者可能关心的边界问题
为什么不用一个全局健康检查？
因为连通性是 Provider 级事实，能力是否可信取决于具体 Prompt、输出合同和校准集。全局健康检查可以保留，但不能替代能力级准入。
为什么运行时失败后不直接停机？
因为在线事实提取和候选决策仍有模型外 Schema、确定性回退、Policy 与 Guard。系统将其降为 guarded，而不是假装 authorized；离线治理能力没有同样的可用性压力，因此缺证据时默认阻断。
连续三次有什么科学依据？
没有足够证据把它称为科学阈值。它是一个显式、可调整的工程政策，用于阻止单次偶然成功直接放行。生产阈值应由真实流量、风险等级和统计评测确定。
怎样证明最新失败真的会撤权？
可以展示能力合同源码以及聚焦测试中的最小反例：同身份旧通过、新失败，最终准入必须绑定新失败并返回 calibration_failed。当前工作树中该测试文件 11 项测试全部通过。
结语
AI 能力治理最危险的误区之一，是把“能调用”写成“能使用”，再把“能使用”写成“能决定”。
ResolveAI 的做法是逐层收紧结论：HTTP 200 证明连通，Schema 证明形状，固定 Suite 检查行为，四维身份限定证据适用范围，最新记录决定当前状态，模型外合同限制最终权限。
能力准入绑定执行身份与最新证据。出现失效或校准失败时，系统收回对应资格；再次启用需要重新检查，而不是沿用过去的通过状态。