[Proposal] 运行时动态工具选择模块

[zeus-cht]

我有一个关于运行时动态工具选择的“naive idea”，想听下大佬意见，是否可行/有没有类似已知解决方案？

背景

当前 Agent 通常在实例化时绑定固定工具列表，存在以下问题：

• 工具选择子集固定，缺乏自适应能力；
• 用户可能不清楚需要用什么工具更合适，以及可能不清楚目标工具如何配置，导致工具列表过长/过短；
• 无法根据实时成本、延迟或成功率动态决策；

proposal

建议：增加一个增强模块，使 Agent 能够在运行时通过 “MCP工具能力网关”：

• 提供一组常用工具集合，这些工具用户可能没有配置；
• 动态检索、过滤、评分工具；
• 选择最匹配且成本最低的工具；
• 自动收集反馈数据形成闭环优化。

该模块旨在：

• 提升对工具的易用性，并减少用户感知
• 提高任务成功率和执行效率

模块组成

1. 工具注册目录

• 存储工具元数据：能力标签、schema、成本、成功率、区域、版本等。
• 接口示例：

type ToolManifest struct {
  ToolID         string
  Capabilities   []string
  InputSchema    Schema
  EstimatedCost  float64
  SuccessRate    float64
  Region         []string
}

2. 语义匹配与评分引擎（Matcher）

• 输入：任务意图 + 上下文；
• 输出：Top-N 工具 + 得分；
• 评分函数示例：

score = α * relevance - β * normCost - γ * normLatency + δ * successRate

3. 动态工具选择器（ToolSelector Node）

• 插入 Graph 中，调用 Matcher 获取候选工具；
• 选出最优工具传递至 ToolInvoke/Stream；
• 接口示例：

type ToolSelector interface {
  SelectTool(ctx context.Context, intent string, context map[string]any) (ToolManifest, error)
}

4. 反馈与学习模块（FeedbackCollector）

• 通过Eino callback机制，收集每次工具调用的成本、耗时、成功率；
• 持续优化评分模型参数。

5. 缓存与降级机制

• 通过 LRU / TTL 缓存减少重复匹配；
• 异常时回退至静态工具表。

流程示例

graph TD
    subgraph 应用层["应用层"]
        U[Agent应用/用户]
    end

    subgraph 智能体层["Agent Runtime"]
        A1[上下文管理器]
        A2[意图解析]
        A3[动态工具选择器]
        A4[工具调用器]
    end

    subgraph 能力网关层["MCP网关"]
        M1[工具注册表]
        M2[语义匹配与过滤]
        
    end

    subgraph 工具服务层["外部工具服务"]
        T1[翻译服务]
        T2[数据库查询服务]
        T3[搜索服务]
    end

    subgraph 学习层["学习与优化模块"]
        M3[评分与排序引擎]
        M4[性能与反馈存储]
        F1[学习引擎 / 模型优化器]
    end

    U -->|任务请求| A1
    A1 -->|提取上下文| A2
    A2 -->|生成意图与需求| A3
    A3 -->|请求工具匹配| M2
    M2 -->|访问| M1
    M2 -->|过滤 + 评分| M3
    M3 -->|返回候选工具列表| A3
    A3 -->|选择最优工具| A4
    A4 -->|调用工具| T1
    A4 -->|调用工具| T2
    A4 -->|调用工具| T3
    T1 -->|返回结果| A4
    T2 -->|返回结果| A4
    T3 -->|返回结果| A4
    A4 -->|汇总结果输出| U
    A4 -->|反馈执行数据:耗时/成本/成功率| M4
    M4 -->|性能数据更新| F1
    F1 -->|优化评分参数 / 学习结果| M3

后续扩展

• 工具匹配可以在工具名称、描述的基础上，增加更多信息，比如工具支持的假设问题
• 工具数量较大时，基于RAG检索生成Top-k工具

[shentongmartin]

这是一个不错的思路。我们来仔细看一下这个思路的背景：

1. 工具选择子集固定，缺乏自适应能力；
2. 用户可能不清楚需要用什么工具更合适，以及可能不清楚目标工具如何配置，导致工具列表过长/过短；
3. 无法根据实时成本、延迟或成功率动态决策；

其中，第一个问题，可以考虑给不同的 agent 设置不同的工具集，并由 LLM 选择不同的 agent，来实现“自适应的工具子集选择”。

第二个问题，是扩展 Eino 的一方工具集，这个是一个长期的建设过程，欢迎一起共建。

第三个问题，可以通过现有的 model.WithTools 这个 option 来动态构建 tool 列表。构建的依据，是你说的“成本、延迟、成功率”等，这些信息可以通过 callback 等机制收集。收集后如何决策的算法，可以由 developer 按需自行实现。