大模型当大脑：LLM 规划 + 硬件执行

设想这样一幕：你对着小车说「去前面看看有没有障碍，有就绕开」，它顿了一下，然后真的往前挪、停下、原地转了个弯、绕过桌腿继续走。没有遥控器，没有预先写死的「障碍小于 20cm 就转」那种 if，你说的是人话，它听懂了，自己拆成了一串动作。

这就是「大模型当机器人大脑」想达到的效果。听起来很科幻，但落到一台 ESP32 小车上，它是个人当下最能上手的具身智能形态——比四足狗便宜，比机械臂简单，一块开发板加几个舵机就能玩。

但这里有个最关键、也最容易被误会的点先点破：大模型并不直接控制电机。它不会去拉某个 GPIO 的电平，也不知道你的左轮接在哪个脚。它做的是「理解 + 规划 + 调用工具」——把你写好的硬件函数（forward、turn、readDistance）当成它能调用的工具，由它来决定「先调哪个、传什么参数、根据返回结果再调哪个」。真正去控电机的，还是你那段跑在 ESP32 上的老代码。

这套「大模型调工具函数」的机制，技术名字叫 Function Calling，是 Agent 的核心能力。这篇不重复协议细节——它的来龙去脉在 Function Calling 入门，更进一步的标准化封装见 MCP 协议。这篇只讲一件事：当这套机制用在机器人上，长什么样、怎么分工、坑在哪。 读之前最好先扫一眼那两篇，知道「大模型怎么调函数」，这里直接讲「调的是硬件函数」。

Agent 范式：大模型调的是你写的工具

先把这个范式的骨架钉住，它和你以前写的机器人代码有本质区别。

老写法（状态机）：你把所有逻辑都写死在 ESP32 里——if 距离 < 20 then 转向。小车很「快」，但很「笨」，只会你预先想到的那几种情况。换个指令就得重新烧录。

Agent 写法：你不再写死逻辑，而是写一组工具函数，每个函数干一件具体的硬件动作，然后告诉大模型「你有这些工具可用」。用户说人话，大模型自己决定调用顺序。逻辑从你的代码里搬到了大模型的「脑子」里。

这两者的分界，就是这篇的核心。大模型负责编排（先看一眼、有障碍就转、转完再走），你负责实现每个动作（怎么转、转多少度由电机驱动板执行）。各管一段，井水不犯河水。

工具定义：把硬件动作描述给大模型

要让大模型知道「它能调什么」，得先用它能读懂的格式把每个工具描述清楚——叫什么、干什么、要传什么参数。下面是一套参考实现的工具 schema（JSON 形式），定义了三个小车工具：

[
  {
    "name": "move",
    "description": "控制小车按指定方向移动一段距离。前进或后退。",
    "parameters": {
      "type": "object",
      "properties": {
        "direction": {
          "type": "string",
          "enum": ["forward", "backward"],
          "description": "移动方向"
        },
        "distance": {
          "type": "number",
          "description": "移动距离，单位厘米，范围 0-100"
        }
      },
      "required": ["direction", "distance"]
    }
  },
  {
    "name": "scan",
    "description": "用超声波测量正前方障碍物距离，返回厘米数。需要先调用它了解环境再决定怎么走。",
    "parameters": { "type": "object", "properties": {} }
  },
  {
    "name": "grab",
    "description": "控制机械臂抓取正前方物体。仅在已贴近目标时调用。",
    "parameters": { "type": "object", "properties": {} }
  }
]

这段 JSON 不是代码，是说明书。description 写得越清楚，大模型用得越准——它就是靠这几行自然语言判断「该不该调、什么时候调」。注意 scan 的描述里那句「需要先调用它了解环境」，这是在引导大模型先感知再决策，等于把 sense-think-act 的循环用人话教给了它。

这三个工具背后，是你在 ESP32 上早就写好的硬件函数：move 对应电机驱动 + 编码器测距，scan 对应读 HC-SR04 超声波，grab 对应控制舵机机械臂。大模型只看到「说明书」，看不到也不关心你具体怎么拉电平。

这是一套参考实现，为了讲清范式做了简化。一个真正端到端跑通、把语音识别 + 大模型 + 硬件串成完整产品的样子，去看 小智 AI 硬件项目总览，那是这套思路的完整落地。

对话流程：一句人话变成一串动作

工具定义好了，看大模型拿到「去前面看看有没有障碍，有就绕开」之后，整个对话怎么转。这是一来一回的多轮过程：

① 用户 → 大模型：「去前面看看有没有障碍，有就绕开」

② 大模型思考：要先知道前面有没有东西，调 scan
   大模型 → 你的程序：调用 scan()

③ 你的程序 → ESP32 → 读超声波 → 返回
   你的程序 → 大模型：{ "distance": 18 }

④ 大模型思考：18cm 很近，是障碍，得绕。先后退一点再转向
   大模型 → 你的程序：调用 move(direction="backward", distance=10)

⑤ 你的程序执行后 → 大模型：{ "status": "ok" }

⑥ 大模型 → 你的程序：调用 turn(angle=45)   // 转向避开

⑦ 你的程序执行后 → 大模型：{ "status": "ok" }

⑧ 大模型 → 你的程序：调用 move(direction="forward", distance=30)

⑨ 大模型 → 用户：「前方 18cm 有障碍，我已经后退转向绕开，继续前进了。」

看明白这九步，就看明白了整个范式。大模型在第②④⑥⑧步反复「调工具 → 等结果 → 再决定下一步」，每一轮它都拿着上一步的真实返回值（比如 distance: 18）来做下一个判断。这正是 sense-think-act 闭环，只不过「think」这一环从你写死的 if 换成了大模型的实时推理。

你要写的，只是把第③⑤⑦步那个「收到调用 → 让 ESP32 真的动 → 返回结果」的桥接层实现好。大模型负责剧本，你负责让演员（硬件）按剧本动起来。

分工架构：云端规划，端侧执行

上面流程里藏着一条物理分界线，值得单独拎出来讲，因为它决定了这套系统怎么搭。

	云端大模型（规划）	端侧 MCU（执行）
角色	大脑，做规划	手脚，做动作
特点	慢、贵、聪明	快、便宜、可靠
时延	几百毫秒到几秒	毫秒级实时
联网	必须联网	不需要
负责	理解人话、拆解动作、决定调哪个工具	控电机、读传感器、实时安全保护

为什么必须这么分？ 因为这两件事的需求是矛盾的。

「理解人话、规划动作」需要的是聪明——得有几百亿参数的大模型，跑在云端 GPU 上，一次推理几百毫秒起步。这种活 ESP32 干不了，它内存才几百 KB。

「控电机、躲碰撞」需要的是实时和可靠——碰撞传感器触发到电机停，必须在毫秒内完成，慢一拍小车就撞了。这种活绝不能等云端：网络抖一下、大模型想久一点，小车就出事了。所以它必须留在端侧 MCU，本地闭环，不联网也能干。

把「慢而聪明」的放云端、「快而可靠」的放端侧，各取所长。大模型给出高层指令（「往前 30cm」），ESP32 在执行这 30cm 的过程中，自己用本地的碰撞保护兜底——大模型说走，但真撞上了，是 ESP32 自己叫停，不必请示云端。

局限：别把它想成无所不能

敢说观点：这是当下个人最能上手的具身智能形态。但同样要敢说它的短板，不然你会踩坑。

• 延迟：每次调工具都要走一趟云端，几百毫秒到几秒。所以它适合「我说一句、它从容执行一串」的慢节奏任务，不适合需要毫秒反应的场景（比如平衡车的实时平衡，那必须是端侧 PID，大模型碰都别碰）。
• 联网依赖：断网即失忆。大脑在云端，没网小车就成了只会执行最后一条指令的木头。要么接受这个前提，要么上能本地跑的小模型（性能打折，见 本地部署大模型）。
• 会下错指令：这是最要命的。大模型是概率模型，它可能误解你的话，可能在多轮里算错方向，可能一本正经地让小车冲下楼梯。它的「聪明」不等于「正确」。

正因为第三条，执行层的安全兜底不是可选项，是必须项。大模型说「前进 100cm」，你的 ESP32 代码不能闭眼就冲——它得在前进的每一步里读碰撞传感器，一旦触发立即停；机械臂的舵机要做硬件角度限位，大模型给出超界角度时由代码截断；最好还留一个物理急停。把这条记死：大模型负责「想得对」，你的代码负责「错了也不出事」。

你应该看到什么

接好云端大模型、定义好三个工具、写好桥接层之后，对着小车说一句话，你应该观察到：

• 你说「去前面看看，有障碍就绕开」，小车先停顿一下（这是大模型在云端推理，正常现象）。
• 然后它自己跑了一串动作：先不动（在 scan）、可能后退一点、原地转个角度、再往前——你没写过这个动作序列，是大模型现编的。
• 最后它（如果接了语音）用人话回你：「前面有障碍，我绕开了。」

关键信号：同一句话，换个场景，它的动作序列不一样。前面没障碍它就直接走，有障碍它才转——这就是「规划」在起作用，不是回放固定脚本。如果不管前面有没有东西它都做一样的动作，那大模型大概没真在用 scan 的返回值，往下排查。

故障排查表

现象	多半是	怎么办
大模型只回话，不调任何工具	工具 schema 没传给它，或 description 太模糊	确认请求里带了 tools 定义；把描述写具体，明确「什么时候该调」
调了工具但参数乱（distance 传了 9999）	参数没写取值范围，大模型瞎猜	在 description 里写清范围（0-100cm），执行层再做一次截断兜底
一句话等好几秒才动	云端推理 + 网络往返，正常	这是范式的固有延迟；实时任务别用大模型，留给端侧
断网后完全不动	大脑在云端，断网即失忆	接受联网前提，或换本地小模型（见 本地部署）
小车冲向危险（楼梯/墙）不停	执行层没兜底，盲信大模型指令	立刻加碰撞保护 + 硬限位，这是安全底线不是优化项

变体：让它看得见、让它会反思

把基础链路跑通后，有两个方向能让小车明显「更聪明」：

• 加视觉，让它能看：把 scan（只测距离）升级成一个返回图像描述的工具，背后接个能看图的多模态大模型。这样你能说「把红色的方块推到左边」，它先「看」一眼认出红色方块在哪，再规划路径。代价是算力和延迟都更高，超声波那种几块钱的方案换成摄像头 + 更重的模型。原理见 传感器与 AI。
• 加多轮反馈，让它会反思：在每个动作执行后，把更丰富的结果喂回去（不只是 ok，而是「前进了，但只走了 20cm 就被挡住」）。大模型拿到这个反馈能调整策略——「没走到位，换个方向再试」。这让小车从「执行一串预定动作」进化成「边做边纠错」，更接近真正的自主。

动手挑战

不用一上来就接大模型，先做最关键的一步——把硬件抽象成工具。

给你手上的小车，定义 3 个工具函数（先在纸上写 schema，再在 ESP32 上实现桩函数）：

1. 一个感知工具：readDistance()，返回前方厘米数。想清它的 description 怎么写，才能让大模型知道「该先调它」。
2. 一个移动工具：move(direction, distance)，把参数范围写进描述，并在实现里加一行截断（超过 100cm 就截到 100，这就是兜底）。
3. 一个你自己的动作：转向、鸣笛、亮灯随便选一个，关键是 description 要让大模型分得清「什么时候用它」。

写完这三个 schema，你就已经把机器人改造成了「可被大模型编排」的形态——接哪个大模型只是下一步的事。这一步想清楚了，Function Calling 入门 里讲的怎么把工具喂给模型，你就能顺着接上。

小结·下一步

• 大模型当大脑，核心是它调用你写的工具函数，不直接控电机——这是 Agent 范式落到硬件上。
• 流程是多轮的：大模型调工具 → 等真实返回 → 再决定下一步，把 think 这一环换成了实时推理。
• 架构上**云端规划（慢、贵、聪明）+ 端侧执行（快、可靠）**分工，因为这两件事的需求天生矛盾。
• 三大局限要认：延迟、断网、会下错指令；正因第三条，执行层的安全兜底是必须项。
• 观点：这是个人当下最能上手的具身智能形态，一块 ESP32 就能玩。

工具范式的细节，回去补 Function Calling 入门 和 MCP 协议。但要让小车真的「动」起来，光会规划不够——大模型说「转 45 度」，底层怎么把它变成轮子精确转过那个角度？下一步去看运动控制这块怎么落地：给小车装上运动能力。