MCP 让它动——把一个硬件动作注册成工具，让小智真会干活

上一节自建后端你把"大脑"搬回自己家了——ASR、LLM、TTS 都能换成自己的。但到这一步你会发现一件别扭事：小智会听、会想、会答，本质却还是个只会说话的音箱。你说"帮我把灯开一下"，它顶多回你"好的，我帮你开灯"——然后灯纹丝不动。

嘴皮子利索，手却是废的。这一节就补上这只手——让小智从"会说话"跨到"能动手"，靠的就是 MCP。

先想清楚：为什么"会说话"不等于"能动手"

回到你手里这台小智。它跑完整条"唤醒 → ASR → LLM → TTS"链路，中间那颗大模型只做了一件事：把你的话变成一句回话。它理解了意图，但输出终点是文字——文字合成成语音播出来，就完了。

问题就出在这儿：模型不知道这台设备上有什么硬件、更没通道去碰它。 对模型来说板子是个黑盒，它看不见上面接了 LED、舵机。它能生成"我帮你开灯"这四个字，但这四个字和板子上那颗真灯之间，隔着一条它跨不过去的鸿沟。

要让它动手，得给它两样东西：一张能力清单（告诉模型这台设备能干哪些事）和一条调用通道（让模型不只是"说要开灯"，而是能真的发出调用，落到板子上那段控灯的代码）。

MCP 干的正是这两件事。想理解 MCP 协议本身"是什么、为什么统一",先补 L4 的 MCP 那节；这里只盯一件事：它在小智这台真设备上，怎么让"开灯"变成一次真实动作。

和 Function Calling 什么关系：一个是能力，一个是标准

你可能已经在 L4 Function Calling 里见过"让模型调函数"了。那 MCP 和它是什么关系，会不会是又一个要重学的东西？不是。把它俩摆一起看就清楚了：

• Function Calling 是「模型能调外部函数」这个能力——模型不再只会吐文字，还能决定调一个工具、把参数填好。这是底层机制。
• MCP 是「这些工具该怎么描述、怎么被调用」的一套标准——让每个人别再各写一套方言，把描述格式、调用约定统一起来。

打个比方：Function Calling 是"你会打电话"这个本事，MCP 是"大家都用同一套拨号规则"这个约定。有本事没标准，每台设备、每家模型都得重配一套号；有了标准，一次配好谁来都能拨通。

小智选 MCP，是因为它要接的硬件动作会越来越多——今天一颗 LED，明天一个舵机，后天联动一屋子智能家居。没有标准，每加一个动作就重写对接；有了 MCP，写一次描述，模型和平台随便换都能接。 接的硬件越多越划算。

机制拆解：一次"开灯"在小智里到底怎么流

把镜头对准最关键处——你说一句"开灯"，这句话在小智内部经过哪几道手，才变成灯真的亮。 想通这条流，你就抓住了 MCP 控硬件的骨架。分五步，用最朴素的话讲：

1. 设备先"报家底"。 小智和大脑接上后，会按 MCP 的规矩把这台设备能干的事列成一张工具清单递过去——"我有个 set_led 能控灯，有个 set_servo 能转舵机"。这一步，模型第一次知道了这台板子的本事。
2. 你说话，模型理解意图。 你喊"把灯打开"，经 ASR 转成文字进到 LLM。模型一看那张清单，发现 set_led 描述写着"控灯"，正好对上你的意图——它决定调这个工具。
3. 模型发出一次工具调用。 模型不再吐"好的我帮你开灯"这种文字，而是按 MCP 的约定发出一个结构化调用：调 set_led，参数 on = true。这条"调用通道"真正走起来了。
4. 调用落回板子，执行真代码。 调用顺着链路回到板子上，触发你早先绑在 set_led 背后那段真正控硬件的代码——就是 L1 点灯时写的那种 GPIO 拉高。灯，这一刻真亮了。
5. 把结果按标准回给模型。 板子执行完回一句"已执行"，模型知道办成了，再合成一句"灯已经开好啦"播给你听。

看清这条流没有？关键转折在第 3 步——模型输出从"一句话"变成"一次调用"。前面几节它的终点是嘴（TTS），从这节起多了一双手（MCP 工具）。这双手能接上全靠第 1 步那张清单：设备把能力按标准说清楚，模型才调得到。

核心动作：把一个硬件能力"注册"成一个工具

上面那条流的起点是"注册"——把硬件动作登记成模型能看见、能调的工具。这是你在小智里控硬件真正要动手做的事。

注册一个工具，本质是用标准格式把这个能力的四件事讲清楚（四件套在 L4 MCP 那节有更细展开，这里落到小智项目视角再点一遍）：

• 名字：工具叫什么，模型靠它"点名"调用。比如 set_led。
• 描述：干嘛的，模型靠它判断"什么时候该用我"。写清"控板载 LED 开关"，才对得上你说的"开灯"。
• 参数：调它要填什么，模型靠它把你的话翻译成值。比如 on、brightness。
• 执行：模型发出调用后落到哪段代码——就是你真正控硬件那一行。

下面是一段概念示意，帮你"看见"注册长什么样。注意：这不是小智上游的真实实现，也不代表真实的 MCP 报文格式——真写法以官方与小智上游为准，这里只为把骨架亮出来。

// 概念示意（非上游实现）：把"控灯"这个本机能力注册成一个 MCP 工具
// 骨架就是四件套：名字 + 描述 + 参数 + 执行

registerMcpTool({
  name: "set_led",                         // ① 名字：模型点名用
  description: "控制板载 LED 的开关与亮度",   // ② 描述：模型据此判断该不该调
  params: {
    on:         "布尔，是否点亮",
    brightness: "整数 0~255，亮度（可选）"    // ③ 参数：模型把你的话翻译成值
  },
  onCall: (args) => {                       // ④ 执行：模型调用后真正落到这
    gpio_set_level(LED_GPIO, args.on ? 1 : 0);  // 你 L1 就会的那一行
    return "已执行";                          // 按标准把结果回给模型
  }
});

要你想明白的不是 gpio_set_level 那行——那是 L1 的老本事。要害在外面那层"注册"：你把控灯按标准描述出来，模型才发现得了、调得动它。想加个"转舵机"？把 onCall 换成控舵机的代码，外面描述结构一模一样——这就是标准化替你省掉的重复活。

两种落地形态：本机能力 vs 联动外部

在小智里，MCP 工具按"能力在哪"分两种，动手前先分清：

• 设备端 MCP（本机）：控这块板子自己接的东西——板载 LED、舵机、几路 GPIO。你说"把灯调暗"，调用直接落到板子上执行，不绕远路，是"AI 能动手"最直接的形态。
• 云端 MCP（联动外部）：控板子之外的东西——查天气，或联动你家别的智能家居（客厅空调、卧室窗帘）。这些能力挂在云端，但通过云端 MCP，模型用同一套调用方式就能碰到。

妙就妙在这个"同一套"。你说一句"我要睡了"，模型可能既走设备端 MCP 关了板子上的灯，又走云端 MCP 关了客厅空调——对模型而言这两类工具长得一模一样，它不用管能力在板子上还是云上。能力在哪不重要，描述和调用的方式统一了，模型就能一视同仁编排。

小结 · 下一步

这一节把小智从"会说话"推到"能动手"，你现在应该拿得住这几件事：

• 为什么会说不等于能动：模型输出终点本是文字（嘴），既不知道设备有什么硬件、也没通道去碰。MCP 递上能力清单、铺好调用通道，补上了这只手。
• MCP 和 Function Calling 的关系：一个是"模型能调函数"的底层能力，一个是"工具怎么描述、怎么调"的统一标准；接的硬件越多，标准越省事。
• 一次"开灯"的五步流：设备报家底 → 模型理解意图 → 发出工具调用 → 落回板子执行真代码 → 结果回给模型。转折点是模型从"吐一句话"变成"发一次调用"。
• 核心动作是"注册"：用"名字 + 描述 + 参数 + 执行"四件套把硬件能力登记成工具；模型只调它见过的，加能力就是再注册一个。分设备端（本机）和云端（联动外部）两种形态。

记住那条红线：MCP 仍在演进，具体注册格式、字段名一律以官方和小智上游当前版本为准，本节讲的是机制而非 API 手册。

下一步：手会动了，接下来该让它更像"你的"——去个性化那节，给小智换人设、调声音、定制性格和反应。想把 MCP 控硬件放进一个从头到尾的贯穿项目里逐段拆，看语音机器人实战；想回炉补 MCP 协议本身的来龙去脉，随时翻 L4 的 MCP 章与 Function Calling 章。