#LLM 应用分层架构

#1. 提出问题

一家 B2B SaaS 公司准备把 AI 放进客服后台。客服每天处理企业客户的工单：阅读用户描述、识别问题类型、查询订单和发票、检索内部知识库、生成回复草稿，必要时创建退款申请或转给财务。

没有 AI 时，客服依赖后台表单、知识库搜索和固定话术模板。平均每个工单 6 到 8 分钟，最慢的不是打字，而是在多个系统之间定位事实、确认权限、避免说错承诺。团队希望 AI 先帮客服生成草稿，后续再逐步接入查询工具和低风险自动化。

这个需求听起来像“做一个客服助手”，但真实输入和失败样本更复杂：

如果只写一个后端接口 POST /ai/reply，里面拼 prompt、查数据库、调用模型、解析结果、执行工具，早期看起来最快。问题是，一旦要换模型、加权限、做路由、接入工具、记录审计或复盘事故，这个接口会迅速变成不可维护的黑箱。

#2. 分析问题

这个客服助手不是一个“生成”问题，而是多个任务组合：

模型擅长理解自然语言、压缩信息、生成解释和在多个候选动作中给出建议。它不应该负责租户隔离、退款规则、状态持久化、审计留痕和最终权限判断。

分层的收益来自把变化隔离开：

• 业务规则会频繁改，不能散落在 prompt 文本里。
• 模型和供应商会替换，不能被业务代码深度绑定。
• 工具能力会扩展，不能让模型直接接触内部 API。
• 上下文会越来越多，不能把所有状态都塞进消息历史。
• 线上事故需要复盘，不能只保存最终回答。

风险也很直接：分层过早、过重，会拖慢验证速度；分层过晚，系统会在第一次上线扩容、第一次模型替换、第一次合规审计时付出更高代价。所以架构判断不是“要不要分层”，而是“当前阶段需要分到什么程度”。

#3. 列举方案

LLM 应用分层可以从简单到复杂逐步升级。

第一层是单次 prompt 调用。适合低风险、输入固定、用户会编辑的场景，例如内部客服话术润色。它的成本最低，但没有稳定结构、权限边界和复盘能力。

第二层是 prompt 模板 + schema。适合需要稳定输出的分类、抽取和草稿生成。模板管理变量，schema 约束输出，程序负责校验、重试和错误提示。这时仍然可以不做复杂平台。

第三层是应用服务层。业务流程在这一层表达：工单是否允许 AI 辅助、当前用户能看哪些字段、哪些输出只是草稿、哪些动作需要审批。应用服务层不应该关心某个模型的细节，也不应该把业务权限交给 prompt。

第四层是上下文组装层。它决定当前模型调用能看到哪些消息、业务对象、知识片段、用户状态和工具结果。上下文组装层要做权限过滤、去重、优先级、预算控制和来源标记。

第五层是模型访问层或模型网关。它统一处理模型选择、参数、超时、重试、降级、成本归因、日志脱敏和供应商差异。只有当团队开始多模型、多场景或需要统一观测时，这一层才有明显收益。

第六层是工具运行时。模型可以建议或触发工具，但运行时负责参数校验、鉴权、确认、幂等、超时、重试和审计。工具层把“能做什么”和“是否允许做”分开。

第七层是工作流编排。多步骤、可恢复、可审计的业务流程不应该靠模型从聊天历史里临场推断。工单升级、退款申请、财务审批这类流程需要状态机、人工队列和补偿路径。

第八层是 Eval + Ops。进入生产后，团队需要样本集、回放、模型版本、prompt 版本、工具调用日志、质量指标、成本延迟监控和异常告警。

简单 prompt 足够的条件是：输入短、风险低、输出可编辑、失败不进入下游系统、调用量不大。prompt 不再足够的信号是：输出要入库、需要引用证据、需要访问业务数据、需要执行动作、需要复盘、成本延迟开始影响核心流程。

#4. 决策判断

分层时有几个关键判断。

第一，业务规则应该留在业务层。prompt 可以解释规则，但不能成为唯一规则来源。比如“退款超过 5000 元必须主管审批”应该由业务系统判断，而不是靠 prompt 记住。

第二，模型访问应该尽量被隔离。业务代码关心任务目标和质量要求，不应该到处散落模型名、temperature、供应商错误码和重试逻辑。

第三，上下文不是数据库。当前调用需要的上下文可以进 prompt，长期状态、审批记录、工具结果和用户记忆应该有结构化存储。

第四，工具不是普通函数暴露。只要参数由模型生成、工具会访问业务数据或产生副作用，就必须有运行时边界。

常见反模式：

• 把所有逻辑塞进一个 prompt，导致业务规则不可测试、不可审计。
• 在业务代码里硬编码模型供应商，后续路由和降级困难。
• 把知识库、用户画像、工具结果和历史聊天全部拼成一段上下文，既昂贵又难复盘。
• 用 Agent 包装固定流程，让本来可控的工单处理变成不可预测路径。
• 只记录最终回复，不记录 prompt 版本、上下文摘要、模型、参数和工具调用。

#5. 结论收束

LLM 应用分层的目标不是把系统做复杂，而是让责任边界清楚：业务层决定流程和权限，上下文层决定模型看什么，模型层负责生成和判断，工具层负责受控执行，工作流层负责状态流转，运营层负责评估和复盘。

最低可上线版本可以很轻：一个应用服务、少量 prompt 模板、结构化输出校验、受控上下文和完整日志。只有当模型选择、工具执行、多步骤恢复或成本治理成为真实问题时，再升级到网关、工具运行时和工作流平台。

上线前检查项：

• 场景边界：使用者、业务流程、输入输出和失败代价是否明确。
• 分层职责：业务规则、上下文、模型调用、工具执行、工作流状态是否分开。
• Prompt 资产：模板、变量、版本和变更记录是否可管理。
• 结构化输出：schema、校验、重试、降级和错误提示是否完整。
• 上下文治理：来源、权限、时间、优先级和 token 预算是否可控。
• 模型接入：超时、重试、降级、成本归因和供应商错误是否统一处理。
• 工具边界：参数校验、鉴权、确认、幂等和审计是否覆盖。
• 人工确认：高风险动作是否展示依据、预览和确认入口。
• 可观测性：是否记录模型、参数、prompt 版本、上下文摘要、工具调用和最终输出。
• 评估体系：是否有样本集、回放机制、线上反馈和回归测试。