做生成式AI应用大半年我从最初“prompt凑一凑就能上线”的乐观到被线上badcase反复教育再到慢慢沉淀出一套能复用的方法论最大的转折点就在于我开始用软件工程里的“设计模式”思路去重新审视LLM应用的设计。这个系列第一篇我先不聊具体的算法调参而是把我认为最值得先装进脑子里的三个维度的AI设计模式——提示策略、编排架构、反馈闭环——拆开讲透。如果你正在做ChatBot、Agent、RAG类项目或者刚把大模型接进业务系统、却总感觉输出不稳定、场景一换就崩这篇文章应该能给你一套真正可落地的思考框架。1. 为什么生成式AI也需要自己的设计模式1.1 从GOF到生成式AI模式思想的一脉相承经典软件设计模式GOF那23种解决的核心问题是“对象之间如何协作才不至于把代码写成一坨”。它把反复出现的场景抽象成可复用的结构让后来者不用每次从零开始踩坑。我一直觉得生成式AI应用设计现在面临的问题和当年面向对象编程刚普及时候极其相似——工具能力很强但大多数人不知道该怎么把这种能力稳定、优雅地组合起来。生成式AI设计模式本质上就是对这些反复出现的组合方式做命名和提炼。它不关心某个具体的prompt技巧而是关心更大的结构问题模型在系统里承担什么角色上下文怎么流动工具调用怎么编排错误怎么回退结果怎么校验这些问题的答案经过多个项目的验证后会形成一套类似“模板”的解法就是我们说的AI设计模式。1.2 没有模式的AI应用会踩哪些坑我先列举几个自己做项目时真实遇到、也经常在同行交流里被反复提起的痛点输出不可控同样的用户问题早上回答正常下午换了模型小版本就胡言乱语。没有约束和校验机制线上事故迟早会来。上下文管理混乱对话一长就把关键指令“挤”出窗口或者把无关历史一股脑塞进去成本和效果双双崩盘。工具调用缺乏兜底模型在函数调用时选错参数、陷入循环如果没有超时、重试、人工接管机制整个流程就卡死。质量评估靠感觉改了一句prompt感觉变好了但没有量化对比上线后就出问题回滚都不知道该回到哪个版本。这些问题的共性是它们都不是“换个模型、改个prompt”就能解决的而是系统结构层面的问题。设计模式这个工具正当其时。2. 提示策略类设计模式先让模型把话说对2.1 示例模式Few-Shot给模型一面镜子Few-Shot少样本示例可能是大多数人最先上手的模式但真要用好它比想象中讲究。它的核心原理是在prompt里给出若干个“输入-输出”对相当于给模型一面镜子让它按照示例的格式、口吻、推理粒度来回答。我在实际项目里的经验是示例数量不是越多越好。对于大多数任务3到6个高质量示例的效果就足够好超过7到8个之后收益递减反而会挤占上下文空间。更重要的是示例的“分布”要覆盖典型的边界情况而不是只挑好看的样本。比如做意图识别示例里除了“查询订单”“申请退款”一定要放一到两个“随口闲聊”之类的负样本否则模型会把什么都分类成业务意图。示例格式也很关键。同一个任务示例之间如果格式不统一模型就会“学坏”。建议把示例的输入输出用固定标签比如“用户”“助手”明确分隔并保持一致。我通常会先在纯文本格式上调稳再改成JSON等结构化输出避免一上来就纠结复杂格式问题定位会很困难。2.2 思维链模式Chain of Thought逼出推理过程思维链模式CoT的原理一句话讲在要求模型回答之前先让它把推理步骤写出来。这个模式的价值已经在很多推理任务上被验证过——尤其是数学、逻辑、多跳问答这类“中间步骤决定结果”的场景。它的本质是引导模型把隐式的思考过程显性化减少跳步带来的错误。触发方式有两种显式和隐式。显式就是在prompt里直接写“请一步步分析”或者“先思考再回答”。隐式则是在示例里体现推理过程模型会模仿这种风格。实测中显式触发对复杂任务更稳定但需要注意不要让思维链变成“过度自嗨”——模型可能编造出一个看似合理的推理过程但结论依然是错的。我的做法是对关键结论同时要求给出依据来源或中间计算结果方便人工校验。使用CoT时采样参数也要相应调整。推理类任务我一般把temperature调到0.2到0.4之间既能保留少量多样性又不至于让推理路径飘得太远。做创意生成类任务才需要拉高温度这两种场景的目标函数完全不同混用会两头不讨好。2.3 自一致性模式Self-Consistency用投票对抗随机性如果说CoT是“把推理过程写出来”自一致性就是更进一步让模型多次推理把结果汇总后投票选最一致的答案。这个模式利用了LLM的采样随机性——单次回答可能陷入局部错误但多次推理的共识往往更接近正确。实操中我会用同一个prompt跑5到10次每次temperature设置在0.4到0.7之间让模型有一定探索空间然后对最终答案聚类。聚类方式可以很简单完全匹配或者用另一个LLM判断语义等价。这里有个容易被忽略的点投票次数不是越多越好。我测过大约10次之后答案质量提升就开始放缓但token成本还在线性增长。一般5到8次是性价比最优区间。自一致性适合离线或准实时的场景比如生成训练数据、自动批改、内容审核意见汇总。在线场景如果延迟敏感不太建议直接用可以用下面要讲的编排模式来降频。3. 编排架构类设计模式从单次对话到系统工程3.1 检索增强生成RAG让模型先查资料再开口RAG已经是生成式AI应用的地基级模式。它的核心思路很简单外部知识先检索再把检索结果拼进prompt让模型基于这些材料生成答案。直接靠模型“背”知识是不靠谱的训练数据有截止日期专业领域更是一问三不知RAG就是给模型接上外部记忆。但实现RAG的坑非常多。先说分块块太小容易断章取义块太大则可能混入无关信息、稀释相关性。我一般按语义完整性来切块而不是死抠固定字数通常200到500个token一个块比较通用特殊文档比如表格、法律条款需要考虑结构边界。向量模型这块我的建议是不要迷信“最新最强”先用通用模型跑通链路再根据领域数据评测后再考虑替换。检索参数里最常调的是top-k我一般从4到8开始测配合重排序rerank来提升命中率。集齐这三个参数检索效果的优化就有抓手了。这里要特别强调检索质量直接决定生成质量。这个优先级的理解Project里越早越好——如果检索结果本身不相关prompt写得再精致模型也只能在错误材料上“无中生有”这正是RAG项目最常见的badcase来源。3.2 ReAct模式让模型动起来ReActReasoning Acting模式是让模型在“思考”和“行动”之间循环的架构模式模型根据当前状态决定下一步是继续推理、还是调用工具查询信息然后根据工具返回的观察结果更新判断直到得出结论。这在需要实时信息、多步操作的任务里特别有用比如查航班、订酒店、操作数据库等。和纯CoT相比ReAct的关键区别是“外部反馈”——推理的中间结果可以调用工具验证而不是单纯靠模型内部的知识封闭推导。这个外部反馈极大地减少了幻觉累积的链条断裂问题但也引入了新的复杂度工具调用的参数格式错误、循环不终止、工具返回数据超时都需要额外处理。一个可参考的实现骨架大致如下def react_agent(query, max_steps5): messages [{role: user, content: query}] for step in range(max_steps): resp llm.chat(messages, toolsTOOLS) if resp.is_finish(): return resp.content # 解析工具调用 tool_name, args parse_tool_call(resp) result run_tool(tool_name, args) # 把结果作为“观察”塞回对话 messages.append({role: tool, tool_call_id: resp.tool_call_id, content: result}) return 达到最大步数人工介入这里最关键的是max_steps设置。我在生产环境一般设置3到6步超过即终止并转入人工。不要天真地以为模型会在几步内收敛真实场景中工具返回了多个候选结果模型很可能想挨个尝试一遍必须由系统强制兜底。3.3 计划-执行模式Plan-and-Execute先想清楚再干ReAct适合步骤交互频繁的场景但如果你让它全程自主决策做一个大型任务比如“分析这份财报并生成一份PPT”模型会在中间反复试错token消耗巨大且容易失控。计划-执行模式把过程改成两段式先让模型生成一份完整计划比如1到N个步骤然后逐步执行、逐步校验。这个模式带给我最大的好处是可控性。计划可以先展示给用户确认用户认可后再开始执行执行中每个步骤都有独立的输入输出可以单独评测。代价则是灵活性下降——如果前置步骤的结果和计划预期不符整个计划可能需要动态调整。理想的设计里会在执行环节引入一个“再规划”的检查点允许模型在必要时修改剩余计划。计划-执行模式特别适合内容生产、数据分析报告、多文档处理这类“流程相对固定、但单步粒度很大”的任务。和ReAct做个粗略对比维度ReActPlan-and-Execute适用场景工具调用密集、实时信息长流程、多步骤、任务型灵活性高动态决策中先计划后执行可控性中依赖终止条件高用户可参与审批成本中高循环调用计划部分占大头坑死循环、参数乱传计划脱离实际、中途失效3.4 多智能体模式让模型们协作严格来说多智能体是编排架构上更上层的一种组合模式。它的思路是让多个拥有不同角色、不同系统提示词的LLM实例分工协作。比如一个“规划者”负责拆解任务“执行者”负责干活“评审者”负责把关。每个智能体都有自己独立的上下文和状态通过消息传递协作。这种模式最直观的价值是角色隔离。评审者不会受到执行者推理路径的影响能更客观地发现错误执行者也不会被评审者的风格带偏。代价则是成本和延迟的成倍增加而且多智能体之间的协调本身可能产生新的失败点。就我目前的实践经验大多数项目用单智能体加上严格的反馈闭环就足够了多智能体更适合“任务边界清晰、子任务之间相对独立”的场景。4. 反馈闭环类设计模式让模型学会自我修正4.1 反射模式Reflection自己检查自己反射模式是让模型对自己输出的内容进行审视、批评和修正。常见做法是在第一次生成之后附加一轮指令如“请检查你刚才的答案找出可能的错误或不完整之处并给出改进版本”。这个模式在代码生成、文本润色、结构化转换等场景里效果明显。比如让模型写一个Python函数第一版可能存在边界条件遗漏反射一轮后往往能补上。要注意两点一是反射目标和修改权限要限定避免模型在“修正”时改动了原本正确的内容二是反射不能无限递归一般最多两轮第三轮的收益趋近于零还会把答案改得四不像。成本上一轮反射约等于两次输入token需要算清楚账。4.2 独立评审模式Critic换个“人”来挑刺反射模式最大的隐患是“自我催眠”——模型会在自己的推理路径上越走越自信甚至把低级错误合理化。独立评审模式的思路是引入一个独立的评审角色让它在不看原推理过程的情况下仅根据任务要求、原始输入和模型输出进行评判。这个评审智能体有自己的系统提示词不受生成智能体的上下文污染。我用这个模式做了个小实验同一篇技术文章摘要自我反思只改动了格式而独立评审找出了两个关键数字的错误。原因不难理解独立评审相当于一次“换角度重看”它更接近读者的视角。实际落地中可以让评审智能体输出结构化建议错误列表、严重级别、修改建议然后由主智能体或人工决定是否采纳。如果业务对准确率要求高可以考虑用更强的模型做评审者即使生成端模型较弱整体效果也能得到明显提升。4.3 评估驱动模式Eval-Driven把prompt当代码来迭代前面几个模式解决的是单次运行内的质量评估驱动模式解决的是长期迭代中的“回归”问题。说白了就是给prompt和整个Agent流程建立自动化测试集每次改动都跑一遍分数用数据说话。建eval集是这里最核心也最花时间的部分。我建议从三个来源收集样本线上真实用户问题脱敏后、历史badcase、模拟边界情况。第一批不需要太多20到50条就够用了但必须有人工标注的“标准答案”。评估方式可以有两类一是规则判断字段格式、关键词、可执行性二是LLM-as-Judge让模型打分。初始阶段可以先让另一个大模型打分但最终一定要抽一部分人工复核防止评估器本身有偏好。一旦跑通这套流程再改prompt或者换模型版本时就不会两眼一抹黑。我在自己项目里把这套东西简称为“Prompt的CI/CD”——改动前先跑基线记录分数改动后再跑同一套集合并对比。这个习惯让我至少避免了三次上线后才发现效果倒退的事故。5. 实战案例把三种模式组合起来的客服问答Agent纸上谈兵多了容易飘我拿一个实际做过的客服问答Agent来串一遍。这个系统同时使用了RAG、ReAct和评估驱动三类模式算是比较典型的结构。任务背景某SaaS产品需要做一个客服机器人覆盖产品使用问答、账号问题、工单创建三类需求且要求最终可以无缝转接人工。整体架构简化为四层入口意图分类先用一个低温度0.1的轻量分类调用把用户输入分为“问答咨询”“账号操作”“闲聊”三类。这一步成本低能有效防止后续高成本流程被无关对话触发。RAG主链路对于问答咨询走检索增强生成。知识库切块约300 token向量检索取top-8加一轮重排序后保留top-4。这一步确保回答能定位到正确文档。ReAct工具链路对于账号操作走多步工具调用。提供查订单、查账号状态两个工具max_steps设为4超时转人工。反馈闭环对所有生成结果统一过一次“答案校验”。校验规则包括是否引用了知识库片段、答案长度是否合理、是否包含兜底联系方式。不满足则强制进入人工会话。上线后把每周badcase沉淀到eval集跑回归对比再决定下一轮优化方向。这个案例里三个维度的模式各司其职提示策略让每一步的模型输出更稳定编排架构把不同任务分派到合适的流程里反馈闭环保证整体质量可控。想表达的核心观点是设计模式不是某一个神奇模板而是一套系统性的取舍方法。真正难的不是知道这些模式而是知道什么场景该组合它们、如何设置参数。6. 常见问题与排查技巧实录6.1 思维链模式下模型输出又长又啰嗦这个几乎是必然遇到的。一旦prompt里写了“请一步步分析”模型会有可能对简单问题也写出几百字的推理过程既浪费token又影响体验。我的做法是在prompt里明确“只输出关键步骤不要解释无关细节”必要时限制输出长度最终答案通过后处理截断。更稳妥的办法是让模型先输出JSON结构其中包含“reasoning”和“answer”两个字段再由系统层决定是否展示推理部分。6.2 RAG检索不到关键内容答案质量上不去大多数情况不是模型问题而是检索链路问题。可以按顺序排查先看分块是否把关键信息切断了再看embedding模型在领域数据上的表现再看top-k是否太小、重排序是否引入偏差。我遇到过的最隐蔽问题是用户问题的说法和知识库原文差异很大向量检索召回率看似还行但关键片段排序太靠后被top-k截掉了。解法是增加一个“关键词-语义”混合检索或者把top-k调大后模型压不过噪音。这种问题靠Prompt很难解决必须回到检索侧修。6.3 ReAct循环不终止工具调用反复失败先说系统侧兜底max_steps和超时一定要配。脚本里很容易只配了max_steps而忽略工具本身的超时时间结果工具接口卡住整个循环挂在那。再说模型侧调试工具描述要写得像函数文档一样严格参数名、类型、约束、示例都要写清楚。还有一个容易被忽略的坑模型在工具返回内容为空时会反复调用同一个工具需要在工具描述里说明“无结果时不要重复查询直接告知用户未查到”。6.4 Prompt多次修改后效果忽好忽坏几乎每个做LLM应用的团队都会遇到这个问题。症状是你改了一个细节A场景效果变好B场景却变差了但你完全没意识到因为B场景没有在你的验收清单里。解法就是我前面说的评估驱动模式把改动前和改动后的版本都跑一遍固定eval集对比各项指标。没有这个机制所有的prompt优化都像是蒙眼在迷宫里走路。结尾说了这么多我在实际操作中最大的体会是生成式AI设计模式不是什么高深理论它就是把工程中反复出现的问题和最优解沉淀下来让后来者能站在前人的肩膀上。但也不要神话它每个模式都有自己的适用边界和代价组合使用、动态取舍才是常态。我自己的习惯是拿到一个需求先明确任务边界和用户最不能接受的问题再从提示策略、编排架构、反馈闭环三个维度去挑合适的模式然后小步快跑地迭代验证。最后再分享一个小技巧把每个模式的关键参数温度、示例数、步数、top-k做成一个可配置的清单每次上线前都过一遍能帮你少踩不少无谓的坑。这套方法论我还在持续完善后续会把更多模式细节和项目实战拆开来聊。
