AI应用架构：模型网关、队列、审计、租户、配额、缓存和观测
摘要
生产级 AI 应用的架构问题，不是模型 API 怎样接得更快，而是一个非确定、昂贵且持续变化的智能组件如何进入长期运行的业务系统。本文把模型网关、任务队列、审计、多租户、配额、缓存、观测、RAG 和上下文管理视为同一套治理结构：它们共同决定一次模型调用能否被授权、被解释、被限额、被恢复和被持续改进。文章关注最小可行生产架构，而不是一次性搭建平台；重点是把早期容易遗漏的证据链、成本归因和质量反馈从第一天纳入系统边界。
关键词
AI 应用架构；模型网关；任务队列；多租户；配额；缓存；可观测性；审计；RAG
研究问题与方法
本文的研究问题是：一个 AI 应用从演示进入真实组织使用时，哪些架构能力是功能成立的前提，而不是上线后的补丁。方法上采用系统分层和失效模式分析，把一次请求拆成身份、上下文、模型、工具、存储、交付与反馈几个环节，观察费用失控、质量回退、权限泄露和供应商故障分别在哪些环节被放大。
图中三层不是部署拓扑，而是责任边界。入口层决定谁能发起什么任务，智能层决定模型怎样拿到材料并行动，治理层决定系统如何被限制、解释和改进。后文评估架构是否足够生产化时，使用下面的取舍表避免只看“能否回答”。
| 维度 | 关键问题 | 架构证据 |
|---|---|---|
| 可控性 | 是否能限制谁、何时、用什么模型和工具 | 网关策略、租户权限、配额记录 |
| 可解释性 | 是否能复盘一次答案怎样产生 | trace、检索片段、提示词版本、工具审计 |
| 可恢复性 | 失败、限流、超时后是否有明确路径 | 队列状态、幂等键、降级与死信处理 |
写作日期：2026-05-22
AI 应用的生产架构，不是把一个聊天框接到模型 API 上，也不是把提示词、知识库和几个工具堆在一起。真正需要设计的是一套可运行、可隔离、可追踪、可恢复、可计费、可优化的应用系统。模型只是其中一个能力节点，围绕模型调用还要有模型网关、任务队列、审计日志、多租户权限、配额控制、缓存策略、可观测性、知识检索、上下文管理和质量评测。缺少这些能力时，应用在演示阶段看起来很聪明，进入真实业务后就会暴露一连串问题：费用突然上升、某个用户拖垮全局、错误回答无法追溯、模型供应商故障导致全站不可用、敏感资料被越权检索、长任务中断后只能重来、RAG 命中率变差但无人发现。
生产级 AI 应用和普通 Web 应用最大的差异，是系统中存在一个高成本、非确定、受上下文影响、受供应商容量约束的智能组件。传统后端服务通常关心请求、数据库、缓存、队列和权限；AI 应用还要关心模型版本、提示词版本、token 预算、上下文窗口、检索证据、工具调用、缓存命中、模型路由、内容安全、人工确认和输出质量。架构设计的目的不是限制模型能力，而是给模型提供正确上下文、可靠工具和清楚边界，让它能真正完成工作，而不是在不可控环境里随机发挥。
这一篇从教程视角系统拆解 AI 应用生产架构。读者不需要一开始就搭建庞大平台，但需要理解每个关键模块为什么存在、解决什么风险、最小实现可以怎样做、后续扩展如何演进。模型网关不是可选装饰，队列不是性能问题才需要，审计不是合规部门才关心，多租户不是大型 SaaS 才遇到，缓存也不只是省钱技巧。它们共同决定一个 AI 应用能否从“能跑”进入“能长期服务真实用户”。
引言：AI 应用的生产架构到底包含什么
可以把 AI 应用拆成三层：入口层、智能层和治理层。入口层负责用户、组织、权限、页面、API、文件上传和业务流程；智能层负责模型调用、RAG、工具调用、Agent 编排、记忆和异步任务；治理层负责网关、配额、审计、缓存、观测、评测、告警和成本管理。三层并不是物理部署边界，而是责任边界。一个小团队可以把它们放在同一个后端服务里，但逻辑上仍然要分清楚。
入口层回答“谁在做什么”。用户属于哪个组织，当前角色能访问哪些知识库，能调用哪些工具，能上传多大文件，能否发起长任务，结果应该返回到哪个工作区。AI 应用一旦有团队、项目、客户或课程空间，就已经进入多租户问题。租户边界如果没有在入口层明确，后续 RAG、缓存和日志都会混在一起。
智能层回答“模型如何完成任务”。模型需要什么系统指令，用户输入如何规范化，是否要检索知识库，检索结果如何重排，是否需要调用工具，工具输出如何进入下一轮上下文，是否要保存短期状态或长期记忆，是否需要人工确认。这里不能只靠提示词。提示词可以描述行为，但无法替代状态机、权限系统、队列、数据库和审计。
治理层回答“系统如何被控制和解释”。模型网关统一接入 OpenAI、Anthropic、Google、Bedrock、本地模型或其他供应商；配额系统限制用户、租户、项目、模型和功能的使用量；缓存降低重复上下文和重复结果的成本；审计记录输入、检索、工具、输出和人工确认；观测系统把一次请求拆成 trace、metrics 和 logs；评测系统把线上失败样本转化为可回归的质量资产。
一个常见误解是：先把产品做出来，治理能力以后再补。普通功能也许可以这样迭代，AI 功能更难。因为模型调用记录、提示词版本、检索证据和用户反馈如果早期没有保存，后面无法复盘。用户说“昨天的答案引用错了”，系统却查不到当时用了哪个模型、哪个提示词、哪批知识片段、哪次工具结果，就只能靠猜。生产架构不一定要重，但关键证据要从第一天保存。
模型网关是 AI 架构的中枢
模型网关的基本职责是把应用和模型供应商解耦。没有网关时，每个业务服务直接保存供应商密钥、直接拼请求、直接处理重试、直接解析响应。短期代码少，长期会失控。团队一旦接入多个模型、多个供应商、多个项目和多个用户，就会遇到统一鉴权、成本统计、路由降级、限流、审计、缓存和安全策略问题。把这些能力散落在各个业务服务里，维护成本会越来越高。
模型网关至少要解决七件事。第一，统一接口，让业务服务用稳定协议调用不同模型。LiteLLM 文档把代理服务定位为中心化 LLM Gateway，强调 OpenAI 格式适配、多供应商调用、虚拟密钥、成本追踪和预算管理；Kong AI Gateway 也强调对 LLM API 的代理、日志、成本跟踪、限流和安全策略。第二，密钥集中管理，业务应用只拿网关的项目级密钥，不直接持有供应商主密钥。第三，模型别名和路由，把“客服摘要模型”“代码审查模型”“中文长文模型”映射到实际供应商和版本。第四，失败重试和降级，当某个供应商超时、429 或区域异常时，按任务类型切到备用模型。第五，token 和费用统计，记录输入、输出、缓存命中、重试次数和最终成本。第六，策略拦截，执行模型白名单、敏感任务限制、内容安全和租户配额。第七，统一观测，把每次模型调用作为 trace 中的一个 span。
模型网关不是“所有请求都走同一个模型”的反面，而是让路由更细。简单分类可以走低成本模型，复杂推理可以走强模型，隐私敏感任务可以走本地模型，长文总结可以走支持大上下文和缓存的模型，稳定模板化任务可以优先查缓存。没有网关时，模型选择往往写死在业务代码里；有网关后，业务代码只表达任务意图，具体模型由策略和配置决定。
路由策略需要保守。不要因为一个模型便宜就把高风险任务全部切过去，也不要因为某个模型榜单高就承担所有请求。更稳的做法是按任务建立能力矩阵：摘要、分类、抽取、问答、工具调用、代码、长上下文、多模态、低延迟、低成本、本地隐私。每类任务有主模型、备用模型、不可用时的用户提示和人工处理路径。路由不是盲目自动化，而是把业务风险、质量要求和成本约束写进系统。
网关还要支持流式响应。许多 AI 应用需要边生成边展示，但流式响应会让统计、重试和审计复杂化。请求一旦开始输出，失败后不能像普通 HTTP 请求一样无感重试，因为用户已经看到了部分结果。生产系统要记录流式输出是否完整、是否被客户端中断、是否发生模型侧终止、是否命中安全策略。对写入业务系统的任务，更不能把流式文本当作最终事实，必须等完整结果通过格式校验和业务校验后再提交。
最小模型网关可以从一个后端模块开始：接收统一请求，附带用户、租户、任务类型和预算上下文；根据配置选择模型；调用供应商；记录 token、耗时、错误和成本；返回标准化响应。随着规模上升，再引入独立代理、虚拟密钥、仪表盘、细粒度策略和多区域部署。重点是不要让每个应用各自直连模型。
队列让长任务、重试和削峰可控
AI 应用大量任务不适合在一次同步 HTTP 请求里完成。上传一批 PDF 后解析、切分、向量化、生成摘要；给一千条工单做分类；对代码仓库做索引；让 Agent 执行多轮研究；批量生成个性化邮件；这些任务耗时长、步骤多、容易受模型供应商限流影响。如果全部放在前端等待的请求里，用户体验差，服务也难恢复。
队列的价值不只是提高吞吐，而是把任务变成可管理对象。一个任务入队后，系统可以记录状态、优先级、重试次数、租户、输入摘要、幂等键、截止时间和处理结果。消费者处理失败时，可以按错误类型决定立即重试、延迟重试、进入死信队列或等待人工处理。RabbitMQ 可靠性文档强调数据安全需要节点、发布者和消费者共同负责，消费者要准备处理重复投递并尽量设计成幂等。Kafka 设计文档也提醒消息语义要看清边界，所谓一次性语义并不会自动覆盖所有失败场景。AI 任务尤其要把幂等当作基本要求，因为模型调用、文件写入、邮件发送和数据库更新都可能在中途失败。
队列在 AI 架构里常见于五类工作。第一，文件处理队列，负责上传后的病毒扫描、格式识别、OCR、文本抽取、切分和索引。第二，模型调用队列，负责批量摘要、批量分类、离线打标和成本可控的后台生成。第三，Agent 执行队列，负责多步任务、工具调用、人工确认和恢复。第四，通知队列，负责生成完成后提醒用户、推送消息或写入外部系统。第五，评测队列，负责将线上样本送入离线评测、回归集和质量分析。
同步请求和异步任务要明确分工。低延迟问答、聊天、短文本改写可以同步处理，必要时用流式响应。长文档处理、批量任务、跨系统写入、高成本推理和可能等待人工确认的任务，应该异步化。异步并不意味着用户看不到进度。相反，生产级体验应该提供任务状态：排队中、处理中、等待确认、部分完成、失败可重试、已完成。用户不需要知道内部队列名，但需要知道系统是否还在工作，以及下一步由谁行动。
重试策略不能粗暴。模型供应商返回 429，可以根据 retry-after 或指数退避重试；外部 API 短暂超时，可以延迟重试；用户权限不足，不应该重试；输入文件损坏，不应该无限重试；模型输出格式不合法，可以用修复提示词重试一次，但多次失败后要进入人工复核或给出可理解错误。死信队列不是垃圾桶，而是失败样本库。失败样本要能被查看、分类、修复和重放。
AI 队列还要结合配额。一个租户提交一万个文档索引任务，不能把全站模型额度占满。队列调度要考虑租户级并发、任务优先级、模型供应商限流、成本预算和后台低峰执行。高价值交互任务通常优先于离线批处理；付费租户可以有更高并发；低优先级批处理可以在夜间执行。没有队列时，这些策略很难落地。
审计日志保存责任链，不只是排错信息
AI 应用审计的目标不是收集越多日志越好，而是保存足以解释结果和责任边界的证据。一次 AI 输出通常来自用户输入、系统提示词、历史对话、检索片段、工具返回、模型版本、路由策略、缓存命中、后处理规则和人工修改。任何一个环节变化，结果都可能不同。如果审计只记录最终文本，就无法说明“系统为什么这样答”。
生产级审计至少包含六类记录。第一，身份和上下文：用户、租户、项目、角色、入口、请求 ID、任务 ID。第二，输入和策略：用户输入摘要、敏感字段脱敏状态、提示词版本、模型路由决策、温度等关键参数。第三，检索证据：知识库 ID、文档版本、片段 ID、召回分数、重排结果、引用位置。第四，工具调用：工具名、参数摘要、授权结果、执行耗时、返回状态、幂等键和副作用结果。第五，模型输出：token 统计、缓存命中、停止原因、结构化字段、最终答案版本。第六，人工动作：谁确认、谁修改、谁驳回、确认时看到的内容是什么。
审计日志和普通应用日志不同。普通日志服务于工程排查，可能只保留错误堆栈和请求耗时；审计日志服务于责任说明，必须能回答“谁在什么权限下让系统做了什么，系统依据什么产生结果，哪些外部动作已经发生”。在客服、教育、医疗、财务、合同、代码部署等场景，审计不是上线后的合规补丁，而是产品可信度的一部分。
审计也要考虑隐私和成本。直接保存完整提示词和完整输出最方便，但可能包含个人信息、商业秘密和用户上传资料。AWS Bedrock 的模型调用日志文档说明可以把调用日志发送到 CloudWatch Logs 或 S3，并记录请求、响应和元数据；这类能力很有用，但也提醒团队要处理敏感日志和访问权限。实际系统中可以分层保存：默认保存结构化摘要、哈希、片段 ID 和指标；对高风险业务或用户授权场景，保存完整证据；对敏感内容做脱敏、加密和保留周期控制。
审计记录要能关联。请求 ID 贯穿入口、后端、队列、模型网关、RAG、工具和数据库写入。没有统一 ID，事后只能在多份日志里人工拼接。最好为用户请求、后台任务、模型调用、工具调用分别建立 ID，并在 trace 中形成父子关系。这样用户反馈一条错误答案时，系统能直接定位到具体链路。
审计还要服务持续改进。错误答案、低分反馈、人工重写、工具失败、检索空结果、缓存误命中，都可以进入样本库。样本库用于回归评测、提示词优化、检索策略调整和模型路由优化。只把审计当作事后追责，会浪费大量质量信号；把审计变成质量闭环，AI 应用才会越用越稳。
多租户隔离是权限、数据和成本的共同边界
多租户不只是 SaaS 平台才需要。只要一个系统里有多个团队、项目、客户、课程、知识库或工作区，就已经需要租户隔离。AI 应用的多租户更敏感，因为模型输入可能包含私有文档、客户信息、对话历史和工具结果。一次越权检索或缓存串租户，后果比普通页面多展示一条记录更严重。
租户隔离至少有四个维度。第一，身份隔离：用户属于哪个组织，拥有什么角色，能访问哪些项目。第二，数据隔离：文件、向量、对话、记忆、任务、审计和模型输出都要带租户标识。第三，能力隔离：不同租户可用的模型、工具、知识库、并发和额度不同。第四，成本隔离：模型 token、缓存、队列任务、向量存储和文件存储要能按租户归集。
RAG 是多租户风险高发区。向量库里如果只存 embedding 和文本，不存租户、权限和文档版本，检索时就很容易跨边界召回。正确做法是把租户、项目、知识库、文档、版本、可见角色、过期状态作为检索过滤条件的一部分，而不是检索后再让模型判断能不能用。模型不应该承担访问控制职责。它可以解释资料，但不能决定用户是否有权看到资料。
缓存也是高风险区。提示词缓存、语义缓存、模型响应缓存、工具结果缓存，都要考虑租户边界。OpenAI 和 Vertex AI 的上下文缓存文档都强调重复内容可降低成本和延迟，Vertex AI 还区分隐式缓存和显式缓存。应用自建缓存时，必须把租户、权限、模型、提示词版本、工具版本、数据版本和安全策略纳入缓存键或命中条件。否则 A 租户问过的问题可能被 B 租户命中，或者用户权限变化后继续得到旧缓存答案。
工具调用同样要按租户隔离。一个“查询订单”工具，模型看到的只是工具描述，但后端必须根据当前用户和租户注入授权条件。不要把 tenant_id 作为模型可自由填写的参数，也不要让模型传入任意 SQL 条件。工具接口应该由系统上下文绑定租户，模型只能提供业务上必要的查询条件。执行前后都要记录授权结果。
多租户还影响观测。指标和告警既要看全局，也要看租户。全局错误率正常，不代表某个租户知识库没有失效；全局费用可控，不代表某个项目没有异常消耗。模型网关、队列和审计系统都应该支持按租户过滤。这样才能回答客户关心的问题：我们用了多少、花了多少、哪些任务失败、哪些资料被引用。
配额和限流把成本风险前置
AI 应用的成本风险比普通应用更直接。一个普通搜索请求可能消耗很少资源，一个长上下文模型请求可能消耗大量 token；一个用户的批量任务可能在几分钟内花掉一天预算；一个错误循环的 Agent 可能连续调用工具和模型直到触发供应商限流。配额和限流的作用，是在成本失控前把风险挡住，并给用户清楚的使用边界。
配额分为硬配额和软配额。硬配额是绝对限制，比如某租户每月最多一千万输入 token、每天最多一千次高端模型调用、每个用户最多五个并行长任务。软配额是预警和降级，比如达到月度预算 80% 时通知管理员，达到 90% 时把低优先级任务切到便宜模型，达到 100% 时只允许关键功能继续。Anthropic API 限流文档提到组织级消费限制、429 错误和 retry-after；Vertex AI 文档也说明生成式 AI 服务存在配额系统、动态共享配额或预置吞吐等不同消费方式。应用不能把供应商限流原样暴露给用户，而要在自己的配额系统中提前管理。
限流有多个层次。入口层限制请求频率，防止恶意或误操作；模型网关限制模型调用频率和 token 速率，保护供应商额度；队列限制租户并发和后台任务量，保护系统资源；工具层限制高风险动作频率，保护业务系统。Kong Gateway 的限流文档把限流应用到服务、路由和消费者；AI Gateway 进一步提供面向 LLM 的限流能力。对 AI 应用来说，按请求数限流不够，还要按输入 token、输出 token、缓存创建 token、成本、并发任务和工具调用次数限流。
配额系统要面向产品体验。用户不应该只看到“429”或“quota exceeded”。更好的体验是：当前套餐剩余额度、预计本次任务消耗、超额后可选动作、管理员如何调整、低成本模式是否可用。对于长任务，提交前就应该估算成本范围。用户上传一百份文档时，系统要告诉他预计处理时间和额度影响，而不是处理一半才失败。
配额还影响模型路由。一个租户高端模型额度用完后，可以降级到中档模型，但并非所有任务都适合降级。合同风险、医疗建议、代码发布、财务分析等高风险任务，宁可暂停并请求管理员确认，也不应该静默切到能力不足的模型。生产级路由需要把“可降级”和“不可降级”作为任务属性。
成本归因要足够细。按供应商账单看，只能知道总体费用；按模型网关看，才能知道哪个租户、哪个功能、哪个提示词版本、哪个知识库任务消耗最多。很多成本优化不是换模型，而是发现重复上下文没有缓存、RAG 片段过多、Agent 循环次数过高、失败重试太激进、后台任务没有削峰。配额和观测结合，才能做真实优化。
缓存不是偷懒，而是上下文资产管理
AI 应用缓存有四层。第一层是传统缓存，缓存用户资料、配置、权限和常用查询。第二层是检索缓存，缓存搜索结果、向量召回、重排结果和文档解析结果。第三层是提示词或上下文缓存，利用供应商能力降低重复前缀、长系统指令、固定资料和多轮对话的成本。第四层是语义响应缓存，对语义相近的低风险问题复用已有答案。
提示词缓存适合大块重复上下文。OpenAI prompt caching 文档说明重复请求相同前缀时可以更便宜、更快，并在 usage 中体现 cached tokens；Vertex AI context cache 文档说明上下文缓存适合反复引用大量初始上下文的场景，例如长系统指令、长视频分析、反复查询大文档集或代码仓库。Anthropic prompt caching 文档也提供了缓存控制能力。共同启发是：把稳定、大块、重复的内容放在上下文前部，并保持结构稳定，能提高缓存收益。
自建缓存要谨慎区分“完全相同”和“语义相似”。完全相同缓存适合确定性强的任务：同一模型、同一提示词版本、同一输入、同一知识版本、同一权限上下文。语义缓存适合低风险、高重复、答案稳定的问题，例如帮助中心问答、政策解释、常见流程咨询。RedisVL 的 LLM Cache 文档提供了 SemanticCache，通过向量相似度检查相似提示并返回缓存响应。语义缓存的好处是节省成本和降低延迟，风险是误命中。如果用户问“能不能删除账户”和“怎么删除团队账户”被错误地当作同一问题，结果可能产生风险。
缓存键设计决定安全。一个 AI 响应的缓存键不应只包含用户问题，还要包含租户、角色、模型、提示词版本、知识库版本、工具版本、安全策略、语言和输出格式。对 RAG 问答，还要考虑召回片段版本。对工具结果缓存，要考虑工具权限和数据更新时间。对多轮对话，要考虑会话状态。少放一个关键维度，就可能出现旧答案、越权答案或不符合当前配置的答案。
缓存失效比缓存命中更重要。知识库更新后，旧 RAG 答案是否还能用？用户权限变化后，旧缓存是否立即失效？模型升级后，旧输出是否仍可复用？提示词改版后，是否要清空相关缓存？对政策、价格、库存、订单状态、法律条款等时效性强的数据，缓存 TTL 要短，甚至只缓存检索计划，不缓存最终答案。对稳定文档摘要、内部规范解释和固定教材问答，缓存周期可以更长。
缓存还可以服务架构分层。文件解析结果应缓存，避免每次问答重复解析 PDF；文档切分和 embedding 应版本化缓存，避免每次重建知识库；工具查询结果可短缓存，降低业务系统压力；模型输出可在低风险场景缓存；评测结果也可缓存，避免重复跑昂贵评测。好的缓存体系把昂贵步骤变成可复用资产，而不是把不确定答案随便存起来。
观测要覆盖 token、延迟、质量和链路
AI 应用可观测性不能只看服务是否在线。一个接口返回 200，但答案引用错、工具调用失败后被模型掩盖、RAG 没召回关键资料、成本比昨天高三倍，这些都属于生产问题。可观测性要同时覆盖系统健康、模型调用、业务质量和用户反馈。
OpenTelemetry 提供 trace、metrics 和 logs 的通用框架，GenAI semantic conventions 进一步定义了生成式 AI 操作相关的语义属性、指标、span 和事件名称。它的价值不在于某个具体后端，而在于统一命名和链路结构。一次 AI 请求可以被拆成入口请求、权限检查、检索、重排、模型调用、工具调用、后处理、写入和响应。每个步骤都有耗时、状态、错误和关键属性。没有 trace 时，用户说“很慢”，团队不知道慢在检索、模型、工具还是网络。
指标层要看四组数据。第一，流量和延迟：请求量、并发、P50/P95/P99、流式首 token 时间、总生成时间。第二，错误和稳定性：供应商错误、超时、429、格式校验失败、工具失败、队列积压、死信数量。第三，成本和 token：输入 token、输出 token、cached token、每租户费用、每功能费用、重试成本。第四，质量信号：检索命中率、引用覆盖率、用户点赞点踩、人工重写率、任务完成率、评测分数。
日志层要服务定位，但不能泄漏敏感信息。模型输入输出可能包含用户资料，不适合无差别写入普通日志。可以在应用日志中保存摘要、哈希、ID 和错误原因，在审计存储中按权限保存完整证据。日志要结构化，包含请求 ID、租户、用户、任务、模型、提示词版本、知识库版本和错误码。自然语言错误描述可以有，但不能替代结构化字段。
Trace 层特别适合工具调用和 Agent。Agent 经常多轮循环：观察、计划、调用工具、读取结果、继续推理。若只保存最终答案，无法知道它为何走错路径。Trace 可以展示每轮模型调用、每次工具输入输出、每次检索结果和每个判断节点。LangGraph durable execution 文档强调通过持久化检查点让工作流能暂停和恢复，并要求副作用操作具备幂等性；这些运行时状态也应进入观测体系。
观测还要闭环到告警。模型错误率升高、某供应商 429 增加、缓存命中率骤降、某租户费用异常、队列积压、知识库索引失败、评测分数下降，都应该触发告警。告警不应只发给工程师，也要根据类型通知产品、运营或租户管理员。比如某个租户接近月度预算，管理员比工程师更适合处理。
RAG、记忆和上下文管理是应用质量核心
模型网关、队列、审计和观测解决“系统能否稳定运行”，RAG、记忆和上下文管理解决“模型能否拿到正确材料”。很多 AI 应用质量差，不是模型不够强，而是上下文错了。用户问的是最新制度，系统检索到旧版本；用户在 A 项目里提问，系统召回 B 项目资料；文档切分丢掉表格标题；历史对话太长，把关键约束挤出窗口；工具返回结果没被整理清楚，模型误读状态。
RAG 的生产链路通常包括资料接入、解析、清洗、切分、embedding、索引、召回、过滤、重排、上下文拼装、引用生成和反馈评测。每一步都要带版本。资料有版本，解析器有版本，切分策略有版本，embedding 模型有版本，索引有版本，提示词有版本。没有版本，质量变化无法定位。用户说“上周还答对，今天答错”，团队必须能判断是资料更新、模型路由、切分策略还是提示词改版导致。
记忆系统要区分短期和长期。短期记忆是当前会话、当前任务、当前 Agent 状态；长期记忆是跨会话保留的用户偏好、项目事实、历史决策和业务知识。LangGraph memory 文档把短期记忆作为 agent state 的一部分管理，也区分更持久的记忆能力。生产系统中，长期记忆必须可见、可编辑、可删除、可授权，不能让模型随意把用户一句话永久写入记忆。错误记忆比没有记忆更危险。
上下文管理要考虑顺序、密度和来源。长上下文模型并不意味着可以把所有资料塞进去。Lost in the Middle 论文显示，模型在长上下文中使用中间位置的信息会变弱，相关信息位置会影响表现。工程上应把关键指令、任务目标、权限边界、当前状态和最相关证据放在清晰位置，减少无关材料。上下文不是越多越好，而是越相关、越结构化、越可追溯越好。
工具结果也是上下文。很多系统把工具返回的原始 JSON 直接塞给模型，字段多、命名乱、错误码晦涩，模型自然容易误解。工具应该返回面向模型的结构化结果：动作是否成功、关键业务字段、可用证据、下一步可选动作、不可执行原因。工具描述也要像提示词一样认真设计。Anthropic 的 agents 实践文章强调工具定义和规格需要像整体提示词一样投入提示工程注意力，这对生产工具调用非常关键。
RAG 和记忆还要进入审计和评测。每次回答引用了哪些片段、是否覆盖答案关键断言、用户是否点击了来源、人工是否修改引用，都应该沉淀为质量信号。只评测最终文本流畅度不够，要评测证据正确性、权限正确性、引用完整性和拒答边界。
从最小生产架构开始，而不是一步到位造平台
一个小团队可以从最小生产架构开始：应用后端、数据库、对象存储、模型网关模块、任务队列、向量检索、审计表、基础指标和管理后台。这个形态不一定复杂，但责任边界清楚。用户请求进入后端，后端完成身份和权限检查；需要模型时通过网关调用；需要长任务时写入队列；需要知识时通过带权限过滤的检索服务；每次模型调用、工具调用和最终输出都写入审计；关键指标进入观测系统。
第一阶段目标是“可追踪”。每个 AI 功能都要能查到：谁调用、用了哪个模型、用了哪个提示词版本、消耗多少 token、检索了哪些资料、调用了哪些工具、结果是否被用户采纳。即使没有独立网关，也要在后端统一记录这些信息。没有追踪，就没有优化。
第二阶段目标是“可控成本”。引入租户配额、模型路由、缓存和后台队列。把高频简单任务切到低成本模型，把重复系统指令和长资料利用供应商缓存，把批量任务放进队列削峰，把预算接近上限的租户降级或暂停。成本控制不是财务报表，而是架构能力。
第三阶段目标是“可恢复”。长任务有状态，队列有重试和死信，Agent 有检查点，外部副作用有幂等键，人工确认有记录。系统中断后，不应该只能从头开始。LangGraph 的 durable execution 给了一个清晰思路：工作流在关键点保存进度，恢复时避免重复副作用。即使不用 LangGraph，也应在自研任务表中保存步骤状态。
第四阶段目标是“可评测”。把线上真实样本转成评测集，覆盖常见问题、边界权限、旧资料、复杂工具调用、高风险拒答和多租户隔离。每次提示词、模型、检索策略或工具改动，都跑回归评测。AI 功能不能只靠人工主观体验上线，尤其是已经进入生产流程后。
第五阶段目标是“平台化”。当多个业务功能都需要模型网关、配额、审计、RAG、队列和观测时，再抽象为内部 AI 平台。平台化过早会拖慢产品，平台化过晚会造成重复建设。判断时机的标准不是团队规模，而是重复痛点是否已经稳定出现。
典型案例：企业知识助手的架构拆解
假设要做一个企业知识助手，支持员工提问制度、项目资料、合同模板和历史会议纪要。最小可用演示很简单：上传文件，做 embedding，用户提问，检索片段，拼接提示词，调用模型回答。但生产系统要多出许多架构决策。
入口层要接入企业身份系统，用户属于部门、项目和角色。知识库按组织、项目、资料类型和保密等级隔离。用户提问时，后端先解析当前身份，再决定可检索范围。向量检索时必须带权限过滤，不允许先召回后让模型判断。答案引用必须指向用户有权访问的资料，并显示资料标题、更新时间和片段位置。
模型网关负责选择模型。普通制度问答走中档模型，复杂合同条款解释走强模型，内部敏感材料可走私有模型或受控云模型。系统提示词和资料格式保持稳定，以便命中提示词缓存。重复问答可使用严格缓存，但缓存键包含租户、权限、知识库版本和提示词版本。高风险问题，比如“这份合同是否可以直接签”，需要输出风险点和建议人工确认，而不是给出确定结论。
队列负责资料处理。员工上传文件后，任务进入解析队列，完成 OCR、文本抽取、切分、embedding 和索引。处理失败进入死信列表，管理员能看到是哪份文件、哪一步失败、是否可重试。大批量资料导入按租户限速，避免影响在线问答。
审计保存每次问答证据。系统记录用户问题、检索片段 ID、模型版本、提示词版本、输出答案、引用资料和用户反馈。敏感内容只在审计存储中加密保存，普通日志只保存 ID 和摘要。当员工质疑答案时，管理员能还原当时的资料版本和模型调用。
观测系统看质量和成本。指标包括问答量、无答案率、引用点击率、用户点踩率、检索空结果、缓存命中、每部门 token 消耗、P95 延迟和索引失败率。如果某个知识库更新后点踩率上升，团队能定位到资料质量或切分策略问题，而不是笼统认为模型变差。
这个案例说明：同一个“知识问答”功能，演示架构和生产架构差距巨大。生产不是堆功能，而是把身份、权限、资料、模型、任务、证据、成本和质量都纳入同一条责任链。
典型案例：AI 客服和工单处理架构
AI 客服比知识助手更强调动作边界。用户不仅问问题，还可能要求退款、改地址、查订单、取消订阅、升级套餐。模型不能只会回答，还要能调用业务工具。但工具调用一旦有副作用，就必须经过权限、校验、幂等和审计。
架构上，前端会话进入客服后端，后端识别用户身份和会话上下文。模型网关调用对话模型，模型可以使用订单查询、政策检索、优惠券查询、工单创建等工具。工具参数由后端绑定用户身份，模型不能自行指定任意用户 ID。退款、取消订单、修改地址这类动作需要生成确认摘要，让用户或人工客服确认后执行。
队列负责异步工单。复杂问题不能在聊天里无限等待，系统应创建工单任务，后台汇总对话、检索政策、查询订单、生成处理建议，再推给人工客服。客服确认后，系统执行动作并通知用户。整个过程有状态，而不是一段聊天文本。
配额用于控制滥用和成本。游客只能使用基础问答，登录用户可以查订单，高价值客户有更高并发和更强模型，异常高频用户进入限流。模型供应商超时时，系统可以降级为检索式答案或转人工，不应让用户卡在生成中。
审计在客服场景尤其重要。每一次承诺、退款建议、政策引用、人工接管和最终处理都要保存。模型输出如果被人工客服修改，也要保存修改前后差异。这样发生投诉时，企业能说明系统依据和人工决策。
观测指标包括首响时间、解决率、转人工率、错误政策引用、退款工具失败、用户满意度、每单成本和高风险动作确认率。AI 客服上线后，如果只看回答速度，会误判成功；真正要看的是是否解决问题、是否减少人工负担、是否保持政策一致。
常见误区
第一个误区是把模型能力当成架构能力。模型更强可以提升推理和表达，但不能自动提供权限、队列、审计、配额、缓存和观测。一个强模型在弱架构里，仍然可能越权、失控和无法追溯。
第二个误区是把网关理解成转发代理。模型网关不是反向代理换个名字，而是 AI 调用控制面。它要管理模型、密钥、路由、预算、日志、缓存、降级和策略。只做 URL 转发，无法解决生产问题。
第三个误区是所有任务都同步生成。同步适合低延迟交互，不适合长文档、批处理、复杂 Agent 和高风险动作。任务一旦需要等待、重试、人工确认或恢复，就应该进入队列和状态机。
第四个误区是缓存越多越好。AI 缓存必须尊重权限、数据版本、提示词版本和风险等级。错缓存比不缓存更危险。语义缓存只能用于答案稳定、风险低、边界清楚的任务。
第五个误区是把审计当作调试日志。审计要保存责任链，日志服务工程排查。两者可以共享请求 ID，但保存内容、权限、保留周期和查询方式不同。
第六个误区是让模型处理权限。模型可以解释权限结果，但不能决定权限。访问控制必须由后端、数据库、检索过滤和工具层执行。
第七个误区是只看模型错误率。AI 应用质量还包括检索质量、工具成功率、引用正确性、任务完成率、人工修改率、成本和延迟。模型返回成功不代表业务成功。
第八个误区是过早平台化。平台应来自多个业务场景的共性需求，而不是先做一个宏大的 AI 中台。先把一个真实场景做到可追踪、可控、可恢复、可评测，再抽象平台。
生产架构检查清单
- 是否有统一模型调用入口，能够记录模型、token、耗时、成本、错误和路由策略。
- 是否把供应商密钥集中管理，业务前端和普通服务不直接持有主密钥。
- 是否按租户、项目、用户、模型和任务类型设置配额、限流和预算预警。
- 是否区分同步请求和异步任务，长任务是否有状态、重试、死信和人工处理入口。
- 是否为工具调用设计权限、幂等键、参数校验、结构化返回和审计记录。
- 是否在 RAG 检索阶段执行租户和权限过滤，而不是把权限交给模型判断。
- 是否保存知识库资料版本、切分版本、embedding 模型版本和索引任务记录。
- 是否区分短期状态、长期记忆和业务事实，长期记忆是否可查看、可修改、可删除。
- 是否设计缓存键和失效规则，覆盖租户、权限、模型、提示词版本、知识版本和工具版本。
- 是否保存每次回答的检索证据、引用片段、模型版本、提示词版本和最终输出。
- 是否有 trace 串起入口、后端、检索、模型网关、工具、队列和数据库写入。
- 是否监控 token、成本、延迟、错误、队列积压、缓存命中、检索空结果和质量反馈。
- 是否把线上失败样本进入评测集，并在模型、提示词、检索策略变更后做回归。
- 是否对高风险动作设置人工确认、可解释摘要和回滚或补救路径。
- 是否能在模型供应商故障、限流、成本超额或知识库索引失败时给用户清楚反馈。
参考资料
- OpenTelemetry：Generative AI semantic conventions
https://opentelemetry.io/docs/specs/semconv/gen-ai/ - OpenTelemetry：Semantic conventions 概念说明
https://opentelemetry.io/docs/concepts/semantic-conventions/ - LiteLLM：Proxy Server / LLM Gateway 文档
https://docs.litellm.ai/ - Kong：AI Gateway 文档
https://developer.konghq.com/ai-gateway/ - Kong：Gateway rate limiting 文档
https://developer.konghq.com/gateway/rate-limiting/ - LangGraph：Durable execution 文档
https://docs.langchain.com/oss/python/langgraph/durable-execution - OpenAI：Prompt caching 文档
https://platform.openai.com/docs/guides/prompt-caching/overview - Anthropic：Prompt caching 文档
https://docs.anthropic.com/en/docs/build-with-claude/prompt-caching - Anthropic：API rate limits 文档
https://docs.anthropic.com/en/api/rate-limits - Google Cloud Vertex AI：Context caching overview
https://cloud.google.com/vertex-ai/generative-ai/docs/context-cache/context-cache-overview - Google Cloud Vertex AI：Generative AI quotas and system limits
https://cloud.google.com/vertex-ai/generative-ai/docs/quotas - Amazon Bedrock：Model invocation logging
https://docs.aws.amazon.com/en_us/bedrock/latest/userguide/model-invocation-logging.html - Apache Kafka：Design and message delivery semantics
https://kafka.apache.org/42/design/design/ - RabbitMQ：Reliability guide
https://www.rabbitmq.com/docs/reliability - RedisVL：LLM Cache / SemanticCache 文档
https://redis.io/docs/latest/develop/ai/redisvl/api/cache/ - LangGraph：Memory overview
https://docs.langchain.com/oss/javascript/langgraph/memory