6+1+3混合模型×四层智能体架构：企业级AI安全编排实战

先说个我在设计这套体系时的切身感受：每次跟人聊"AI 模型完整体系"，大家的第一反应都是"又要堆大模型了"，但真正落到生产环境，你会发现问题的关键从来不是某一个模型的聪明程度，而是一堆模型怎么分工、怎么协作、怎么被安全地编排起来。

这篇文章是技术系列的第 5 篇，聊聊我们内部代号"55873 生态"里沉淀下来的一套做法：6+1+3 混合模型 × 四层智能体架构 × 安全策略编排。简单说，就是用 6 个垂直模型负责感知与抽取，1 个核心大模型负责推理与生成，3 个辅助模型负责安全、路由和质量控制；在这套模型体系之上，再架设一层四层结构的智能体编排层，把"能对话"升级成"能干活"，最后用一套安全策略编排机制把工具调用、上下文访问和输出内容全部管起来。

这套东西适合谁？如果你正在做智能体平台架构设计，或者准备把 AI 代理助手接到自己的业务系统里，再或者你手里有几个模型但不知道怎么组合、怎么管权限，那这篇应该能给你一些能直接抄作业的思路。

1. 为什么非要做"6+1+3"混合模型：纯大模型路线跑不通的三个原因

在拆解 6+1+3 之前，得先聊清楚一个底层问题：为什么不用一个超大模型包打天下？这直接决定了整个架构的走向。

1.1 大模型万能论的反面

我见过太多团队，一开始都迷信"只要 GPT-5 级别的模型够强，什么任务都能做"。但真正上生产后，现实会给你三记耳光：

第一，成本爆炸。一次通用大模型调用的成本，是垂直小模型的几十倍。如果每一项任务都走大模型，光推理费用就能吃掉整个项目的预算。我们线上有一个问数智能体，早先所有请求都走大模型，一个月账单下来，财务直接找我谈话。

第二，延迟不可控。大模型的推理延迟通常在秒级到十几秒，但很多场景（比如实时意图识别、敏感词过滤、实体抽取）需要毫秒级响应。让大模型做这些事，体验上就是灾难。

第三，精度不够专。通用模型在"什么都会一点"的同时，往往意味着"什么都不够精"。让它做法律条款的要素抽取，或者医疗问答的辨证分型，效果永远不如一个针对性训练过的垂直模型。

所以混合模型的核心思路就是一句话：让最合适的模型做最合适的事，大模型只做那些真正需要"智能"的事。

1.2 6+1+3 的具体分工

我们的"6+1+3"不是拍脑门定的，是演化出来的——从最开始一个模型硬扛，到后来慢慢拆分，最终沉淀成这套组合。

6 个垂直模型，负责感知与抽取类任务，特点是轻量、快、针对性强：

编号	垂直模型	负责任务	选型考量
M1	文本意图分类模型	识别用户意图大类（查询、操作、闲聊、投诉）	用蒸馏后的 200M 级模型，单次推理 5ms 以内
M2	命名实体抽取模型	抽取人名、地名、机构名、产品名、编号	基于 BiLSTM+CRF 或小规模 Transformer，支持自定义词典
M3	情感倾向分析模型	判断正/负/中性情绪，用于工单分级	线上语料微调，比通用模型在业务数据上准 8~12 个点
M4	视觉特征模型（ViT）	处理图像输入，提取版面结构或关键区域	用的是 ViT-Base 结构，适合文档 OCR 之后的结构化
M5	向量化编码模型	把文本转成 embedding，供检索使用	BGE 系列或同等水平的开源模型，维度 768/1024
M6	语音/音频特征模型	处理语音输入的情绪与端点检测	仅在语音交互场景启用，按需加载

1 个核心大模型，负责推理、生成、规划。它不做感知，只做"脑力活"——理解上下文、拆解任务、生成答案、调用工具时做决策。可以根据预算选择闭源 API 或本地部署的 7B~70B 模型，这个后面细聊。

3 个辅助模型，更像是"保障组"：

• A1 安全审核模型：对输入和输出分别做安全过滤，拦截注入类内容、敏感话题和异常指令。
• A2 路由决策模型：根据意图分类结果和上下文状态，决定请求交给哪个模型、走哪条链路，相当于交通警察。
• A3 质量评估模型：对生成结果做幻觉检测和答案打分，分数低于阈值就触发重试或降级方案。

这里有个容易踩的坑：很多团队把路由逻辑直接写在业务代码里，用 if-else 硬编码。但我们的经验是，路由本身也需要模型化，因为意图之间存在大量边界情况，规则写死了就没法应对变化。A2 不是用来替代规则，而是用来兜底规则覆盖不到的模糊地带。

1.3 模型之间怎么通信：路由链路的执行顺序

混合模型不是各干各的，它们必须串成一条清晰的流水线。我们的请求链路大概是这样的：

1. 请求到达后，A1 输入安全审核先跑一遍，不通过直接拦截，不进模型。
2. 通过后，M1 意图分类给出粗粒度标签，同时M2 实体抽取从原文中取出关键实体。
3. 这两路结果汇总给A2 路由决策模型，A2 结合用户的会话上下文和业务规则，决定下一步是走检索链路（M5 向量化）、视觉链路（M4）、还是直接交给核心大模型。
4. 大模型生成答案后，A3 质量评估模型打分。如果分数低，就触发二次规划或换一个 prompt 模板重新生成。
5. 最终输出前，A1 再做一次输出侧安全审核，没问题才返回给用户。

这条链路看起来长，但因为 90% 的请求在 M1/M2 阶段就能确定走轻量链路，真正的全链路深度推理只占一小部分，所以整体成本可控。实测下来，简单问答类请求的平均响应时间在 200ms 以内，只有复杂推理请求才会走到秒级。

2. 四层智能体架构：把"会对话"升级成"会干活"

模型体系只是底层能力，真正让这套系统从"聊天机器人"变成"智能体"的关键，是上面的编排层。我们把它拆成四层：意图路由层、任务规划层、工具调用层、记忆与反思层。每一层各司其职，又通过统一的数据结构串起来。

2.1 第一层：意图路由层

这一层和 M1、A2 紧密配合，但粒度更细。模型层做的是"这句话是查询还是操作"，编排层的意图路由则要回答"这个操作具体调哪个API、走哪个流程"。

举个例子，用户说"帮我把上个月的销售数据整理成周报发给团队"。意图路由层要做三件事：

• 识别这是一个多步任务，不是单次问答；
• 拆出关键参数：时间范围（上个月）、数据对象（销售数据）、产出物（周报）、接收人（团队）；
• 把任务挂载到对应的会话状态机上，进入规划层。

这一层在设计上有两个容易忽略的点。一是状态管理：每个任务都要有独立的会话状态，避免多个任务之间互相污染上下文。我们用的是无状态接口 + 状态暂存区的方式，状态以 JSON 结构存到临时存储里，任务结束后异步写回持久层。二是超时与中断：不是每个任务都能顺利完成，意图路由层必须预设超时和人工转交的出口，否则用户会被卡死在一个失败状态里。

2.2 第二层：任务规划层

规划层是智能体和普通 RAG 问答最本质的区别。它负责把一个大目标拆解成可执行的小步骤。

我们的规划层借鉴了经典的"计划-执行"循环，但做了一些工程化改造：

1. 步骤生成：大模型根据目标生成候选步骤序列，比如上面的"查数据 → 算汇总 → 生成周报 → 发给团队"。
2. 步骤校验：每个步骤都要通过一个合法性检查，确认它对应的工具是存在的、参数是完整的、依赖的数据源是可达的。这一步我们做了个"工具注册表"来支撑，后面安全部分会详细说。
3. 动态调整：如果某一步执行失败，规划层需要回到现场重新规划，而不是简单地报错返回。

这里我必须强调：规划层没必要追求"一次性规划完美"。我们早期花了很多精力让大模型一步到位生成最优化步骤，后来发现完全是自找麻烦。现实是，步骤在执行过程中会因为数据不对、权限不足、外部 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: >