AI 应用系统设计：从 Prompt Demo 到生产级架构

把一次模型调用包装成产品功能很容易，难的是让它在真实流量下可治理、可排障、可控制成本。这篇教程按接入、编排、模型、数据四层拆解 AI 应用的典型架构，讲清同步对话与异步流水线两种形态的设计差异、状态管理方式，以及延迟、成本、质量这个绕不开的三角。

它解决什么问题

最常见的 AI Demo 只有一条直线链路：前端收集问题，后端拼上系统提示词，调一次模型 API，把答案原样返回。验证产品想法够了，但真实用户进场后，缺口会集中爆发：

稳定性：单一模型、单次调用，超时或限流就是一次线上事故，没有重试与兜底。
权限：用户问什么就检索什么，越权文档悄悄进入上下文。
成本：月底账单只有总数，说不清钱花在哪位租户、哪个功能、哪个模型上。
可观测：回答出错时，只能从应用日志里猜当时发生了什么。
可演进：Prompt 硬编码在代码里，改一版提示词就是一次全量发布的赌博。

根本原因在于模型输出是概率性的：同一个问题的答案受 Prompt 版本、检索结果、上下文顺序、采样参数共同影响，出错时无法像普通 if-else 那样沿调用栈定位到某行代码。生产架构要解决的，就是把「一次聊天」改造成每一步都可记录、可回放、可回滚的任务流水线。

核心原理：四层职责划分

按请求的流向，可以把 AI 应用划成四层：

客户端 -> 接入层 -> 编排层 -> 模型层(网关) -> 数据层(知识/记忆/状态)
              |         |-> 工具运行时
              |         |-> 上下文组装(RAG + Memory)
              +-> 观测与评测贯穿全程

接入层：把请求变成可治理的任务

负责认证鉴权（用户、租户、数据范围）、协议适配（Web、App、Webhook 统一为内部任务模型）、限流防刷、幂等键分配，以及 PII 脱敏和提示词注入初筛。它输出的是结构化请求，而不是一段裸文本。

编排层：决定这次请求怎么跑

这是 Demo 里最缺的一层。它回答：这次走直答、RAG 问答、Agent 多步任务还是批处理？需要哪些上下文？允许调哪些工具？同步、流式还是异步？输出要不要进审核？一个关键原则是：规则能穷举的判断（权限、额度、确认流）交给代码，语言理解才交给模型。两者混进一个「超级 Prompt」后，出错时无法区分是规则失效还是模型判断偏差。

模型层：统一模型入口

即模型网关：收敛多家供应商的 API 差异，提供路由、失败切换、Token 预算和成本归因。业务代码只面对一个稳定接口，而不是分别耦合各家 SDK。

数据层：知识、记忆与状态

包括 RAG 知识库、Memory（用户偏好与长期事实）、会话历史、任务状态与 Trace 存储。注意三类上下文的治理规则完全不同：RAG 是共享知识源，权限过滤必须在检索时生效；Memory 是用户态可写数据，写错一条会污染后续所有会话；Tool 返回是运行时临时数据，需要摘要和污染防护。三者不应混成一段「背景资料」塞进 Prompt。

深入机制

两种形态：同步 Copilot 与异步流水线

同步形态以对话 Copilot 为典型：短问答直接等待返回，长回答用 SSE/WebSocket 流式输出改善首字延迟体验。设计要点是短超时、快速失败、首 Token 延迟（TTFT）监控和可取消生成。

异步形态以批处理流水线为典型：报告生成、批量评测、长文档分析等多步任务放入队列，任务表记录状态，通过回调或 Webhook 通知结果。它换来的是可排队、可重试、可恢复，代价是状态与通知链路的复杂度。判断依据很直接：能稳定几秒内完成的用同步，需要首字反馈的用流式，多步骤长任务必须异步化。

状态管理：会话与任务分开建模

会话状态（多轮对话历史）随轮次膨胀，需要压缩与摘要策略；任务状态（异步作业的 PENDING/RUNNING/SUCCEEDED/FAILED/UNKNOWN）需要状态机、进度事件和补偿机制。两者都不要丢进上下文让模型自己记——状态是系统的责任，模型每轮只看到系统精心挑选后的视图。带副作用的异步任务建议用 outbox 模式保证至少一次执行；超时且结果不明的任务进入 UNKNOWN 状态走对账，而不是盲目重试造成重复扣款。

与微服务体系的关系

AI 应用不是微服务之外的飞地。编排服务、RAG 服务、工具运行时应作为普通微服务接入现有的注册发现、配置中心、熔断限流与灰度发布体系；模型网关则补齐传统 API 网关不覆盖的模型特有治理（路由、Token 计量）。消息队列、缓存、对象存储原样复用，真正新增的只有评测集与 Trace 这类 AI 特有的数据资产。

工程实践

Prompt 当配置而非代码：模板版本化，支持灰度与回滚，每次请求记录所用版本号；Trace 与版本绑定才能回放。
幂等设计前置：可重试的写操作和异步任务从第一版就带幂等键，不要等出现重复执行再补。
上下文预算：调用前估算 Token，超预算时先删低相关片段、压缩历史消息，而不是从字符串中间截断。
观测从第一天做起：记录 Prompt 版本、检索命中、工具调用、Token 用量与各段耗时。没有 Trace，一切优化都是猜。

对比与权衡

延迟、成本、质量构成 AI 应用的铁三角，任何架构决策都是在三者之间取点：

维度	拉高它的手段	付出的代价
质量	更强模型、更多检索证据、多轮校验	成本与延迟同步上升
低延迟	小模型、流式输出、缓存命中	复杂任务质量下降
低成本	模型分级路由、语义缓存、Token 预算	额外的路由与缓存基建

三种交互形态的取舍同样围绕这个三角：

形态	适用场景	优势	主要风险
同步	分类、抽取、短问答	链路简单、易排障	超时敏感、占用连接
流式	对话、长文生成	首字快、体验好	中断恢复与前端状态复杂
异步	报告、批处理、多工具任务	可重试可恢复	状态机与通知链路复杂

选型建议：默认从最简单的同步做起，出现具体瓶颈再引入流式或队列，不要为想象中的规模提前堆复杂度。

面试视角

Prompt Demo 与生产系统的核心差距是什么？ Demo 只验证模型能否答一次；生产系统还要处理超时降级、租户权限、Token 成本归因、全链路 Trace、评测回放与数据留存。回答时可以按稳定性、权限、成本、观测、评测、数据治理六个维度组织。

为什么需要单独的编排层，直接把逻辑写进 Prompt 不行吗？ 权限、额度、确认流是确定性规则，用代码执行才可靠、可测、可审计；模型擅长的是规则难以穷举的语言理解。混在一起后，出错无法归因，规则改动也无法灰度。

同步、流式、异步怎么选？ 看三点：能否在超时窗口内稳定完成、用户是否需要即时的首字反馈、失败后是否需要重试恢复。短任务同步，对话流式，长任务异步入队。

RAG、Memory、Tool 三者的治理差异？ RAG 是共享知识，权限在检索时过滤；Memory 是用户态长期数据，写入要校验来源与置信度并设过期时间；Tool 是运行时能力，要按风险分级并做执行前鉴权。三者分区注入上下文，不能混为一段文本。

AI 应用如何与现有微服务体系融合？ AI 能力按领域拆成普通服务，复用注册发现、配置、熔断、灰度等既有基建；差异主要在模型网关、Prompt 版本管理与评测体系这三块新增资产上。

小结

生产级 AI 架构的核心是分层与解耦：接入层管治理，编排层管路径，模型层管入口，数据层管知识与状态。
同步对话与异步流水线是两种基本形态，按耗时、首字反馈和恢复需求选择，别为想象中的规模过度设计。
状态（会话与任务）由系统而非模型管理；写操作和异步任务必须幂等。
延迟、成本、质量是永恒的三角，模型分级路由、缓存与 Token 预算是日常调节旋钮。
Prompt 版本与请求 Trace 要从第一版就建立——没有回放能力，就没有优化能力。