多模型接入治理的工程实践：凭证、路由与审计

近期头部模型厂商的动作，呈现出同一个方向：模型能力开始按风险等级、使用场景与调用者身份分层提供。Claude Fable 5.1 全面开放，其同底层模型的 Mythos 版本仅向特定安全领域的审核机构开放；另一家头部厂商则确认下一代模型达到其安全框架最高风险等级，最强能力仅向小范围受信项目开放，普通用户获得的是默认收紧的版本。

对工程团队而言，值得关注的不是跑分差异，而是供给方式变化带来的接入复杂度：模型正从"单一能力出口"变为"一组受控出口"。本文不讨论具体模型优劣，仅从工程实践角度，梳理多模型接入治理的几类基础问题与设计思路。

多出口带来的三类基础问题

凭证分散。 多个模型供应商对应多把 Key，散落在个人环境、代码与流水线中。缺乏统一的生命周期管理，人员变动后权限无法及时回收，密钥暴露面随出口数量线性扩大。

路由耦合。 业务代码直接依赖具体厂商地址与模型名。一旦供应商调整价格、限流或下线模型，就需要修改代码与配置重新发布，切换成本全部落在业务侧。

审计缺失。 多出口场景下，调用方、出口、模型、费用分散在各自厂商的控制台，缺少统一的调用留痕，既无法回答安全事件中的"谁在什么时候调用了什么能力"，也无法回答成本侧的"哪个团队烧了多少钱"。

落地思路：意图声明 + 统一执行点

通用的解法是在应用与模型之间增加一层治理面，核心设计可以概括为两个原则。

原则一：代码声明意图，不绑定具体供应商。

业务侧只描述需要什么能力，由治理层完成模型匹配。配置中不存放任何真实密钥，仅包含逻辑模型与密钥别名：

{
  "logicalModel": "code-review",
  "provider": "anthropic",
  "keyAlias": "review-default",
  "quota": "day-50"
}

真实密钥保存在独立的加密存储中，在调用时通过执行点注入。这样做的好处是：换 Key、加模型、调整供应商，都不需要改动业务代码，配置描述的是"需求"而非"某个厂商的某把钥匙"。

原则二：统一执行点承载校验、路由与控制动作。

所有调用收敛到统一执行点，在每次请求中完成四件事：

1. 身份与虚拟凭证校验；
2. 按逻辑模型解析实际供应商与模型档位，结合预算策略路由；
3. 内容安全检测，采用分级动作而非单纯放行/阻断；
4. 记录审计日志与成本事件。

执行点需要具备一个可靠性细节：策略缓存兜底。控制面更新策略依赖网络下发，执行面应保留最近一份已知良好的策略缓存，在网络抖动时沿用，避免"拿不到新策略就放行或全拒"的极端行为。

# 调用侧示意：只声明能力，路由与鉴权由治理层完成
resp = gateway.complete(
    logical_model="code-review",
    message="review this diff"
)

几个值得注意的设计要点

虚拟凭证的生命周期管理。 凭证应支持签发、续期、轮换、撤销全流程，撤销要做到分钟级生效，通过执行点缓存失效机制拒绝后续调用，而不是依赖人工删除。

审计口径分离。 实时估算口径用于日常监控与告警，账单口径用于月底与供应商核对，两者并存，避免"监控显示正常、账单突然超标"时无法定位偏差。

安全分级动作。 内容检测建议分基础规则与上下文判断两层：基础层识别敏感信息与密钥格式；上下文层识别越狱、提示词提取等对抗行为；动作上区分告警、改写、阻断与改路由，兼顾安全与误伤率。

接入形态按环境选择。 本地开发用轻量代理；容器化环境用同 Pod 的 Sidecar；生产环境收敛为统一网关入口，集中执行策略与审计。

小结

模型供给走向分层与多出口，是安全与商业双重考量下的长期趋势。对企业而言，与其每次追逐新模型，不如先把接入治理建好：凭证统一、路由解耦、调用留痕。这一层独立于具体模型，模型换代只是新增一次配置；出了安全事件，也能第一时间定位并收敛风险面。治理层的价值，会在出口越来越多的过程中持续放大。