type
status
date
slug
summary
tags
category
icon
password
org
使用TOOL SEARCH TOOL而不是全部加载上下文中
传统方法将所有工具全部加载入上下文中,当工具变多变得复杂时,会大量浪费上下文,很多工具在一个任务中是不会使用的
延迟加载:根据RAG的思想,原来的文档很多,直接读取知识在上下文中,存在类似问题,于是使用检索的方式,同理引入tool search tool,可以根据query对现有的工具进行检索,只引入需要的工具。

如何进行检索,claude使用regex、BM25或者custom的方法,设计为多个tool search tools,供agent进行调用
如果遇到特别高频使用的tool怎么办?
为所有tool加入一个defer_loading字段,说明其是否需要延迟载入,如果设置为true,则通过tool search tool进行载入,面对high-use tools,可以设置为false,直接载入
这样的方式会引入检索的研究在tool检索上,如果想要在这方面做研究,则要明确tool检索和一般的文本检索有什么区别,claude只提供了regex-based and BM25-baesd方法,并且说明可以使用embedding或者其他的自定义方式。
使用tool search tool会引入更多步骤,所以需要平衡时间消耗和token消耗,面对tool复杂繁多且很多tool是不会用到的情况使用这个方式会更好
使用tool search tool会产生什么问题?
- 仍然依靠工具定义和描述进行选择,当工具开发者对工具定义描述不够全面时,检索精度会下降,导致相关工具无法正确选择到
Programmatic Tool Calling 程序化工具调用
传统方法是让agent一步一步进行tool calling,会产生两种问题
- 上下文污染:当需要对一个大文件进行分析的时候,会将所有的内容读取到上下文中,可能会导致重要信息被排除到上下文窗口外。问题是将中间结果保存在了上下文中造成污染
- 推理开销与人工合成:tool calling的过程完全由agent进行连接,大模型得到中间结果进行理解后再决定下一步的情况,一方面消耗更多token,另一方面可能会产生更多错误
于是采用了程序化的工具调用方式,将tool calling的过程使用code进行,agent编写代码,调用多个工具并可以处理他们的outputs,有更加严谨的控制逻辑


这里的代码生成和一般的代码生成有什么区别?
怎么针对性加强programmatic tool calling capability?
怎么进行programmatic tool calling?
首先让tool能够被code调用
为agent设置一个code_execution工具,并且设置allowed_caller,将tool definition转化为可以执行的python function
这是不是就是code based function calling,抛弃了json 自然语言为主的工具调用
agent 编写代码作为input参数调用code execution工具
- Author:Wenxuan Wang
- URL:http://preview.tangly1024.com/article/2c0d0968-b245-8078-a831-cd11725df56f
- Copyright:All articles in this blog, except for special statements, adopt BY-NC-SA agreement. Please indicate the source!





