openinterpreter 中 tool_search 工具描述模板Apps/Connectors 工具发现的 BM25 实现解析【免费下载链接】openinterpreterA coding agent for open models like Kimi K3 and GLM 5.3项目地址: https://gitcode.com/GitHub_Trending/op/openinterpreter本文围绕 tool_description.md 这份tool_search工具描述模板展开先逐句解读模板本身的提示词设计与{{app_descriptions}}占位符机制再深入 ToolSearchHandler 与 create_tool_search_tool 的源码实现说明描述文本如何被动态渲染、BM25 检索引擎如何构建、搜索结果又如何转化为下一次模型调用可用的工具规格。读完本文你可以完整理解本项目延迟加载工具 关键词检索发现这一工具发现机制从提示词到执行链路的落地方式。1. 模板定位一段注入给模型的工具发现说明书模板文件 codex-rs/core/templates/search_tool/tool_description.md 全文如下# Apps (Connectors) tool discovery Searches over apps/connectors tool metadata with BM25 and exposes matching tools for the next model call. You have access to all the tools of the following apps/connectors: {{app_descriptions}} Some of the tools may not have been provided to you upfront, and you should use this tool (tool_search) to search for the required tools and load them for the apps mentioned above. For the apps mentioned above, always use tool_search instead of list_mcp_resources or list_mcp_resource_templates for tool discovery.它不是给人看的说明文档而是作为tool_search工具的 description 文本注入到模型上下文中的一段提示词。逐句拆解其设计意图标题# Apps (Connectors) tool discovery限定这份描述服务于 Apps/Connectors应用/连接器场景下的工具发现与 MCP 通用工具发现相区分。第一句功能声明明确说明该工具基于 BM25 对工具元数据做检索并把命中的工具暴露给下一次模型调用。这一句同时交代了检索算法BM25与结果用途供下一轮调用加载使用让模型知道调用它不会立即执行工具而是解锁工具。{{app_descriptions}}占位符运行时会被当前已启用的应用/连接器清单及描述替换告诉模型这些应用的工具你都可能用到。部分工具可能没有提前提供给你解释了延迟加载deferred loading策略——工具元数据不会一次性全部塞进上下文而是按需检索加载以此控制 token 开销。对上述应用始终用tool_search而不是list_mcp_resources/list_mcp_resource_templates做工具发现这是一条硬性路由规则避免模型绕过检索直接枚举 MCP 资源保证发现路径统一走 BM25。与 MCP 通用场景对应的描述由 Rust 代码动态生成见 tool_search_spec.rslet description format!( # Tool discovery\n\nSearches over deferred tool metadata with BM25 and exposes matching tools for the next model call.{source_section}Some of the tools may not have been provided to you upfront, and you should use this tool ({TOOL_SEARCH_TOOL_NAME}) to search for the required tools. For MCP tool discovery, always use {TOOL_SEARCH_TOOL_NAME} instead of list_mcp_resources or list_mcp_resource_templates. );两者结构几乎同构都是功能声明 来源清单 延迟加载提示 路由规则四段式。从源码结构看模板文件承载的是来源为 Apps/Connectors的变体而 Rust 侧create_tool_search_tool负责通用 MCP 场景及来源清单的渲染两者共享同一套提示词骨架。同目录下还有一份姊妹模板 request_plugin_install_description.md定义request_plugin_install工具的使用约束仅当用户明确要求某个已知未安装的插件/连接器、且tool_search不可用或已尝试但未命中时才允许调用并给出完整五步工作流先检查活跃工具列表 → 对照已知清单精确匹配 → 插件优先于连接器 → 携带tool_type/action_type/tool_id/suggest_reason参数发起安装请求 → 安装完成后决定继续搜索还是放弃。它与tool_search构成互补关系tool_search解决已启用来源里找不到工具request_plugin_install解决工具根本还没安装。2. 工具 Schemaquery 必填、limit 默认 8tool_search的参数定义同样在 create_tool_search_tool 中let properties BTreeMap::from([ (query.to_string(), JsonSchema::string(Some(Search query for deferred tools..to_string()))), (limit.to_string(), JsonSchema::number(Some(format!( Maximum number of tools to return. Defaults to {default_limit}. )))), ]);querystring必填检索词对应 JSON Schema 的required: [query]limitnumber可选返回工具数量上限默认值来自常量 TOOL_SEARCH_DEFAULT_LIMIT其值为8pub const TOOL_SEARCH_TOOL_NAME: str tool_search; pub const TOOL_SEARCH_DEFAULT_LIMIT: usize 8;参数在运行时的校验逻辑见 ToolSearchHandler::handle_callquery去除首尾空白后为空 → 返回RespondToModel(query must not be empty)错误让模型自行修正limit 0→ 返回RespondToModel(limit must be greater than zero)无匹配来源时直接返回空的ToolSearchOutput不报错。这种把错误回传给模型而不是崩溃的设计使模型可以在同一会话内自我修正参数。3. BM25 检索引擎从 search_text 到 SearchEnginetool_description.md中with BM25这句声明的实现在 ToolSearchHandlerpub(crate) fn new( search_infos: VecToolSearchInfo, source_listing: ToolSearchSourceListing, ) - Self { let search_source_infos search_infos .iter() .filter_map(|search_info| search_info.source_info.clone()) .collect::Vec_(); let spec create_tool_search_tool( search_source_infos, TOOL_SEARCH_DEFAULT_LIMIT, source_listing, ); let documents: VecDocumentusize search_infos .iter() .map(|search_info| search_info.entry.search_text.clone()) .enumerate() .map(|(idx, search_text)| Document::new(idx, search_text)) .collect(); let search_engine SearchEngineBuilder::usize::with_documents(Language::English, documents).build(); // ... }关键点每个可检索工具ToolSearchInfo都携带一段search_text字段它即是被索引的文档。BM25 引擎以英文语言配置构建Language::English文档 ID 就是该工具在search_infos数组中的下标检索时 search 方法 用search_engine.search(query, limit)拿到按相关性排序的文档 ID再映射回ToolSearchEntry中的outputLoadableToolSpec最后经coalesce_loadable_tool_specs合并——同一命名空间如mcp__calendar下命中的多个工具会被归并为一个LoadableToolSpec::Namespace减少重复的工具声明。单元测试 mixed_search_results_coalesce_mcp_namespaces 验证了 MCP 工具与动态命名空间工具混合命中时的归并结果并确认每个工具都带defer_loading: Some(true)标记。4. 来源清单渲染去重、512KB 预算与按字符边界截断模板里的{{app_descriptions}}对应的来源清单渲染逻辑在 tool_search_spec.rs按名称去重以BTreeMap汇总来源名与描述重复名称保留先出现的描述测试 create_tool_search_tool_deduplicates_and_renders_enabled_sources 验证了同名来源只取首个非空描述、输出保持字典序的行为512KB 描述预算常量MAX_TOOL_SEARCH_SOURCE_DESCRIPTION_BYTES 512 * 1024渲染前先扣除来源名等固定开销再逐个来源分配描述字节数超预算的来源被跳过且截断借助 take_bytes_at_char_boundary 在多字节字符边界处安全切割测试 create_tool_search_tool_bounds_aggregate_source_descriptions 用 2 万个 字符构造了极端用例Omit 模式ToolSearchSourceListing::Omit时完全不渲染来源清单当世界状态已在别处宣告了这些来源时启用测试 create_tool_search_tool_omits_sources_when_world_state_advertises_them 断言此时描述中不再出现来源名。这套预算控制保证了无论接入了多少应用/连接器注入模型上下文的那段 description 都不会失控增长——这正是延迟加载 按需检索策略能成立的前提之一。5. 暴露控制与缓存何时模型才能看到 tool_searchtool_search是否对模型可见由配置开关控制。mcp_tool_exposure.rs 中的逻辑根据search_tool_enabled布尔值决定工具暴露策略search_tool_enabled为true时走经检索发现的暴露路径其配套单测文件 mcp_tool_exposure_test.rs 覆盖了apps_enabled与search_tool_enabled四种组合下的暴露结果。性能侧ToolSearchHandlerCache 用MutexOptionArcToolSearchHandler缓存已构建的检索器当新的search_infos与source_listing与缓存完全一致时直接复用避免每轮对话重建 BM25 索引任一字段变化则重建。单测 cache_reuses_handler_for_identical_search_infos_and_rebuilds_for_changes 验证了相同输入复用同一 Arc、修改一条 search_text 即触发重建的行为。端到端集成测试位于 tests/suite/search_tool.rs 与 tests/suite/request_plugin_install.rs后者同时验证了必须先耗尽tool_search才允许请求安装的约束。6. 小结一条完整的工具发现链路把模板与源码串起来tool_search的完整链路是描述注入模板/代码生成的 description含来源清单与 BM25 声明进入模型上下文模型据此知道哪些应用的工具需要检索才可用参数校验query非空、limit 0默认 8错误以可回传模型的方式返回BM25 检索对每个工具的search_text建立英文 BM25 索引按相关性取前limit个规格归并命中工具按命名空间合并为LoadableToolSpec携带defer_loading标记暴露给下一轮调用兜底协同检索不到时若用户显式要求某个已知插件/连接器走姊妹模板约束下的request_plugin_install安装流程。这一机制的本质是用提示词声明发现规则 客户端 BM25 检索 延迟加载标记三层配合让模型在工具数量膨胀时无需背负全部工具 schema 的上下文成本同时保留确定性的发现路径。若要进一步阅读建议从 tool_search_spec.rs 与 tool_search.rs 两个文件及其内嵌测试入手再对照 codex-rs/core/templates/search_tool/ 下的两份模板即可完整还原该功能的提示词面与实现面。【免费下载链接】openinterpreterA coding agent for open models like Kimi K3 and GLM 5.3项目地址: https://gitcode.com/GitHub_Trending/op/openinterpreter创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考