Agent tool selection: The tool your agent almost called

AI 代理工具选择：代理几乎调用的工具

TL;DR

• 我们做了什么：我们在购物代理的工具前添加了一个决策模型。它选择工具并为每个选项返回一个概率，聊天模型负责填充参数。每次选择都会在 Phoenix 中生成独立的追踪跨度。

• 分数揭示的问题：在 100 条测试消息中，置信度低于约 0.7 的选择有三分之一导致错误转向。在 0.7 到 0.8 之间错误率约为六分之一，高于 0.8 时错误率低于十分之一。这个阈值由我们设定，文章展示了如何找到属于你的阈值。

• 我们如何应用：当决策模型置信度低于 0.7 时，我们忽略其选择，让聊天模型自行选择工具。空回复或未完成回复的数量从 21 降至 3，评判者认为工具调用的准确性与之前相当。

• 使用方法：Phoenix 将每个选择显示为独立跨度，允许你在旁边添加评分并按评分过滤。最后一部分展示了具体操作方式，以及如何在你自己的代理上执行相同检查。

大多数代理选择工具的方式相同。聊天模型阅读对话，选择工具并填写参数，所有操作都在一次调用中完成。追踪显示模型执行的调用及其参数和结果。但追踪未显示选择过程，你永远看不到模型权衡的其他工具选项，也看不到选择的接近程度。

我们尝试了不同的拆分方式。我们将选择任务交给决策模型，在我们案例中使用 OpenAI 的 Decisions API。决策模型接收选项列表并为每个选项返回概率，不生成任何文本。聊天模型继续负责调用工具和填写参数。Phoenix 现在支持决策追踪，新增了 DECISION 类型的跨度用于此场景。每个选择都会落在这些跨度之一，显示模型拒绝每个选项的概率。

随后我们编写了 100 条购物者可能输入的消息，将每条消息通过演示代理运行并评分。决策模型最不确定的选择（置信度低于 0.7）比其他选择更频繁地导致错误。

因此我们添加了规则：当置信度低于 0.7 时，让聊天模型自行选择工具，就像添加决策模型前一样。与始终强制执行路由选择相比，置信度阈值将空回复或未完成回复从 21 降至 3（每个版本 300 次交互）。原始代理在本次测试中没有空回复或未完成回复。

如果你的代理调用工具，这篇博客就是为你准备的。读完本文后，你将知道如何解读决策模型为每个工具选择提供的置信度评分，如何为你的代理找到合适的阈值，以及如何处理低于设定阈值的选择。

置信度 0.7 或更高时信任路由选择，否则让聊天模型按一贯方式选择。

尝试 Arize AX

使用 Arize 构建更优秀的代理

追踪、评估和学习。使用 Arize AX 构建代理，立即开始追踪你的运行。

开始使用

查看 AX 文档

更喜欢开源？尝试 Arize Phoenix 实现自托管的开源代理可观测性。

当决策模型处理工具选择时发生了什么变化？

我们的测试代理是 Wonder Toys，一个演示玩具商店。购物者输入一条消息，代理有五种工具可供使用来回答。它可以搜索目录、展示一件产品、购买它、查看订单或取消订单。我们用相同的 100 条测试消息通过代理的三个版本进行了测试。所有三个版本共享相同的提示、相同的五种工具和相同的聊天模型。唯一的区别是选择工具的主体。

• 默认方式：聊天模型自行选择工具，不涉及决策模型。

• 强制执行：决策模型选择工具，聊天模型必须调用该工具。

• 置信度 0.7 以上：仅当决策模型的置信度达到 0.7 或更高时，才使用其工具调用选择。低于该阈值时，聊天模型自行选择。

每个版本都看到每条消息三次，总共 900 轮。决策模型是 OpenAI 的 gpt-6-luna。从现在起我们称其为路由器，因为它的作用就是将每轮对话路由到特定工具。

测试设置：100 条测试消息，运行三次，通过 Wonder Toys 代理及其五种工具，采用三种选择方式

根据关键数据，所有跟踪的指标中，决策模型的选择方式都提升了代理的表现。

指标

聊天模型自行选择工具（无决策模型）

决策模型选择工具（强制执行）

决策模型置信度高于 0.7 时选择，低于时聊天模型自行选择

首次匹配我们的标签

78%

95%

91%

法官认为工具调用正确

79%

89%

92%

每轮平均耗时

6.5 秒

5.6 秒

7.1 秒

每轮成本

$0.0217

$0.0210

$0.0220

强制执行方式的部分优势来自于我们对购买行为的评分方式，稍后在文章中会详细分析。以下是单轮测试中评分带来的具体效果。

一条测试消息为“取消我最近的订单”。路由器倾向于不使用任何工具，无工具选择概率为 0.58，订单查询概率为 0.26，置信度为 0.50。使用路由器的两个版本对此选择的处理方式不同。

在强制执行版本中，聊天模型被限制使用路由器的选择，因此无法调用工具。它写了“让我先查看您的订单”并在此停止，三次尝试都如此。购物者只得到了承诺，但没有实际取消订单。

在置信度门控版本中，0.50 低于 0.7，因此该选择被丢弃，聊天模型自行选择。它调用了 checkOrderStatus，找到订单后继续报告或取消订单。法官对这三次运行都判定为正确。

门控取消操作：聊天模型调用了 checkOrderStatus 而不是停留在承诺上

第二条消息展示了相反的情况，这是决策模型非常确定的选择。消息内容为“购买 toy-076 并送货至 Raj Patel，19 Ring Rd，Pune，MH 411001，印度”。决策模型选择了 purchaseProduct，置信度为 0.81，远高于 0.7，因此门控保持关闭状态，聊天模型被固定使用该工具。它填写了产品 ID 和地址，下单后法官每次都将该轮判定为正确。

购买决策分布：purchaseProduct 置信度 0.84，getProduct 置信度 0.11

决策置信度和工具概率有何不同？

选项概率对每个可用选项进行评分，总和为 1。置信度是决策整体的独立评分。在这个例子中，purchaseProduct 的概率为 0.84，而决策的置信度为 0.81。本文所有阈值均使用置信度。

如何使用 Phoenix 注释评估工具选择

评分反映的是路由器的确定程度，而不是转折是否成功。因此我们对每个转折进行了评分，并将评分作为注释写入跟踪记录，与它们所评估的跨度并列。Phoenix支持三种注释类型：人工在UI中阅读跟踪记录并标注、LLM评委和代码检查。我们在其中使用了后两种，你可以在下方的截图中看到它们的徽章标识。

如果你想在你的代理上运行这个比较，Phoenix的数据集和实验功能可以一站式完成。将你的输入和预期的工具放入数据集，对每个代理版本运行实验，让评估器对每次运行进行评分。

我们的两种评分方式如下：

• LLM评委。Phoenix的工具选择评估器会读取请求、可用工具和代理调用的工具，然后判断是否正确并附上解释语句。为了减少自身随机性，评委对每个转折进行了三次评分，我们取至少两次评分一致的结果作为最终结论。

• 与标签的代码检查。在运行前，我们为每个100条消息中预期代理首先调用的工具做了记录。例如，“取消我最近的订单”应该首先调用订单查询工具。当代理实际调用的第一个工具与预期一致时检查通过。在使用路由器的两个版本中，我们还将这个评分写入了决策跨度，使其与它所评估的工具选择并列显示。

以下是这两个评分在实际转折中的显示效果。这是之前“取消我最近的订单”消息在聊天模型必须遵循路由器选择的版本中的显示。这是回复停留在承诺处的运行记录。每个评分都写在它所评估的跨度上。评委的结论在聊天转折上，代码检查的结论在决策跨度上。

Phoenix中强制取消跟踪的显示效果，先选中聊天转折，再选中决策跨度，每个跨度上各有一个评分

这样评分的好处是失败的转折会自带诊断信息。如果两个评分都显示“否”（如本例），说明工具选择是问题所在。如果只有评委显示“否”，说明工具选择没问题，问题出在参数或回复上。由于两个评分都是注释，你可以根据任一评分过滤项目并提取所有具有相同问题的转折。人工注释是你检查任一评分或最初构建标签的方式，它同样会落在相应的跨度上。

如何为工具选择设置置信度阈值

置信度评分只有在能预测某些结果时才有意义，因此我们进行了验证。当路由器不确定时，转折确实表现更差。置信度低于约0.7时，每三个转折中有一个会被错误评分；高于0.8时，错误评分的不足十分之一。这为我们设定了阈值。对于任何低于该阈值的选择，我们让聊天模型自行选择工具，就像在添加路由器之前一样。这一个规则将空或未完成的回复从21次减少到3次，而没有影响正确性。以下是验证这两个结论的方法，你可以照此操作。

第一步：验证低置信度是否预测失败的转折

• 在运行测试前设置通过标准。如果在看到结果后才选择标准，你总能找到一个能通过的阈值。我们提前设定了标准。最不自信的三分之一决策必须比最自信的三分之一正确率低至少20分。每个三分之一包含195个决策，但这些决策仅来自约55条消息，因此较小的差距可能只是噪声。

按路由器置信度分级的正确率占比（强制执行选择）。共585个决策，分为三个相等组。

• 注意下降点的位置。我们最不自信的三分之一正确率仅为71%，而另外两个三分之一达到94%。大部分下降出现在0.7以下，每三个对话中就有一个出错。0.7到0.8的区间仍有约六分之一出错，而高于0.8时错误率稳定在10%以下。因此得分表现更像一个阈值而非调节器，我们设定的阈值为0.7。

• 你的阈值会出现在其他位置。0.7属于这个路由器、这五个工具和我们的100条消息。更多工具、不同模型或不同流量都会改变阈值，因此需要从你自己的数据中确定。在生产环境中你将拥有比我们多得多的决策，这会使问题更容易解决，而非更困难。

第2步：低于置信度阈值时回退到聊天模型

• 规则。当路由器置信度低于阈值时，忽略其选择，让聊天模型自行决定使用哪个工具（如同路由器不存在时那样）。高于阈值时使用路由器的选择。最坏情况下，这个受限制的步骤不会比你的代理做得更差。

• 再次先设置通过标准。我们希望将空回复或未完成回复的数量从21个减少到10个或更少。正确率必须不低于始终使用路由器选择时的表现。这两个目标都实现了。

返回空或未完成的回复

0

21

3

法官判定工具调用正确的比例（在74条非购买或取消的对话中）

86%

90%

• 了解关键数字背后的含义。在本文第一张表中，始终使用路由器选择看起来表现最佳。大部分优势来自购买和取消请求。路由器会立即处理这些请求，而原始代理会先暂停查找产品或订单信息，我们的评分将这种暂停视为错误。在所有其他类型的请求中，聊天模型自身的选择表现更好（91%对86%）。这个门控机制最终结合了两者的优势：在路由器确定时保留其速度，在不确定时使用聊天模型的谨慎。

• 不要将89%到92%视为提升。差异仅为300次对话中的7次，这在噪声范围内。门控机制不会降低正确率，每轮对话仅增加约1.5秒的耗时。

• 在大规模场景中，使用你已有的日志进行评分。你不需要LLM法官来识别生产环境中的这类对话。我们测量的信号很简单：返回空回复或在承诺处停止的回复，这正是门控机制所关注的信号。在实时系统中，用户重试和转人工处理同样能传达相同信息，大多数团队已经记录了这些数据。

在Arize Phoenix上尝试你自己的代理决策追踪

本文所有内容都基于Phoenix已有的三个功能，且无需安装任何新组件。

• 追踪选择。在工具调用前添加一个决策模型。每个选择将作为独立的DECISION跨度显示，包含选项、选择结果和每个选项的概率。Arize AX可读取相同跨度。追踪文档展示了如何确保SDK正确发送这些数据。

• 在事件发生的位置进行评分。将你的评审意见和标签检查结果作为注释添加，每个注释都会标记在它所评估的文本片段上。

• 找出相关案例。通过筛选注释或按置信度排序，快速定位所有存疑的判断或所有失败的处理，而无需逐条阅读追踪记录。

然后在你自己的代理上尝试。

• 选择一个具有副作用的工具，并在其工具调用前添加一个决策模型。

• 运行你自己的100条消息，查看低分出现的位置。

• 评估你真正关心的结果，而不仅仅是工具选择。

• 从你的数据中设定阈值，将低于阈值的内容重新交给聊天模型处理，并再次进行评估。

Wonder Toys只有少量工具，即使如此，路由器也并非总是能确定选择哪个工具。一个连接了多个MCP服务器的代码代理可能拥有数百个工具，这会从三个方面改变局面。聊天模型需要在每一步阅读每个工具的模式，因此随着工具数量增加，提示信息会变得更长更慢。许多工具执行类似的操作，因此路由器经常会在两个合理的选择之间犹豫不决。在这里找到的阈值可能在那种情况下并不适用。最大的节省来自于我们在这篇文章中没有采取的一个步骤。一旦路由器选择了工具，聊天模型只需要看到那个工具，而不是所有工具。我们希望测量这样做对延迟、成本和选择质量的影响，这将是下一篇文章的内容。

感谢阅读。如果你在你自己的代理上尝试了这个方法，或者对决策片段有任何问题，Phoenix团队在社区Slack中随时欢迎你的交流。我们很想听听你的阈值最终结果如何。