企业官网建设流程全解析

写之前先把背景交代一下。我是 55873 生态这个项目的技术负责人，这个代号来自内部项目管理系统里的迭代编号，不是某个公开产品的名字。前四篇我分别写了数据治理、底座模型微调、推理服务压测和本地部署方案，都是在单点上做深；这一篇是第 5 篇，主题是把散装的模型拼成一套能线上稳定跑的完整体系，也就是标题里那句"6+1+3 混合模型 × 四层智能体架构 × 安全策略编排"。

先说一个最容易跑偏的判断：很多团队以为做 AI 体系是"缺模型"，其实恰恰相反，大家是"模型太多"。算法工程师各训各的模型，业务方各封装各的 Agent，结果模型散落在一堆私有服务里，调用关系画不清楚，安全边界只在最外层 API 网关，Agent 内部对数据库、邮件、第三方接口的访问几乎等于放养。55873 这套体系要做的，是把模型变成可注册、可路由、可审计的资源，再让智能体在一条干净的架构链路上协作。

这篇是给两类人准备的：一类是已经被多模型接入和 Agent 调用链整得焦头烂额的工程师，另一类是正准备从"单模型 API 调用"走向"模型体系化"的架构负责人。下面直接进正题。

1. 55873 要解决的不是缺模型，而是"模型太多了"

1.1 散装模型时代，三个被反复吐槽的问题

先说第一个问题：模型找得到，但根本不敢接。每个团队的微调模型都部署在自己的推理服务里，只给自己业务用。别的团队想接入，得先找到负责人、拉群、对接口、约算力，一套流程下来两周过去了，等接完，需求可能已经变了。

第二个问题是同类能力在重复建设。团队 A 训了一个意图识别模型，团队 B 因为不知道，又训了一个。两边线上各烧一份 GPU，效果彼此不透明，指标还都对不上。这种重复建模在稍微大一点的组织里几乎是必然发生的，缺的不是建模能力，而是一个让模型能力能被全局看见的注册环境。

第三个问题最隐蔽：Agent 内部的权限是黑盒。外部 API 网关做了身份认证和基础鉴权，但 Agent 链路里编排模型可以组合调用很多动作——查数据库、发邮件、写文档、调第三方接口。网关只认证了"你在调用 Agent 接口"这件事，管不到 Agent 内部将要执行的每一个具体动作。这就像一个访客进了大楼，门卫查了身份证，但访客在大楼里可以进任意房间、按任意按钮。

所以 55873 立项的时候目标就很明确：把模型和 Agent 当作一等资源统一纳管，编排层负责路由和决策，策略层负责在每个动作上做权限判断，记忆层负责上下文状态。模型负责"会不会"，编排负责"做什么"，策略负责"能不能"，三者不能混。

1.2 "6+1+3"到底是什么意思

标题里的 6+1+3，拆开看是三种角色的模型：

注意一个关键点：这不是从零训练 10 个模型，而是把团队已有的、开源的、微调过的模型统一纳管进一个体系。6 个通用模型负责高频低成本的环节，1 个编排核心模型负责调度，3 个垂直模型负责专业场景。模型本身可以换，架构不换。

1.3 为什么敢把这个体系叫"生态"

叫"生态"而不是"平台"，是因为模型之间有明确的上下游关系。编排核心模型像交通调度中枢，它不负责载客，但所有车辆往哪走由它决定；策略注册中心像交规，所有动作必须先过灯再上路。生态的真正含义是：新模型注册即可接入，不需要改主流程；老模型可以灰度退出，不影响链路。这是后续所有稳定性的基础。

2. 混合模型选型：为什么是 10 个模型而不是一个超级大模型

2.1 先算一笔经济账，但省钱不是唯一理由

很多人第一反应是：既然有强大的通用大模型，为什么不全部走它，非要搞 10 个模型？我直接给一组我们线上实测后的数据口径，按 200 万日请求估算：

这个差距主要体现在两个地方：一是通用大模型往往把所有历史上下文都重复计入 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 模型注册中心：把模型变成可路由的资源

所有模型不会直接出现在编排代码里，而是先注册进模型注册中心，挂在"能力槽位"上：

编排核心模型路由时不直接写模型名，而是写能力槽位，比如"查询类任务走 sql_answer"。槽位背后的模型可以随时替换，这给灰度发布和回滚留下了操作空间，后面第 6 节会详细讲。

3. 四层智能体架构：调度层和记忆层，坚决不能和业务代码揉在一起

3.1 四层到底怎么切

四层架构听起来像套话，但真正落地时最难的是"边界划在哪里"。我们最终切成了这样：

每一层只做一件事。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_depth=3，默认超时 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_iterations=8，单步超时 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 缓存命中率优化，这些都是当前版本还没做透的地方，到时候再把实战数据补上。