AI SaaS 架构模式

一旦你见过几个 AI SaaS 产品，就会发现它们共享一套可识别的架构——而失败模式也同样有规律：token 成本吞噬利润、一个租户的数据出现在另一个租户的回答中、供应商宕机导致整个产品瘫痪。本指南按层梳理了那些经得起考验的模式。

参考架构

text
客户端（Web/API）
   │
API 层 ──── 认证、速率限制、用量计量（按租户！）
   │
编排服务 ── 提示词、路由、工具、护栏
   │                       │
AI 网关 ── 供应商          ├── 检索层（按租户存储）
（故障转移、成本路由）      ├── 任务队列（异步/批量 AI 工作）
                           └── 评估 + 可观测性脊柱

三个结构性决策决定了其余部分：

1. 网关缝。 所有模型流量流经一个层，该层负责供应商路由、故障转移、缓存和*按租户的成本归属*。没有这个缝，多供应商、价格谈判以及“哪个客户在烧我们的利润？”都将成为重写。

2. 同步与异步分离。 交互式功能使用流式传输（SSE 模式）；所有可以等待的任务都通过队列（理想情况下使用批量 API，价格减半）。经典的初创公司错误是通过交互路径运行批量工作——成本翻倍，且与用户延迟竞争。工作进程遵循 webhook 处理器规范：幂等、背压、安全关闭。

3. 配置/注册表缝。 提示词、模型选择和参数从版本化注册表解析，而非代码——提示词迭代与部署解耦，回滚只需切换指针，每个响应都记录其配置版本。

多租户：无法事后补救的部分

AI SaaS 中的租户隔离有三个层面，每个层面背后都有一个失败故事：

检索隔离：每个向量查询至少要有 tenant_id 过滤（pgvector 行级模式）；企业级租户使用独立的集合/模式；*显式测试跨租户泄漏*——这是 AI SaaS 中的认证绕过等价问题。

上下文隔离：每次请求根据租户配置组装提示词；绝不在租户间缓存组装好的提示词；租户数据绝不进入共享的少样本示例。

成本隔离：在网关层按租户计量 token——用于计费、滥用上限，以及发现某个租户的工作负载占了你推理账单的 40%（总是如此）。

企业级附加功能：租户固定的数据驻留、零保留供应商路由、DPA，以及自带密钥（他们的 API 密钥，你的软件）——如果网关缝存在，架构上成本很低。

利润层（AI SaaS 经济性的关键）

Token 成本是传统 SaaS 没有的销货成本；按影响排序的保护毛利的模式：

分层路由：70% 的调用（分类/提取/简单聊天）使用小型模型；仅在评估证明差异重要时使用前沿模型。

缓存：对重复问题缓存响应；缓存友好的提示词结构（稳定前缀在前）以获得供应商端提示词缓存折扣。

合适的上下文：检索 top-k 规范和摘要历史——上下文膨胀是无声的利润杀手。

可批处理的工作负载进行批处理（嵌入、增强、报告）。

按使用量定价对齐：如果你的成本按 token 缩放，但按席位定价，一个重度用户就会颠覆你的利润——相应地计量和分层产品。

信任层

边界护栏：对所有输出进行模式验证、注入感知的输入处理、对关键操作设置审批门。

评估脊柱：每个功能的评估集把关提示词/模型变更（工作流）；任何用户可见的内容都要进行金丝雀发布。

可观测性：每个租户每个功能的追踪 + 成本 + 质量指标（工具选项）——“昨天哪些租户看到了降级的回答？”必须是一个查询，而不是一次调查。

新 AI SaaS 的搭建顺序

第 1 周：骨架 + 网关缝 + 一个端到端流式功能。第 2-3 周：注册表、评估集、成本计量（在客户之前，而非之后）。然后是功能。缝在早期只花几天，后期则要重写——这就是整个模式目录的一句话总结。

---

*最后更新：2026 年 6 月。*