一个生产级大模型应用通常怎么分层架构？

简化版

生产级大模型应用不能只有一个 prompt 和一次 API 调用，通常要分成入口层、编排层、模型网关、工具/RAG 层、状态存储、评测监控和安全治理层。这样才能把能力、成本、权限、质量和故障隔离开。

详细版

入口层负责鉴权、限流、参数校验和多端协议适配。
编排层负责 prompt 拼装、RAG、工具调用、多轮状态和降级策略。
模型网关负责多模型路由、重试、超时、成本统计和供应商隔离。
状态层保存会话、记忆、缓存、审计日志和业务上下文。
LLMOps 的核心是把不可完全确定的模型能力纳入可观测、可评测、可回滚的工程体系。

完整版教学

记忆钩子：大模型应用不是“接口转发器”，而是“有模型参与的分布式业务系统”。

一、分层是为了隔离责任与故障

生产级 LLM 应用至少分离入口鉴权、编排、模型网关、检索、工具执行、策略与观测。分层的目的不是画更多方框，而是让每个边界能独立限流、授权、版本化和回滚。

模型输出的不确定性只能留在明确边界内：它可以提出参数候选，不能直接成为权限事实；检索可以提供证据，不能改变系统指令；工具执行器只接受验证后的结构化动作。

二、核心原理和工程边界

LLM 应用的复杂度来自两类不确定性：模型输出不确定，外部依赖不确定。分层架构的目的就是把这些不确定性分摊到不同模块里处理：入口层管用户和权限，编排层管任务流程，模型网关管模型选择，安全层管边界，监控层管质量反馈。

三、带数字的工程算例

假设一个客服助手每天 10 万次请求，平均每次 3000 input token、800 output token。如果没有模型网关，模型升级、限流、成本统计和故障切换都会散落在业务代码里；一旦供应商超时率从 1% 升到 8%，排查会非常困难。

请求总成本 = input_tokens * 输入单价 + output_tokens * 输出单价
可用性 = 1 - 失败请求数 / 总请求数
生产级链路 = API 入口 + 编排 + 模型网关 + 工具/RAG + 监控评测

四、典型链路怎么跑

可以把这类问题拆成下面的链路来理解：

用户/业务系统
    |
API 入口：鉴权、限流、参数校验
    |
编排层：Prompt、RAG、Tools、Memory
    |
模型网关：路由、重试、超时、成本
    |
后处理：格式校验、安全过滤、审计
    |
观测评测：日志、指标、Trace、反馈

五、方案对比和选择标准

层次	职责	常见失败
入口层	鉴权、限流、协议	越权、流量打爆
编排层	任务流和上下文	prompt 混乱、状态错
模型网关	模型访问和治理	重试风暴、成本失控
观测层	质量和稳定性闭环	线上问题不可解释

六、上线后最容易出问题的地方

把所有逻辑塞进一个 prompt，会让权限、成本和故障处理都失控。
模型供应商接口稳定不等于业务稳定，业务还要处理超时、降级和输出错误。
原始用户输入与检索内容都应标为不可信数据，不能跨过编排层直接获得工具执行权。

七、同步链路与异步任务怎样分开

实时问答走有总 Deadline 的同步链路，长报告、批量处理和人工审批更适合提交任务后异步执行。异步任务保存不可变输入版本、operation_id 和幂等键，客户端通过状态接口或事件流获取进度。

两类链路不能共用无限等待的请求线程。异步 Worker 完成后仍需校验状态版本与用户是否取消，避免过期结果覆盖新任务。

八、常见误区与追问

误区：大模型应用就是前端加一个聊天框。 真实链路还包含身份、状态、检索、工具、策略、监控和回滚，任一层失败都会影响结果。
误区：只要模型能力强，架构就可以简单。 强模型仍会超时、幻觉和被注入，系统必须管理外部状态、权限与副作用。
误区：模型网关只是转发 API。 网关还负责模型路由、配额、重试、版本、凭证隔离、统一观测和协议适配。
追问：为什么 LLM 应用需要单独的模型网关？ 它把供应商差异和凭证从业务层隔离，并集中实施限流、路由、降级与审计。
追问：如何设计一次请求的 trace？ 用同一 trace_id 串起 Prompt 版本、检索文档、工具调用、模型 usage、阶段耗时和最终反馈。
追问：模型升级应该放在哪一层控制？ 由网关或发布控制面按版本路由，业务只依赖能力契约，便于灰度和快速回滚。

九、加强记忆

按“入口、编排、模型、工具、状态、观测、安全”七个词记。面试时先画层次，再讲每层处理什么不确定性，最后用成本和故障例子落地。

项目实战落地

项目里怎么做的

《AI Agentic RAG高级企业知识库平台》的后端按职责分成五个包，每个新功能都沿着「建表 → models/ → service/ → api/ → 页面」这条链路落地：

包	只做什么
`api/`	接收参数、调用 service、返回统一的 `Result`，一个业务域一个文件
`service/`	参数校验、业务规则、默认值、跨表逻辑
`ai/`	全部与大模型、检索、Agent、评测相关的代码：模型工厂、Prompt 加载、检索、状态图、评测
`models/`	数据表结构定义
`common/`	统一返回、认证、异常处理

在这个分层之上，项目把「会反复调的东西」放进数据库：模型接入在 ai_model_config，Prompt 在 prompt_template，切分策略在 chunk_strategy，检索策略的 7 个开关在 retrieval_strategy，工具清单在 function_tool。编排层有两条链路：步数由检索策略配置决定的直线链路，和步数由模型决定的 Agentic 链路，靠问答应用上的 qa_app.agent_enabled 一个开关切换，同一个知识库上可以直接对比两种模式。

《AI Agent旅游行程智能规划平台》把模型访问收成一个类：AiChatService 是项目里唯一直接调用模型的类，按用途取配置、单轮对话、向量化、报错翻译和调用日志都在这里，业务代码只调它。

为什么这样取舍

模型相关的代码单独一层。 模型工厂、Prompt 加载、检索和状态图都在 ai/ 里，api/ 和 service/ 不直接碰模型对象，换模型、换 Prompt 只动配置和这一层。
放进数据库的标准是「会不会反复调」。 模型、Prompt、检索参数、工具开关都是要反复调的，改一次就重启服务不现实；不会变的东西留在代码里。
链路切换做成开关。 直线链路和 Agentic 链路共用同一套知识库和落库结构，一个开关就能在同样的数据上比较效果和耗时。

面试官还会追问

知识库的文档数、片段数这类统计数字，为什么每次都重新 count，而不是在增删时加一减一？
检索策略里关掉「查询改写」之后，为什么还要把改写方式的字段清空？

学完《AI Agentic RAG高级企业知识库平台》，上面这些追问你都会迎刃而解。

简化版

详细版