第 3 章：为上游建立能力、信任和版本清单

3.1 把候选资格与排序分开

先判断资格，再在合格候选里排序。资格约束包括租户授权、数据可发送的区域、协议能力、输入大小和当前可接纳状态。排序才考虑延迟、成本、偏好和权重。

如果把这些条件混成一个分数，低价格可能抵消“不允许传输到该区域”这种硬约束。一个不合格上游即使便宜十倍，也应该从候选集合中排除。

可以用如下伪代码表达次序：

candidates = inventory(snapshot_version)
eligible = candidates satisfying every required constraint
if eligible is empty: reject with a reason category
selected = rank(eligible, policy_version)
record selected identity and both versions

这段伪代码说明决策结构，并不冒充某个产品的配置文件。真实清单需要结合自己的密钥系统和能力验证机制实现。

3.2 能力清单也是证据清单

对于每项能力，至少记录验证对象、验证时间、协议版本和测试依据。供应商文档说某个模型支持图片，并不能证明你的账号、部署端点和适配器已经走通图片处理。一次成功调用也不能证明所有图片大小都可用。

清单可以采用“已验证支持、明确不支持、待验证”三种状态。验证失效之后，不必立刻删除上游，但应限制需要该保证的流量。这样能把“产品声称”与“本系统验证”分别保留。

3.3 信任范围决定哪些信号可以使用

随书替身会提供一项特殊保证：某种拒绝响应明确表示尚未开始处理。只有实验控制的替身才拥有这个合同。网关不能把互联网上任意 503 响应解释成同样的信号，更不能仅凭对方返回一个同名头字段，就允许它控制重试和账本。

真实接入需要定义信任根：固定端点、经过认证的连接、经过审核的适配器，以及该服务关于请求接受和幂等的正式合同。如果中间还有代理，头字段是否可被伪造或重写，也必须纳入判断。

3.4 配置变更需要一个稳定视图

请求开始时取到清单版本 v7，执行到一半切换成 v8，如果两个版本对同一个上游的能力解释不同，审计记录会很难还原。一个实用做法是让单次请求持有不可变配置快照，新的请求使用新版本。

快照不意味着忽略紧急吊销。密钥泄露或区域禁用可能需要立即阻止未发起的尝试。系统应把普通配置升级与紧急阻断分开：前者保持请求内一致性，后者优先终止风险，并明确记录终止原因。

练习。 两个上游都支持 text，其中一个支持结构化输出但尚未验证工具调用。请求同时要求这两项能力时，候选资格应怎样判定？请写出拒绝原因，而不是只返回“无可用模型”。