模型微调 vs 提示词注入：工具调用架构路线全方位权衡

两大技术路线的根本分歧

路线 A（In-Context 方案）：使用顶尖通用大模型（如 Claude 3.5 Sonnet / GPT-4o），在每次请求中通过 System Prompt 动态附带工具 Schema；
路线 B（微调专用模型方案）：收集数万条垂直领域的工具调用轨迹，对开源中轻量模型（如 8B~14B）进行深度微调（SFT / LoRA）。

第一项是工具文档的体积占比。把当前 Schema 全量注入后的提示长度记下来，与平均对话长度对比：如果工具说明占了主要部分，说明每轮都在为静态信息重复付费，缓存或微调才有意义。

第二项是调用分布的稳定性。统计一段时间内实际被调用的工具数量，很多注册表里长期只有一小部分工具被真正使用，这决定了是否值得为固定的小集合做训练。

第三项是错误类型的可归因性。把线上失败分成"选错工具""参数格式错""幻觉出不存在的工具"三类，In-Context 路线通常靠改描述与命名修复，微调路线才适合纠正格式类问题。

混合方案是多数团队的现实答案：用 In-Context 覆盖长尾与实验期工具，等某类调用稳定并成为主流量后，再把它单独蒸馏给小模型，切换过程用同一批用例做离线对比。

准备一份固定评测集，条目建议覆盖三类：常规单选工具、需要多步串联、以及干扰项（描述相近的近似工具）。两条路线在同一集合上跑，重点看参数格式合法率与工具选择命中率，而不是回答是否"好看"。灰度时保留一键回退到基线模型的开关，任何命中率明显劣化都要能立即切回。

判断标准可以量化：先用一周线上数据算出"工具文档 Token 占总 Token 的比例"和"实际被使用工具数占注册表的比例"。当前者很高而后者很低时，微调或缓存的收益才真正成立；反之说明瓶颈在工具描述质量，先去改提示与命名，不要急着上训练流水线。