做了四个月 AI 平台最深的感受是模型这关其实不难过难的是把一堆模型像一支球队一样组织起来。今天这篇是这个系列的第 5 篇我想把最近跑通的“55873 生态”完整拆开讲讲包括 613 混合模型怎么配、四层智能体架构怎么搭、安全策略编排怎么做。这套东西不是实验室方案是已经在真实业务里跑了好几个月的生产体系踩过的坑我都尽量写出来打算做多模型接入或者搭智能体平台的朋友可以直接拿来当参考。先说结论这套体系的核心思路是把“模型能力”和“业务逻辑”彻底解耦。业务侧只描述“我要什么结果”模型侧只负责“把能力提供出来”中间所有的路由、判断、编排、安全控制全部收拢到智能体编排层统一处理。听起来不复杂但真正落地后你就知道以前的“谁强用谁”方案有多脆弱。1. 先聊明白为什么要做“模型体系编排层”这套组合1.1 模型碎片化问题不在模型少而在没人管大概一年前我接手了一个内部 AI 中台项目。当时局势很有意思大模型 API 一堆开源模型随便跑本地团队里每个人手里都攥着三四个模型 Key看起来资源很丰富用起来却是一团乱麻。最典型的场景是——我们做一个文档问答助手最开始只调用一个通用大模型效果还行。后来发现代码类问题必须换代码模型数据分析又得换专用模型。于是业务代码里开始出现大量 if/else判断用户问的是什么然后 switch 到不同的模型 API。这还不是最可怕的最可怕的是每个模型的上下文格式不一样、返回结构不一样、超时行为不一样。有的模型喜欢把结果塞在 markdown 表格里有的喜欢用 JSON 输出有的动不动就截断。业务团队为了适配这些差异维护成本已经超过了模型本身的调用成本。我后来复盘问题的本质是我们做的是“多模型接入”而不是“多模型管理”。接入只要连上 API 就行管理却要解决路由、状态、容错、安全、审计这一整套问题。只做接入不做管理模型越多系统越脆弱。就好比家里装了好几个品牌的家电但没有一个统一的控制面板每个电器都要自己跑过去开关时间久了肯定乱套。1.2 编排层真正管的是“任务”不是“模型”想明白这一点后我重新画了架构。关键转变是把模型当作能力算子把任务当作一等公民。之前的设计思考是“这个请求该用哪个模型”现在的设计思考是“这个任务需要哪些能力按什么顺序组合”。编排层因此被单独拎出来承担四类核心职责模型路由根据任务类型、输入特征、成本预算、延迟要求把任务分给合适的模型。这不是简单的规则映射而是要支持动态策略调整。上下文管理跨模型协同的时候不能把原始对话一股脑传给下游模型。要有一套摘要、裁剪、字段提取机制让上下文在不同模型之间可搬运、可重构。工具编排大模型本身不产生结构化动作它输出的是“意图”。编排层负责把意图转成真正的工具调用并对调用结果做校验和回填。安全策略在触发模型前、执行动作前、输出内容前分别设置独立的安全管控点。安全逻辑不能依赖模型自觉必须由编排层强制执行。这样设计之后一个非常明显的收益是业务侧不再关心“背后是哪个模型”。他们只需要描述任务的输入输出剩下的路由和调度全由编排层消化。我们后来换过一次主力模型业务代码零改动只改了编排层的路由配置。那一刻我才觉得这套架构确实值了。1.3 一个中心化的编排层会带来什么问题当然中心化编排层也不是没有代价。最大的问题就是它必须足够健壮否则所有模型能力都会被它拖累。我们刚上线那阵子编排层服务只要抖动一下底下所有模型调用跟着全部超时。这里要提一个很关键的认知编排层不是一个“转发网关”它本身是有业务状态的。网关是无状态的请求进来转发出去就完了。但编排层要跟踪任务状态、记录上下文摘要、管理工具调用的中间结果。所以它的设计必须有独立的存储、缓存和容错机制不能跟普通 API 网关混为一谈。我见过很多团队在这个地方翻车。他们用网关的思路搭编排层结果任务进行到一半编排服务重启了所有状态丢失任务只能从头开始。正确做法是给每个任务分配一个持久化状态对象编排节点重启后可以从状态对象恢复执行进度而不是让用户重新发起请求。2. 613 混合模型模型矩阵怎么搭才不浪费2.1 六个主力模型按任务切分而不是按名气切分“55873 生态”这个名字是我们内部架构评审时随手编的编号后来用顺口了就干脆当作整个生态的代称。其中 613 是模型矩阵的核心形态先来看 6 个主力模型怎么选、怎么配。我们的做法是先把业务任务分成六类再为每一类挑一个主力模型模型编号负责任务类型选型要点M1通用对话与问答综合能力强、指令遵循稳定、上下文窗口大M2代码生成与解释代码能力优先支持长代码上下文允许更大输出M3结构化信息抽取小体量但格式遵循好输出 JSON 稳定成本低延迟低M4长文本理解与摘要上下文窗口要求高具备多文档对比能力M5图像识别与多模态视觉编码能力强支持图文混合输入M6数据分析与图表生成数值推理能力好支持表格输入和图表代码输出选型的标准不是“谁最强就上谁”而是“谁最匹配这个任务类别的约束”。比如 M3 结构化抽取我们特意选了一个参数量不算大的开源模型因为它输出的 JSON schema 非常稳定很少出现字段缺失。而且这类任务调用量巨大如果用大模型成本根本扛不住。这里有一个特别容易被忽视的点主力模型不是一成不变的。大模型行业几个月就换一波年初的王者可能年中被开源模型追平。所以架构上必须支持“模型可替换”路由配置和生产代码完全分离。我们每个模型都用一个逻辑编号路由配置里把逻辑编号映射到具体的模型实例换模型就等于改一行配置。2.2 那个“1”调度底座模型不产出内容但决定走向6 个模型是干活儿的那“1”是干什么的它不产出内容只负责“判断、拆解、兜底”。我把它叫作调度底座模型它是整个编排层决策的核心大脑。具体来说调度底座模型承担三件关键任务意图归类与置信度评分用户请求进来后它不是简单判断“这是什么类型”而是要给出一个类型标签和一个置信度分数。置信度分数非常重要后续路由策略全靠它。复杂任务拆解把一个复杂请求拆成多个可执行子任务并编排成 DAG。比如“分析这份财报并生成摘要然后对比去年同期数据”会被拆成抽取、摘要、对比、生成四个子任务。异常情况兜底当主力模型返回结果不满足校验要求时调度底座模型负责二次处理。它可能重新组织请求、补充追问信息或者决定是否需要切换模型重跑。选择调度底座模型时我们更看重它的“稳定输出”而不是“创造力”。它不写代码、不生成文案、不做图片只是做判断和拆解所以要求它严格遵循输出格式。我们用的底座模型在训练时就强调过指令遵循和 JSON 输出能力实测下来它在拆解任务时很少出现格式跳脱的情况。有个细节值得说一下调度底座模型的上下文窗口不需要太大因为它处理的是“任务描述”级别的信息而不是原始长文档。如果它需要读长文我们会先在 M4 上做摘要再把摘要喂给它。这样既省钱又保证响应速度。2.3 三个辅助模型审核、压缩、参数化缺一不可“3”是三个辅助模型它们不直接面向业务但决定了上面所有模型能不能被安全、高效地使用。第一个是安全审核模型专门做内容安全与合规检查。它独立于其他所有模型由安全团队单独维护。为什么要独立因为模型不能既当运动员又当裁判。如果让主力模型自己判断自己输出是否安全它很可能会“自我放行”——毕竟模型对自己的生成内容是有偏好的。独立的安全审核模型可以用一套固定的审查标准不参与业务生成只输出“通过/拒绝/降级”三类结论。第二个是摘要与记忆模型负责上下文压缩和记忆管理。跨模型协同中最头疼的就是上下文传递原始对话动辄几千 token直接传给下一个模型既浪费钱又容易让模型“迷失重点”。摘要模型的任务是把上一个模型的输出压成一个结构化摘要包含“结论、关键数据、未解决问题”三个部分下游模型只需要读摘要就能继续干活。这部分我后面会详细讲因为踩坑最多。第三个是工具参数生成模型专门负责把自然语言请求转成工具调用的结构化参数。这个模型被单独拎出来是因为工具调用的参数错误率在高并发场景下会急剧放大。让主力模型在干正事的同时还要抠参数格式效果往往不如一个专职模型。它只干一件事输入用户请求和工具 schema输出合法的调用参数 JSON。2.4 模型路由的双阈值策略与成本账模型矩阵搭好之后真正的难点是路由。如果只按“任务类型固定映射”那等于没做路由因为很多请求是跨类型的。我们采用的方案是基于“置信度双阈值”的动态路由策略高置信度区间置信度 ≥ 0.85直接路由到对应的专业模型。这个区间说明调度底座模型对意图判断非常笃定不需要其他模型介入。中等置信度区间0.6 ≤ 置信度 0.85路由到通用对话模型兜底。因为专业模型的确很强但如果不确定是不是这个类型强行调用专业模型反而可能答非所问。低置信度区间置信度 0.6不直接调用任何模型由编排层向用户发起澄清追问或者让调度底座模型通过上下文推断。尽量避免在意图不明时乱开枪。这套策略跑下来效果非常直接专业模型的调用准确率提升了通用模型的负载降了整体成本下降了大概 40%。算账的逻辑是以往所有请求都走最贵的大模型实际上有将近一半是简单抽取或格式转换任务用便宜的小模型足够。现在高频低难度任务走小模型低频高难度任务走大模型钱花得明明白白。关于成本还有一个容易被忽略的地方模型的输入输出 token 计价不对称。有些模型输入便宜输出贵有些反过来。路由策略里最好带上 token 价格的权重。我们的做法是把每个模型的单位成本折算成“分数”路由打分时同时考虑“任务匹配度”和“成本分”取加权最高的模型。3. 四层智能体架构编排层从感知到自进化的运转逻辑3.1 感知与意图解析层先治脏数据再谈理解四层智能体架构是从执行视角定义的第一层是感知与意图解析层。这一层做的事情看起来简单——接收用户输入、识别意图、提取实体——但实际跑起来最花时间的不是意图识别而是输入标准化。我们接收的输入五花八门有的用户直接贴一大段 HTML有的带 emoji 和多余符号有的把日期写成“周三”有的在文本里混入图片链接。如果这些脏数据直接进模型再强的模型也容易出错。所以感知层做了一个前置处理管线顺序是格式清洗去除不可见字符、统一换行符、标准化日期格式。类型识别区分文本、图片、表格、语音转写结果。字段抽取先做一轮轻量级实体识别把时间、地点、人名、金额等关键字段提前抽出来。意图打分交给调度底座模型输出任务类型和置信度。这层设计最关键的一点是不要让大模型处理原始输入。很多人图省事直接把用户输入丢给大模型让它“自己读、自己理解”。其实做一个几百行的标准化脚本就能把后续所有模型的幻觉率降下一大截。比如日期格式不统一的时候模型经常把“周三”理解成“本周三”还是“下周三”提前标准化成具体日期问题直接就消失了。3.2 任务规划与调度层DAG 节点白名单是底线第二层是整个编排层最核心的部分任务规划与调度层。调度底座模型在这里发挥主要作用它接收到感知层传来的意图标签和置信度然后做任务拆解。一个复杂任务会被拆成一个有向无环图DAG每个节点代表一个子任务边代表依赖关系。比如“按季度汇总销售数据并生成分析报告”会拆成数据查询节点 → 数据分析节点 → 报告生成节点前两个节点执行完才能执行第三个。这里有一个我强烈建议执行的约束DAG 的节点类型必须是白名单机制。我们预设的节点只有四类模型调用节点调用某个主力模型。工具节点执行外部 API 调用或数据操作。条件分支节点根据上一步输出决定下一步走向。合并节点把多个子任务的结果合并成一个。为什么要卡这么死因为大模型在自由发挥时偶尔会生成编排层根本不支持的节点类型比如“等待节点”“循环节点”“人工审批节点”。如果编排层看到不认识的节点就执行轻则报错重则流程失控。白名单机制相当于给模型的“创造力”上了一道锁它只能在预设框架内做拆解这恰恰是生产系统需要的确定性。调度执行上还要注意三个机制超时、重试、熔断。每个节点都要设定超时时间超时后按策略重试重试仍失败就触发上游熔断避免一个故障节点拖垮整条链路。我们最初只做了超时没做熔断结果有一次工具节点因为上游服务故障挂起所有任务都在反复重试把队列全堵死了。后来加了熔断器效果立竿见影。3.3 执行与工具调用层schema 校验比模型更可靠第三层是执行与工具调用层它负责真正干事儿。DAG 里的模型调用节点会在这里发起模型请求工具节点会在这里执行外部 API 调用。工具调用的协议设计是一个大学问。我们统一用一套工具描述格式工具名称、描述、入参 schema、权限范围、结果回传格式。模型看到这个描述后输出对应的调用参数。但注意模型输出的参数不能直接拿去执行必须先过一层 schema 校验。为什么必须校验因为模型在生成参数时经常出幺蛾子。最常见的错误包括布尔字段传成字符串“true/false”、数字字段带上了单位“5000元”、枚举值大小写不对、必填字段缺失。这些错误如果不在执行前拦截执行层就会拿到一份非法的参数去调外部接口轻则返回错误重则产生脏数据。我们的做法是在工具执行前加一个“参数归一化器”专门处理类型转换、枚举映射、必填项检查。归一化器是纯代码实现不经过任何模型可靠性远高于让模型自己修正。另一个执行层的常见坑是工具返回结果过大。比如一个查询工具返回了几万行数据如果全塞给模型做后续判断上下文瞬间就被撑爆了。解决方法是工具执行完先对结果做摘要和截断只把摘要和关键字段传给后续节点。压缩的时机和粒度直接决定了大模型的上下文够不够用。3.4 反馈与自进化层没有数据闭环的编排不叫体系第四层是反馈与自进化层。这一层在最初设计时几乎被我们砍掉因为看起来不产生直接业务价值。后来发现没有这一层整套体系就像没有仪表盘的汽车跑得再快也不知道该什么时候转弯。反馈层做的事情是把每次任务的完整生命周期记录下来包括任务输入与最终输出路由决策结果哪个模型被选中置信度多少每个节点的耗时和 token 消耗任务是否成功、失败在哪个节点用户有没有对结果做更正或反馈。这些数据不会立刻反哺线上系统而是进入一个离线样本池。我们每周做一次评测回归从样本池里捞一批本周新增的失败案例用固定的评测集跑一遍看看路由策略、提示词、模型版本这些改动有没有把老功能改坏。这个闭环带来的收益非常大。我们上线四个月通过持续迭代调度底座模型的提示词和路由阈值整体任务成功率从 76% 提升到了 92%。这里要强调一下92% 不是凭空优化出来的每一个百分点都是靠失败样本一口一口喂出来的。没有反馈层我们根本不知道任务失败的具体原因是什么只能靠用户投诉去发现问题。4. 安全策略编排智能体体系里最不该省的一层4.1 为什么“靠模型自觉”在智能体场景里会翻车如果你只是做一个对话机器人安全策略主要靠大模型自身的内容过滤就够了。但智能体不一样智能体会调用工具、操作数据、触发外部动作。一句“帮我删除所有测试数据”如果被模型理解成合理的工具调用就真的可能把数据删了。安全策略不能被模型自己掌握因为模型的输出是不确定的。你没法保证一个模型在复杂上下文里始终保持正确的安全判断。所以必须把安全逻辑从模型里剥离出来放到编排层用代码强制执行。我们内部定了一个原则所有工具调用的权限校验不得早于模型输出之后也不得晚于工具执行之前但它必须独立于模型判断。翻译一下就是模型可以建议调用某个工具但能不能调用、怎么调用由编排层的安全策略决定模型说了不算。4.2 安全策略的四个控制点基于这个原则我们在四层架构里分别布了安全防线输入侧防线脱敏手机号、身份证号、地址、注入检测识别提示词注入、越权检测检查用户是否有权访问输入中提到的资源。规划侧防线校验 DAG 节点类型是否在白名单内、工具是否在用户权限范围内、是否有非法依赖关系。执行侧防线工具调用二次确认、最小权限执行每个工具调用都用独立临时凭证、沙箱环境不可信代码在隔离容器里运行。输出侧防线内容过滤敏感词、违规内容、敏感信息检测、输出格式校验。这套防线布下来效果是即使在规划阶段模型被诱导生成了异常节点执行阶段也会被权限校验拦住。我们做过一次攻防演练用提示词注入试图让智能体执行“给所有用户发送邮件”结果在规划侧被白名单机制拦截在输入侧也被注入检测拦了一道。双保险确实比单保险稳得多。4.3 安全策略的编排不是写死安全策略如果只是硬编码在代码里那就失去了灵活性。今天想对某个新功能加一个限制难道还要改代码发版所以我们把安全策略本身也做成了“可编排”的。具体形态是三层模型策略单元最原子的规则比如“禁止调用删除类工具”“禁止访问非授权数据源”“输出中不得包含身份证号”。策略集一组针对同一场景的策略单元组合。比如“数据分析场景策略集”包含数据脱敏、查询白名单、结果漂白三条规则。策略编排按优先级把多个策略集串起来定义命中后的动作——是直接拒绝、降级、还是转人工审批。这样做的好处是运营人员可以动态调整策略而不需要动一行代码。比如某个新功能上线初期我们会对高危动作启用“影子模式”策略策略照常评估并记录日志但不实际拦截。等观察几天确认该动作在业务中是合理需求后再切换成“拦截模式”或“审批模式”。策略变更的灰度也很重要。我们要求任何策略变更先用历史请求数据做一次回放看看新策略会误伤多少正常请求。回放评估通过后再按流量比例灰度发布。这里踩过一次坑有一回我们把关键词过滤阈值调严了历史回放时没发现问题上线后抖音小助手生成的文案大量被拦截因为新阈值把“免费”“优惠”这样的词也当成了营销敏感词。后来回放逻辑里增加了“按业务场景分类统计误伤率”问题才得到根治。4.4 安全策略的置信度等级设计最后说一下安全策略里的“置信度等级”。这是一个很实用的设计每一条策略命中时不是非黑即白地“拒绝”或“放行”而是输出一个风险置信度。高置信度风险直接拦截日志记录原因。中置信度风险降级处理比如把“自动执行工具”降级为“生成待人工审批的任务”。低置信度风险放行但打上标记后续排查时重点关注。这样做的好处是避免“一刀切”。业务上有些操作确实处于灰色地带比如“批量删除过期测试数据”看起来危险但如果是测试环境的清理任务其实完全合法。用置信度等级处理既不会放过真正的高风险操作也不会因为过度拦截把正常业务卡死。5. 实操落地中的常见问题与排查技巧5.1 跨模型上下文断裂“摘要传递”方案多模型协同最常遇到的问题就是上下文断裂。一个任务往往要经过三四个模型每个模型都需要一定的上文信息但上文不能无脑传递否则 token 消耗会爆炸。我们的方案是“三段式摘要传递”。上游模型输出后摘要模型先把结果压缩成三部分结论这个子任务得到了什么结论不超过 200 字。关键数据结构化字段比如数值、日期、实体名称尽量用 JSON。未解决问题下一个模型需要继续处理的事项。下游模型只读取这三段摘要不接触原始输出。实测下来摘要控制在 500 字以内时下游模型的混淆率最低。超过 800 字后混淆率开始明显上升。这个规律其实也好理解摘要越短信息密度越高模型抓重点的能力才能发挥出来。5.2 编排层的性能瓶颈两层缓存设计做编排的人很容易忽略一个事实编排层本身是有性能开销的。我们最初版的设计每次模型调用前都要请求一次“路由决策服务”结果路由决策本身成了性能瓶颈。一个任务如果有 5 个子任务光路由决策就消耗了任务总耗时的 30%。优化方案是两层缓存第一层请求级缓存。按输入文本的哈希值缓存路由决策结果。同一个问题再次被问到直接命中缓存。第二层用户级缓存。按用户的常用路由偏好缓存。比如某用户经常做数据分析类任务那他的请求大概率还是会走数据分析模型。实测下来命中缓存后单次路由耗时从平均 220ms 降到 35ms整个任务链路的 P95 延迟几乎降了一半。如果你也在做编排层性能优化的优先级排序应该是先做缓存再做并发最后才考虑优化模型本身的响应速度。因为模型响应速度上限摆在那里而编排层的开销往往是我们可以控制的。5.3 高频问题排查速查表这里整理了一份我们在生产环境里最常遇到的排查手册希望帮你少走弯路。现象大概率原因排查路径某模型突然批量报错上游厂商限流或服务故障先看限流日志做指数退避重试不要硬重试确认是服务端故障后切换备用模型生成长文时中途截断最大输出 token 设太小或上下文被撑爆检查 max_tokens 设置改用输出分流分段生成再拼接安全策略误伤正常请求策略阈值设置不合理查看命中策略的置信度等级按业务场景分类统计误伤率再调整阈值工具调用参数格式错误模型生成的参数未做归一化检查是否经过参数归一化器补充 schema 校验的兜底逻辑任务失败但找不到原因缺少完整链路日志排查是否有任务级状态持久化日志是否记录了每个节点的输入输出摘要5.4 关于模型部署与并发的一些建议最后聊一下部署层面的观察。如果主力模型都走外部 API编排层的重点在于路由和容错。但如果自己部署开源模型有几个额外建议第一小模型和专用模型优先本地部署。像 M3 结构化抽取、摘要模型这类任务量大但对效果要求不极端的本地部署可以显著降低成本。大模型尤其是通用对话和代码模型量没起来之前没必要急着本地部署先用 API 撑住。第二模型推理的并发问题集中在“请求排队”而不是“显存不够”。我们用 vLLM 这类推理框架部署本地模型时发现关键配置是最大并发数和最大 batch 数。并发数设得太小响应慢设得太大GPU 显存溢出。经验值是先按机型显存估算一个理论值然后压测 20 分钟看 P95 延迟和显存占用的交叉点取那个平衡点。第三本地模型最好都接一个统一的推理网关对外暴露兼容接口。这样换模型的时候编排层完全无感。我们最开始每个模型独立接口每次换模型都要改编排层代码后来花了半天时间统一了推理网关后面就轻松了。写在最后这套体系还能怎么扩展这套 613 混合模型加四层智能体架构的体系目前已经稳定运行了一段时间。我个人最大的体会是模型永远在更新但编排的思想是可复用的。不要指望某一天出现一个模型能解决所有问题混合模型加编排层加安全策略的组合会是未来相当长一段时间里 AI 平台建设的主旋律。最后再分享一个小技巧在搭建编排层的第一天就把“每次任务的路由决策、token 消耗、失败原因”全部埋点记录。这些数据后期价值极高不仅能指导路由策略的调优甚至能反过来告诉你是不是到了该换主力模型的时候。宁可多花一点日志存储的钱也不要等出了问题再回头翻流水账。数据永远是这套体系里最值得投资的部分。