Reachy Mini 这次有个很有意思的反常点：前一阵大家还在聊对话后端本地化，少一次上云，少一层依赖；现在 Hugging Face 又给它加了远程 MCP 工具，天气、搜索这些能力重新跑到云端。

看起来像打脸，其实不是。

如果说本地化解决的是“机器人脑子和身体别全交给云端”，这次远程 MCP 解决的是另一件事：工具能力怎么共享、更新、分发。新增线索补强的正是这里——Reachy Mini 不是简单地从云端撤退，而是在重新切分边界：身体能力留本地，信息能力放远程，闸门仍由本地 profile 控制。

这比“又接入 MCP 了”重要得多。

发生了什么：一条命令，把 Space 工具接进机器人

Hugging Face 在 6 月 3 日宣布，Reachy Mini conversation app 现在可以调用托管在公开 Hugging Face Spaces 上的 MCP 工具。

用户执行：

reachy-mini-conversation-app tool-spaces add <owner/space-name>

就能把一个公开 Gradio Space 接进 Reachy Mini。官方示例包括：

  • pollen-robotics/reachy-mini-search-tool：搜索工具
  • pollen-robotics/reachy-mini-weather-tool：天气工具

添加后，工具默认启用到当前 profile。模型在对话里就可以调用它们，比如回答“今天波尔多要不要带外套”或“今晚市中心有没有活动”。

但边界很窄：

  • 只支持公开 Hugging Face Gradio Spaces
  • Space 要兼容 MCP
  • 需要暴露标准 /gradio_api/mcp/ 端点
  • 不支持任意 MCP 服务器
  • 不支持私有或需要认证的 Space
  • 不支持直接粘一个原始 MCP URL

所以别把它理解成“Reachy Mini 接入了整个 MCP 世界”。目前更准确的说法是：Reachy Mini 接入了 Hugging Face Spaces 里的特定 MCP 工具。

为什么重要：新增的不是工具，是分工

Reachy Mini 原来的工具更偏身体能力：

工具类型运行位置适合能力关键问题
内置工具本地应用头部动作、舞蹈、摄像头、情绪播放安全、低延迟、可信执行
本地自定义工具本地 profile 或 external_tools硬件实验、一次性扩展灵活，但难分发
远程 MCP 工具公开 Hugging Face Gradio Space天气、搜索、资料查询易共享、易更新，但受平台边界限制

这张表才是这次更新的核心。

机器人真正敏感的部分，不该随便交给远程服务。比如转头、看图、播放动作、调用摄像头，这些直接碰到硬件和现实环境。留在本地，合理。

天气、搜索、知识查询则不同。它们更像外部服务。放在云端 Space 里，开发者更新一次，使用者本地不用拷贝 Python 文件，也不用重新改应用。

这就是比此前“后端本地化”多出来的判断：少上云不是把云端一刀切掉，而是把云端从“控制中枢”降级成“工具市场”。

这个变化不大，但方向清楚。

谁受影响：主要是开发者和折腾型用户

普通用户能感受到的东西很简单：机器人可能会回答更多现实问题。今天下不下雨、附近有没有活动、某个信息能不能查到。

但真正受影响的是两类人。

一类是 Reachy Mini 开发者。

过去加一个工具，常常意味着改本地代码、处理依赖、分发文件、解释安装方式。现在可以把能力做成公开 Gradio Space，别人用 slug 安装。工具代码跑在 Space 端，本地应用不会下载任意代码。

这是一条安全边界，也是一条分发边界。

另一类是想做机器人应用原型的人。

他们最怕的不是写一个 demo，而是 demo 之后每个人机器上环境都不一样。远程 MCP 工具把一部分麻烦挪走了。能不能长期稳定另说，至少试用成本降下来了。

但别高兴太早。

工具被加进来，不等于模型就能可靠调用。Reachy Mini 仍靠 profile 管能力：instructions.txt 写提示词，tools.txt 列可用工具名。工具 ID 不在 tools.txt，模型就不能调用。

add 命令会校验 Space、探测 MCP 端点、发现工具，并把工具 ID 追加到当前 profile。远程工具还会命名空间化，比如把某个 Space 的工具名变成类似 pollen_robotics_reachy_mini_weather_tool__get_day_brief 的本地 ID，避免撞名。

这类细节不性感，但很关键。

机器人平台最后死不死，往往不死在模型能力，而死在工具注册、权限边界、版本冲突和用户不知道自己到底启用了什么。

这次做对了：把外延放出去，把闸门留在本地

我更愿意把这次更新看成一次克制的设计，而不是一次大跃进。

MCP 现在很热。Anthropic 推动 Model Context Protocol 之后，桌面助手、IDE、Agent 框架都在往里塞。热词一旦扩散，行业就容易犯一个毛病：只要接了 MCP，就像拿到平台门票。

Reachy Mini 这次没有把门开到最大。

它没有说任意 MCP 服务器都能接。没有让机器人随便拉远程代码。没有把本地 profile 绕过去。它只允许公开、MCP 兼容的 Hugging Face Gradio Space 进入，还要经过工具发现和命名空间处理。

这叫知止。

《道德经》里那句“知止不殆”，放在机器人产品上很合适。机器人不是浏览器插件。它有身体，有摄像头，有动作能力。软件世界里一次错误调用可能只是弹个窗口，机器人世界里一次错误调用可能会碰到桌面、用户、环境。

所以问题不在“能不能开放”。问题在“开放到哪一层”。

这次的分层比较清楚：

  • 本地保身体和可信执行
  • 远程放搜索、天气、查询这类可替换能力
  • profile 做能力闸门
  • `tools.txt` 控制模型能调用什么

这不是完美方案，但比“全部本地插件化”和“全部云端托管”都更现实。

全部本地插件化，开发者爽一阵，用户装到崩溃。全部云端托管，演示好看，信任成本爆炸。Reachy Mini 现在走的是中间路线：核心收紧，外部放开。

这条路没那么燃，但更像能跑下去的工程路线。

真正的风险：工具能装，不代表工具好用

我不太买账的是另一个叙事：只要工具生态打开，机器人能力就会自然增长。

没这么简单。

工具生态最难的不是“有没有入口”，而是入口之后的秩序。谁维护工具？工具坏了谁负责？Space 更新后是否兼容旧 profile？工具描述写得差，模型会不会乱调？搜索结果错了，机器人要不要复述？天气接口慢了，对话体验怎么兜底？

这些都不是 MCP 四个字能解决的。

尤其是调用编排。官方示例可以鼓励模型并行调用天气和搜索，但提示词只是软约束。低延迟、强流程、安全敏感的场景，不能把执行顺序交给模型“领会精神”。该写进代码的，就写进代码。

模型适合做意图理解和自然语言交互，不适合被当成流程引擎的唯一保险丝。

这也是很多 Agent 产品的老毛病：演示时像会办事，上线后像会找事。问题不一定在模型，而在产品把不该交给概率系统的东西交了出去。

Reachy Mini 这次少犯了一点这个毛病。它把工具入口做出来，但保留 profile 和本地工具闸门。真正要继续看的，不是又多几个天气、搜索 demo，而是这条链路能不能稳定：

  • 第三方工具能不能被准确发现
  • 工具命名能不能避免冲突
  • profile 能不能管住权限
  • Space 更新会不会破坏已有调用
  • 用户能不能知道机器人到底启用了哪些能力

跑顺了，它会更像一个有边界的机器人应用平台。

跑不顺，就是老问题：插件一多，体验变脏；生态一热，维护变冷。

机器人平台的老问题：开放和控制永远互相咬

扯远一点，今天这事很像早期智能手机和浏览器插件的老路。

开放带来繁荣，也带来垃圾、冲突和安全问题。控制带来稳定，也带来封闭和创新变慢。平台方最难的不是喊开放，而是决定哪些东西必须自己守，哪些东西可以交给外部。

机器人比手机更麻烦。

手机 App 崩了，用户重启。机器人动作错了，风险进入现实世界。摄像头、马达、麦克风、外部服务、语言模型混在一起，边界设计就不是架构洁癖，而是产品生死线。

Reachy Mini 的这一步小，但它至少承认了一个事实：AI 机器人不能只靠一个大模型撑场面。它需要工具，需要分发，需要权限，也需要一个不那么浪漫的工程秩序。

模型看着更强，产品反而更虚。虚就虚在工具、权限、流程、责任全没落地。

这次远程 MCP 工具没有解决所有问题，但它把问题摆到了正确位置：机器人不该在本地和云端之间二选一，而该把不同风险的能力放在不同地方。

少一次上云，是为了保住可信核心。再接一点云，是为了让能力长出来。

关键不在云不云。

关键在谁握闸门。