给一个代理30个工具后，它在关键工具的使用上表现更差了。

我正在为支持工作流构建一个代理，并随着新案例的出现不断添加工具。工单查询、退款处理、订单历史、升级，以及其他十几个。看起来无害，提供更多功能和覆盖范围。在添加到20多个工具后，情况发生了变化。代理开始为简单请求选择错误的工具，而在只有五个选项时，它处理得很好。我回头测试了相同的请求，对比了早期版本工具较少的代理。在完全相同的提示下，准确性更高。底层模型没有变化，任务也没有变化。只是在决策时有了更多选项。一旦你想到工具选择对模型来说实际上是一个分类问题，即对工具列表中的所有内容进行分类，随着看似合理的选项数量增加，分类会变得更难，尤其是当多个工具的描述重叠，且听起来都与给定请求合理相关时。例如，对于“客户想要退款”的请求，退款处理和订单历史可能看起来都是正确的选择，具体取决于描述如何措辞，而代理必须猜测哪个真正合适，但没有太多信息来消除歧义。比我预期更有帮助的是：将代理拆分为多个工具集更窄的小型代理，通过一个轻量级的第一步进行路由，而不是一个代理包含所有内容。在实际决策点上，选择更少。虽然感觉不如一个能做一切的代理那么优雅，但这是实际上更可靠的版本。