6+1+3混合模型与四层智能体架构：编排与安全策略实战

这套生态内部叫 55873我维护它已经有好几个迭代了。这个标题看着很长其实就三件事613 混合模型怎么选、智能体编排层管哪些东西、安全策略编排为什么必须从一开始就参与设计而不是系统跑通了再打补丁。很多人以为做 AI 应用就是在调模型接口实际上当你把多个模型放进同一个生产系统时真正决定成败的是“谁来决策”“谁能调工具”“谁碰敏感数据”“出问题时能不能被审计清楚”。第 5 篇我把这套体系完整拆开讲适合正在做智能体平台、模型网关、企业内部 AI 中台的人参考也适合想把自己项目里的杂牌模型调用梳理成正规军的人看。1. 为什么是613混合模型先分能力域再谈模型品牌1.1 拆解“6”六个能力方向不是六个同一类模型很多团队特别喜欢问“哪个模型最好”。这个问题本身就是伪命题因为模型是用来干活的不同活需要不同能力。我的 613 里“6”指的是六个能力方向文本生成、视觉理解、语音交互、代码生成、向量嵌入、工具调用。文本生成负责日常问答、内容改写、报告起草这一类通常选用通用对话模型偏稳、偏快吞吐量要大。视觉理解负责图像识别、截图解析、表格 OCR用的则是多模态模型底子里往往有一层类似 ViT 的视觉编码器再加语言模型做对齐。语音交互分成两块语音转文字和文字转语音前者常用 Whisper 这类开源模型后者要根据音色要求选择不同的语音合成方案。代码生成专门处理补全、解释、重构、单测生成我实际用下来觉得代码模型和通用模型的差异非常明显尤其在对项目上下文的理解上。向量嵌入是个容易被低估的方向知识库检索、语义去重、Agent 记忆查询都靠它但很多人直接在通用模型接口里随便拿一个 embedding导致检索效果忽上忽下。工具调用能力的模型负责把用户意图转成结构化函数调用参数这是智能体能落地的前提。为什么一定要按能力域选而不是一个强模型全包最直接的原因是成本和延迟。一套生产环境里如果所有请求都走同一个最强模型你的响应速度和账单都会很难看。而且能力域之间天然有性能差异一个模型文本能力极强不代表它的视觉描述就准确也不代表它的 JSON 输出就稳定。所以我在 55873 生态里给每个能力方向锁定一个主力模型用一套固定评测集去验证不轻易跟风换品牌。1.2 “1”是什么总控推理模型613 里的“1”是所有模型里唯一有“最终决策权”的模型。它负责长链路推理、任务拆解、多步规划、风险判定。比如用户提了一句“把华东区最近三个月的退货数据和客服工单关联分析一下”这个任务不可能一次调用就完成。总控模型需要先判断要查哪些表、要不要检索历史报告、调用哪些工具、按什么顺序执行最后还要把工具返回的结果组织成自然语言回答。我把它从 6 个主力能力模型里单独拎出来是因为它的角色特殊。总控模型一方面要大推理能力必须够强否则拆出来的子任务经常是错的另一方面速度又不用太快因为真正干活的是下面那 6 个模型。这种分层设计我在实践中觉得特别好用总控慢但准执行模型快但相对专各司其职。选总控模型时我建议大家不只盯着冲榜分数要重点看它在“多轮修正”上的表现。实际场景里Agent 第一次规划往往是错的它需要根据环境反馈调整计划。有些模型第一次回答惊艳但在多轮修正中会固执己见。我现在的选择标准是给同一组纠错测试集连续五轮修正后仍能完成任务的模型才进总控位置。1.3 “3”是哪三个本地/辅助模型“3”是三个小体量模型部署在更靠近业务的地方有时候跑在本地工作站上。第一个是意图识别和敏感信息过滤模型所有用户请求先过它它判断该走哪条链路同时把识别到的敏感字段交给脱敏模块。第二个是本地降级模型当远程模型不可用或响应超时时由它保证基础服务不中断哪怕答案质量低一点系统也不能整体挂掉。第三个是结果校验模型负责检查其他模型输出是否符合格式要求、有没有幻觉风险、数值是否能对得上。这三个模型通常不用太大7B 到 14B 就够。说实话它们的升级频率比那 6 个大模型低得多但作用极其关键。我遇到过好几次远程模型服务抖动就是靠本地降级模型撑过了那几分钟用户毫不知情。1.4 Agent、LLM 和 AI 模型到底有什么区别这个话题总有人搞混尤其是刚接触智能体的朋友。AI 模型是所有模型的统称包括图像模型、语音模型、传统机器学习模型。LLM 是大型语言模型特指文本生成这一类DeepSeek、GPT、Llama 都属此类。Agent 则不是一个模型它是一个包含模型、记忆、工具、策略循环的系统。你用 LLM 只能做问答Agent 能做“接收任务、制定计划、调用工具、观察结果、修正行动”这一整圈事情。DeepSeek 本身属于 LLM但当你把它封装进一个编排框架并且接上工具调用能力以后它才成为一个 Agent 的核心大脑。混合模型体系存在的意义就是给 Agent 提供多技能支撑。一个 Agent 既要会说话又要会看图表还要能操作数据库单靠一个 LLM 做不到。这也是为什么我在 55873 里坚持做 613 而不是只买一个最强接口Agent 是瑞士军刀不是单把锤子。2. 智能体编排层从模型能力到业务结果中间隔着的是组织逻辑2.1 编排层到底在编排什么我见过太多人把 Agent 做成了一个巨大的“if-else 套壳”模型只在最里层被调用一次然后所有分支都由硬编码判断。那不是智能体那是一个披着 AI 外衣的规则引擎。真正的智能体编排层要管理的是状态、上下文、工具注册、路由决策、记忆存取和回调追踪。以“问数智能体”为例用户问“这个季度华东区域的退货率是多少跟去年同期比有什么变化”。编排层要做的事包括把这个问题送到意图分类器判断这是数据分析任务启动文本生成模型做一次问题拆解调用工具模型选择 SQL 执行器查数据库把结果带回让总控模型组织最终回答把整轮过程写入审计日志。每一步都有轻量模型参与但流程控制权在编排层手里而不是把控制权完全丢给某一个模型。我这里特别强调“轻量模型做局部决策、总控模型做全局决策”的原则。意图分类、情绪识别、实体提取这类简单任务用大模型杀鸡焉用牛刀又贵又慢真正需要推理深度的地方才派总控模型上场。编排层就是这条人肉流水的调度室谁轻谁重、谁先谁后、失败怎么办都由它说了算。2.2 LangChain 和 LangGraph 组合下的开发案例网上很多关于 harness 架构的讨论都会落到 LangChain LangGraph 这套组合上。LangGraph 核心是一个状态图节点是执行单元边是流转条件状态对象在不同节点之间传递。用它做多智能体编排比直接用 LangChain 的链式调用要清晰得多因为你可以在图上看到所有分支和回退路径。我拿一个真实案例说明。系统里有三个智能体策略智能体、检索智能体、执行智能体。用户的查询先进策略智能体它决定任务类型检索智能体负责从知识库找相关材料执行智能体专门调 API 或查数据库。三个节点并行跑各自把结果写进公共状态最后由总控模型汇总输出。LangGraph 的一个明显好处是你可以定义条件边比如检索结果为空时跳过失配节点直接回到策略智能体重新拆解任务。不过这套方案有个坑LangGraph 的 state 不是无限大的大对象的读写效率很感人。我的习惯是 state 里只放元信息和任务结果摘要完整的聊天记录和工具原始输出放到外部存储用 message_id 关联。这样状态图反应快回溯也方便。多智能体编排最怕的就是所有上下文都堆在内存里几轮对话以后每次调用都要搬一大堆历史最后系统慢得没法用。2.3 多个智能体并存时的协作与竞争问题多智能体系统真正麻烦的不是“能不能跑通”而是“三个智能体同时发表意见时听谁的”。我遇到过几次典型事故两个智能体对同一问题的结论完全相反最后输出结果是错的但系统没有任何校验环节用户拿到错答案还以为是对的。后来我在编排层加了一类“裁判节点”它不参与具体答复只负责对比多方输出的一致性出现矛盾时自动触发复核流程。另一个经验是智能体之间的“上下文隔离”。很多时候 Agent A 产生的中间数据包含临时假设如果直接把 A 的完整状态塞给 Agent BB 可能会把 A 的假设当成事实。我在每个智能体对外输出的边界上做了一层封装只允许传递经过校验的结构化结果不经校验的原始思考过程不允许跨节点传播。如果你也在做多智能体编排我建议先对照这张表检查一轮风险点现象应对手段状态冲突两个节点同时修改同一字段状态 key 按节点前缀命名写入前加锁校验上下文污染上游假设被下游当成结论节点间只传结构化结果不传完整思维链回环死循环Agent 递归重试直到超时每层设置最大迭代次数和熔断阈值结论矛盾多个 Agent 输出不一致增加裁判节点与重试机制记忆丢失多轮对话后失去早期关键信息外部记忆库按会话 ID 存储和召回3. 四层智能体架构把“Agent”从口号变成可治理的系统3.1 第一层入口路由层四层架构的第一层是入口路由层负责接待所有用户请求。这一层主要干三件事识别意图类型、判断风险等级、分配合适的处理链路。风险等级是我特别在意的。敏感数据查询、删除类操作、对外发消息这些属于高风险请求需要额外的权限校验和二次确认闲聊、知识问答属于低风险请求直接进普通链路。这层通常用一个小模型加规则引擎混排完成速度快可解释性强。不要一上来就用大模型做全量意图分析入口流量往往最大在这里浪费计算资源非常蠢。入口路由层的另一个职责是“拒绝”。不是所有请求都应该进入后面的流程。比如用户问了一个完全没有业务上下文的问题或者试图让系统执行不受支持的操作路由层应该在第一道门就把请求拦下。很多安全事故其实是 Agent 自己越权造成的入口层做一次过滤能挡掉很大一部分问题。3.2 第二层任务编排层任务编排层是四层架构的“大脑”对应我前面说的总控推理模型和编排框架。这一层负责把用户的复杂请求拆成若干子任务确定它们之间的依赖关系然后调度下一层的工具执行。我在设计任务编排层时遵循一条原则子任务的粒度要足够小小到每个子任务对应一个明确的工具调用。比如“分析退货率”被拆成“查询退货数据”“查询销售数据”“查询去年同期数据”“执行归因计算”“生成对比结论”这五个子任务每个子任务都能独立执行、独立验证任何一个失败都不会导致整个流程崩掉。任务编排层还负责“计划回退”。第一次拆解的计划如果执行到一半发现条件不满足编排层要能回到计划节点重新拆。这个能力看起来简单但对状态管理的要求很高。很多人做 Agent 只做正向流程一旦中间出问题就死在那里用户只看到一个转圈或一句“系统繁忙”这是典型的编排层设计缺失。3.3 第三层工具执行与数据检索层这一层是干活的地方所有外部依赖都在这里发生。数据库查询、API 调用、RAG 检索、文件读写、命令行操作都属于这一层。它暴露给上层的是一个标准化的工具注册表每个工具包含名称、参数、权限级别、调用限制。工具层需要做两件十分重要的事。第一是参数校验模型生成的参数不能直接传给真实系统必须经过格式校验和值域检查。比如模型调用 SQL 工具时不加 WHERE 条件这种错误不应该让数据库来教育我们。第二是超时熔断每个工具调用都要设置超时时间和最大并发量防止某个慢接口拖垮整个流程。RAG 检索也被我归到这一层。向量嵌入模型在整个体系里的作用是给非结构化文档建索引让 Agent 能在海量内容里快速找到相关片段。但我发现很多人把 RAG 做成了“把数据库里所有文本分块、然后让向量模型算相似度”的简单流水线这远远不够。好的 RAG 还要考虑检索策略、切片方式、元数据过滤和重排序模型。你辛辛苦苦配好的混合模型体系很可能在检索层把质量全部丢掉。3.4 第四层审计与安全策略层这一层不是埋点日志那么简单它是整套体系能否被信任的基础。审计层负责记录每次模型调用、每次工具执行、每个决策节点的输入输出并且保证这些记录在加密和脱敏的基础上可追溯。更关键的是安全策略的强制执行点。工具能不能执行取决于用户在系统里被分配的权限角色数据能不能查取决于数据源的权限标签敏感字段能不能展示取决于脱敏策略。这套规则不是模型决定的是策略引擎在模型调用之前和之后分别执行的。我把这一类机制叫做安全策略编排先审批后放行再留痕。安全策略层还应该包含异常的实时检测。例如单个用户在一分钟内调用了大量高风险操作比如批量导出数据系统应该自动降级响应或触发人工审核。这些规则必须写死不能依赖模型自动判断。模型不该成为安全边界的一部分安全边界应该独立于模型存在。4. 安全策略编排先给模型划边界再让模型自由发挥4.1 安全不等于限制模型而是限制操作只要一聊到安全就会有人把话题拉到“限制模型自由度”上。我不太同意这个思路。模型的自由度本身不是风险模型能执行什么操作才是风险。一个只会生成文本的模型就算它满嘴跑火车最坏的结果是内容质量差但如果一个 Agent 能调 SQL、能发邮件、能删除文件那它的输出内容与执行结果就直接挂钩。所以安全策略编排关注的是“执行权限”不是“思想审查”。热门讨论里总提到“没有限制 AI 模型”很多人理解成不被审查、什么都敢说。从工程实践的角度看这个目标没有意义。在真实生产系统中你真正需要的是“该模型能否被允许调用某个工具”。哪怕是号称最开放的模型只要它没拿到数据库密码它也没法读取用户隐私反过来一个声称安全但对工具不做限制的 Agent和一个装载了武器的人形机器人没有差别。4.2 本地模型与远程模型混合时的边界风险613 混合模型体系里本地模型和远程模型同时存在。本地模型的好处是数据不出内网适合处理敏感数据远程模型的好处是能力强适合复杂推理。但两者混在一起时边界一旦模糊就会出事。我举一个很常见的翻车场景用户请求里含客户姓名与联系方式入口路由层误判为低风险直接把请求送给了远程模型。数据被发到外部而模型返回的结果里又能看到原样的敏感字段等于把隐私数据交出去又拿回来。解决方案是在入口层强制加一条规则凡是识别出敏感字段的请求一律先进本地模型做脱敏脱敏后的内容才能出网远程模型的输出也要经过脱敏字段映射还原保证下游业务能正常使用。另一个风险点是工具调用的权限我不想因为某个模型是开源的、是本地部署的就默认它安全。模型的安全性和它跑在哪里是两码事权限判断必须统一走策略引擎。我在系统里给每个工具都打了权限标签不管是哪个模型发出的调用请求最终执行前都要过这一关。4.3 一套实际可落地的安全策略编排方案我建议从四个维度配置安全策略编排。第一是输入过滤。所有请求先经过敏感信息识别模型识别出身份证号、手机号、银行卡、企业机密关键词等对象。第二是风险定级。根据请求涉及的操作类型和数据范围给每个请求打上风险等级标签高风险请求必须附加用户身份验证或者审批人的确认。第三是工具白名单。每个模型角色有对应允许调用的工具集合比如检索模型只能读执行模型只能写总控模型没有直接调工具的权利。第四是输出校验与审计。模型输出先过格式校验和敏感字段还原再返回给用户同时完整链路写入审计日志日志里记录模型版本、工具版本、输入输出摘要、耗时与 token 消耗。这套方案看起来繁琐但真到出事故的时候你会发现它的价值无法估量。我有一次接到线上客户投诉说系统返回了错误数据。复盘时靠审计日志定位到是某个版本的工具执行失败之后编排层拿旧的缓存结果兜底而兜底逻辑没有二次校验。如果当时没有完整的审计链路这个问题可能要被归因到模型头上最后根本修不到根上。5. 日常接入与部署VS Code、IDEA、Mac Studio、本地模型四种真实接入场景5.1 VS Code 连接 AI 模型的两种方式VS Code 接 AI 模型现在主要有两条路。一条是装 Continue 这类开源插件另一条是使用官方自带 GitHub Copilot 的兼容模式。Continue 的优势是灵活性高你可以在设置里自由配置模型供应商指向远程服务或者本地部署的模型端点。配置方式不复杂在 Continue 的配置文件里添加模型供应商填上 API 地址、模型名称和认证信息。如果你用的是本地模型可以把地址指向你自建的推理服务。我习惯把 613 里的本地降级模型跑在 VS Code 场景里日常写代码补全用不上远程大模型本地 7B 代码模型就够快私密性也好。不过要提醒一句本地模型写出来的代码一定要过一遍编译和单测模型对项目全局上下文的把握是有上限的。5.2 IDEA 上配置自定义模型供应商插件Java 生态里IDEA 配置自定义模型供应商插件也很成熟。现在主流 AI 插件基本都支持自定义 OpenAI 兼容接口你只需要填写接口地址、密钥和模型列表。我项目里常用的是把内部网关地址配进去这样所有 IDE 内的请求都走统一的模型路由和安全策略层而不是让开发直接连各厂商接口。这样做的价值在于模型替换对开发者无感。今天的主力模型从 A 换成 B只需要在网关配置里改一个名字而开发者 IDA 里不用改任何设置。自定义供应商插件本质上是个只显示接口的壳子真正做模型路由和权限控制的还是后端网关。5.3 Mac Studio 本地模型部署的配置建议Mac Studio 跑本地模型关键是内存容量。统一内存架构对 AI 推理非常有利但要装得下大一点的模型内存最好选 64GB 以上。我实际测试下来跑 14B 左右的量化模型很流畅再大一些的模型就要用 MLX 或者 llama.cpp 做量化部署了。在 Mac 上我建议安装 Ollama 或者直接走 MLX因为这两者对 Apple Silicon 的优化比标准 CUDA 路径更好。日常用三个本地辅助模型完全没压力。如果你想把总控模型也跑在本地那就要认真考虑显存和内存的极限了。我的做法是只在 Mac 上跑“3”也就是那三个辅助模型“6”和“1”还是走远程服务。5.4 用本地模型重构 C# 项目的注意点本地模型用来重构老项目这个场景很实际。C# 项目在 IDE 里用 AI 插件补全代码时最容易出的问题是对项目引用的理解不够。模型建议的代码经常依赖了不存在的 NuGet 包或者用了过时的 API。我的建议是小步走一次只让模型重构一个方法立刻编译立刻跑测试确认无误再进下一段。让模型一次重写整个类你会在编译错误的海洋里挣扎。重构之前把关键单测写好这件事不能省。模型不记得项目里十年前的历史约束只有测试能告诉它哪个改法会破坏旧逻辑。6. 实测翻车记录质量骤降、多轮失忆、扩容反效果6.1 AI 生成图像质量突然变差的排查链路热搜里有人在问“AI 模型生成图片时突然间质量特别差是为什么”这个问题我在 55873 生态里也遇到过。第一反应往往是怀疑模型本身出了问题但后来发现九成原因是某个环节没对齐。我按这套顺序排查先检查模型版本是不是被自动更新了很多平台静默切换版本行为差异很大再检查采样器和步数参数同样的提示词在不同采样器下差别巨大然后检查负面提示词有没有被某种长度截断截断后负面提示词失效画面质量断崖式下降最后看缓存有时旧的缓存特征与当前模型版本不兼容导致结果质量崩掉。整个过程下来真正需要换模型的情况少之又少多数是参数和链路问题。6.2 Agent 多轮对话中的“断片”问题多轮对话失忆是另一个高频翻车点。用户明明在第二轮提供了关键信息第五轮 Agent 却完全不记得。我的排查结果通常集中在三个原因第一对话历史的截断策略太粗暴窗口放不下时直接把早期消息丢掉了第二工具调用结果没有写回到历史Agent 做完查询后立刻忘了刚才查到什么第三请求被路由到不同模型节点而各节点的上下文存储互相隔离。现在我的规范是工具调用的原始结果必须强保留至少保留到整个任务结束上下文存储统一放外部缓存不跟模型调用绑定截断策略保留任务开始时用户的核心目标而不是简单按时间顺序切。这样修完以后失忆问题基本绝迹。6.3 模型扩容后性能反降的教训最后说一个反直觉的教训。我曾经认为把 13 的辅助模型升级成更大的版本体系整体效果会更好。结果升级之后平均响应时间暴涨部分链路的答案质量反而下降。原因是更大的模型在输入输出长度和延迟上发生了变化而编排层的超时阈值和路由策略没有同步调整最终很多请求在总控那里等待超时才回退。从那以后我形成了一个习惯每次替换混合模型体系里的任何一个成员都要把编排层的路由策略、超时参数、降级策略、评测集结果同步做一轮回归。模型再强调度策略没有对齐强也发挥不出来。这个教训说起来简单但我在真实项目里踩了一次代价是一周的业务投诉。7. 最后再提一嘴让编排层留一张可回放的审计票实际维护这套体系到现在我最想分享的一条经验是如果你的智能体系统还没有审计通道赶紧补上。所谓审计票就是每一次完整请求从入口到每个中间节点的可回放记录哪怕不出问题也值得留。没有审计票你根本没法回答“刚才模型为什么给用户返回了那个数字”“是哪个工具执行失败导致链路回退”“脱敏在哪个环节漏掉了”。我现在每个节点都会往审计日志里写一条结构化记录内容包括输入摘要、输出摘要、模型版本、token 耗时、错误码和链路追踪 ID。出问题时可以先按链路 ID 拉到整条执行路径再逐节点分析。这套机制在“613”模型体系扩充到四层智能体架构时节省的排查时间已经无法用量来衡量了。如果你的体系刚起步我建议从第一天就把审计带上而不是等事故逼你补课。