AI Agent工具调用边界case：路由错误比想象中更脆弱

一旦对话系统接入了超过一个外部工具——数据库查询、日历预订、支付处理等——就会产生一种全新的失败类别，这种失败与单个工具本身是否正常工作无关。模型首先需要判断某个请求实际上应该调用哪个工具，而这个路由决策在开发阶段往往被视为微不足道，但一旦真实世界里略微模糊的用户请求开始涌入，就成了整个系统中最脆弱的环节之一。

这一类别属于现代模型架构中通常讨论的 tool calling 或 function calling 范畴——模型会获得一组可用的工具，每个工具都有名称、描述和定义的输入模式，然后需要根据用户消息选择正确的工具，在此之前不会发生任何其他操作。大多数 tool calling 演示使用的请求都是恰好只有一个工具明显正确的情况，比如"预约 appointment"显然应该调用预订工具，"查询余额"显然应该调用账户查询工具。真实对话很少这么干净，真正重要的路由失败恰好发生在两个工具对某个请求都看起来合理的灰色地带。

路由选择真正出问题的地方

这种情况在一个系统同时拥有通用知识库搜索工具和更具体的结构化查询工具时会不断出现，例如通用 FAQ 检索工具和专门的订单状态工具。用户问"我的订单到哪了"显然属于订单状态工具的领地。用户问"损坏商品的退货政策是什么"在两个工具之间就处于更模糊的边界了，因为它既可以合理地被视为通用知识问题由 FAQ 工具处理，也可以被视为足够具体的东西需要更有针对性的查询——如果系统恰好有这样一个工具的话。没有明确的路由指引，模型在两者之间的选择可能真正不一致，有时调用这个，有时调用那个，对于措辞略有不同的功能相同的请求。

选择错误工具的后果很少是戏剧性的失败，这也是为什么这个问题在生产环境中比更明显的 bug 静默存在更长时间的原因之一。错误的工具仍然经常返回一些东西——通用信息而不是用户实际需要的具体结构化答案，或者触发了一个结构化查询来回答一个本需要更广泛上下文解释的问题。响应不能算错，它只是比正确工具会产生的结果更窄或更不有用，而这种微妙降级的输出很少会产生与完全失败相同的清晰错误信号，使得通过正常监控很难发现。

第二个更具后果性的版本涉及具有真实副作用的工具——预订操作、支付触发、数据库写入。在只读工具和具有写入能力的工具之间进行模糊路由的后果，比两个只读工具之间的模糊路由风险高得多，因为错误触发的写入操作无法像错误检索的信息那样被悄悄纠正。用户问"我能把预约改到周四吗"这件事在检查可用性的工具和实际重新安排预订的工具之间处于真正模糊的边界，而一个通过默认向更具后果性的操作来解决这种模糊问题的系统，而不是先确认意图，恰恰创造了最容易侵蚀信任的那种失败。

为什么仅靠工具描述很少能解决这个问题

修复模糊路由最常见的第一步尝试是简单地，为每个工具编写更详细的描述，扩展解释每个工具的作用及何时使用。这确实在某种程度上有帮助，但仅靠描述质量往往会在一类特定问题上遇到瓶颈——即请求落在两个工具合法用例的实际重叠区域，而不是明确属于其中一个的情况。再精确的措辞也无法完全解决一个本质上模糊的请求，因为模糊性是请求本身的属性，而不是工具解释得不够清楚的问题。

更有效的方法是在系统提示中构建一个明确的消歧层，独立于并先于工具选择步骤本身，指示模型识别一个请求是否可能映射到多个可用工具，然后要么提出简短的澄清问题，要么应用一个明确的、声明过的决胜规则，而不是静默地选择一个选项并继续。决胜规则可能看起来像这样：当一个请求可以合理地由通用知识工具或订单特定工具处理时，只要对话中任何地方出现订单引用，就优先使用订单特定工具，只有当不存在这种引用时才回退到通用工具。这种明确的、声明过的优先级规则会确定性地解决模糊性，而不是将其留给模型在特定一次传递中隐含判断所倾向的任何结果——而正是这种隐含判断产生了一致性问题。

对于涉及具有写入能力操作的更高风险情况，更重要的指示实际上根本不是更好的消歧，而是在触发请求对意图存在轻度模糊时，明确要求在任何具有真实副作用的工具被调用之前进行确认，而不是试图将路由准确性完善到让确认显得不必要的程度。这涉及到一个更广泛的设计原则，有时被称为分层权限处理，工具不被视为在模型允许调用它们的置信度上均等——只读工具可以根据合理推断调用，而具有真实后果的工具需要在指令中内置明确的确认步骤，无论模型的路由判断在那一刻恰好有多自信。

针对这一点进行测试

工具路由可靠性，像结构化输出可靠性一样，抵制随意的对话式审查，因为人类在阅读示例对话时会自然地关注最终答案是否听起来正确，而不是静默产生它的具体是哪个工具。捕获路由不一致需要故意构建位于可用工具之间实际模糊重叠区域的测试用例，而不是只测试明确明显属于某个工具或另一个工具的请求，因为那些干净的情况会可靠地通过，无论底层路由逻辑实际上是否健全。

为对话系统添加更多工具会扩大其能力，也会增加系统可能悄悄出错的决策点数量——在任何人都实际测试的最终响应质量部分之前。工具选择值得拥有自己的明确指示层、自己的明确决胜逻辑来处理真正模糊的情况，以及自己对任何具有真实后果的操作的分层确认要求，而不是被视为一个简单的、不言自明的路由步骤——一旦每个单独的工具被描述清楚就会自然解决。

具体的客户端工具架构和路由逻辑因此工作的性质属于保密范畴。很高兴通过适当的渠道与任何构建多工具对话系统的人讨论工具选择和消歧设计的一般方法。

Written by Mohammad Farhan Habib Faraz Senior Prompt Engineer and Prompt Team Lead at PowerinAI www.powerinai.com