生成式AI设计模式入门：上下文组装、RAG与工具调用实战解析

做AI应用开发这两年我越来越觉得“生成式AI设计模式”是个被低估的话题。经典软件工程里有23种设计模式生成式AI这边虽然还没有一本GoF那样的经典著作但真正在一线反复踩坑的人私底下早就沉淀了不少共识性的打法。所谓生成式AI设计模式就是那些被反复验证过的、解决特定AI应用问题的通用方案比如上下文怎么拼、知识怎么喂、模型能力边界怎么补。这次开一个系列第一期先聊三个最基础、出现频率最高的模式上下文组装模式、检索增强生成RAG模式和工具调用模式。适合正在做AI应用但觉得效果不稳定、总在调prompt、想让系统更工程化的同学参考。1. 为什么生成式AI需要自己的设计模式1.1 从“调API”到“设计AI系统”的转变先说一个我观察到的现象。早期做AI应用多数人的思路是“把prompt写长一点、写细一点”觉得效果不好就是prompt不够好。但实际项目做到后面你会发现一个能稳定上线的AI功能往往不是一句prompt搞定的而是由模型调用、上下文管理、输出校验、重试降级、缓存、日志等多个环节共同构成的。prompt只是这台机器里的一个零件而不是全部。这种思维转变本质上是从“调API”转向“设计AI系统”。传统软件工程里设计模式解决的是“在特定场景下反复出现的问题”比如创建对象、接口适配、算法策略切换。生成式AI应用也有自己反复出现的问题模型上下文窗口有限、输出具有随机性、知识有截止日期、无法主动获取实时数据、一本正经地胡说八道。这些问题如果不加抽象、不沉淀成方案每个项目都是从零开始踩坑换个人就换一套写法。1.2 生成式AI模式的分类思路业内对生成式AI设计模式还没有统一分类不过按我自己的实践可以从四个维度去拆解信息组织维度解决“怎么把上下文喂给模型”的问题典型如上下文组装、记忆压缩、历史会话管理。知识扩展维度解决“模型不知道或知道得不准”的问题典型如RAG检索增强、微调、知识图谱注入。能力边界维度解决“模型只能生成文字、不能执行动作”的问题典型如工具调用、代码解释器、Agent多步规划。可靠性维度解决“输出不稳定、不可控、不可信”的问题典型如输出校验、自反思、评估防线、人工审核兜底。这四个维度不是完全割裂的一个实际功能往往会同时用到多个模式。比如一个客服机器人既需要上下文组装来组织用户信息和业务规则也需要RAG来查阅最新的售后政策还需要工具调用来查询订单状态。这也是为什么我建议先从这三个基础模式入手它们几乎覆盖了大多数AI应用的主干逻辑。1.3 为什么现在沉淀模式很重要一个很现实的问题没有设计模式AI功能就是“一次性代码”。这个月写得爽下个月需求一变或者换个人维护整个prompt逻辑就像一团乱麻。而有了模式之后好处是实打实的团队协作有共同语言说“这里走RAG”比把整个流程重新解释一遍高效得多。功能可测试、可回归模式意味着标准入口和标准输出围绕模式建测试集就顺理成章。成本可控模式本身就包含了对token消耗、调用次数、延迟的优化手段而不是事后再补救。我在做项目时最直观的感受是用模式搭出来的功能验收时问题少一半。好多“玄学问题”其实是没按套路出牌导致的比如上下文顺序不对、知识没有正确注入、工具声明含糊。把这些套路沉淀成模式就是让AI应用从“碰运气”变成“可预期”。2. 模式一上下文组装模式2.1 同一条模型指令不同的上下文效果天差地别上下文组装是我认为最基础也最容易被低估的模式。同一个模型、同一个问题上下文组织方式不同效果可能差出好几个级别。我举个例子用户问客服机器人“怎么退货”如果你只把这句话丢给模型它大概率会给出一个通用的、正确但没用的回答。但如果你在上下文里同时塞进了“用户是谁、购买了什么商品、订单状态如何、退货政策是什么、之前聊到哪一步”模型给出的就是一条可直接执行的个性化答复。这种差异的本质是大模型本身是个“空泛的知识库”回答质量取决于上下文里提供了多少有效约束。用户的一句话只是冰山一角真正决定输出质量的是水面上下的全部信息拼装。这个拼装动作就是上下文组装模式。2.2 上下文三件套的核心结构我自己写上下文时习惯把内容分成三个层次类似三层夹心结构系统层System Prompt角色设定、任务目标、输出规范、禁忌事项。这层是稳定不变的放在消息列表最前面相当于给模型“定调子”。业务数据层当前用户的信息、业务规则、知识片段、实时数据。这是每次请求动态变化的放在中间相当于“喂给模型的素材”。会话层最近几轮问答历史。放在最后给模型提供对话延续性相当于“短期记忆”。这样分层的逻辑很简单模型对越靠前的内容注意力权重往往越高所以最重要的指令要放在最前面动态数据放中间便于模型结合指令一起理解而对话历史属于辅助信息放最前面反而会稀释掉指令的权重。2.3 实操一个简单的上下文组装器这里给一个我在客服场景里实际用过的组装函数示例结构可以通用def build_messages(user_query, user_profile, policy_text, chat_history): system_prompt ( 你是一名电商客服助手。你的任务是依据给定的售后政策和用户订单信息 给出准确、简洁、友好的回答。\n 要求\n 1. 只能依据提供的政策内容回答不得自行编造规则\n 2. 如果政策中没有相关信息明确告知用户需要转人工\n 3. 回答控制在100字以内先给结论再给依据。\n ) business_context ( f【用户信息】\n{user_profile}\n\n f【售后政策】\n{policy_text}\n ) messages [{role: system, content: system_prompt}] # 动态业务信息以user消息注入放在历史之前 messages.append({role: user, content: business_context}) # 历史对话取最近5轮避免窗口溢出 for turn in chat_history[-5:]: messages.append(turn) # 当前问题 messages.append({role: user, content: user_query}) return messages这段代码里有三个关键细节值得展开。第一业务信息我以user消息注入而不是塞进system prompt原因是system里如果放动态内容每次请求都要重新构造token浪费且容易让模型混淆“固定的身份”和“临时的数据”。第二历史只取最近5轮超出就截断这是控制上下文长度的基本手段。第三业务上下文和当前问题分成两条独立消息让模型能区分“背景资料”和“要我回答的问题”。2.4 上下文组装常见的坑这部分是我踩过最多的地方列几个典型的把全部对话历史塞进去。窗口是有限的历史一长前面的指令可能被“挤”出有效注意力范围甚至直接触发长度上限报错。正确做法是裁剪、摘要、或按轮次滑动窗口。指令和数据混在一起。如果system prompt里既写角色又写订单信息模型经常分不清哪些是规则、哪些是素材容易把业务数据也当成“要遵守的指令”。没有任何分隔符。消息内部如果全是长段落模型对边界的感知会很弱。用【用户信息】、【售后政策】这样的标记或者XML标签、Markdown分隔符都能显著提升模型对结构的理解。输出规范埋在长篇业务文本里。输出格式这类关键约束应该单独用一条消息或在system里独立成段别和动态数据混在一起否则模型容易被大量数据带偏。上下文组装模式是后面所有模式的地基。RAG检索回来的知识最终要组装进上下文工具调用返回的结果也要组装进上下文连Agent的记忆管理本质上也属于上下文组装的范畴。把这个模式吃透后面会顺手很多。3. 模式二检索增强生成RAG模式3.1 为什么不能把知识硬塞给模型上下文组装解决了“如何组织已有信息”但很快会遇到另一个问题有些信息模型根本没有。比如一个企业最新的售后政策昨天刚发布或者某个产品的参数表只在内部wiki里模型的知识截止日期根本覆盖不到。你不可能把这些全塞进prompt哪怕硬塞进去每次都带几千上万字的资料成本和时间都扛不住。RAG检索增强生成解决的就是这个问题不把知识塞给模型而是把知识放在外部数据库里等用户提问时先检索出相关的几个片段再把这些片段注入上下文让模型基于检索结果做回答。这个模式的好处非常多知识可以随时更新、不用为每个专题重新训练模型、回答可以有出处、可以追溯。3.2 一条完整的RAG链路有五步我做了不少RAG项目之后把链路拆成了五个环节每个环节都可能成为瓶颈文档加载把PDF、Word、网页、数据库记录读进来转成纯文本。这里的坑主要是格式解析表格和复杂排版经常解析乱。文本切分把长文档切成片段也叫chunk。切分粒度直接决定检索质量太大不精准太小语义不完整。向量化每个片段用embedding模型转成向量存入向量数据库。这一步选对embedding模型很关键不同模型对中文、长文本、专业术语的编码能力差别很大。检索召回用户提问时把问题也转成向量在库里做相似度搜索取出top-k个候选片段。合成生成检索结果与用户问题一起组装进上下文交给模型生成最终回答。这个链路看起来简单但实际调优点非常多。我在最开始做的时候想当然地觉得“只要向量检索准回答就一定好”结果被现实教育了。整个链路是漏斗形的前面四步任何一环掉了链子最后生成质量都不可能好。3.3 实操参数chunk_size、overlap、top_k与rerank参数是RAG里最见功夫的部分。先说我常用的几组参考值chunk_size切分大小中文场景我一般控制在500~800字或者按token估算256~512 token。太短一个片段装不下一个完整意思太长噪声多而且单个片段可能超过模型单次注入上限。如果内容结构性强比如法律条款我倾向于按段落切长段落再按句号或分号拆。overlap重叠长度相邻片段之间保留50~100字符的重叠避免切分恰好把一句话从中间劈开导致语义断裂。top_k召回数量我的习惯是先多召回再精筛。初召回取20个候选经过重排后只保留5个注入prompt。如果只取top_1到3有时候一个片段正好匹配但信息不全结果容易答偏。rerank重排强烈建议在正式项目里加一步重排用一个专门的排序模型对召回片段做精细打分。实践中重排对准确率的提升非常明显尤其是用户问题比较复杂、关键词和语义不完全一致的时候。另外还有一个经常被忽略的点混合检索。向量检索擅长语义匹配但对精确关键词、编号、商品型号这类信息反而可能吃不准。我在项目中通常把BM25关键词检索和向量检索同时跑做结果融合能解决不少边界情况。下面是一个简化的RAG查询伪代码流程def rag_answer(question): # 1. 召回候选片段 query_vec embed(question) candidates vector_db.search(query_vec, top_k20) # 2. 可选关键词检索结果融合 bm25_results bm25_search(question, top_k10) merged merge_rank(candidates, bm25_results) # 3. 重排取最终Top-5 final_chunks rerank(question, merged)[:5] # 4. 组装上下文并生成 context assemble_rag_context(final_chunks) return llm_generate(question, context)注意第4步组装时每个片段前要加来源标识例如“[资料1] ... [资料2] ...”然后在system prompt里要求模型回答时标注“根据资料1”。这一步对回答可追溯性至关重要用户能看到依据模型也更不容易胡说。3.4 RAG排查思路先定位是召回不行还是生成不行RAG最气人的问题是明明检索了模型还是答非所问。这时候先别急着改prompt而是要先定位问题出在链路的前半段还是后半段。我的排查顺序如下先打印检索到的片段看召回内容是否相关。如果召回内容本身就跑偏了那是切分粒度、向量模型、top_k或rerank的问题改prompt没有用。如果召回内容相关但回答跑偏那就是生成阶段的问题。可以在system里强化“你只能依据资料内容回答不要使用内部知识补充”这类约束甚至加一句“如果资料中没有对应信息老实说不知道”。如果切分切断了语义比如表格被拦腰截断、代码块被拆散需要调整切分策略对特殊格式先做保护性处理再按结构切分。如果用户问题本身包含精确型号或编号向量检索效果不好试试加上BM25混合检索或者做一步查询改写从原始问题里抽取关键实体后再去检索。RAG是我个人觉得最容易“表面搞定、深挖全是坑”的模式。它不像上下文组装那样改个结构就见效而是需要反复调参、看检索日志、分析badcase的细活。但反过来说一旦把RAG链路沉淀成标准模块后续接任何知识库场景都只是换数据源的事这也是设计模式的价值所在。4. 模式三工具调用模式4.1 让模型长出“手和脚”哪怕上下文组装和RAG都做到位了模型依然有一个先天短板它只能生成文本没法主动获取实时数据也没法执行具体操作。你问它“明天北京天气如何”它可能凭训练数据编一个答案你让它“帮忙查一下订单OD20240001的物流状态”它根本没有查询接口只能瞎猜或让你自己去查。工具调用Function Calling / Tool Use就是给模型补上“手和脚”的模式。思路是我们预先声明一批可供调用的函数每个函数带清晰的描述和参数定义模型在生成回答时如果判断需要某个函数就输出一个结构化的“调用请求”我们收到请求后在系统里真实执行这个函数把结果以消息形式返回给模型模型根据结果生成最终回答。整个流程形成一个“感知-决策-执行-反馈”的闭环这也是Agent的雏形。4.2 一个最小可用的工具调用实现我用的是OpenAI风格的tools参数示例其他平台的SDK虽然字段名略有差异但整体思路一致。假设我要让模型能查询订单状态from openai import OpenAI client OpenAI() # 1. 声明工具 tools [{ type: function, function: { name: get_order_status, description: 查询订单当前状态。当用户询问订单物流、发货进度、签收情况时必须调用此工具。, parameters: { type: object, properties: { order_id: { type: string, description: 用户订单号格式如OD20240001 } }, required: [order_id] } } }] # 2. 首次调用让模型决策是否调用工具 response client.chat.completions.create( modelgpt-4o-mini, messages[ {role: system, content: 你是一个电商客服助手。遇到需要查询实时数据的问题时先调用工具获取信息再回答。}, {role: user, content: 帮我查一下订单OD20240001到哪了} ], toolstools, tool_choiceauto ) msg response.choices[0].message # 3. 判断是否请求调用工具 if msg.tool_calls: # 4. 执行本地函数真实查库 order_id msg.tool_calls[0].function.arguments result get_order_status(order_id) # 5. 把工具结果返回给模型 messages [ {role: system, content: 你是一个电商客服助手}, {role: user, content: 帮我查一下订单OD20240001到哪了}, msg, # 携带tool_calls的assistant消息 {role: tool, tool_call_id: msg.tool_calls[0].id, content: str(result)} ] final client.chat.completions.create(modelgpt-4o-mini, messagesmessages) print(final.choices[0].message.content)这套流程里第3步到第5步是关键模型第一次返回的是“工具调用指令”而非最终答案我们必须执行指令、把真实结果回填再让模型做第二次生成。很多人第一次接触工具调用时以为模型会自己执行函数这是个重要误解。模型只负责任意决策执行权始终在我们手里。这种设计恰恰是安全性的核心模型无法直接操作数据库它只能“申请”调用真正干活的是受控的本地代码。4.3 工欲善其事必先利其“声明”工具调用的成败很大程度取决于你写的函数声明清不清楚。模型是通过描述来决定“何时调用、怎么调用”的描述写得差模型就会乱调、少调、错调。比如上面例子中description我专门写了“当用户询问订单物流、发货进度、签收情况时”这就是给模型一个触发条件没有这句话模型可能面对订单问题也选择直接回答。再分享几个参数设计细节参数越少越好。每个参数都会给模型增加选择负担能从一个参数解决的问题不要拆成三个。我见过有人设计工具时传了十几个参数结果模型频繁填错或漏填。枚举值尽量给全。如果某个参数只有固定选项比如“物流公司顺丰、圆通、中通”直接写进枚举别让模型自由发挥。工具描述用“什么时候用”的句式。与其写“查询订单”不如写“当用户需要查询订单状态、物流信息时调用”模型对触发场景的理解会更准。设置最大迭代次数。工具调用不是只能调一次模型完全可以调完一个工具后基于结果再调另一个。但为了防止模型进入死循环或无限追问工具我通常把循环次数限制在3~5轮超次直接终止并转人工。4.4 工具调用的常见失败模式与对策实际跑下来工具调用最常见的失败有以下几种模型虚构参数。比如用户没说订单号模型自己编了一个“OD20240002”去调工具。对策调用前做参数校验必要时反问用户补充关键信息不要拿着幻觉参数去执行真实验证。模型不调工具直接胡编答案。对策有两个一是强化system提示明确“查询实时信息必须调用工具不得自行推断”二是把tool_choice设为required强制模型每次都走工具调用路径。工具之间反复横跳。模型一会儿调订单查询、一会儿调物流查询两三个来回不收敛。对策就是前面说的迭代上限以及对工具做更细粒度的触发描述减少误触。工具执行结果注入后模型又“忘”了前文。一般来说第二次生成时要把前文完整带上尤其是中间穿插的assistant消息和tool消息顺序不能乱。丢了上下文模型就会答非所问。工具调用模式是把AI从“聊天机器人”升级成“能办事的数字员工”的关键一步。但它也引入了新的复杂度调试链路变长、安全边界需要设计、第三方接口不稳定时还要做重试和降级。这也是为什么这类代码一定要模块化沉淀下来而不是在每个业务里复制粘贴改参数。5. 常见问题与排查技巧实录5.1 一张速查表排查常见症状这一节把我在实操中遇到的典型问题整理成速查表按“症状-原因-排查动作-预防措施”四列组织方便你直接对照症状可能原因排查动作预防措施输出内容不稳定同样输入每次答案不同温度过高、上下文随机性大将temperature降到0.1~0.3固定seed如支持复测生产环境低温运行评估环境与生产环境参数一致回答跑到上下文窗口外被截断max_tokens设置过小、输入token超限查看usage统计确认输入输出token占比裁剪历史、压缩业务数据、必要时换更长上下文模型RAG答非所问召回内容不相关或切分粒度不当打印检索片段人工判断相关性调整chunk_size、增加rerank、混合检索检索到了但模型输出没用到资料生成prompt约束不足检查prompt中“只能依据资料回答”的指令是否清晰增加“无资料时拒绝回答”的边界指令工具调用一直不触发工具描述不清晰、触发条件没写在API调试台构造触发问题观察模型是否返回tool_callsdescription里写明调用场景必要时给一个few-shot示例工具返回结果后生成的回答仍错误工具结果未正确回填消息、顺序错乱检查assistant/tool消息顺序和tool_call_id按官方规范组装多轮消息写单元测试验证token成本居高不下每次请求都塞超长历史或大段政策文本按实际用量配置token统计看板历史裁剪、动态摘要、相似请求加缓存层这张表里的每一项背后都是我用真金白银和时间换来的经验。最值得强调的一点是排查AI问题时永远先定位再修改不要一上来就改prompt。改prompt是最快但也最容易掩盖问题的方式它解决的是“生成阶段”的问题如果问题出在检索或工具调用那你改了十版prompt也白搭。5.2 三个让我少走弯路的实操习惯最后分享三个我每次做AI项目都会坚持的实操习惯算不上高深技巧但真的能救命第一所有关键请求都保存完整消息快照。我习惯把每次请求的原始messages、模型参数、完整响应都存到日志里配上request_id。这样线上的badcase可以直接定位是上下文拼错了、还是检索召回差了、还是模型生成抽风了而不是靠用户描述“刚才有个问题不对”来盲猜。第二给每个AI功能预留一个可配置的参数层。温度、top_p、max_tokens、甚至所用的模型名称都做成配置项不要硬编码在业务代码里。这样调优的时候不用改代码重新部署改个配置就能做A/B对比。第三把评估案例沉淀成回归测试集。不要每次优化都凭“感觉这个回答行不行”。把典型问题、边界场景、必测项收集起来每次改prompt、改检索策略、改工具声明后统一跑一遍测试集对比前后效果。我见过太多人因为一次改动修好了A场景却搞坏了B场景有回归测试集就能第一时间发现问题。这期写的三个生成式AI设计模式——上下文组装、RAG、工具调用——虽然单个看都不算新鲜但它们组合起来几乎能覆盖大多数AI应用的主干。我自己在做项目时最大的感受是AI应用开发的复杂度不在模型本身而在模型周围的“系统设计”。模式不是教条而是从实战里长出来的拐杖你用得多了自然会衍生出自己的变体。后面几期我打算继续聊聊Agent的多步规划模式、输出校验与评估模式、还有记忆管理这块硬骨头。想继续看的朋友可以先把手头这三个模式用起来有具体问题欢迎在评论区聊。