1. 从“613”说起这套混合模型体系到底在解决什么问题第一次看到“613 混合模型”这个说法很多人会以为是某种版本号或者内部代号。其实它描述的是一套模型能力分层调度的思路6 个通用基座模型负责广度覆盖1 个领域精调模型负责深度穿透3 个轻量专用模型负责高频低延迟场景。这套组合不是拍脑袋定的而是被真实业务逼出来的。我接触过不少团队早期都倾向于“一个大模型打天下”。想法很朴素既然通用模型什么都能聊那就全部走它省得维护多套。结果上线两周就崩了——客服场景里用户问“帮我查一下上个月订单”通用模型答得头头是道但就是查不了库代码补全场景里模型生成的片段语法对但业务逻辑全错而一些简单的意图分类请求走大模型一次要等两三秒成本还高得离谱。问题的根子在于通用能力不等于场景能力。一个模型在公开评测集上跑分高不代表它在你的业务闭环里能直接干活。613 的本质是把“模型选型”从一次性决策变成持续编排——不同请求走不同通道该重的重、该轻的轻。具体拆开看6 个通用基座覆盖文本理解、代码生成、多轮对话、结构化抽取、翻译润色、知识问答六个方向。它们不直接面向终端用户而是作为“能力池”被上层智能体按需调用。选型时重点看三项上下文窗口是否够用、函数调用Function Calling格式是否稳定、流式输出是否支持中断恢复。1 个领域精调模型这是整套体系的“压舱石”。它基于业务私有数据做指令微调专门处理那些通用模型容易“说外行话”的场景。比如中医问答场景通用模型会把“肝郁脾虚”解释成西医的肝脏问题而精调模型能准确关联到中医辨证体系。精调数据的质量比数量重要得多五万条干净标注数据的效果往往好过五十万条爬来的脏数据。3 个轻量专用模型通常包括一个意图分类小模型、一个实体抽取小模型、一个安全审核小模型。它们参数量小、推理快部署在离用户更近的位置。意图分类模型负责在请求进入大模型之前就判断“这是闲聊还是查数据”实体抽取模型负责把“上个月”解析成具体日期范围安全审核模型负责在输出前做最后一道过滤。提示613 不是固定配方。有的团队是 422有的是 814核心逻辑是“通用能力池 领域纵深 轻量前置”。数字不重要分层调度的思想才重要。这套体系解决的核心问题是成本、延迟、准确率的不可能三角。全走大模型准确率尚可但成本和延迟爆炸全走小模型延迟低但复杂问题答不了。混合调度的价值在于让 80% 的简单请求走轻量通道15% 的中等请求走通用基座只有 5% 的硬骨头才动用领域精调模型。实测下来整体推理成本能压到纯大模型方案的 30% 左右首 token 延迟从 2.5 秒降到 800 毫秒以内。2. 四层智能体架构编排层才是真正的“大脑”模型选好了下一个问题是谁来决定哪个请求走哪个模型答案是智能体编排层。很多人把智能体理解成“会调工具的聊天机器人”这个理解太窄了。在 613 体系里智能体是一套四层分工结构每一层有明确的职责边界。2.1 接入层请求进来的第一道分拣接入层不做任何智能决策它只干三件事鉴权、限流、请求标准化。听起来简单但这里有个容易踩的坑——请求体格式不统一。有的客户端传 JSON有的传 form-data有的把图片 base64 塞在文本字段里。如果接入层不做归一化后面每一层都要写兼容逻辑维护成本会指数级上升。我的做法是在接入层定义一个内部请求协议所有外部请求先转成这个格式再往下传。协议里必须包含的字段有request_id全链路追踪用、user_tier用户等级决定走哪档模型、scene_tag场景标签如“客服”“代码”“问数”、raw_input原始输入、attachments附件列表。这个协议一旦定下来就不要轻易改改一次全链路都要跟着动。2.2 路由层意图识别与模型选择路由层是编排层的核心。它拿到标准化请求后先调轻量意图分类模型判断场景再根据场景标签和用户等级决定走哪条模型通道。这里的关键设计是路由表可配置而不是硬编码在代码里。路由表长这样场景标签用户等级首选通道兜底通道超时阈值闲聊免费轻量模型通用基座1s查数据付费领域精调通用基座3s代码生成付费通用基座领域精调5s安全审核全部轻量审核模型通用基座500ms路由层还要处理一个棘手问题模型降级。当首选通道超时或返回错误时要能自动切到兜底通道而不是直接把错误抛给用户。降级策略要区分“可重试错误”和“不可重试错误”——超时和限流可以降级参数错误和内容违规不能降级。2.3 执行层工具调用与上下文管理执行层负责真正调模型和调工具。这里最容易被低估的是上下文管理。多轮对话场景下如果把全部历史消息都塞给模型token 消耗会迅速失控。我的经验是维护一个滑动窗口加摘要的混合策略最近 5 轮保留原文更早的轮次用轻量模型压缩成摘要摘要长度控制在 200 字以内。工具调用方面执行层要维护一个工具注册表。每个工具定义包含工具名、描述、参数 schema、超时时间、是否幂等。模型返回工具调用请求后执行层先做参数校验校验通过才真正执行。这里有个血泪教训永远不要信任模型返回的参数格式。我见过模型把日期返回成“下周三”这种自然语言也见过把数字返回成字符串。参数校验层必须做类型强转和边界检查。2.4 反馈层日志、评估与持续优化反馈层是很多团队会忽略的一层但它决定了整套体系能不能持续变好。反馈层要收集三类数据请求日志谁在什么时候问了什么、模型输出哪个模型答了什么、用户反馈点赞点踩、是否采纳、是否转人工。这些数据不是存下来就完了要定期做离线评估。具体做法是每周抽 500 条真实请求人工标注“理想回答”然后让当前路由策略和候选路由策略分别跑一遍对比准确率、成本、延迟三个指标。如果候选策略在准确率不降的前提下成本降低 15% 以上就灰度切换。注意反馈层的数据要脱敏后再用于评估。用户 ID、手机号、地址等敏感信息必须在入库前做哈希或掩码处理。这不是合规要求那么简单而是防止内部人员无意中看到用户隐私。3. 安全策略编排不是加个过滤词就完事安全策略编排是整套体系里最容易被做成“摆设”的部分。很多团队的做法是在输出端加一个敏感词过滤命中就返回“抱歉我无法回答”。这种做法有两个问题一是误杀率高正常讨论医学问题可能被当成违规二是漏杀率高换个说法就能绕过。在 613 体系里安全策略是分层嵌入的而不是只在最后加一道闸。3.1 输入侧意图预判与风险分级输入侧的安全检查在路由层之前完成。轻量审核模型会对用户输入做三分类安全、可疑、高危。安全请求直接放行可疑请求打上标记继续处理但输出侧会加严审核高危请求直接拦截并记录。这里的关键是风险分级而不是二值判断。把请求分成“安全/可疑/高危”三档比“通过/不通过”两档灵活得多。可疑档的请求可以正常走流程只是输出侧多一道检查这样既不会误杀正常用户又能对边缘情况保持警惕。3.2 推理侧系统提示词与工具权限隔离推理侧的安全策略体现在两个地方系统提示词和工具权限。系统提示词里要明确写清楚“你不能做什么”比如“你不能执行任何删除操作”“你不能访问用户未授权的数据”。但光靠提示词不够因为模型可能被诱导绕过。真正的防线是工具权限隔离。每个智能体实例在初始化时绑定一个权限集权限集决定了它能调用哪些工具、能访问哪些数据表、能执行哪些操作。比如客服智能体只能读订单表不能写代码智能体只能读代码仓库不能推代码。权限集在编排层强制执行模型返回的工具调用请求如果超出权限集直接拒绝并记录告警。3.3 输出侧多模型交叉审核输出侧的安全检查不是单模型判断而是多模型交叉审核。具体做法是主模型生成回答后同时送给两个轻量审核模型一个查内容合规一个查事实一致性。两个模型都通过才返回给用户任一不通过则触发重生成或降级回复。事实一致性审核特别重要。我遇到过模型在回答“如何申请退款”时编造了一个不存在的退款入口用户照着操作找不到地方直接投诉。事实一致性审核模型会对比回答内容和知识库里的标准流程发现不一致就拦截。审核维度审核模型不通过处理误杀补救内容合规轻量审核模型 A拦截并记录人工复核队列事实一致轻量审核模型 B触发重生成降级到知识库直答格式规范规则引擎自动修正无需人工3.4 安全策略的动态调整安全策略不是定下来就不变的。要建立策略效果监控每天统计拦截率、误杀率、漏杀率通过用户投诉和人工抽检发现。如果某个策略的误杀率超过 5%就要放宽阈值如果漏杀率上升就要收紧。动态调整的另一个维度是场景差异化。医疗场景的安全阈值要比闲聊场景高得多代码场景对“执行”类操作的审核要比文本场景严。这些差异要体现在策略配置里而不是一套规则打天下。4. 落地实操从零搭一套最小可用体系前面讲的是架构思想这一节讲怎么落地。我以“问数智能体”为例走一遍从环境准备到跑通链路的完整过程。问数场景的特点是用户用自然语言问数据智能体要理解意图、生成查询、执行并返回结果。4.1 环境准备与模型接入第一步是确定模型接入方式。613 体系里模型来源可能很杂有的走 API有的本地部署有的走推理框架。我的建议是统一接入层所有模型都通过一个内部网关调用网关负责协议转换、鉴权、限流、日志。网关的核心接口定义如下class ModelGateway: def invoke(self, model_id: str, messages: list, tools: list None, stream: bool False, timeout: float 5.0) - ModelResponse: model_id: 模型标识如 general-1, domain-medical messages: 标准消息列表 [{role: user, content: ...}] tools: 可用工具列表None 表示不启用工具调用 stream: 是否流式返回 timeout: 超时秒数 pass这个接口看起来简单但内部要做很多事根据 model_id 查路由表找到实际端点、把标准消息转成目标模型要求的格式、处理流式和非流式的差异、超时后触发降级。把这些复杂性收在网关里上层编排逻辑就干净了。4.2 意图分类模型的训练与部署问数场景的意图分类不需要大模型一个基于 BERT 的小模型就够了。训练数据从历史日志里挖标注类别包括查单条数据、查聚合数据、查趋势、对比分析、无关请求。训练时有个技巧负样本要足够多样。如果负样本只有“今天天气怎么样”这种明显无关的模型会把“帮我查一下类似订单”也判成无关。负样本要覆盖各种边缘情况模糊指代、多意图混合、带情绪的表达。部署时用 ONNX Runtime 或类似推理引擎单次推理控制在 50ms 以内。模型文件不大可以随服务一起打包不需要单独的模型服务。4.3 工具调用的参数校验与执行问数智能体的核心工具是query_database参数包括表名、字段列表、过滤条件、聚合方式、排序、限制条数。模型生成的参数必须经过严格校验def validate_query_params(params: dict) - tuple[bool, str]: # 表名白名单 if params[table] not in ALLOWED_TABLES: return False, f表 {params[table]} 不在允许列表中 # 字段名白名单 for field in params[fields]: if field not in ALLOWED_FIELDS[params[table]]: return False, f字段 {field} 不存在 # 过滤条件类型检查 for cond in params.get(filters, []): if cond[op] not in (eq, gt, lt, in, like): return False, f不支持的操作符 {cond[op]} # 限制条数上限 if params.get(limit, 100) 1000: return False, 查询条数超过上限 return True, 校验通过后才拼 SQL 执行。拼 SQL 时用参数化查询不要字符串拼接防止注入。执行结果返回后再交给模型做自然语言总结。4.4 全链路联调与压测链路跑通后要做压测。压测重点看三个指标P99 延迟、错误率、降级触发率。P99 延迟超过 5 秒就要查是哪一层慢错误率超过 1% 要看是模型超时还是工具执行失败降级触发率超过 10% 说明首选通道容量不够。压测时用真实请求回放不要用构造的假数据。真实请求里的长尾分布是假数据模拟不出来的。我见过压测时 QPS 跑到 1000 很稳上线后真实流量一来就崩因为真实请求里有大量超长文本和复杂工具调用。提示压测环境要和生产环境隔离但模型版本、工具版本、配置参数要和生产保持一致。否则压测结果没有参考意义。5. 那些只有踩过才知道的坑架构讲完了实操也走了一遍最后分享几个我在落地过程中真实踩过的坑。这些坑在官方文档里找不到但每一个都让我多加了至少两天的班。5.1 模型输出的“格式漂移”模型在测试环境返回的 JSON 格式很稳定上线后偶尔会多一个逗号、少一个引号或者把数字写成字符串。一开始我以为是模型版本问题后来发现是温度参数在作怪。测试时温度设的 0.1上线后为了“更自然”调到了 0.7格式稳定性直线下降。解决办法是结构化输出和自然语言输出分离。需要 JSON 的地方温度设 0 或 0.1并且用 JSON Schema 做校验需要自然语言的地方温度可以高一些但输出不参与程序解析。不要指望模型在高温下还能稳定输出结构化数据。5.2 工具调用的“幻觉参数”模型会编造不存在的工具名或者给工具传不存在的参数。我遇到过模型调用query_database时传了一个sort_by参数但工具定义里根本没有这个参数。模型大概是觉得“查询应该能排序”就自己加了一个。解决办法是在工具注册表里加严格模式模型返回的工具调用必须完全匹配注册的 schema多一个字段少一个字段都拒绝。拒绝后把错误信息返回给模型让它重新生成。通常重试一次就能对。5.3 上下文窗口的“隐形消耗”系统提示词、工具定义、历史消息、当前输入这些加起来很容易超过模型上下文窗口。更麻烦的是不同模型的窗口大小不一样路由到不同模型时可用空间也不同。我的做法是在编排层维护一个token 预算表每个模型的最大窗口、系统提示词占用、工具定义占用、预留输出空间剩下的才是历史消息和当前输入可用的。超预算时自动触发摘要压缩或历史截断。这个预算表要随模型版本更新而更新不能写死。5.4 安全审核的“过度拦截”安全审核模型刚上线时误杀率很高正常问“这个药有什么副作用”被拦截因为模型把“副作用”关联到了“危险”。后来调整了策略安全审核模型只做风险打分不做最终决策。打分超过高阈值才拦截中等阈值交给人工复核低阈值放行。这样误杀率降到了可接受范围。5.5 降级链路的“雪崩效应”首选通道超时触发降级兜底通道瞬间涌入大量请求也超时然后所有请求都失败。这是典型的雪崩。解决办法是给降级加熔断和限流兜底通道的容量是有限的降级请求超过容量时直接快速失败而不是排队等超时。快速失败至少能让用户立刻知道“稍后再试”比等 10 秒后报错体验好。坑点表象根因修复方案格式漂移JSON 解析失败温度参数过高结构化输出温度设 0幻觉参数工具调用报错模型自行发挥严格 schema 校验窗口超限请求被截断token 预算未管理动态预算表 摘要压缩过度拦截正常请求被拒审核模型二值判断风险打分 分级处理雪崩效应大面积超时降级无熔断熔断 快速失败6. 这套体系还能怎么扩展613 和四层架构不是终点。我目前在做两个方向的扩展一个是模型热切换一个是跨场景编排。模型热切换是指在不重启服务的情况下替换某个通道的模型。比如通用基座模型出了新版本我想先灰度 10% 流量过去看看效果。这要求网关支持按比例路由并且能实时对比两个版本的输出质量。实现上可以用配置中心下发路由权重网关监听配置变化后动态调整。跨场景编排是指一个请求可能横跨多个场景。比如用户说“帮我查一下上个月销售额然后生成一份报告发给张总”。这一个请求里包含了问数、报告生成、邮件发送三个场景。当前的编排层是按单场景设计的跨场景需要引入任务分解和子任务编排。我的思路是在路由层之上加一个规划层把复杂请求拆成子任务每个子任务走各自的场景通道最后汇总结果。这两个方向都还在迭代中等跑稳了再单独写一篇分享。如果你也在搭类似的体系建议先把单场景链路跑通跑稳再考虑跨场景。单场景都没跑顺就上跨场景排查问题时会非常痛苦。