LLM 应用架构专题总览
LLM 应用架构不是把一次模型调用包成一个接口，也不是在业务系统旁边加一个聊天窗口。真正进入生产以后，团队会遇到更具体的问题：
- 客服助手什么时候只生成回复草稿，什么时候可以查询订单，什么时候必须转人工？
- 不同模型价格、延迟和质量差异很大，应该在业务代码里到处写 if，还是做统一网关？
- 用户状态、会话历史、知识库片段、工具结果和审批记录，到底哪些应该进 prompt，哪些应该留在业务系统？
- 模型输出错了以后，能不能知道它看到了什么、调用了什么、为什么做出这个判断？
这个专题聚焦进阶材料第 1 类：LLM 应用架构。目标不是堆技术名词，而是帮助读者建立一套工程判断：什么时候简单 prompt 足够，什么时候需要结构化输出、上下文工程、模型网关、工具运行时、工作流和评估体系。
适合谁阅读
本专题面向已经做过基础 LLM API 调用、准备把 AI 能力放进真实产品的人：
文章地图
专题主线
LLM 应用常见的架构失控，通常不是模型本身突然变差，而是边界不清：
- prompt 里混进业务规则、权限逻辑和工具结果，后续无人知道哪些内容是事实。
- 业务代码直接依赖某个模型返回格式，换模型、降级或重试都会牵一发动全身。
- 每个功能各自调用模型，成本、延迟、错误和评估无法统一归因。
- 工具可以读写真实系统，但缺少确认、审计、幂等和回滚。
- 会话历史越堆越长，状态却没有结构化存储，任务失败后不能恢复。
本专题的判断顺序是：
- 先看业务流程，不从模型能力出发。
- 再拆任务类型，区分分类、抽取、生成、检索、判断、规划和执行。
- 再选择最小可用方案，不默认上 Agent、网关或复杂工作流。
- 一旦进入生产，就补齐评估、观测、权限、成本和恢复。
最低可上线架构
一个可上线的 LLM 应用，至少应该回答这些问题：
- 场景边界：谁使用、在什么流程里使用、输入输出是什么、失败代价是什么。
- 应用分层：业务规则、prompt、上下文组装、模型调用、工具执行和审计分别在哪一层。
- 模型接入：模型、参数、超时、重试、降级和成本是否可配置、可观测。
- 状态边界：业务状态、会话摘要、用户记忆、工具结果和临时上下文是否分开管理。
- 工具边界：模型能调用哪些工具，参数如何校验，哪些动作需要人工确认。
- 质量闭环：是否有样本集、回放日志、人工反馈、回归测试和线上监控。
如果这些问题都还没有答案，继续增加更长 prompt、更强模型或更多工具，通常只会把不确定性推迟到线上。