加载中...
加载中...
智能体如何发现可用工具、在运行时动态注册新工具,以及MCP协议和OpenAI Function Calling背后的工具发现机制——让Agent不再「盲人摸象」
工具发现(Tool Discovery)解决的是Agent「能做什么」的问题——就像人进到一个房间需要知道里面有哪些工具可用。动态注册则让Agent在运行时获取新工具而不必重启,是Agent从「静态工具集」到「自适应工具箱」的关键一步。
工具发现的三种模式:
模式一:静态声明(Static Manifest)——在系统提示词或配置文件中提前列出所有工具的名称、描述和参数Schema。Agent启动时一次性加载,运行期间不变。代表:OpenAI Function Calling 的 tools 参数、LangChain 的 @tool 装饰器。优点是简单可控,缺点是工具列表固定,无法适应动态场景。
模式二:注册中心发现(Registry-Based Discovery)——工具提供方主动向注册中心注册自己的元信息(名称、端点、Schema)。Agent通过查询注册中心来发现可用工具。代表:MCP(Model Context Protocol)的 tools/list 方法、Kubernetes 的 Service Discovery。优点是可动态增删工具,缺点是引入了额外的注册中心依赖和心跳维护。
模式三:按需检索(On-Demand Retrieval)——Agent在接到任务后,先检索工具向量库或API目录,按语义相似度匹配最相关的工具,再加载其Schema。代表:DSPy 的工具选择器、Semantic Kernel 的 Plugin 检索。优点是工具池可以非常大(成百上千个),缺点是检索可能不准确,工具描述质量直接影响召回。
核心差异总结:静态模式适合封闭环境(企业内部Agent),注册中心模式适合平台型Agent(如MCP生态),检索模式适合开放域Agent(如通用助手需要调用海量第三方API)。
操作:搭建一个本地MCP Server(如 filesystem server),用 MCP Inspector 或 hermes-agent 连接,观察 tools/list 返回的工具列表是否与预期一致
工具:MCP Inspector(https://github.com/modelcontextprotocol/inspector)、hermes-agent 的内置MCP客户端
指标:工具发现完整性(声明工具数 = 实际发现工具数)、首次发现延迟(tools/list 响应时间应 < 500ms)
操作:在Agent运行期间,通过MCP Server动态添加一个新工具(如新增一个 weather API 工具),立即发送相关任务请求,观察Agent是否能发现并调用新工具
工具:自定义MCP Server + SSE event 推送工具变更通知
指标:工具注册到可用的端到端延迟(应 < 2s)、新工具首次调用成功率(应 > 95%)
操作:准备3组工具Schema——A组用模糊描述(如「获取数据」)、B组用精确描述(如「从指定URL获取JSON格式的天气数据,参数:city, days」)、C组包含误导性描述。分别让Agent完成同一批任务,统计工具选择准确率
工具:LangSmith(https://smith.langchain.com)追踪每次工具选择、Weights & Biases 记录实验指标
指标:工具选择准确率(Top-1正确率)、工具误用率、首次选择正确时的平均延迟
「分享到微信」:手机浏览器打开时一键调起系统分享面板,选择微信即可分享到朋友圈或聊天。电脑上回退为复制文案。
暂无留言,来说两句吧