@hanakoxbt：你的智能体有三十个工具。它只调用了其中两个。另外二十八个并没有闲置在某个地方。它们就在请求中…

你的智能体有三十个工具。 它只调用了其中两个。 另外二十八个并没有闲置在某个地方。它们就在请求里，每一个请求里，而且它们同时在两个地方造成损害。 首先是显而易见的一点。工具 schema 会进入提示词，而 schema 不只是一个名字。 它是一段描述、参数列表、类型、必填字段、一个示例。三十个这样的 schema 就是几千个 token，每次调用都要带上，包括智能体只是说声“谢谢”然后结束的那些调用。 你在为二十八个从未触发过的工具支付租金。 第二点，也是代价更高的一点。 当请求说“取消订单”时，模型会对照所有可用的东西进行匹配选择。你的工具中有四个看起来都可能：cancel_order、refund_order、update_order、void_order。 它是在根据你几个月前某个下午写下的描述来从中选择。 你每增加一个工具，就是给那个候选名单多添一个候选者。你从未调用的那二十八个并不是中性的。它们是在决定运行是否成功的那一个决策中的噪音。 > 为什么它会在没有人刻意决定的情况下不断膨胀 没有人会故意添加三十个工具。 你为了一个任务添加一个，它起作用了，它就留下来。六个月后，注册表变成了一本目录，而且从来没有人删除过任何东西，因为删除一个工具感觉有风险，而添加一个工具感觉没有成本。 而且没有任何反馈告诉你不是这样。那些未使用的工具从不报错。它们从不出现在失败的追踪记录里。它们之所以隐形，正是它们得以累积的原因。 > 实际该怎么做 统计最近一千次运行中每个工具的调用次数。这只是一个 group-by，但通常会让人们震惊。那些为零的工具就是纯粹的成本。 只交付任务需要的工具，而不是整个注册表。研究阶段不需要部署。写作阶段不需要数据库。 在不同阶段之间切换工具集，而不是一开始就全部加载。同一个智能体，不同的工具，取决于运行进行到哪一步。 而当两个工具都可能合理地回答同一个请求时，这不是你可以忽略的冗余。这是你内置在系统里的一次抛硬币。 那二十八个工具并非未被使用。 它们每一次都在被使用，被你看不见的那部分运行所使用。