做 AI 应用落地这几年我一直有个执念别把鸡蛋放在同一个大模型里。单一模型再强也扛不住所有场景成本、延迟、效果、稳定性根本没法同时兼顾。所以就攒了这么一套东西代号55873 生态核心是613 混合模型四层智能体架构安全策略编排。这套体系不是纸面上的架构图而是我实际跑了大半年的生产环境踩过无数坑之后沉淀下来的一个完整打法。今天这篇技术第5篇就把这套体系的拆解思路、核心细节、落地过程和避坑经验全部摊开来讲希望能给正在做 AI 应用架构选型的朋友一些真实参考。先说清楚这套体系解决什么问题。如果你只是调 API 做个 demo那确实不需要看这篇文章。但如果你要做的是一个要接多个场景、多类模型、多套智能体的正式系统——比如既有对话问答又有代码辅助还要处理文档分析、数据抽取甚至要应对不同用户的差异化需求——那你就一定会遇到几个绕不开的问题模型怎么选、任务怎么路由、智能体怎么协作、怎么保证输出安全合规。55873 这套东西就是冲着这四个问题去的。适合谁看两种人一种是刚准备搞 AI 应用架构、想少走弯路的开发者另一种是已经在跑多模型服务、被调度混乱和成本失控折磨过的技术负责人。我尽量少讲虚的架构理念多讲具体的配置、参数、策略和真实场景哪怕你现在团队只有三五个人这套思路也能落地。1. 模型体系设计613 混合模型到底怎么拆先说这个“613”。很多人一听混合模型第一反应是“不就是多个模型轮着用嘛”。真这么简单就好了。实际工程里模型一多问题反而更多谁来选模型选了怎么切切了怎么保证效果一致每个模型擅长的东西不一样怎么让它们各司其职又不打架这套 55873 的模型体系就是为了解决这些问题才设计的。1.1 六个基础模型按能力特长分工而不是按参数规模堆6 个基础模型我称为“底座模型群”覆盖了日常最常见的六类任务承载通用对话模型负责任务理解、闲聊、语义分析这类高频基础交互要求响应快、知识面广。长文本处理模型专门处理超长上下文比如数万字文档的摘要抽取、要点归纳。轻量端侧模型部署成本低、推理延迟小负责简单分类、意图识别、关键词抽取等不需要大模型深思考的任务。代码生成模型针对代码补全、注释生成、重构建议等场景做了专项优化。多模态理解模型负责图文结合的输入解析例如从截图里提取信息、识别流程图和表格结构。结构化输出模型重点保证 JSON、SQL、正则等格式内容的稳定输出用在数据抽取和接口对接场景。这 6 个模型怎么分组不是拍脑袋定的是我根据实际业务数据统计出来的。早期我试过只用一个通用大模型结果代码任务和文档抽取效果还行但每次调用成本都高得离谱而且长文本场景经常超时。后来我加了一个轻量模型去做意图识别把大部分简单请求过滤掉成本直接降了六成。这个教训很直接模型分工本质上是对成本和效果的权衡不是为了分而分。1.2 一个统一决策模型模型路由的“大脑”那 6 个模型谁来调度这就要说到那个“1”——统一决策模型。它不是用来直接回答用户问题的而是用来回答另一个问题当前这个请求应该交给哪个模型处理。我把它放在模型网关的位置所有请求先经过它它结合任务类型、上下文长度、业务场景、成本预算等多个维度输出一个路由决策。做过推荐系统的人会觉得很像“粗排精排”的思路。这个设计我觉得是整套体系里最关键的一点。没有它你就是把 6 个模型摆在那但不知道该用哪个。很多人做多模型应用翻了车不是模型不好是缺了这层调度脑子。所以这个“1”我坚持要用一个理解能力强、指令遵循性好、输出稳定的模型来当它决定不了业务的上限但决定了整个体系的利用率下限。1.3 三个垂直模型把专业场景做深3 个垂直增强模型是面向特定领域专门做的微调模型解决的是“通用模型在专业场景下表现不够深”的问题。我这边目前跑了三个方向你可以参考代码补全与重构模型是在代码模型底座上用项目的真实提交记录和 Issue 数据做了微调补全建议的准确率明显比通用模型高尤其是对特定框架的风格掌握得更准。知识问答模型针对企业内部文档、产品手册这些语料做了领域适配回答起来更像“自己人”而不是百度百科式的一本正经。数据抽取与结构化模型专门吃纯文本输入输出标准 JSON 字段跑业务数据清洗时稳定得很。这三个垂直模型是我认为“混合模型”里最体现功夫的地方。通用模型能做到 80 分垂直模型就是把那 80 分推到 95 分。但要注意垂直模型不是越多越好每个模型都意味着训练成本、维护成本和部署成本。我见过有人一口气微调了十几个模型最后大量模型处于低利用率状态纯粹是给自己找运维麻烦。1.4 混合调度的核心逻辑按请求分层做路由613 这 10 个模型组合起来调度策略大概是这样的第一层简单请求直接由轻量端侧模型消化掉比如“这句评论是正向还是负面”“这个工单属于哪个分类”这种任务不需要大模型用轻量模型又快又省。第二层中等复杂度任务走通用对话模型或代码生成模型覆盖日常大多数请求。第三层复杂专业任务才轮到垂直模型比如长文档结构化抽取、领域问答、专业代码重构。这三层之间由统一决策模型来判定而且我还加了两个回退规则一是垂直模型结果置信度过低时回退到通用模型重新生成二是长文本模型处理超时或失败时自动将请求重试到通用模型。这种分层路由 回退机制是整套模型体系稳定性的核心。你单看任何一个模型都会有短板但把它们组合起来短板彼此补位整体稳定性远比单个最强模型扛全年要靠谱。2. 四层智能体架构从接收到交付的完整闭环模型体系解决“谁来做”的问题但实际干活的是智能体。四层智能体架构是我在这套体系里用来组织所有 AI 能力和业务流程的骨架。别被“智能体”三个字唬住说白了就是把模型、工具、记忆、编排逻辑拆成四层各管一摊。2.1 四层分别是哪四层每层干什么L1 感知接入层负责接收和多源输入解析。不管是用户聊天、上传文档、接口请求还是内部任务消息全部在这一层统一成标准输入格式并做初步的意图识别、主体识别和敏感信息标记。这一层解决的是“AI 怎么理解进来的东西”。L2 决策规划层负责任务拆解、工具选择和模型路由。感知层告诉你“用户想干嘛”这一层就要想清楚“先干嘛再干嘛每一步找谁干”。比如用户说“分析这份合同的风险点”决策规划层要把任务拆成文档解析、条款提取、风险判断、报告生成四个子任务并指定每个子任务用哪个模型和哪个工具。L3 执行工具层负责真正干活。调用模型、执行代码、跑 SQL、请求 RAG 检索、拉外部 API全部在这一层。我特意把工具层和决策层解耦这样新增工具不影响上层逻辑。L4 协同记忆层负责跨会话记忆、跨智能体协作、结果校验与状态同步。比如一个用户连续对话过程中前面提到的信息在这一层被保留和引用多个智能体协作时中间结果也在这里汇总。这套分层我迭代过三次最初的版本只有两层一个输入一个输出结果所有逻辑全堆在一起改造一次胆战心惊。后来拆成三层再后来发现记忆和协作无处安放才最终定了四层。每一层都有一个明确的职责边界这是我能在这套体系上持续加功能而不崩的根本原因。2.2 一次完整请求是怎么穿过四层的拿“分析这份合同的风险点并生成报告”这个真实场景来说第一步L1 感知接入层收到文档和指令做格式转换和分段同时标记出文档里可能涉及敏感信息的段落。第二步L2 决策规划层识别这是“文档分析类任务”把任务拆成文档内容抽取、风险条款定位、风险等级评估、报告生成四个步骤每个步骤分别绑定到结构化输出模型、长文本模型、知识问答模型和通用对话模型。第三步L3 执行工具层依次执行这四步期间长文本模型负责读全文结构化输出模型负责输出风险点清单知识问答模型负责结合历史案例做风险判断。第四步L4 协同记忆层把中间结果汇总生成最终报告并写入会话记忆下次用户追问“之前说的第三条风险怎么处理”时能直接呼应。这四层跑完一个请求的完整链路也就闭环了。每一层的输出都是下一层的输入而且所有层都受到安全策略编排的约束这刚好衔接到下一部分。2.3 四层边界为什么这么切多一层少一层行不行有人可能会问为什么要四层而不是三层或者五层。我的判断依据是“变更频率”和“复用性”。感知层变的是接口和输入格式决策层变的是业务逻辑执行层变的是工具能力记忆层变的是状态和存储。这四样的变化节奏完全不同。比如我接了一个新的数据源只动感知层就够了换了一个更聪明的模型也只动执行层里的模型调用不需要碰决策层。这正是分层架构的价值每一层的变更都能被控制在最小范围降低回归和故障风险。三层会出问题——记忆和协作如果塞进决策层决策逻辑很快就会和状态管理纠缠在一起变得又厚又难维护。五层又显得冗余——比如把鉴权单独拆一层我觉得太重了放在安全策略编排里横切更好。四层是我在十几套真实业务场景里试出来的平衡点既不薄也不臃肿。3. 安全策略编排为什么安全不能靠“事后审核”标题里特意加了这个词因为我确实在这上面吃过亏。早期的做法是模型输出之后做个敏感词过滤有问题就拦截。结果你猜怎么着过了一个月发现很多被拦截掉的输出其实品质很高只是用词不够“模板”而某些真正有风险的输出反而绕过了关键词顺利发出去。后来我才反应过来安全必须前置到每个落地环节而且必须是一套可编排的组合策略不是一条过滤规则。3.1 安全策略编排的四个入口我在 55873 里把安全策略拆成四个入口每个入口对应不同的防护目标入口一请求准入。所有进入系统的内容先过一次校验识别提示注入、越权指令、非法敏感数据等命中直接拦截或降级处理。入口二模型路由安全。决策模型在选型时会根据内容的敏感程度和业务场景动态决定走哪个模型。例如敏感业务优先切换到数据不外传的本地部署模型而不是云端通用模型。入口三输出合规。模型返回内容在递交给用户之前做一次语义级审查重点检测幻觉风险、不当建议、敏感信息泄露而不是单纯做关键词匹配。入口四审计追踪。每一次路由决策、模型调用、工具执行、输出结果都留痕保证事后能追溯全链路。这四个入口不是串联的而是横切在四层智能体架构之上的每层执行前都会校验当前策略状态。我把它们统一交给策略中心管理运营人员可以在控制台调整策略优先级而不用改代码。3.2 一个具体的安全策略配置案例举个实际用过的配置例子。假设业务里有一个“合同分析助手”安全策略大概长这样策略项配置值说明输入敏感信息识别开启命中“身份证/银行卡/手机号”掩码后进入脱敏流程防止个人隐私数据进入模型上下文提示注入检测开启检测到“忽略以上指令”“重新设定角色”等模式直接拦截并上报防提示攻击是智能体安全第一大关高敏感任务模型约束合同内容抽取出条款时强制走本地部署模型不允许云端通用模型参与数据不出内网这是合规刚需输出幻觉校验开启模型生成的条款编号与原文不一致时自动标记并要求重生成这种“看起来对但其实错”的幻觉最致命审计日志全量开启保存路由决策、模型版本、耗时、token 消耗后期复盘和成本核算都靠它这个配置跑了一段时间体感很稳。你可能会问策略这么多会不会影响性能确实会有一点但安全和性能的权衡我认为在 AI 场景里安全优先级更高因为一旦出了事故你后面补的每一个规则都是在为过去的失误填坑。3.3 策略的“编排”体现在哪如果只是写死几条规则那不叫编排叫配置。我理解“编排”的核心是规则之间可以组合、可以条件触发、可以动态调整顺序。例如同一份文档对内部分析场景走“宽松策略本地模型”对外展示场景走“严格策略输出审核”。策略不是静态的而是跟着业务上下文走的。再比如降级策略。某个模型连续三次响应异常策略中心会自动把它标记为“不健康”后续请求自动切换备用模型同时发出告警通知。这种动态健康检查、容量保护、降级熔断的逻辑放在策略中心里统一管理比写死在模型网关代码里灵活得多。后面业务加新模型上线的同时把策略配上就行不用动任何主链路代码。4. 实操落地模型网关、上下文管理与数据闭环讲完架构说点能直接上手的东西。这套体系落地第一步是先搭一个统一的模型网关把 10 个模型全部收敛到一个出入口第二步是把上下文、记忆和反馈数据的处理做成标准化模块。这两个环节做扎实了后续加模型、加智能体基本就是填配置的事。4.1 模型网关怎么搭关键配置项有哪些模型网关我用 Go 写了一层代理服务把所有上游模型 API 统一封装成一套接口协议。这样做的好处是上层智能体根本不用关心底层是本地模型还是云端模型只需要按统一格式发起请求剩下的路由、鉴权、限流、重试、熔断全都由网关完成。网关里比较关键的一个配置是模型超时和重试策略。我的配置大概是轻量模型超时 10 秒普通模型 30 秒长文本任务 120 秒失败重试一次重试间隔 2 秒互不重试同模型。这些数字看着琐碎但生产环境和 demo 的差别就在这。另外还要在网关层做token 级别的用量统计和成本预估。我按模型维度记录每天的 token 消耗、响应时长、成功率和成本按月出报表。有了这些数据你才知道哪些模型真的在干活哪些模型天天闲着烧钱。4.2 上下文管理从无状态调用到有状态智能体纯调模型是无状态的但智能体必须记住上下文否则一问三不知。我在四层架构里把上下文管理放在了 L4 协同记忆层具体做了三件事第一短期会话记忆。每次对话的关键信息抽象成结构化条目存到会话级的临时存储里保证同一会话内多轮追问的连贯。第二长期知识沉淀。把用户的历史偏好、业务规则、常见问题解答方案同步到长期存储跨会话也能复用。第三上下文压缩。当一轮对话太长导致 token 超限时触发压缩机制把早期对话摘要化释放上下文空间给当前最有价值的部分。这个压缩策略非常有用不然一个长会话跑到一半就撞上模型上下文上限直接没办法继续。4.3 数据闭环把每次调用变成训练素材最后这一点可能是很多人容易忽略的。我始终觉得混合模型体系跑得再好如果不做数据回流那它的价值就只发挥了一半。每次模型调用、每个智能体执行过程、每次人工纠错都是宝贵的训练和评估素材。我在执行层加了一个反馈采集逻辑用户对回答点了“有帮助/没帮助”工具调用成功与否路由决策对不对全部打标入库。积累到一定量之后定期挑选高质量数据用来做垂直模型的增量微调。这个数据闭环跑起来之后我的经验是垂直模型的效果会越用越好而且能逐渐暴露路由规则的盲区反哺统一决策模型。AI 应用不是部署完就结束了它是个持续生长的系统数据闭环就是它的养料。5. 常见问题与排查技巧实录跑这套体系期间我踩过的坑、查过的问题能列一大串。挑几个最有代表性的写出来很多细节常规文档里根本不会提。5.1 模型路由误判轻量模型把复杂任务接走了这是我最开始遇到的高频问题。轻量模型负责简单请求但偶尔遇到一个明明很复杂的问题它却给了很高的置信度然后复杂任务就被它干砸了。排查下来发现轻量模型对“复杂度”的判断并不准它觉得能答就等于简单。解决思路给统一决策模型增加一个“复杂度置信度”维度当判定结果模棱两可时宁可交给更强的模型也不要省钱交给轻量模型。多花一点点成本换来的稳定性远大于节省的那点钱。5.2 输出幻觉导致业务事故风险有个场景是生成合同风险报告模型把原文里根本没有的条款给“脑补”出来了。这种幻觉其实比答错更危险因为看着特别可信。我后来在输出合规校验里加了一层“事实性抽检”模型生成的关键实体条款编号、金额、日期必须能从原文片段里找到对应依据找不到就自动重生成。这个抽检逻辑跑下来幻觉问题明显减少。这一条我觉得是 AI 应用落地最重要的经验之一不要相信模型输出的事实性要让输出可溯源。5.3 上下文超限长对话跑到一半就断了长文本任务和长会话场景都容易触发上下文超限。最早我是粗暴地清空历史结果用户一问之前聊过的内容就傻眼。后来才做了上下文压缩机制把早期对话转成结构化摘要既保留关键信息又不挤压当前上下文空间。另外还有一个细节不同模型的上下文窗口差别很大网关层要做统一适配超长请求自动切到长文本模型短对话留在普通模型避免资源浪费。5.4 工具调用失败智能体“想得到”但“做不了”智能体规划得很好但实际执行工具时失败了这种情况在接入外部 API 时非常高发。常见原因有三个参数格式不对、目标服务响应超时、权限不足。我的排查思路是先在执行层加详细的工具调用日志把入参、出参、异常原因全记录下来然后针对高频失败原因做自动修正。比如参数格式错误就在调用前加一层 schema 校验响应超时就加本地重试和降级逻辑。5.5 安全策略误杀该拦的没拦住不该拦的拦了一堆最后说一个安全策略编排最容易踩的坑——误杀。规则定得太死正常的业务内容也被拦截用户体感特别差规则定松了又真会漏风险。我的做法是给每条策略配置“动作等级”高危策略直接拦截中危策略走人审复核低危策略仅打标提醒。通过等级化配置把误杀率降下来同时高危场景一点不放。安全策略是持续迭代的过程不能一次配完就不管要经常根据拦截日志和用户反馈调参。收尾想说的话55873 这套体系从设计到落地我最深的体会是AI 应用架构到最后拼的不是单个模型有多强而是组合、编排和取舍的能力。613 混合模型解决成本与效果的平衡四层智能体架构解决复杂任务的协作安全策略编排解决系统在真实业务里的生存底线。在实际使用中如果你一开始觉得这套复杂度太高完全可以从最小版本起步——先把一个模型网关搭起来接两三个模型配一层简单路由后面再逐步往里面加智能体和安全策略。我自己就是这样做的先跑通主链路再持续迭代不到半年就长成了现在这个规模。最后再分享一个小技巧给每一层、每一个模型、每一条策略都加上独立可观测的日志和指标。这套体系不怕逻辑复杂就怕出问题时你没有数据可以追溯。你的一半运维压力会因为这个习惯直接消失。 55873生态：6+1+3混合模型 + 四层智能体架构 + 安全策略编排实战
做 AI 应用落地这几年我一直有个执念别把鸡蛋放在同一个大模型里。单一模型再强也扛不住所有场景成本、延迟、效果、稳定性根本没法同时兼顾。所以就攒了这么一套东西代号55873 生态核心是613 混合模型四层智能体架构安全策略编排。这套体系不是纸面上的架构图而是我实际跑了大半年的生产环境踩过无数坑之后沉淀下来的一个完整打法。今天这篇技术第5篇就把这套体系的拆解思路、核心细节、落地过程和避坑经验全部摊开来讲希望能给正在做 AI 应用架构选型的朋友一些真实参考。先说清楚这套体系解决什么问题。如果你只是调 API 做个 demo那确实不需要看这篇文章。但如果你要做的是一个要接多个场景、多类模型、多套智能体的正式系统——比如既有对话问答又有代码辅助还要处理文档分析、数据抽取甚至要应对不同用户的差异化需求——那你就一定会遇到几个绕不开的问题模型怎么选、任务怎么路由、智能体怎么协作、怎么保证输出安全合规。55873 这套东西就是冲着这四个问题去的。适合谁看两种人一种是刚准备搞 AI 应用架构、想少走弯路的开发者另一种是已经在跑多模型服务、被调度混乱和成本失控折磨过的技术负责人。我尽量少讲虚的架构理念多讲具体的配置、参数、策略和真实场景哪怕你现在团队只有三五个人这套思路也能落地。1. 模型体系设计613 混合模型到底怎么拆先说这个“613”。很多人一听混合模型第一反应是“不就是多个模型轮着用嘛”。真这么简单就好了。实际工程里模型一多问题反而更多谁来选模型选了怎么切切了怎么保证效果一致每个模型擅长的东西不一样怎么让它们各司其职又不打架这套 55873 的模型体系就是为了解决这些问题才设计的。1.1 六个基础模型按能力特长分工而不是按参数规模堆6 个基础模型我称为“底座模型群”覆盖了日常最常见的六类任务承载通用对话模型负责任务理解、闲聊、语义分析这类高频基础交互要求响应快、知识面广。长文本处理模型专门处理超长上下文比如数万字文档的摘要抽取、要点归纳。轻量端侧模型部署成本低、推理延迟小负责简单分类、意图识别、关键词抽取等不需要大模型深思考的任务。代码生成模型针对代码补全、注释生成、重构建议等场景做了专项优化。多模态理解模型负责图文结合的输入解析例如从截图里提取信息、识别流程图和表格结构。结构化输出模型重点保证 JSON、SQL、正则等格式内容的稳定输出用在数据抽取和接口对接场景。这 6 个模型怎么分组不是拍脑袋定的是我根据实际业务数据统计出来的。早期我试过只用一个通用大模型结果代码任务和文档抽取效果还行但每次调用成本都高得离谱而且长文本场景经常超时。后来我加了一个轻量模型去做意图识别把大部分简单请求过滤掉成本直接降了六成。这个教训很直接模型分工本质上是对成本和效果的权衡不是为了分而分。1.2 一个统一决策模型模型路由的“大脑”那 6 个模型谁来调度这就要说到那个“1”——统一决策模型。它不是用来直接回答用户问题的而是用来回答另一个问题当前这个请求应该交给哪个模型处理。我把它放在模型网关的位置所有请求先经过它它结合任务类型、上下文长度、业务场景、成本预算等多个维度输出一个路由决策。做过推荐系统的人会觉得很像“粗排精排”的思路。这个设计我觉得是整套体系里最关键的一点。没有它你就是把 6 个模型摆在那但不知道该用哪个。很多人做多模型应用翻了车不是模型不好是缺了这层调度脑子。所以这个“1”我坚持要用一个理解能力强、指令遵循性好、输出稳定的模型来当它决定不了业务的上限但决定了整个体系的利用率下限。1.3 三个垂直模型把专业场景做深3 个垂直增强模型是面向特定领域专门做的微调模型解决的是“通用模型在专业场景下表现不够深”的问题。我这边目前跑了三个方向你可以参考代码补全与重构模型是在代码模型底座上用项目的真实提交记录和 Issue 数据做了微调补全建议的准确率明显比通用模型高尤其是对特定框架的风格掌握得更准。知识问答模型针对企业内部文档、产品手册这些语料做了领域适配回答起来更像“自己人”而不是百度百科式的一本正经。数据抽取与结构化模型专门吃纯文本输入输出标准 JSON 字段跑业务数据清洗时稳定得很。这三个垂直模型是我认为“混合模型”里最体现功夫的地方。通用模型能做到 80 分垂直模型就是把那 80 分推到 95 分。但要注意垂直模型不是越多越好每个模型都意味着训练成本、维护成本和部署成本。我见过有人一口气微调了十几个模型最后大量模型处于低利用率状态纯粹是给自己找运维麻烦。1.4 混合调度的核心逻辑按请求分层做路由613 这 10 个模型组合起来调度策略大概是这样的第一层简单请求直接由轻量端侧模型消化掉比如“这句评论是正向还是负面”“这个工单属于哪个分类”这种任务不需要大模型用轻量模型又快又省。第二层中等复杂度任务走通用对话模型或代码生成模型覆盖日常大多数请求。第三层复杂专业任务才轮到垂直模型比如长文档结构化抽取、领域问答、专业代码重构。这三层之间由统一决策模型来判定而且我还加了两个回退规则一是垂直模型结果置信度过低时回退到通用模型重新生成二是长文本模型处理超时或失败时自动将请求重试到通用模型。这种分层路由 回退机制是整套模型体系稳定性的核心。你单看任何一个模型都会有短板但把它们组合起来短板彼此补位整体稳定性远比单个最强模型扛全年要靠谱。2. 四层智能体架构从接收到交付的完整闭环模型体系解决“谁来做”的问题但实际干活的是智能体。四层智能体架构是我在这套体系里用来组织所有 AI 能力和业务流程的骨架。别被“智能体”三个字唬住说白了就是把模型、工具、记忆、编排逻辑拆成四层各管一摊。2.1 四层分别是哪四层每层干什么L1 感知接入层负责接收和多源输入解析。不管是用户聊天、上传文档、接口请求还是内部任务消息全部在这一层统一成标准输入格式并做初步的意图识别、主体识别和敏感信息标记。这一层解决的是“AI 怎么理解进来的东西”。L2 决策规划层负责任务拆解、工具选择和模型路由。感知层告诉你“用户想干嘛”这一层就要想清楚“先干嘛再干嘛每一步找谁干”。比如用户说“分析这份合同的风险点”决策规划层要把任务拆成文档解析、条款提取、风险判断、报告生成四个子任务并指定每个子任务用哪个模型和哪个工具。L3 执行工具层负责真正干活。调用模型、执行代码、跑 SQL、请求 RAG 检索、拉外部 API全部在这一层。我特意把工具层和决策层解耦这样新增工具不影响上层逻辑。L4 协同记忆层负责跨会话记忆、跨智能体协作、结果校验与状态同步。比如一个用户连续对话过程中前面提到的信息在这一层被保留和引用多个智能体协作时中间结果也在这里汇总。这套分层我迭代过三次最初的版本只有两层一个输入一个输出结果所有逻辑全堆在一起改造一次胆战心惊。后来拆成三层再后来发现记忆和协作无处安放才最终定了四层。每一层都有一个明确的职责边界这是我能在这套体系上持续加功能而不崩的根本原因。2.2 一次完整请求是怎么穿过四层的拿“分析这份合同的风险点并生成报告”这个真实场景来说第一步L1 感知接入层收到文档和指令做格式转换和分段同时标记出文档里可能涉及敏感信息的段落。第二步L2 决策规划层识别这是“文档分析类任务”把任务拆成文档内容抽取、风险条款定位、风险等级评估、报告生成四个步骤每个步骤分别绑定到结构化输出模型、长文本模型、知识问答模型和通用对话模型。第三步L3 执行工具层依次执行这四步期间长文本模型负责读全文结构化输出模型负责输出风险点清单知识问答模型负责结合历史案例做风险判断。第四步L4 协同记忆层把中间结果汇总生成最终报告并写入会话记忆下次用户追问“之前说的第三条风险怎么处理”时能直接呼应。这四层跑完一个请求的完整链路也就闭环了。每一层的输出都是下一层的输入而且所有层都受到安全策略编排的约束这刚好衔接到下一部分。2.3 四层边界为什么这么切多一层少一层行不行有人可能会问为什么要四层而不是三层或者五层。我的判断依据是“变更频率”和“复用性”。感知层变的是接口和输入格式决策层变的是业务逻辑执行层变的是工具能力记忆层变的是状态和存储。这四样的变化节奏完全不同。比如我接了一个新的数据源只动感知层就够了换了一个更聪明的模型也只动执行层里的模型调用不需要碰决策层。这正是分层架构的价值每一层的变更都能被控制在最小范围降低回归和故障风险。三层会出问题——记忆和协作如果塞进决策层决策逻辑很快就会和状态管理纠缠在一起变得又厚又难维护。五层又显得冗余——比如把鉴权单独拆一层我觉得太重了放在安全策略编排里横切更好。四层是我在十几套真实业务场景里试出来的平衡点既不薄也不臃肿。3. 安全策略编排为什么安全不能靠“事后审核”标题里特意加了这个词因为我确实在这上面吃过亏。早期的做法是模型输出之后做个敏感词过滤有问题就拦截。结果你猜怎么着过了一个月发现很多被拦截掉的输出其实品质很高只是用词不够“模板”而某些真正有风险的输出反而绕过了关键词顺利发出去。后来我才反应过来安全必须前置到每个落地环节而且必须是一套可编排的组合策略不是一条过滤规则。3.1 安全策略编排的四个入口我在 55873 里把安全策略拆成四个入口每个入口对应不同的防护目标入口一请求准入。所有进入系统的内容先过一次校验识别提示注入、越权指令、非法敏感数据等命中直接拦截或降级处理。入口二模型路由安全。决策模型在选型时会根据内容的敏感程度和业务场景动态决定走哪个模型。例如敏感业务优先切换到数据不外传的本地部署模型而不是云端通用模型。入口三输出合规。模型返回内容在递交给用户之前做一次语义级审查重点检测幻觉风险、不当建议、敏感信息泄露而不是单纯做关键词匹配。入口四审计追踪。每一次路由决策、模型调用、工具执行、输出结果都留痕保证事后能追溯全链路。这四个入口不是串联的而是横切在四层智能体架构之上的每层执行前都会校验当前策略状态。我把它们统一交给策略中心管理运营人员可以在控制台调整策略优先级而不用改代码。3.2 一个具体的安全策略配置案例举个实际用过的配置例子。假设业务里有一个“合同分析助手”安全策略大概长这样策略项配置值说明输入敏感信息识别开启命中“身份证/银行卡/手机号”掩码后进入脱敏流程防止个人隐私数据进入模型上下文提示注入检测开启检测到“忽略以上指令”“重新设定角色”等模式直接拦截并上报防提示攻击是智能体安全第一大关高敏感任务模型约束合同内容抽取出条款时强制走本地部署模型不允许云端通用模型参与数据不出内网这是合规刚需输出幻觉校验开启模型生成的条款编号与原文不一致时自动标记并要求重生成这种“看起来对但其实错”的幻觉最致命审计日志全量开启保存路由决策、模型版本、耗时、token 消耗后期复盘和成本核算都靠它这个配置跑了一段时间体感很稳。你可能会问策略这么多会不会影响性能确实会有一点但安全和性能的权衡我认为在 AI 场景里安全优先级更高因为一旦出了事故你后面补的每一个规则都是在为过去的失误填坑。3.3 策略的“编排”体现在哪如果只是写死几条规则那不叫编排叫配置。我理解“编排”的核心是规则之间可以组合、可以条件触发、可以动态调整顺序。例如同一份文档对内部分析场景走“宽松策略本地模型”对外展示场景走“严格策略输出审核”。策略不是静态的而是跟着业务上下文走的。再比如降级策略。某个模型连续三次响应异常策略中心会自动把它标记为“不健康”后续请求自动切换备用模型同时发出告警通知。这种动态健康检查、容量保护、降级熔断的逻辑放在策略中心里统一管理比写死在模型网关代码里灵活得多。后面业务加新模型上线的同时把策略配上就行不用动任何主链路代码。4. 实操落地模型网关、上下文管理与数据闭环讲完架构说点能直接上手的东西。这套体系落地第一步是先搭一个统一的模型网关把 10 个模型全部收敛到一个出入口第二步是把上下文、记忆和反馈数据的处理做成标准化模块。这两个环节做扎实了后续加模型、加智能体基本就是填配置的事。4.1 模型网关怎么搭关键配置项有哪些模型网关我用 Go 写了一层代理服务把所有上游模型 API 统一封装成一套接口协议。这样做的好处是上层智能体根本不用关心底层是本地模型还是云端模型只需要按统一格式发起请求剩下的路由、鉴权、限流、重试、熔断全都由网关完成。网关里比较关键的一个配置是模型超时和重试策略。我的配置大概是轻量模型超时 10 秒普通模型 30 秒长文本任务 120 秒失败重试一次重试间隔 2 秒互不重试同模型。这些数字看着琐碎但生产环境和 demo 的差别就在这。另外还要在网关层做token 级别的用量统计和成本预估。我按模型维度记录每天的 token 消耗、响应时长、成功率和成本按月出报表。有了这些数据你才知道哪些模型真的在干活哪些模型天天闲着烧钱。4.2 上下文管理从无状态调用到有状态智能体纯调模型是无状态的但智能体必须记住上下文否则一问三不知。我在四层架构里把上下文管理放在了 L4 协同记忆层具体做了三件事第一短期会话记忆。每次对话的关键信息抽象成结构化条目存到会话级的临时存储里保证同一会话内多轮追问的连贯。第二长期知识沉淀。把用户的历史偏好、业务规则、常见问题解答方案同步到长期存储跨会话也能复用。第三上下文压缩。当一轮对话太长导致 token 超限时触发压缩机制把早期对话摘要化释放上下文空间给当前最有价值的部分。这个压缩策略非常有用不然一个长会话跑到一半就撞上模型上下文上限直接没办法继续。4.3 数据闭环把每次调用变成训练素材最后这一点可能是很多人容易忽略的。我始终觉得混合模型体系跑得再好如果不做数据回流那它的价值就只发挥了一半。每次模型调用、每个智能体执行过程、每次人工纠错都是宝贵的训练和评估素材。我在执行层加了一个反馈采集逻辑用户对回答点了“有帮助/没帮助”工具调用成功与否路由决策对不对全部打标入库。积累到一定量之后定期挑选高质量数据用来做垂直模型的增量微调。这个数据闭环跑起来之后我的经验是垂直模型的效果会越用越好而且能逐渐暴露路由规则的盲区反哺统一决策模型。AI 应用不是部署完就结束了它是个持续生长的系统数据闭环就是它的养料。5. 常见问题与排查技巧实录跑这套体系期间我踩过的坑、查过的问题能列一大串。挑几个最有代表性的写出来很多细节常规文档里根本不会提。5.1 模型路由误判轻量模型把复杂任务接走了这是我最开始遇到的高频问题。轻量模型负责简单请求但偶尔遇到一个明明很复杂的问题它却给了很高的置信度然后复杂任务就被它干砸了。排查下来发现轻量模型对“复杂度”的判断并不准它觉得能答就等于简单。解决思路给统一决策模型增加一个“复杂度置信度”维度当判定结果模棱两可时宁可交给更强的模型也不要省钱交给轻量模型。多花一点点成本换来的稳定性远大于节省的那点钱。5.2 输出幻觉导致业务事故风险有个场景是生成合同风险报告模型把原文里根本没有的条款给“脑补”出来了。这种幻觉其实比答错更危险因为看着特别可信。我后来在输出合规校验里加了一层“事实性抽检”模型生成的关键实体条款编号、金额、日期必须能从原文片段里找到对应依据找不到就自动重生成。这个抽检逻辑跑下来幻觉问题明显减少。这一条我觉得是 AI 应用落地最重要的经验之一不要相信模型输出的事实性要让输出可溯源。5.3 上下文超限长对话跑到一半就断了长文本任务和长会话场景都容易触发上下文超限。最早我是粗暴地清空历史结果用户一问之前聊过的内容就傻眼。后来才做了上下文压缩机制把早期对话转成结构化摘要既保留关键信息又不挤压当前上下文空间。另外还有一个细节不同模型的上下文窗口差别很大网关层要做统一适配超长请求自动切到长文本模型短对话留在普通模型避免资源浪费。5.4 工具调用失败智能体“想得到”但“做不了”智能体规划得很好但实际执行工具时失败了这种情况在接入外部 API 时非常高发。常见原因有三个参数格式不对、目标服务响应超时、权限不足。我的排查思路是先在执行层加详细的工具调用日志把入参、出参、异常原因全记录下来然后针对高频失败原因做自动修正。比如参数格式错误就在调用前加一层 schema 校验响应超时就加本地重试和降级逻辑。5.5 安全策略误杀该拦的没拦住不该拦的拦了一堆最后说一个安全策略编排最容易踩的坑——误杀。规则定得太死正常的业务内容也被拦截用户体感特别差规则定松了又真会漏风险。我的做法是给每条策略配置“动作等级”高危策略直接拦截中危策略走人审复核低危策略仅打标提醒。通过等级化配置把误杀率降下来同时高危场景一点不放。安全策略是持续迭代的过程不能一次配完就不管要经常根据拦截日志和用户反馈调参。收尾想说的话55873 这套体系从设计到落地我最深的体会是AI 应用架构到最后拼的不是单个模型有多强而是组合、编排和取舍的能力。613 混合模型解决成本与效果的平衡四层智能体架构解决复杂任务的协作安全策略编排解决系统在真实业务里的生存底线。在实际使用中如果你一开始觉得这套复杂度太高完全可以从最小版本起步——先把一个模型网关搭起来接两三个模型配一层简单路由后面再逐步往里面加智能体和安全策略。我自己就是这样做的先跑通主链路再持续迭代不到半年就长成了现在这个规模。最后再分享一个小技巧给每一层、每一个模型、每一条策略都加上独立可观测的日志和指标。这套体系不怕逻辑复杂就怕出问题时你没有数据可以追溯。你的一半运维压力会因为这个习惯直接消失。