SH

Soloharness

概念 · 辨析 · Agent

← 返回概念辨析

Concept Contrast Fable

工具调用和工具选择

工具调用是模型决定调用哪个工具之后的执行步骤——发出调用请求、接收返回结果。工具选择是决定「该不该调用工具、调用哪个工具」的决策步骤。两者在一条流水线上紧挨着,但问题拆开后才知道卡在哪一步:输出质量差可能不是调用写错了,而是选错了工具。

寓言

传菜员和看菜单的人

宴会厅的后厨流水线分成两道工序。第一道是看菜单的人——客人点完菜,他要判断哪道菜哪个灶台能做、优先炒哪道、是不是需要换一个平替。第二道是传菜员——灶台炒好菜,传菜员端到客人桌上。

新来的领班小孔注意到最近客人投诉上菜慢,他直接盯着传菜员整改。传菜员的手速从一分钟两趟提升到三趟,投诉量没降。小孔加了一个传菜员,两个人一起跑,投诉量还是没降。小孔急了,说传菜环节有问题。

后厨老师傅老涂把小孔拉到看菜单的人旁边站了十分钟。老涂说:你看他在干什么。这个人拿到一张菜单不先排序,全按单子上的顺序往下念。红烧肉需要四十分钟,凉拌黄瓜只需要两分钟。他先念了红烧肉,后面五道凉菜全卡在那等着。传菜员跑得再快,灶台上没菜可传。

小孔把流程改了。看菜单的人先分类:快菜先下单,慢菜标记预计时间,同类菜可以合锅。分类之后再传给灶台,灶台炒完再给传菜员。改动当天,上菜平均时间从二十八分钟降到了十四分钟。投诉量降到零。

小孔后来复盘这件事,画了一张流程卡。看菜单的人做的叫「菜品调度」——选哪个灶台、什么顺序、有没有平替。传菜员做的叫「菜品传递」——炒好的菜端上桌。两个岗位挨着,但瓶颈在前一个。他花了两个月优化后一个,只是在放大前一个环节的错误。

老涂说:传菜慢可能是传菜员的问题,也可能是灶台上根本没菜。你先看灶台,再看传菜——灶台没菜的时候,传菜员原地站着不是因为懒,是因为前面的决策没给他东西可传。你给一个手快的传菜员配一个糊涂的看菜单人,就等于让一个反应极快的系统拿不到正确的工具。

宴会厅后来出了一本培训手册,第一页画了一张流程图,旁边写了四个字:调度在前。新员工入职培训时,老涂会把他们叫过来,让他们感受一下传菜员空着手在走廊里跑。跑完一圈,问他们:你觉得他跑得够快吗。都说快。再问:那你觉得他为什么手里没菜。

最后一个问题的答案写在了手册第二页:上菜慢的时候,不要第一反应是传菜员跑不快。先检查一下看菜单的人——他选的灶台对不对、排的顺序对不对、有没有替代方案。

工具调用

模型在确定使用某个工具后,生成结构化调用参数、发出请求并处理返回结果的执行步骤。它关注的是「调用格式对不对、结果能不能用」。

工具选择

模型根据用户意图和上下文判断是否需要调用工具、在多个可用工具中选择最合适的那一个的决策步骤。它关注的是「该不该调、调哪个」。

故事对应

  • 传菜员端菜:工具调用——执行层面的传递和返回。
  • 看菜单的人选灶台和排序:工具选择——决策层面的工具匹配和调度。
  • 先念红烧肉卡住后面五道凉菜:工具选择错误导致下游全堵。
  • 优化传菜速度没用:只修调用环节不修选择环节,瓶颈没动。
  • 调度在前:工具选择是工具调用的前置条件,选择错则调用再快也没用。

落到项目里

排查 Agent 输出质量问题时,把工具选择和工具调用拆开看。先看选对了没有——模型有没有在不该调用工具时调了,有没有该调但没调,有没有在多个工具中选了效率最低的。再看调用写对了没有——参数格式、边界值、返回结果解析。选择错误要多看 prompt 中的工具描述清晰度和决策引导,调用错误要多看 schema 定义和错误处理。