1. 为什么把编排与评估放到第五篇来讲生成式AI设计模式这个系列写到第五篇前面的内容已经覆盖了不少基础层的东西提示词模板化、上下文窗口管理、RAG检索增强以及模型抽象与统一网关。如果你是从第一篇一路跟过来的应该已经能搭出一个能跑、能改、能接不同模型供应商的AI应用骨架了。但骨架归骨架真正把生成式AI从“demo级”推到“生产级”卡点往往不是模型选型而是系统在复杂场景下的编排能力、质量闭环和成本控制。这一篇我来拆解三个偏“上层建筑”的模式路由编排模式、评估优化模式、多智能体协作模式外加一个容易被忽视的缓存复用机制。之所以把这几个放在一起是因为它们在真实项目里往往是配套出现的——路由负责把请求分派到正确的能力单元评估负责判断结果是否达标优化负责在未达标时迭代缓存负责避免重复劳动而多智能体则是把这套逻辑放大到多个角色协同的规模。单独聊任何一个都像是只给了一个零件拼起来才是完整落地链路。这篇内容适合谁从事AI应用开发的工程师、正在做技术方案的架构师以及被领导要求“把AI能力接入现有系统”但还没想清楚架构的人。我不准备讲太多理论重点放在我在生产环境里实测过的东西几个典型流程、关键参数怎么定、踩过什么坑、最后怎么收场的。2. 路由与编排模式别让一个模型干所有活2.1 这个模式到底在解决什么问题很多团队一上来就喜欢“一个Prompt走天下”什么需求都丢给同一个大模型。早期确实能跑通等到业务复杂起来问题就暴露了有的场景需要低延迟比如聊天助手有的场景需要高质量回复比如长文生成有的场景涉及敏感数据不能出内网还有的场景根本不需要大模型——普通规则匹配就够了。这时候如果所有请求都打向同一个端点、同一个模型代价非常高。路由编排模式的核心思路是在客户端和模型之间加一层“交通指挥”。它根据请求的特征把任务分派到最合适的处理单元。这个特征可以是意图分类结果、用户请求的复杂度阈值、上下文长度、安全等级或者只是简单的费用预算。我实际见到的一个典型case是这样的某知识库问答系统原来全部走千亿参数模型每轮对话成本高不说响应还慢。后来只加了一层路由先让一个小模型做意图识别如果是“资料查询类”走RAG流水线如果是“闲聊安抚类”走另一个轻量模型如果是“多轮复杂推理”才升级到强模型。结果整体成本降了百分之四十多用户体感延迟反而更快了——因为大部分请求都落到了轻量路径上。2.2 路由层的落地实现要点实践中最简单且可靠的路由实现不是堆一堆复杂规则而是分三级来处理。第一级是规则路由最便宜也最快。比如根据关键词、正则、接口来源、用户角色直接分流这些完全不需要模型参与。我见过一个错误倾向是团队一上来就训练意图分类模型做路由结果训练数据不够效果反而不如规则。规则能覆盖的场景绝对不要上模型。第二级是模型路由用一个低成本的小模型做意图分类或任务分派。关键词规则覆盖不了模糊表达小模型可以。选型上不必追求大参数能分对粗粒度意图就够。这时候要注意给模型一个明确的分派协议输出格式最好是严格的JSON比如{route:rag_query,confidence:0.92,reason:...}。格式越严格下游解析越稳定不要让它自由发挥。第三级是动态路由也就是由编排器综合上下文、历史会话、当前系统负载和实时成本指标决定走哪条路。比如同一个请求系统忙时走快速轻量模型闲时走高质量模型。这一级需要建立指标监测不是拍脑袋切换。这里有个常见的设计误区有人觉得路由层只能放在最前面做一次分派。实际上业务稍微复杂后一个请求内部可能需要依次经过多个能力单元这时候编排器的任务就变成了“流程控制”它要维护一个执行计划按DAG或流水线方式调度。这也是为什么很多生产级框架最后都长成了工作流引擎的原因。不要把路由和编排割裂开设计两者是同一个模块的两面。2.3 路由参数怎么定路由策略毕竟要落地最关键的无非是几个阈值。我分享一组自己用过的初始参数你可以照抄后按场景调整。参数项建议初始值说明与调整依据小模型意图分类置信度阈值0.6低于该阈值则升级到大模型重新判断避免小模型乱分派上下文长度阈值8K tokens超过后优先走长上下文模型或触发摘要压缩流程成本超出阈值单请求成本的120%超过后自动切换至备用轻量模型防止成本失控响应超时阈值大模型10s小模型3s超时自动降级到缓存结果或规则兜底安全敏感标记白名单/黑名单匹配命中敏感规则直接拦截或走私有化模型通道这些阈值没有一个是可以一次到位的。我在项目里通常会给路由服务加一个可热更新的配置中心灰度观察一周后微调。比如意图分类置信度0.6可能太激进有些场景0.5更合适因为小模型本来就容易保守。不要迷信别人给的数字要基于自己的流量分布来校准。2.4 路由层的一个关键禁忌路由层最容易犯的错误是让路由决策完全不可追溯。生产环境里一定会出现“为什么这个请求走了贵模型”的质疑。所以你必须在路由日志里记录分派依据、模型版本、输入摘要和耗时成本缺一不可。注意路由日志本身就是一种资产它可以反过来帮你优化路由规则。我亲眼见过团队靠日志里的大量“升级到强模型”记录发现其实是小模型的指令里漏了某个业务术语定义补上之后强模型调用量直接降了20%。3. 评估优化模式给生成结果加上质检闭环3.1 为什么生成式AI也需要“质检员”传统软件开发里单元测试和CI/CD是质量底线代码写错了能立刻被发现。生成式AI不一样模型输出千变万化同一个Prompt今天回答得体明天可能就跑偏。你没法断言“这个输出是对的还是错的”只能在概率意义上说“它有多好”。评估优化模式Evaluator-Optimizer的思路是把生成过程拆成两步第一步是Generator负责产出候选结果第二步是Evaluator负责评估候选结果质量如果未达标就把反馈注入优化阶段让Generator基于反馈重写。这很像真实工作里“写手写稿、编辑审稿、退稿修改”的循环。很多团队连一个评测集都没有就直接上线AI功能这是我在实际排查中见过最普遍的问题。没有评测闭环你根本不知道一次提示词修改到底是变好了还是变坏了只能靠“感觉”。而评估优化模式的核心价值就是把这个“感觉”变成可重复、可量化的流程。3.2 评估器怎么设计评估器可以是规则的、模型判分的、或者混合的。纯规则适合有明确答案的场景比如代码是否包含指定的API调用回答中是否遗漏必须提到的政策条款。基于模型判分适合主观依赖高的场景比如“这篇文档是否通俗易懂”“这段回复是否有说服力”。混合模式就是先跑规则检查过不了的直接打回过得了的再交给模型评分。我在实战里用的评估模板通常会要求评分模型输出带理由的分数而不仅仅是数字。比如“内容完整性0.9理由覆盖了所有三个关键点但没有展开第三个点”。没有理由的分数没法指导优化器做修改这个细节特别重要。评估的另一个重点是指标设计。单看一个总体分是没用的我惯用的指标分四维完整性、准确性、格式合规、业务约束。每个维度单独打分再按业务权重算出加权总分。注意权重不是拍脑袋定的应该是从你积累的bad case里反推出来的——哪个维度出问题最多权重就拉高。3.3 优化器的反馈闭环设计优化器端的关键不是让模型“重新生成”而是让模型知道“具体哪里不合格”。你把评估器的原始评论文本直接塞给Generator效果一般都不好因为意见太散模型不知道该改哪里。我实践下来的做法是把评估结果做一次结构化转换生成一个明确的修改指令清单比如第二点论证不充分需要补充至少一个数据支持。结论部分过于笼统请给出可执行的下一步。格式不满足要求所有小标题必须使用中文编号。结构化反馈比自然语言反馈的效果明显好原因是模型对指令清单的遵循度比对散文式评价的理解度高得多。实测中同样是Retry一次结构化反馈下重写结果达标率提升了30%以上。另外要控制好最大迭代次数。每一轮调用都在烧钱烧时间建议默认最多两轮。也建议设置“改不改进都提交”的妥协策略如果第二轮优化后得分仍低于阈值就取两轮中得分较高的那个输出返回同时在监控里标记为“低质量”供后续人工抽查或补充训练数据。评估优化不是一个无限循环要有终止条件。3.4 评测集的沉淀方法没有评测集的评估优化模式就是空中楼阁。我的建议是每上线一个新功能同步动手建一个50到100条输入样本的评测集覆盖正常场景、边界场景、恶意输入三个类别。不需要一开始就搞几千条50条精挑细选的场景样本足以发现大多数明显劣化。评测集的更新也要讲究每次在真实流量的bad case里发现的新问题都固化到评测集里。这个过程我称为“坏例归档”。归档不是简单存个字符串要记录当时期望的输出形态、当前模型的错误表现、以及你判断它错在哪里的依据。这个归档库积累到一定程度后你会发现自己对本系统的理解远超任何模型评估工具能自动给出的水平。4. 缓存复用模式别让模型重复回答同一个问题4.1 生成式AI的缓存与传统缓存有什么不同后端开发的人对缓存太熟了但到了生成式AI领域很多人反而忘了这个老朋友。模型调用每次都是真金白银相同或相似的请求反复去问模型既慢又贵。缓存复用模式就是把传统的缓存思路移植到AI场景但因为模型输出天然不稳定它的实现比普通Redis缓存要复杂一些。缓存的对象可以是完整响应、检索结果、中间计算状态甚至是Prompt模板的子片段。粒度选择直接决定缓存命中率和存储成本之间的平衡。这个原则没有变过离计算越近的数据缓存价值越大。4.2 缓存的粒度怎么选我直接列出几种我在项目里用过的缓存粒度按命中率和复杂度排列。缓存粒度适用场景命中率参考难点整Prompt原文完全相同的问句重复出现低用户提问几乎不会完全一致Prompt语义哈希语义相近的问题中高需要向量嵌入有误判风险RAG检索结果同一资料被反复检索高语料更新后缓存需失效模型响应片段固定话术、政策条款类输出高需要内容切分策略中间向量embedding结果复用极高存储占用大几乎全部是冷数据整Prompt原文缓存是最容易实现的但是命中率低得可怜我见过真实项目里用户一句话改了标点就miss了。语义哈希是更实用的方案它把自然语言输入先embedding再通过向量相似度匹配到历史请求。这个方案要小心误命中两个问题表面相似但意图相反一旦命中错误缓存就是一次错误回答。所以我的经验是语义相似度阈值宁可调高一点不要追求高命中率而牺牲准确性。4.3 缓存失效策略的几个坑普通缓存有TTL就完事了AI缓存不一样。最典型的坑是RAG场景下知识库更新了但检索结果缓存没有失效系统继续给用户返回旧资料。我踩过一次产品更新了服务条款但用户连续几天在问答里收到旧条款内容原因就是我把knowledge_version这个字段漏在了缓存key之外。修复方式很简单所有涉及检索结果的缓存key必须带上检索库的版本号或更新时间戳。知识库一旦变更版本号变化缓存自然全部失效。同理涉及用户个性化内容的缓存key要带上用户ID涉及模型版本的缓存key要带模型标识。缓存key的设计原则就一句话把影响输出正确性的所有变量都放进key里。不过也别把所有东西都塞进缓存成本意识要有。我在一个项目里见过有人把几千个用户的个性化回复全部缓存结果内存打爆了缓存命中率才不到10%。这类请求本身区分度高重复率低根本不值得缓存。缓存前先看一眼这段流量的重复率数据重复率低于5%的路径不要缓存。4.4 输出缓存的命中校验还有一种做法是不同请求的Prompt不同但最终生成的答案完全一样比如政策条款类问题。对这种场景我试过“输出内容片段缓存”核心是把完整响应切分成段落或句子做缓存请求来了先检查记忆片段能否拼出完整答案缺的部分再调用模型补全。这种方案能明显降低调用量但实现要注意校验粒度如果片段太碎拼接时会产生语义断裂如果太大又很难命中。我实测下来按“完整语义段落”切分效果最好。另外对缓存片段要做脱敏检查因为缓存池里可能混入包含用户隐私的内容一旦被另一个用户命中读取就是严重事故。这类校验不能省。5. 多智能体协作模式把任务拆给一屋子人5.1 什么时候真的需要多智能体多智能体是被炒作得最厉害的词我看到很多团队三个人两条狗也号称做“多智能体系统”。先泼盆冷水超过80%的业务场景一个编排良好的单智能体流程就够了加多智能体只会增加延迟、成本和不稳定。那什么时候真需要我的判断标准是三条任务包含多个明显不同且可以并行的子任务子任务各自需要不同的专业角色能力或不同的上下文单个模型流程难以在一个Prompt里同时完成且保持质量。比如一个综合报告生成需求需要市场分析、财务数据解读、文案撰写、合规检查四块并行工作这就是典型的多智能体场景。5.2 协作拓扑与消息协议多智能体落地重点不是“智能体个数”而是它们之间怎么协作。我用过的协作拓扑主要有三种各自的适用面不一样。链式拓扑最简单一个智能体的输出作为下一个的输入适合流水线型任务比如“检索→总结→润色”。它的优点是流程清晰、容易跟踪缺点是只要一个环节卡住全链路阻塞。中枢拓扑是有一个协调者负责接收所有任务然后分发给不同的专业智能体汇总它们的结果。这个适合子任务相互独立、需要并行的场景。中枢承担了最多的编排压力它自身需要做任务拆分和结果融合所以这个协调器的Prompt设计对整个系统的质量影响极大。网状拓扑是每个智能体都能自由通信能处理高度耦合的协作任务但是消息数量爆炸式增长调试难度极大。我在生产环境基本不推网状只在实验场景玩过。普通业务用中枢拓扑就够了。消息协议方面我强烈建议智能体之间不传自然语言长文而是传结构化任务对象包含任务ID、输入数据引用、预期输出格式、截止时间等字段。智能体之间的“对话”本质上应该是数据流水线而不是聊天室。这样做的好处是每条链路都可追踪失败可重试部分结果可复用而且不会出现“两个智能体聊着聊着忘了主线”的失控局面。5.3 治理与成本控制多智能体系统最大的隐患不是性能是失控。失控表现包括循环调用停不下来、某个智能体反复重试刷成本、两个智能体互相纠正进入死循环。我在项目里设了几道防线分享给你。第一道是每个智能体的调用预算不管是时间预算还是费用预算超出就中断并走兜底回答。第二道是全局深度限制任何链路的智能体跳转次数不能超过预设上限。第三道是循环检测记录每个消息链的消息指纹如果检测到重复消息出现说明进入了循环立刻熔断。这三道防线缺一不可。成本控制上还有个容易被忽略的点多智能体的并发很容易把外部模型的速率限制打爆。所以在协调器层要做一个全局的令牌桶限流而不是让每个智能体各自限流。全局限流的目的并不是单纯限制并发而是要按任务的优先级动态分配模型调用预算让高优任务在高峰期也能保证走强模型。注意多智能体的可观测性建设要前置。每个智能体的每次输入输出、路由决策、耗时、费用都要进日志。等你遇到线上质量事故再想补日志已经晚了。多智能体的调试难度是单链路的十倍以上没有日志排查问题就是纯猜。6. 常见问题与排查技巧实录6.1 高频故障速查表这一节直接整理成表格都是我或者同行在生产环境真踩过的问题。症状可能原因排查方法与处理建议路由频繁升级到大模型成本飙升小模型置信度阈值设太高拉日志看意图分类的分数分布把阈值降到分界点同时检查小模型指令是否缺少领域术语定义评估分数一直在及格线边缘徘徊评估器与Generator共用同一个大模型评估容易被同源偏见带偏优先换一个不同系列的模型做评估或者至少换不同的Prompt模板和温度参数缓存命中率极高但用户投诉“回答太旧”缓存key漏了知识库版本号检查所有涉及检索的缓存key补上版本字段并建一个强制刷新接口多智能体任务总在某个环节超时某个智能体承担的Prompt太重输出过长拆分子任务或给该智能体改用输出更短的模型同时检查该环节是否可以采用部分结果提前返回同一请求重试后结果差异巨大温度参数太高或Generator接收了未经整理的反馈梳理优化器的反馈是否结构化把自由文本评价改造成修改指令清单评估环节本身退化打分越来越宽松评估器的输出没有做统计监控定期统计评估器给分的均值和方差发现持续漂移就要介入评估Prompt或模型版本都要做可回滚管理6.2 排查方法上的几点心得排查生成式AI系统问题和排查传统系统最大的区别是错误不是非黑即白的很多bug只有在特定输入、特定上下文、特定时间范围里才出现。我的排查习惯是三步走。第一步看日志不看感觉。先把出问题的那次请求的完整链路日志拉出来包括路由决策、模型版本、Prompt内容、评估分数、耗时和费用。第二步做可控复现。不要拿线上流量反复试把那次请求的输入固化成一个测试用例在测试环境的固定参数下跑几遍看是否稳定复现。第三步分层定位。先判断是输入侧问题Prompt写得不好模型侧问题模型本身能力不足还是架构侧问题编排逻辑有缺陷三层逐个排除。这套流程看起来简单但它能避免大多数团队“从改Prompt开始乱试一通”的低效路径。7. 最后一个建议设计模式要服务于可演进我个人在实际项目里越来越觉得设计模式的价值不在于“用了某个模式”这件事本身而在于它让系统拥有了面对变化时的结构弹性。路由和编排让新模型接入不费力评估优化让提示词迭代有方向缓存复用让成本始终可控多智能体让服务边界可以扩展。你完全可以不按字面照搬这四个模式但建议保留它们的核心思想分派、校验、复用、治理。这四点是一套组合拳。漏掉任意一个系统都会在某个阶段给你找麻烦。我见过只做了路由没做评估优化的项目结果分流是分对了但每个分支的输出质量都不可控。也见过只做评估不做缓存的项目每轮迭代都在烧全量调用费。设计模式不是考卷上的名词解释它是一张你随时可以裁剪的工程地图。下一期如果继续写我打算聊聊生成式AI应用的可观测性体系和评测驱动开发的具体操作这两块是把这一篇里的思想落成日常工程习惯的关键支撑。