快模型不再只是便宜替代品，而是 Agent 的默认执行层
过去的模型分层很简单：旗舰模型负责质量，快模型负责便宜的摘要、分类和客服。随着新一代快模型在编码、多模态、计算机操作和工具调用上持续提升，这条边界正在消失。
更合理的系统形态是：快模型承担大多数确定性较强的执行步骤，强模型处理高不确定、高风险和跨阶段推理，验证器决定结果是否可接受。
为什么 Agent 特别需要快模型
一个 Agent 任务往往包含十几到上百个模型回合。单轮延迟增加 500 毫秒，累积后就是明显的交互停顿；单轮多花几千 token，乘上工具重试和并发任务后会快速放大。
但快并不等于短回答。执行模型要同时满足：
- 理解工具契约；
- 在多个候选工具中稳定选择；
- 生成结构正确的参数；
- 读懂工具错误并进行有限重试；
- 维护任务状态；
- 在完成条件满足时停止。
如果其中一项不稳定，节省的推理成本会被失败回路吃掉。
生产系统应拆成四种角色
| 角色 | 主要职责 | 适合的能力 |
|---|---|---|
| 路由器 | 判断风险、难度和所需工具 | 快、稳定、低方差 |
| 执行器 | 调用工具、更新状态、完成常规步骤 | 高工具成功率、低延迟 |
| 思考器 | 处理模糊问题、异常与跨域计划 | 强推理、长上下文 |
| 验证器 | 检查事实、权限、格式和业务约束 | 独立、可复现、偏保守 |
这四个角色可以由两到三个模型承担，不必对应四个独立服务。关键是职责和上下文分开。
例如，执行器不需要看到全部战略讨论；验证器不应继承执行器“我已经完成”的自我判断；路由器只读取任务特征和风险标签，不必加载所有文档。
路由不应一次决定到底
静态地把“复杂任务”发给强模型仍然粗糙。更有效的是运行时升级：
快模型开始执行
├─ 工具成功、验证通过 → 完成
├─ 缺少信息 → 请求用户或检索
├─ 连续两次工具错误 → 升级强模型诊断
├─ 涉及不可逆动作 → 独立验证 + 人工批准
└─ 超过预算 → 保存检查点并退出
升级信号可以包括：
- 计划步骤数超出阈值；
- 工具 schema 修复次数增加；
- 同一错误重复出现；
- 输入包含冲突目标；
- 验证器无法确定；
- 需要写入生产、转账、发布或删除；
- 任务进入网络安全、医疗、法律等高风险域。
专用模型必须和专用 harness 一起看
面向安全、编码或浏览的专用模型并不是“加了领域知识的聊天模型”。它的效果高度依赖周围系统：可访问工具、网络边界、允许的动作、状态保存、验证器和回滚。
例如安全修复任务至少需要：
- 只读代码与依赖清单；
- 隔离的构建和测试环境；
- 漏洞复现用例；
- 补丁差异审查；
- 不能触达生产凭证；
- 输出可被常规 CI 重放。
如果直接给专用模型开放公网、包仓库写权限和长生命周期凭证，模型能力越强，风险越大。
评测快模型要看“尾部”
平均延迟和平均正确率不够。Agent 用户感受到的是最慢、最容易卡死的一批任务。建议记录：
- P50 / P95 / P99 端到端时长；
- 首次工具参数正确率；
- 一次完成率；
- 平均与 P95 工具调用数；
- 进入升级路径的比例；
- 升级后真正解决问题的比例；
- 验证器拒绝率；
- 每次通过任务成本。
特别要检查“便宜模型反复失败，最终仍调用强模型”的双重成本。
一套现实的模型组合
对于企业 Agent，可从以下分层起步：
- 确定性代码处理正则校验、权限检查、金额边界和状态转换。
- 快模型负责意图分类、信息抽取、普通检索和短工具链。
- 强模型负责新任务规划、异常诊断和高信息密度分析。
- 关键结果由规则、测试、第二模型或人工独立验证。
- 日志记录每次路由、升级与拒绝原因。
系统稳定后，再根据真实失败分布调整阈值。不要先假设某个模型“只适合简单任务”，也不要因为旗舰模型能力强，就让它承担大量本可确定执行的步骤。
快模型真正改变的不是价格表，而是 Agent 架构：智能不再集中在一个大脑里，而是按步骤、风险和验证成本被分配。