让 AI 用量可问责的四类记录

一个企业 AI 平台往往从用户表、应用表和一个额度余额开始。这足以完成演示，但在真实团队开始使用后，无法回答采购、安全或财务的追问。

TenSaaS 把四类记录分开保存：团队、应用、合同额度和 用量账本。它们在每次运行中协同，但不能互相代替。

团队：可问责的运营主体

团队确定谁拥有当前租户上下文。成员身份、租户内角色和生命周期状态都归属于团队。

URL 中的 teamId 只是导航上下文。服务端仍然需要解析当前会话，并确认有效成员身份。这一区分阻止调用方通过更换一个标识符访问其他租户。

团队记录回答：

• 哪个组织单元对这次活动负责？
• 哪些人目前属于该团队？
• 该租户是否有效并允许运行？

应用：受管的能力

AI 应用不只是一个模型名称。它是归属于团队的资产，拥有自己的状态、配置、权限边界和凭据处理方式。

应用记录回答：

• 哪个团队安装了这个体验？
• 它当前是否有效？
• 哪些成员可以使用或管理？
• 哪一条服务端策略选择模型服务商和模型？

管理和使用是两种不同操作。团队所有者和管理员可以拥有 app.manage，有效成员可以拥有 ai.use。浏览器能打开应用体验，但不会收到应用 API 密钥。

合同额度：支出授权的来源

没有来源的余额很难对账。TenSaaS 把可用额度绑定到团队合同发放记录。该来源可以携带有效期、权益和剩余数量。

合同额度回答：

• 哪份商业协议为这次运行出资？
• 资金来源当前是否有效？
• 它是否授权团队使用这个应用或模型策略？
• 该来源还剩多少可用额度？

当一个团队获得多次发放时，保留来源尤其重要。退回、过期和调账可以回到或引用正确原始来源，而不是修改一个匿名总数。

用量账本：运行回执

账本记录实际发生了什么。一条可靠记录会连接团队、成员、应用、执行、额度来源和数量。它需要支持幂等消耗与退回，因为模型服务商回调和网络重试不会承诺每个消息只送达一次。

用量账本回答：

• 谁发起了运行？
• 使用了哪个应用和模型策略？
• 访问模型服务前预留了多少？
• 模型服务商返回的实际用量是什么？
• 最终结算或释放了多少？

运行链路

这四类记录在严格的执行顺序中会合：

1. 解析已鉴权用户和有效团队成员身份。
2. 解析有效团队应用和必需权限。
3. 解析有效合同和权益。
4. 根据平台模型价格计算估算成本。
5. 在一个事务中从符合条件的额度来源预留。
6. 由服务端调用模型服务商。
7. 按实际用量结算并释放未使用预留。
8. 向浏览器返回安全结果和回执。

这一顺序避免两个危险空档。支出授权完成预留前，模型服务访问不会开始；浏览器也无法指定服务端将要记录的成本。

为什么一张大表更糟

把所有信息都存在一条应用或团队记录上看起来很简单，但生命周期变化会很快变得模糊。团队可能仍然有效，但某个应用已停用。合同可能过期，但审计历史不能删除。一次退回可能在执行完成后才发生。

分开的记录让每个生命周期独立变化，不会擦除其他事实。测试也因此更清晰：租户隔离、权限执行、应用状态、额度有效性和账本幂等性可以各自失败，并各自默认拒绝。

这就是多租户 AI 底座的实际价值。它不只是增加一个团队选择器，而是为每次 AI 运行提供可问责的运营主体、已批准能力、支出来源和持久回执。