在构建需要承载真实流量、服务真实用户的AI应用时，

如何组织LLM调用，比选用哪个模型更重大。

许多团队只有在演示环境完美运行的系统，上线后开始崩溃时，才会清楚这一点。

大多数规模化失败，并非由于模型“不够机智”，而是源于糟糕的流程编排。

• 设计良好的工作流，能让一个合格的模型变成可靠的系统。
• 设计糟糕的工作流，即便最先进的模型也会输出不稳定、不一致的结果。

本文介绍工程团队在生产环境中真正在用的5种模式，覆盖初创公司到大型企业。

每种模式解决一类特定问题，有明确的优缺点，也都可以用LangGraph等工具实现，具体实现我会在另一篇博客中讲解。

什么是LLM工作流？

LLM工作流，是用户请求到最终响应之间的一系列执行步骤。

最简单的情况只有一步：
把提示词发给模型，拿回结果。
但在生产系统中，几乎从来没这么简单。

一个工作流一般包括：

• 在调用模型前检索相关文档
• 将复杂任务拆成更小的任务并分别处理
• 将不同类型的请求路由给不同处理器
• 使用多个模型相互校验、优化输出

工作流是你编码应用逻辑的地方：决定模型需要什么信息、如何结构化任务、如何处理边缘情况。

做对了，系统会更稳定、更准确、更实用。
做错了，你就会一直调试不稳定行为，跟用户解释“为什么同样的问题，答案有时不一样”。

下面这些模式，是从原型走向生产时，经过验证的工作流设计方案，每种都对应一类真实挑战。

1. 检索增强生成（RAG）：让模型基于实际说话

生产级LLM系统最基础的模式就是
检索增强生成（RAG）。它解决一个核心问题：

• 大模型有知识过期日期，且会编造实际。
• 把模型连到你的数据源，就能让它获取最新、准确的业务信息。
• 同时节省时间与算力。

工作原理

RAG系统按顺序包含三个模块：

1. 用户查询进来，系统将其转为能表达语义的数值表明（嵌入向量）。
2. 在向量数据库中，通过向量类似度搜索，找到与查询语义最相关的文档或文本块。
3. 将Top检索结果与原查询拼进提示词，模型基于这些真实上下文生成回答。

真实示例

假设你是一家软件公司的客服聊天机器人。
用户问：“如何为团队配置单点登录（SSO）？”

没有RAG，模型可能只会给出通用的SSO概念讲解。
有了RAG，系统会从你们的官方文档里检索出具体的配置指南，模型基于这份真实资料生成回答。

适用场景

应用需要引用特定、会随时间更新的实际信息时：
文档助手、客服机器人、法律检索、医疗信息系统等。

生产注意事项

• 分块策略至关重大：块太小丢上下文，太大稀释相关性，主流在500–2000 token之间实验。
• 提议加重排序（reranking）：先用类似度召回候选，再用重排序模型按真实相关性打分，两阶段精度提升明显。
• 检索会增加延迟，需要维护数据库并保持数据更新。
• 实践中，只要把检索层当成核心系统而非附加功能，RAG一般都值得投入。

2. 提示词链：把复杂任务拆成步骤

有些任务太复杂，一次LLM调用搞不定。
提示词链（Prompt Chaining） 将任务拆成一连串小步骤，每一步都基于上一步的输出。

工作原理

不要求模型一次性产出所有内容，而是拆成专注的序列：

1. 生成大纲：只做结构化梳理。
2. 校验大纲：检查缺失、逻辑、清晰度。
3. 写引言：基于大纲只写开头。
4. 逐节生成正文：每节独立生成，降低过载，可并行。
5. 校验并组装最终结果：应用规则、重试失败步骤、合并全文。

每一步都是独立LLM调用，上一步输出是下一步输入，更容易控制、调试、优化。

真实示例

营销内容生成系统，用户要一篇关于新功能的博客。

1. 第一步生成3个写作角度。
2. 第二步把选中角度扩成完整大纲。
3. 第三步逐节写内容。
4. 第四步生成元描述和社交短文案。
5. 第五步检查品牌语气一致性。

任何一步不达标，只重试该步，不用从头再来。

适用场景

任务有天然断点、流程可预测时：
文档生成、代码审查、数据转换 pipeline 等。

生产注意事项

• 设计可重试、可降级的链条：一步失败能否只重试这一步？能否降级到简单方案？
• 可并行的步骤尽量并行，降低延迟。
• 缺点：每一步都是一次API调用，延迟更高、系统更复杂，需要精细的错误处理。
• 但对那些单提示词难以搞定的复杂任务，可观测、可调试、可重试的链式结构价值巨大。

3. 路由：把请求发给正确的处理器

不是所有查询都需要同一种处理方式。
路由（Routing） 用分类器，根据请求内容，把流量导向专门的处理器。

工作原理

先判断请求类型，再发给对应模块：

1. 分析 incoming 查询：理解意图与分类。
2. 对请求分类：

• 简单场景：关键词/规则匹配
• 进阶：嵌入向量或轻量分类器
• 复杂：用LLM做路由决策

3. 选择合适处理器：发给专用工作流、模型或工具集。
4. 执行对应流程：每个路径都有专属提示词、数据源、约束，为该类请求优化。

这样，每个请求都由最合适的 pipeline 处理，而不是所有查询挤在一个通用系统里。

真实示例

客服系统的路由：

• 账单问题 → 走账单文档RAG pipeline
• 技术问题 → 走可查日志、做诊断的工作流
• 账号管理 → 走可操作数据库的Agent
• 投诉 → 走带升级流程的专用处理器

每条路径用不同工具、不同提示词、甚至不同模型：
简单问题用更快、更便宜的模型；复杂问题上更强推理的模型。

适用场景

应用处理多样查询类型、需要不同资源时，也用于成本优化：简单查询用便宜模型，复杂查询上高配。

生产注意事项

• 路由本身是关键组件：分错类，整个流程就错了。
• 监控路由准确率，设置兜底路径：不确定时发给通用处理器，不要乱猜。
• 可做多级路由：高速路由初分，置信度低时再用更准但慢的路由终审。
• 做得好：单体系统变高效、专业化；做得差：变成脆弱单点，拖垮整体体验。

4. 调度器-工作器：动态任务拆解

有些问题无法提前拆解，子任务完全取决于具体输入。
调度器-工作器（Orchestrator-Workers） 用中央Agent分析请求，拆分子任务，分发给专用工作器。

工作原理

不按固定流程走，而是动态拆分：

1. 调度器分析请求，明确要做什么。
2. 拆分子任务：每个输入的子任务都可能不同。
3. 分发给专用工作器：每个工作器只专注一类工作。
4. 并行执行任务。
5. 调度器/合成器合并结果，输出最终响应。

步骤数量与顺序不固定，多工作器可协同产出单一结果，比提示词链更灵活，比简单路由更协作。

真实示例

代码生成工具收到：“给这个代码库加用户认证。”

调度器分析代码结构，确定需要：

• 找到用户模型定义
• 识别已用的认证库
• 找到登录/注册路由
• 检查现有中间件模式

然后为每个任务启动工作器：
一个找模型，一个查依赖，一个看路由。
所有工作器返回后，调度器掌握全貌，再生成合适的认证代码。

适用场景

任务随输入剧烈变化时：
代码修改、复杂研究、多步骤问题求解。

生产注意事项

• 调度器必须有明确停止规则，否则可能无限开工作器。
  常用方案：设置最大迭代次数，或要求调度器显式声明完成。
• 可用独立评估器判断结果是否达标。
• 上下文管理关键：每个工作器只给必要信息，避免全量历史浪费token。
• 模式强劲但不宽容：支持多变任务、可并行，但灵活性带来实现复杂度。停止条件没设好，生产环境会出现死循环。

5. 评估器-优化器：迭代式精调

有些输出需要多轮改善才够好。
评估器-优化器（Evaluator-Optimizer） 用两个模型形成循环：一个生成，一个评估并给出反馈，直到满足质量标准。

工作原理

1. 生成模型产出初始结果。
2. 评估模型按明确标准打分，给出详细修改意见。
3. 生成模型根据反馈修改。
4. 循环直到评估通过，或达到最大迭代次数。

真实示例

高要求文档翻译：
第一轮翻译 → 评估器检查准确性、语气、文化适配、术语一致，标出需修改片段 → 生成器修正 → 评估器再检查。

代码生成同理：
生成函数 → 评估器检查正确性、效率、规范 → 生成器重构 → 直到通过所有检查。

适用场景

质量 > 速度，且能定义清晰评估标准时：
专业翻译、技术写作、代码生成、复杂分析。

生产注意事项

• 最重大：何时停止。设最大迭代次数，避免死循环。
• 给评估器明确的通过/不通过标准。
• 延迟是主要代价：每轮迭代都增加耗时。
  可异步跑循环，完成后通知用户；或先给一版结果，后台继续精调。
• 能说清“什么是好”，这个模式才好用；没有清晰标准，循环就变成昂贵的试错。

如何选择合适的模式

这些模式并非互斥，生产系统常常组合使用。

• 路由可以把技术查询发给带RAG的调度器-工作器系统。
• 评估器-优化器可以放在最后精调输出。

快速决策指南：

• 需要实际、实时信息？用 RAG。
• 任务可拆成固定步骤？用 提示词链。
• 请求类型多、要差异化处理？用 路由。
• 流程随输入动态变化？用 调度器-工作器。
• 追求高质量、可定义标准？用 评估器-优化器。

组合思路：

• 简单查询太贵？在现有模式前加路由。
• 质量不稳定？在现有流程后加评估器-优化器。
• 既要实时数据又要多步推理？RAG + 链 / 调度器。

从最简单、能解决问题的模式开始，有明确证据后再加复杂度。
一个稳定可用的简单RAG，远胜于一个复杂但不可预测的多Agent系统。

目标不是做最复杂的系统，而是做稳定解决问题的系统。

落地实施实践

无论用哪种模式，以下实践都能帮你成功：

1. 全链路埋点监控：跟踪每一步延迟、token用量、错误率、质量指标。
2. 为失败而设计：LLM会报错、幻觉、超时。每一步都加重试、降级、兜底。
3. 积极缓存：类似查询许多，缓存响应或中间结果可大幅降本提效。语义缓存能识别同义问法，部分场景可减少70% API调用。
4. 从小开始，逐步扩展：先单点场景、单模式，稳定后再迭代。
5. 用真实数据测试：合成基准测不出真实用户的混乱查询。重点分析失败案例，它们告知你该优化哪里。

结语

构建可扩展AI方案，关键不在选对模型，而在围绕模型设计对的系统。

• RAG：让系统基于实际。
• 提示词链：把复杂变可控。
• 路由：让流量高效分发。
• 调度器-工作器：动态处理多变任务。
• 评估器-优化器：用迭代保证质量。

每种模式都在生产中规模化验证过，每种都解决一类真实问题，每种都能用现有工具实现。

从简单开始，全面度量，渐进式优化。
模型会越来越强，但工作流设计只会更重大。
早期做对这件事的团队，会少救火、多建设。