为什么 TenSaaS 把团队定义为 AI 租户

企业采用 AI 后，真正困难的不是再增加一个聊天框，而是回答四个运营问题：

一个 AI 应用归谁所有，谁能使用，花谁的额度，又在哪里留下回执？

TenSaaS 的答案是 团队。团队不是页面上的一个文件夹，也不是查询时的便利筛选条件。 它是租户边界，承载成员、应用、权益、AI 额度和审计历史。

为什么个人账户不够

个人账户适合管理资料、偏好和个人账单。企业 AI 工作是共享的。一个部门安装应用，多个成员使用， 一份合同提供预算，管理员需要说明最终成本。

如果这些记录都挂在个人账户下，会很快出现三个问题：

• 人员转组后，访问权可能继续保留。
• 共享应用没有可问责的主体。
• 模型用量无法对应到真正出资的合同。

TenSaaS 把个人设置放在 /settings，团队运营放在 /workspace/:teamId，平台级操作放在 /admin。URL 可以帮助用户理解当前上下文，但授权从不只信任 URL。

两个管理面

平台管理员管理整个服务，负责模型价格、平台策略、租户合同和额度发放。他们的决定可能影响 多个租户。

团队所有者和团队管理员只管理自己的团队，包括维护成员、安装或停用应用、在租户边界内委派 访问权。他们不会因为是团队管理员，就获得平台级权限。

普通成员使用已批准的应用。他们的使用权来自有效团队成员身份和 ai.use 等明确能力。

这种分离避免了一个常见错误：把团队管理员当成缩小版平台管理员。实际上，两类角色处理不同 资源，对应不同风险边界。

每次应用运行都要找到责任主体

服务端只有在确认以下对象后，才会接受一次应用运行：

1. 已登录用户。
2. 该用户在所选团队中的有效成员身份。
3. 归属于该团队的有效应用。
4. 当前操作需要的权限与权益。
5. 一笔有足够余额的有效合同额度。

这些校验会在执行时再做一次。浏览器已经打开某个页面，不代表当前请求仍然被允许。

浏览器也不会获得应用 API 密钥。模型服务商凭据和成本策略保留在服务端，成员无法修改模型价格， 也无法自行提交额度成本。

额度是账本，不是一个数字

单一余额可以告诉团队还剩多少，但无法说明资金来自哪里，又被什么消耗。

TenSaaS 把团队额度处理为一组可归属记录。运行时先根据当前模型价格计算估算成本，从有效合同 额度中预留，调用模型服务商，再按实际用量结算，并释放未使用的预留部分。调账和退回也保留 原始来源。

这对付费试点很重要。团队管理员可以把一次运行连接到团队、成员、应用、合同来源和用量结果， 而不是面对一笔无法解释的余额变化。

默认拒绝是产品行为

多租户信任在失败情况下最清楚。当成员身份、应用状态、合同、权益或余额无效时，TenSaaS 会 停止运行。它不会默默改用个人积分、其他团队额度或未定价模型。

这种产品体验比消费级 AI 工具更严格，但它是企业权限和成本可解释的基础。

因此，TenSaaS 最初有价值的部署并不是一个庞大的应用市场，而是一个团队、一个受管应用、 一组具名成员，以及一条完整的授权、额度和审计闭环。这条闭环建立信任后，平台才能在不丢失 归属的前提下扩展。