AI模型完整体系与智能体编排层拆解：混合模型与四层架构实践

技术第5篇，AI模型完整体系与智能体编排层拆解

模型不是越强越好，组合起来好用才是关键。

这个观点是我过去大半年搭内部AI应用体系最深的一个体会。这个系列已经写到第五篇，前四篇讲的是单点能力，从模型部署、数据工程、推理优化到评估体系。这一篇我打算把视角拉高，聊聊我们正在跑的这套代号"55873"的完整体系：6+1+3混合模型怎么分角色、四层智能体架构怎么分工、安全策略编排怎么嵌进调用链而不是外挂在旁边。如果你正在搭中大型AI应用，或者准备把多个模型组合成一个可用的产品，这篇应该能给你一套完整可参考的框架。

先解释一下55873这个代号。数字不代表玄学，它是对内部资源的映射：5类模型底座、5条安全基线、8种标准工具协议、7个核心业务场景、3套运维保障。拆开看就是我们常说的"模型不是单一能力，而是需要分层、分组、分批管理"。而这篇的重点在两个最容易被忽略、却最影响成败的部分：混合模型的分工设计，以及智能体编排层的组织方式。

1. 为什么是"6+1+3"：单一模型永远解决不了真实业务的多重约束

1.1 单一大模型的三个死穴

先说结论：指望一个大模型扛下所有任务，在真实业务环境里基本走不通。不是模型能力不够，而是"能力够"和"业务可用"之间隔着三道坎。

第一道坎是能力维度冲突。一个模型很难同时在长文本理解、代码生成、数学推理、多模态识别、创意写作上都达到顶尖水平。你可以让一个通用大模型写周报，也可以让它分析表格，但让它一边做严谨的合规判断、一边保持自然的口语对话风格，结果往往是两边都别扭。真实业务需要的是"一个入口，多种专业能力"，单模型无法在同一时刻满足这些互相冲突的约束。

第二道坎是成本和延迟。把所有请求都发给一个70B甚至更大规模的模型，跑简单任务时你会发现响应时间直接压垮用户体验。一个"帮我查一下订单状态"的问题，犯不着动用全参数模型。实际业务里，大量请求是短文本、低复杂度、高频次，这些请求用大模型处理就是资源浪费，用专用小模型处理又快又稳。

第三道坎是安全与可控。单一模型一旦出了幻觉或者违规内容，整条链路跟着遭殃，你找不到一个降级的替代方案。如果架构里从一开始就设计了多个模型分角色、互相校验，至少还能在某个环节出问题时切断或回退，不至于全盘失控。

1.2 6+1+3的分工逻辑

基于这三道坎，我们的方案是把模型按角色拆成三组：6个主力模型，1个路由与质检模型，3个垂类小模型。这听起来像是堆模型，其实是在做"角色分权"。

先说6个主力模型。它们不是随便选6个，而是按能力特长挑出来的。6个分别对应文本生成、代码理解与生成、数学与逻辑推理、长文档分析、多模态理解、创意写作这六个方向。之所以要用6个而不是1个，是因为每个方向对模型的能力要求差异太大。比如长文档分析，需要模型能处理几十万字的上下文并准确引用某个段落，这对模型的注意力机制和上下文窗口有刚性要求；而数学推理，则更依赖模型在符号计算和链式思考上的表现。把六个模型放在一个"模型池"里，通过路由决定每个请求去哪个模型，才能在成本、速度、质量之间找到平衡。

再说那1个路由与质检模型。这个模型是最容易被忽略的，但也是整个体系里唯一不能省的角色。它的任务不是生成内容，而是判断"这个请求该交给谁处理"以及"处理结果是不是合格"。换句话说，它是一个裁判，不亲自下场踢球。路由模型通常用中等规模模型就够了，因为它不重生成，重分类和打分。

最后是3个垂类小模型。它们分别负责知识库问答、合规审核、结构化数据抽取。选择小模型的原因是这三个任务领域边界清晰、数据充分，小模型通过微调就能达到甚至超过通用大模型的效果，但推理成本低了至少一个数量级。合规审核这种任务要求规则可解释，小模型更容易做到"为什么拒绝"的可追溯。

这个配置的核心理念一句话总结就是：大模型负责"生成"，小模型负责"保镖"，中等模型负责"调度"。谁干什么事，从一开始就划定边界，而不是让一个模型既当运动员又当裁判。

2. 四层智能体架构：模型在中间，编排在两头

模型分好了工，接下来要解决的是"谁来安排工作"。这就是智能体编排层的价值所在。我在设计这套架构的时候，一直在强调一个观点：智能体的"智能"，不是模型给的，是编排层给的。模型只负责生成文本，怎么拆任务、怎么调工具、怎么记忆、怎么纠错，全是编排层的活。

我们把整体架构拆成四层，每一层都有明确边界。

2.1 接入层：把工具和渠道都变成标准协议

接入层是整个架构面向外界的窗口，也是最容易被低估的一层。你把API、对话机器人、工单系统、邮件、内部IM全部接进来，如果每个渠道都单独写一套逻辑，后面维护起来就是灾难。

我们的做法是定义一套统一的协议。一个请求进来到编排层之前，必须先转换成标准消息格式：请求ID、用户身份、会话上下文、意图候选列表、附带的结构化参数。这样后面无论哪个模型来处理，都不会被渠道差异干扰。

接入层还要做一件重要的事：工具注册。智能体要能调用外部的API、数据库查询、计算器、搜索服务，不可能在代码里写死每个工具的调用方式。我们实现了一个工具仓库，每个工具用OpenAPI风格的描述文件注册，声明它接受什么参数、返回什么结构、需要什么权限级别。模型看到的是工具列表和描述，编排层看到的是可执行的函数。这一层的核心价值就是把"模型自由"和"工具边界"隔开。

2.2 规划层：任务拆解与路由决策

规划层是我花时间最多的地方。用户的请求往往不是一个单一动作。比如用户问"帮我对比一下这两个供应商的报价，然后生成一份采购建议"，这句话背后至少包含三个子任务：解析报价单、做数据对比、生成建议文案。如果没有任务拆解，模型很容易只做最后一步，丢掉前面两个关键环节。

规划层的执行顺序是这样的：先用路由模型做意图分类和复杂度评估，判断请求属于哪个业务领域、需要哪类能力；然后基于预定义的"任务模板"把大请求拆成多个原子任务；最后根据每个原子任务的目标，决定调用哪个模型、执行哪个工具。

这里有个细节我特别想强调：任务拆解绝不能完全交给模型自由发挥。我们做了可配置的DAG模板，把常见业务流程预定义好，模型只是在模板里做参数填充和顺序微调。为什么这么做？因为完全自由的任务规划在真实业务里太容易失控——模型可能漏掉关键校验步骤，也可能把顺序搞反，比如先调用工具再鉴权。预定义模板相当于给模型画了一条轨道，既保留了灵活性，又限制了破坏力。

2.3 执行层：模型调工具，而不是模型写代码

执行层的职责很纯粹：真正把规划层拆出来的任务一个个执行掉，并且校验执行结果。

很多人在这一层容易走进一个误区：让模型直接生成代码来解决工具调用问题。比如模型说"我用Python字符串处理一下这个JSON再提取字段"，这在测试环境没问题，一上生产就是定时炸弹——模型生成的代码可能有漏洞，可能引入不安全的库，而且你无法审计它到底干了什么。

我们的执行层遵循一个原则：模型只做参数映射和结果解释，工具调用本身由确定的代码完成。也就是说，模型的任务是"根据用户意图，把工具函数所需的参数从上下文中抽取出来"，然后编排层调用真实的、经过测试的代码去执行。模型给的是"意图和参数"，而不是"命令和脚本"。实测下来，这个思路让工具调用的失败率降低了70%以上，因为代码路径是确定的，可变的部分只在参数层面。

执行层还要记录每一次工具调用的输入输出，方便后面做审计和回放。这个我在安全策略编排部分再展开。

2.4 记忆与自检层：让体系具备"后悔能力"

四层架构里，记忆与自检层最容易被人当成"附加功能"，但我认为它是决定智能体体验上限的一层。

记忆分为两块。短期记忆负责当前会话的上下文，包括用户刚才说了什么、模型已经执行了哪些步骤、得到了哪些中间结果。长期记忆则负责跨会话的信息沉淀，比如用户偏好的文档格式、历史订单的常用条款、之前拒绝过的风险操作。我们用的是向量数据库做长期记忆的检索，候选记忆和当前请求做相似度匹配后注入上下文。这里最需要注意的是记忆注入的"不喧宾夺主"——记忆只是参考，不能覆盖用户当前明确的意图，否则就会出现用户明明说了"这次换成邮件模板"，系统还沿用上次的PDF模板这种低级错误。

自检层是我特别自豪的设计。每一次任务完成后，系统不会直接把结果返回给用户，而是先让质检模型走一遍"复盘"：检查输出格式是否符合预期、关键数据是否有来源支撑、是否出现自相矛盾、是否踩了安全红线。如果质检不过，系统会触发一轮"纠错"：回到出错环节，调整参数重新执行，或者换一个模型生成。这个机制相当于给系统装了一个"后悔按钮"，让它在把错误结果交给用户之前，先自己犯一遍错并修正。

实测下来，自检层对质量的提升非常明显。尤其是在多步工具调用场景里，没有自检时经常出现"前面步骤对了、后面步骤错了"的中间态错误，有了自检之后，整体任务成功率提升了大概20个百分点。

3. 安全策略编排：把权限、审计、防幻觉做进调用链

安全这件事，在传统架构里往往是事后补救，但在智能体架构里，它必须成为调用链的一部分。为什么？因为智能体的行为路径是动态的，你没法用静态的规则穷举所有可能的调用组合。安全策略必须跟着每一次请求实时编排。

3.1 工具白名单与最小权限原则

第一道防线是工具白名单。我们这个体系里，智能体能用的每一个工具都在接入层注册过，并且明确标注了权限等级。模型看到的工具列表不是全量，而是根据当前用户的身份过滤后的子集。一个普通员工发起请求，他对应的工具列表里就不可能出现"删除数据库记录"这种操作。

这里有个容易忽略的点：工具级别的白名单还不够，必须要做到"参数级别的校验"。比如"查询订单"这个工具，普通用户可以传自己的订单号，但不允许传"全部订单"这种范围参数。我们在执行层加了一个参数校验组件，在每个工具调用之前，检查参数是否落在当前用户的权限范围内。这个设计一开始被团队嫌麻烦，后来一次安全事故排查里发现，正是这道参数校验拦住了一个越权查询的漏洞，大家才意识到这是刚需。

3.2 敏感操作的二次确认与分级审批

第二道防线是敏感操作分级。不是所有操作都需要走审批，但"发送外部邮件""修改生产配置""删除数据""批量导出用户信息"这类高风险操作，必须进入二次确认流程。

我们实现了一个简单的分级机制：低风险操作直接执行；中风险操作返回结果前需要用户输入"确认执行"；高风险操作则直接转人工审批，智能体只能生成草稿，不能直接提交。这套机制看起来简单，但它防止了智能体最常见的失控方式——"用户问了一个模糊问题，智能体自动执行了一连串不可逆操作"。那些LLM造成的"越权事故"，本质不是模型有恶意，而是编排层没有默认给敏感性排序。

3.3 防幻觉的三道闸门

幻觉是智能体架构里最让人头疼的问题，尤其当模型需要调用外部数据时，它可能把编造的内容包装成"查到的结果"。我们的防幻觉策略是三道闸门：

第一道，路由侧。请求进来时，如果涉及事实性查询（查询订单、查库存、查政策），强制走带工具调用的链路，禁止模型凭空回答。这道闸门在规划层实现，缺了它，后面做得再好都拦不住生成侧的幻觉。

第二道，质检侧。模型生成回答后，质检模型会做"事实一致性校验"，把回答里出现的具体数字、日期、姓名等实体，与工具调用返回的真实数据进行比对，不一致就触发纠错重跑。

第三道，用户侧。即使前面两道都没拦住，最终返回给用户的内容里，凡涉及关键结论，我们强制附带来源引用。用户可以点开引用，核实数据出处。这既是对用户负责，也是倒逼模型在生成时不敢随便编。

3.4 全链路审计与回放

最后一道安全能力是审计。每一个请求从进入接入层开始，会生成一个全局唯一的request_id，这个ID贯穿：意图识别、任务拆解、模型调用、工具调用、质检判定、最终返回。所有环节的日志都以request_id为索引存储。

这意味着什么？一旦线上出了问题，或者用户投诉某个回答有问题，我们可以完整回放这个请求的"心路历程"：模型当时看到了什么、为什么决定调用这个工具、工具返回了什么、质检为什么放行了。这种可回放性在传统软件开发里是基本要求，但在智能体架构里反而经常被忽略。没有可回放性，AI应用出了安全事故就只能是"排查靠猜、修复靠试"，这是绝对不能接受的。

4. 落地部署中的五个实测问题与排查链路

这套体系写出来很理想，但真实落地过程中踩过的坑比方案本身更有参考价值。我挑五个典型的实测问题，把完整的排查链路写出来，方便你对照自己的场景。

4.1 现象：多个模型都答得不错，编排后效果反而变差

上线初期，我们遇到一个很奇怪的现象：单个模型在评测集上表现都不错，但走完整个编排链路之后，输出质量明显下降，甚至出现答非所问。

排查链路是从路由模型开始的。结果发现，路由模型在传递上下文时，会把原始请求之外的一些系统提示语和工具描述也一起传给下游模型。多个模型拼装提示词时，由于各自的模板风格不同，出现了指令冲突。比如路由模型要求"用简洁语气回答"，而主力模型自己的系统提示是"输出详细的分析报告"，两者一叠加，主力模型就会处于一种"不知道听谁的"状态，输出的内容一会儿简洁一会儿啰嗦，非常不稳定。

根因找到了，解决方案是统一提示词协议：所有模型共享同一套指令层级，约定系统级指令、业务级指令、用户级指令的优先级顺序。口号是"你只需要关注你的角色，全局指令由编排层负责"。这个修复上线后，效果立即回到单测水平，甚至因为上下文更精简了，推理速度还快了一点。

4.2 现象：路由模型把小问题路由给了重型模型

这个问题的直接后果就是成本飙升。排查链路里我第一时间看了路由日志，发现大量简单请求，比如"今天天气怎么样""帮我算一下24×17"，被路由模型分配给了最大的那个主力模型处理。

根因不是路由模型笨，而是路由模型的分类阈值设置得太保守。它对意图判断的低置信度区间里，默认策略是"宁大勿小"——不确定就丢给最强的模型，保证质量优先。但对简单任务来说，这种兜底没有任何意义，杀鸡用了牛刀。

修复方式是两条腿走路。一是调阈值：当分类置信度低于60%时，先降级给中等规模模型尝试，而不是直接上最强模型。二是加了一个"复杂度预筛"：在路由之前先用规则和关键词判断请求复杂度，明显简单的独立计算任务直接走轻量模型通道，不进路由。调整后，整体推理成本下降约30%，P95延迟也缩短了将近一半。

4.3 现象：安全模块在质检时被大模型的输出"说服"

这个坑是我最没想到的。合规审核小模型在一段时间内出现了漏检率上升，尤其是对大模型生成的流畅文本，几乎不拦截。排查日志发现，合规模型给这些文本打的违规置信度都非常低。

后来我们做了一个对照实验：同一段违规文本，由人工改写得更"自然流畅"一些之后送给合规模型，拦截率明显下降。这说明合规模型被文本的表面流畅性"说服"了——大模型生成的文本语法完整、逻辑连贯，反而让分类器放松了警惕。这本质上是一种对抗性鲁棒性问题。

解决方案有三个层次。第一，在合规模型的训练数据里加入大模型生成的对抗样本，让它学会关注语义而非表面流畅度。第二，设置双人复核机制：合规模型的小模型做初筛，如果是大模型生成的高质量文本，额外送一个不同系列的模型做交叉复核，避免"同一家模型互相包庇"。第三，对低置信度但高风险的文本类型，强制人工抽检。这套组合下来，漏检率回到了可控范围。

4.4 现象：并发高峰时，工具调用超时蔓延

智能体架构里的链路比传统API要长得多，一次复杂任务可能要串行调用三到五个工具。当并发量上来，任何一个环节变慢都会导致整体超时，而且会像交通拥堵一样向后蔓延。

排查链路里，我先用全链路追踪工具把每个环节的耗时拉出来。发现最大的瓶颈不在模型推理，而在外部服务响应——尤其是数据库查询和第三方API，在并发冲击下响应时间直接翻倍。模型推理的时间是相对固定的，外部服务才是不确定因素。

修复方案是三层降级策略。第一层是超时熔断：给每个工具调用设置硬超时，超过500ms直接中断并返回"暂时不可用"，而不是无限等待。第二层是结果缓存：对于查询类工具，同一参数组合的结果缓存5分钟，极大地减轻了重复请求对下游的压力。第三层是异步化：不依赖先后顺序的工具调用改为并行，整体耗时从串行的累加变成并行的最大值。这三招落地后，P95延迟从原来的6秒降到了2秒左右。

4.5 现象：长短记忆冲突导致用户困惑

记忆层上线一段时间后，有用户反馈"明明上次说了要简体中文，这次回复还是用了繁体"。排查发现，长期记忆里确实存了"用户偏好简体中文"的向量，但当前会话的短期记忆里有一条不太起眼的记录——用户在这轮对话中说了一句"不过繁体也可以接受"。

问题就出在记忆的优先级设计上。我们当时的策略是长期记忆和短期记忆混合注入，没有明确优先级，模型根据上下文的相关性自己判断，结果它被"最近出现"的信息带偏了。

修复方式很直接：给记忆加时间权重和身份权重。短期记忆中距离当前轮次越近的内容，权重越高；长期记忆中与用户身份绑定的偏好，权重略高于短期记忆中非明确指令的内容。另外加了一条硬规则：当短期记忆中出现"用户明确改变偏好"的表述时，立即覆盖长期记忆中的旧偏好，并写入新的长期记忆。这套"覆盖-更新"机制上线后，这类冲突问题基本绝迹。

这五个问题的共性很明确：智能体架构的坑，绝大多数不是模型能力问题，而是编排逻辑、上下文管理、降级策略这些"工程细节"问题。模型本身的进步是线性的，而编排层的完善往往能带来数量级的体验提升。

5. 从55873到更多：这套体系带来的实际变化

说点具体的。这套体系上线三个月后，我统计了一组内部数据：复杂任务的端到端成功率从最初的62%提升到了83%；单次请求的平均推理成本下降了约35%；安全模块累计拦截了大小违规操作上千次，其中包含多起如果放任下去会直接影响业务数据的风险操作。这些数字谈不上惊艳，但在稳定性和可控性上的提升是实打实的。

从我个人的实操体会来说，搭这套体系最大的收获不是把多个模型拼在了一起，而是意识到一个朴素的道理：AI应用的天花板不在模型，在编排。模型的能力是底座，但决定产品体验的是任务拆解是否合理、路由决策是否聪明、记忆管理是否有序、安全策略是否兜得住。

最后分享一个小技巧。在配置路由模型时，不要太追求一次路由就完全正确。给路由加一个"允许修正"的机制：当下游模型发现输入和自身擅长领域不匹配时，允许它回抛给路由重新分配。这样等于给路由加了一个反馈回路，比单纯调阈值要有效得多。

下一篇我会重点写执行层里工具调用的协议设计细节，包括函数描述的编写规范、参数抽取的策略以及错误重试的最佳实践。如果你在那方面有踩坑经验，欢迎一起交流。