这篇是 55873 生态系列的技术第 5 篇前面几篇把向量库、模型微调和工具网关分别讲透了这篇是把它们串起来的总装说明——AI 模型完整体系加智能体编排层。标题里的 613 混合模型、四层智能体架构、安全策略编排不是三个并列的模块而是一套从模型选型到任务调度的生产级链路。你可以通过这篇文章完整理解多模型混排为什么能比单模型省钱、四层智能体架构每一层在干什么、安全策略怎么在模型与工具之间动态生效、以及部署这种体系时真正卡人的性能瓶颈在哪。这篇不是架构图上的理想方案而是我实际跑过、记录过、踩过坑之后的版本适合正在做智能体产品或者准备从单模型调用升级到多模型系统的读者。1. 55873 生态的整体设计从一个模型扛不住三个问题说起1.1 为什么一个大模型扛不住全部需求55873 最开始就是一个通用大模型打通关的思路我把一个 70B 级别的模型接到全部业务场景里跑了不到一个月就得出一个结论这条路走不通问题出在三个地方。成本最先爆。每个请求都走这个大模型多轮对话加上知识库检索后的长上下文每一轮动不动几千 token月底看账单时确实有点心疼。延迟也非常难看。用户问一句今天天气怎么样从输入到输出要等七八秒这种体验放在生产环境里基本是劝退级别的。能力上也不对味同一个通用模型写代码不如专项模型看表格不如问数模型让它处理长文档时注意力漂移让它做语音时还得套一层非常笨拙的外部转换。这三个问题其实指向同一个结论模型选择从来不是越大越好而是在能力、延迟、成本之间做平衡。55873 最后确定的方案就是标题里那个 613 混合模型体系——把任务按照类型、复杂度、风险等级拆开让不同模型干自己最擅长的那部分。1.2 613 的选型分工我先列一下这套体系的构成每类模型都标了规模区间和我实际分配的职责方便你对照自己的场景做调整分类模型定位规模参考职责通用模型 1轻量对话1B-3B打招呼、闲聊、意图明确的小问题要求首字延迟低、成本低通用模型 2主力推理7B-14B逻辑推理、文本改写、翻译、中等复杂度任务通用模型 3长文本理解7B-14B 带长上下文文档总结、会议纪要、超长输入的基础理解通用模型 4向量嵌入0.1B-0.5B知识库召回、语义检索不直接出现在对话里但每个任务都依赖它通用模型 5多模态理解4B-8B图片识别、图表解析视觉部分用的是 ViT 骨架加多模态对齐层通用模型 6语音处理0.5B-2B语音转写和语音合成负责语音入口中枢模型编排大脑3B-8B意图理解、任务拆分、路由决策不负责具体内容生成专项模型 1代码智能体7B-34B代码生成、调试、重构建议接入代码仓库工具专项模型 2问数智能体7B-14B数据库问答、SQL 生成、表格结构理解对应标题里问数这一类场景专项模型 3文档智能体7B-14B基于 RAG 的长文档问答、多文档对比分析这 10 个模型不是平均分配资源而是按调用频率排优先级轻量对话模型和主力推理模型承接大概 60% 的请求中枢模型虽然小但每一条请求都要经过它第三个重资源的是问数模型因为它要接 SQL 生成和表格理解一次请求可能要多次推理。1.3 混合模型体系要解决的三件事选完模型之后真正的难点才开始。混合模型体系摆在面前的有三件事。第一件是路由问题一条请求进来怎么在几百毫秒内判断出该交给谁。第二件是协作编排问题一个多步骤任务可能需要多个模型接力比如对比上季度和本季度销售数据并总结趋势需要问数模型、主力推理模型、文档模型依次参与谁先谁后有严格顺序。第三件是一致性问题不同模型的中文表达风格、格式习惯都不太一样怎么让用户感受到这是一个连贯的产品而不是十个拼盘。这三件事分别构成了这篇后面几个部分的主线路由机制、四层智能体架构、安全策略编排其实都是围绕它们展开的。2. 613 模型的运行机制中枢调度、并行分工与降级策略2.1 中枢模型的路由决策逻辑路由是 613 体系的心脏负责泵血的那部分就是那个小尺寸中枢模型。它在整体设计里只干四件事意图分类、置信度判断、参数提取、模型分配。一条请求进来先经过明文预处理然后送进中枢模型。模型输出一个结构化结果我用函数调用方式拿到 JSON后续的所有决策都基于这个 JSON 执行。一个实际的路由结果长这样{ intent: code_refactor, intent_label: 代码重构, confidence: 0.96, assigned_model: code-agent, required_tools: [repo.read, code.scan, git.diff], fallback_models: [chat-main, chat-light], risk_level: medium }关键字段是 confidence。我的策略是置信度大于 0.9 直接走对应模型0.7 到 0.9 之间走规则校验比如问数意图但请求里没有任何表格或数据库字段名就退回主力推理模型低于 0.7 全部落到主力推理模型宁可慢一点也不能让轻量模型答非所问。中枢模型的 prompt 里我固化了一批高价值 few-shot 示例尤其是那些容易混淆的任务边界。比如帮我看看这个项目为什么编译不过是代码修复不是文档问答这个 Excel 里哪个城市销量最高是问数任务不是多模态识别。最开始我只有 5 条示例误路由率在 8% 上下后来扩到 20 条覆盖高频场景误路由率降到了 1.5%这一步投入产出比很高。2.2 多模型协作的四种基本模式中枢模型分发完之后具体执行时模型之间的关系不是简单的一对一我实际跑下来总结出四种协作模式。单模型直答最简单意图明确、结果固定比如翻译、查天气、算个日期差直接走一个模型就结束占比最高大概一半请求属于这一类。模型链是最常用的复杂任务模式。比如用户问上季度销售额环比变化多少链路是中枢模型拆任务 → 问数模型生成 SQL → 执行器在数据库跑 SQL → 主力推理模型基于结果生成解释。这个链路里问数模型只负责写 SQL不负责执行因为执行需要数据库连接权限不能交给模型直接操作。并行调用用在多模态场景。用户上传一张店铺照片加一句帮我分析客流和陈列问题图片理解模型先识别照片内容同时主力推理模型处理文字最后合并两个结果再做一轮总结。这种并行能省将近一半的端到端时间但代价是需要两个结果都稳定所以我在并行合并前加了一个校验步骤任一模型返回异常就整链路重试。混合投票用得最谨慎。只有高价值的判断类任务才会启用比如合同风险字段抽取我会让两个不同模型各跑一遍结果一致才采用不一致就走人工。这种模式成本高不能作为默认选项我的经验是只对影响金钱或合规决策的任务开启。2.3 混合模型最难的不是选型是上下文衔接模型选型反而没那么难真正麻烦的是上下文怎么在模型之间平滑接力。我的第一个方案很笨直接把同一段消息拼进每个模型各自的模板。结果问题立刻出现长文档会话里用户上传一份 2 万 token 的技术文档先让长文本模型总结再把原始文档原封不动喂给文档智能体做问答。后者重新做了一遍 prefill整整等了 6 秒用户明显感觉到卡了一下。后来我把上下文管理拆成三层解决。会话层统一用一套消息格式不管目标模型是什么切换时只要做模板转换文档层做缓存长文档的 prefill 结果按文档 ID 缓存下来第二次调用直接复用前缀消息层做裁剪超过窗口长度时先压缩历史摘要再截断最早的原始消息。这套方案上线之后同一个 2 万 token 文档从主力模型切到长文本模型耗时从 6 秒降到 1.2 秒用户无感。这里我最想强调的是混合模型的性能瓶颈往往不在单模型推理而在上下文接力如果你也开始做多模型混排优先解决这个问题。3. 四层智能体架构从感知接入到反思改进的完整链路3.1 L1 感知接入层指令先在这里被消毒四层架构的第一层叫感知接入层负责承接所有外部输入。它做三件事意图解析、指令清洗、会话初始化。很多人觉得这一层就是把用户输入传给中枢模型其实它有一个更重要的职责预过滤。输入先过一个轻量规则引擎识别出明显的指令注入模式比如忽略之前所有设定这类前缀打上风险标签再往后传。PII 脱敏也在这一层做手机号、身份证、邮箱先用占位符替换任务结束后再还原避免个人数据进到模型上下文里。会话初始化同样不能省。要判断这是新会话还是老会话从记忆层拉取历史摘要把用户的身份角色挂到请求头上。这条身份信息会一路传到第四层决定后面工具调用时的权限范围。L1 不调用任何业务工具它只负责看懂请求和清洗请求这是我在这个层设计上的原则。3.2 L2 规划编排层任务拆解的决策点第二层是规划编排层也是智能体有脑子的起点。它的输入是清洗后的用户目标输出是一个可执行的任务序列。还是拿那个销售对比需求举例。用户说对比上季度和本季度的销售数据总结变化趋势并生成一份报告规划层会把这句话拆成四个子任务查数据库拿到两个季度的明细、用问数模型跑一轮指标计算、让主力推理模型总结变化、最后调文档模型生成报告结构并填充。任务之间是有依赖关系的我用 DAG 管理的思路做任务编排但在工程实现上不引入复杂框架就用一个任务列表加状态标记。每个子任务有三个字段模型分配、工具列表、完成标准。完成标准很关键没有它智能体干得好坏没有判断依据。这一层还有个容易被忽略的环节叫预算控制。规划层在拆任务时会估算 token 消耗和执行时间超过预设预算就主动缩减方案比如把全量数据分析降级成只分析营收 Top10 产品而不是硬跑。线上跑下来预算控制能避免很多用户投诉和成本事故值得单独设计一版。3.3 L3 执行工具层真正动手干活的岗位第三层是执行工具层智能体在这里真正动手。工具层由四部分组成工具注册中心、参数校验、调用鉴权、限流熔断。每个工具在注册中心里声明名称、参数结构、权限标签、调用方式智能体不能凭空调用任何外部服务只能调注册过的工具。实践经验里有个数字我记得很清楚工具数量超过 20 个以后模型自己选工具很容易选错。我一开始有 23 个工具选型准确率只有 78%。后来我把工具描述全部改成动词加宾语加约束条件的写法比如query_order_detail(order_idstatus) 查询单笔订单明细只能传有效订单号不可用于列表查询准确率提到了 92%。工具描述写得好比换工具选择算法划算得多。这一层也是本地模型的一个重要应用场景。有段时间我在本地的 C# 项目里做重构会让代码智能体先跑一遍结构扫描分析警告项再让主力推理模型针对每个警告生成修改建议最后把改到一半的代码片段放进工具层的沙箱里做语法校验。这套流程比过去手动翻代码效率高了一大截也让我真正意识到工具层是智能体价值的放大器。3.4 L4 记忆与反思层让智能体不白干一趟第四层是记忆与反思层管三类记忆会话记忆、项目记忆、技能记忆。会话记忆是短期的记录当前对话的上下文摘要超时自动过期。项目记忆是长期的沉淀用户项目相关的背景知识比如代码仓库结构、数据库表关系、文档体系这些信息在会话开始时主动加载不需要用户每次重讲。技能记忆则是任务完成后沉淀出来的可复用模块比如Excel 数据清洗这个流程如果成功执行了三次就会固化成一个技能片段下次直接被规划层复用。反思循环是这一层的点睛之笔。每个任务执行完系统会让处理模型对结果做一次自检对比预期完成标准和实际输出。不满足就发起修正最多重试两轮。有一次执行生成月度销售数据报表自检环节发现结果里漏了同比字段模型自动发起了第二次查询补齐数据后才返回最终结果。这种体验在单模型直答里基本做不到因为单模型没有回头检查自己的机制。反思层让智能体从一次性的线性执行变成了闭环行为这对复杂任务的成功率提升非常明显。4. 安全策略编排跨越多层架构的动态防御线4.1 安全策略为何要作为一个独立编排层安全规约不是配置一个过滤器就完事而应该做成一个独立的编排层——这是我做 55873 时的体会。如果安全逻辑散落在各个模型和工具里比如对话模型自带一套内容过滤、工具层又各自校验权限会出现三个问题策略粒度不一致有的环节管得严有的环节松审计链路断裂出了问题很难定位是哪一层放行的策略更新要逐个发布跟不上业务变化。所以我单独做了一个安全策略编排层它更像一个控制平面不参与具体推理但每一层的决策都要向它查询。规则用声明式配置管理改策略不用改代码。4.2 全链路五道防线实际落地时我把安全策略编排拆成五道防线每一道对应处理不同风险。输入净化是第一道拦截提示注入、清洗恶意指令片段。路由约束是第二道按任务类型限制可用的模型集合比如未登录的游客会话不能调用问数智能体和代码智能体即使意图识别错了也不会把请求分发到高权限模型。工具鉴权是第三道每个工具带最小权限标签会话角色和工具权限不匹配就直接拒绝。输出审计是第四道敏感内容过滤、URL 白名单校验、输出结构校验防止模型生成恶意链接或不合规文本。审计追踪是最后一道全链路用统一 trace ID记录哪个模型处理过、哪个工具被调用过、耗时和 token 消耗明细。这五道防线里第二道和第三道是纵深防御的核心。就算前两道被绕过工具鉴权仍然能拦住真正敏感的调用——指令可以通过意图过滤但权限矩阵对不上就是进不去。4.3 一个被安全策略拦下来的典型越权请求有个例子我印象很深。一个游客身份的用户在对话里尝试诱导智能体调用内部查询接口它的措辞包装成查看订单售后政策意图识别通过了会话也确实被路由到了主力推理模型但在 L3 工具调用时工具鉴权发现该接口要求 admin 权限而当前角色是 guest直接拒绝了调用。整个攻击过程没有造成实际影响但审计日志完整记录下来了请求来源、意图标签、路由路径、被拦截的工具名、拒绝原因。这类事件在后台每天都有安全策略编排的价值就是让这些拦截不再是不可预测的而是可配置、可审计、可复现的。策略配置长这样用 YAML 声明一个角色和它对应的模型、工具白名单role: guest allow_models: - chat-light - chat-main - doc-agent deny_models: - code-agent ->
6+1+3混合模型与四层智能体架构：从模型选型到安全编排的生产级实践
这篇是 55873 生态系列的技术第 5 篇前面几篇把向量库、模型微调和工具网关分别讲透了这篇是把它们串起来的总装说明——AI 模型完整体系加智能体编排层。标题里的 613 混合模型、四层智能体架构、安全策略编排不是三个并列的模块而是一套从模型选型到任务调度的生产级链路。你可以通过这篇文章完整理解多模型混排为什么能比单模型省钱、四层智能体架构每一层在干什么、安全策略怎么在模型与工具之间动态生效、以及部署这种体系时真正卡人的性能瓶颈在哪。这篇不是架构图上的理想方案而是我实际跑过、记录过、踩过坑之后的版本适合正在做智能体产品或者准备从单模型调用升级到多模型系统的读者。1. 55873 生态的整体设计从一个模型扛不住三个问题说起1.1 为什么一个大模型扛不住全部需求55873 最开始就是一个通用大模型打通关的思路我把一个 70B 级别的模型接到全部业务场景里跑了不到一个月就得出一个结论这条路走不通问题出在三个地方。成本最先爆。每个请求都走这个大模型多轮对话加上知识库检索后的长上下文每一轮动不动几千 token月底看账单时确实有点心疼。延迟也非常难看。用户问一句今天天气怎么样从输入到输出要等七八秒这种体验放在生产环境里基本是劝退级别的。能力上也不对味同一个通用模型写代码不如专项模型看表格不如问数模型让它处理长文档时注意力漂移让它做语音时还得套一层非常笨拙的外部转换。这三个问题其实指向同一个结论模型选择从来不是越大越好而是在能力、延迟、成本之间做平衡。55873 最后确定的方案就是标题里那个 613 混合模型体系——把任务按照类型、复杂度、风险等级拆开让不同模型干自己最擅长的那部分。1.2 613 的选型分工我先列一下这套体系的构成每类模型都标了规模区间和我实际分配的职责方便你对照自己的场景做调整分类模型定位规模参考职责通用模型 1轻量对话1B-3B打招呼、闲聊、意图明确的小问题要求首字延迟低、成本低通用模型 2主力推理7B-14B逻辑推理、文本改写、翻译、中等复杂度任务通用模型 3长文本理解7B-14B 带长上下文文档总结、会议纪要、超长输入的基础理解通用模型 4向量嵌入0.1B-0.5B知识库召回、语义检索不直接出现在对话里但每个任务都依赖它通用模型 5多模态理解4B-8B图片识别、图表解析视觉部分用的是 ViT 骨架加多模态对齐层通用模型 6语音处理0.5B-2B语音转写和语音合成负责语音入口中枢模型编排大脑3B-8B意图理解、任务拆分、路由决策不负责具体内容生成专项模型 1代码智能体7B-34B代码生成、调试、重构建议接入代码仓库工具专项模型 2问数智能体7B-14B数据库问答、SQL 生成、表格结构理解对应标题里问数这一类场景专项模型 3文档智能体7B-14B基于 RAG 的长文档问答、多文档对比分析这 10 个模型不是平均分配资源而是按调用频率排优先级轻量对话模型和主力推理模型承接大概 60% 的请求中枢模型虽然小但每一条请求都要经过它第三个重资源的是问数模型因为它要接 SQL 生成和表格理解一次请求可能要多次推理。1.3 混合模型体系要解决的三件事选完模型之后真正的难点才开始。混合模型体系摆在面前的有三件事。第一件是路由问题一条请求进来怎么在几百毫秒内判断出该交给谁。第二件是协作编排问题一个多步骤任务可能需要多个模型接力比如对比上季度和本季度销售数据并总结趋势需要问数模型、主力推理模型、文档模型依次参与谁先谁后有严格顺序。第三件是一致性问题不同模型的中文表达风格、格式习惯都不太一样怎么让用户感受到这是一个连贯的产品而不是十个拼盘。这三件事分别构成了这篇后面几个部分的主线路由机制、四层智能体架构、安全策略编排其实都是围绕它们展开的。2. 613 模型的运行机制中枢调度、并行分工与降级策略2.1 中枢模型的路由决策逻辑路由是 613 体系的心脏负责泵血的那部分就是那个小尺寸中枢模型。它在整体设计里只干四件事意图分类、置信度判断、参数提取、模型分配。一条请求进来先经过明文预处理然后送进中枢模型。模型输出一个结构化结果我用函数调用方式拿到 JSON后续的所有决策都基于这个 JSON 执行。一个实际的路由结果长这样{ intent: code_refactor, intent_label: 代码重构, confidence: 0.96, assigned_model: code-agent, required_tools: [repo.read, code.scan, git.diff], fallback_models: [chat-main, chat-light], risk_level: medium }关键字段是 confidence。我的策略是置信度大于 0.9 直接走对应模型0.7 到 0.9 之间走规则校验比如问数意图但请求里没有任何表格或数据库字段名就退回主力推理模型低于 0.7 全部落到主力推理模型宁可慢一点也不能让轻量模型答非所问。中枢模型的 prompt 里我固化了一批高价值 few-shot 示例尤其是那些容易混淆的任务边界。比如帮我看看这个项目为什么编译不过是代码修复不是文档问答这个 Excel 里哪个城市销量最高是问数任务不是多模态识别。最开始我只有 5 条示例误路由率在 8% 上下后来扩到 20 条覆盖高频场景误路由率降到了 1.5%这一步投入产出比很高。2.2 多模型协作的四种基本模式中枢模型分发完之后具体执行时模型之间的关系不是简单的一对一我实际跑下来总结出四种协作模式。单模型直答最简单意图明确、结果固定比如翻译、查天气、算个日期差直接走一个模型就结束占比最高大概一半请求属于这一类。模型链是最常用的复杂任务模式。比如用户问上季度销售额环比变化多少链路是中枢模型拆任务 → 问数模型生成 SQL → 执行器在数据库跑 SQL → 主力推理模型基于结果生成解释。这个链路里问数模型只负责写 SQL不负责执行因为执行需要数据库连接权限不能交给模型直接操作。并行调用用在多模态场景。用户上传一张店铺照片加一句帮我分析客流和陈列问题图片理解模型先识别照片内容同时主力推理模型处理文字最后合并两个结果再做一轮总结。这种并行能省将近一半的端到端时间但代价是需要两个结果都稳定所以我在并行合并前加了一个校验步骤任一模型返回异常就整链路重试。混合投票用得最谨慎。只有高价值的判断类任务才会启用比如合同风险字段抽取我会让两个不同模型各跑一遍结果一致才采用不一致就走人工。这种模式成本高不能作为默认选项我的经验是只对影响金钱或合规决策的任务开启。2.3 混合模型最难的不是选型是上下文衔接模型选型反而没那么难真正麻烦的是上下文怎么在模型之间平滑接力。我的第一个方案很笨直接把同一段消息拼进每个模型各自的模板。结果问题立刻出现长文档会话里用户上传一份 2 万 token 的技术文档先让长文本模型总结再把原始文档原封不动喂给文档智能体做问答。后者重新做了一遍 prefill整整等了 6 秒用户明显感觉到卡了一下。后来我把上下文管理拆成三层解决。会话层统一用一套消息格式不管目标模型是什么切换时只要做模板转换文档层做缓存长文档的 prefill 结果按文档 ID 缓存下来第二次调用直接复用前缀消息层做裁剪超过窗口长度时先压缩历史摘要再截断最早的原始消息。这套方案上线之后同一个 2 万 token 文档从主力模型切到长文本模型耗时从 6 秒降到 1.2 秒用户无感。这里我最想强调的是混合模型的性能瓶颈往往不在单模型推理而在上下文接力如果你也开始做多模型混排优先解决这个问题。3. 四层智能体架构从感知接入到反思改进的完整链路3.1 L1 感知接入层指令先在这里被消毒四层架构的第一层叫感知接入层负责承接所有外部输入。它做三件事意图解析、指令清洗、会话初始化。很多人觉得这一层就是把用户输入传给中枢模型其实它有一个更重要的职责预过滤。输入先过一个轻量规则引擎识别出明显的指令注入模式比如忽略之前所有设定这类前缀打上风险标签再往后传。PII 脱敏也在这一层做手机号、身份证、邮箱先用占位符替换任务结束后再还原避免个人数据进到模型上下文里。会话初始化同样不能省。要判断这是新会话还是老会话从记忆层拉取历史摘要把用户的身份角色挂到请求头上。这条身份信息会一路传到第四层决定后面工具调用时的权限范围。L1 不调用任何业务工具它只负责看懂请求和清洗请求这是我在这个层设计上的原则。3.2 L2 规划编排层任务拆解的决策点第二层是规划编排层也是智能体有脑子的起点。它的输入是清洗后的用户目标输出是一个可执行的任务序列。还是拿那个销售对比需求举例。用户说对比上季度和本季度的销售数据总结变化趋势并生成一份报告规划层会把这句话拆成四个子任务查数据库拿到两个季度的明细、用问数模型跑一轮指标计算、让主力推理模型总结变化、最后调文档模型生成报告结构并填充。任务之间是有依赖关系的我用 DAG 管理的思路做任务编排但在工程实现上不引入复杂框架就用一个任务列表加状态标记。每个子任务有三个字段模型分配、工具列表、完成标准。完成标准很关键没有它智能体干得好坏没有判断依据。这一层还有个容易被忽略的环节叫预算控制。规划层在拆任务时会估算 token 消耗和执行时间超过预设预算就主动缩减方案比如把全量数据分析降级成只分析营收 Top10 产品而不是硬跑。线上跑下来预算控制能避免很多用户投诉和成本事故值得单独设计一版。3.3 L3 执行工具层真正动手干活的岗位第三层是执行工具层智能体在这里真正动手。工具层由四部分组成工具注册中心、参数校验、调用鉴权、限流熔断。每个工具在注册中心里声明名称、参数结构、权限标签、调用方式智能体不能凭空调用任何外部服务只能调注册过的工具。实践经验里有个数字我记得很清楚工具数量超过 20 个以后模型自己选工具很容易选错。我一开始有 23 个工具选型准确率只有 78%。后来我把工具描述全部改成动词加宾语加约束条件的写法比如query_order_detail(order_idstatus) 查询单笔订单明细只能传有效订单号不可用于列表查询准确率提到了 92%。工具描述写得好比换工具选择算法划算得多。这一层也是本地模型的一个重要应用场景。有段时间我在本地的 C# 项目里做重构会让代码智能体先跑一遍结构扫描分析警告项再让主力推理模型针对每个警告生成修改建议最后把改到一半的代码片段放进工具层的沙箱里做语法校验。这套流程比过去手动翻代码效率高了一大截也让我真正意识到工具层是智能体价值的放大器。3.4 L4 记忆与反思层让智能体不白干一趟第四层是记忆与反思层管三类记忆会话记忆、项目记忆、技能记忆。会话记忆是短期的记录当前对话的上下文摘要超时自动过期。项目记忆是长期的沉淀用户项目相关的背景知识比如代码仓库结构、数据库表关系、文档体系这些信息在会话开始时主动加载不需要用户每次重讲。技能记忆则是任务完成后沉淀出来的可复用模块比如Excel 数据清洗这个流程如果成功执行了三次就会固化成一个技能片段下次直接被规划层复用。反思循环是这一层的点睛之笔。每个任务执行完系统会让处理模型对结果做一次自检对比预期完成标准和实际输出。不满足就发起修正最多重试两轮。有一次执行生成月度销售数据报表自检环节发现结果里漏了同比字段模型自动发起了第二次查询补齐数据后才返回最终结果。这种体验在单模型直答里基本做不到因为单模型没有回头检查自己的机制。反思层让智能体从一次性的线性执行变成了闭环行为这对复杂任务的成功率提升非常明显。4. 安全策略编排跨越多层架构的动态防御线4.1 安全策略为何要作为一个独立编排层安全规约不是配置一个过滤器就完事而应该做成一个独立的编排层——这是我做 55873 时的体会。如果安全逻辑散落在各个模型和工具里比如对话模型自带一套内容过滤、工具层又各自校验权限会出现三个问题策略粒度不一致有的环节管得严有的环节松审计链路断裂出了问题很难定位是哪一层放行的策略更新要逐个发布跟不上业务变化。所以我单独做了一个安全策略编排层它更像一个控制平面不参与具体推理但每一层的决策都要向它查询。规则用声明式配置管理改策略不用改代码。4.2 全链路五道防线实际落地时我把安全策略编排拆成五道防线每一道对应处理不同风险。输入净化是第一道拦截提示注入、清洗恶意指令片段。路由约束是第二道按任务类型限制可用的模型集合比如未登录的游客会话不能调用问数智能体和代码智能体即使意图识别错了也不会把请求分发到高权限模型。工具鉴权是第三道每个工具带最小权限标签会话角色和工具权限不匹配就直接拒绝。输出审计是第四道敏感内容过滤、URL 白名单校验、输出结构校验防止模型生成恶意链接或不合规文本。审计追踪是最后一道全链路用统一 trace ID记录哪个模型处理过、哪个工具被调用过、耗时和 token 消耗明细。这五道防线里第二道和第三道是纵深防御的核心。就算前两道被绕过工具鉴权仍然能拦住真正敏感的调用——指令可以通过意图过滤但权限矩阵对不上就是进不去。4.3 一个被安全策略拦下来的典型越权请求有个例子我印象很深。一个游客身份的用户在对话里尝试诱导智能体调用内部查询接口它的措辞包装成查看订单售后政策意图识别通过了会话也确实被路由到了主力推理模型但在 L3 工具调用时工具鉴权发现该接口要求 admin 权限而当前角色是 guest直接拒绝了调用。整个攻击过程没有造成实际影响但审计日志完整记录下来了请求来源、意图标签、路由路径、被拦截的工具名、拒绝原因。这类事件在后台每天都有安全策略编排的价值就是让这些拦截不再是不可预测的而是可配置、可审计、可复现的。策略配置长这样用 YAML 声明一个角色和它对应的模型、工具白名单role: guest allow_models: - chat-light - chat-main - doc-agent deny_models: - code-agent ->
