[Feature Request] Toolkits Refactoring

[WHALEEYE]

Required prerequisites

• I have searched the Issue Tracker and Discussions that this hasn't already been reported. (+1 or comment there if it has.)
• Consider asking first in a Discussion.

Motivation

The current style of toolkits is quite chaotic, we need to make it more standardized to ensure the code quality and also for the ease of adding future tools.

Solution

No response

Alternatives

No response

Additional context

No response

[lightaime]

Part of the refactoring:

• Support tool names: [Feature Request] Enable getting a tool from a ToolKit by tool_name and listing the available tool_name_list #946 by @yiyiyi0817
• Add a AllToolKit class to have all tools in once place: [Feature Request] Add a AllToolKit class to have all tools in one place  #947 @ZackYule
• Support tool search in ToolKit: feat: test cases for retrive_tools functions #603, [Feature Request] Support tool search in ToolKit #948 @Wendong-Fan
• Support auto tool schema or docstring generation for OpenAIFunction: [Feature Request] Support auto tool schema or docstring generation for OpenAIFunction #949 @Zhangzeyu97 @Wendong-Fan
• A unify api key management for tools: [Feature Request] A unify api key management for tools #950 @NeilJohnson0930 @WHALEEYE
• Support conditional tool calling: [Feature Request] Support conditional tool calling #951 @yiyiyi0817 @zhiyu-01 @WHALEEYE @ZackYule
• Tool calling execution modes: [Feature Request] Support synthesize and execute mode for tool calling execution #1008 @Zhangzeyu97 @WHALEEYE
• Add tools for GAIA benchmark: [Feature Request] Add tools for GAIA benchmark #1014 @CaelumF @yuzhenmao
• Add function calling benchmark and tools: [Feature Request] Add function calling benchmark and tools #1013 @CaelumF @yuzhenmao

[ZackYule]

I have a couple of detail questions regarding the Toolkits refactoring that might be worth considering：

Q1: Would it make sense to replace BaseToolkit classes that don’t require any configuration with functional tools instead? This way, we could avoid exposing classes without actual tool methods in the ToolManager, streamlining the structure.

Q2: I think it might be better if the tool list returned by ToolManager is List[str] when intended for user interaction, and list[OpenAIFunction] when used by the agent. Since list_toolkits is primarily for users, it seems reasonable for it to return List[str]. As for search_toolkits, should it be designed for user use or for the agent?

[ZackYule]

Below are the current ways we use tools, and I believe it would be helpful to consider unifying these approaches while also supporting developers in customizing their own tools.

There’s also one more point to consider: the OpenAPIToolkit doesn’t currently support the management approach used by toolkits_manager.

Perhaps it would be a good idea to revisit and discuss these details again. @lightaime @yiyiyi0817 @zhiyu-01

1. Without toolkit_manager

No configuration needed

tools_list = [
  *SEARCH_FUNCS,
  *MathToolkit().get_tools(),
]

Configuration needed

toolkit = GithubToolkit(repo_name=repo_name)

tools_list = [
  *SEARCH_FUNCS,
  *WEATHER_FUNCS,
  *toolkit.get_tools(),
]

2. With toolkits_manager

No configuration needed

tools_list = manager.get_toolkits(names=manager.search_toolkits('weather'))

Configuration needed

camel_github_toolkit = GithubToolkit(repo_name='camel-ai/camel')

tools_list = manager.register_tool([camel_github_toolkit, ])

Custom tools

def div(a: int, b: int) -> float:
    r"""Divides two numbers.
    Args:
        a (int): The dividend in the division.
        b (int): The divisor in the division.
    Returns:
        float: The quotient of the division.
    Raises:
        ValueError: If the divisor is zero.
    """
    if b == 0:
        raise ValueError("Division by zero is not allowed.")
    return a / b
  
tools_list = manager.register_tool([div, ])