实现族、注册表与动态 MCP
区分内置工具实现族、静态注册表与运行时发现的 MCP 工具
本页解决的问题
先给结论「实现族、注册表与动态 MCP」要解决的关键问题是什么？
区分内置工具实现族、静态注册表与运行时发现的 MCP 工具
让这个结论先证明自己值得留下。 把这一页当成决策工具，而不是需要背下来的定义。把概念连到一个真实任务、一个可观察结果，以及一个能改变你判断的失败上。
写下一个问题：试完这个方法后，你能用什么证据回答它？
结论听起来很完整，却没有检查最关键的假设。
ToolBridge 执行，同时准确写出两个 MCP 元工具的真实输入字段。
grok_build主要产品工具族，包含 ReadFile、SearchReplace、Bash、Task 等实现。
grok_build_concise精简工具族，目录中包含 read_file、search_replace 与 bash。
grok_build_hashline带 hashline 语义的 read_file、edit 与 grep 实现。
codex包含 apply_patch、read_file、list_dir、grep_files 等兼容实现。
opencode包含 read、write、edit、bash、glob、grep、skill 与 todowrite。
memory / lsp / skills按能力拆出的实现模块。namespace 枚举还包含 MCP，用于运行时外部工具。
SearchTool
在 ToolIndex 中按 BM25 搜索 MCP 工具。结果按 server 分组，并返回工具描述与 input_schema。
query: String关键词limit: Option<u8>默认 5UseTool
接收发现后的合格工具名，通过 InnerDispatch 或 managed gateway 调用 MCP。这个固定入口让模型工具列表跨轮次保持稳定。
tool_name: String通常为 server__tooltool_input: Value按发现到的 schema 构造pub struct ToolBridge {
registry: Arc<FinalizedToolset>,
terminal: Option<Arc<dyn TerminalBackend>>,
}
pub async fn register_mcp_tools<T>(
&self,
mcp_name: String,
tool: T,
input_schema: Option<serde_json::Value>,
) -> Result<(), xai_tool_runtime::ToolError> {
self.registry.register_tool(mcp_name, tool, input_schema)?;
Ok(())
}
pub struct UseToolInput {
pub tool_name: String,
pub tool_input: serde_json::Value,
}grok-build-main，重点核对 xai-grok-tools/src/implementations/mod.rs、types/tool.rs、bridge.rs、registry/types.rs、implementations/search_tool 与 implementations/use_tool，核对日期 2026-07-17。追踪一次外部工具调用
从模型先调用 search_tool 开始，写出查询字段、返回中需要读取的 schema、随后传给 use_tool 的两个字段，以及最终由哪个桥接类型把结果交回会话。
ToolBridge 连接会话。动态 MCP 通过 SearchTool 发现 schema，再由 UseTool 按 schema 分发执行。
「核心视觉 · 从定义到执行的数据流」为什么要看操作
「主要产品工具族，包含 ReadFile、SearchReplace、Bash、Task 等实现」把结构落到了一个具体动作。这里真正要比较的不是名词谁更高级，而是数据如何被放置，以及最常发生的操作需要走多远。
读懂结构，要同时看访问方式和变化方式
「精简工具族，目录中包含 read_file、search_replace 与 bash」揭示了一个容易被忽略的取舍：按位置读取、按键查找、从两端进出、插入新元素和遍历关系，适合的组织方式并不相同。一个结构在某个操作上很快，不代表它在所有操作上都快。
把规模和更新频率一起算进去
实践时可以把「从模型先调用 search_tool 开始，写出查询字段、返回中需要读取的 schema、随后传给 use_tool 的两个字段，以及最终由哪个桥接类型把结果交回会话」当作边界提醒：先写下数据量、最常用的操作和允许的延迟，再看 AI 给出的结构是否真的匹配。
从「核心视觉 · 从定义到执行的数据流」走到「源码中的实现族」
「核心视觉 · 从定义到执行的数据流」先把问题落在「实现族 grok_build · codex · opencode 动态 MCP 运行时注册 ToolRegistryBuilder 选择 · 参数重命名 finalize(config, context) FinalizedToolset definitions · resources dispatch ToolBridge 会话适配 调用与结果 tool definitions 提供给模型 ToolOutput…」上；到了「源码中的实现族」，讨论继续推进到「主要产品工具族，包含 ReadFile、SearchReplace、Bash、Task 等实现」。两段连起来，重点就不只是记住一个结论，而是看清它成立所依赖的条件。
把这条判断带到下一个场景
遇到一个新的数据结构时，不要从定义开始背。先写出最频繁的操作，再估计数据量和更新方式，最后检查结构是否让这三个条件同时成立。
- 「核心视觉 · 从定义到执行的数据流」：实现族 grok_build · codex · opencode 动态 MCP 运行时注册 ToolRegistryBuilder 选择 · 参数重命名 finalize(config, context) FinalizedToolset definitions · resources dispatch ToolBridge 会话适配 调用与结果 tool definitions 提供给模型 ToolOutput…
- 「源码中的实现族」：主要产品工具族，包含 ReadFile、SearchReplace、Bash、Task 等实现
- 「最后的要点」：按能力拆出的实现模块。namespace 枚举还包含 MCP，用于运行时外部工具
最后的「最后的要点」把讨论落到「按能力拆出的实现模块。namespace 枚举还包含 MCP，用于运行时外部工具」。回看这条线索时，最值得保留的是：当输入、规模或风险改变，哪些判断需要重新做一遍。
我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是，知道下一步要观察什么。
读完以后我先回头找它成立的条件，而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。
如果把这个判断放到真实工作里，最先需要补的约束是什么？我想知道从阅读到第一次实践之间，哪一步最值得先做。
还没有这篇文章的讨论。