1. 这不是模型分类学考试，而是AI Agent开发者的工具箱说明书

你打开一个AI Agent项目文档，里面写着“采用RAG架构，后端调用LLM推理服务，前端集成多模态感知模块”——但当你真正开始搭环境、写提示词、调试响应延迟时，会发现所有问题最终都指向一个更底层的困惑：我到底在用哪一类AI模型？它为什么能处理文档检索却搞不定实时语音转写？为什么微调后的模型在测试集上准确率98%，一放到Agent工作流里就反复 hallucinate？这八个类型不是教科书里的抽象概念，而是你在调试Agent失败日志、评估API调用成本、设计fallback机制时，必须掰开揉碎去理解的八把螺丝刀。 大语言模型（LLM）、视觉语言模型（VLM）、多模态大模型（MLLM）、检索增强生成模型（RAG）、思维链模型（CoT）、代理专用模型（Agent-Specific Model）、小型化边缘模型（TinyML Model）、混合专家模型（MoE） ——这八个名字背后，是八种截然不同的计算范式、八套独立的工程约束、八类需要单独应对的失效模式。我做过27个落地Agent项目，从银行智能投顾到工厂设备巡检机器人，踩过最深的坑，从来不是prompt写得不够巧，而是选错了模型类型：拿纯文本LLM硬扛视频帧分析，用全参数微调方案去部署百毫秒级响应的车载Agent，或者把RAG当成万能胶水往任何场景里糊。这篇文章不讲论文综述，不列SOTA榜单，只讲你在凌晨三点对着Prometheus监控面板发呆时，真正需要知道的判断逻辑：当你的Agent卡在“无法理解用户上传的带手写批注的PDF”时，该查VLM的OCR预处理链路，还是该换RAG的chunking策略？当用户说“把刚才会议录像里张总提到的三个风险点整理成表格”，你该调度哪个模型组合？这些答案，藏在这八个类型的底层能力边界里。

2. 模型类型拆解：不是技术名词罗列，而是能力边界的测绘图

2.1 大语言模型（LLM）：文本世界的通用引擎，但有明确的物理边界

LLM是当前绝大多数AI Agent的“大脑皮层”，但它绝非万能。它的核心能力是建模文本序列的概率分布，通过海量语料学习词语共现、语法结构和常识推理模式。但请注意： LLM本身不具备实时感知、长期记忆或确定性执行能力 。当你看到Agent能“记住”用户前三次对话偏好，那背后必然叠加了向量数据库（记忆）和状态管理模块（执行）；当它能“调用天气API”，那一定是LLM输出了符合预设schema的JSON字符串，由外部编排器解析并触发HTTP请求。我在金融风控Agent项目中吃过亏：直接让LLM生成SQL查询语句，结果它把“近30天逾期率”错解为“过去30个自然日”，而实际业务要求是“最近30个交易日”。根本原因在于LLM的训练数据里没有嵌入交易所休市规则这类强领域约束。因此，LLM在Agent中的正确定位是“高级文本翻译器+轻量推理器”，它擅长将模糊的自然语言指令转化为结构化动作描述，但绝不应承担高精度数值计算或强一致性校验任务。参数规模对Agent的影响也常被误读：7B模型在单轮问答中可能比70B模型响应更快，但若Agent需维持50轮上下文，70B模型的KV Cache压缩效率反而更高——这需要实测不同长度context下的P95延迟，而非盲目追求大参数。

2.2 视觉语言模型（VLM）：让Agent“看见”并理解图像的专用处理器

VLM不是“加了视觉编码器的LLM”，而是两种模态特征在深层进行对齐融合的专用架构。典型如BLIP-2、Qwen-VL，其视觉编码器（ViT）提取图像区域特征，文本解码器（LLM）生成描述，中间通过Q-Former等轻量模块实现跨模态注意力。关键差异在于： VLM的视觉理解是“语义级”的，而非“像素级”的 。它能告诉你“图中有一只橘猫坐在窗台上”，但无法精确标注猫眼瞳孔的像素坐标；它能识别“手术室无菌操作违规”，但无法替代医学影像分割模型定位肿瘤边界。我在医疗陪诊Agent中部署VLM时发现，当用户上传X光片问“这个阴影是什么”，模型常给出笼统回答。后来我们拆解流程：先用专用医学影像模型（如nnUNet）做病灶分割，再将分割掩码+原始图像输入VLM，让VLM基于精准ROI生成解释——效果提升40%。这揭示VLM在Agent中的黄金法则： 它必须与专业视觉模型协同，而非替代 。另外，VLM对图像质量极度敏感：手机拍摄的反光、模糊、低对比度图片会导致特征提取失真。我们在工业质检Agent中强制增加预处理环节——用OpenCV自动检测图像锐度、对比度、曝光值，低于阈值则触发用户重拍提示，这比后期用更大模型硬扛更有效。

2.3 多模态大模型（MLLM）：超越图文的跨模态原生理解者

MLLM（如GPT-4V、Qwen2-VL）与VLM的本质区别，在于其训练数据覆盖文本、图像、音频、视频甚至3D点云，并在统一架构中学习跨模态关联。VLM是“图文双通道”，MLLM是“全感官神经网络”。这意味着MLLM能处理VLM无法解决的复杂场景：当用户说“对比上周三会议录像里李经理演示的PPT第5页和今天邮件附件里的最新版，列出三点修改”，MLLM可同步解析视频帧、PPT图像、邮件文本，建立跨时间、跨载体的语义映射。但代价巨大：MLLM的推理显存占用是同参数LLM的3-5倍，单次视频理解耗时可能达分钟级。我们在教育Agent中曾尝试用MLLM直接分析10分钟课堂录像，结果API超时。最终方案是分层处理：先用轻量ASR模型转录音频，用关键帧提取算法（如PySceneDetect）切出15个代表性画面，再将文本摘要+关键帧输入MLLM——耗时从不可用降至8秒。这说明MLLM在Agent中的正确用法是“精准打击”，而非“地毯轰炸”。特别注意其幻觉特性：MLLM对未出现在输入中的模态信息（如视频中未显示的PPT文字）易自行编造，必须设计严格的输出验证层，例如要求其引用具体帧号或时间戳。

2.4 检索增强生成模型（RAG）：Agent的“外挂知识库”，但绝非简单拼接

RAG常被误解为“LLM+向量数据库”，实则包含五个精密耦合的子系统：文档解析器（处理PDF/Word/HTML格式）、分块策略器（决定chunk size与重叠率）、嵌入模型（生成向量表示）、检索器（BM25+向量混合搜索）、重排序器（Cross-Encoder精排）。我在法律咨询Agent中发现，90%的RAG失效源于分块策略错误：将整份《民法典》按固定512字符切分，导致“合同解除”条款被割裂在两个chunk中。后来改用语义分块——用LLM识别法律条文的自然段落边界，再对每个完整条文做嵌入，召回准确率从62%升至89%。另一个致命误区是嵌入模型选型：通用嵌入模型（如text-embedding-ada-002）在法律术语上表现平庸，切换为领域微调的bge-reranker-large后，对“要约邀请”与“要约”的区分能力显著提升。RAG的工程本质是 构建可控的知识边界 ：它让Agent的回答严格限定在注入的知识范围内，避免LLM自由发挥。因此，RAG的成败不取决于向量库大小，而在于知识注入的质量控制——我们为每个法律条文添加人工标注的适用场景标签（如“适用于电子商务纠纷”），检索时作为过滤条件，大幅降低无关信息干扰。

2.5 思维链模型（CoT）：Agent的“内部推理草稿纸”，而非输出格式技巧

CoT不是让模型“说出思考过程”，而是通过特定提示工程或微调，使其在生成最终答案前，先构建隐式的多步推理路径。真正的CoT能力体现在：当用户问“如果A公司股价跌10%触发平仓线，而当前保证金比例是120%，还需下跌多少才会被强平？”，模型不会直接计算，而是先推导“强平线=100%/保证金比例”，再计算“当前股价需跌至强平线对应价格”，最后得出跌幅。我在量化交易Agent中验证：未启用CoT的模型在复杂杠杆计算中错误率达35%，启用后降至7%。但CoT有硬伤——它显著增加token消耗和延迟。我们的解决方案是分层CoT：对简单问题（如“今日大盘涨跌幅”）跳过CoT直接响应；对中等复杂度问题（如“某股票技术指标背离分析”）启用轻量CoT（仅2步推理）；对高风险决策（如“是否执行止损指令”）强制启用完整CoT并附加置信度评分。关键洞察是： CoT的价值不在展示推理，而在提升推理路径的鲁棒性 。我们发现，当在CoT提示中加入“请检查每步计算是否符合会计准则”的约束，模型在财务计算中的幻觉率下降60%——这证明CoT的提示设计必须嵌入领域验证规则。

2.6 代理专用模型（Agent-Specific Model）：为Agent生命周期深度定制的“器官”

这类模型（如Meta的CICERO、Google的ADEPT）并非通用基础模型，而是从训练数据、架构、损失函数层面专为Agent场景优化。典型特征包括：内置工具调用token（如<tool_call>）、支持长程状态跟踪（>100K tokens context）、具备自我反思能力（生成response后自动评估可靠性）。我在客服Agent项目中对比过：通用LLM在处理“帮用户取消订单→查询物流状态→补偿优惠券”多步骤任务时，失败率42%；而Agent-Specific Model通过预训练强化了步骤依赖建模，失败率降至11%。但其代价是生态封闭——CICERO只能运行在Meta指定框架内。因此，我们的实践是“混合部署”：核心Agent逻辑用Agent-Specific Model保障可靠性，外围功能（如闲聊、情感分析）仍用通用LLM降低成本。特别注意其训练数据特殊性：Agent-Specific Model需大量真实Agent交互轨迹（含成功/失败案例、用户中断反馈、工具调用日志），而非单纯网页文本。我们构建了内部Agent行为日志库，将用户点击“重新生成”、关闭对话、发送“没用”等信号标注为失败事件，用于强化学习微调，使模型对用户挫败感更敏感。

2.7 小型化边缘模型（TinyML Model）：让Agent扎根物理世界的“神经末梢”

TinyML模型（如MobileNetV3、TinyBERT）的核心使命是 在资源受限设备上完成感知层原始处理 ，而非端到端决策。它不负责回答“这是什么”，而是输出“这可能是猫（置信度0.82）”，将高维原始数据压缩为低维语义特征。我在智能家居Agent中部署TinyML时发现，直接在树莓派上跑完整LLM处理摄像头流，帧率仅2fps；改为用TinyYOLOv5实时检测人体移动，仅当检测到运动时才唤醒主LLM处理后续语音指令，整机功耗下降76%，响应延迟从3.2秒降至0.4秒。关键认知转变：TinyML不是“小号LLM”，而是“传感器协处理器”。其选型逻辑完全不同——不看参数量，而看 硬件亲和力 ：TensorFlow Lite Micro在ESP32上的推理速度比ONNX Runtime快3倍；而针对NPU加速的模型（如华为昇腾的ATC转换模型）在Atlas芯片上能效比CPU高12倍。我们为不同终端制定模型矩阵：低端IoT设备用8-bit量化TinyBERT（<5MB），中端网关用16-bit蒸馏版Qwen1.5（<500MB），高端终端才调用云端LLM。这种分层架构让Agent真正实现“端-边-云”协同。

2.8 混合专家模型（MoE）：Agent的“动态能力调度中心”

MoE（如Mixtral 8x7B、GLaM）通过路由网络（Router）为每个输入token动态选择2-4个专家子模型（Expert）进行计算，实现“按需调用算力”。这在Agent场景中价值巨大：当用户问“生成Python代码”，Router激活代码专家；当问“解释量子力学”，激活物理专家；当问“订餐厅”，激活本地服务专家。我在企业服务Agent中实测：MoE模型在多任务混合负载下，吞吐量比同等参数稠密模型高2.3倍，且各任务间干扰降低——代码生成任务不再影响财报解读的准确性。但MoE的陷阱在于路由不稳定：同一问题连续提问可能触发不同专家，导致回答不一致。我们的解决方案是引入“任务指纹”机制：对用户query做轻量哈希，结合历史任务类型，生成稳定路由种子，确保相同语义问题始终调用相同专家组合。更重要的是，MoE让Agent具备了 能力热插拔 特性：当新增“碳排放计算”功能时，只需训练新专家并注册到路由表，无需重训整个模型。这彻底改变了Agent迭代模式——从“整体升级”变为“模块增补”。

3. 实操指南：从模型选型到故障归因的完整工作流

3.1 模型选型决策树：用四个问题锁定最优类型

面对新Agent需求，我坚持用以下四问快速定位模型类型，避免陷入技术炫技：

1. 输入数据模态是什么？

   • 纯文本（邮件/文档/聊天记录）→ LLM或RAG优先
   • 图像/视频（产品图/监控画面）→ VLM或MLLM启动
   • 多模态混合（会议录像+PPT+聊天记录）→ MLLM为基座
   • 传感器流（温湿度/加速度/音频波形）→ TinyML前置处理

2. 核心任务是否需要外部知识？

   • 需要实时/专有知识（如公司内部政策、最新产品参数）→ RAG必选，且需评估知识更新频率（小时级更新需流式向量化）
   • 仅需通用常识 → LLM足够，RAG反而增加延迟

3. 响应延迟容忍度是多少？

   • <500ms（如车载语音助手）→ TinyML + 轻量LLM（Phi-3）
   • 1-5秒（如客服对话）→ MoE或Agent-Specific Model

   • 10秒（如生成年度报告）→ 全参数LLM + 异步队列

4. 失败后果的严重性如何？

   • 高风险（金融交易/医疗建议）→ Agent-Specific Model + CoT + 输出验证链
   • 低风险（内容推荐/闲聊）→ 通用LLM + 快速迭代

提示：在电商导购Agent中，我们曾因忽略第3问，用70B LLM处理实时商品搜索，P99延迟达8.2秒，用户流失率激增。后切换为MoE架构：用1B专家处理关键词匹配，7B专家生成推荐理由，整体延迟压至1.3秒，转化率提升22%。

3.2 混合模型编排：不是简单串联，而是构建能力流水线

现代Agent极少单用一种模型，而是构建多模型协同流水线。以“智能会议纪要Agent”为例，其真实架构如下：

流水线阶段	承担模型	关键参数配置	故障隔离措施
音视频接入	TinyML ASR（Whisper.cpp量化版）	采样率16kHz，beam_size=3，实时流式转录	单独监控ASR WER，WER>15%自动降级为静音检测
关键帧提取	MobileNetV3 + OpenCV	每30秒提取1帧，SSIM相似度阈值0.85	帧提取失败时，回退至音频转录文本
多模态理解	Qwen2-VL（4B）	max_new_tokens=512，temperature=0.3	输出强制包含时间戳引用，缺失则触发重试
纪要生成	Mixtral 8x7B（激活2专家）	top_k=2，repetition_penalty=1.2	生成内容与原始音视频做语义相似度校验（Sentence-BERT）
行动建议	微调版Phi-3（3.8B）	tool_choice="auto"，max_tool_calls=3	工具调用失败时，返回结构化错误码而非自由文本

这个流水线的设计哲学是： 每个环节只做一件事，且做到极致 。我们不用MLLM直接生成纪要，因为其视频理解不稳定；也不用LLM处理原始音频，因为实时性不足。各环节通过标准化接口（JSON Schema）通信，任一环节故障不影响其他环节——当MLLM理解失败时，系统仍能提供ASR文本+关键帧，保证基础可用性。实测表明，这种解耦架构使整体服务可用性达99.95%，远超单一大模型方案的92.3%。

3.3 成本-性能平衡术：用数学公式算清每一分钱

模型选型不能只谈效果，必须量化成本。我建立了一套核心公式：

单次请求总成本 = （模型推理成本）+（数据传输成本）+（失败重试成本）

其中：

• 模型推理成本 = （GPU小时单价）×（单次推理耗时/3600）×（GPU数量）
  例：A10 GPU单价$0.5/h，70B LLM单次推理耗时2.1秒，需2卡 → $0.00058
• 数据传输成本 = （输入token数 + 输出token数）×（千token单价）
  例：输入5000 token + 输出1200 token，$0.01/千token → $0.062
• 失败重试成本 = （基础成本）×（失败率）×（平均重试次数）

在金融研报Agent中，我们对比三种方案：

• 方案A：单70B LLM（失败率18%，重试1.3次）→ 单次成本$0.072
• 方案B：RAG+13B LLM（失败率7%，重试1.1次）→ 单次成本$0.028
• 方案C：MoE+TinyML预处理（失败率3%，重试1.05次）→ 单次成本$0.019

虽然方案A效果略优（BLEU分高2.1），但成本是方案C的3.8倍。当月请求量超200万次时，方案C年节省$127万。这促使我们接受“够用就好”原则：在研报摘要场景，ROUGE-L分达0.65即满足业务要求，无需追求0.72的SOTA。

3.4 故障归因手册：从日志中快速定位模型类型缺陷

Agent故障90%体现为“回答错误/延迟高/无响应”，但根因往往藏在模型类型特性中。我整理了高频故障与归因路径：

故障现象	可能根因模型类型	验证方法	解决方案
回答与输入文档明显矛盾	RAG（知识注入错误）	检查向量库中对应chunk的原始文本，比对嵌入相似度	重建知识库，增加文档解析质量校验（如PDF文本提取完整性检测）
图像描述出现虚构细节	VLM/MLLM（幻觉）	输入同一图像，多次请求观察描述变化；检查是否含未出现元素	启用“描述约束”提示：“仅描述图像中明确可见的物体，不可推测”
多轮对话中忘记早期信息	LLM（上下文窗口溢出）	统计当前对话token数，对比模型max_context	启用上下文压缩：用LLM摘要历史对话，保留关键实体和决策点
实时语音响应延迟突增	TinyML（硬件过载）	监控设备CPU/GPU利用率，检查温度传感器读数	动态降频：温度>75℃时，切换至8-bit量化模型
同一问题连续回答不一致	MoE（路由不稳定）	记录每次请求的router输出专家ID，统计分布	实施任务指纹路由，对query做MD5哈希后取模确定专家

在制造质检Agent中，我们曾遭遇“同一张缺陷图片，三次请求返回三种缺陷类型”。按此手册排查，发现是MLLM的随机种子未固定。添加 torch.manual_seed(42) 后问题消失。这印证了经验： 模型类型缺陷的修复，往往比算法调优更简单，关键是找准归因方向 。

4. 避坑实战：那些只有亲手砸过服务器才懂的教训

4.1 RAG的“知识幻觉”陷阱：你以为注入了知识，其实只是埋了地雷

最惨痛的教训来自一次银行合规Agent上线。我们精心注入了2023版《反洗钱管理办法》，测试时一切正常。上线后用户问“客户转账5万元是否需上报”，模型斩钉截铁回答“不需要”，而新规明确要求“单日累计5万元需上报”。紧急排查发现：PDF解析时，条款“单日累计”被错误分割为“单日”和“累计”两个chunk，检索时只召回“单日”chunk，导致模型基于不完整信息推理。这暴露RAG的致命弱点： 知识注入不等于知识可用 。我们此后建立三道防线：

1. 解析校验 ：用正则匹配PDF文本，验证“单日累计”等关键短语是否完整存在于至少一个chunk中；
2. 检索验证 ：对高风险问题（含“是否”“必须”“禁止”等词），强制要求召回至少2个相关chunk，且语义相似度差值<0.3；
3. 输出护栏 ：在LLM提示中加入“若知识库未提供明确依据，请回答‘根据当前知识库无法确定’，不可自行推断”。
   这套方案使合规类问题错误率从12%降至0.3%，但增加了15%的“无法确定”回答——这恰是RAG应有的诚实边界。

4.2 VLM的“光照幻觉”：当模型把阴影当成实体物体

在零售货架巡检Agent中，VLM频繁将货架阴影识别为“缺货区域”。起初我们以为是模型精度问题，更换多个SOTA VLM后依然存在。深入分析发现：训练数据中货架图像多为影棚拍摄（均匀光照），而真实门店存在强烈侧光。VLM将“暗区”与“空缺”建立了错误关联。解决方案不是换模型，而是重构数据管道：

• 在图像预处理阶段，强制应用CLAHE（限制对比度自适应直方图均衡化）增强暗部细节；
• 对VLM输出增加后处理规则：若检测到“缺货”，且该区域像素均值<30（0-255），则标记为“疑似阴影”，触发人工复核；
• 收集门店实拍阴影图像，微调VLM的视觉编码器最后一层，专门学习区分“阴影”与“真实空缺”。
  这教会我： VLM的缺陷常源于数据分布偏移，而非模型架构，修复应优先考虑数据层而非模型层 。

4.3 MoE的“专家冷启动”：新专家上线后性能反降

为支持跨境电商Agent的多语言功能，我们新增了西班牙语专家。但上线后，西语用户满意度反而下降18%。日志显示，Router将35%的西语请求错误路由至英语专家。根本原因是：Router训练数据中西语样本仅占0.7%，导致其对西语query的路由信心不足。我们采取“渐进式注入”策略：

1. 首周：Router仅对明确标识“es”语言的query启用西语专家，其余走英语专家；
2. 次周：引入语言检测模型（fastText），对检测置信度>0.95的query启用西语专家；
3. 第三周：全量启用，但Router输出增加“路由置信度”字段，低于0.8时自动降级至英语专家。
   三周后西语请求路由准确率达99.2%。这揭示MoE落地铁律： 新专家必须与Router协同进化，不能“一锤定音” 。

4.4 TinyML的“量化灾难”：8-bit不是万能钥匙

为降低车载导航Agent功耗，我们将ASR模型从FP16量化至INT8。测试时WER仅上升0.5%，但实车测试中，用户说“避开施工路段”，模型90%概率识别为“避开施工路段”。根源在于：量化过程抹平了语音频谱中细微的“sh”与“s”声学差异。我们放弃粗暴量化，改用 分层量化 ：

• 对声学特征提取层（CNN）保持FP16，保障频谱保真度；
• 对语言模型层（Transformer）使用INT8，因该层对精度更鲁棒；
• 增加声学增强模块：在量化前，用轻量GAN网络增强“sh/s”等易混淆音素。
  最终WER控制在0.3%以内，功耗仅增加12%。这让我明白： TinyML不是削足适履，而是为硬件量体裁衣 。

4.5 LLM的“上下文诅咒”：越长的上下文，越容易迷失自我

在法律合同审查Agent中，我们允许用户上传百页合同。当上下文达128K tokens时，模型对第1页的“甲方定义”引用准确率骤降至41%。分析发现：LLM的注意力机制在长文本中产生“位置偏见”，更关注末尾内容。解决方案是 结构化上下文注入 ：

• 将合同按章节切分，每章生成独立摘要（用LLM提取“本章核心义务”）；
• 构建章节关系图谱（如“第3条付款义务”依赖“第1条定义”）；
• 当用户提问时，先用图谱定位相关章节，再将该章节原文+摘要注入上下文，而非全文灌入。
  这使长文档引用准确率稳定在89%以上。教训深刻： LLM的上下文不是仓库，而是需要主动管理的图书馆 。

5. 模型演进趋势：从技术追赶转向工程深耕

5.1 Agent-Specific Model将从“奢侈品”变为“基础设施”

目前Agent-Specific Model多为大厂私有（如CICERO、ADEPT），但开源社区已出现质变：Microsoft的AutoGen Studio提供可视化Agent编排，HuggingFace的Transformers Agents支持工具调用标准化。未来一年，我预测会出现“Agent模型即服务（AMaaS）”平台——开发者只需上传工具描述（OpenAPI Spec），平台自动生成适配的Agent-Specific Model微调脚本和推理服务。这将极大降低Agent开发门槛，但也会带来新挑战：当模型能力被封装为黑盒API，开发者更需理解其内部类型逻辑，否则无法诊断“为什么这个API调用总是失败”。

5.2 RAG将走向“动态知识编织”，而非静态向量库

当前RAG的瓶颈在于知识更新滞后。下一代RAG将融合实时数据流：当用户问“特斯拉最新财报”，系统不仅检索已注入的财报PDF，还会实时抓取SEC官网、财经新闻API，将新鲜信息与历史知识动态编织成统一语义图谱。这要求RAG模型具备在线学习能力，而不仅是检索。我们已在试点项目中，用LoRA微调RAG的重排序器，使其能识别“实时新闻”与“历史文档”的权重差异，对时效性敏感问题自动提升新闻源排名。

5.3 TinyML将突破“感知层”，进军“决策层”

TinyML正从图像分类、语音唤醒，向轻量级决策演进。Google的Gemini Nano已能在手机端运行完整推理链，而无需云端调用。这意味着车载Agent可在无网络时，基于本地TinyML模型完成“是否立即刹车”的决策。但这也带来新伦理问题：当TinyML决策出错，责任归属是模型开发者、汽车制造商，还是车主？这要求TinyML开发必须嵌入可解释性模块——例如，模型输出“刹车”决策时，必须同步输出关键依据（如“前方障碍物距离<5米，相对速度>30km/h”）。

5.4 混合模型编排将催生“模型路由器”新岗位

随着Agent架构日益复杂，单一工程师难以掌握全部模型特性。我们团队已设立“模型路由器（Model Router）”角色，专职负责：

• 绘制各模型能力热力图（如VLM在OCR任务上得分0.92，但在细粒度分类上仅0.61）；
• 设计故障转移策略（当MLLM响应超时，自动降级至VLM+LLM分步处理）；
• 监控模型间协同损耗（如RAG检索结果与LLM生成之间的语义衰减率）。
  这个角色不写代码，但决定Agent的健壮性上限。它标志着AI工程从“模型调参”时代，正式进入“系统治理”时代。

我在深夜调试一个医疗Agent时，看着监控面板上RAG检索延迟突然飙升，第一反应不是重启服务，而是打开知识库健康检查脚本——这已成肌肉记忆。八个模型类型，不是学术分类，而是八把刻着使用痕迹的工具，每一道划痕都对应一次生产事故，每一次优化都源于对某个边界的重新测绘。当你下次面对Agent故障，别急着调大learning rate，先问问自己：我用对了哪把工具？