写之前先把背景交代一下。我是 55873 生态这个项目的技术负责人这个代号来自内部项目管理系统里的迭代编号不是某个公开产品的名字。前四篇我分别写了数据治理、底座模型微调、推理服务压测和本地部署方案都是在单点上做深这一篇是第 5 篇主题是把散装的模型拼成一套能线上稳定跑的完整体系也就是标题里那句613 混合模型 × 四层智能体架构 × 安全策略编排。先说一个最容易跑偏的判断很多团队以为做 AI 体系是缺模型其实恰恰相反大家是模型太多。算法工程师各训各的模型业务方各封装各的 Agent结果模型散落在一堆私有服务里调用关系画不清楚安全边界只在最外层 API 网关Agent 内部对数据库、邮件、第三方接口的访问几乎等于放养。55873 这套体系要做的是把模型变成可注册、可路由、可审计的资源再让智能体在一条干净的架构链路上协作。这篇是给两类人准备的一类是已经被多模型接入和 Agent 调用链整得焦头烂额的工程师另一类是正准备从单模型 API 调用走向模型体系化的架构负责人。下面直接进正题。1. 55873 要解决的不是缺模型而是模型太多了1.1 散装模型时代三个被反复吐槽的问题先说第一个问题模型找得到但根本不敢接。每个团队的微调模型都部署在自己的推理服务里只给自己业务用。别的团队想接入得先找到负责人、拉群、对接口、约算力一套流程下来两周过去了等接完需求可能已经变了。第二个问题是同类能力在重复建设。团队 A 训了一个意图识别模型团队 B 因为不知道又训了一个。两边线上各烧一份 GPU效果彼此不透明指标还都对不上。这种重复建模在稍微大一点的组织里几乎是必然发生的缺的不是建模能力而是一个让模型能力能被全局看见的注册环境。第三个问题最隐蔽Agent 内部的权限是黑盒。外部 API 网关做了身份认证和基础鉴权但 Agent 链路里编排模型可以组合调用很多动作——查数据库、发邮件、写文档、调第三方接口。网关只认证了你在调用 Agent 接口这件事管不到 Agent 内部将要执行的每一个具体动作。这就像一个访客进了大楼门卫查了身份证但访客在大楼里可以进任意房间、按任意按钮。所以 55873 立项的时候目标就很明确把模型和 Agent 当作一等资源统一纳管编排层负责路由和决策策略层负责在每个动作上做权限判断记忆层负责上下文状态。模型负责会不会编排负责做什么策略负责能不能三者不能混。1.2 613到底是什么意思标题里的 613拆开看是三种角色的模型分组数量角色负责内容通用能力模型6底座能力对话、意图识别、摘要抽取、向量化、多模态理解、内容安全预检编排核心模型1决策中枢把用户请求拆成任务序列决定调用哪个模型、哪个工具、检查哪条策略垂直领域模型3专业能力数据问答/SQL、代码生成与重构、领域知识问答注意一个关键点这不是从零训练 10 个模型而是把团队已有的、开源的、微调过的模型统一纳管进一个体系。6 个通用模型负责高频低成本的环节1 个编排核心模型负责调度3 个垂直模型负责专业场景。模型本身可以换架构不换。1.3 为什么敢把这个体系叫生态叫生态而不是平台是因为模型之间有明确的上下游关系。编排核心模型像交通调度中枢它不负责载客但所有车辆往哪走由它决定策略注册中心像交规所有动作必须先过灯再上路。生态的真正含义是新模型注册即可接入不需要改主流程老模型可以灰度退出不影响链路。这是后续所有稳定性的基础。2. 混合模型选型为什么是 10 个模型而不是一个超级大模型2.1 先算一笔经济账但省钱不是唯一理由很多人第一反应是既然有强大的通用大模型为什么不全部走它非要搞 10 个模型我直接给一组我们线上实测后的数据口径按 200 万日请求估算方案单次平均 token 数综合单价(元/千 token)单次成本P95 延迟估算日成本全部走超大模型35000.030.105 元4.8s21 万613 混合编排21000.0120.025 元2.1s5 万这个差距主要体现在两个地方一是通用大模型往往把所有历史上下文都重复计入 token二是混合架构里 80% 的低复杂度请求会被路由到中小模型上根本不会触达大模型。成本优势不用多解释。但省钱不是我们做混合选型的核心原因。真正的约束是数据合规——大量业务数据不允许出内网很多模型必须本地化部署同时又希望效果上各场景有专业模型兜底。混合模型本质上是效果、成本、合规三个约束取交集的结果。如果只抱着大模型万能的思路第二个月账单出来的时候公司财务会先找你谈话。2.2 6 个通用模型各自守好一个能力槽位这 6 个模型不负责回答复杂问题它们的目标是把请求流里高频低质的环节低成本跑完对话轻模型承接寒暄、简单澄清、多轮追问这类低逻辑深度的对话量大但不烧大模型。意图识别与任务分类模型链路的第一步把用户自然语言转成结构化意图槽位输出格式必须稳定。摘要与信息抽取模型压上下文用的。长对话塞进下游模型之前先抽关键实体和时间线。向量化 Embedding 模型RAG 检索的入口所有知识问答和记忆检索都过它。多模态理解模型处理图片、截图、扫描件里的信息抽取。内容安全预检模型输入侧和输出侧各过一次负责拦截注入特征和敏感信息泄漏。为什么是 6 个而不是 8 个或 4 个因为我们统计了线上请求的形态分布80% 的流量可以被这 6 类能力覆盖。多一个模型就多一份运维成本和路由复杂度少一个又会让某些请求被迫落到底座大模型上。6 是当时测算下来性价比最合适的数字。2.3 编排核心模型凭什么选1而不是选最大这个模型是整个体系里最容易被误解的位置。很多人觉得调度中枢应该用最强的模型我们一开始也这么想后来被现实教育了大模型在开放式对话上很强但让它稳定输出任务 DAG 的 JSON 描述这种高度结构化的东西反而容易出现自由发挥。编排核心模型要输出的东西长这样[ { task: query_sql, target_slot: sql_answer, params: { metric: sales_amount, region: 华东, date_range: 上周 } }, { task: summary, target_slot: summary_model, params: { source: task_0_result } } ]这种输出对模型的要求是指令遵循能力极强、JSON 格式有效率达到 99.5% 以上、能在有限的 token 预算内把 3 到 5 个任务拆清楚。我们专门建了一套评测集用格式有效率和任务拆分正确率选型而不是凭对话手感选。最后选的是一个中等规模、但指令遵循能力特别扎实的模型来坐这个位置。2.4 3 个垂直模型为什么不敢省垂直模型存在的理由是通用模型在专业领域什么都懂一点什么都不精确。我们的三个垂直模型各有分工。第一个是数据问答/SQL 模型。它接收自然语言问题输出 SQL 和解释。训练数据来自企业数据字典、历史 SQL 和问答标注我们实际用的是 5 万条左右的高质量样本做 SFT。这里插一句网上很多教程喜欢宣传54 万条数据这种大数字但在我们项目里盲目灌进去的大批量数据反而会把模型带偏噪声样本远比缺样本可怕。第二个是代码生成/重构模型。我们用它做本地代码重构比如把旧项目按团队规范重写约束是输出必须符合代码风格规范且不改变外部接口。热词里有人搜如何使用本地 AI 模型重构 C# 项目代码我们确实就这么干过垂直模型的优势在于它能学到团队的代码习惯而不是只会输出 LeetCode 风格代码。第三个是领域知识问答模型。它回答任何问题都必须带引用引用来源必须是检索系统真实返回的文档编号置信度不够时明确说不确定。这个必须带引用不是写进提示词就完事我们在后处理里做了校验具体放第 5 节讲。2.5 模型注册中心把模型变成可路由的资源所有模型不会直接出现在编排代码里而是先注册进模型注册中心挂在能力槽位上model_id能力槽位部署形态单次成本(元)当前版本chat-lite-v2chat本地 GPU0.002v2.3intent-cn-v4intent本地 GPU0.003v4.1sql-qa-v3sql_answer本地 GPU0.015v3.6planner-spec-v5planner本地 GPU0.008v5.2编排核心模型路由时不直接写模型名而是写能力槽位比如查询类任务走 sql_answer。槽位背后的模型可以随时替换这给灰度发布和回滚留下了操作空间后面第 6 节会详细讲。3. 四层智能体架构调度层和记忆层坚决不能和业务代码揉在一起3.1 四层到底怎么切四层架构听起来像套话但真正落地时最难的是边界划在哪里。我们最终切成了这样层职责关键组件L1 接入层身份认证、会话管理、多端协议转换认证网关、会话服务L2 编排决策层意图识别、任务拆解、模型路由、策略执行点(PEP)编排核心模型、策略执行点L3 执行层模型调用、工具调用、外部系统对接工具注册表、Function Call、MCP 连接器L4 状态与记忆层短期上下文、长期记忆、业务快照会话缓存、向量库、记忆压缩服务每一层只做一件事。L1 只负责谁在问L2 只负责要做什么、用什么资源、是否符合策略L3 只负责把动作做完并返回结构化结果L4 只负责上下文存取和压缩。界线越清楚后续排障越容易。3.2 为什么调度层不能和执行层揉在一起我不止一次见过单体 Agent 代码在一个大函数里先调意图模型再调业务工具又把历史记录塞进 prompt所有逻辑写在一起。这种代码最典型的症状是加一个新工具要改主流程出问题时分不清是模型判断错了还是工具执行错了因为调度、执行、记忆混在一团。我们把调度和执行拆开之后实际收益非常明显。新增一个外部系统只需要两步在 L3 注册一个工具 schema在策略注册中心加两条授权规则。主流程代码完全不用动。调度层是大脑执行层是手臂大脑可以换思路手臂可以换工具互不牵连。3.3 一个请求从进入到返回的完整链路看一个真实例子。用户说帮我把上周华东销售数据拉出来总结成周报发给市场部负责人。L1 接入层先完成身份认证拿到用户的角色和权限标签。L2 编排决策层做意图识别拆出任务序列query_sql → summary → send_email。L2 里的策略执行点(PEP)开始逐项检查读取销售数据允许生成摘要允许发送邮件需要审批。于是 send_email 这一步被拦截返回需要先通过审批。L3 执行层依次调用 SQL 垂直模型生成 SQL 并执行调用摘要模型生成周报邮件工具因为没有通过策略检查根本没有被发起调用。L4 状态与记忆层把 SQL 结果摘要和周报写入会话记忆用户下一句说华东换成华南不需要重新把需求描述一遍。这个链路的关键细节是send_email 被拦截发生在执行层发起调用之前而不是之后。安全校验永远前置不能靠跑完再看合不合规。3.4 智能体之间能不能互调能但必须有强约束。我们的设计原则是Agent 互调只允许发生在 L2 编排层产出的任务序列里L3 执行层不允许私自发起新的 Agent 调用链路。同时强制设置递归深度上限 max_depth3默认超时 30 秒防止套娃式调用打爆集群。互调链路上每一跳都必须携带原始 trace_id否则排障时会变成一场灾难。4. 安全策略编排把权限模型从 API 网关搬进 Agent 链路内部4.1 网关之外还有一段没人管的路传统 API 网关的安全模型是认证 粗粒度鉴权用户能调 Agent 接口工厂就放行。但 Agent 链路内部编排模型可以组合发起一系列动作。一个只拥有只读权限的用户完全可以提出把销售数据整理一下顺便发给我老板这样的请求背后其实是 select 数据库 send_mail 两个动作。网关只会看到用户调用了 Agent 接口根本管不到里面的 send_mail。这就是安全策略编排存在的理由鉴权要下沉到 Agent 的每一个具体动作上而不是停留在最外层接口。换句话说权限模型必须跟着 Agent 的执行链走。4.2 策略注册中心 PDP/PEP策略要能编排不能写死在代码里我们把安全策略编排设计成三件套策略注册中心(Policy Registry)、策略决策点(PDP)、策略执行点(PEP)。PDP 负责判断五元组谁(Subject)、做什么动作(Action)、对什么资源(Resource)、数据敏感级别、上下文风险分。返回三种结果allow、deny、require_approval。PEP 位于 L2 编排决策层在所有模型调用和工具调用发起之前执行一次检查。策略本身是配置不是代码这样安全人员和业务人员都能审不用等开发排期。一个典型的策略配置长这样policy: send_email_approval subject.role: employee resource.type: email action: send decision: require_approval approval.channel: 工单系统这个机制起作用的方式是编排模型把任务序列拆出来之后PEP 逐个动作向 PDP 请求决策。决策通过任务才交给 L3 执行。任何策略变更都带版本号和模型一样可以灰度、可以回滚。4.3 输入侧和输出侧安全预检模型各守一道M6 内容安全预检模型在我们的链路里过两次。输入侧拦截 prompt 注入特征和越权诱导比如忽略以上规则这类指令模式输出侧在模型结果返回给用户前检查是否包含敏感数据、是否可能越界。同时我们会给每个会话维护一个综合风险分。如果同一个会话里连续出现多条可疑输入风险分就上涨PDP 对高敏感动作会自动从 allow 升级为 require_approval。这相当于给安全策略加了一个动态调节旋钮而不是永远用一套死规则。4.4 审计链路要做到从问题到动作可回放监管和合规审查问的往往不是你的模型回答了什么而是当时为什么让 Agent 做了这件事。所以审计日志必须能回答为什么调、谁批准、命中哪条策略。我们用 trace_id 把整条链路串起来用户请求 → 计划 DAG → 每一步模型的输入输出摘要 → 工具调用参数 → 策略决策结果 → 最终回答。只记录调了哪个模型远远不够核心是记录编排模型为什么决定这么调、PDP 基于哪条策略做了哪个决策。有了这套日志事后复盘任何一次事故都能像回放录像一样把当时的每一步还原出来。5. 线上踩坑实录五个把系统打崩的瞬间5.1 坑一垂直模型输出格式变更下游解析直接 panic现象灰度新版 SQL 模型 v3.6 之后回答解析失败率突然冲到 30%线上告警一片。排查链路是先看 trace发现新版模型输出的 SQL 不再包裹在代码块里而下游解析逻辑是依赖代码块边界做截断的解析器直接 panic。再对比训练数据发现新版训练集里混入了一批不输出代码块的对话样本模型学歪了。修复方案是三件事输出协议做 schema 版本化模型输出统一走结构化提取层不再依赖副本文本格式训练数据里对输出模板做统一清洗灰度前强制跑格式合规率评测。这件事的教训是模型升级不是换个权重而是换一套输出协议协议必须先锁死模型后上。5.2 坑二Agent 互相调用的死循环现象某次提问触发了 47 次内部 Agent 调用跑了 5 分钟才超时集群 CPU 直接拉满连带影响其他业务。排查链路很典型。看 DAG 追踪记录发现总结 Agent 生成了需要继续查询的子任务查询 Agent 又生成了需要先总结的子任务两个节点互相等待谁也不让谁。根因是编排层没有做循环检测也没有最大迭代次数限制。修复方案DAG 构建时做环检测出现循环直接拒绝执行时强制 max_iterations8单步超时 10 秒相邻节点出现重复调用直接熔断。这个教训让我意识到Agent 编排必须像写状态机一样写终止条件不能指望模型靠自觉跳出循环。5.3 坑三RAG 检索出来的答案带着假引用现象领域知识模型回答问题时引用了一个内部文档编号 KM-023但检索系统里根本没有这份文档。排查链路先复现单问一句就得到根据 KM-023 文档……再去知识库检索确认编号不存在。根因是模型在训练时学会了输出引用格式这个动作但引用内容并没有和检索系统返回的结果对齐属于典型的检索增强幻觉。修复方案提示词里明确引用只能来自检索结果列表同时在后处理里做交集校验——模型输出的引用编号如果不在本次检索返回列表里直接判定为无依据回答未找到相关资料。垂直模型再强引用校验也不能省否则幻觉会以看起来很专业的方式被成倍放大。5.4 坑四用户一句忽略所有规则骗过了路由模型现象某段时间安全拦截率在午后突然下降直觉告诉我这很不正常。拦截率突然变低往往不是天下太平而是有人绕过了拦截。排查链路翻策略日志发现 PDP 命中 allow 的动作明显变多再看输入预检发现注入文本没有触发 M6 的黑名单关键词阈值。根因是 M6 只做了关键词级校验没做语义级注入识别而路由模型把忽略规则当成了普通上下文照单全收。修复方案M6 增加语义注入分类器不再只看关键词PEP 对高风险指令模式一律降级为 require_approval路由模型的 system prompt 增加一段不可被用户文本覆盖的声明。这件事最深的体会是这种攻击靠模型自觉根本防不住必须靠编排层的强策略兜底。5.5 坑五链路全通了但没人知道每天花了多少钱现象月底账单出来token 费用比预期多 2.3 倍。根因是灰度切换时路由权重配错了80% 流量打到昂贵的底座大模型上而成本统计只统计了完成请求数没有统计单请求 token 消耗分布。换句话说管钱的人只看得到一个总数字说不清钱花在了哪个环节。修复方案每个能力槽位记录成本明细按 slot 统计单请求 token 分布设置超预算自动降级开关流量一旦超支自动切到低配模型增加告警规则单槽位成本日环比涨幅超过 20% 就提醒。混合模型的成本不是由模型数量决定的而是由路由权重和 token 冗余度决定的没有成本观测的编排层等于盲人摸象。6. 稳定运行靠三条命评测基线、灰度开关、全链路观测6.1 评测基线每次换模型先过 260 道题体系能稳定换模型靠的是一套硬性评测基线。我们维护了一个 260 条样本的评测集覆盖四个方面任务拆分正确率、模型输出格式合规率、工具调用参数准确率、安全拦截召回率。门槛定得很死路由准确率不低于 98%输出格式合规率不低于 99.5%垂直模型 SQL 执行通过率不低于 95%安全注入检出率不低于 90%。任何模型想上线先过这套题过不了就在测试环境里继续调不上线。还有一个经验评测集要跟着线上 badcase 持续补充。前 50 个线上坏例子比后面随便凑的 500 个测试样本有用得多因为它们代表的是真实用户行为不是开发者想象中的理想输入。6.2 灰度开关权重是配置不是改代码我们的灰度粒度精确到能力槽位。比如 sql_answer 槽位在切换模型时先让新模型承接 5% 流量观察 24 小时再逐步扩大到 20%、50%、100%。回滚就是把路由权重改回去一分钟内完成不需要发版。安全策略同样可以灰度。新策略先只对 5% 的流量生效观察两个指标误杀率有没有上升、绕过率有没有下降确认没问题再全量。灰度对象必须精确到 slot不要全局一把梭否则一个槽位的抖动会影响所有业务。6.3 全链路观测trace_id 不是可选项最后说观测。Agent 系统的观测重点不是模型性能而是编排行为和策略行为。我们日常盯三个核心指标P95 延迟整链路控制在 6 秒以内每个模型节点都有单独耗时能定位是哪个槽位拖慢了整条链。单请求 token 成本按槽位统计找出又贵又慢的请求特征反推路由策略是否需要调整。安全拦截率这个指标需反向理解它突然降到接近 0 时优先怀疑有人绕过了编排层而不是觉得安全形势一片大好。告警也要围绕编排行为设计。比如策略配置变更后 30 分钟无任何拦截事件这种告警比服务器 CPU 高有用得多因为前者直接指向策略失效或链路绕过后者往往已经被监控系统告烂了没人当回事。写到这里55873 生态从模型选型、架构分层、安全策略到稳定手段完整拼装思路基本到齐了。我自己的体会是这个体系里真正难的不是单个模型而是让 10 个模型像一个系统一样工作而这件事成不成立不看模型本身强不强看编排层是否足够干净、策略层是否真的守得住底线。下一篇我打算把记忆层单独拿出来写包括长期记忆的失效处理、向量库的容量治理以及 RAG 缓存命中率优化这些都是当前版本还没做透的地方到时候再把实战数据补上。