Glean 企业语音工具栈升级：从检索质量到确定性执行路径的架构演进
在构建 Glean Voice 的过程中，核心发现是：语音交互的瓶颈通常不在于模型本身，而在于工具栈（Tool Stack）。
语音助手需要从企业知识库中实时提取信息并大声回答，这意味着每一次响应都依赖于在正确的时间调用正确的工具，以触达正确的企业上下文或执行正确的操作。虽然 Glean 的工具栈已在企业聊天（Chat）中经过实战检验，但语音场景暴露了新的需求层级：语音模型通常更小，上下文窗口更窄，必须在严格的延迟预算内响应，且错误操作难以回滚。在文本聊天中，模型可以在下一轮对话中悄悄修正错误的工具调用；而在语音中，用户实时听到模型的发音，任何间隙都会让体验瞬间崩塌。
这一转变将工程重心转移到了工具栈的更清洁、更严格的设计上：更好的过滤、更优的排序、更前置的工具详情展示，以及单一的标准执行路径。
核心突破：技能封装与动态检索漏斗
Glean 将工具封装为技能（Skills），将完成任务所需的工具与详细指令配对。对于每个请求，系统不再让模型从庞大的工具列表中自行挑选，而是通过动态技能与工具发现机制，先检索合适的技能，再遵循其指令调用底层工具。
这一架构带来了两个关键收益：
- 检索质量前置：复杂的动作（如“安排会议”）涉及跨时区日历协调、身份解析、冲突规避等多重逻辑。让模型直接基于裸工具重建这些逻辑既昂贵又不可靠。通过“过滤 - 排序 - 修剪”（filter-rank-trim）漏斗，系统在执行前确保检索到的技能与工具是最优的。对于语音模型而言，由于推理能力较弱且缺乏纠错机会，检索质量的提升往往能使其表现优于一个拥有更强推理能力但面对噪声工具集的模型。
- 词法信号保留：在工具列表较短且重复动词（如 send, create, update）较多的情况下，稠密嵌入（dense embeddings）往往无法区分 Slack、Gmail 或 Jira 等特定平台。Glean 发现简单的词法加权（lexical weighting） 在此场景下更有效，因为它保留了区分不同平台的稀有 token 信号。
语音场景的特殊约束：内联契约与确定性执行
文本聊天可以容忍更多的间接性，模型可以跟随链接或稍后检查模式。但语音通常无法做到这一点。
- 内联工具契约（Inline Tool Contract）：语音场景要求更多的工具契约信息前置，包括标准名称、服务器身份、参数名称以及足够的模式细节，以确保第一次调用就能正确。否则，模型填补的空白往往会导致危险的结果。这与文本模型中通过渐进式披露工具来最小化上下文开销的策略截然不同。
- 结构化重试信号：语音模型需要更多关于错误的上下文。在聊天中，通用的验证失败可能仍可恢复；但在语音中，验证错误必须作为结构化重试信号。如果系统明确指出哪个字段错误以及期望的类型，模型通常可以修复调用；如果仅收到“那行不通”的模糊反馈，该轮对话通常就会丢失。
- 动作导向的确定性：语音交互往往更侧重于动作导向的工作（如发送消息、创建事件、提交工单），这些操作具有低容错性。因此，工具栈需要支持精确重试、显式的授权状态和确定性的执行语义。Glean 通过将选择坍缩为单一标准路径（查找技能 -> 解析授权工具 -> 验证调用 -> 执行 -> 确认结果），使系统更加可预测，并防止模型在下游系统确认前就声称成功。
总结
Glean 的这次技术演进揭示了语音 AI 在企业级应用中的独特挑战。它不仅重新定义了工具调用的最佳实践，还通过架构层面的优化，让语音模型在有限的计算资源和严格的实时性约束下，依然能够执行复杂、高可靠性的企业任务。
“语音模型往往具有更少的推理能力和更少的纠错机会，因此检索到的技能和工具质量至关重要。这往往是一个非直观的结果：一个拥有更少、更干净、排名更好的技能集的语音模型，可以胜过一个从噪声工具集中工作的高推理模型。” —— Glean 技术团队
