AI 凭证治理粒度解析：从账号共享困局到虚拟 Key 架构

问题：凭证治理粒度太粗

"拼车被封"已经成了 AI 工具用户社区里的高频话题：几个人凑钱共用一个订阅账号，额度还没用完，账号先没了；更麻烦的是，你不知道是哪一次登录、哪一个 IP、哪台设备触发的风控，只能全员一起承担后果。

大多数讨论把问题归因于"风控太严"。这个判断只对了一半。风控是表层的执行者，真正的问题在更底层：AI 凭证的治理粒度太粗。

一个订阅账号，本质上是一份身份，额度只是这份身份附带的使用权。多人共用一个账号时，共享的不只是额度，还有上下文（对话记忆互相可见）、行为画像（多设备多 IP 同时活跃本身就是异常信号）、责任边界（出问题无法定位到人）。用一份身份承载多个主体的使用需求，在架构上天然不成立。

反过来，一人一号也不经济。AI 使用是典型的波动负载：重度用户两天烧完限额，轻度用户月底还剩大半。静态分配必然造成重度用户频繁撞墙、轻度用户额度浪费。

解法：把凭证从身份中解耦

问题的核心是凭证的治理粒度。业界普遍存在两种凭证形态：

• 账号级凭证（订阅账号、原始 API Key）：全有或全无，不可拆分、不可设限、不可精确回收。
• 策略级凭证（虚拟 Key / Scoped Token）：从身份中解耦出来的使用权凭证，背后绑定的不是"一个自然人"，而是一组策略——能用哪些模型、单日多少额度、在哪个环境生效、有效期多久。

把粒度从账号级细化到策略级后，共享问题就换了一种解法：不再是"多人共用一个身份"，而是"多个受控凭证共享一个资源池"。身份隔离保住了，额度共享也实现了——这两件事在账号级凭证里互斥，在策略级凭证里可以并存。

工程架构：控制面与执行面

虚拟 Key 架构在工程上由两部分组成：

控制面负责"定义"：签发与撤销凭证、配置额度与策略、沉淀审计日志。它是所有凭证的权威来源，真实密钥集中托管，不流向任何终端。

执行面负责"执行"：在 AI 请求真正发出前，完成身份校验、策略评估、路由与审计。它可以以本地代理、Sidecar 或网关的形态存在，业务代码基本不需要改动。

一次调用的完整处理流程：

# 执行面处理流程（伪代码）
def handle_request(virtual_key, model, payload):
    # 1. 身份校验：解析虚拟 Key，定位绑定策略
    policy = control_plane.resolve(virtual_key)

    # 2. 策略评估：模型白名单 + 配额检查
    if model not in policy.allowed_models:
        raise PermissionError("model not allowed")
    if not policy.quota.try_acquire():
        raise QuotaExceededError("quota exceeded")

    # 3. 路由转发：从凭证池选取真实凭证调用上游
    credential = pool.acquire(policy.provider)
    response = upstream.call(credential, model, payload)

    # 4. 审计留痕
    audit.log(virtual_key, model, response.usage)
    return response

粒度细化带来的治理能力：

• 按需分配：按项目、按成员、按环境签发不同策略的虚拟 Key
• 分钟级撤销：有人离职、有项目下线，直接吊销对应凭证，其他人不受影响
• 责任可追溯：每次调用都携带凭证身份，谁用了哪个模型、花了多少 Token 全部留痕
• 预算与风控前置：配额、白名单、异常调用拦截在调用发生前执行

与云上治理能力的配合

这套架构与云基础设施已有的治理能力互补，而非替代：

一个需要澄清的常见误读：虚拟 Key 架构不等于"中转站"。中转站是第三方截留——请求经过别人的服务器，数据过了一道手；而虚拟 Key 架构的执行面部署在自己环境里，流量直连模型官方接口，中间没有第三方经手。数据主权与合规边界始终在自己手里。

演进建议

如果团队正被多模型凭证管理困扰，建议分三步走：

1. 收敛：把散落在个人环境变量里的 Key 收拢到统一接入点，凭证池化
2. 细化：按项目/成员签发虚拟 Key，配额与模型白名单生效
3. 闭环：接入审计与成本归因，撤销流程常态化

凭证治理的粒度，决定了团队在 AI 投入上能看得多清楚。与其在"共享被封、买多浪费"的两难里反复横跳，不如把凭证治理的粒度一次性做对。