做个AI基础设施做了三年我最大的感受是单点模型再强放不进一套完整体系里就是一堆昂贵的摆设。业务方今天要聊天机器人明天要文档问答后天要代码审查你如果每个需求都单独接一个模型、单独写一套调用逻辑最后维护成本能把团队活活拖死。这篇是技术系列第5篇我把手头跑通的这套方案完整拆开来讲——内部代号“55873生态”核心就三件事613混合模型矩阵、四层智能体架构、安全策略编排。这套东西不是实验室玩具已经在真实业务流量下跑了半年多适合正打算做企业级AI平台、或者已经觉得“模型太多没法管理”的团队参考。1. 为什么需要“模型体系 智能体编排层”一起设计1.1 单一大模型的三个致命问题先说个反直觉的结论如果你的业务只有一个模型调用入口初期很爽后面会越来越难受。第一个问题是成本失控。通用大模型处理所有请求看起来省心实际上大量简单任务根本不需要那么大的模型。客服场景里“我要改收货地址”这种意图用一个7B的小模型就够了非要去调用千亿级底座每轮推理都是烧钱。第二个问题是领域能力不足。通用模型在代码审查、中医知识问答、特定业务数据分析这些垂直场景下回答质量远不如一个针对性微调过的专科模型。第三个问题是安全策略没法沉淀。很多团队把关键词过滤、敏感信息脱敏、输出合规检查全部散落在业务代码里今天加一个if明天加一个正则到最后没人说得清完整的策略链路长什么样审计更是无从谈起。这时候需要的不是“再找一个更大的模型”而是把模型、智能体、安全当作一个整体来设计。模型负责“能力”智能体负责“编排”安全负责“边界”三者缺一不可。1.2 “55873生态”的命名由来与整体边界“55873”不是拍脑袋的版本号是我们内部对这套体系的边界定义5类基础模型底座5条核心业务线8个标准化模型服务接口7层安全防护机制3套部署形态中心集群、边缘节点、端侧推理。这个数字组合方便记忆也让团队能一眼看出一套系统覆盖了什么。在这套生态里模型不是一个黑盒API而是被拆成一张矩阵表来管理。矩阵的横向是任务类型纵向是模型规格。所有的调用不直连模型而是经过一个智能体编排层统一调度。这个编排层负责理解用户意图、拆解任务、选择模型、调用工具、检查结果再把安全策略编排成流水线嵌入每一步。没有这个编排层613模型矩阵就是6加1加3个没人理清的野接口。2. 613 混合模型矩阵各司其职而不是追大求全2.1 矩阵拆解6个专项模型管好每一类专业活很多人一听到混合模型第一反应是“搞一堆模型跑起来靠运气看谁答得好”。这是误区。混合模型的核心是分工每个模型只负责自己最擅长的那一类任务。我们这里的“6”是6个经微调后的领域专项模型。名字不重要给你看角色和参数客服语义理解模型7B负责售前售后对话中的槽位提取和意图分类代码缺陷检查模型13B负责静态代码扫描和变更风险提示知识库问答模型7B基于企业内部文档做RAG化回答数据分析模型13B负责把自然语言问题转成SQL并解释查询结果营销内容生成模型7B负责文案和话术生成强约束在品牌合规范围内语音转写后处理模型3B负责ASR结果的标点恢复、纠错和说话人区分。选择7B/13B这个量级不是偶然。实测下来7B模型在单一垂直任务上用LoRA微调后的效果已经能追平很多没有做行业强化的通用大模型而推理成本只有后者的五分之一。13B模型用于更复杂的逻辑任务兼顾质量和速度。在实际分配请求时每个专项模型前都有一个独立的队列和超时控制避免某一个任务打爆后拖垮全局。2.2 1个中枢模型如何完成路由与意图理解“1”是整个矩阵里最关键的组件一个中枢编排模型。它不直接回答业务问题而是负责听明白用户到底想干什么然后决定把请求发给谁。这个中枢模型同样经过微调输入是用户的原始问题输出是一个结构化路由指令包括任务类型intent、置信度confidence、参数slots和可选的候选模型列表。举个例子用户问“帮我查一下上个月的退货率”中枢模型会输出{ intent: data_analysis, confidence: 0.92, slots: {metric: return_rate, period: last_month}, route: [dm-analyst-13b, dm-general-70b] }如果置信度低于0.7中枢模型不会硬分而是返回“需澄清”状态让智能体编排层反问用户。这比直接扔给大模型碰运气要可靠得多。中枢模型每隔一段时间还要通过线上反馈数据做增量微调保持路由准确率。2.3 3个端侧轻量模型的价值“3”是三个部署在端侧或边缘节点的轻量模型参数量都在1B以下。别小看它们它们承担了体系里最脏最累的活。第一个是意图预筛模型0.5B在请求到达中枢模型之前先做第一道粗分类把“闲聊”和“正经任务”分开。闲聊直接回复固定话术不占中枢模型资源。第二个是敏感信息识别模型0.8B在输入侧和输出侧同时运行识别身份证号、手机号、银行卡号、地址等PII信息命中后触发脱敏策略。第三个是摘要抽取模型1.2B用于在请求进入大模型前压缩上下文降低token消耗还能在日志落地前抽取关键信息用于审计。这三个模型跑在CPU上都能实时响应。实测下来请求经过预筛后真正打到中枢模型和专项模型的流量能减少约40%。对于成本敏感的场景这三个小模型才是降本的主力。2.4 模型路由策略与参数选择模型矩阵确定后路由策略是落地重点。我们的路由不是简单的if-else而是按“成本梯度”设计第一梯度是端侧轻量模型处理高损耗低价值的请求第二梯度是垂直专项模型处理明确的业务任务第三梯度才是通用大模型兜底处理那些专项模型都搞不定的复杂开放域任务。每次路由发生时编排层都会记录路由路径、模型版本、耗时、费用这四个关键字段用于后续的路由优化。参数选择上各专项模型的temperature要严格控制。营销文案类任务可以稍微放开到0.9保留创作空间数据分析、代码检查类任务一律0.2以下减少幻觉。max_tokens也要按任务类型设置客服问答256足够知识库问答给到1024代码审查则需要2048防止模型生成到一半被截断。3. 四层智能体架构从用户输入到任务闭环3.1 第一层接入与感知层四层智能体架构不是四个模块简单堆叠而是把“一个人解决问题”的流程翻译成系统流程。第一层是接入与感知层负责对上屏蔽所有渠道差异。这里要统一处理的东西很多Web页面、企业微信、钉钉、邮件、API直连每种渠道的请求格式都不一样。我们做了一个统一的中转网关把外部请求转换成内部的标准事件结构event_id、user_id、channel、input_type、raw_data、timestamp。感知层还要负责多模态数据的初步处理如果是图片就过一遍OCR如果是语音就过一遍ASR然后连同文本一起打包交给下一层。这层最容易犯的错是在网关里写业务逻辑。网关只做格式转换和鉴权一旦出现“这个用户是VIP所以直接走高级模型”这种业务判断编排层就没法统一管理了。我们踩过这个坑后来把所有业务规则全部挪进编排层网关瘦得只剩下管道功能。3.2 第二层规划与决策层第二层是整个智能体架构的大脑也是“智能体”这个词的核心体现。它接收感知层传进来的标准事件先通过中枢模型或端侧预筛模型识别意图再根据意图生成一个执行计划。执行计划不是一串固定的步骤而是一个树状结构。每个节点代表一个原子动作比如“调用客服模型”“查询订单库”“生成回复”节点之间有依赖关系。这个方案的好处是支持并行动作。用户问“对比这两款产品的价格和参数”编排层能把“查询产品A”“查询产品B”“提取参数”三个动作并行下发全部返回后再合成答案整体延迟能降低一半。规划与决策层还需要维护“会话状态”。每轮交互的中间结果都保存在一个短期记忆池里TTL设为30分钟。决策层通过状态机判断当前轮到哪一步避免多轮对话上下文断裂。3.3 第三层执行与工具层第三层负责真正干脏活累活。所有外部依赖都被封装成统一工具接口每个工具包含名称、描述、输入参数schema、调用地址、超时时间、重试次数。工具类型包括模型调用工具、数据库查询工具、HTTP API工具、代码执行工具、文件读写工具。工具层最关键的设计是“沙箱隔离”。代码执行工具必须在容器里运行容器内存上限512MBCPU配额1核超时30秒强制杀掉。数据库查询工具只允许经过预编译的SQL模板禁止拼接SQL。我们曾经遇到过模型生成的SQL里带了删除操作如果不是在工具层做了白名单拦截后果不敢想。工具层还要做失败重试和降级。一个工具连续失败两次后编排层会触发“故障转移”策略比如主数据库掉线自动切换只读从库模型服务超时自动选择同类型的备用模型。这些策略全部是可配置的不写死在代码里。3.4 第四层反思与记忆层第四层是很多人容易忽略的一层它的作用是让智能体“越用越聪明”。这里面做了三件事结果校验、长期记忆、反馈回流。结果校验不是简单判断“有没有输出”而是对输出做一致性检查。数据分析任务要验证SQL执行是否报错、返回的行数是否在预期范围、答案中的数字是否与查询结果一致。客服任务要检查回复中是否含有未解决的疑问点。校验不通过时触发重规划重新走一遍第二层和第三层。长期记忆采用向量数据库存储按用户维度分离。每个用户的偏好、历史工单、常见问题都会被抽取成向量和摘要存入记忆池。注意隐私边界敏感信息在入库前必须经过脱敏且用户可以一键清空自己的记忆。反馈回流是把线上用户对回复的点赞、点踩、纠错数据收集起来按周汇总形成微调数据集和路由优化依据。这套闭环跑起来后每个月专项模型的效果都有肉眼可见的进步。4. 安全策略编排把安全做成一个可编排的流水线4.1 安全策略链的整体设计安全最怕“散装”。在智能体架构里安全策略应该像流水线一样串联起来每一步都可以插拔、配置、测试。我们把安全策略编排在请求进入编排层之前和返回给用户之前各跑一遍同时在工具调用过程中也挂上安全钩子。一个典型的请求生命周期是这样的先经过网关鉴权再进入输入安全策略链敏感信息识别、Prompt注入检测、内容分级然后进入路由决策再到模型调用模型输出经过输出安全策略链合规校验、PII脱敏、格式校验最后通过审计日志模块落地。整套策略链用YAML文件定义顺序和参数调策略不需要改代码只需要重载配置。4.2 模型输入输出侧的关键策略输入侧的重点是防止恶意指令和敏感数据外泄。Prompt注入检测我们采用了“双重检测”先用轻量模型做分类命中可疑再走规则库细查。规则库里有针对“忽略之前指令”“输出系统提示词”等注入模式的语义特征。输出侧的重点是防止有害内容和数据泄露。所有输出都要过一轮敏感信息识别一旦检测到身份证号或银行卡号会执行部分脱敏。合规校验用的是自定义词库加分类模型组合确保输出内容符合公序良俗。这里要特别提醒安全策略不能只做“有没有命中词库”的布尔判断还要看置信度和上下文否则很容易误杀正常业务回复。4.3 数据与审计策略数据安全不能只盯着模型输出要看全链路。我们的日志系统记录了每一次请求的完整链路包括输入指纹、路由结果、模型输出、安全策略命中项、耗时和费用。日志脱敏后保存在独立的审计库中只允许审计角色访问。训练数据的使用也要严格管控。用于微调的数据集必须经过数据清洗和标注安全审核每个数据集都有版本号和数据血缘记录。特别提醒千万不能让生产环境的真实用户数据直接进微调流程否则一个不小心就会造成隐私泄露。4.4 流程级保护限流、熔断与人工介入安全不只是过滤内容还包括保护系统本身。限流策略按用户、按渠道、按模型维度设置三档配额。比如普通用户每分钟最多20次调用深度分析类模型每分钟最多5次。超出配额直接返回排队提示而不是让它无限堆积。熔断策略针对模型服务异常。连续5个请求超时或返回错误码编排层会打开熔断开关暂停调用该模型切换备用模型或返回兜底话术。熔断恢复采用半开状态先放1%的流量探测稳定后再逐渐放量。关键业务场景必须有人工介入机制。比如涉及退款申诉、医疗建议、法律条款解释的高风险操作系统可以自动生成一个“转人工”事件附上完整的推理过程和候选回复由人工确认后才允许发出。这个设计在合规审查中非常加分。5. 落地实操从0到1搭建最小可用编排层5.1 环境与模型清单如果不想一开始就铺太大可以按最小闭环来搭1个端侧意图模型、1个中枢模型、2个专项模型、1个通用兜底模型再加上四层智能体框架和安全策略链。服务器建议4台GPU机器两台负责中心侧模型推理A10级别足够一台跑端侧模型和编排服务一台做日志和向量库。模型用开源底座微调即可。我们内部用的底座是13B和7B两个尺寸分别做专项训练。微调采用QLoRA单张16G显存可以跑7B模型13B模型需要两张卡。数据集量不需要太大每个专项任务准备5000到20000条高质量数据就够。5.2 智能体编排核心代码示例下面给一个简化但可运行的编排核心示例省略了具体模型服务细节重点看分层和路由逻辑class AgentOrchestrator: def __init__(self, router, tools, memory, security_chain): self.router router self.tools tools self.memory memory self.security_chain security_chain async def handle(self, event): event_id event[event_id] # 输入安全策略 safe_event await self.security_chain.input_check(event) if safe_event[action] block: return self._build_response(safe_event[reason]) # 第一层已由网关完成标准事件构造这里直接做意图路由 route await self.router.route(safe_event[text]) if route[confidence] 0.7: return self._ask_clarify(route[ambiguous]) # 第二层生成执行计划简化为直接选择模型 if route[intent] knowledge_qa: result await self.tools.call(model, knowledge-7b, safe_event[text]) elif route[intent] data_analysis: sql await self.tools.call(model, analyst-13b, safe_event[text]) rows await self.tools.call(db, read, sql) result await self.tools.call(model, analyst-13b, rows, modeexplain) else: result await self.tools.call(model, general-70b, safe_event[text]) # 第四层结果校验 if not self._validate(route[intent], result): result await self._replan(route, safe_event[text]) # 记忆更新 await self.memory.save(event_id, safe_event[text], result) # 输出安全策略 safe_result await self.security_chain.output_check(result) return self._build_response(safe_result[text])这版代码的核心思想是编排层不关心模型内部怎么算只关心路由、调用、校验、安全这四个动作。后续加新模型只需要扩展router和tools注册表。5.3 安全策略编排配置示例安全策略链用YAML配置的好处是运维和算法可以分开协作。下面是一段简化配置定义了一条输入策略链security_chain: input: - name: auth_check type: gate params: allowed_channels: [web, wecom, api] - name: prompt_injection_detect type: model_classifier params: model: sec-injection-0.8b threshold: 0.8 action: block - name: pii_detect type: model_detector params: model: sec-pii-0.8b action: mask mask_keys: [phone, id_card, bank_card] - name: content_grade type: rule_based params: block_keywords: [] sensitive_keywords: [] log_hit: trueoutput策略链类似额外加一个“json_schema_check”保证模型输出符合业务需要的格式避免前端拿到无法解析的内容。5.4 部署后的性能验证方法最小闭环跑通后不要急着接真实流量。先做三件事第一用录制的历史请求做回放对比新体系和旧逻辑的成功率、延迟、费用第二做并发压测我们目标TP95延迟不超过3秒模型服务单实例QPS至少20第三安全策略专项测试准备100条注入攻击样本和200条含PII的测试文本验证拦截率和误杀率。压测时特别关注端侧模型分流带来的成本变化。按经验加入意图预筛后中心模型的调用量会下降35%-45%但如果发现预筛准确率过低导致错误拦截反而要调整阈值。安全策略的过滤节点也要做性能耗时统计单个策略节点耗时不能超过20ms否则整个链路延迟顶不住。6. 常见问题与排查技巧实录6.1 模型路由不准怎么办路由不准最典型的场景是用户明明在做数据分析中枢模型却把请求路由到了知识库问答。排查步骤分三步先看路由日志里的confidence和slot提取结果确认是不是槽位识别丢了字段再看训练数据里这类样本是不是太少一般需要补充至少500条易混淆样本重新微调最后检查是否被端侧预筛模型误改意图可以在端侧和中枢侧各加一个debug字段输出中间结果。6.2 智能体递归死循环有一次线上出现诡异现象一个查询类任务反复调用数据工具始终返回失败然后编排层触发重规划又去调用同一个工具形成死循环。问题原因出在重规划策略没有“失败记忆”。解决方法是给每个执行计划增加最大迭代次数一般设置3次并在计划节点上记录每次失败的原因和工具ID同一个工具连续失败两次后直接从候选列表剔除。6.3 安全过滤误伤严重安全策略上线初期误杀率超过15%很多正常客服对话被提醒音其中一个原因是“敏感词库”词太多把“发票”“金额”都当成了敏感信息。后来把策略调整为“分级处理”高危险词直接拦截中危险词先过分类模型判断上下文低危险词仅记录不阻断。调整后误杀率降到3%以下而真正的高危内容拦截率没有下降。6.4 混合模型集群资源利用率低模型多但流量不均导致GPU利用率经常只有20%。我们把所有在线模型做成共享池按任务优先级调度。低峰时把数据中心任务合并到一个实例高峰时自动扩容。另一个技巧是给冷门模型加“最小保留实例数”比如0.5B的端侧模型在CPU上跑不占GPU7B模型至少保留2个实例避免频繁冷启动。实测调整后整体GPU利用率从22%提升到58%成本账一下子就好看了。最后补一句维护心得AI体系不是上线就完事它是一个需要持续喂养的系统。模型要更新路由要调优安全策略要跟上新攻击手段。每次线上出问题第一件事不要急着调模型先把当天的完整链路日志拉出来看80%的问题其实出在路由、工具和策略配置上而不是模型本身。搞懂这个逻辑你搭的这套东西才能真正跑得稳、管得住、用得久。