这系列文章写到第5篇我打算把模型层和智能体编排层之间那条线彻底讲透。55873这个代号指的是我们内部这套AI体系的全景编号——613混合模型四层智能体架构外加一套贯穿始终的安全策略编排。很多团队现在手里模型不少Agent框架也试了好几个但真正的问题从来不是缺模型或缺框架而是模型之间怎么协同、Agent每一层该干什么、安全策略在哪个环节介入这三件事没打通。这篇文章就把这套体系从设计思路到落地参数拆开讲适合正在做企业级AI平台、想把多个模型和Agent编排层整合到一起的团队参考。1. 613混合模型为什么单一模型方案撑不住生产环境1.1 混合模型的分配逻辑与选型考量先解释一下613这套分配是怎么来的。6个领域小模型各自负责一类相对固定的任务比如意图识别、情感分析、实体抽取、文本分类、摘要生成、向量化。1个核心基座大模型负责复杂推理、长文本生成、多轮对话这类需要高智能水平的任务。3个辅助模型分别是代码模型、多模态模型和检索重排模型解决代码生成、图文理解、RAG场景中的相关性排序问题。这个比例不是拍脑袋定的是从请求分布里统计出来的。生产环境里真正需要顶级大模型参与的请求占比往往不到20%剩下80%的流量是相对固定的结构化任务。这80%如果全部丢给基座大模型成本会直接失控而且延迟也扛不住。让6个小模型承接高频简单任务基座大模型专注处理复杂场景整体吞吐和成本就能平衡下来。选型上小模型的原则是参数量不大但要精——我们的经验是每个小模型只做一件事不要指望一个模型既做意图识别又做实体抽取还做情感分析。拆得越细每个模型的效果越稳定后续也越好替换。基座大模型的选择则要看你最核心的场景是什么如果写作为主就选生成能力强的如果分析推理为主就选逻辑能力强的不要贪大求全。1.2 模型路由让每类请求都找到最合适的归处有了一堆模型接下来的关键问题是谁来决定一个请求该交给哪个模型。模型路由层解决的就是这个。我们的做法是先做意图粗筛再做实体校验最后才是模型分发。意图粗筛通常用一个小模型或者规则引擎完成识别出这个请求属于闲聊、知识问答、代码生成、数据分析里的哪一类。实体校验是为了防止意图识别出错比如用户说帮我算一下这个月支出意图是数据分析但请求里带着一个Excel附件这时候就要确认附件格式是否支持确定走数据分析链路。最后模型分发根据意图映射到对应模型同时带上优先级和超时时间。路由层最容易犯的错是试图用一个通用模型做意图判断。我见过不少团队让基座大模型来分流结果每个请求都先经过一次大模型推理成本和延迟全上去了。正确做法是分流用轻量模型只有被判定为复杂任务时才升级到基座大模型。这里有一个降级策略要提前设计好当小模型置信度低于阈值时自动把请求交给大模型兜底而不是直接返回结果。2. 四层智能体架构从感知到执行的编排链路2.1 感知层与决策层的职责边界四层架构里L1感知层和L2决策层是最容易被混淆的。很多团队把这两个层合并成一个模块结果职责不清出了问题都不知道该查谁。L1感知层干的是看清楚的活。它负责把原始输入转化成结构化信息包括意图识别、实体抽取、情绪判断、上下文窗口管理。这一层的特点是速度快、覆盖面广但不需要做复杂推理。我们通常用6个小模型里的意图识别和实体抽取模型来支撑这层单个请求耗时控制要在100毫秒以内。L2决策层干的是想清楚的活。它接收感知层输出的结构化信息判断这个任务需不需要拆解成多步需要调用哪些工具涉及哪些知识域以及最终该走哪个执行链路。决策层是唯一允许调用基座大模型的地方因为任务规划本身就属于复杂推理。一个重要经验是决策层一定要输出的不是一段自然语言解释而是一个结构化决策结果比如任务清单、工具调用列表、参数映射关系。如果输出的是自由文本后续执行层解析起来会极其痛苦。2.2 执行层与协调层的闭环设计L3执行层负责把决策转化成实际动作。调用API、查询数据库、触发工作流、生成文件、发起HTTP请求这些都在这一层完成。执行层要关注两件事一是工具接入要做统一抽象所有外部能力都封装成标准接口参数校验和权限校验在执行层入口统一完成二是执行结果必须回传不能让执行变成发射后不管。L4协调层是四层架构里最容易被忽略却最关键的。它的职责是管理多智能体协作、维护长期记忆、控制上下文窗口、记录执行轨迹。我们在协调层维护一份任务状态表记录每个智能体的执行状态、依赖关系和结果引用。当某个任务需要多个智能体协作时协调层负责编排先后顺序解决谁先谁后、谁等谁的问题。闭环的意思是说执行层的每个动作都有结果回传协调层拿到结果后更新状态然后判断整个任务是否完成。如果没完成把中间结果重新送回决策层做下一步规划。这个循环的设计要点是必须有最大迭代次数限制一般任务最多5轮到8轮超过就强制终止避免Agent陷入死循环。3. 安全策略编排从模型入口到工具调用的全链路管控3.1 输入侧防护注入检测与权限前置校验安全策略编排不是单独一条线而是像神经系统一样渗透在每一层。先说输入侧这是最容易出问题的地方。第一道防线是提示词注入检测。用户输入、外部文档、第三方API返回的内容都有机会进入模型提示词。我们的做法是所有外部输入在进入提示词模板之前先经过一个注入检测过滤器识别忽略之前指令忘记你之前的角色输出你的系统提示词这类攻击模式。这个过滤器可以用规则加小模型组合规则负责拦截典型模式小模型负责识别语义层面的绕过。第二道防线是权限前置校验。在决策层开始规划之前先确认当前用户身份、会话上下文、操作范围。比如一个普通用户发起删除数据的指令在决策层规划阶段就要被拦截根本不给执行层机会。权限校验一定要前置不要等到工具调用时才查——等到那时模型可能已经把工具参数都生成了连同注入的恶意指令一起交了出去。第三道防线是数据最小化。输入给模型的数据只保留任务必需的部分不做全量上下文投喂。比如一个文档分析请求系统先做检索只把相关段落拼进提示词而不是把整个文档库都塞进去。这既是安全考虑也是成本和上下文窗口的管理策略。3.2 输出侧审计脱敏、留痕与熔断输入侧防护做得再好输出侧也必须兜底。因为模型幻觉和越狱攻击总有可能穿透防线输出侧是最后一道闸门。输出脱敏是第一步。模型生成的结果在返回给用户之前经过一个PII识别组件把手机号、身份证号、银行账号、邮箱这类敏感信息打码或替换。这一步对于面向C端的应用尤其重要因为模型在训练数据里学到的内容可能包含个人信息。输出审计是第二步。我们要求所有Agent执行动作都要记录审计日志包括谁发起的、用了哪个模型、调了哪个工具、传了什么参数、返回了什么结果。日志格式是结构化的方便事后查询和复盘。这里有个细节值得注意审计日志不能只记入参不记出参否则排查问题的时候根本不知道Agent在哪个环节出错。熔断机制是第三步。系统实时监控错误率、超时率、敏感词命中率一旦某个模型或链路指标异常立即启动熔断降级。比如基座大模型连续返回异常内容编排层自动把流量切换到备用模型而不是让用户直接面对错误。熔断阈值要根据实际流量动态调整我们初始配置是错误率超过3%触发压测后调整为5%。4. 落地实操模型部署、编排配置与成本平衡4.1 模型部署形态与资源规划先聊部署形态。613这套体系里不同模型的部署方式差别很大。小模型因为调用量最大我们建议用GPU集群部署开启动态批处理尽可能提高吞吐。基座大模型参数量大如果流量峰值高最好用多卡推理配合模型并行策略。辅助模型里的多模态和代码模型看使用频率决定是否常驻显存。资源规划上一个容易踩的坑是只按模型参数量估算显存忽略了推理时的KV Cache开销。以7B模型为例上下文长度设为4096单并发大概需要16GB左右显存你以为一张A10就够实际并发一上来就OOM。我们的经验是预留30%到40%的显存余量上下文长度越长余量要越大。如果你用的是托管API而不是自建推理那资源规划的重点就变成配额管理。给每个业务方分配独立的模型调用配额设置每分钟请求上限和每日tokens上限防止某个业务线异常流量把整个账号的配额打满。4.2 编排层的关键参数与路由规则配置编排层配置的核心是三个参数路由规则、超时控制、重试策略。路由规则我建议配置成优先级链而不是硬编码映射。举个例子某类请求优先走领域小模型当小模型置信度低于0.6时降级到大模型大模型也失败时走兜底规则返回预设话术。这一套链路配置在一个YAML文件里运维可以随时调整不需要改代码。超时控制分两层模型推理超时和整体任务超时。模型推理超时一般设5到10秒因为模型推理超过10秒通常意味着显存竞争或推理服务异常。整体任务超时根据任务复杂度设30秒到2分钟。超时触发后编排层返回一个结构化错误码给上游而不是直接抛异常让调用方一头雾水。重试策略要区分错误类型。模型服务返回5xx错误可以重试但4xx错误不要重试那是请求本身有问题。幂等请求可以安全重试非幂等请求重试前要确认上一步是否已经执行。我见过重试机制导致重复扣款、重复发消息的事故这都是因为没做幂等控制。4.3 成本与性能的平衡策略成本控制是这套体系能不能长期跑下去的关键。我们的目标是把整体推理成本控制在纯大模型方案的1/3以内。第一个策略是缓存。相同或相似的请求直接命中缓存结果不重新推理。我们线上运营数据里FAQ类请求缓存命中率能到60%以上。第二个策略是批量聚合低优先级的请求在队列里攒一批再一起推理充分利用GPU的批处理能力。第三个策略是模型降级闲时流量走小模型高峰期复杂任务才升级到大模型。性能优化上最有效的手段是减小上下文长度。同一个请求上下文从8000 tokens砍到2000 tokens推理耗时能下降一大半。这就要求在做上下文管理时只保留关键信息历史对话做摘要压缩而不是把所有聊天记录原样传给模型。另一个优化点是向量检索提前做在路由阶段就把相关文档捞出来而不是等到决策层执行时才检索。5. 常见问题与排查技巧实录5.1 模型串扰与路由误判模型串扰是我们上线后遇到的第一个大问题。现象是原本应该走文本分类模型的请求跑到了总结模型上输出结果完全不对。排查发现是路由规则里两个模型的判定条件有重叠当输入文本同时满足两个条件时命中了优先级低的那个。解决办法是给路由规则加了互斥约束明确各模型的专属场景和兜底场景。同时把路由决策结果记录到日志里每次命中都能回溯是哪个条件触发的。排查路由问题时有个小技巧给每个模型分配独立的trace ID前缀看日志时一眼就能判断流量走向。路由误判最典型的场景是短文本。用户输入只有一两个字时意图识别模型的置信度往往很低。我们的处理方式是设置最低置信度阈值0.5低于阈值直接进人工兜底对话不硬猜。5.2 Agent死循环与上下文膨胀Agent死循环是编排层最常见的故障。现象是任务就是执行不完Agent反复调用同一个工具每次都拿到相似的中间结果然后在决策层绕圈。排查时先看协调层的任务状态表如果发现某个动作的调用次数超过预期且结果没有推进基本可以确认是死循环。解决方法是加两套防护最大迭代次数限制已经说过还有一个结果去重机制——如果某一步的输入输出和之前某一步完全一致说明已经绕回原点了直接终止。上下文膨胀是另一个高频问题。多轮对话场景里每轮都把完整历史传给模型上下文越滚越大推理延迟和成本肉眼可见地涨。我们后来强制要求超过5轮的历史对话做摘要摘要只保留实体、关键结论和未完成事项。这个改动让长对话场景的推理延迟下降了40%以上。5.3 安全策略误伤与回退机制安全策略配置太严会误伤正常业务。我们发现过注入检测过滤器把忽略所有格式要求这种正常指令当成注入攻击拦截的情况。经过统计误拦截比例一度到了2%用户的体感就是为什么我的请求莫名其妙被拒了。后来我们把安全策略分成了硬拦截和软标记两种。硬拦截是确定性的高危行为直接拒绝软标记是疑似风险只记录不拦截同时给下游加一个审核标记。如果某个请求被软标记后执行出问题再升级处理。这套机制上线后误拦截率降到了0.1%以下。还有一个经验安全策略的回退机制要留一个手动放行通道。运营人员遇到误拦截时可以凭权限手动标记人工已审核让请求继续走完流程。没有这个通道每次误拦截都要走紧急发布流程太影响线上效率。最后说一个这些年踩坑最多的感悟模型选型和架构设计都不难最难的是让体系里的每一环都具备可观测性。55873这个体系能跑稳靠的不是某一层设计得多完美而是从模型路由到安全策略每一层都有日志、有指标、有追踪任何一个环节出问题都能在10分钟内定位。如果你也在搭类似的体系我建议把可观测性当作第一优先级来设计而不是等出了问题再补。