为 Reachy Mini 添加 MCP 工具：从本地控制到远程扩展

背景

在人与机器人的交互中，反馈不仅仅是语音回复，更是一套对对话做出反应的系统。当适用时，机器人可以通过移动身体、做出非语言回应来增强交互体验。这一能力的核心在于“工具”（Tools）——即模型在对话过程中可以调用的功能，例如播放情绪、移动头部或查看摄像头画面。

传统的机器人应用架构中，工具通常是本地的、内置在应用程序中的 Python 代码。虽然这种方式对于控制机器人硬件（如 move_head 或 play_emotion）非常合适且安全，但它存在明显的局限性：

1. 共享困难：分享一个工具意味着必须分发 Python 文件。
2. 更新繁琐：更新工具需要重新发送文件。
3. 耦合度高：即使某些能力（如网络搜索、天气查询）与机器人本体无关，开发者仍需修改应用代码才能添加或更改这些功能。

为了解决这些摩擦，Pollen Robotics 推出了基于 Model Context Protocol (MCP) 的远程工具机制。这一机制允许将无状态的能力（如搜索、天气、数据查询）独立发布、共享和更新，从而将“受信任的本地核心”与“可共享的远程扩展”分离开来。

核心内容

1. 工具的生命周期与配置

在 Reachy Mini 的应用架构中，代码中定义的工具并不会自动生效，必须通过“配置文件”（Profile）进行启用。配置文件是一个包含两个关键文件的文件夹：

• instructions.txt：定义提示词（Prompt），指导模型如何使用工具。
• tools.txt：列出当前启用的工具名称。

默认配置（profiles/default/tools.txt）启用了全套本地工具，包括舞蹈、情绪播放、摄像头、头部追踪等。如果某个工具名称未出现在 tools.txt 中，模型将无法调用它。

2. 远程工具（Remote Tools）的引入

远程工具是继“内置工具”和“自定义本地工具”之后的第三种类型。它们主要托管在公共的 Hugging Face Spaces 中，旨在处理那些与机器人身体无关、但需要频繁迭代或共享的能力。

工作流程：

1. 安装与发现：通过命令行工具从 Hub 安装 Space，系统会自动探测 MCP 端点并发现其中的工具。
2. 启用：默认情况下，安装操作会将工具 ID 追加到当前活动配置文件的 tools.txt 中。
3. 调用：实时后端像调用内置工具一样调用远程工具。

命令示例：

# 安装并启用（默认添加到 active profile）
reachy-mini-conversation-app tool-spaces add pollen-robotics/reachy-mini-weather-tool

# 仅安装，不启用
reachy-mini-conversation-app tool-spaces add <owner/space-name> --install-only

# 列出已安装的 Spaces
reachy-mini-conversation-app tool-spaces list

# 移除已安装的 Space
reachy-mini-conversation-app tool-spaces remove <owner/space-name>

3. 命名空间与冲突管理

为了确保远程工具与内置工具共存且互不干扰，系统采用了严格的命名规范：

• 本地别名：每个安装的 Space 会根据其 slug 生成一个本地别名，将连字符、点和斜杠转换为下划线。
  • 例如：pollen-robotics/reachy-mini-search-tool 变为 pollen_robotics_reachy_mini_search_tool。
• 远程工具 ID：远程工具 ID 由“本地别名”加上双下划线和工具名组成。
  • 例如：pollen_robotics_reachy_mini_search_tool__search_web
  • 例如：pollen_robotics_reachy_mini_weather_tool__get_day_brief

这种命名空间机制避免了名称冲突，并允许同一配置文件下存在多个 Space。如果简化名称会导致冲突，系统会回退到完整的命名空间名称。此外，注册表层面还设有重复安全检查，确保所有来源的工具名称全局唯一。

4. 提示词工程的重要性

远程工具的存在不仅改变了技术架构，也凸显了提示词（Prompt）在控制模型行为中的关键作用。

在“搜索+天气”的 Canary 测试中，面对复合问题（例如：“今天波尔多需要带夹克吗？今晚市中心有什么大事吗？”），模型有多种处理路径：先查天气再搜索、先搜索再查天气，或同时调用。如果提示词模糊，模型可能会串行调用工具，导致不必要的延迟。

因此，Canary 配置文件中的 instructions.txt 包含了具体的规则，指导模型：

• 仅在用户询问最新事实、新闻或实时可用性时使用远程工具。
• 如果搜索结果已直接回答问题，直接用自然语言回答，避免“工具闲聊”。
• 对于可能需要时间的远程查询，先给出简短的英文确认（如“让我查一下”），然后继续。
• 保持回答简短、口语化，类似语音助手的风格，省略前言、列表和标题。

5. 持久化存储

已安装的 Space 信息会持久化存储，具体位置取决于运行模式：

• 托管应用模式：installed_tool_spaces.json
• 终端模式：external_content/installed_tool_spaces.json

关键要点

• 架构分离：将受信任的本地硬件控制工具与可共享的远程无状态工具分离，降低了维护成本并提高了灵活性。
• 标准化集成：通过 MCP 协议，任何兼容的 Hugging Face Space 都可以作为工具被 Reachy Mini 发现和使用，实现了生态系统的互操作性。
• 配置驱动：tools.txt 充当“守门人”，只有明确列出的工具（无论是本地还是远程）才能被模型调用，确保了安全性。
• 命名空间隔离：使用 space_name__tool_name 的格式防止远程工具与内置工具发生命名冲突，支持多 Source 共存。
• 提示词即功能：远程工具的可用性高度依赖于 instructions.txt 中的提示词工程，清晰的规则能显著优化模型的调用策略和响应速度。
• 快速迭代：开发者可以独立发布和更新远程工具（如天气、搜索），无需重新打包或分发整个机器人应用程序。

意义与影响

这一更新标志着具身智能（Embodied AI）应用开发模式的重要转变。

首先，它降低了机器人应用开发的门槛。开发者无需深入理解机器人底层硬件接口，只需开发符合 MCP 标准的远程服务（如天气 API 封装、搜索引擎封装），即可将其集成到机器人对话中。这促进了“工具即服务”（Tool-as-a-Service）在机器人领域的落地。

其次，它增强了社区协作与生态繁荣。通过 Hugging Face Spaces 公开共享工具，开发者可以复用他人的成果，也可以将自己的工具贡献给社区。这种“积木式”的开发方式加速了创新，使得机器人能够迅速获得最新的互联网能力（如实时新闻、动态数据查询）。

最后，它提升了用户体验的实时性与自然度。通过分离关注点，机器人可以更专注于其核心的物理交互能力（如表情、动作），同时无缝接入强大的云端信息处理能力，从而提供更丰富、更智能的人机交互体验。