1. 55873生态的构建动机为什么是613而不是一个巨型模型先交代背景。今年我在做企业级AI中台的时候遇到一个非常现实的问题单靠一个大模型根本没法覆盖所有场景。对话、代码生成、文本分类、结构化数据抽取、多模态内容理解每个场景对模型能力的要求都不一样如果全部塞给同一个模型要么能力过剩浪费算力要么能力不足导致效果拉胯。更麻烦的是不同业务线对数据隔离、响应时延、可解释性的要求差异极大一个模型没法同时满足。所以就有了613这套混合模型矩阵。当时我们内部定的代号叫55873生态含义是5个核心业务域、5种主要模态、8类高频任务、7条部署环境、3级安全等级的映射关系而613则是这套生态里具体的模型组合策略6个基础能力模型、1个综合调度主模型、3个专用强化模型。这个组合不是拍脑袋定的是从业务需求频率统计和算力成本约束里倒推出来的结果。先说结论混合模型架构的价值不在于模型多而在于路由准。如果只是堆了一堆模型却没有一套好的调度机制那跟直接调一个API没什么区别反而徒增运维成本。55873生态里真正核心的不是那10个模型而是模型之上那一层智能体编排层。模型负责会做编排层负责知道什么时候该让谁做这两件事必须分开。这篇文章我会从三个维度展开模型矩阵的设计思路、四层智能体架构的具体拆解、以及安全策略编排这块容易被大多数人忽略的硬骨头。最后再聊几个我们实际踩坑后的经验包括模型路由的缓存策略、智能体并发下的状态管理以及安全过滤对性能的影响曲线。2. 613模型矩阵的选型逻辑与路由策略2.1 六个基础能力模型按任务形态切分而不是按参数量切分六个基础模型当时选型的核心原则是按任务形态切分不是按参数量大小切分。参数量只能说明模型的容量上限但实际工程里更关心的是单位算力下的有效产出。我们最终选了三个开源底座模型和三个商业API模型具体分配如下文本生成底座负责长文写作、摘要、翻译、改写类任务追求的是语义连贯性和指令跟随能力输出token成本按量计价。代码理解与生成底座负责代码补全、解释、单元测试生成、仓库级代码检索接入了仓库索引工具支持跨文件上下文。对话推理底座负责多轮对话、意图识别、槽位填充优化的重心是上下文窗口利用率和回复时延。结构化抽取底座负责信息抽取、字段映射、表格理解输出强约束为JSON Schema不允许自由发挥。情感与风格分析底座负责情感极性、文本分类、风格迁移精度要求高被设计成批量离线跑不参与实时链路。多模态理解底座负责图像描述、OCR、文档版面分析、图表解读是六个模型中唯一带视觉编码器的。为什么特意分出结构化抽取这个看似小众的底座因为企业内部有大量把非结构化文本转成结构化数据的场景比如合同条款抽取、工单信息整理、简历解析。通用大模型做这个事能做但经常出现字段遗漏、格式跑偏的问题。我们单独拿一个模型配合强约束解码和字段级校验器把准确率从中等的85%左右拉到99%以上这笔账是划算的。2.2 综合调度主模型不是最强的模型而是最会分配的模型1号主模型在我们的设计里承担的是总控职责。为了说清楚它的定位我需要先纠正一个常见误解很多人以为调度主模型应该是能力最强的那个模型什么都能干别的不行它兜底。我们实践下来的结论正相反——主模型应该是参数量适中、指令跟随极稳、延迟最低的那个因为它要高频地被调用如果每一步调度都让大模型思考半天整个链路的延迟就废了。我们用的方案是基于中等规模底座微调出来的调度模型专门训练了三类能力第一类是指令路由即判断用户当前请求属于哪个任务域应该分发到哪个基础模型或专用模型。第二类是任务拆解复杂请求到来时不直接回答而是拆成子任务清单再决定哪些子任务可以并行、哪些必须串行。第三类是结果仲裁同一个问题可能多个模型给出结果调度模型要能综合判断采纳哪个结果或做融合。有个印象很深的例子用户问这份合同里甲方的违约责任是什么并且在第三条款里找有没有违约金上限的表述。这个请求横跨了文档理解、结构化抽取、语义检索三个能力域。如果让一个模型硬处理它需要一次性把整份合同塞进上下文不仅慢还可能漏。调度主模型的处理方式是先路由到文档版面解析再路由到结构化抽取最后把抽取结果和用户问题做语义匹配整个过程用时降了一半。2.3 三个专用强化模型在关键隘口上拼命加码3个专用强化模型各管一个高价值高难度的隘口第一个是复杂推理强化模型。针对数学证明、逻辑推理、多条件规划类任务用思维链数据做了专门的强化训练。这个模型平时不参与实时请求只有当调度模型检测到请求包含推导证明规划等信号时才触发因为它单次推理耗时较长不适合做通用流量。第二个是安全审查专用模型。这个模型是用大量对抗样本训练出来的专门负责检测输入输出中的异常模式比如提示注入、恶意指令、越权请求、数据泄露信号。把它单独拎出来的原因是通用模型的自审查能力不可靠——模型在生成内容的同时还要审查自己是否违规这种既当运动员又当裁判的做法在压力场景下会失效。独立的审查模型没有生成压力只做二分类加标注准确率反而高得多。第三个是领域知识增强模型。基于企业的私有知识库语料做了持续预训练和检索增强专门负责回答需要引用具体业务条款、历史案例的问题。这个模型回答每条结论都会附带知识来源编号方便审计回溯。为什么单独做而不是把私有知识直接塞进通用模型因为企业知识是动态更新的单独做一个轻量模型做检索增强更新成本远低于重训大模型。2.4 模型路由的判定链路与实际效果模型路由是整个613能跑起来的关键机制。我们采用三级判定链路第一级规则前置用轻量正则和关键词表做快速分流命中率高且几乎不消耗算力第二级调度模型判定处理规则无法覆盖的长尾表达第三级兜底策略如果调度模型的置信度低于阈值默认走对话推理底座避免因为分类错误导致请求失败。实现上用的是一个基于语义向量相似度和意图分类器组合的机制。意图分类器负责粗粒度划分大概20个意图类别语义向量负责细粒度匹配具体到模型能力和任务模板。路由判定的平均耗时我们控制在30毫秒以内在整体响应时间里占比很低。这里必须说一个实际工程里的权衡模型路由的粒度到底该多细。太粗了所有请求都涌到几个模型上能力优势发挥不出来太细了类别膨胀分类准确率下降调度模型本身也容易过拟合。我们迭代到第4版时确定了原则——路由粒度只到任务域级别不到用户意图级别。比如合同条款抽取是一个任务域但跟用户闲聊合同相关知识是另一个任务域前者路由到结构化抽取后者路由到对话推理而不再往下细分违约金条款抽取管辖条款抽取这种过细的类别。3. 四层智能体架构的逐层拆解从感知到执行的协作机制3.1 第一层感知接入层解决输入不标准的问题智能体的第一层要处理的是所有乱七八糟的输入。用户可能发来一段文字、一张截图、一个语音转写出来的文本、一个含有表格的PDF甚至是一段带有错别字的口语化描述。感知接入层要做的不是直接把这些扔给模型而是先完成输入标准化。我们在这层做了三件事。第一件事是多格式解析PDF、Word、图片、语音走对应的解析组件统一转成带元数据的文本块。第二件事是上下文组装把多轮对话的历史、当前请求、关联知识库结果按特定模板拼装成模型输入。第三件事是隐私标记检测输入中是否包含手机号、身份证号、银行卡号等敏感字段命中的字段直接脱敏后再进入后续链路原始值只在必要时透传到特定下游。这层容易被忽视但极其重要的一个点在于感知接入层是所有安全策略的第一道闸口。很多提示注入攻击就是从输入里带入恶意指令的如果不在这层做基础过滤后面模型再强也会被攻击。我们的做法是在接入层内置了一个轻量级的敏感模式扫描器它能识别忽略之前的所有指令你现在是另一个角色等常见注入句式命中后直接拦截并标记异常而不让这类输入进入模型推理环节。3.2 第二层决策编排层四层架构里的大脑第二层是整个智能体架构里最复杂、也是我们花时间最多的一层。决策编排层承载了两个核心职责一是将复杂任务拆解成可执行的子任务序列二是为每个子任务挑选合适的执行体。任务拆解不是一个纯模型行为它需要和业务规则强绑定。我们的做法是规则模板动态规划双轨制对于高频出现的固定流程比如查询订单状态走预置的流程模板直接按模板顺序执行对于没有匹配到模板的新场景才由调度主模型做实时拆解。这个设计极大降低了调度的不确定性和时延也让业务团队可以通过配置模板来干预智能体行为不需要改代码。在执行体选择上我们维护了一个执行体注册表里面登记了每个执行体的能力描述、依赖资源、最大并发数、平均延迟。调度模型在决策时会参考这些元数据进行匹配——不是只看能不能做还要看现在做会不会超时是否与其他正在执行的子任务冲突。比如一个需要调用外部API的子任务如果外部API当前限流调度就不会选它而是走降级方案。决策编排层还有一项容易被忽略的工作依赖关系处理。子任务之间有并行、串行、条件分支三种关系。我们用一个轻量的有向无环图来描述任务依赖每次执行前先做图解析再把无依赖的子任务打包并发执行。这个机制让整体响应时间从原始的串行累加降到了最长路径的水平效果立竿见影。3.3 第三层执行工具层把模型能力变成可用服务第三层是执行工具层它把模型输出的决策真正落地成业务动作。我们可以把它理解成智能体的手——模型负责想工具层负责做。工具层里包含的能力分三类内置工具、外部API、知识检索组件。内置工具包括文本处理、数据格式转换、定时任务触发等外部API通过统一网关接入每个API都有超时、重试、熔断配置知识检索组件则对接企业知识库支持向量检索加关键词检索混合召回。在这一层我们踩过的最大一个坑是工具参数校验缺失。早期版本里模型生成的工具调用参数直接透传给下游API结果出现过大意地把字符串塞进数字字段、把根路径当成相对路径调用等事故。后来我们在工具层增加了参数Schema校验每个工具都定义自己接受的参数类型、范围、必填项模型输出先过校验再执行不合规的直接打回重新生成。这个改动让工具调用的成功率从88%提升到了97%而且排查问题的难度也降低了——以前报错根本不知道是模型生成错了还是API执行错了现在参数校验器会明确告诉我们是哪一步出的问题。3.4 第四层记忆与状态层让智能体记住而不是失忆第四层是记忆与状态层。智能体如果没有状态管理就像一个每次见面都把你当陌生人的客服体验极差。但状态管理如果做重了又会成为性能瓶颈所以我们采用的是三级记忆结构短期记忆放在会话级别用Redis保存TTL设为30分钟存储最近几轮对话的关键信息包括用户意图、已确认参数、当前任务进度。中期记忆放在用户维度记录用户的历史偏好和常用上下文比如这个用户习惯用表格形式看数据他上次要求过缩写名词要带全称。长期记忆则落到向量数据库里存储的是从历史对话中抽取出来的事实性知识支持相似语义检索。状态管理上我们为每个用户会话维护了一个状态快照里面记录了当前所处任务阶段、已完成的子任务、尚未收齐的参数。一旦某个子任务执行失败需要重试智能体可以根据状态快照判断是从头再来还是从失败点续跑而不是让用户把需求再复述一遍。还有一个细节值得提记忆写入的时机。最开始我们是一轮对话结束就立即写记忆后来发现很多中间产物是噪声写多了反而污染检索结果。改成了关键节点记忆策略——只在任务完成、用户确认、参数变更三个节点写入记忆中间过程的临时信息一律不落库。这让记忆质量提升了也让存储成本降了下来。4. 安全策略编排被多数架构师低估的第五层4.1 安全设计的起点智能体比普通API更脆弱传统API网关的安全策略主要管传输加密、接口鉴权、限流熔断这套东西对智能体系统来说远远不够。为什么因为智能体系统的特点是自由度高、变更频繁、模型不可完全控。模型是概率系统同样的输入可能产生不同的输出工具是外部依赖其行为不完全在掌控范围内用户输入是开放式的攻击面非常大。我们在设计安全策略编排时明确了一个原则安全不只是加一个过滤词表而是一套贯穿全链路的编排机制。它包含三层输入侧的安全检查、行为侧的权限控制、输出侧的合规审查。这三层各自独立部署又由统一的策略引擎串联。4.2 输入侧的语义级安全检查不再依赖关键词黑名单很多团队做输入过滤还在用关键词黑名单这已经被证明是低效的做法。攻击者可以轻易通过改写、编码变换、大小写混合来绕过关键词匹配。我们改用语义级检查——所有进入智能体的输入都要过一遍安全审查模型就是前面说的3个专用模型中那个安全审查专用模型它从语义层面判断输入是否包含恶意指令、是否存在诱导模型输出违规内容的行为、是否试图通过构造特殊上下文来劫持对话目标。这套方案上线后我们做过一次对抗性测试让安全团队模拟了300条攻击样本包含直接注入、间接注入、多轮诱导、角色扮演伪装、编码混淆等类型。关键词黑名单方案漏掉了大约30%语义级检查方案只漏掉了约3%漏掉的还都是无害的边界情况。当然语义级检查也有代价——每次输入检查增加了约250毫秒的延迟但我们最终接受这个成本安全不能省。4.3 行为侧的权限控制给智能体的每个动作上锁行为侧权限控制解决的是智能体被授权做什么的问题。这部分设计逻辑与企业内部的权限体系类似但因为执行者是AI约束方式有了很大区别。第一层是工具权限映射。每个工具调用前都要查权限表确认当前用户是否拥有该工具的调用权限。比如删除工单这个工具只有管理员角色的用户才能触发普通用户即便在对话里表达了删除意图智能体也会拒绝执行并解释原因。第二层是数据域隔离。不同业务线的数据分域存储智能体在检索知识库时权限边界会作为过滤条件注入检索语句。这层实现有些绕因为模型的检索是语义相似度匹配单纯的SQL条件限制无法直接生效我们采用的是为企业知识库打标签的办法——每个知识文档打好业务域标签检索时先根据用户归属过滤标签再做向量召回。第三层是敏感操作二次确认。对于涉及删除、修改、发送外部信息、创建订单这类操作智能体执行前必须先回传给用户等待确认。这个机制看起来简单但能挡住一大类由于模型幻觉导致的事故。我们曾遇到过智能体在没向用户确认的情况下自动把一个草稿邮件发出去了。加了二次确认后这类事故直接归零。4.4 输出侧的合规审查在结果返回前做最后一道把关输出合规审查是很多人忽略的一环。模型生成的内容本来就有不确定性即使输入没问题、行为也合规输出仍然可能包含冲突的表述、未经核实的事实、或者对本企业不利的措辞。我们做了三重输出检查第一重是格式校验确认输出的JSON结构完整字段类型正确没有截断。第二重是内容安全复核用安全审查模型重新过一遍生成结果检测是否存在泄露敏感信息、包含不当内容、给出违规建议的迹象。第三重是事实一致性校验如果输出中引用了文档原文或数据系统会用检索结果反向比对发现引用不存在或数据对不上时自动在回复中标注该结论未能验证来源。这趟流程跑下来确实多花了一些时间但换来的是智能体输出的可信度。内部业务方曾反馈过一个问题我们不担心AI回答不了问题担心的是它一本正经地胡说八道我们还发现不了。有了事实一致性校验这个问题基本解决了。输出审查现在平均增加约400毫秒的延迟但对于对准确性要求高的业务场景这些延迟完全可接受。4.5 策略编排的落地形态策略即配置配置即代码安全策略编排最后要落地成一套可以灵活修改、随时启停的机制而不是写死在代码里。我们采用了策略引擎规则DSL的方式每一条安全策略都是一个独立的配置文件里面定义了触发条件、执行动作、降级方案。新增一个安全策略不需要改代码发布只需要增加一条配置记录策略引擎会在下一次请求时自动加载。举个例子某天我们发现了一种新型的提示注入模式安全团队在策略平台里直接添加了一条规则五分钟后全网生效不需要等版本发布。相比之下传统的方式最少也要走半天的开发测试发布流程面对快速演变的攻击手段是完全不够用的。策略编排还保证了安全策略本身的可用性。安全系统不能成为单点故障——如果安全审查服务挂了我们的降级策略是限流放行异步补审也就是临时允许请求通过但记录日志同时报警给值班同学等审查服务恢复后再对日志做批量补审。这个降级方案在可用性和安全性之间取了一个务实的平衡。5. 部署实战性能调优、故障复盘与参数配置参考5.1 模型路由缓存策略把重复计算变成命中查询模型路由判断虽然平均只有30毫秒但在高并发下也是一笔不小的开销。我们做了两级缓存来优化第一级是精确匹配缓存相同用户在同一会话中提出相同问题时路由结果直接复用这层缓存命中率大概35%第二级是语义近似缓存相当于缓存同一类问题的路由结果而不是完全相同的问题。实现上第二级缓存是核心难点。我们先把用户请求embedding化然后用向量数据库做相似检索相似度超过0.92的请求直接复用路由结果不再走调度模型。这套方案上线后路由模块的整体耗时下降了60%调度主模型的调用量也减少了差不多一半。当然缓存需要设TTL因为业务规则和模型部署状态会变化我们的默认策略是缓存五分钟。5.2 智能体并发下的状态隔离一个极易踩坑的隐性Bug多用户并发访问智能体时最大的隐形杀手是状态串号。症状是用户A的会话上下文突然出现了用户B的信息或者两个用户共享了同一个任务进度。这种Bug极其隐蔽因为不是每次都会复现只在并发峰值时概率性出现。我们复盘后的根因是状态存储层用了共享的变量容器会话ID的传递链路中有一个中间环节丢失了上下文。具体来说异步任务回调时没有把会话ID透传下去导致回调结果写入了当前线程持有的默认上下文。修复方案是重构成全链路ID传递——从请求入口生成唯一的trace_id所有子任务、回调、工具调用都携带这个trace_id状态读写全部以trace_id为key。修复后这类串号问题彻底消失。所以强烈建议任何做多智能体并发系统的团队从第一天起就建立全链路追踪机制别等出了事故再补。5.3 安全审查的耗时陷阱与异步化改造早期实现里输入安全审查和输出合规审查都是同步阻塞在请求路径里的。一个请求最坏情况下要多吃两次模型推理的延迟输入一次、输出一次加上调度模型的推理整条链路可能超过5秒这个体验对实时对话来说不可接受。后来我们做了分层异步化改造。输入侧的安全审查保持同步因为这是不可让渡的安全底线输出侧的合规审查改成同步快速筛查异步深度复核两级方案。快速筛查只做规则级检查格式、字段、关键词信号耗时控制在50毫秒以内深度复核走语义级模型审查异步进行复核结果通过webhook推送如果有问题再通知客户端撤回或标记。这样做把同步链路的耗时压缩到了可接受范围同时没有牺牲审查深度。5.4 关键参数配置参考最后分享一些我们稳定运行的配置参数仅供参考具体数值要根据自己的场景调整配置项参数值说明路由判断超时200ms超过则降级为默认路由调度主模型最大推理token1024调度任务不需要长输出重点在速度输入安全审查超时500ms超过则拒绝请求并报异常输出快速筛查超时50ms只跑规则级检查知识检索召回数量top 5高于5会稀释注意力会话短期记忆TTL30分钟无操作后过期工具调用最大重试次数2次两次失败则切换到备用工具外部API熔断阈值5秒超时/3次连续失败满足任一条件即熔断降级策略限流放行异步补审安全服务异常时启用模型路由缓存TTL5分钟业务规则变更频繁时调短参数调整的总体原则是优先保证可用性其次追求精准度最后才是成本。安全相关的超时参数宁可设置得更保守也不能让一次恶意请求蒙混过关。6. 从架构到落地的几点个人体会这套613混合模型四层智能体架构安全策略编排的方案前前后后迭代了五个版本才稳定下来。现在回头看看几个当初坚持下来的设计决策是真正起到了决定性作用的。第一个是坚持把安全策略编排独立成层。最初团队里也有人觉得模型自己会拒绝违规请求不需要额外一层但实际对抗测试和线上数据都证明模型的自审查在复杂攻击面前会有明显的遗漏率独立一层语义级审查是必要的。第二个是坚持路由粒度到任务域而不是用户意图。这避免了大量模型改造成本也让路由模块保持简单可靠。很多团队容易陷入分类越细越好的误区但分类越细样本就越稀疏效果就越不稳定边际收益反而是负的。第三个是坚持能异步的绝不同步。这个原则不仅救了延迟指标还让整个系统的可观测性上了一个台阶。因为异步任务天然需要任务ID和状态记录这倒逼我们建立了完整的追踪体系后面排查问题方便太多了。最后再说一句关于智能体安全的心态问题。很多人觉得安全是上线前一次性做完的事其实完全不是。攻击手段在演化业务场景在扩展模型版本在更新安全策略必须持续迭代。我们现在的节奏是每周都要review一次安全日志每月做一次攻击模拟演练安全策略的更新频率几乎和业务功能的更新频率一样高。这套机制跑起来之后遇到新出现的攻击手法也不慌了——因为策略引擎支持热更新五分钟内就能把新的防护规则推到全量环境生效。
6+1+3混合模型与四层智能体架构：企业级AI中台的设计实践
1. 55873生态的构建动机为什么是613而不是一个巨型模型先交代背景。今年我在做企业级AI中台的时候遇到一个非常现实的问题单靠一个大模型根本没法覆盖所有场景。对话、代码生成、文本分类、结构化数据抽取、多模态内容理解每个场景对模型能力的要求都不一样如果全部塞给同一个模型要么能力过剩浪费算力要么能力不足导致效果拉胯。更麻烦的是不同业务线对数据隔离、响应时延、可解释性的要求差异极大一个模型没法同时满足。所以就有了613这套混合模型矩阵。当时我们内部定的代号叫55873生态含义是5个核心业务域、5种主要模态、8类高频任务、7条部署环境、3级安全等级的映射关系而613则是这套生态里具体的模型组合策略6个基础能力模型、1个综合调度主模型、3个专用强化模型。这个组合不是拍脑袋定的是从业务需求频率统计和算力成本约束里倒推出来的结果。先说结论混合模型架构的价值不在于模型多而在于路由准。如果只是堆了一堆模型却没有一套好的调度机制那跟直接调一个API没什么区别反而徒增运维成本。55873生态里真正核心的不是那10个模型而是模型之上那一层智能体编排层。模型负责会做编排层负责知道什么时候该让谁做这两件事必须分开。这篇文章我会从三个维度展开模型矩阵的设计思路、四层智能体架构的具体拆解、以及安全策略编排这块容易被大多数人忽略的硬骨头。最后再聊几个我们实际踩坑后的经验包括模型路由的缓存策略、智能体并发下的状态管理以及安全过滤对性能的影响曲线。2. 613模型矩阵的选型逻辑与路由策略2.1 六个基础能力模型按任务形态切分而不是按参数量切分六个基础模型当时选型的核心原则是按任务形态切分不是按参数量大小切分。参数量只能说明模型的容量上限但实际工程里更关心的是单位算力下的有效产出。我们最终选了三个开源底座模型和三个商业API模型具体分配如下文本生成底座负责长文写作、摘要、翻译、改写类任务追求的是语义连贯性和指令跟随能力输出token成本按量计价。代码理解与生成底座负责代码补全、解释、单元测试生成、仓库级代码检索接入了仓库索引工具支持跨文件上下文。对话推理底座负责多轮对话、意图识别、槽位填充优化的重心是上下文窗口利用率和回复时延。结构化抽取底座负责信息抽取、字段映射、表格理解输出强约束为JSON Schema不允许自由发挥。情感与风格分析底座负责情感极性、文本分类、风格迁移精度要求高被设计成批量离线跑不参与实时链路。多模态理解底座负责图像描述、OCR、文档版面分析、图表解读是六个模型中唯一带视觉编码器的。为什么特意分出结构化抽取这个看似小众的底座因为企业内部有大量把非结构化文本转成结构化数据的场景比如合同条款抽取、工单信息整理、简历解析。通用大模型做这个事能做但经常出现字段遗漏、格式跑偏的问题。我们单独拿一个模型配合强约束解码和字段级校验器把准确率从中等的85%左右拉到99%以上这笔账是划算的。2.2 综合调度主模型不是最强的模型而是最会分配的模型1号主模型在我们的设计里承担的是总控职责。为了说清楚它的定位我需要先纠正一个常见误解很多人以为调度主模型应该是能力最强的那个模型什么都能干别的不行它兜底。我们实践下来的结论正相反——主模型应该是参数量适中、指令跟随极稳、延迟最低的那个因为它要高频地被调用如果每一步调度都让大模型思考半天整个链路的延迟就废了。我们用的方案是基于中等规模底座微调出来的调度模型专门训练了三类能力第一类是指令路由即判断用户当前请求属于哪个任务域应该分发到哪个基础模型或专用模型。第二类是任务拆解复杂请求到来时不直接回答而是拆成子任务清单再决定哪些子任务可以并行、哪些必须串行。第三类是结果仲裁同一个问题可能多个模型给出结果调度模型要能综合判断采纳哪个结果或做融合。有个印象很深的例子用户问这份合同里甲方的违约责任是什么并且在第三条款里找有没有违约金上限的表述。这个请求横跨了文档理解、结构化抽取、语义检索三个能力域。如果让一个模型硬处理它需要一次性把整份合同塞进上下文不仅慢还可能漏。调度主模型的处理方式是先路由到文档版面解析再路由到结构化抽取最后把抽取结果和用户问题做语义匹配整个过程用时降了一半。2.3 三个专用强化模型在关键隘口上拼命加码3个专用强化模型各管一个高价值高难度的隘口第一个是复杂推理强化模型。针对数学证明、逻辑推理、多条件规划类任务用思维链数据做了专门的强化训练。这个模型平时不参与实时请求只有当调度模型检测到请求包含推导证明规划等信号时才触发因为它单次推理耗时较长不适合做通用流量。第二个是安全审查专用模型。这个模型是用大量对抗样本训练出来的专门负责检测输入输出中的异常模式比如提示注入、恶意指令、越权请求、数据泄露信号。把它单独拎出来的原因是通用模型的自审查能力不可靠——模型在生成内容的同时还要审查自己是否违规这种既当运动员又当裁判的做法在压力场景下会失效。独立的审查模型没有生成压力只做二分类加标注准确率反而高得多。第三个是领域知识增强模型。基于企业的私有知识库语料做了持续预训练和检索增强专门负责回答需要引用具体业务条款、历史案例的问题。这个模型回答每条结论都会附带知识来源编号方便审计回溯。为什么单独做而不是把私有知识直接塞进通用模型因为企业知识是动态更新的单独做一个轻量模型做检索增强更新成本远低于重训大模型。2.4 模型路由的判定链路与实际效果模型路由是整个613能跑起来的关键机制。我们采用三级判定链路第一级规则前置用轻量正则和关键词表做快速分流命中率高且几乎不消耗算力第二级调度模型判定处理规则无法覆盖的长尾表达第三级兜底策略如果调度模型的置信度低于阈值默认走对话推理底座避免因为分类错误导致请求失败。实现上用的是一个基于语义向量相似度和意图分类器组合的机制。意图分类器负责粗粒度划分大概20个意图类别语义向量负责细粒度匹配具体到模型能力和任务模板。路由判定的平均耗时我们控制在30毫秒以内在整体响应时间里占比很低。这里必须说一个实际工程里的权衡模型路由的粒度到底该多细。太粗了所有请求都涌到几个模型上能力优势发挥不出来太细了类别膨胀分类准确率下降调度模型本身也容易过拟合。我们迭代到第4版时确定了原则——路由粒度只到任务域级别不到用户意图级别。比如合同条款抽取是一个任务域但跟用户闲聊合同相关知识是另一个任务域前者路由到结构化抽取后者路由到对话推理而不再往下细分违约金条款抽取管辖条款抽取这种过细的类别。3. 四层智能体架构的逐层拆解从感知到执行的协作机制3.1 第一层感知接入层解决输入不标准的问题智能体的第一层要处理的是所有乱七八糟的输入。用户可能发来一段文字、一张截图、一个语音转写出来的文本、一个含有表格的PDF甚至是一段带有错别字的口语化描述。感知接入层要做的不是直接把这些扔给模型而是先完成输入标准化。我们在这层做了三件事。第一件事是多格式解析PDF、Word、图片、语音走对应的解析组件统一转成带元数据的文本块。第二件事是上下文组装把多轮对话的历史、当前请求、关联知识库结果按特定模板拼装成模型输入。第三件事是隐私标记检测输入中是否包含手机号、身份证号、银行卡号等敏感字段命中的字段直接脱敏后再进入后续链路原始值只在必要时透传到特定下游。这层容易被忽视但极其重要的一个点在于感知接入层是所有安全策略的第一道闸口。很多提示注入攻击就是从输入里带入恶意指令的如果不在这层做基础过滤后面模型再强也会被攻击。我们的做法是在接入层内置了一个轻量级的敏感模式扫描器它能识别忽略之前的所有指令你现在是另一个角色等常见注入句式命中后直接拦截并标记异常而不让这类输入进入模型推理环节。3.2 第二层决策编排层四层架构里的大脑第二层是整个智能体架构里最复杂、也是我们花时间最多的一层。决策编排层承载了两个核心职责一是将复杂任务拆解成可执行的子任务序列二是为每个子任务挑选合适的执行体。任务拆解不是一个纯模型行为它需要和业务规则强绑定。我们的做法是规则模板动态规划双轨制对于高频出现的固定流程比如查询订单状态走预置的流程模板直接按模板顺序执行对于没有匹配到模板的新场景才由调度主模型做实时拆解。这个设计极大降低了调度的不确定性和时延也让业务团队可以通过配置模板来干预智能体行为不需要改代码。在执行体选择上我们维护了一个执行体注册表里面登记了每个执行体的能力描述、依赖资源、最大并发数、平均延迟。调度模型在决策时会参考这些元数据进行匹配——不是只看能不能做还要看现在做会不会超时是否与其他正在执行的子任务冲突。比如一个需要调用外部API的子任务如果外部API当前限流调度就不会选它而是走降级方案。决策编排层还有一项容易被忽略的工作依赖关系处理。子任务之间有并行、串行、条件分支三种关系。我们用一个轻量的有向无环图来描述任务依赖每次执行前先做图解析再把无依赖的子任务打包并发执行。这个机制让整体响应时间从原始的串行累加降到了最长路径的水平效果立竿见影。3.3 第三层执行工具层把模型能力变成可用服务第三层是执行工具层它把模型输出的决策真正落地成业务动作。我们可以把它理解成智能体的手——模型负责想工具层负责做。工具层里包含的能力分三类内置工具、外部API、知识检索组件。内置工具包括文本处理、数据格式转换、定时任务触发等外部API通过统一网关接入每个API都有超时、重试、熔断配置知识检索组件则对接企业知识库支持向量检索加关键词检索混合召回。在这一层我们踩过的最大一个坑是工具参数校验缺失。早期版本里模型生成的工具调用参数直接透传给下游API结果出现过大意地把字符串塞进数字字段、把根路径当成相对路径调用等事故。后来我们在工具层增加了参数Schema校验每个工具都定义自己接受的参数类型、范围、必填项模型输出先过校验再执行不合规的直接打回重新生成。这个改动让工具调用的成功率从88%提升到了97%而且排查问题的难度也降低了——以前报错根本不知道是模型生成错了还是API执行错了现在参数校验器会明确告诉我们是哪一步出的问题。3.4 第四层记忆与状态层让智能体记住而不是失忆第四层是记忆与状态层。智能体如果没有状态管理就像一个每次见面都把你当陌生人的客服体验极差。但状态管理如果做重了又会成为性能瓶颈所以我们采用的是三级记忆结构短期记忆放在会话级别用Redis保存TTL设为30分钟存储最近几轮对话的关键信息包括用户意图、已确认参数、当前任务进度。中期记忆放在用户维度记录用户的历史偏好和常用上下文比如这个用户习惯用表格形式看数据他上次要求过缩写名词要带全称。长期记忆则落到向量数据库里存储的是从历史对话中抽取出来的事实性知识支持相似语义检索。状态管理上我们为每个用户会话维护了一个状态快照里面记录了当前所处任务阶段、已完成的子任务、尚未收齐的参数。一旦某个子任务执行失败需要重试智能体可以根据状态快照判断是从头再来还是从失败点续跑而不是让用户把需求再复述一遍。还有一个细节值得提记忆写入的时机。最开始我们是一轮对话结束就立即写记忆后来发现很多中间产物是噪声写多了反而污染检索结果。改成了关键节点记忆策略——只在任务完成、用户确认、参数变更三个节点写入记忆中间过程的临时信息一律不落库。这让记忆质量提升了也让存储成本降了下来。4. 安全策略编排被多数架构师低估的第五层4.1 安全设计的起点智能体比普通API更脆弱传统API网关的安全策略主要管传输加密、接口鉴权、限流熔断这套东西对智能体系统来说远远不够。为什么因为智能体系统的特点是自由度高、变更频繁、模型不可完全控。模型是概率系统同样的输入可能产生不同的输出工具是外部依赖其行为不完全在掌控范围内用户输入是开放式的攻击面非常大。我们在设计安全策略编排时明确了一个原则安全不只是加一个过滤词表而是一套贯穿全链路的编排机制。它包含三层输入侧的安全检查、行为侧的权限控制、输出侧的合规审查。这三层各自独立部署又由统一的策略引擎串联。4.2 输入侧的语义级安全检查不再依赖关键词黑名单很多团队做输入过滤还在用关键词黑名单这已经被证明是低效的做法。攻击者可以轻易通过改写、编码变换、大小写混合来绕过关键词匹配。我们改用语义级检查——所有进入智能体的输入都要过一遍安全审查模型就是前面说的3个专用模型中那个安全审查专用模型它从语义层面判断输入是否包含恶意指令、是否存在诱导模型输出违规内容的行为、是否试图通过构造特殊上下文来劫持对话目标。这套方案上线后我们做过一次对抗性测试让安全团队模拟了300条攻击样本包含直接注入、间接注入、多轮诱导、角色扮演伪装、编码混淆等类型。关键词黑名单方案漏掉了大约30%语义级检查方案只漏掉了约3%漏掉的还都是无害的边界情况。当然语义级检查也有代价——每次输入检查增加了约250毫秒的延迟但我们最终接受这个成本安全不能省。4.3 行为侧的权限控制给智能体的每个动作上锁行为侧权限控制解决的是智能体被授权做什么的问题。这部分设计逻辑与企业内部的权限体系类似但因为执行者是AI约束方式有了很大区别。第一层是工具权限映射。每个工具调用前都要查权限表确认当前用户是否拥有该工具的调用权限。比如删除工单这个工具只有管理员角色的用户才能触发普通用户即便在对话里表达了删除意图智能体也会拒绝执行并解释原因。第二层是数据域隔离。不同业务线的数据分域存储智能体在检索知识库时权限边界会作为过滤条件注入检索语句。这层实现有些绕因为模型的检索是语义相似度匹配单纯的SQL条件限制无法直接生效我们采用的是为企业知识库打标签的办法——每个知识文档打好业务域标签检索时先根据用户归属过滤标签再做向量召回。第三层是敏感操作二次确认。对于涉及删除、修改、发送外部信息、创建订单这类操作智能体执行前必须先回传给用户等待确认。这个机制看起来简单但能挡住一大类由于模型幻觉导致的事故。我们曾遇到过智能体在没向用户确认的情况下自动把一个草稿邮件发出去了。加了二次确认后这类事故直接归零。4.4 输出侧的合规审查在结果返回前做最后一道把关输出合规审查是很多人忽略的一环。模型生成的内容本来就有不确定性即使输入没问题、行为也合规输出仍然可能包含冲突的表述、未经核实的事实、或者对本企业不利的措辞。我们做了三重输出检查第一重是格式校验确认输出的JSON结构完整字段类型正确没有截断。第二重是内容安全复核用安全审查模型重新过一遍生成结果检测是否存在泄露敏感信息、包含不当内容、给出违规建议的迹象。第三重是事实一致性校验如果输出中引用了文档原文或数据系统会用检索结果反向比对发现引用不存在或数据对不上时自动在回复中标注该结论未能验证来源。这趟流程跑下来确实多花了一些时间但换来的是智能体输出的可信度。内部业务方曾反馈过一个问题我们不担心AI回答不了问题担心的是它一本正经地胡说八道我们还发现不了。有了事实一致性校验这个问题基本解决了。输出审查现在平均增加约400毫秒的延迟但对于对准确性要求高的业务场景这些延迟完全可接受。4.5 策略编排的落地形态策略即配置配置即代码安全策略编排最后要落地成一套可以灵活修改、随时启停的机制而不是写死在代码里。我们采用了策略引擎规则DSL的方式每一条安全策略都是一个独立的配置文件里面定义了触发条件、执行动作、降级方案。新增一个安全策略不需要改代码发布只需要增加一条配置记录策略引擎会在下一次请求时自动加载。举个例子某天我们发现了一种新型的提示注入模式安全团队在策略平台里直接添加了一条规则五分钟后全网生效不需要等版本发布。相比之下传统的方式最少也要走半天的开发测试发布流程面对快速演变的攻击手段是完全不够用的。策略编排还保证了安全策略本身的可用性。安全系统不能成为单点故障——如果安全审查服务挂了我们的降级策略是限流放行异步补审也就是临时允许请求通过但记录日志同时报警给值班同学等审查服务恢复后再对日志做批量补审。这个降级方案在可用性和安全性之间取了一个务实的平衡。5. 部署实战性能调优、故障复盘与参数配置参考5.1 模型路由缓存策略把重复计算变成命中查询模型路由判断虽然平均只有30毫秒但在高并发下也是一笔不小的开销。我们做了两级缓存来优化第一级是精确匹配缓存相同用户在同一会话中提出相同问题时路由结果直接复用这层缓存命中率大概35%第二级是语义近似缓存相当于缓存同一类问题的路由结果而不是完全相同的问题。实现上第二级缓存是核心难点。我们先把用户请求embedding化然后用向量数据库做相似检索相似度超过0.92的请求直接复用路由结果不再走调度模型。这套方案上线后路由模块的整体耗时下降了60%调度主模型的调用量也减少了差不多一半。当然缓存需要设TTL因为业务规则和模型部署状态会变化我们的默认策略是缓存五分钟。5.2 智能体并发下的状态隔离一个极易踩坑的隐性Bug多用户并发访问智能体时最大的隐形杀手是状态串号。症状是用户A的会话上下文突然出现了用户B的信息或者两个用户共享了同一个任务进度。这种Bug极其隐蔽因为不是每次都会复现只在并发峰值时概率性出现。我们复盘后的根因是状态存储层用了共享的变量容器会话ID的传递链路中有一个中间环节丢失了上下文。具体来说异步任务回调时没有把会话ID透传下去导致回调结果写入了当前线程持有的默认上下文。修复方案是重构成全链路ID传递——从请求入口生成唯一的trace_id所有子任务、回调、工具调用都携带这个trace_id状态读写全部以trace_id为key。修复后这类串号问题彻底消失。所以强烈建议任何做多智能体并发系统的团队从第一天起就建立全链路追踪机制别等出了事故再补。5.3 安全审查的耗时陷阱与异步化改造早期实现里输入安全审查和输出合规审查都是同步阻塞在请求路径里的。一个请求最坏情况下要多吃两次模型推理的延迟输入一次、输出一次加上调度模型的推理整条链路可能超过5秒这个体验对实时对话来说不可接受。后来我们做了分层异步化改造。输入侧的安全审查保持同步因为这是不可让渡的安全底线输出侧的合规审查改成同步快速筛查异步深度复核两级方案。快速筛查只做规则级检查格式、字段、关键词信号耗时控制在50毫秒以内深度复核走语义级模型审查异步进行复核结果通过webhook推送如果有问题再通知客户端撤回或标记。这样做把同步链路的耗时压缩到了可接受范围同时没有牺牲审查深度。5.4 关键参数配置参考最后分享一些我们稳定运行的配置参数仅供参考具体数值要根据自己的场景调整配置项参数值说明路由判断超时200ms超过则降级为默认路由调度主模型最大推理token1024调度任务不需要长输出重点在速度输入安全审查超时500ms超过则拒绝请求并报异常输出快速筛查超时50ms只跑规则级检查知识检索召回数量top 5高于5会稀释注意力会话短期记忆TTL30分钟无操作后过期工具调用最大重试次数2次两次失败则切换到备用工具外部API熔断阈值5秒超时/3次连续失败满足任一条件即熔断降级策略限流放行异步补审安全服务异常时启用模型路由缓存TTL5分钟业务规则变更频繁时调短参数调整的总体原则是优先保证可用性其次追求精准度最后才是成本。安全相关的超时参数宁可设置得更保守也不能让一次恶意请求蒙混过关。6. 从架构到落地的几点个人体会这套613混合模型四层智能体架构安全策略编排的方案前前后后迭代了五个版本才稳定下来。现在回头看看几个当初坚持下来的设计决策是真正起到了决定性作用的。第一个是坚持把安全策略编排独立成层。最初团队里也有人觉得模型自己会拒绝违规请求不需要额外一层但实际对抗测试和线上数据都证明模型的自审查在复杂攻击面前会有明显的遗漏率独立一层语义级审查是必要的。第二个是坚持路由粒度到任务域而不是用户意图。这避免了大量模型改造成本也让路由模块保持简单可靠。很多团队容易陷入分类越细越好的误区但分类越细样本就越稀疏效果就越不稳定边际收益反而是负的。第三个是坚持能异步的绝不同步。这个原则不仅救了延迟指标还让整个系统的可观测性上了一个台阶。因为异步任务天然需要任务ID和状态记录这倒逼我们建立了完整的追踪体系后面排查问题方便太多了。最后再说一句关于智能体安全的心态问题。很多人觉得安全是上线前一次性做完的事其实完全不是。攻击手段在演化业务场景在扩展模型版本在更新安全策略必须持续迭代。我们现在的节奏是每周都要review一次安全日志每月做一次攻击模拟演练安全策略的更新频率几乎和业务功能的更新频率一样高。这套机制跑起来之后遇到新出现的攻击手法也不慌了——因为策略引擎支持热更新五分钟内就能把新的防护规则推到全量环境生效。
