前四篇分别写了单模型部署、提示词工程、RAG 向量检索和一次微调踩坑记录都是从单点切入讲实操。这一篇我打算把整套东西彻底串起来完整聊聊我们团队的 AI 中台——内部代号叫“55873 生态”。这套体系的核心是一套613 混合模型矩阵模型之上多建了一层智能体编排层用四层智能体架构把接入、决策、执行、安全全部收拢到一起最后靠一整套安全策略编排机制保证系统在复杂场景下不乱套、不出事。它要解决的具体问题有三个多模型之间怎么协同不打架、Agent 任务怎么稳定流转不失控、安全策略怎么既拦住风险又不误伤正常业务。如果你正在搭企业级 AI 平台或者想把自己的多个模型从“能用”推进到“好用”这篇文章应该能替你省下不少弯路。先说结论这套架构真正难的不是选模型而是怎么把 10 个模型、四层编排逻辑、几十条安全策略经营成一个整体。下面我把设计过程和落地细节全部摊开讲。1. 为什么是 613 混合模型整体设计思路拆解1.1 单模型包打天下的执念我劝你趁早放弃最早我们团队也天真地想过干脆用一个通用大模型解决全部需求算了省事。结果试了不到两个月就被现实打脸三个问题非常明显。第一是场景冲突。同一个模型既要做代码补全又要做客服问答还要做内容审核提示词之间互相干扰。把对话场景的 prompt 调顺了代码场景的输出质量立刻下滑最后每个场景都不满意。这就像让一个全科医生同时看骨科、眼科和传染科虽然都能接但专科深度远远不够。第二是成本失控。所有流量不管简单复杂全部涌向大模型GPU 消耗惊人一句“你好”也要按满 token 算计算力。我们当时统计过大概有 35% 的请求根本用不着大模型出场纯粹浪费。第三是故障风险。单模型挂了就是全局雪崩。模型服务一抖动客服、内部知识库、代码助手全挂了连一个备用的降级通道都没有。就这三点让我们彻底转向了混合模型矩阵的思路。后来我们把架构调整成专业分工的模式就像大医院里不只有一个全科医生而是有急诊科、专科门诊、影像科、检验科每个科室只处理自己最擅长的问题。混合模型矩阵的价值不是“模型多”而是“职责清晰、成本可控、故障隔离”。1.2 六个通用模型、一个调度大脑、三个垂直模型我们的矩阵固定为 10 个模型内部编号就叫“613”。这 10 个模型不是拍脑袋定的而是按业务场景倒推出来的。6 个通用能力模型承担基础能力输出分别是通用文本生成模型对话、润色、摘要、代码生成模型补全、解释、单测生成、多模态理解模型图片识别、OCR、图表理解、语音模型ASR 识别 TTS 合成、Embedding 向量化模型为 RAG 检索和语义匹配提供向量、Text2SQL 模型把自然语言转成结构化查询。1 个统一调度模型是整个矩阵的“路由大脑”核心职责是三件事对用户意图做分类、把复杂任务拆解成子任务、决定当前请求交给哪个模型或哪几个模型协同完成。可以把它理解成医院里的分诊台病人进来先分诊再决定去哪个科室。调度模型本身也是一个模型但它的产出不是内容而是“决策”。3 个垂直领域模型在通用模型的基础上做强化分别是企业客服垂直模型用行业知识微调过话术更贴近业务语境、内容安全检测模型负责敏感信息识别和风险内容初筛、代码安全审计模型专门做代码漏洞的静态初筛。这三个模型有个共同点要的是稳定可重复的判断结果不需要太强的泛化创造力所以参数量不需要很大重点在于精确。整个矩阵的角色分配用一张表来看更直观模型角色数量核心任务部署倾向通用能力模型6文本、代码、多模态、语音、向量、SQL中大规模量化部署统一调度模型1意图识别、任务分解、模型路由中等规模高可用垂直领域模型3客服、内容安全、代码安全小规模快速响应1.3 为什么是 10 个模型而不是更多或更少这里我专门说一下数量边界问题。市面上动不动就有人炫“我们接入了几十个模型”但我个人认为模型数量不是越多越好。每多一个模型就多一份推理资源、多一套监控告警、多一组版本升级联动。模型之间的协同复杂度不是线性增长的而是差不多指数级增长的。613 这个数字是我们用 QPS 压测和成本核算反推出来的平衡点。6 个通用能力已经覆盖了 90% 以上的基础请求类型剩下的长尾场景靠调度模型动态组合能力来覆盖不需要再加新模型。3 个垂直模型解决的是“通用模型做不好”的高频任务再往上加投入产出比就低了。如果团队规模不大我建议你哪怕砍掉几个通用模型也要先把调度模型和垂直安全模型立起来这两个才是体系的承重墙。2. 智能体编排层四层架构的关键设计与实现2.1 四层架构各司其职模型矩阵是“零件”编排层才是把零件组装成机器的“装配线”。我们把编排层拆成四层每一层的职责边界严格划分相互之间只通过统一接口通信。第一层叫接入与感知层是所有请求的统一入口。不管是 Web 端、IM 机器人还是内部 API都先过这一层。它负责四件事请求鉴权、频率限制、参数规整、会话标识分配。第二层叫编排与决策层是整个架构的核心发动机。用户请求在这里完成意图识别、任务规划、模型路由和上下文管理。这层我们内部叫 AgentOrchestrator本质上是一个有状态的任务执行引擎所有 Agent 任务都在这一层被分解和调度。第三层叫执行与工具层负责实际干活。包括调用 RAG 检索、执行外部 API、调用代码解释器、读写业务系统数据。工具调用结果返回给编排层做校验和融合。第四层叫安全与审计层不直接参与业务逻辑但每一层的数据流都会镜像一份给它。在输入侧做拦截、在输出侧做校验、在全程做审计日志记录。层级核心职责关键组件L1 接入感知层鉴权、限流、参数规整API 网关、流量控制、会话管理L2 编排决策层意图识别、任务规划、模型路由路由引擎、上下文管理器、状态机L3 执行工具层RAG 检索、API 调用、代码执行工具注册中心、检索服务、执行沙箱L4 安全审计层输入拦截、输出校验、审计策略引擎、脱敏组件、审计日志2.2 编排层核心从意图识别到模型路由编排层最核心的环节是路由决策。我们不是一股脑把所有请求丢给调度模型判断而是设计了一套“规则优先、模型兜底”的三级路由策略稳定性和灵活性兼顾。第一级是硬规则比如检测到请求里包含图片 URL 或附件标识直接进多模态模型检测到明显的 SQL 语句特征直接进 Text2SQL。这些请求特征明确不需要动用模型判断速度快、可解释性强。第二级是语义匹配把请求的 embedding 向量跟预置场景向量做余弦相似度计算超过阈值的进对应模型。第三级才是调度模型兜底意图模糊、跨场景的请求全部交给调度模型做综合判断。路由配置用 YAML 描述上线后改配置即可不用改代码router: rules: - if: input.contains(图片URL) or input.has_attachment model: multimodal - if: code_score(text) 0.6 model: code - if: contains_sql_intent(text) model: text2sql semantic_route: enabled: true min_similarity: 0.78 fallback_model: chat_main decision_model: router-master这套三级路由上线后调度模型的请求量只占总流量的 30% 左右剩下的 70% 都被规则和语义匹配分流掉了。这里有一个重要心得让模型做路由判断是降级方案不是首选方案。凡是能用确定逻辑解决的就不要把决定权交给概率。这样出了问题也好排查规则是透明的但模型的判断是黑盒。2.3 Agent 任务状态机与上下文管理Agent 任务在编排层内部不是“跑完就扔”的无状态调用每一轮任务都有明确的状态流转。我们内部定义了一个精简的状态机任务先进入等待队列然后做规划确定调用哪些模型和工具接着进入执行阶段工具结果返回后校验通过就组装回复不通过就重试或终止。TASK_STATES [ PENDING, # 待处理 PLANNING, # 意图识别与任务分解 ROUTING, # 模型与工具选择 EXECUTING, # 执行调用 VALIDATING, # 结果校验与安全检测 RETRYING, # 异常重试 TERMINATED, # 任务终止 ]状态机设计里面有两个细节特别容易踩坑。一个是循环上限Agent 在处理复杂任务时经常出现“调用工具→拿到结果→继续调用工具”的循环如果设计时不设上限个别任务会无限烧 token。我们硬性规定一行任务最多执行 5 个工具调用循环超出直接终止并返回上下文摘要用户可以选择继续或者重新提问。另一个是上下文管理。长会话的上下文不可能全量塞给模型本地塞不下、费用也扛不住。我们拆成两段处理短期记忆保留最近 10 轮对话的缩略版本长期记忆只保留用户核心信息和个人偏好的向量索引。每次路由决策前编排层会组装一个精简的上下文包而不是把历史记录全量灌进去。这一步优化直接让端到端延迟降低了 40% 左右。3. 安全策略编排从拦截到审计的闭环实践3.1 安全为什么不能靠每个模型自己管第一版安全方案非常天真我们想在每个模型前面单独挂过滤规则结果上线第一天就出问题同一个问题文本模型拦了代码模型没拦同一个关键词客服场景提示词里出现了没事知识库问答里触发了告警。规则完全不一致而且完全没法联动审计。后来我们想明白了一个道理安全是横切关注点必须从业务代码和模型推理中抽离出来做成一个独立的策略编排引擎。就像大楼的消防系统它不是某一层的装饰而是整栋楼统一规划、统一控制的体系。模型可以换策略编排层不动策略调整时也不影响模型推理逻辑。3.2 三级策略体与动态规则引擎我们的安全策略不是简单的“放行/拦截”二值判断而是设计了三级处置动作强拒绝、告警放行、降级处理。强拒绝用于高置信度的风险请求直接拦截并返回固定提示语不让请求进入模型层。告警放行用于模糊场景放行但记录现场样本供安全团队后续评估。降级处理用于高价值但低风险的业务请求不调用大模型直接返回预设的安全兜底文案保证业务可用性。策略引擎的核心是一个可动态加载的规则集按场景包和角色包组织。场景包定义了“这是什么类型的请求”角色包定义了“当前用户是什么身份权限”两者组合决定最终执行哪些规则policy: scene: customer_service roles: - guest - member rules: - name: prompt_injection_check stage: input action: block fallback: err_msg_injection - name: pii_mask stage: output action: mask fields: [phone, id_card] - name: max_tokens_limit stage: generation value: 2048这套结构的好处是可以按业务场景灰度下发策略。比如客服场景先只对 10% 流量启用新策略观察无误杀后逐步放量到 100%代码助手场景可以单独维持更严格的策略等级。3.3 全链路布防点与敏感信息治理安全布防不是只在入口拦截一次就万事大吉我们在三个位置都放了检测点输入侧负责查 Prompt 注入、越权指令和敏感词输出侧负责查 PII 泄露、合规风险和格式异常审计侧负责全量留痕。输入侧的拦截重点是 Prompt 注入。模型已经成了企业内部工具的一部分如果有人通过对话诱导模型输出不该说的内容或者套取其他用户的私有信息就是大事故。我们用内容安全检测模型做初筛过滤掉明显带注入特征的请求命中“系统指令词”“忽略以上规则”这类特征的直接强拒绝不进入后续流程。输出侧的拦截重点是敏感信息泄露特别是把身份证号、手机号、银行卡号这些明确 PII 字段做脱敏处理。脱敏不是简单打星号而是按字段类型做保留格式的遮蔽比如手机号显示前 3 位后 4 位中间四位打码这样可用性更高。审计侧的日志不能只记录“谁在什么时候问了什么”还要记录“路由到了哪个模型”“命中了哪些策略”“是否触发了降级”。这个全链路 ID 建议在接入层就生成贯穿 L1 到 L4 所有环节方便出问题时快速回溯到具体请求链路。4. 落地部署实录资源规划、性能压测与调优4.1 GPU 资源规划与推理框架选型10 个模型不可能各自独占一张卡成本受不了。我们的做法是给模型分级分配资源大参数量模型独占高显存实例中等模型共享实例小模型直接放 CPU 或者低配 GPU 都行。以我们实际环境为例5 张 A100-80G 的池子里通用文本生成模型和调度模型各独占 1 张卡代码模型和垂直客服模型共享 1 张卡多模态、语音和 Text2SQL 合占 1 张卡Embedding 模型和内容安全检测模型直接 CPUGPU 混合部署在最后 1 张卡的剩余显存上。这套分配方案跑了两个月峰值时段显存利用率能压到 85% 以内没有出现明显的资源瓶颈。推理框架我们统一用的 vLLM它对高并发量和长序列支持都更好配合 PagedAttention 显存管理吞吐比原生部署高出一截。Embedding 模型和内容安全小模型用了 ONNX Runtime因为这些模型结构固定、不需要动态 shape 适配ONNX 部署更轻。4.2 限流、降级与缓存策略模型资源是有限的流量却是突发的所以限流和降级必须提前设计好。我们按“用户维度 场景维度 时段维度”三张配额表做动态限制普通用户每分钟最多 30 次模型调用高优先级用户 100 次复杂场景多模态、Text2SQL的单独配额压得更低防止高成本接口被打爆。缓存策略分了三层第一层是消息级缓存命中用户最近 10 分钟内问过的同一个问题直接返回缓存结果不重跑模型第二层是语义缓存用 embedding 判断两个问题语义相似度超过 0.95 就当作同一问题处理第三层是组件级缓存RAG 检索的向量结果、工具调用的响应都做短时缓存。三层缓存叠加后模型层的实际调用量下降了差不多三分之一。降级链路我们是这么设计的主模型服务异常时自动把流量切到备选小模型备选模型也不可用时进入语义缓存兜底只返回预置的高频问答固定答案。这样极端情况下用户还能收到一个“网络繁忙”或预设文案而不是干等报错。4.3 压测结果和性能指标曲线上线前我们做了一轮完整的压测压测数据给后来扩容提供了比较准的参考。整个链路的目标值设置得比较保守但在 200 并发下能稳住大家可以参考指标项目标值实测峰值首字返回延迟TTFT≤ 800ms平均 380ms完整回复生成吞吐≥ 15 token/s42 token/s模型路由准确率≥ 95%96.2%安全策略误杀率≤ 1%0.8%系统可用性月度≥ 99.5%99.8%有个细节值得单独说TTFT 提升的大头不在模型推理而在上下文组装。之前我们把全部历史对话塞给模型首字延迟直接飙到 1.5 秒以上。改成上下文精简策略之后TTFT 断崖式下降。这说明很多性能问题根本不是模型跑不动而是工程链路把效率拖死了。5. 上线后我踩过的坑高频问题排查与避坑技巧5.1 高频问题速查表系统上线三个月技术群里被问得最多的几个问题基本固定了我整理成一张速查表大家直接照着排查问题现象定位思路解决方案代码问题被路由到通用文本模型检查第三级语义匹配相似度阈值是否过低将代码意图专属的场景向量加入语义库提高代码识别的优先级长会话对话突然中断检查上下文 token 数是否超过模型上下文窗口启用上下文压缩策略超过阈值自动摘要历史正常业务问题被安全策略拦截查看审计日志命中策略的置信度打分将误杀样本加入白名单并调整对应规则的阈值Agent 任务长时间不返回检查状态机是否卡在 EXECUTING开启超时熔断单步执行超时 30 秒强制终止多模型并发时显存 OOM观察卡上活跃实例数和峰值显存开启 vLLM 的自动调度增加模型实例排队机制5.2 一次典型事故的处理实录这里分享一次我们处理得比较难看的事故。某天下午内容安全检测模型突然把一批正常的客户咨询判定为风险问题全部强拒绝导致客服值班群瞬间被轰炸客诉量直接翻了三倍。排查过程是这样的先看策略引擎的日志发现命中策略全部是“prompt_injection_check”而且置信度打分异常高。再看内容安全检测模型的输入发现当天上午运维人员把这个模型的提示词更新了一版新版提示词里加了一段“你是一个严格的安全审查员必须优先拦截所有包含换行符、符号密集、疑似指令的请求”的描述。这直接导致模型对所有格式稍微复杂的正常请求都产生了误判。问题定位后处理倒是快回滚提示词版本策略引擎里对客服场景临时加了白名单十分钟内恢复了正常。但教训很深刻给安全模型的提示词改动必须走灰度任何一点措辞变化都可能造成灾难性的误杀。现在我们对安全检测模型的每一条提示词修改都要求先在离线样本集上做回归测试通过以后才能上线再也不敢直接改了。5.3 几条保命级别的避坑经验最后补充三条我自己用真金白银换来的经验。第一新模型接入不要直接上全量流量先按 5% 灰度放行。我们接入新版本的代码模型时贪快直接全量上了结果新版模型在部分代码风格上的输出质量比旧版差一大截等用户反馈过来已经积压了大量错误代码建议。灰度放行跑一天观察数据和用户反馈再逐步放量这是对用户负责也是对自己负责。第二安全策略每周做一次离线回放。把过去一周的拦截日志全部取出来人工筛选被误杀的样本每周固定补一次白名单和阈值校准。不坚持做这一步策略引擎的准确率会随时间默默下滑等你发现时已经积了很多隐患。第三所有模型名称不要在代码里写死。模型升级、替换、退役在体系里是常态如果代码里到处是model_namechat_v1这种字样每次升级都是一次灾难。我们把所有模型调用都收敛成统一接口通过配置中心做版本映射上层业务根本感知不到底层模型换了。这套体系从架构设计到稳定运行前后花了四个多月。如果让我提炼一句话那就是混合模型负责解决能力边界问题智能体编排层负责解决系统复杂度问题安全策略编排负责解决信任问题三者缺一不可。单点技术再强整合不好也是白搭。我个人最大的感触是技术难点其实不在模型选型而在编排与安全的平衡。编排层管得太死系统灵活性和扩展性就受影响安全策略管得太松事故随时给你脸色看。后面我打算在可观测性子系统和模型效果回归体系上再做一轮优化等有实际进展了再来更新第 6 篇。如果你也在搭类似的体系欢迎照着上面的思路先试起来遇到具体问题再逐个拆解。