Tulip Agent – 基于 LLM 智体使用大型工具库解决任务

24年7月来自欧洲本田研究所的论文“Tulip Agent – Enabling LLM-Based Agents to Solve Tasks Using Large Tool Libraries”。

Tulip Agent，是一种基于 LLM 的自主智体架构，富有大量工具的工具库创建、读取、更新和删除访问权限。与最先进的实现相比，Tulip Agent不会在系统提示中编码所有可用工具的描述（这计入模型的上下文窗口），也不会嵌入整个提示以检索合适的工具。相反，Tulip Agent可以在其可扩展工具库中递归搜索合适的工具，该库以向量存储的形式实现。Tulip Agent架构显著降低了推理成本，允许使用甚至大型工具库，并使智体能够调整和扩展其工具集。

参考实现和基准如 GitHub - HRI-EU/tulip_agent: autonomous agent with access to a tool library 。

如图是Tulip Agent求解一个数学问题的架构实例：

• 挑战 1（成本）工具描述计入 LLM 的上下文窗口，从而增加推理时间和金钱方面的成本。

• 挑战 2（注意和工具限制）从大量工具中进行选择对 LLM 来说是一项挑战，因为它带来了一种“大海捞针”的挑战。因为 LLM 很难进行长输入的上下文学习（Li et al. [2024]），很难检索多个事实，也很难推理这些事实（LangChain, 2024）。此外，可以提供给 LLM 的工具数量可能有限，例如 OpenAI 模型就是这种情况。

• 挑战 3（静态性）工具的使用是静态的，并且仅限于先验定义的工具，这限制了自主智体的适应性及其对开放式场景的适用性。

Tulip Agent架构旨在通过为 LLM 提供对可扩展工具库的访问权限来解决挑战 1 - 3。这使得可以访问任意大小的工具集，这些工具可以高效扩展和调整，同时降低总体成本。

如图概述了Tulip Agent的组件，箭头表示信息流。要设置Tulip Agent，需要通过代码自省自动提取有关可用工具（在例子中是 Python 函数）的信息。从函数的文档字符串中，生成嵌入，这些嵌入与工具信息的 LLM 兼容表示 一起存储在工具库中（0）。当收到用户提示时（1 ），模型将请求 分解 为子任务，并将相应的描述传递给搜索模块 （2） 。这些描述是嵌入的基础，搜索模块使用嵌入通过语义搜索为每个子任务找到合适的 工具（检索） 。搜索模块将有关最相关工具的信息传递给模型 （3） ，模型为所有子任务适当地 调用工具 （4） 。相应 工具执行 （5） 并将结果反馈给模型 （6） ，从而允许模型启动进一步的操作或向用户提供响应 （7） 。

对于使用工具，LLM 需要工具的唯一标识符（可解析该标识符以调用工具）、工具用途的描述以及必要输入参数的名称、类型和描述。这种方法依赖于函数分析器进行自省。它可以提取根据 Sphinx 样式记录的 Python 函数，但这可以扩展到其他类型的工具。从提取的信息中，构建一个工具库。原则上，工具库可以是任何支持搜索合适工具的数据库。由于用户提供自然语言输入，并且 LLM 适用于自然语言，因此通过密集嵌入进行语义搜索（允许将任务与可用工具匹配）尤其有前景。在智体初始化期间，创建函数名称和相应文档字符串的嵌入，即捕获语义的向量表示，并将它们与自省模块生成的函数描述一起存储。生成的向量存储允许通过语义搜索来搜索合适的工具。初始化工具库的过程总结在如下算法 1 中：

Tulip Agent在其工具库中搜索每个子任务的合适工具。具体来说，为规划中的每个子任务创建一个嵌入，并与工具描述的嵌入进行匹配，返回最合适的前 k 个工具。

值得注意的是，Tulip Agent架构支持递归分解和搜索工具。如果初始子任务不够细粒度，无法找到合适的工具，这很有用。通过为语义搜索设置相似度阈值，可以确保只返回合适的工具。如果没有找到描述与任务描述足够相似的工具，智体会进一步分解子任务，对下一级工具进行另一次搜索。为了避免无限循环，求助于设置最大递归深度。

如下算法 2 总结了在工具库中搜索工具作为语义搜索的过程。默认情况下，用平方 l2 范数作为嵌入向量之间的距离函数：