Progressive Tool Discovery

当Agent可访问大型工具目录（涵盖数十乃至数百种可用工具）时，预先加载所有工具定义会占用过多的context window空间。在特定工作流中，大多数工具都不会被用到，这种预加载方式不仅造成资源浪费，还会限制实际任务执行时可调用的context空间。

通过类文件系统层级结构呈现工具，让Agent能够通过探索该结构按需发现功能。实现search_tools功能，允许Agent请求不同详细程度的信息：

1. 仅名称：用于初始浏览的极简上下文
2. 名称+描述：足以理解工具用途的信息
3. 包含Schema的完整定义：仅在需要时提供完整的API细节

工具按层级组织（例如servers/google-drive/getDocument.ts、servers/slack/sendMessage.ts），因此Agent可以：

• 列出./servers/目录以查看可用集成
• 进入特定服务目录查找相关工具
• 仅为打算使用的工具加载完整定义

# Agent 工作流
1. list_directory("./servers/")
   → 返回：["google-drive/", "slack/", "github/", ...]

2. search_tools(pattern="google-drive/*", detail_level="name+description")
   → 返回：Google Drive 工具的简要说明

3. get_tool_definition("servers/google-drive/getDocument")
   → 返回：包含参数、类型、示例的完整JSON Schema

最佳适用场景：

• 拥有20款及以上可用工具或集成能力的系统
• 模型上下文协议（MCP）服务器实现
• 代理可从大量功能中选择的插件架构

实现注意事项：

• 按集成来源、业务领域或功能类型，将工具组织为清晰的层级结构
• 在每个层级提供具有实际意义的名称与描述
• 支持工具搜索的模式匹配（通配符或正则表达式）
• 缓存经常被批量请求的工具定义

示例目录结构：

servers/
├── google-drive/
│   ├── getDocument.ts
│   ├── listFiles.ts
│   └── shareFile.ts
├── slack/
│   ├── sendMessage.ts
│   └── getChannels.ts
└── github/
    ├── createIssue.ts
    └── listRepos.ts

优点：

• 大幅降低初始上下文（context）消耗
• 可扩展至数百乃至数千个工具
• Agent可通过探索了解工具生态
• 与基于代码的工具接口自然映射

缺点：

• 增加发现开销（执行前需额外调用工具）
• 需要精心设计的组织架构与命名规则
• 若Agent原本就需要用到多数工具，该方案效果会打折扣
• 可能需要多轮交互才能找到合适的工具