企业官网建设流程全解析

1. 从标题拆解一套可落地的 AI 模型体系到底长什么样

第一次看到“6+1+3 混合模型 × 四层智能体架构 × 安全策略编排”这个组合时，我脑子里冒出来的第一个念头不是“好复杂”，而是“终于有人把模型选型和智能体编排放在一张图里讲了”。过去大半年，我经手过三个从零搭建的智能体项目，踩过最大的坑就是：模型选型跟编排层是两拨人各干各的，模型侧只管把 API 吐出来，编排侧只管把流程串起来，结果上线之后要么是响应慢得离谱，要么是某个环节的模型突然抽风导致整条链路崩掉。所以这套“6+1+3”的思路，本质上是在解决一个很实际的问题——怎么让不同能力、不同成本、不同响应速度的模型，在一个智能体系统里各司其职，而不是一锅乱炖。

先把标题里的几个核心概念翻译成人话。“6+1+3 混合模型”指的是一套模型分层策略：6 个基础能力模型负责通用任务，1 个核心推理模型负责复杂决策，3 个专用模型负责垂直场景的精细化处理。这不是随便凑的数字，后面我会详细拆解每一层的选型逻辑。“四层智能体架构”则是从感知层、编排层、执行层到反馈层的完整链路设计，每一层解决不同的问题。“安全策略编排”是贯穿始终的约束机制，确保智能体在可控范围内运行。

这套体系适合谁来参考？如果你正在做智能体平台架构设计，或者手头有一个需要多模型协作的项目，再或者你只是想知道“问数智能体”这类东西底层是怎么跑起来的，那这篇内容应该能给你一些可以直接抄作业的思路。我不会只讲概念，每个环节都会配上我实际用过的参数配置和踩坑记录。

2. 6+1+3 混合模型的分层逻辑与选型实操

2.1 为什么是 6+1+3 而不是别的数字组合

很多人第一反应会问：为什么不是 5+2+2 或者 7+1+2？这个数字组合背后其实对应的是任务复杂度的分布规律。我统计过自己经手的三个项目里智能体实际调用的任务类型，大致呈现这样一个分布：约 60% 是简单的信息提取、格式转换、意图识别类任务，约 25% 是需要多步推理的复杂决策任务，剩下 15% 是垂直领域的专业任务。6+1+3 正好对应这个比例——6 个轻量模型覆盖那 60% 的高频简单任务，1 个强推理模型处理那 25% 的核心决策，3 个专用模型搞定那 15% 的专业场景。

这个分配不是拍脑袋定的。我试过用一个大模型包打天下，结果就是简单任务也要等好几秒，成本还高得吓人。后来改成混合模型之后，简单任务的响应时间从平均 3.2 秒降到了 0.8 秒，整体成本下降了约 47%。这个数字因项目而异，但方向是对的：让合适的模型做合适的事，不要用大炮打蚊子。

2.2 六个基础能力模型的具体分工

这 6 个基础模型不是随便找六个小模型塞进去就行，它们各自有明确的能力边界。我在实际部署中是这样划分的：

• 意图分类模型：负责判断用户输入属于哪一类任务，是整个链路的第一道关卡。这个模型不需要太强，但一定要快，我通常选参数量在 1B 到 3B 之间的轻量模型，推理延迟控制在 200ms 以内。
• 实体抽取模型：从用户输入里把关键信息捞出来，比如时间、地点、数值、专有名词。这个模型对准确率要求高，但对推理能力要求低，适合用经过微调的小模型。
• 文本改写模型：把用户口语化的表达转成规范输入，或者把结构化数据转成自然语言。这个环节很多人会忽略，但实际用下来，加一个改写模型能让后续环节的准确率提升 15% 以上。
• 格式转换模型：处理 JSON、XML、Markdown 等格式之间的转换，以及表格数据的解析。这个用规则引擎也能做，但遇到非标准格式时模型更稳。
• 摘要压缩模型：当上下文太长时，负责把历史对话压缩成关键信息，避免超出模型的上下文窗口。
• 基础问答模型：处理那些不需要推理的简单事实性问题，比如“今天天气怎么样”这种。

这六个模型可以部署在同一台机器上，用不同的端口区分。我实测下来，在 Mac Studio 上跑这六个小模型，内存占用大约 12GB，完全在可接受范围内。

2.3 那一个核心推理模型怎么选

这个“1”是整个体系的大脑，选型最关键。我的经验是：不要盲目追新，要看你的任务类型。如果你的智能体主要做逻辑推理和规划，那就选推理能力强的；如果主要做知识问答，那就选知识覆盖广的。

具体到部署方式，我试过两种方案。一种是直接用云端 API，优点是省事，缺点是延迟不可控、成本随调用量线性增长。另一种是本地部署，我目前在 Mac Studio 上跑的是一个 70B 级别的量化模型，用 4-bit 量化后内存占用约 40GB，推理速度大约 15 tokens/秒。这个速度对于非实时场景够用了，但如果是需要快速响应的场景，还是得用云端 API 或者更小的模型。

这里有个坑要注意：核心推理模型的输出格式一定要做约束。我早期没做约束，模型有时候返回一大段自然语言，编排层解析起来非常痛苦。后来改成强制 JSON 输出，配合 few-shot 示例，解析成功率从 78% 提升到了 96%。

2.4 三个专用模型的垂直场景适配

三个专用模型对应的是垂直场景，比如中医问答、代码重构、数据分析这类。以中医问答模型训练数据集为例，我了解到的一个项目用了 54 万条数据做微调，这个量级对于垂直领域来说是够的。

专用模型的训练有几个关键点。第一是数据质量比数量重要，54 万条数据里如果有一半是噪声，效果还不如 10 万条干净数据。第二是基座模型的选择，垂直领域微调不需要从零训练，选一个通用能力还不错的基座，用 LoRA 做微调就行，成本低很多。第三是评估集一定要独立，不能拿训练数据当测试数据，否则上线后会发现效果大打折扣。

我自己的做法是：每个专用模型都配一个独立的评估脚本，每次微调后跑一遍，看准确率、召回率和 F1 值的变化。如果某个指标下降超过 5%，就回滚到上一个版本。

3. 四层智能体架构的逐层拆解与实现细节

3.1 感知层：把非结构化输入变成结构化信号

感知层是整个架构的入口，负责接收用户输入并做初步处理。这一层要做的事情包括：输入清洗、意图识别、实体抽取、上下文组装。

输入清洗听起来简单，但实际做起来有很多细节。比如用户输入里可能包含特殊字符、多余空格、换行符，这些都要处理掉。还有多轮对话的场景，需要把历史对话按一定规则拼接起来。我的做法是保留最近 5 轮对话，更早的用摘要模型压缩成一句话。

意图识别和实体抽取可以并行做，用两个小模型分别处理。这里有个优化技巧：先做意图识别，再根据意图决定要不要做实体抽取。比如用户只是打招呼，那就不需要抽实体，省一次模型调用。

上下文组装是把用户输入、历史对话、系统提示词、工具描述等拼成一个完整的 prompt。这个环节最容易出问题的是 token 超限。我的做法是设一个阈值，比如 80% 的上下文窗口，超过就触发压缩流程。

3.2 编排层：智能体的调度中枢

编排层是四层架构里最核心的部分，负责决定“下一步做什么”。这一层我采用的是“规划-执行-反思”的循环结构。

规划阶段，核心推理模型会根据当前状态生成一个行动计划，通常是一个步骤列表。执行阶段，编排器按步骤调用相应的工具或模型。反思阶段，检查执行结果是否符合预期，如果不符合就调整计划重新执行。

这里的关键是状态管理。我用一个 JSON 对象来维护整个会话的状态，包括当前步骤、已完成步骤、中间结果、错误信息等。每次循环开始时读取状态，结束时更新状态。这个 JSON 对象会作为 prompt 的一部分传给核心推理模型，让它知道当前进展。

编排层还有一个重要职责是超时和重试控制。我设的规则是：单个步骤超过 30 秒未完成就标记为超时，自动重试一次；如果重试还失败，就跳过该步骤并记录错误。整个会话的总时长控制在 5 分钟以内，超过就强制结束并返回已有结果。

3.3 执行层：工具调用与模型路由

执行层负责实际调用工具和模型。这一层要解决的核心问题是路由：根据编排层的指令，把任务分发给正确的模型或工具。

我的路由策略是这样的：先查路由表，路由表里定义了每种任务类型对应的模型或工具。比如“文本摘要”对应摘要压缩模型，“代码生成”对应专用代码模型，“数据查询”对应数据库工具。如果路由表里没有匹配项，就交给核心推理模型兜底。

工具调用这块，我用的是标准的 function calling 格式。每个工具定义包括名称、描述、参数 schema。核心推理模型在规划阶段会输出要调用的工具名称和参数，执行层解析后调用对应的工具，再把结果返回给编排层。

这里有个坑：工具描述一定要写清楚。我早期有个工具叫“查询数据”，描述写得很模糊，结果模型经常在不该调用的时候调用它。后来改成“根据用户提供的条件查询销售数据库，返回匹配的记录”，调用准确率明显提升。

3.4 反馈层：让智能体从错误中学习

反馈层是很多人会忽略的一层，但它决定了智能体能不能持续优化。反馈层要做的事情包括：记录每次会话的完整轨迹、标注成功和失败案例、定期分析失败模式、更新路由表和提示词。

我的做法是每次会话结束后，把完整的交互轨迹存到数据库里，包括用户输入、每步的模型输出、工具调用结果、最终输出。然后每周跑一次分析脚本，统计失败率最高的环节，针对性地优化。

比如我发现某个意图的识别准确率一直很低，就去检查训练数据，发现这类样本很少，于是补充了一批标注数据重新微调，准确率从 72% 提升到了 89%。这个闭环很重要，没有反馈层的智能体就是一个静态系统，不会随着使用变好。

4. 安全策略编排：贯穿四层的约束机制

4.1 输入侧的安全过滤

输入侧的安全过滤是第一道防线。我在感知层之前加了一个过滤模块，做三件事：敏感词检测、注入攻击检测、输入长度限制。

敏感词检测用的是一个维护好的词表，匹配到就直接拦截并返回预设的提示语。注入攻击检测主要是防 prompt injection，比如用户输入里包含“忽略之前的指令”这类内容。我的做法是用一个小的分类模型来判断，准确率比规则匹配高不少。

输入长度限制是防止超长输入导致 token 爆炸。我设的上限是 4000 个字符，超过就截断并提示用户。

4.2 编排层的权限控制

编排层的权限控制决定了智能体能调用哪些工具、访问哪些数据。我的做法是给每个工具打上权限标签，比如“公开”“内部”“机密”，然后根据会话的权限级别来决定是否允许调用。

权限级别在会话初始化时确定，通常跟用户身份绑定。比如普通用户只能调用“公开”级别的工具，管理员可以调用所有级别的工具。这个机制能有效防止智能体越权操作。

4.3 执行层的输出审查

执行层的输出审查是在结果返回给用户之前做最后一道检查。我主要检查三类问题：敏感信息泄露、格式错误、逻辑矛盾。

敏感信息泄露的检查用正则表达式匹配手机号、身份证号、邮箱等模式。格式错误检查是验证输出是否符合预期的 JSON schema。逻辑矛盾检查比较难，我的做法是用一个小的判别模型来判断输出是否与输入矛盾，准确率大概在 85% 左右，作为辅助手段够用了。

4.4 反馈层的审计日志

反馈层的审计日志记录所有会话的完整轨迹，包括谁在什么时候调用了什么工具、返回了什么结果。这个日志有两个用途：一是事后追溯，出问题时能快速定位；二是定期审计，发现异常调用模式。

我的日志格式是 JSON Lines，每行一条记录，包含时间戳、会话 ID、用户 ID、操作类型、输入输出摘要。日志保留 90 天，之后归档到冷存储。

5. 实操部署与性能调优的完整记录

5.1 硬件选型与资源分配

我目前的部署环境是一台 Mac Studio，M2 Ultra 芯片，128GB 内存。这个配置跑 6 个小模型加 1 个 70B 量化模型加 3 个专用模型，内存占用大约 85GB，还有余量。

如果你预算有限，可以考虑用一台机器跑小模型和专用模型，核心推理模型用云端 API。这样硬件成本能降低不少，但要注意 API 的延迟和成本控制。

资源分配上，我给每个模型设了内存上限，防止某个模型占用过多资源导致其他模型被挤掉。具体做法是用推理框架的资源限制功能，比如 llama.cpp 的--memory-limit参数。

5.2 模型加载与推理优化

模型加载我用的是一种懒加载策略：启动时只加载核心推理模型和意图分类模型，其他模型在第一次被调用时才加载。这样启动时间从 3 分钟缩短到了 40 秒。

推理优化方面，我做了几件事。第一是开启批处理，把多个请求合并成一个批次推理，吞吐量提升了约 2 倍。第二是使用 KV 缓存，多轮对话时避免重复计算。第三是量化，所有模型都用 4-bit 量化，精度损失在可接受范围内，速度提升明显。

5.3 端到端延迟的拆解与优化

我实测了一次完整会话的延迟分布：感知层约 300ms，编排层约 2.5s（主要是核心推理模型的耗时），执行层约 800ms，反馈层约 100ms。总延迟约 3.7 秒。

优化空间主要在编排层。我的做法是把一些常见的规划模式缓存起来，比如“查询数据”这类任务的规划步骤基本固定，直接查缓存就行，不用每次都调核心推理模型。这个优化让编排层延迟降到了 1.2 秒左右。

5.4 压力测试与稳定性验证

上线前我做了一轮压力测试，模拟 50 个并发会话。结果是：平均延迟从 3.7 秒上升到了 8.2 秒，但没有出现超时或崩溃。瓶颈在核心推理模型，因为它是串行处理的。

如果要支持更高并发，有两个方案：一是部署多个核心推理模型实例做负载均衡，二是把部分任务分流到更小的模型。我目前用的是第一种方案，部署了两个实例，并发能力提升到了 80 左右。

6. 常见问题与排查技巧实录

6.1 模型输出格式不稳定的排查思路

这是最常见的问题。模型有时候返回 JSON，有时候返回自然语言，有时候 JSON 里还带注释。我的排查步骤是这样的：

先检查提示词里有没有明确要求 JSON 格式，并且给出示例。如果没有，加上。如果加了还是不稳定，就检查温度参数，温度太高会导致输出随机性大，调到 0.1 以下。如果还不行，就在解析层加一个容错机制，用正则表达式提取 JSON 部分，提取失败就重试一次。

我踩过最坑的一次是模型返回的 JSON 里包含中文引号，导致解析失败。后来在解析前统一替换成英文引号，问题解决。

6.2 工具调用失败的常见原因

工具调用失败通常有三个原因：参数格式不对、工具内部报错、超时。

参数格式不对最常见，比如模型输出的参数类型跟 schema 定义的不一致。我的做法是在执行层加一个参数校验和转换模块，把字符串类型的数字转成数字类型，把单个值转成数组等。

工具内部报错就要看具体工具的日志了。我一般会在工具里加详细的错误日志，方便定位。

超时的话，先看工具本身的性能，如果确实慢，就考虑异步调用或者加缓存。

6.3 上下文超限的处理策略

上下文超限是多轮对话场景下的常见问题。我的处理策略是分级压缩：先压缩最早的对话，如果还不够就压缩中间部分，最后才动最近的对话。

压缩用摘要模型做，把多轮对话压缩成一句话。我试过用规则做压缩，效果不太好，还是模型压缩更靠谱。

6.4 性能问题的快速定位方法

性能问题我一般用“分段计时”的方法定位。在感知层、编排层、执行层、反馈层的入口和出口都打上时间戳，跑一次会话就能看到哪一层耗时最长。

如果编排层耗时最长，就进一步拆解是规划慢还是执行慢。规划慢通常是核心推理模型的问题，执行慢通常是工具的问题。这样一层层往下查，很快就能找到瓶颈。

7. 几个我踩过的坑和对应的解法

第一个坑是模型版本管理混乱。早期我同时用了好几个模型，每个模型又有多个版本，结果经常搞混哪个版本对应哪个功能。后来我建了一个模型注册表，记录每个模型的名称、版本、路径、用途、评估指标，每次更新都走注册流程，问题就解决了。

第二个坑是提示词散落在代码各处。一开始提示词直接写在 Python 文件里，改一个提示词要翻好几个文件。后来我把所有提示词抽到一个单独的配置文件里，用 YAML 格式管理，改起来方便多了，也方便做版本对比。

第三个坑是没有做灰度发布。有一次我更新了核心推理模型的提示词，直接全量上线，结果效果反而变差了。后来改成灰度发布，先放 10% 的流量，观察一天没问题再全量，风险小很多。

第四个坑是日志太多导致磁盘爆满。早期我把所有模型的输入输出都完整记录，一天就写了几十 GB 的日志。后来改成只记录摘要和关键字段，完整日志按需开启，磁盘压力小了很多。

8. 关于扩展方向的一些个人想法

这套架构目前跑得还算稳，但我觉得还有几个可以继续优化的方向。一个是模型蒸馏，把核心推理模型的能力蒸馏到小模型上，进一步降低延迟和成本。另一个是自适应路由，根据当前负载动态调整路由策略，负载高的时候把部分任务分流到小模型。还有一个是多模态扩展，目前只处理文本，后续可以加入图像和语音的处理能力。

不过这些都是后话了，当前这套体系能稳定跑起来，已经解决了我的大部分需求。如果你也在搭类似的系统，我的建议是先把核心链路跑通，再逐步优化，不要一上来就追求完美架构。