先说个我在设计这套体系时的切身感受每次跟人聊AI 模型完整体系大家的第一反应都是又要堆大模型了但真正落到生产环境你会发现问题的关键从来不是某一个模型的聪明程度而是一堆模型怎么分工、怎么协作、怎么被安全地编排起来。这篇文章是技术系列的第 5 篇聊聊我们内部代号55873 生态里沉淀下来的一套做法613 混合模型 × 四层智能体架构 × 安全策略编排。简单说就是用 6 个垂直模型负责感知与抽取1 个核心大模型负责推理与生成3 个辅助模型负责安全、路由和质量控制在这套模型体系之上再架设一层四层结构的智能体编排层把能对话升级成能干活最后用一套安全策略编排机制把工具调用、上下文访问和输出内容全部管起来。这套东西适合谁如果你正在做智能体平台架构设计或者准备把 AI 代理助手接到自己的业务系统里再或者你手里有几个模型但不知道怎么组合、怎么管权限那这篇应该能给你一些能直接抄作业的思路。1. 为什么非要做613混合模型纯大模型路线跑不通的三个原因在拆解 613 之前得先聊清楚一个底层问题为什么不用一个超大模型包打天下这直接决定了整个架构的走向。1.1 大模型万能论的反面我见过太多团队一开始都迷信只要 GPT-5 级别的模型够强什么任务都能做。但真正上生产后现实会给你三记耳光第一成本爆炸。一次通用大模型调用的成本是垂直小模型的几十倍。如果每一项任务都走大模型光推理费用就能吃掉整个项目的预算。我们线上有一个问数智能体早先所有请求都走大模型一个月账单下来财务直接找我谈话。第二延迟不可控。大模型的推理延迟通常在秒级到十几秒但很多场景比如实时意图识别、敏感词过滤、实体抽取需要毫秒级响应。让大模型做这些事体验上就是灾难。第三精度不够专。通用模型在什么都会一点的同时往往意味着什么都不够精。让它做法律条款的要素抽取或者医疗问答的辨证分型效果永远不如一个针对性训练过的垂直模型。所以混合模型的核心思路就是一句话让最合适的模型做最合适的事大模型只做那些真正需要智能的事。1.2 613 的具体分工我们的613不是拍脑门定的是演化出来的——从最开始一个模型硬扛到后来慢慢拆分最终沉淀成这套组合。6 个垂直模型负责感知与抽取类任务特点是轻量、快、针对性强编号垂直模型负责任务选型考量M1文本意图分类模型识别用户意图大类查询、操作、闲聊、投诉用蒸馏后的 200M 级模型单次推理 5ms 以内M2命名实体抽取模型抽取人名、地名、机构名、产品名、编号基于 BiLSTMCRF 或小规模 Transformer支持自定义词典M3情感倾向分析模型判断正/负/中性情绪用于工单分级线上语料微调比通用模型在业务数据上准 8~12 个点M4视觉特征模型ViT处理图像输入提取版面结构或关键区域用的是 ViT-Base 结构适合文档 OCR 之后的结构化M5向量化编码模型把文本转成 embedding供检索使用BGE 系列或同等水平的开源模型维度 768/1024M6语音/音频特征模型处理语音输入的情绪与端点检测仅在语音交互场景启用按需加载1 个核心大模型负责推理、生成、规划。它不做感知只做脑力活——理解上下文、拆解任务、生成答案、调用工具时做决策。可以根据预算选择闭源 API 或本地部署的 7B~70B 模型这个后面细聊。3 个辅助模型更像是保障组A1 安全审核模型对输入和输出分别做安全过滤拦截注入类内容、敏感话题和异常指令。A2 路由决策模型根据意图分类结果和上下文状态决定请求交给哪个模型、走哪条链路相当于交通警察。A3 质量评估模型对生成结果做幻觉检测和答案打分分数低于阈值就触发重试或降级方案。这里有个容易踩的坑很多团队把路由逻辑直接写在业务代码里用 if-else 硬编码。但我们的经验是路由本身也需要模型化因为意图之间存在大量边界情况规则写死了就没法应对变化。A2 不是用来替代规则而是用来兜底规则覆盖不到的模糊地带。1.3 模型之间怎么通信路由链路的执行顺序混合模型不是各干各的它们必须串成一条清晰的流水线。我们的请求链路大概是这样的请求到达后A1 输入安全审核先跑一遍不通过直接拦截不进模型。通过后M1 意图分类给出粗粒度标签同时M2 实体抽取从原文中取出关键实体。这两路结果汇总给A2 路由决策模型A2 结合用户的会话上下文和业务规则决定下一步是走检索链路M5 向量化、视觉链路M4、还是直接交给核心大模型。大模型生成答案后A3 质量评估模型打分。如果分数低就触发二次规划或换一个 prompt 模板重新生成。最终输出前A1 再做一次输出侧安全审核没问题才返回给用户。这条链路看起来长但因为 90% 的请求在 M1/M2 阶段就能确定走轻量链路真正的全链路深度推理只占一小部分所以整体成本可控。实测下来简单问答类请求的平均响应时间在 200ms 以内只有复杂推理请求才会走到秒级。2. 四层智能体架构把会对话升级成会干活模型体系只是底层能力真正让这套系统从聊天机器人变成智能体的关键是上面的编排层。我们把它拆成四层意图路由层、任务规划层、工具调用层、记忆与反思层。每一层各司其职又通过统一的数据结构串起来。2.1 第一层意图路由层这一层和 M1、A2 紧密配合但粒度更细。模型层做的是这句话是查询还是操作编排层的意图路由则要回答这个操作具体调哪个API、走哪个流程。举个例子用户说帮我把上个月的销售数据整理成周报发给团队。意图路由层要做三件事识别这是一个多步任务不是单次问答拆出关键参数时间范围上个月、数据对象销售数据、产出物周报、接收人团队把任务挂载到对应的会话状态机上进入规划层。这一层在设计上有两个容易忽略的点。一是状态管理每个任务都要有独立的会话状态避免多个任务之间互相污染上下文。我们用的是无状态接口 状态暂存区的方式状态以 JSON 结构存到临时存储里任务结束后异步写回持久层。二是超时与中断不是每个任务都能顺利完成意图路由层必须预设超时和人工转交的出口否则用户会被卡死在一个失败状态里。2.2 第二层任务规划层规划层是智能体和普通 RAG 问答最本质的区别。它负责把一个大目标拆解成可执行的小步骤。我们的规划层借鉴了经典的计划-执行循环但做了一些工程化改造步骤生成大模型根据目标生成候选步骤序列比如上面的查数据 → 算汇总 → 生成周报 → 发给团队。步骤校验每个步骤都要通过一个合法性检查确认它对应的工具是存在的、参数是完整的、依赖的数据源是可达的。这一步我们做了个工具注册表来支撑后面安全部分会详细说。动态调整如果某一步执行失败规划层需要回到现场重新规划而不是简单地报错返回。这里我必须强调规划层没必要追求一次性规划完美。我们早期花了很多精力让大模型一步到位生成最优化步骤后来发现完全是自找麻烦。现实是步骤在执行过程中会因为数据不对、权限不足、外部 API 超时等各种原因失败规划层真正要练好的是失败后如何优雅重规划。所以我们的规划层设计上允许最大三次重规划超过三次就转人工。2.3 第三层工具调用层如果说规划层是大脑工具调用层就是手和脚。这一层的核心工作有两件工具发现和参数绑定。工具发现不是把所有 API 都堆给大模型让它自己挑那样大模型会蒙。我们的做法是为每个工具写结构化的 OpenAPI 描述并在请求进来时先通过意图路由层的标签做一次工具预过滤只把当前任务可能用到的 3~5 个工具的描述塞进大模型的上下文。这样既省 token又降低模型选错工具的概率。参数绑定是更容易出 bug 的地方。大模型经常会把参数名搞错、把单位搞错甚至凭空捏造参数。我们的处理方式是定义严格的参数 Schema大模型只能从 Schema 里选值不允许自由发挥。对于日期、金额这类高敏感参数再加上一层规则引擎做校验——比如日期必须符合 YYYY-MM-DD 格式金额必须在合理区间内超过区间就得返回给用户二次确认。还有一个实操细节工具调用的超时和重试策略必须有。我们在工具调用层统一封装了超时控制默认 5 秒超时超时后自动重试一次再失败就熔断并返回规划层调整方案。这条经验是从一次事故里总结出来的当时某个工具接口慢智能体就一直干等结果大量会话卡死最后把整个服务拖垮了。2.4 第四层记忆与反思层这一层是最容易被忽视、但对体验影响最大的部分。没有记忆的智能体每次对话都是初见用户得反复重复自己的需求特别烦人。记忆层我们分两段短期记忆当前会话内的上下文包含用户最近几轮输入、中间产出的临时数据。用缓存存储会话结束就清。长期记忆跨会话的用户偏好、历史任务结果、常见纠偏记录。比如用户上次说周报用表格格式不要用列表这个偏好会被沉淀到长期记忆里下次生成周报自动应用。反思层则是对执行结果的复盘。每完成一个任务系统会生成一条结构化日志目标是什么、步骤是什么、哪一步耗时最长、哪一步失败过、用户最终是否满意。这些日志不光是运营分析的素材更是后面优化 prompt、优化工具参数的数据来源。我们曾经靠分析反思日志发现某类时间类请求的失败率特别高排查后发现是用户习惯说周末月底这种相对时间而工具只接受绝对日期——后来加了一个时间归一化模块失败率直接降了 60%。3. 安全策略编排整个架构里最容易被后补的硬地基如果前面说的是怎么让智能体能干安全策略编排就是保证它不乱干。我一直跟团队强调安全不是功能特性而是基础设施。等项目上线了再补安全层基本等于给一个已经装修完的房子改承重墙代价高到你不想面对。3.1 为什么智能体架构需要一套独立的安全编排层传统 API 的安全只要管好鉴权和限流就行但智能体不一样它多了一个巨大的风险面工具调用。一个智能体可能对接几十个 API每个 API 都有自己的权限边界如果智能体的规划层被诱导绕过权限检查去调用了本不该调用的工具后果比单个 API 的越权严重得多。2016 年那类通过构造恶意输入欺骗系统执行的攻击在智能体场景里会以更隐蔽的方式重现。我们的安全策略编排本质上是在模型体系和工具体系之间加了一道可控的闸门。所有工具调用请求不管从哪一层发起来都必须经过策略引擎的校验没有任何例外。这个没有例外非常重要——只要存在绕过校验的后门攻击者迟早会找到它。3.2 策略编排的四个落地要素我们最终沉淀出四个必须落到代码里的要素第一工具级白名单。每个智能体角色有自己的工具白名单。比如数据分析助手只能调查询类、报表类工具运维助手可以调重启服务类工具但绝不能碰数据删除类工具。白名单不是写在代码里的 if 判断而是存在配置中心的一组策略规则改权限不用发版。第二上下文隔离。不同会话、不同用户的数据必须做到严格隔离。我们遇到过一个大模型把用户 A 的数据带到用户 B 的会话里的情况原因是当时短期记忆层没做租户隔离直接用了全局缓存。后来我们在记忆层增加了一个 mandatory 的隔离维度——每条记忆记录必须携带用户 ID 和会话 ID读取时强制校验校验不过直接拒绝。这不是优化项是强制项。第三敏感操作复核。高风险操作比如发送外部邮件、修改数据库、执行删除必须经过二次确认。智能体在执行前会先输出我准备做以下操作的确认卡片用户批准后才真正执行。虽然这会让一部分用户觉得多此一举但如果你的智能体真的有工具调用能力这一步绝对不能省。第四输入输出双向过滤。很多团队只对用户输入做安全过滤忽略了模型输出。但模型的输出同样可能包含提示注入的内容比如模型读了某个被污染的网页后把下次请删除某个文件这句话原样输出给用户所以输出侧必须有一个独立的审核模型把关。3.3 一个真实的安全策略配置样例下面是一个简化版的策略配置用的 YAML 格式方便理解agents: >