≈1/10重构后的上下文输入长度（相比原全量方案）
p90 < 5s端到端响应时延
92%目标工具进入 Top-30 候选集的召回率
50% → 88%最终工具选择与参数填充综合准确率
全量注入的代价：既慢，又容易“看花眼”
最初的基线方案将 400 多个工具的完整 JSON 定义一次性塞给大模型，单次输入超过 80,000 tokens。这不仅导致首字输出（TTFT）动辄超过 5 秒，超长上下文还引发了严重的注意力分散，最终调用准确率仅有 50% 左右。车载语音交互容不得漫长的多轮反思，破局点必须放在进入主模型之前的上下文瘦身上。
围绕真实口语指令设计“三路召回”
用户在车里的说法千奇百怪：仅靠检索工具的“功能描述”，很容易漏掉像“放首歌”这样简短口语对应的媒体接口；而只看“工具名称”，又无法理解“回首页”其实对应着“页面导航工具”里的一个枚举参数。
为此，我设计了覆盖工具描述、工具名称与参数定义的三路混合检索机制：先识别指令所属的功能域（Domain），再补充跨领域的强相关候选，最终将去重后的 30 个高置信度工具交给主模型做最终决策与填参。
拆解指标：把速度、召回与执行看清楚
在阶段性验证中，输入 tokens 被压缩至原来的约 1/10，端到端响应时延成功收敛至 p90 < 5 秒；目标工具在候选集中的召回率达到 92%，最终调用准确率从 50% 跃升至 88%。
指标边界：我们将“召回率（92%）”与“最终准确率（88%）”严格区分——前者检验检索层有没有把正确工具找出来，后者检验主模型能不能选对并填准参数；同时，p90 < 5 秒代表统计分布达标，尚不等于极端长尾指令下的绝对硬实时保证。完成该架构验证后，方案正式移交业务团队做工程化落地。