多个 Function 描述存在歧义或冲突时如何处理？

核心回答

先修正工具职责与契约，再优化路由，不能只在Prompt里强调“选对函数”。描述冲突既可能是两个接口本来做同一件事，也可能只是名称太泛、参数语义不清，或者一个面向列表、另一个面向精确对象却没写出区别。

我会通过真实错选案例定位混淆对，分别检查候选召回、工具选择、参数生成和执行调度。选择了两个相似工具与两个工具并发改同一资源，是不同问题，需要分别处理。

怎样提高区分度

名称采用领域、对象和动作等有意义信息，避免多个工具都叫“查询信息”。描述明确用途、适用条件、必需输入、返回内容及不适用场景，说明它与易混工具的区别。

参数写清ID类型、单位、时间范围、枚举值和缺失语义，不能让同一个id有时代表用户、有时代表订单。返回结构也保持一致，错误和空结果分开。

例如门店关键词搜索返回候选列表，门店详情查询需要精确门店ID。前者适合不知道具体对象时找候选，后者读取确定对象的营业信息。将这个前后关系写进契约，比给两个工具都加“智能、准确、强大”更有效。

重叠能力如何整理

完全重复的工具可以合并或保留一个稳定入口，后端选择具体实现；只有参数、权限或结果范围存在实质差异时再分别暴露。不要盲目拆出大量微小工具，也不要合成一个参数含义混乱的万能函数。

企业工具很多时，先按当前身份、可用性和任务范围过滤，再做关键词或语义召回，保留跨类别候选与扩展检索。类别可以多标签，首层路由错误应能恢复，不能把正确函数永久挡在后面。

模型仍无法判断时，可以先做明确的只读查询或补问真正缺失的条件。两个写操作互为替代时尤其不能“都试一下”。运行时检查对象、权限和资源冲突，为同资源修改安排串行、版本校验或业务事务。

如何衡量改善

为易混函数构造同义表达、边界输入、信息不足、多意图和不应调用的反例。记录候选召回率、工具选择正确率、混淆矩阵、参数有效率、无关调用和最终任务成功；再比较成本与延迟。

如果正确工具没有进入候选，修改名称后仅测最后一步模型选择仍无法解决；若候选齐全但频繁混淆，再调整描述、示例或接口粒度。每次保留工具版本和用例，避免改名或改参影响旧调用方。

技术亮点是把描述歧义、候选遗漏与运行冲突分别定位，再用对照用例证明改动有效。

对应教程

参考资料