AI 应用基础架构

这个主题从单个功能进入应用架构。真实 AI 产品需要把模型、上下文、工具、存储、日志、成本和权限组织成系统。

当 AI 功能从 Demo 进入产品,最大的问题通常不再是“能不能调通模型”,而是“能不能稳定、可控、可替换、可观测地运行”。这个阶段会把模型调用放回完整应用系统里,理解 AI Gateway、模型路由、会话数据模型和运行生命周期如何一起工作。

学习目标

完成这个主题后,你应该能够:

  • 描述一个真实 AI 应用从前端到模型 Provider 的完整链路。
  • 设计 AI Gateway,用统一接口管理多模型、多 Provider、重试、超时和 fallback。
  • 为 conversation、message、run、step、tool call 建立清晰的数据模型。
  • 根据任务、成本、延迟和质量做模型路由。
  • 记录 token、cost、latency、first token time、error rate 等核心指标。

关键概念

AI Gateway 是应用和模型 Provider 之间的工程边界。它不只是转发请求,还负责鉴权、模型抽象、密钥管理、限流、fallback、日志和成本统计。

Model Routing 是根据任务选择模型的策略。高风险任务可能选择更强模型,实时补全可能选择低延迟模型,批处理可能选择低成本模型。

Session 数据模型 决定你能不能追踪一次 AI 交互。用户看到的是一条 assistant message,系统内部可能包含一次 run、多次 step、若干 tool call 和最终输出。

AI Run 生命周期 描述一次生成任务从创建到结束的状态变化。它是前端状态、后端任务和可观测日志之间的共同语言。

AI 应用架构

这张图把 AI 应用拆成可替换的层:前端不直接理解模型差异,业务后端不直接散落 Provider 细节,Gateway 负责把 Prompt、Context、Tool、Routing 和日志组织起来。

核心主题

  • AI 应用基本架构:frontend、backend、model provider、prompt layer、context layer、tool layer、storage layer、observability layer。
  • AI Gateway:provider abstraction、model abstraction、API key management、retry、timeout、fallback、rate limit。
  • Model Provider:OpenAI、Anthropic、Gemini、DeepSeek、Qwen、local model。
  • Model Routing:按任务、成本、速度、质量和 fallback 路由。
  • Session 设计:user、conversation、message、run、step、tool call。
  • AI Run 生命周期:created、queued、running、requires_action、completed、failed、cancelled。
  • AI 可观测性:latency、first token time、token usage、error rate、model distribution、user satisfaction。

阶段实践拆解

  1. 设计数据表:从 user、conversation、message 开始,再增加 run、step、tool call。
  2. 抽象 Provider 接口:统一输入 messages、tools、stream,统一输出 delta、usage、finish reason。
  3. 实现 AI Gateway:集中处理 API key、timeout、retry、fallback 和错误映射。
  4. 增加模型路由:根据任务类型或配置选择不同模型,并保留路由日志。
  5. 接入可观测性:记录每次请求的 token、cost、latency、first token time、model 和错误原因。
  6. 回到前端验证:让 Chat UI 能显示运行中、工具调用中、失败和重试状态。

阶段实践

  • 设计一套 AI Chat 数据表。
  • 实现一个 AI Gateway。
  • 记录每次请求 token、cost、latency。

计划文章

  • AI 应用为什么需要 Gateway 层
  • 如何设计 AI Chat 的数据库模型
  • AI 应用应该记录哪些日志