AI SaaS背后的隐藏架构：构建企业自动化平台的经验教训
AI SaaS背后的隐藏架构：构建企业自动化平台的经验教训
构建一个基于AI的SaaS（软件即服务）平台让我学到了一些最初低估的东西：
难点不在于调用LLM（大语言模型）。
难点在于让AI在真实的商业环境中运行。
起初，一切看起来都可控。
你会想：
- API密钥只是生成的秘密。
- SSO（单点登录）只是连接一个身份提供商。
- 计费只是接入Stripe。
- 监控只是添加仪表板。
- 部署只是Docker和Kubernetes。
- AI只是调用OpenAI、Mistral、Anthropic或其他提供商。
然后平台开始变得真实。
每一个“简单”的话题都变成了一个架构系统。
API密钥不仅仅是API密钥
一开始，API密钥看起来像这样：
生成密钥
存储哈希值
返回一次性的秘密
但在真实的SaaS环境中，API密钥很快变成：
作用域
过期时间
撤销
租户边界
审计日志
速率限制
特权访问
基于计划的访问
表面级别的权限
一个密钥不仅需要回答：
这个密钥有效吗？
它还需要回答：
谁拥有这个密钥？
它属于哪个租户？
它可以访问哪些资源？
它可以执行哪些操作？
哪个计划允许这个操作？
它什么时候过期？
可以撤销吗？
可以审计吗？
这时你才会意识到，API密钥是你授权模型的一部分，而不仅仅是认证模型。
SSO不仅仅是登录
SSO看起来简单，直到你开始处理租户。
连接Keycloak、Google、Microsoft或任何OIDC（OpenID Connect）提供商并不是最难的部分。
最难的是决定你信任什么。
你信任电子邮件域名吗？
你信任subject声明吗？
你信任群组吗？
你信任来自外部IdP（身份提供商）的角色吗？
租户管理员可以映射角色吗？
租户管理员会不会意外创建平台管理员？
当用户属于多个租户时会发生什么？
当令牌有效但为另一个受众签发时会发生什么？
真正的SSO架构变成了：
签发者验证
受众验证
nonce验证
PKCE（授权码交换的证明密钥）
角色映射
租户成员身份
身份权威
回退预防
会话隔离
外部IdP配置
在企业级SaaS中，登录只是入口点。
真正的问题是：
身份能否跨用户、租户、项目和执行上下文被信任？
AI使用不仅仅是调用模型
调用模型很容易。
但运营AI不一样。
一旦AI成为产品的一部分，你需要考虑：
令牌消耗
成本可见性
提供商使用情况
模型使用情况
速率限制
延迟
重试
超时
回退
工具调用
可追溯性
提示治理
数据边界
对于演示来说，模型响应就足够了。
对于商业平台，你需要回答：
哪个租户使用了模型？
哪个工作流触发了它？
哪个用户启动了执行？
使用了哪个提供商？
消耗了多少令牌？
花费了多少成本？
输出是否被审查？
结果可以追溯吗？
过程可以重复吗？
这时AI不再是功能，而成为一个运营系统。
计费不仅仅是Stripe
Stripe可以处理支付。
但Stripe不会为你定义产品模型。
一个严肃的SaaS需要将计费连接到：
计划
配额
能力
功能开关
租户限制
令牌限制
存储限制
执行限制
订阅状态
许可证密钥
部署模式
如果你的产品可以部署为：
托管SaaS
客户云
本地部署
BYOC（自带云）
那么计费就不仅仅是支付。
它变成了商业治理。
系统需要理解：
客户被允许使用什么？
产品部署在哪里？
订阅是否有效？
这是企业合同吗？
是否涉及Stripe？
是否有许可证密钥？
当配额超出时会发生什么？
这就是定价、架构和运行时执行交汇的地方。
Kubernetes并不自动意味着可扩展
使用Kubernetes并不会自动使平台可扩展。
一个真正的执行平台需要考虑工作负载。
有些作业是轻量级的。
有些作业运行AI调用。
有些作业处理文件。
有些作业生成文档。
有些作业摄取知识。
有些作业运行长期工作流。
这意味着你需要开始分离：
队列
工作器
通道
超时时间
资源限制
探针
自动伸缩
存储
网络策略
可观测性
在某个时刻，“部署”变成了执行架构。
你需要知道：
哪个队列饱和了？
哪个工作器失败了？
哪些作业被延迟了？
哪个执行通道过载了？
哪个进程消耗了内存？
哪个租户产生了最多的负载？
没有这种可见性，扩展基本上是猜测。
可观测性不是可选项
当自动化成为业务运营的一部分时，监控不是技术上的额外福利。
它是产品的一部分。
你需要以下指标：
队列深度
执行成功率
执行失败率
平均持续时间
P95 / P99 延迟
AI令牌使用量
提供商使用情况
存储使用情况
认证失败
Webhook失败
备份状态
SLA / SLO（服务等级协议/服务等级目标）
对于工程师，可观测性回答：
什么出了故障？
对于领导层，可观测性回答：
价值在哪里创造？
时间在哪里节省？
成本在哪里增加？
哪个流程在失败？
哪个团队在采用平台？
这是不同层次的可见性。
配置最终会成为产品界面
起初，环境变量就足够了。
然后客户要求不同的设置。
不同的提供商。
不同的限制。
不同的身份配置。
不同的存储。
不同的安全策略。
不同的集成。
不同的部署模型。
突然之间，每次更改都重新部署变得不可接受。
这时配置需要移入管理界面。
当然，并不是所有内容都可以从UI（用户界面）编辑。
但一个严肃的平台需要区分：
启动配置
运行时配置
租户配置
基于密钥的配置
平台管理的配置
客户管理的配置
你的产品越企业级，你的后台就越成为产品本身的一部分。
真正的SaaS + AI关联
最大的教训是，这些系统不能孤立地设计。
它们是相互连接的。
商业模式 ↔ 计划
计划 ↔ 能力
能力 ↔ 角色
角色 ↔ 访问控制
访问控制 ↔ 安全
安全 ↔ 信任
AI使用 ↔ 成本可见性
工作流 ↔ 可衡量的结果
基础设施 ↔ 可靠性
可观测性 ↔ 更好的决策
如果某一部分薄弱，整个平台就会变得更难运营。
没有治理的工作流引擎变得危险。
没有计量的AI变得昂贵。
没有租户隔离的SSO变得危险。
没有可观测性的Kubernetes变得盲目。
没有运行时执行的计费变得表面化。
没有后端强制的管理功能变成安全剧场。
真正的问题
对于CEO，问题不仅仅是：
我们能使用AI吗？
而是：
我们能恢复运营能力、衡量影响并安全地扩展它吗？
对于CTO，问题不仅仅是：
我们能构建这个吗？
而是：
我们能治理它、保护它、部署它、监控它并在真实环境中维护它吗？
对于AI负责人，问题不仅仅是：
我们应该使用哪个模型？
而是：
我们如何将AI从孤立的实验转变为受控的业务执行？
最后的思考
构建AI SaaS最难的部分不是提示词。
不是第一个演示。
不是第一个集成。
难点在于让身份、数据、权限、成本、基础设施、工作流、可观测性和用户体验一起协同工作。