8.2AI 应用架构模式

先给直觉

最简单的 AI 应用是：

用户输入 → 模型 → 输出

这适合 Demo。

真实产品往往需要：

• 用户身份。
• 权限控制。
• 上下文管理。
• 文档检索。
• 工具调用。
• 输出校验。
• 日志记录。
• 成本控制。
• 失败处理。
• 人工审核。

所以 AI 应用架构不是“接一个模型”这么简单。模型是发动机，但产品还需要刹车、仪表盘、导航和保险杠。

模式 1：直接调用模型

结构：

用户输入
  ↓
Prompt 模板
  ↓
LLM
  ↓
输出

适合：

• 简单改写。
• 头脑风暴。
• 通用解释。
• 文案生成。
• 原型验证。

优点：

• 实现快。
• 成本结构简单。
• 适合早期试验。

缺点：

• 缺少私有知识。
• 难以保证事实。
• 输出不稳定。
• 缺少可追溯性。

这个模式适合低风险任务，不适合严肃知识问答。

模式 2：Prompt 模板应用

结构：

用户输入
  ↓
任务参数
  ↓
Prompt 模板
  ↓
LLM
  ↓
结构化输出

适合：

• 固定格式总结。
• 课程单元生成。
• 标签分类。
• 文案改写。
• 客服回复草稿。

关键设计：

• 模板版本管理。
• 输入字段校验。
• 输出格式校验。
• Prompt 变更记录。

Prompt 模板一旦进入产品，就应该像代码一样管理。随手改 Prompt，等于半夜改生产逻辑。

模式 3：RAG 架构

结构：

用户问题
  ↓
查询改写
  ↓
检索系统
  ↓
相关资料
  ↓
LLM 生成回答
  ↓
引用与评估

适合：

• 知识库问答。
• AI 搜索。
• 企业制度助手。
• 产品文档助手。
• 课程问答助手。

关键组件：

• 文档解析。
• Chunk 切分。
• Embedding。
• 向量/关键词检索。
• 重排。
• 上下文组装。
• 引用。
• 检索评估。

RAG 架构的重点是让模型“带着资料回答”，而不是靠记忆发挥。

模式 4：工具调用架构

结构：

用户请求
  ↓
LLM 判断工具
  ↓
参数生成
  ↓
权限和参数校验
  ↓
工具执行
  ↓
工具结果
  ↓
LLM 生成最终回答

适合：

• 查数据库。
• 查订单。
• 调日历。
• 执行代码。
• 查询实时信息。
• 操作业务系统。

关键组件：

• 工具 schema。
• 参数校验。
• 权限控制。
• 幂等性设计。
• 错误处理。
• 操作日志。
• 人工确认。

工具调用让模型能连接外部世界，也让风险从“说错”升级到“做错”。

模式 5：工作流型 Agent 架构

结构：

任务目标
  ↓
状态机 / 工作流
  ↓
模型判断
  ↓
工具调用
  ↓
结果检查
  ↓
确认节点
  ↓
继续或停止

适合：

• 研究助手。
• 内容生产流程。
• 数据分析助手。
• 代码修改助手。
• 工单处理。

关键组件：

• 任务状态。
• 计划生成。
• 步骤执行。
• 工具管理。
• 中间结果存储。
• 失败恢复。
• 人工确认。

工作流型 Agent 比自由 Agent 更适合产品化。

模式 6：模型路由架构

结构：

用户请求
  ↓
任务分类
  ↓
模型选择
  ↓
执行
  ↓
质量检查
  ↓
必要时升级模型

适合：

• 多任务 AI 产品。
• 成本敏感场景。
• 高频请求系统。
• 同时使用小模型和大模型的产品。

例子：

• 简单分类走小模型。
• 普通问答走中等模型。
• 高风险推理走强模型。
• 图片输入走多模态模型。

关键组件：

• 任务分类器。
• 成本策略。
• 模型能力表。
• 失败升级策略。
• 质量监控。

模型路由能降成本，但会增加系统复杂度。

模式 7：Human-in-the-loop

结构：

AI 生成
  ↓
风险判断
  ↓
人工审核
  ↓
修改 / 通过 / 拒绝
  ↓
记录反馈

适合：

• 对外发布内容。
• 法律、医疗、财务等高风险场景。
• 生产系统操作。
• 敏感数据处理。

关键组件：

• 审核队列。
• 审核标准。
• 版本对比。
• 审核日志。
• 反馈回流。

人工审核不是落后，而是高风险 AI 产品的安全结构。

横向基础能力

不管采用哪种架构，通常都需要这些基础能力。

上下文管理

决定模型看到什么。

包括：

• 系统提示。
• 用户输入。
• 历史对话。
• 检索资料。
• 工具结果。
• 用户偏好。

输出校验

检查模型输出是否符合要求。

包括：

• JSON 格式。
• 必填字段。
• 引用存在。
• 长度限制。
• 风险词。
• 是否越权。

日志

记录：

• 输入。
• 模型版本。
• Prompt 版本。
• 检索结果。
• 工具调用。
• 输出。
• 错误。
• 用户反馈。

评估

评估离线和线上表现。

权限

控制模型和工具能访问什么。

成本控制

记录 Token、调用次数、模型费用和工具费用。

场景选型

场景	推荐架构
文案改写	Prompt 模板
课程问答	RAG
查询订单	工具调用
研究报告生成	工作流型 Agent
高风险合同摘要	RAG + 强模型 + 人工审核
多任务助手	模型路由 + 工具调用
图片问答	多模态模型 + 必要时 RAG

案例：AI 课程学习产品架构

一个完整课程产品可以这样组合：

课程问答

• RAG。
• 引用课程资料。
• 资料不足时说明。

学习路径推荐

• 用户学习状态。
• 模型分析。
• 人类可编辑建议。

练习题生成

• Prompt 模板。
• Rubric。
• 人工抽查。

项目辅导

• 工作流型 Agent。
• 状态记录。
• 阶段确认。

内容更新

• 事实核查队列。
• 官方资料链接。
• 版本发布说明。

这不是一个聊天框能独自承担的。

常见误区

误区 1：所有 AI 应用都应该是 Chatbot

很多任务更适合按钮、表单、侧边栏、审核队列或自动化流程。

误区 2：RAG、Agent、工具调用互相替代

它们解决不同问题，经常组合使用。

误区 3：架构越复杂越专业

不一定。低风险任务用简单架构更好。

误区 4：日志以后再加

没有日志，系统出错很难定位。早期就要记录关键链路。

误区 5：Prompt 是临时文本，不需要管理

Prompt 在产品里就是行为逻辑，需要版本管理。

动手练习

为一个“AI 课程学习助手”设计架构。

填写：

功能	架构模式	关键组件	风险控制
课程问答
生成练习题
推荐学习路径
项目辅导
内容更新