两大技术路线的根本分歧
- 路线 A（In-Context 方案）：使用顶尖通用大模型（如 Claude 3.5 Sonnet / GPT-4o），在每次请求中通过 System Prompt 动态附带工具 Schema；
- 路线 B（微调专用模型方案）：收集数万条垂直领域的工具调用轨迹，对开源中轻量模型（如 8B~14B）进行深度微调（SFT / LoRA）。
权衡决策矩阵
- 灵活性：In-Context 占绝对优势。新增或修改一个工具只需修改 JSON 即可生效；而微调路线需要重新拉取训练流水线与回归测试；
- Token 开销与延迟：微调路线占优。模型已对工具协议形成神经突触记忆，无需在每轮对话中重复传输几千 Token 的工具文档，首字延迟显著降低；
- 架构选型结论：高变动性、宽泛的通用业务工具采用 In-Context；高频固定、对延时和隐私有极致要求的封闭场景采用微调小模型。
选型前先做三项测算
第一项是工具文档的体积占比。把当前 Schema 全量注入后的提示长度记下来，与平均对话长度对比：如果工具说明占了主要部分，说明每轮都在为静态信息重复付费，缓存或微调才有意义。
第二项是调用分布的稳定性。统计一段时间内实际被调用的工具数量，很多注册表里长期只有一小部分工具被真正使用，这决定了是否值得为固定的小集合做训练。
第三项是错误类型的可归因性。把线上失败分成"选错工具""参数格式错""幻觉出不存在的工具"三类，In-Context 路线通常靠改描述与命名修复，微调路线才适合纠正格式类问题。
两条路线的成本结构对比
| 维度 | In-Context 通用大模型 | 微调小模型 |
|---|---|---|
| 新增工具 | 改配置即生效 | 需重训与回归 |
| 单请求成本 | 随上下文长度线性上升 | 训练后单轮推理成本低 |
| 上线周期 | 小时级 | 天到周级 |
| 私有化部署 | 依赖外部 API 或大显存 | 单机可跑 |
| 质量下限 | 由基座模型保证 | 由数据质量决定 |
| 失败可解释性 | 可直接读提示定位 | 需回溯训练样本 |
混合方案是多数团队的现实答案：用 In-Context 覆盖长尾与实验期工具，等某类调用稳定并成为主流量后，再把它单独蒸馏给小模型，切换过程用同一批用例做离线对比。
验证方法
准备一份固定评测集，条目建议覆盖三类：常规单选工具、需要多步串联、以及干扰项（描述相近的近似工具）。两条路线在同一集合上跑，重点看参数格式合法率与工具选择命中率，而不是回答是否"好看"。灰度时保留一键回退到基线模型的开关，任何命中率明显劣化都要能立即切回。
常见故障速查
| 现象 | 原因 | 处理 |
|---|---|---|
| 微调模型调用不存在的工具 | 训练集含旧的或虚构工具名 | 清洗标签并对齐当前注册表 |
| 输出 JSON 偶发缺字段 | 训练样本缺少该字段场景 | 补充该分支样本再加格式约束解码 |
| 长列表工具下选择漂移 | Schema 过多注意力被摊薄 | 先做一层候选检索再注入 |
| 成本不降反升 | 每轮重复携带工具文档 | 启用缓存或裁剪未使用工具 |
| 小模型复杂任务成功率低 | 基座推理能力不足 | 保留升级到通用大模型的路径 |
小结
判断标准可以量化：先用一周线上数据算出"工具文档 Token 占总 Token 的比例"和"实际被使用工具数占注册表的比例"。当前者很高而后者很低时，微调或缓存的收益才真正成立；反之说明瓶颈在工具描述质量，先去改提示与命名，不要急着上训练流水线。