大模型项目做多了你会发现一个特别扎心的规律单靠一个“大而全”的模型根本撑不起一个真正能落地的生产系统。不是模型能力不够而是成本、延迟、安全、并发这些问题拧在一起逼着你把“模型”拆成“模型体系”再把“模型体系”和“能干活的人”拼成一套生态。这期想拆的这套体系我内部编号叫 55873一句话能说清核心结构613 混合模型矩阵 四层智能体架构 安全策略编排。它不是某个开源项目也不是某个厂商的白皮书而是我在做企业级 AI 智能体平台过程中沉淀下来的一套参考设计。如果你正在搭智能体平台架构或者正在纠结“我到底该用几个模型、模型之间怎么分工、怎么防止被简单 prompt 打穿”这篇内容大概率值得你泡杯茶慢慢看。1. 613 混合模型矩阵为什么非要“拆着用”先说结论模型选型这件事最怕“一个模型走天下”。55873 体系里的“613”本质上是把模型按职责拆成三类角色6 个专用模型负责跑量、1 个主模型负责推理、3 个辅助模型负责安全和质量。加起来 10 个模型听着吓人实际跑起来反而比只挂一个大模型省钱一个数量级。1.1 核心需求解析精度、成本与延迟的三角博弈做 AI 模型部署第一刀要切在“请求类型”上。一个企业级智能体平台每天进来的请求大致可以分成三类高频且简单的识别类请求、中频且复杂的推理类请求、低频但要求极高的安全/质量类请求。这三类请求的模型诉求完全不同。简单意图识别用百亿参数的模型去做纯属浪费——响应慢单次推理成本高还容易因为模型太大在推理时不稳定。而复杂任务规划用小模型去做又会发现它根本 hold 不住长上下文和多步推理。这时候如果你只用一个大模型兜底全部请求成本会迅速吃掉整个项目的利润如果你只用一个小模型硬撑用户的体验又会差到让人想卸载。613 的思路非常直白按请求复杂度和安全要求把流量分到不同的模型层级上。6 个专用模型解决 80% 的简单请求各自精通一项1 个主模型只处理剩下的 20% 复杂推理3 个辅助模型不直接面向业务而是横向穿插在链路里做安全、质量、记忆的兜底。用一句行话讲这不是模型选型问题这是系统架构问题。1.2 六个专用模型跑量主力每块砖都有明确用途6 个专用模型我按实际业务场景拆成了以下岗位每门只做好一件事训练和部署成本都能压缩到很低的水平意图识别模型负责判断用户的请求类型——是查知识库、生成文案、分析数据、还是要调用某个工具。这个模型不参与任何生成只输出一个分类结果所以可以用轻量级的分类模型单次推理控制在几十毫秒。实体抽取与文本解析模型负责从用户问题、上传文档里抽关键词、结构化信息比如日期、金额、合同编号、产品型号。它把抽取结果变成 Json 传给后续流程是数据进 RAG 前的第一道工序。检索重排模型负责从向量数据库召回候选片段之后做第二轮的精细排序。前期召回可能拉回 50 条片段重排模型从里面挑出最相关的 5 条保证主模型不会读到一堆噪声内容。文档摘要与内容生成模型负责写日报、总结会议纪要、生成周报初稿这类高频生成任务。生成任务不需要太深推理中等规模的模型就能在一个合理质量线上稳定输出。代码生成与数据查询模型负责把用户的自然语言问题翻译成 SQL、Python 脚本或 API 调用参数。这个模型要求输出结构必须正确所以我会单独微调它的输出格式不允许它自由发挥。对话质检与情感模型用在客服场景里判断用户是否不满、是否需要人工介入。它同时给每条会话打一个“紧急程度”评分作为路由层判断是否切换到人工的重要参考。这 6 个模型有一个共同特点输出是结构化的或者输出范围是受限的所以它们天然适合快而稳的刻意设计。我的做法是每个模型都单独做服务化部署用极低的并发资源就能扛住一天几十万次的调用从源头把推理成本打下来。1.3 一个主模型推理中枢处理“需要想一下”的事专用模型能解决“看到就能答”的问题但解决不了“需要想一下”的问题。比如用户问“我们上季度华东区销售额为什么下滑和华北区对比怎么样”这个问题需要先拆条件、再检索、再对比、再总结期间还要调用不止一个工具——这种任务只能交给 1 个主模型。主模型的选型标准不是“越大越好”而是“在合理延迟内能给出稳定的多步骤推理”。我现在实际生产里倾向选用支持长上下文、具备函数调用能力的开源模型量级在 7B 到 14B 之间配合量化精度控制在 4bit 或 8bit。它负责三件事接收任务规划层拆好的子任务生成最终答案在复杂对话中做全局的语义理解综合多轮上下文对专用模型输出的结构化结果做“人话化”包装让它读起来自然、有逻辑。注意主模型不是每请求都要触发的。我的规则是意图识别模型判断为简单请求时直接让对应专用模型返回只有意图识别模型的置信度低于某个阈值或者请求被判定为“多步骤任务”才会把流量转发给主模型。这一步卡掉大约 70% 的流量是我整套架构成本控制的关键。1.4 三个辅助模型安全、质量和记忆的隐形护法剩下 3 个模型在标题里容易被人忽略但恰恰是整个 55873 生态的稳定器内容安全审查模型所有进入系统的大模型输入、输出都要过它一遍。它的任务包括识别提示词注入、检测越狱尝试、标记敏感话题、捕捉异常输出。这个模型不需要很大的参数量但需要特别高的召回率宁可误判不要漏判。答案质量校验模型负责检查主模型生成的答案和知识库原文是否一致有没有幻觉有没有关键信息缺失。它通过“问答一致性打分”的方式工作把原始答案和检索到的参考片段都喂给它让它输出一个 0 到 1 的一致性评分。评分低于阈值系统会触发二次生成或者直接拒绝答案。记忆与画像模型负责构建用户的长期记忆。它会从历史对话里抽取偏好、常用术语、兴趣标签做成向量存到记忆库。这个模型和主模型不同它不需要生成完整回答只需要提炼和向量化。三个辅助模型加在一起单次调用的平均延迟目标在 200 毫秒以内但它们的价值不在速度而在于让整条链路具备了“把错误挡在门外”和“让系统越来越懂用户”的能力。2. 四层智能体架构从一次请求到一整套动作模型矩阵是“弹药”智能体架构是“作战体系”。四层智能体架构在我的设计里是一套严格的层级关系接入层、规划层、执行层、反思与记忆层。每一层只做自己的事不越权不回头才能保证整套系统的行为可预测、可追踪。2.1 第一层会话接入层负责理解“谁在什么场景下说了什么”接入层是所有请求的入口它由三个组件组成身份认证、场景识别、意图识别。身份认证决定这个用户的权限范围比如普通员工能不能查薪资数据部门负责人能不能看跨组报表场景识别决定这个请求要匹配哪套指令模板是客服场景、内部问答场景还是数据分析场景意图识别则把请求分成“可直接回答”“需要检索”“需要调用工具”“需要人工介入”四种去向。接入层这一层看起来简单最容易踩的坑是把“意图识别”做成一次性判断。实际上用户经常在一句话里同时表达多个意图比如“帮我把上季度的数据拉出来然后总结一下最后发到群里”。我的做法是将意图识别拆成三步第一轮粗分类第二轮细拆解第三轮用置信度阈值决定谁接管。如果连续两次意图识别结果不一致宁可转人工或让用户确认也不能自作主张。接入层的另一个重要作用是建立会话上下文 ID。这个 ID 贯穿后面所有层级的日志是安全审计和责任追溯的最小单元。没有这层设计后续所有层级的调用互相割裂出了问题根本无法复盘。2.2 第二层任务规划层把“一句话”拆成“一张图”任务规划层是智能体的“大脑皮层”它做的事情用一句话描述就是把用户目标拆成可执行的子任务序列。这里有一个非常核心的设计点任务规划层不能直接调用工具它只负责输出任务清单和依赖关系。比如用户说“对比一下 A 产品和 B 产品近半年的销量输出一份分析报告”规划层会输出查询商品数据库分别获取 A、B 产品近半年销量数据对两组数据做趋势对比找出峰值和谷值汇总分析结果生成报告大纲调用报告模板填充内容最终校验并返回。规划层输出的不是一句话而是一份带状态机的任务 DAG。每个子任务都有明确的输入、输出、依赖关系、预期超时时间。这里我强烈建议不要用“自由对话式规划”而要用“模板 开放扩展”的方式主模型在预设的任务模板库里边选边改而不是每次从零生成计划。没有模板约束一旦主模型温度参数略高任务规划就会跑偏到离奇的方向后面执行层全跟着遭殃。规划层还必须遵守一条铁律所有子任务都必须在执行之前标注数据敏感级别。比如任务涉及用户手机号标记为“高敏感”对应权限不足的执行单元要被拦截。2.3 第三层工具执行层真正“动手”的地方执行层负责干两件事一是根据规划层给出的子任务清单选择最合适的专用模型或者工具去执行二是处理工具返回的原始结果做清洗、转换、标准化。工具执行层的核心难点在中途失败处理。现实世界里工具调用不可能永远成功——数据库连不上、API 超时、检索结果为空这些情况天天见。我的经验是执行层不做“默默重试”要做“带反馈的重试”。第一次失败记录错误原因第二次重试换参数或换路径第三次仍然失败就直接把错误信息返回给规划层由规划层重新生成子任务或者降级处理。比如原计划查数据库失败就降级为查缓存再不行就提示用户“数据暂时不可用”。另一个容易踩的坑是工具参数注入。用户看似无害的一句话里可能藏着特殊字符直接拼进 SQL 就会出大问题。我在执行层强制所有工具参数都走“白名单校验 转义处理 类型强校验”宁可多加一道序列化也不允许原始字符串直接透传给任何数据库或命令行。2.4 第四层反思与记忆层让系统学会“复盘”反思与记忆层平时不怎么显眼但它是决定整套智能体是“越用越好用”还是“越用越混乱”的关键。反思机制做三件事结果校验验证执行层的输出是否符合用户原意是否有遗漏条件过程复盘把一次完整的请求、规划 DAG、每一次模型调用、每一次工具调用记录成一条轨迹存入经验库策略修正发现某类问题反复失败时把修正规则注入规划层的模板库。比如系统连续三次在“比较大小”任务上失败经验库就会沉淀一条“涉及数字比较必须用代码计算不允许模型直接口算”的规则。记忆机制则负责把用户长期偏好、历史决策、常用业务黑话写进记忆库。注意记忆库不是对话历史的简单堆积而是经过“记忆与画像模型”提炼后的压缩结构化数据。我强烈建议所有记忆在进入上下文前都必须经过一层“相关性筛选”只取和当前请求最相关的一组记忆否则上下文被塞满无用历史主模型的注意力会被稀释。3. 安全策略编排把安全当系统设计而不是事后补丁很多团队做 AI 应用安全是最后的“灵光一闪”上线后出问题了才想起来拿一个内容审核 API 挡在前面。这种做法在 55873 里根本不可行。我的观点是安全必须是一个独立于业务链路的编排层从请求入口到输出出口每个节点都执行“安全检查 策略判断”双轨机制。3.1 安全策略按层级下沉不搞一刀切传统安全方案喜欢“一刀切”所有输入统一过一个敏感词库所有输出统一过一个审查器。看起来省事实际体验非常糟糕。因为企业场景里很多词语必须放在上下文中判断用户问“贷款”很可能是在咨询公司内部的贷款产品“头痛药”是药店客服的日常词。一刀切拦截会把正常业务误杀也会漏掉那些“每个字都正常连起来却在绕过规则”的注入攻击。55873 的策略编排做法是安全策略跟着业务场景走至少分三个档位。高安全档位所有输入输出都过完整的内容安全审查适用场景如金融咨询、医疗咨询、HR 敏感数据处理中安全档位输入过安全审查输出做质量校验 抽样安全复审适用场景如内部知识问答低安全档位只做基础敏感词过滤 审计日志记录适用场景如内部系统运维辅助、代码注释生成。高低档位的切换不是拍脑袋定的而是根据接入层的场景识别结果自动匹配。这样既不牺牲安全也不牺牲业务灵活性。3.2 智能体链路中的安全切断点把大模型关进“笼子”四层智能体架构里安全策略编排最少要设置四个切断点入口切断点在会话接入层之后、任务规划层之前识别提示词注入和越狱攻击。这个切断点最关键一旦发现异常整个请求直接终止不做任何后续动作。工具调用切断点在工具执行层调用任何外部资源之前校验参数、校验权限、校验路径。这层在于防止模型被诱导去读取不该读的文件、调用不该调用的 API。输出切断点在主模型返回结果之后、回答用户之前做内容安全审查和答案一致性校验。这层防的是模型被深度诱导后输出风险内容或者答案里出现和知识库完全矛盾的幻觉。经验沉淀切断点在反思与记忆层写入记忆/经验之前做脱敏处理。这层防止用户的敏感信息被存进长期记忆也防止经验库被污染——如果某条经验本身是错误策略后面所有请求都会被带偏。四个切断点全部要在路由链路里串联起来任何一个节点判定“不通过”就不能进入下一层。3.3 可追踪的审计链每一层都留下指纹安全策略编排的最后一环是审计。我在每个切断点都生成一条结构化的审计事件包含时间戳、请求 ID、模型调用类型、输入输出摘要、策略判定结果、延迟耗时。所有审计事件汇入统一日志平台按请求 ID 一键拉取全链路记录。这套审计链的威力在于出了安全事件你不需要去翻一堆碎片化的日志直接按请求 ID 搜索就能看到“用户说了什么→模型识别成什么→规划层拆成什么→工具层调用了什么→输出审查如何判定→最终返回了什么”。我遇到过几次需要向合规部门提供证据的场景都是靠这套审计链几十秒就给出结论。4. 常见问题与排查技巧实录理论说再多不如直接抖点实战踩坑的干货。以下是我在 55873 生态搭建和运行过程中印象最深的四个问题以及对应的排查思路。4.1 路由发飘同样的表述两次走进了不同模型我在接入层用意图识别模型做路由时早期遇到一个诡异现象用户连续两天问几乎一样的问题第一次走了专用模型秒回第二次却走了主模型慢吞吞分析。查了半天发现是意图识别模型对表述做归一化处理时没有统一大小写和缩写格式。比如“OKRs”和“okrs”在部分分词器里会被拆成不同的 token直接影响分类结果。我的解决方案是在意图识别模型前加一个轻量的文本归一化组件统一大小写、全半角、缩写展开、敏感词标记。归一化之后意图识别模型的输入就不再是野路子了。做完这个改动路由稳定性明显提升。4.2 多步骤任务陷入循环规划层和执行层打转智能体系统最容易翻车的场景是多步骤任务的死循环。典型表现规划层拆了 5 个子任务执行完第 3 个发现结果不符合预期于是规划层重新生成计划新计划又引入新的子任务导致系统在一层又一层“重新规划”里空转直到超时。这个问题根因是规划层没有设计“重规划次数上限”。我的修复方案任务规划层每输出一个子任务都附带一个“最大重规划次数”字段默认 3 次。一旦超过限制系统强制收敛把当前已有的结果打包返回同时追加一条“部分完成”的提示。另外执行层的失败反馈要更具体不是抛一句“任务失败”而是带上失败原因的分类编码规划层才能根据编码做有针对性的调整而不是盲目重新生成计划。4.3 安全策略误伤太多业务方差点掀桌子安全编排层刚上线时我把所有场景默认为高安全档位规则也写得特别严格。结果运营同事反馈客户问“怎么申请理赔”直接被安全拦截因为规则库把“理赔”和“投诉”混在了一起用户问“你们的价格为什么比去年高”也被判成敏感比较触发人工介入。排查后发现问题出在策略路由对“业务上下文”感知不足。我只做了关键词规则没有结合意图识别结果做联合判断。后来我调整了策略编排结构安全策略的触发条件里强制加入“意图类型”作为上下文参数。比如只有意图是“投诉维权”的请求才会触发高敏感拦截意图是“业务咨询”的请求走中安全档位正常回答后再做输出审查。调整之后误伤率降了三分之二安全召回率没有明显下降。4.4 延迟兜不住模型越多链路越慢55873 生态有 10 个模型如果每次请求都把该调不该调的模型全部串行跑一遍延迟直接爆炸。早期我统计过一次一次完整的多步骤请求光模型调用就串了 7 次总延迟超过了 5 秒这在生产环境里基本不可接受。我的优化思路有三个层次。第一个层次是“并行化”把无依赖的子任务并行执行比如同时抽取实体、做检索重排、生成摘要第二个层次是“预取”高频请求的相关结果提前放进缓存检索重排模型和摘要模型命中缓存时直接跳过第三个层次是“降级”在低峰期把专用模型部署实例数降到最低高峰期用弹性扩容顶上去。做完这三层优化同样的多步骤请求总延迟压到 1.8 秒左右而且模型越多这套并行和缓存的收益越明显。5. 写在最后的一些经验沉淀55873 生态这套设计说到底解决的是一个朴素的问题大模型时代系统架构师真正要设计的不是某个模型而是多个模型如何不打架、不越权、不拖垮系统地完成一次复杂任务。613 的模型矩阵给了我们按需调度的成本弹性四层智能体架构给了我们行为可控的执行链路安全策略编排则保证了这一切不会失控。我个人在实际操作中最深的体会是这套体系最不能省的不是主模型的参数量而是那条审计链。模型选得再差后面还能换审计链要是没搭好出了问题连根因都找不到。如果你正准备搭自己的智能体平台架构我的建议是从小处起步不要一上来就十模型满天飞。先搭一层接入 一个主模型 一个安全审查模型跑通一个核心场景再把高频的简单请求逐步分流给专用模型慢慢演进成 613 的完整形态。实际上模型越多对基建和运维的考验越大没有一套成熟的监控、日志、路由机制兜底扩得越快崩得越惨。55873 不是终点它只是一个已经被验证过、值得抄作业的起点。