技术第5篇AI模型完整体系与智能体编排层拆解模型不是越强越好组合起来好用才是关键。这个观点是我过去大半年搭内部AI应用体系最深的一个体会。这个系列已经写到第五篇前四篇讲的是单点能力从模型部署、数据工程、推理优化到评估体系。这一篇我打算把视角拉高聊聊我们正在跑的这套代号55873的完整体系613混合模型怎么分角色、四层智能体架构怎么分工、安全策略编排怎么嵌进调用链而不是外挂在旁边。如果你正在搭中大型AI应用或者准备把多个模型组合成一个可用的产品这篇应该能给你一套完整可参考的框架。先解释一下55873这个代号。数字不代表玄学它是对内部资源的映射5类模型底座、5条安全基线、8种标准工具协议、7个核心业务场景、3套运维保障。拆开看就是我们常说的模型不是单一能力而是需要分层、分组、分批管理。而这篇的重点在两个最容易被忽略、却最影响成败的部分混合模型的分工设计以及智能体编排层的组织方式。1. 为什么是613单一模型永远解决不了真实业务的多重约束1.1 单一大模型的三个死穴先说结论指望一个大模型扛下所有任务在真实业务环境里基本走不通。不是模型能力不够而是能力够和业务可用之间隔着三道坎。第一道坎是能力维度冲突。一个模型很难同时在长文本理解、代码生成、数学推理、多模态识别、创意写作上都达到顶尖水平。你可以让一个通用大模型写周报也可以让它分析表格但让它一边做严谨的合规判断、一边保持自然的口语对话风格结果往往是两边都别扭。真实业务需要的是一个入口多种专业能力单模型无法在同一时刻满足这些互相冲突的约束。第二道坎是成本和延迟。把所有请求都发给一个70B甚至更大规模的模型跑简单任务时你会发现响应时间直接压垮用户体验。一个帮我查一下订单状态的问题犯不着动用全参数模型。实际业务里大量请求是短文本、低复杂度、高频次这些请求用大模型处理就是资源浪费用专用小模型处理又快又稳。第三道坎是安全与可控。单一模型一旦出了幻觉或者违规内容整条链路跟着遭殃你找不到一个降级的替代方案。如果架构里从一开始就设计了多个模型分角色、互相校验至少还能在某个环节出问题时切断或回退不至于全盘失控。1.2 613的分工逻辑基于这三道坎我们的方案是把模型按角色拆成三组6个主力模型1个路由与质检模型3个垂类小模型。这听起来像是堆模型其实是在做角色分权。先说6个主力模型。它们不是随便选6个而是按能力特长挑出来的。6个分别对应文本生成、代码理解与生成、数学与逻辑推理、长文档分析、多模态理解、创意写作这六个方向。之所以要用6个而不是1个是因为每个方向对模型的能力要求差异太大。比如长文档分析需要模型能处理几十万字的上下文并准确引用某个段落这对模型的注意力机制和上下文窗口有刚性要求而数学推理则更依赖模型在符号计算和链式思考上的表现。把六个模型放在一个模型池里通过路由决定每个请求去哪个模型才能在成本、速度、质量之间找到平衡。再说那1个路由与质检模型。这个模型是最容易被忽略的但也是整个体系里唯一不能省的角色。它的任务不是生成内容而是判断这个请求该交给谁处理以及处理结果是不是合格。换句话说它是一个裁判不亲自下场踢球。路由模型通常用中等规模模型就够了因为它不重生成重分类和打分。最后是3个垂类小模型。它们分别负责知识库问答、合规审核、结构化数据抽取。选择小模型的原因是这三个任务领域边界清晰、数据充分小模型通过微调就能达到甚至超过通用大模型的效果但推理成本低了至少一个数量级。合规审核这种任务要求规则可解释小模型更容易做到为什么拒绝的可追溯。角色分组数量核心职责选型标准部署方式主力生成模型6覆盖文本、代码、推理、长文档、多模态、创意六大能力每种能力维度的SOTA梯队云端GPU集群独立部署路由与质检模型1意图识别、模型路由、输出质量评分中等规模、低延迟、分类精度高单卡推理常驻内存垂类小模型3知识库问答、合规审核、结构化抽取领域微调效果为主参数量可牺牲普通GPU或CPU边缘部署这个配置的核心理念一句话总结就是大模型负责生成小模型负责保镖中等模型负责调度。谁干什么事从一开始就划定边界而不是让一个模型既当运动员又当裁判。2. 四层智能体架构模型在中间编排在两头模型分好了工接下来要解决的是谁来安排工作。这就是智能体编排层的价值所在。我在设计这套架构的时候一直在强调一个观点智能体的智能不是模型给的是编排层给的。模型只负责生成文本怎么拆任务、怎么调工具、怎么记忆、怎么纠错全是编排层的活。我们把整体架构拆成四层每一层都有明确边界。2.1 接入层把工具和渠道都变成标准协议接入层是整个架构面向外界的窗口也是最容易被低估的一层。你把API、对话机器人、工单系统、邮件、内部IM全部接进来如果每个渠道都单独写一套逻辑后面维护起来就是灾难。我们的做法是定义一套统一的协议。一个请求进来到编排层之前必须先转换成标准消息格式请求ID、用户身份、会话上下文、意图候选列表、附带的结构化参数。这样后面无论哪个模型来处理都不会被渠道差异干扰。接入层还要做一件重要的事工具注册。智能体要能调用外部的API、数据库查询、计算器、搜索服务不可能在代码里写死每个工具的调用方式。我们实现了一个工具仓库每个工具用OpenAPI风格的描述文件注册声明它接受什么参数、返回什么结构、需要什么权限级别。模型看到的是工具列表和描述编排层看到的是可执行的函数。这一层的核心价值就是把模型自由和工具边界隔开。2.2 规划层任务拆解与路由决策规划层是我花时间最多的地方。用户的请求往往不是一个单一动作。比如用户问帮我对比一下这两个供应商的报价然后生成一份采购建议这句话背后至少包含三个子任务解析报价单、做数据对比、生成建议文案。如果没有任务拆解模型很容易只做最后一步丢掉前面两个关键环节。规划层的执行顺序是这样的先用路由模型做意图分类和复杂度评估判断请求属于哪个业务领域、需要哪类能力然后基于预定义的任务模板把大请求拆成多个原子任务最后根据每个原子任务的目标决定调用哪个模型、执行哪个工具。这里有个细节我特别想强调任务拆解绝不能完全交给模型自由发挥。我们做了可配置的DAG模板把常见业务流程预定义好模型只是在模板里做参数填充和顺序微调。为什么这么做因为完全自由的任务规划在真实业务里太容易失控——模型可能漏掉关键校验步骤也可能把顺序搞反比如先调用工具再鉴权。预定义模板相当于给模型画了一条轨道既保留了灵活性又限制了破坏力。2.3 执行层模型调工具而不是模型写代码执行层的职责很纯粹真正把规划层拆出来的任务一个个执行掉并且校验执行结果。很多人在这一层容易走进一个误区让模型直接生成代码来解决工具调用问题。比如模型说我用Python字符串处理一下这个JSON再提取字段这在测试环境没问题一上生产就是定时炸弹——模型生成的代码可能有漏洞可能引入不安全的库而且你无法审计它到底干了什么。我们的执行层遵循一个原则模型只做参数映射和结果解释工具调用本身由确定的代码完成。也就是说模型的任务是根据用户意图把工具函数所需的参数从上下文中抽取出来然后编排层调用真实的、经过测试的代码去执行。模型给的是意图和参数而不是命令和脚本。实测下来这个思路让工具调用的失败率降低了70%以上因为代码路径是确定的可变的部分只在参数层面。执行层还要记录每一次工具调用的输入输出方便后面做审计和回放。这个我在安全策略编排部分再展开。2.4 记忆与自检层让体系具备后悔能力四层架构里记忆与自检层最容易被人当成附加功能但我认为它是决定智能体体验上限的一层。记忆分为两块。短期记忆负责当前会话的上下文包括用户刚才说了什么、模型已经执行了哪些步骤、得到了哪些中间结果。长期记忆则负责跨会话的信息沉淀比如用户偏好的文档格式、历史订单的常用条款、之前拒绝过的风险操作。我们用的是向量数据库做长期记忆的检索候选记忆和当前请求做相似度匹配后注入上下文。这里最需要注意的是记忆注入的不喧宾夺主——记忆只是参考不能覆盖用户当前明确的意图否则就会出现用户明明说了这次换成邮件模板系统还沿用上次的PDF模板这种低级错误。自检层是我特别自豪的设计。每一次任务完成后系统不会直接把结果返回给用户而是先让质检模型走一遍复盘检查输出格式是否符合预期、关键数据是否有来源支撑、是否出现自相矛盾、是否踩了安全红线。如果质检不过系统会触发一轮纠错回到出错环节调整参数重新执行或者换一个模型生成。这个机制相当于给系统装了一个后悔按钮让它在把错误结果交给用户之前先自己犯一遍错并修正。实测下来自检层对质量的提升非常明显。尤其是在多步工具调用场景里没有自检时经常出现前面步骤对了、后面步骤错了的中间态错误有了自检之后整体任务成功率提升了大概20个百分点。3. 安全策略编排把权限、审计、防幻觉做进调用链安全这件事在传统架构里往往是事后补救但在智能体架构里它必须成为调用链的一部分。为什么因为智能体的行为路径是动态的你没法用静态的规则穷举所有可能的调用组合。安全策略必须跟着每一次请求实时编排。3.1 工具白名单与最小权限原则第一道防线是工具白名单。我们这个体系里智能体能用的每一个工具都在接入层注册过并且明确标注了权限等级。模型看到的工具列表不是全量而是根据当前用户的身份过滤后的子集。一个普通员工发起请求他对应的工具列表里就不可能出现删除数据库记录这种操作。这里有个容易忽略的点工具级别的白名单还不够必须要做到参数级别的校验。比如查询订单这个工具普通用户可以传自己的订单号但不允许传全部订单这种范围参数。我们在执行层加了一个参数校验组件在每个工具调用之前检查参数是否落在当前用户的权限范围内。这个设计一开始被团队嫌麻烦后来一次安全事故排查里发现正是这道参数校验拦住了一个越权查询的漏洞大家才意识到这是刚需。3.2 敏感操作的二次确认与分级审批第二道防线是敏感操作分级。不是所有操作都需要走审批但发送外部邮件修改生产配置删除数据批量导出用户信息这类高风险操作必须进入二次确认流程。我们实现了一个简单的分级机制低风险操作直接执行中风险操作返回结果前需要用户输入确认执行高风险操作则直接转人工审批智能体只能生成草稿不能直接提交。这套机制看起来简单但它防止了智能体最常见的失控方式——用户问了一个模糊问题智能体自动执行了一连串不可逆操作。那些LLM造成的越权事故本质不是模型有恶意而是编排层没有默认给敏感性排序。3.3 防幻觉的三道闸门幻觉是智能体架构里最让人头疼的问题尤其当模型需要调用外部数据时它可能把编造的内容包装成查到的结果。我们的防幻觉策略是三道闸门第一道路由侧。请求进来时如果涉及事实性查询查询订单、查库存、查政策强制走带工具调用的链路禁止模型凭空回答。这道闸门在规划层实现缺了它后面做得再好都拦不住生成侧的幻觉。第二道质检侧。模型生成回答后质检模型会做事实一致性校验把回答里出现的具体数字、日期、姓名等实体与工具调用返回的真实数据进行比对不一致就触发纠错重跑。第三道用户侧。即使前面两道都没拦住最终返回给用户的内容里凡涉及关键结论我们强制附带来源引用。用户可以点开引用核实数据出处。这既是对用户负责也是倒逼模型在生成时不敢随便编。3.4 全链路审计与回放最后一道安全能力是审计。每一个请求从进入接入层开始会生成一个全局唯一的request_id这个ID贯穿意图识别、任务拆解、模型调用、工具调用、质检判定、最终返回。所有环节的日志都以request_id为索引存储。这意味着什么一旦线上出了问题或者用户投诉某个回答有问题我们可以完整回放这个请求的心路历程模型当时看到了什么、为什么决定调用这个工具、工具返回了什么、质检为什么放行了。这种可回放性在传统软件开发里是基本要求但在智能体架构里反而经常被忽略。没有可回放性AI应用出了安全事故就只能是排查靠猜、修复靠试这是绝对不能接受的。安全控制点所在层核心机制拦截目标工具白名单接入层按身份过滤工具列表未授权能力调用参数级校验执行层校验工具参数范围越权数据访问敏感操作分级执行层二次确认/人工审批不可逆高风险操作事实一致性校验自检层比对生成内容与真实数据模型幻觉输出来源引用接入层出口关键结论附带可查来源不可信回答全链路审计全部层request_id贯穿日志事后追溯与复盘4. 落地部署中的五个实测问题与排查链路这套体系写出来很理想但真实落地过程中踩过的坑比方案本身更有参考价值。我挑五个典型的实测问题把完整的排查链路写出来方便你对照自己的场景。4.1 现象多个模型都答得不错编排后效果反而变差上线初期我们遇到一个很奇怪的现象单个模型在评测集上表现都不错但走完整个编排链路之后输出质量明显下降甚至出现答非所问。排查链路是从路由模型开始的。结果发现路由模型在传递上下文时会把原始请求之外的一些系统提示语和工具描述也一起传给下游模型。多个模型拼装提示词时由于各自的模板风格不同出现了指令冲突。比如路由模型要求用简洁语气回答而主力模型自己的系统提示是输出详细的分析报告两者一叠加主力模型就会处于一种不知道听谁的状态输出的内容一会儿简洁一会儿啰嗦非常不稳定。根因找到了解决方案是统一提示词协议所有模型共享同一套指令层级约定系统级指令、业务级指令、用户级指令的优先级顺序。口号是你只需要关注你的角色全局指令由编排层负责。这个修复上线后效果立即回到单测水平甚至因为上下文更精简了推理速度还快了一点。4.2 现象路由模型把小问题路由给了重型模型这个问题的直接后果就是成本飙升。排查链路里我第一时间看了路由日志发现大量简单请求比如今天天气怎么样帮我算一下24×17被路由模型分配给了最大的那个主力模型处理。根因不是路由模型笨而是路由模型的分类阈值设置得太保守。它对意图判断的低置信度区间里默认策略是宁大勿小——不确定就丢给最强的模型保证质量优先。但对简单任务来说这种兜底没有任何意义杀鸡用了牛刀。修复方式是两条腿走路。一是调阈值当分类置信度低于60%时先降级给中等规模模型尝试而不是直接上最强模型。二是加了一个复杂度预筛在路由之前先用规则和关键词判断请求复杂度明显简单的独立计算任务直接走轻量模型通道不进路由。调整后整体推理成本下降约30%P95延迟也缩短了将近一半。4.3 现象安全模块在质检时被大模型的输出说服这个坑是我最没想到的。合规审核小模型在一段时间内出现了漏检率上升尤其是对大模型生成的流畅文本几乎不拦截。排查日志发现合规模型给这些文本打的违规置信度都非常低。后来我们做了一个对照实验同一段违规文本由人工改写得更自然流畅一些之后送给合规模型拦截率明显下降。这说明合规模型被文本的表面流畅性说服了——大模型生成的文本语法完整、逻辑连贯反而让分类器放松了警惕。这本质上是一种对抗性鲁棒性问题。解决方案有三个层次。第一在合规模型的训练数据里加入大模型生成的对抗样本让它学会关注语义而非表面流畅度。第二设置双人复核机制合规模型的小模型做初筛如果是大模型生成的高质量文本额外送一个不同系列的模型做交叉复核避免同一家模型互相包庇。第三对低置信度但高风险的文本类型强制人工抽检。这套组合下来漏检率回到了可控范围。4.4 现象并发高峰时工具调用超时蔓延智能体架构里的链路比传统API要长得多一次复杂任务可能要串行调用三到五个工具。当并发量上来任何一个环节变慢都会导致整体超时而且会像交通拥堵一样向后蔓延。排查链路里我先用全链路追踪工具把每个环节的耗时拉出来。发现最大的瓶颈不在模型推理而在外部服务响应——尤其是数据库查询和第三方API在并发冲击下响应时间直接翻倍。模型推理的时间是相对固定的外部服务才是不确定因素。修复方案是三层降级策略。第一层是超时熔断给每个工具调用设置硬超时超过500ms直接中断并返回暂时不可用而不是无限等待。第二层是结果缓存对于查询类工具同一参数组合的结果缓存5分钟极大地减轻了重复请求对下游的压力。第三层是异步化不依赖先后顺序的工具调用改为并行整体耗时从串行的累加变成并行的最大值。这三招落地后P95延迟从原来的6秒降到了2秒左右。4.5 现象长短记忆冲突导致用户困惑记忆层上线一段时间后有用户反馈明明上次说了要简体中文这次回复还是用了繁体。排查发现长期记忆里确实存了用户偏好简体中文的向量但当前会话的短期记忆里有一条不太起眼的记录——用户在这轮对话中说了一句不过繁体也可以接受。问题就出在记忆的优先级设计上。我们当时的策略是长期记忆和短期记忆混合注入没有明确优先级模型根据上下文的相关性自己判断结果它被最近出现的信息带偏了。修复方式很直接给记忆加时间权重和身份权重。短期记忆中距离当前轮次越近的内容权重越高长期记忆中与用户身份绑定的偏好权重略高于短期记忆中非明确指令的内容。另外加了一条硬规则当短期记忆中出现用户明确改变偏好的表述时立即覆盖长期记忆中的旧偏好并写入新的长期记忆。这套覆盖-更新机制上线后这类冲突问题基本绝迹。这五个问题的共性很明确智能体架构的坑绝大多数不是模型能力问题而是编排逻辑、上下文管理、降级策略这些工程细节问题。模型本身的进步是线性的而编排层的完善往往能带来数量级的体验提升。5. 从55873到更多这套体系带来的实际变化说点具体的。这套体系上线三个月后我统计了一组内部数据复杂任务的端到端成功率从最初的62%提升到了83%单次请求的平均推理成本下降了约35%安全模块累计拦截了大小违规操作上千次其中包含多起如果放任下去会直接影响业务数据的风险操作。这些数字谈不上惊艳但在稳定性和可控性上的提升是实打实的。从我个人的实操体会来说搭这套体系最大的收获不是把多个模型拼在了一起而是意识到一个朴素的道理AI应用的天花板不在模型在编排。模型的能力是底座但决定产品体验的是任务拆解是否合理、路由决策是否聪明、记忆管理是否有序、安全策略是否兜得住。最后分享一个小技巧。在配置路由模型时不要太追求一次路由就完全正确。给路由加一个允许修正的机制当下游模型发现输入和自身擅长领域不匹配时允许它回抛给路由重新分配。这样等于给路由加了一个反馈回路比单纯调阈值要有效得多。下一篇我会重点写执行层里工具调用的协议设计细节包括函数描述的编写规范、参数抽取的策略以及错误重试的最佳实践。如果你在那方面有踩坑经验欢迎一起交流。
AI模型完整体系与智能体编排层拆解：混合模型与四层架构实践
技术第5篇AI模型完整体系与智能体编排层拆解模型不是越强越好组合起来好用才是关键。这个观点是我过去大半年搭内部AI应用体系最深的一个体会。这个系列已经写到第五篇前四篇讲的是单点能力从模型部署、数据工程、推理优化到评估体系。这一篇我打算把视角拉高聊聊我们正在跑的这套代号55873的完整体系613混合模型怎么分角色、四层智能体架构怎么分工、安全策略编排怎么嵌进调用链而不是外挂在旁边。如果你正在搭中大型AI应用或者准备把多个模型组合成一个可用的产品这篇应该能给你一套完整可参考的框架。先解释一下55873这个代号。数字不代表玄学它是对内部资源的映射5类模型底座、5条安全基线、8种标准工具协议、7个核心业务场景、3套运维保障。拆开看就是我们常说的模型不是单一能力而是需要分层、分组、分批管理。而这篇的重点在两个最容易被忽略、却最影响成败的部分混合模型的分工设计以及智能体编排层的组织方式。1. 为什么是613单一模型永远解决不了真实业务的多重约束1.1 单一大模型的三个死穴先说结论指望一个大模型扛下所有任务在真实业务环境里基本走不通。不是模型能力不够而是能力够和业务可用之间隔着三道坎。第一道坎是能力维度冲突。一个模型很难同时在长文本理解、代码生成、数学推理、多模态识别、创意写作上都达到顶尖水平。你可以让一个通用大模型写周报也可以让它分析表格但让它一边做严谨的合规判断、一边保持自然的口语对话风格结果往往是两边都别扭。真实业务需要的是一个入口多种专业能力单模型无法在同一时刻满足这些互相冲突的约束。第二道坎是成本和延迟。把所有请求都发给一个70B甚至更大规模的模型跑简单任务时你会发现响应时间直接压垮用户体验。一个帮我查一下订单状态的问题犯不着动用全参数模型。实际业务里大量请求是短文本、低复杂度、高频次这些请求用大模型处理就是资源浪费用专用小模型处理又快又稳。第三道坎是安全与可控。单一模型一旦出了幻觉或者违规内容整条链路跟着遭殃你找不到一个降级的替代方案。如果架构里从一开始就设计了多个模型分角色、互相校验至少还能在某个环节出问题时切断或回退不至于全盘失控。1.2 613的分工逻辑基于这三道坎我们的方案是把模型按角色拆成三组6个主力模型1个路由与质检模型3个垂类小模型。这听起来像是堆模型其实是在做角色分权。先说6个主力模型。它们不是随便选6个而是按能力特长挑出来的。6个分别对应文本生成、代码理解与生成、数学与逻辑推理、长文档分析、多模态理解、创意写作这六个方向。之所以要用6个而不是1个是因为每个方向对模型的能力要求差异太大。比如长文档分析需要模型能处理几十万字的上下文并准确引用某个段落这对模型的注意力机制和上下文窗口有刚性要求而数学推理则更依赖模型在符号计算和链式思考上的表现。把六个模型放在一个模型池里通过路由决定每个请求去哪个模型才能在成本、速度、质量之间找到平衡。再说那1个路由与质检模型。这个模型是最容易被忽略的但也是整个体系里唯一不能省的角色。它的任务不是生成内容而是判断这个请求该交给谁处理以及处理结果是不是合格。换句话说它是一个裁判不亲自下场踢球。路由模型通常用中等规模模型就够了因为它不重生成重分类和打分。最后是3个垂类小模型。它们分别负责知识库问答、合规审核、结构化数据抽取。选择小模型的原因是这三个任务领域边界清晰、数据充分小模型通过微调就能达到甚至超过通用大模型的效果但推理成本低了至少一个数量级。合规审核这种任务要求规则可解释小模型更容易做到为什么拒绝的可追溯。角色分组数量核心职责选型标准部署方式主力生成模型6覆盖文本、代码、推理、长文档、多模态、创意六大能力每种能力维度的SOTA梯队云端GPU集群独立部署路由与质检模型1意图识别、模型路由、输出质量评分中等规模、低延迟、分类精度高单卡推理常驻内存垂类小模型3知识库问答、合规审核、结构化抽取领域微调效果为主参数量可牺牲普通GPU或CPU边缘部署这个配置的核心理念一句话总结就是大模型负责生成小模型负责保镖中等模型负责调度。谁干什么事从一开始就划定边界而不是让一个模型既当运动员又当裁判。2. 四层智能体架构模型在中间编排在两头模型分好了工接下来要解决的是谁来安排工作。这就是智能体编排层的价值所在。我在设计这套架构的时候一直在强调一个观点智能体的智能不是模型给的是编排层给的。模型只负责生成文本怎么拆任务、怎么调工具、怎么记忆、怎么纠错全是编排层的活。我们把整体架构拆成四层每一层都有明确边界。2.1 接入层把工具和渠道都变成标准协议接入层是整个架构面向外界的窗口也是最容易被低估的一层。你把API、对话机器人、工单系统、邮件、内部IM全部接进来如果每个渠道都单独写一套逻辑后面维护起来就是灾难。我们的做法是定义一套统一的协议。一个请求进来到编排层之前必须先转换成标准消息格式请求ID、用户身份、会话上下文、意图候选列表、附带的结构化参数。这样后面无论哪个模型来处理都不会被渠道差异干扰。接入层还要做一件重要的事工具注册。智能体要能调用外部的API、数据库查询、计算器、搜索服务不可能在代码里写死每个工具的调用方式。我们实现了一个工具仓库每个工具用OpenAPI风格的描述文件注册声明它接受什么参数、返回什么结构、需要什么权限级别。模型看到的是工具列表和描述编排层看到的是可执行的函数。这一层的核心价值就是把模型自由和工具边界隔开。2.2 规划层任务拆解与路由决策规划层是我花时间最多的地方。用户的请求往往不是一个单一动作。比如用户问帮我对比一下这两个供应商的报价然后生成一份采购建议这句话背后至少包含三个子任务解析报价单、做数据对比、生成建议文案。如果没有任务拆解模型很容易只做最后一步丢掉前面两个关键环节。规划层的执行顺序是这样的先用路由模型做意图分类和复杂度评估判断请求属于哪个业务领域、需要哪类能力然后基于预定义的任务模板把大请求拆成多个原子任务最后根据每个原子任务的目标决定调用哪个模型、执行哪个工具。这里有个细节我特别想强调任务拆解绝不能完全交给模型自由发挥。我们做了可配置的DAG模板把常见业务流程预定义好模型只是在模板里做参数填充和顺序微调。为什么这么做因为完全自由的任务规划在真实业务里太容易失控——模型可能漏掉关键校验步骤也可能把顺序搞反比如先调用工具再鉴权。预定义模板相当于给模型画了一条轨道既保留了灵活性又限制了破坏力。2.3 执行层模型调工具而不是模型写代码执行层的职责很纯粹真正把规划层拆出来的任务一个个执行掉并且校验执行结果。很多人在这一层容易走进一个误区让模型直接生成代码来解决工具调用问题。比如模型说我用Python字符串处理一下这个JSON再提取字段这在测试环境没问题一上生产就是定时炸弹——模型生成的代码可能有漏洞可能引入不安全的库而且你无法审计它到底干了什么。我们的执行层遵循一个原则模型只做参数映射和结果解释工具调用本身由确定的代码完成。也就是说模型的任务是根据用户意图把工具函数所需的参数从上下文中抽取出来然后编排层调用真实的、经过测试的代码去执行。模型给的是意图和参数而不是命令和脚本。实测下来这个思路让工具调用的失败率降低了70%以上因为代码路径是确定的可变的部分只在参数层面。执行层还要记录每一次工具调用的输入输出方便后面做审计和回放。这个我在安全策略编排部分再展开。2.4 记忆与自检层让体系具备后悔能力四层架构里记忆与自检层最容易被人当成附加功能但我认为它是决定智能体体验上限的一层。记忆分为两块。短期记忆负责当前会话的上下文包括用户刚才说了什么、模型已经执行了哪些步骤、得到了哪些中间结果。长期记忆则负责跨会话的信息沉淀比如用户偏好的文档格式、历史订单的常用条款、之前拒绝过的风险操作。我们用的是向量数据库做长期记忆的检索候选记忆和当前请求做相似度匹配后注入上下文。这里最需要注意的是记忆注入的不喧宾夺主——记忆只是参考不能覆盖用户当前明确的意图否则就会出现用户明明说了这次换成邮件模板系统还沿用上次的PDF模板这种低级错误。自检层是我特别自豪的设计。每一次任务完成后系统不会直接把结果返回给用户而是先让质检模型走一遍复盘检查输出格式是否符合预期、关键数据是否有来源支撑、是否出现自相矛盾、是否踩了安全红线。如果质检不过系统会触发一轮纠错回到出错环节调整参数重新执行或者换一个模型生成。这个机制相当于给系统装了一个后悔按钮让它在把错误结果交给用户之前先自己犯一遍错并修正。实测下来自检层对质量的提升非常明显。尤其是在多步工具调用场景里没有自检时经常出现前面步骤对了、后面步骤错了的中间态错误有了自检之后整体任务成功率提升了大概20个百分点。3. 安全策略编排把权限、审计、防幻觉做进调用链安全这件事在传统架构里往往是事后补救但在智能体架构里它必须成为调用链的一部分。为什么因为智能体的行为路径是动态的你没法用静态的规则穷举所有可能的调用组合。安全策略必须跟着每一次请求实时编排。3.1 工具白名单与最小权限原则第一道防线是工具白名单。我们这个体系里智能体能用的每一个工具都在接入层注册过并且明确标注了权限等级。模型看到的工具列表不是全量而是根据当前用户的身份过滤后的子集。一个普通员工发起请求他对应的工具列表里就不可能出现删除数据库记录这种操作。这里有个容易忽略的点工具级别的白名单还不够必须要做到参数级别的校验。比如查询订单这个工具普通用户可以传自己的订单号但不允许传全部订单这种范围参数。我们在执行层加了一个参数校验组件在每个工具调用之前检查参数是否落在当前用户的权限范围内。这个设计一开始被团队嫌麻烦后来一次安全事故排查里发现正是这道参数校验拦住了一个越权查询的漏洞大家才意识到这是刚需。3.2 敏感操作的二次确认与分级审批第二道防线是敏感操作分级。不是所有操作都需要走审批但发送外部邮件修改生产配置删除数据批量导出用户信息这类高风险操作必须进入二次确认流程。我们实现了一个简单的分级机制低风险操作直接执行中风险操作返回结果前需要用户输入确认执行高风险操作则直接转人工审批智能体只能生成草稿不能直接提交。这套机制看起来简单但它防止了智能体最常见的失控方式——用户问了一个模糊问题智能体自动执行了一连串不可逆操作。那些LLM造成的越权事故本质不是模型有恶意而是编排层没有默认给敏感性排序。3.3 防幻觉的三道闸门幻觉是智能体架构里最让人头疼的问题尤其当模型需要调用外部数据时它可能把编造的内容包装成查到的结果。我们的防幻觉策略是三道闸门第一道路由侧。请求进来时如果涉及事实性查询查询订单、查库存、查政策强制走带工具调用的链路禁止模型凭空回答。这道闸门在规划层实现缺了它后面做得再好都拦不住生成侧的幻觉。第二道质检侧。模型生成回答后质检模型会做事实一致性校验把回答里出现的具体数字、日期、姓名等实体与工具调用返回的真实数据进行比对不一致就触发纠错重跑。第三道用户侧。即使前面两道都没拦住最终返回给用户的内容里凡涉及关键结论我们强制附带来源引用。用户可以点开引用核实数据出处。这既是对用户负责也是倒逼模型在生成时不敢随便编。3.4 全链路审计与回放最后一道安全能力是审计。每一个请求从进入接入层开始会生成一个全局唯一的request_id这个ID贯穿意图识别、任务拆解、模型调用、工具调用、质检判定、最终返回。所有环节的日志都以request_id为索引存储。这意味着什么一旦线上出了问题或者用户投诉某个回答有问题我们可以完整回放这个请求的心路历程模型当时看到了什么、为什么决定调用这个工具、工具返回了什么、质检为什么放行了。这种可回放性在传统软件开发里是基本要求但在智能体架构里反而经常被忽略。没有可回放性AI应用出了安全事故就只能是排查靠猜、修复靠试这是绝对不能接受的。安全控制点所在层核心机制拦截目标工具白名单接入层按身份过滤工具列表未授权能力调用参数级校验执行层校验工具参数范围越权数据访问敏感操作分级执行层二次确认/人工审批不可逆高风险操作事实一致性校验自检层比对生成内容与真实数据模型幻觉输出来源引用接入层出口关键结论附带可查来源不可信回答全链路审计全部层request_id贯穿日志事后追溯与复盘4. 落地部署中的五个实测问题与排查链路这套体系写出来很理想但真实落地过程中踩过的坑比方案本身更有参考价值。我挑五个典型的实测问题把完整的排查链路写出来方便你对照自己的场景。4.1 现象多个模型都答得不错编排后效果反而变差上线初期我们遇到一个很奇怪的现象单个模型在评测集上表现都不错但走完整个编排链路之后输出质量明显下降甚至出现答非所问。排查链路是从路由模型开始的。结果发现路由模型在传递上下文时会把原始请求之外的一些系统提示语和工具描述也一起传给下游模型。多个模型拼装提示词时由于各自的模板风格不同出现了指令冲突。比如路由模型要求用简洁语气回答而主力模型自己的系统提示是输出详细的分析报告两者一叠加主力模型就会处于一种不知道听谁的状态输出的内容一会儿简洁一会儿啰嗦非常不稳定。根因找到了解决方案是统一提示词协议所有模型共享同一套指令层级约定系统级指令、业务级指令、用户级指令的优先级顺序。口号是你只需要关注你的角色全局指令由编排层负责。这个修复上线后效果立即回到单测水平甚至因为上下文更精简了推理速度还快了一点。4.2 现象路由模型把小问题路由给了重型模型这个问题的直接后果就是成本飙升。排查链路里我第一时间看了路由日志发现大量简单请求比如今天天气怎么样帮我算一下24×17被路由模型分配给了最大的那个主力模型处理。根因不是路由模型笨而是路由模型的分类阈值设置得太保守。它对意图判断的低置信度区间里默认策略是宁大勿小——不确定就丢给最强的模型保证质量优先。但对简单任务来说这种兜底没有任何意义杀鸡用了牛刀。修复方式是两条腿走路。一是调阈值当分类置信度低于60%时先降级给中等规模模型尝试而不是直接上最强模型。二是加了一个复杂度预筛在路由之前先用规则和关键词判断请求复杂度明显简单的独立计算任务直接走轻量模型通道不进路由。调整后整体推理成本下降约30%P95延迟也缩短了将近一半。4.3 现象安全模块在质检时被大模型的输出说服这个坑是我最没想到的。合规审核小模型在一段时间内出现了漏检率上升尤其是对大模型生成的流畅文本几乎不拦截。排查日志发现合规模型给这些文本打的违规置信度都非常低。后来我们做了一个对照实验同一段违规文本由人工改写得更自然流畅一些之后送给合规模型拦截率明显下降。这说明合规模型被文本的表面流畅性说服了——大模型生成的文本语法完整、逻辑连贯反而让分类器放松了警惕。这本质上是一种对抗性鲁棒性问题。解决方案有三个层次。第一在合规模型的训练数据里加入大模型生成的对抗样本让它学会关注语义而非表面流畅度。第二设置双人复核机制合规模型的小模型做初筛如果是大模型生成的高质量文本额外送一个不同系列的模型做交叉复核避免同一家模型互相包庇。第三对低置信度但高风险的文本类型强制人工抽检。这套组合下来漏检率回到了可控范围。4.4 现象并发高峰时工具调用超时蔓延智能体架构里的链路比传统API要长得多一次复杂任务可能要串行调用三到五个工具。当并发量上来任何一个环节变慢都会导致整体超时而且会像交通拥堵一样向后蔓延。排查链路里我先用全链路追踪工具把每个环节的耗时拉出来。发现最大的瓶颈不在模型推理而在外部服务响应——尤其是数据库查询和第三方API在并发冲击下响应时间直接翻倍。模型推理的时间是相对固定的外部服务才是不确定因素。修复方案是三层降级策略。第一层是超时熔断给每个工具调用设置硬超时超过500ms直接中断并返回暂时不可用而不是无限等待。第二层是结果缓存对于查询类工具同一参数组合的结果缓存5分钟极大地减轻了重复请求对下游的压力。第三层是异步化不依赖先后顺序的工具调用改为并行整体耗时从串行的累加变成并行的最大值。这三招落地后P95延迟从原来的6秒降到了2秒左右。4.5 现象长短记忆冲突导致用户困惑记忆层上线一段时间后有用户反馈明明上次说了要简体中文这次回复还是用了繁体。排查发现长期记忆里确实存了用户偏好简体中文的向量但当前会话的短期记忆里有一条不太起眼的记录——用户在这轮对话中说了一句不过繁体也可以接受。问题就出在记忆的优先级设计上。我们当时的策略是长期记忆和短期记忆混合注入没有明确优先级模型根据上下文的相关性自己判断结果它被最近出现的信息带偏了。修复方式很直接给记忆加时间权重和身份权重。短期记忆中距离当前轮次越近的内容权重越高长期记忆中与用户身份绑定的偏好权重略高于短期记忆中非明确指令的内容。另外加了一条硬规则当短期记忆中出现用户明确改变偏好的表述时立即覆盖长期记忆中的旧偏好并写入新的长期记忆。这套覆盖-更新机制上线后这类冲突问题基本绝迹。这五个问题的共性很明确智能体架构的坑绝大多数不是模型能力问题而是编排逻辑、上下文管理、降级策略这些工程细节问题。模型本身的进步是线性的而编排层的完善往往能带来数量级的体验提升。5. 从55873到更多这套体系带来的实际变化说点具体的。这套体系上线三个月后我统计了一组内部数据复杂任务的端到端成功率从最初的62%提升到了83%单次请求的平均推理成本下降了约35%安全模块累计拦截了大小违规操作上千次其中包含多起如果放任下去会直接影响业务数据的风险操作。这些数字谈不上惊艳但在稳定性和可控性上的提升是实打实的。从我个人的实操体会来说搭这套体系最大的收获不是把多个模型拼在了一起而是意识到一个朴素的道理AI应用的天花板不在模型在编排。模型的能力是底座但决定产品体验的是任务拆解是否合理、路由决策是否聪明、记忆管理是否有序、安全策略是否兜得住。最后分享一个小技巧。在配置路由模型时不要太追求一次路由就完全正确。给路由加一个允许修正的机制当下游模型发现输入和自身擅长领域不匹配时允许它回抛给路由重新分配。这样等于给路由加了一个反馈回路比单纯调阈值要有效得多。下一篇我会重点写执行层里工具调用的协议设计细节包括函数描述的编写规范、参数抽取的策略以及错误重试的最佳实践。如果你在那方面有踩坑经验欢迎一起交流。
