1. 从标题拆解一套可落地的 AI 模型体系到底长什么样第一次看到“613 混合模型 × 四层智能体架构 × 安全策略编排”这个组合时我脑子里冒出来的第一个念头不是“好复杂”而是“终于有人把模型选型和智能体编排放在一张图里讲了”。过去大半年我经手过三个从零搭建的智能体项目踩过最大的坑就是模型选型跟编排层是两拨人各干各的模型侧只管把 API 吐出来编排侧只管把流程串起来结果上线之后要么是响应慢得离谱要么是某个环节的模型突然抽风导致整条链路崩掉。所以这套“613”的思路本质上是在解决一个很实际的问题——怎么让不同能力、不同成本、不同响应速度的模型在一个智能体系统里各司其职而不是一锅乱炖。先把标题里的几个核心概念翻译成人话。“613 混合模型”指的是一套模型分层策略6 个基础能力模型负责通用任务1 个核心推理模型负责复杂决策3 个专用模型负责垂直场景的精细化处理。这不是随便凑的数字后面我会详细拆解每一层的选型逻辑。“四层智能体架构”则是从感知层、编排层、执行层到反馈层的完整链路设计每一层解决不同的问题。“安全策略编排”是贯穿始终的约束机制确保智能体在可控范围内运行。这套体系适合谁来参考如果你正在做智能体平台架构设计或者手头有一个需要多模型协作的项目再或者你只是想知道“问数智能体”这类东西底层是怎么跑起来的那这篇内容应该能给你一些可以直接抄作业的思路。我不会只讲概念每个环节都会配上我实际用过的参数配置和踩坑记录。2. 613 混合模型的分层逻辑与选型实操2.1 为什么是 613 而不是别的数字组合很多人第一反应会问为什么不是 522 或者 712这个数字组合背后其实对应的是任务复杂度的分布规律。我统计过自己经手的三个项目里智能体实际调用的任务类型大致呈现这样一个分布约 60% 是简单的信息提取、格式转换、意图识别类任务约 25% 是需要多步推理的复杂决策任务剩下 15% 是垂直领域的专业任务。613 正好对应这个比例——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 StudioM2 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 性能问题的快速定位方法性能问题我一般用“分段计时”的方法定位。在感知层、编排层、执行层、反馈层的入口和出口都打上时间戳跑一次会话就能看到哪一层耗时最长。如果编排层耗时最长就进一步拆解是规划慢还是执行慢。规划慢通常是核心推理模型的问题执行慢通常是工具的问题。这样一层层往下查很快就能找到瓶颈。问题类型常见原因排查方法解决方案输出格式不稳定提示词不明确、温度过高检查提示词和温度参数加格式约束、降低温度工具调用失败参数格式错误、工具报错查看执行层日志加参数校验、修复工具上下文超限对话轮次过多检查 token 计数分级压缩对话历史性能瓶颈某层耗时过长分段计时针对性优化该层7. 几个我踩过的坑和对应的解法第一个坑是模型版本管理混乱。早期我同时用了好几个模型每个模型又有多个版本结果经常搞混哪个版本对应哪个功能。后来我建了一个模型注册表记录每个模型的名称、版本、路径、用途、评估指标每次更新都走注册流程问题就解决了。第二个坑是提示词散落在代码各处。一开始提示词直接写在 Python 文件里改一个提示词要翻好几个文件。后来我把所有提示词抽到一个单独的配置文件里用 YAML 格式管理改起来方便多了也方便做版本对比。第三个坑是没有做灰度发布。有一次我更新了核心推理模型的提示词直接全量上线结果效果反而变差了。后来改成灰度发布先放 10% 的流量观察一天没问题再全量风险小很多。第四个坑是日志太多导致磁盘爆满。早期我把所有模型的输入输出都完整记录一天就写了几十 GB 的日志。后来改成只记录摘要和关键字段完整日志按需开启磁盘压力小了很多。8. 关于扩展方向的一些个人想法这套架构目前跑得还算稳但我觉得还有几个可以继续优化的方向。一个是模型蒸馏把核心推理模型的能力蒸馏到小模型上进一步降低延迟和成本。另一个是自适应路由根据当前负载动态调整路由策略负载高的时候把部分任务分流到小模型。还有一个是多模态扩展目前只处理文本后续可以加入图像和语音的处理能力。不过这些都是后话了当前这套体系能稳定跑起来已经解决了我的大部分需求。如果你也在搭类似的系统我的建议是先把核心链路跑通再逐步优化不要一上来就追求完美架构。