前阵子调一个小智语音助手的项目真被一个“返回值”整破防了小智通过 MCP 工具下发指令去控制一台工业风扇工具端非常干脆地返回了true日志里一片绿结果风扇纹丝不动。排查到半夜才发现问题不是电机坏了不是接线松了而是我们把“工具调用成功”和“硬件动作完成”这两件事当成了同一件事。这不是个案。只要你正在做小智 MCP 硬件控制这类项目大概率也会踩进同一个坑MCP 工具返回true只代表调用链路本身没报错它离“设备真的动了”还差着十万八千里。这篇文章我把自己的排查过程、协议细节和改后的落地结构完整写出来希望能让你少熬几个夜。1. MCP 工具返回 true 的真实含义它到底在说谁成功了要搞清楚true背后藏着什么得先明白 MCP 工具调用在真实项目里是怎么转起来的以及协议层面怎么定义“成功”。1.1 先扫个盲MCP 工具调用到底是怎么“转一圈”的MCP 全称 Model Context Protocol是一个让大模型应用MCP Client与外部工具、数据源MCP Server打交道的标准化协议。在小智的场景里典型链路是这样的用户说“打开风扇”小智端语音助手完成 ASR 语音识别把文字交给大模型大模型在对话上下文中看到“小智”注册了 MCP 工具fan_on决定调用它并在参数里填好设备 ID、开关状态MCP Client 向 MCP Server 发起工具调用请求MCP Server 里的回调函数执行把风扇控制指令通过 WiFi / 串口 / 云端网关下发给设备MCP Server 把执行结果返回给 MCP Client大模型拿到结果生成一句播报“风扇已打开”这里最容易被忽略的是MCP Server 和实际设备之间并不一定在同一个进程里甚至不在同一个网络里。MCP Server 可能运行在树莓派上风扇挂在 ESP32 后面或者 MCP Server 在云主机上设备在国内某个工厂车间里中间还要过一层 IoT 网关。所以“MCP Server 的执行函数跑完了”和“硬件引脚拉高了、电机转起来了”这两件事天然就不是一回事。函数跑完只代表代码逻辑走到了返回语句不代表物理世界也跟着响应了。1.2 协议层眼睛里“成功”的判定标准只有一个isError如果你去翻 MCP 协议规范会发现现代 MCP 工具调用的响应体里有一个专门的字段叫isError它的语义才是协议层面的“成功标志”。一个标准的 MCP 工具返回结构大致是这样{ content: [ { type: text, text: true } ], isError: false }注意两个关键点第一isError: false只表示“工具函数本身执行过程中没有抛异常”它不表示“你下发指令的硬件动作成功完成了”。协议层面关心的是调用的完整性而不是业务的正确性。第二content.text里的true在绝大多数情况下只是一个字符串。它可能是你代码里return true返回的也可能是return true被 MCP SDK 序列化成文本后的结果。也就是说你在小智播报里听到“执行成功”在日志里看到的所谓true很可能只是 LLM 看到了这段文本然后自己推断出来的并不是协议确认的成功。这带来的后果非常隐蔽isError: false不拦你content是true也不拦你整个链路在程序视角看就是“成功”的。于是 false positive 就这么产生了。1.3 “返回 true”和“硬件动作完成”之间至少隔着三个断层我后来把问题抽象了一下“返回 true”到“风扇真的转起来”中间至少隔着三层任何一层断掉都会造成假成功断层一调用接收 ≠ 设备接收。MCP Server 收到请求可能只是把控制消息丢进了消息队列或者发了个 UDP 包出去。消息队列没消费者、设备已经离线、网关宕机这些都不会立刻反映到工具返回值上。断层二设备接收指令 ≠ 动作执行成功。设备收到了指令但执行器卡住、电源电压不够、GPIO 被复用、固件里 switch-case 没覆盖这个动作它照样动不起来。断层三动作执行了 ≠ 状态正确。就算风扇电机转了转速是不是目标转速状态反馈是否真的回传了这些都还是未知数。更极端的情况下设备“动了一下”但很快又自己停了比如过流保护触发这种瞬时动作算不算“完成”只看工具返回值根本无从判断。想只靠一个true覆盖这三个断层等于在项目初始就埋雷。我见过太多团队花大力气调对话、调工具注册最后全卡在“设备没反应”上还找不到原因就是这个道理。2. 小智控制硬件到底走的哪条路先分清楚你的链路再谈 true不同项目里小智和硬件之间的物理链路完全不一样true的可信度也因此有天壤之别。我的建议是先别纠结返回值先把链路图画清楚。2.1 直连型小智跑在 ESP32 上MCP Server 就是本地模块有一种常见玩法是让小智本体跑在 ESP32 这样的边缘设备上再把 MCP Server 以本地模块形式集成进去比如用 ESP32 工业树莓派 CM0 Nano 单板组合的方案。在这种架构里小智和硬件之间没有网络中转MCP Server 直接操作 GPIOtrue的可信度会高不少。即便如此return true仍然不等于“动作完成”。因为 GPIO 写入成功和物理动作成功仍然是两回事你digitalWrite(pin, HIGH)只是把引脚电平拉高如果外接电路的继电器坏了、驱动芯片烧了、电源没接电平再对设备也不动。所以在直连型架构里我通常会给工具函数内部做“电平回读”gpio_set_level(GPIO_NUM_18, 1); vTaskDelay(pdMS_TO_TICKS(50)); int actual gpio_get_level(GPIO_NUM_18); if (actual ! 1) { return MCP_TOOL_ERROR(引脚已拉高但回读失败); } return ok;这一步能挡住一部分“引脚接触不良”的问题但它仍然管不到电机本身。直连型只是缩短了物理距离没有消除物理世界的不确定性。2.2 中转型小智连接云端 MCP Server设备在局域网里通过网关执行更常见的是小智跑在云端MCP Server 也在云端而硬件设备比如 ESP32 设备在本地网络里通过 Wi-Fi、MQTT、TCP 网关或者私有云平台接收指令。这条链路里的true可信度就要打一个大大的问号。我实际见过一条链路是这样的小智(云端) → API 网关 → MCP Server → Redis 消息队列 → IoT 网关 → MQTT Broker → ESP32 设备 → 继电器 → 风扇从 MCP Server 的视角看它只是把一条消息 push 到了 Redis然后就返回true。这个过程里消息是否被 IoT 网关消费、设备是否在线、MQTT 是否订阅成功、继电器是否吸合它完全感知不到。也就是说连“设备接收”这一层都没跨过去true就出来了。这种架构不是错错的是把这种true当成硬件的“完成确认”去播报给用户。用户问小智“风扇开了吗”小智答“已经开了”结果风扇还停在那里——这在智能家居、工业设备里都是致命的信任危机。2.3 小智控制台里注册 MCP 工具时真正关键的是这几个字段不管是哪种链路你要在小智控制台或自己的 MCP Server 里注册工具表面上是在填“工具名 描述 参数”实际上真正影响正确率的是对工具行为边界的描述。我建议注册工具时描述字段里必须写清楚“返回成功代表什么”。举个例子工具fan_on的描述我后来改成了打开指定风扇。参数 device_id 为设备唯一标识speed 为 0-100 整数。 返回成功仅代表指令已受理不代表设备已完成动作。 如需确认设备实际状态请调用 get_device_status 工具查询。你别小看这段描述。大模型是拿描述来理解工具语义的如果描述里写的是“打开风扇并返回结果”LLM 就会天然认为true等于“开了”。改了描述之后LLM 至少学会了一件事想要确认动作是否完成得再查一次状态。inputSchema 也要尽量细化能加enum就加enum能加minimum、maximum就加上。参数越规范后面排查“指令下发了但动不了”时需要怀疑的变量越少。说到底小智控制台上的 MCP 配置界面本质上是你和 LLM 之间的一份“接口契约文档”。契约写得模糊执行时就会靠猜结果必然翻车。3. 我在项目里是怎么把“真成功”和“假成功”分开的三个落地手段讲完了原理直接上干货。下面这几个手段是我在那次风扇事件之后陆续加上去的现在线上的小智 MCP 控制项目基本都沿用了这套思路。3.1 给工具返回体绑一个状态字段而不是一个裸的 true最直接的改动禁止 MCP 工具直接返回true、false这种裸值。我在自己的代码里定义了一个统一返回结构用 JSON 文本返回给 LLM{ action: fan.on, device_id: esp32_fan_01, accepted: true, executed: false, device_status: unknown, detail: 指令已下发至 MQTT等待设备上报执行结果 }字段含义accepted请求是否被 MCP Server 成功受理executed设备端是否确认动作已完成device_status设备当前上报的状态unknown表示还不知道detail给 LLM 和人类看的自然语言说明这样做的最大好处是大模型拿到的不是“成功”而是一个“当前已知信息快照”。它如果够聪明就会说出“我已经下发了指令但设备还没确认完成”这类准确的话术。你可以在提示词里再补一句当executed: false时不要向用户承诺动作已经完成。这个改动成本非常低但对用户体感提升是立竿见影的。以前是“假成功 用户抱怨”现在是“含糊的中间态 至少不出错”。3.2 设备端 Ack 状态轮询让动作完成有据可查要真正做到“硬件动作完成确认”必须让设备端参与反馈。在我当前的架构里任何控制类工具下发的指令都要求设备在执行完之后上报一条 Ack 消息Ack 里至少包含三个字段{ request_id: a3f8c2e1, device_id: esp32_fan_01, result: success, current_state: { power: on, speed: 60, timestamp: 1710123456 } }对应到 MCP 工具的执行流程工具被调用后生成全局唯一的request_id把指令和设备绑定工具函数立刻返回“已受理”accepted: true, executed: falseMCP Server 后台等待设备 Ack或定时轮询设备状态接口收到 Ack 后将结果缓存在状态表里下次 LLM 调用get_device_status工具时直接从状态表里拿值这一步做完executed才真正有数据支撑。为了不让用户等太久我一般还会在工具返回的同时主动触发一个“等 Ack”的异步任务把超时设置在 3~5 秒。如果超时没等到状态表里就写入executed: false, device_status: timeoutLLM 下次查询时就能看到准确结果。3.3 超时、重试和幂等防住“工具返回 true 但结果不对”的最后一道闸硬件控制场景里还有一个老生常谈但必须说的话调用失败不算最可怕的真正可怕的是“同一动作被执行了多次”。想象一个场景小智下发“关闭水泵”指令MCP Server 发出去了但设备网络卡了一下没有及时回应。工具函数等待超时后报了错LLM 决定重试一次。结果设备其实已经执行了第一次关停第二指令又来了设备逻辑没做幂等处理“关闭”再“关闭”于是又把水泵打开了。这种问题在纯软件接口里都有硬件场景更严重。我的处理方式是两个幂等键每次控制类工具调用都带request_id设备端保存最近 N 个已处理的request_id重复的直接忽略并返回上一次的执行结果。重试必须有上限MCP Server 端对控制类指令默认不自动重试除非 LLM 确认request_id未被处理。我见过不少框架默认有限制但很多时候开发者自己写的工具函数里又加了一层无脑 retry等于绕过了框架的保护。超时时间的设置也要根据设备响应特性来。像 ESP32 局域网直连500ms 到 1s 比较合理走 4G 云平台3s 到 5s 才够。你设得太短设备正常执行也会被误判为失败设得太长用户等小智回答会等到抓狂。4. 小智 MCP 踩坑实录return true 背后的一堆“视觉幻觉”最后这部分我把实际排查中遇到过的几个典型问题整理出来每一个都和“返回 true 但真相不是那样”有关希望能帮你少走弯路。4.1 典型坑类型漂移——MCP 返回了字符串 true代码拿它当布尔用这是我在项目里踩过最隐蔽的一个坑。某个工具函数的代码写的是return true但 MCP SDK 把返回值传出去时经常会把布尔值转成文本true。下游的调用方或者 LLM 拿到的其实是字符串而你的校验代码里写的是if (result true) { ... }于是一切顺利的时候没问题但某次日志里出现了一个非常经典的诡异判断e.hasactivated true e.hasactivated。字符串true和布尔true做比较在 JavaScript 里结果是false于是明明设备执行成功了代码却判断成失败走了一遍异常分支最后给用户播报“操作失败”。排查办法很简单在工具函数返回之前用typeof检查一下返回值在接收端也不要直接用 true而是把值先标准化const isOk String(result).toLowerCase() true;这种“看着成功实际失败”和“看着失败实际成功”的左右横跳往往不是硬件的问题而是类型转换的锅。4.2 典型坑工具在云端成功设备端离线消息进了死信队列有一次线上反馈“工具返回 true但家里的小智音箱控制的灯没反应。”我查了 MCP Server 日志全部绿灯查 IoT 网关发现设备明明已经离线一个多小时了。问题出在消息中间件上。MCP Server 的消息发到 MQTT Broker 时设备不在线Broker 按照 QoS 规则把消息转存了但转存队列长时间没被消费最终进了死信队列。MCP Server 完全感知不到这个过程傻乎乎地返回了true。后来我加了一个强制检查工具函数在执行前先调用设备状态接口确认设备在线才下发指令。设备离线时直接返回{ accepted: false, executed: false, device_status: offline, detail: 设备离线请先检查设备电源和网络连接 }这个改动之后那种“假成功”基本绝迹了因为大部分问题都提前暴露了出来。4.3 典型坑动作成功但反馈丢失硬件的“最后一下”没传到还有一种情况最让人崩溃动作真的完成了但确认反馈丢了于是工具返回不了准确的完成状态。我记得有一次排查智能窗帘控制窗帘明明拉开了但状态一直显示“未知”。查到最后发现设备端控制电机的线程正常执行了但负责上报状态的那个线程因为内存不足直接崩了Ack 根本没发出来。对这种反馈丢失我的策略是状态查询工具不能只依赖一条实时 Ack还要维护一份设备状态缓存并且标记“最后更新时间”。查询时优先返回缓存但明确告知 LLM 这个状态的时效性同时触发一次实时状态刷新如果刷新失败至少给 LLM 一个相对合理的历史状态参考而不是让 LLM 胡乱猜测。4.4 顺手整理MCP 硬件控制的典型问题速查表现象可能原因排查点修复方向工具返回 true硬件没动设备离线 / 消息进死信队列查看设备在线状态、消息队列堆积情况执行前检查设备在线状态工具返回 true硬件动了两次无幂等处理LLM 或网关重试查 request_id 是否被设备过滤引入幂等键设备端去重工具返回 false但硬件成功返回类型漂移字符串 true 与布尔 true 比较失败检查 typeof 和严格相等的判断统一按字符串标准化判断工具一直显示 unknown设备 Ack 丢失状态上报线程崩溃查设备端日志确认 Ack 是否发出增加状态缓存 超时标记LLM 播报“已打开”但实际未完成工具描述里未说明“成功仅代表受理”检查 MCP 工具描述文本重写描述明确边界让 LLM 查询状态工具工具调用超时设备响应慢超时设置不合理压测设备执行时间区间按设备类型调整超时时间我现在的习惯是在代码里给每个控制类工具都加一段注释“此返回值不代表硬件完成请以状态查询工具结果为准”然后在代码评审时盯着这行注释看。这个习惯救了我好多次。老实说我现在看到裸返回true的 MCP 工具第一反应不是高兴而是先去看设备状态员的日志。如果你也开始在小智上做 MCP 控制我的建议是现在就定一条规则MCP 工具只负责告诉大模型“请求是否被接收”至于“动作是否完成”必须由设备的反馈来说明。改完之后你会发现群里那个“设备怎么又没反应”的抱怨终于变成了“这次终于动了”的确认。
前阵子调一个小智语音助手的项目真被一个“返回值”整破防了小智通过 MCP 工具下发指令去控制一台工业风扇工具端非常干脆地返回了true日志里一片绿结果风扇纹丝不动。排查到半夜才发现问题不是电机坏了不是接线松了而是我们把“工具调用成功”和“硬件动作完成”这两件事当成了同一件事。这不是个案。只要你正在做小智 MCP 硬件控制这类项目大概率也会踩进同一个坑MCP 工具返回true只代表调用链路本身没报错它离“设备真的动了”还差着十万八千里。这篇文章我把自己的排查过程、协议细节和改后的落地结构完整写出来希望能让你少熬几个夜。1. MCP 工具返回 true 的真实含义它到底在说谁成功了要搞清楚true背后藏着什么得先明白 MCP 工具调用在真实项目里是怎么转起来的以及协议层面怎么定义“成功”。1.1 先扫个盲MCP 工具调用到底是怎么“转一圈”的MCP 全称 Model Context Protocol是一个让大模型应用MCP Client与外部工具、数据源MCP Server打交道的标准化协议。在小智的场景里典型链路是这样的用户说“打开风扇”小智端语音助手完成 ASR 语音识别把文字交给大模型大模型在对话上下文中看到“小智”注册了 MCP 工具fan_on决定调用它并在参数里填好设备 ID、开关状态MCP Client 向 MCP Server 发起工具调用请求MCP Server 里的回调函数执行把风扇控制指令通过 WiFi / 串口 / 云端网关下发给设备MCP Server 把执行结果返回给 MCP Client大模型拿到结果生成一句播报“风扇已打开”这里最容易被忽略的是MCP Server 和实际设备之间并不一定在同一个进程里甚至不在同一个网络里。MCP Server 可能运行在树莓派上风扇挂在 ESP32 后面或者 MCP Server 在云主机上设备在国内某个工厂车间里中间还要过一层 IoT 网关。所以“MCP Server 的执行函数跑完了”和“硬件引脚拉高了、电机转起来了”这两件事天然就不是一回事。函数跑完只代表代码逻辑走到了返回语句不代表物理世界也跟着响应了。1.2 协议层眼睛里“成功”的判定标准只有一个isError如果你去翻 MCP 协议规范会发现现代 MCP 工具调用的响应体里有一个专门的字段叫isError它的语义才是协议层面的“成功标志”。一个标准的 MCP 工具返回结构大致是这样{ content: [ { type: text, text: true } ], isError: false }注意两个关键点第一isError: false只表示“工具函数本身执行过程中没有抛异常”它不表示“你下发指令的硬件动作成功完成了”。协议层面关心的是调用的完整性而不是业务的正确性。第二content.text里的true在绝大多数情况下只是一个字符串。它可能是你代码里return true返回的也可能是return true被 MCP SDK 序列化成文本后的结果。也就是说你在小智播报里听到“执行成功”在日志里看到的所谓true很可能只是 LLM 看到了这段文本然后自己推断出来的并不是协议确认的成功。这带来的后果非常隐蔽isError: false不拦你content是true也不拦你整个链路在程序视角看就是“成功”的。于是 false positive 就这么产生了。1.3 “返回 true”和“硬件动作完成”之间至少隔着三个断层我后来把问题抽象了一下“返回 true”到“风扇真的转起来”中间至少隔着三层任何一层断掉都会造成假成功断层一调用接收 ≠ 设备接收。MCP Server 收到请求可能只是把控制消息丢进了消息队列或者发了个 UDP 包出去。消息队列没消费者、设备已经离线、网关宕机这些都不会立刻反映到工具返回值上。断层二设备接收指令 ≠ 动作执行成功。设备收到了指令但执行器卡住、电源电压不够、GPIO 被复用、固件里 switch-case 没覆盖这个动作它照样动不起来。断层三动作执行了 ≠ 状态正确。就算风扇电机转了转速是不是目标转速状态反馈是否真的回传了这些都还是未知数。更极端的情况下设备“动了一下”但很快又自己停了比如过流保护触发这种瞬时动作算不算“完成”只看工具返回值根本无从判断。想只靠一个true覆盖这三个断层等于在项目初始就埋雷。我见过太多团队花大力气调对话、调工具注册最后全卡在“设备没反应”上还找不到原因就是这个道理。2. 小智控制硬件到底走的哪条路先分清楚你的链路再谈 true不同项目里小智和硬件之间的物理链路完全不一样true的可信度也因此有天壤之别。我的建议是先别纠结返回值先把链路图画清楚。2.1 直连型小智跑在 ESP32 上MCP Server 就是本地模块有一种常见玩法是让小智本体跑在 ESP32 这样的边缘设备上再把 MCP Server 以本地模块形式集成进去比如用 ESP32 工业树莓派 CM0 Nano 单板组合的方案。在这种架构里小智和硬件之间没有网络中转MCP Server 直接操作 GPIOtrue的可信度会高不少。即便如此return true仍然不等于“动作完成”。因为 GPIO 写入成功和物理动作成功仍然是两回事你digitalWrite(pin, HIGH)只是把引脚电平拉高如果外接电路的继电器坏了、驱动芯片烧了、电源没接电平再对设备也不动。所以在直连型架构里我通常会给工具函数内部做“电平回读”gpio_set_level(GPIO_NUM_18, 1); vTaskDelay(pdMS_TO_TICKS(50)); int actual gpio_get_level(GPIO_NUM_18); if (actual ! 1) { return MCP_TOOL_ERROR(引脚已拉高但回读失败); } return ok;这一步能挡住一部分“引脚接触不良”的问题但它仍然管不到电机本身。直连型只是缩短了物理距离没有消除物理世界的不确定性。2.2 中转型小智连接云端 MCP Server设备在局域网里通过网关执行更常见的是小智跑在云端MCP Server 也在云端而硬件设备比如 ESP32 设备在本地网络里通过 Wi-Fi、MQTT、TCP 网关或者私有云平台接收指令。这条链路里的true可信度就要打一个大大的问号。我实际见过一条链路是这样的小智(云端) → API 网关 → MCP Server → Redis 消息队列 → IoT 网关 → MQTT Broker → ESP32 设备 → 继电器 → 风扇从 MCP Server 的视角看它只是把一条消息 push 到了 Redis然后就返回true。这个过程里消息是否被 IoT 网关消费、设备是否在线、MQTT 是否订阅成功、继电器是否吸合它完全感知不到。也就是说连“设备接收”这一层都没跨过去true就出来了。这种架构不是错错的是把这种true当成硬件的“完成确认”去播报给用户。用户问小智“风扇开了吗”小智答“已经开了”结果风扇还停在那里——这在智能家居、工业设备里都是致命的信任危机。2.3 小智控制台里注册 MCP 工具时真正关键的是这几个字段不管是哪种链路你要在小智控制台或自己的 MCP Server 里注册工具表面上是在填“工具名 描述 参数”实际上真正影响正确率的是对工具行为边界的描述。我建议注册工具时描述字段里必须写清楚“返回成功代表什么”。举个例子工具fan_on的描述我后来改成了打开指定风扇。参数 device_id 为设备唯一标识speed 为 0-100 整数。 返回成功仅代表指令已受理不代表设备已完成动作。 如需确认设备实际状态请调用 get_device_status 工具查询。你别小看这段描述。大模型是拿描述来理解工具语义的如果描述里写的是“打开风扇并返回结果”LLM 就会天然认为true等于“开了”。改了描述之后LLM 至少学会了一件事想要确认动作是否完成得再查一次状态。inputSchema 也要尽量细化能加enum就加enum能加minimum、maximum就加上。参数越规范后面排查“指令下发了但动不了”时需要怀疑的变量越少。说到底小智控制台上的 MCP 配置界面本质上是你和 LLM 之间的一份“接口契约文档”。契约写得模糊执行时就会靠猜结果必然翻车。3. 我在项目里是怎么把“真成功”和“假成功”分开的三个落地手段讲完了原理直接上干货。下面这几个手段是我在那次风扇事件之后陆续加上去的现在线上的小智 MCP 控制项目基本都沿用了这套思路。3.1 给工具返回体绑一个状态字段而不是一个裸的 true最直接的改动禁止 MCP 工具直接返回true、false这种裸值。我在自己的代码里定义了一个统一返回结构用 JSON 文本返回给 LLM{ action: fan.on, device_id: esp32_fan_01, accepted: true, executed: false, device_status: unknown, detail: 指令已下发至 MQTT等待设备上报执行结果 }字段含义accepted请求是否被 MCP Server 成功受理executed设备端是否确认动作已完成device_status设备当前上报的状态unknown表示还不知道detail给 LLM 和人类看的自然语言说明这样做的最大好处是大模型拿到的不是“成功”而是一个“当前已知信息快照”。它如果够聪明就会说出“我已经下发了指令但设备还没确认完成”这类准确的话术。你可以在提示词里再补一句当executed: false时不要向用户承诺动作已经完成。这个改动成本非常低但对用户体感提升是立竿见影的。以前是“假成功 用户抱怨”现在是“含糊的中间态 至少不出错”。3.2 设备端 Ack 状态轮询让动作完成有据可查要真正做到“硬件动作完成确认”必须让设备端参与反馈。在我当前的架构里任何控制类工具下发的指令都要求设备在执行完之后上报一条 Ack 消息Ack 里至少包含三个字段{ request_id: a3f8c2e1, device_id: esp32_fan_01, result: success, current_state: { power: on, speed: 60, timestamp: 1710123456 } }对应到 MCP 工具的执行流程工具被调用后生成全局唯一的request_id把指令和设备绑定工具函数立刻返回“已受理”accepted: true, executed: falseMCP Server 后台等待设备 Ack或定时轮询设备状态接口收到 Ack 后将结果缓存在状态表里下次 LLM 调用get_device_status工具时直接从状态表里拿值这一步做完executed才真正有数据支撑。为了不让用户等太久我一般还会在工具返回的同时主动触发一个“等 Ack”的异步任务把超时设置在 3~5 秒。如果超时没等到状态表里就写入executed: false, device_status: timeoutLLM 下次查询时就能看到准确结果。3.3 超时、重试和幂等防住“工具返回 true 但结果不对”的最后一道闸硬件控制场景里还有一个老生常谈但必须说的话调用失败不算最可怕的真正可怕的是“同一动作被执行了多次”。想象一个场景小智下发“关闭水泵”指令MCP Server 发出去了但设备网络卡了一下没有及时回应。工具函数等待超时后报了错LLM 决定重试一次。结果设备其实已经执行了第一次关停第二指令又来了设备逻辑没做幂等处理“关闭”再“关闭”于是又把水泵打开了。这种问题在纯软件接口里都有硬件场景更严重。我的处理方式是两个幂等键每次控制类工具调用都带request_id设备端保存最近 N 个已处理的request_id重复的直接忽略并返回上一次的执行结果。重试必须有上限MCP Server 端对控制类指令默认不自动重试除非 LLM 确认request_id未被处理。我见过不少框架默认有限制但很多时候开发者自己写的工具函数里又加了一层无脑 retry等于绕过了框架的保护。超时时间的设置也要根据设备响应特性来。像 ESP32 局域网直连500ms 到 1s 比较合理走 4G 云平台3s 到 5s 才够。你设得太短设备正常执行也会被误判为失败设得太长用户等小智回答会等到抓狂。4. 小智 MCP 踩坑实录return true 背后的一堆“视觉幻觉”最后这部分我把实际排查中遇到过的几个典型问题整理出来每一个都和“返回 true 但真相不是那样”有关希望能帮你少走弯路。4.1 典型坑类型漂移——MCP 返回了字符串 true代码拿它当布尔用这是我在项目里踩过最隐蔽的一个坑。某个工具函数的代码写的是return true但 MCP SDK 把返回值传出去时经常会把布尔值转成文本true。下游的调用方或者 LLM 拿到的其实是字符串而你的校验代码里写的是if (result true) { ... }于是一切顺利的时候没问题但某次日志里出现了一个非常经典的诡异判断e.hasactivated true e.hasactivated。字符串true和布尔true做比较在 JavaScript 里结果是false于是明明设备执行成功了代码却判断成失败走了一遍异常分支最后给用户播报“操作失败”。排查办法很简单在工具函数返回之前用typeof检查一下返回值在接收端也不要直接用 true而是把值先标准化const isOk String(result).toLowerCase() true;这种“看着成功实际失败”和“看着失败实际成功”的左右横跳往往不是硬件的问题而是类型转换的锅。4.2 典型坑工具在云端成功设备端离线消息进了死信队列有一次线上反馈“工具返回 true但家里的小智音箱控制的灯没反应。”我查了 MCP Server 日志全部绿灯查 IoT 网关发现设备明明已经离线一个多小时了。问题出在消息中间件上。MCP Server 的消息发到 MQTT Broker 时设备不在线Broker 按照 QoS 规则把消息转存了但转存队列长时间没被消费最终进了死信队列。MCP Server 完全感知不到这个过程傻乎乎地返回了true。后来我加了一个强制检查工具函数在执行前先调用设备状态接口确认设备在线才下发指令。设备离线时直接返回{ accepted: false, executed: false, device_status: offline, detail: 设备离线请先检查设备电源和网络连接 }这个改动之后那种“假成功”基本绝迹了因为大部分问题都提前暴露了出来。4.3 典型坑动作成功但反馈丢失硬件的“最后一下”没传到还有一种情况最让人崩溃动作真的完成了但确认反馈丢了于是工具返回不了准确的完成状态。我记得有一次排查智能窗帘控制窗帘明明拉开了但状态一直显示“未知”。查到最后发现设备端控制电机的线程正常执行了但负责上报状态的那个线程因为内存不足直接崩了Ack 根本没发出来。对这种反馈丢失我的策略是状态查询工具不能只依赖一条实时 Ack还要维护一份设备状态缓存并且标记“最后更新时间”。查询时优先返回缓存但明确告知 LLM 这个状态的时效性同时触发一次实时状态刷新如果刷新失败至少给 LLM 一个相对合理的历史状态参考而不是让 LLM 胡乱猜测。4.4 顺手整理MCP 硬件控制的典型问题速查表现象可能原因排查点修复方向工具返回 true硬件没动设备离线 / 消息进死信队列查看设备在线状态、消息队列堆积情况执行前检查设备在线状态工具返回 true硬件动了两次无幂等处理LLM 或网关重试查 request_id 是否被设备过滤引入幂等键设备端去重工具返回 false但硬件成功返回类型漂移字符串 true 与布尔 true 比较失败检查 typeof 和严格相等的判断统一按字符串标准化判断工具一直显示 unknown设备 Ack 丢失状态上报线程崩溃查设备端日志确认 Ack 是否发出增加状态缓存 超时标记LLM 播报“已打开”但实际未完成工具描述里未说明“成功仅代表受理”检查 MCP 工具描述文本重写描述明确边界让 LLM 查询状态工具工具调用超时设备响应慢超时设置不合理压测设备执行时间区间按设备类型调整超时时间我现在的习惯是在代码里给每个控制类工具都加一段注释“此返回值不代表硬件完成请以状态查询工具结果为准”然后在代码评审时盯着这行注释看。这个习惯救了我好多次。老实说我现在看到裸返回true的 MCP 工具第一反应不是高兴而是先去看设备状态员的日志。如果你也开始在小智上做 MCP 控制我的建议是现在就定一条规则MCP 工具只负责告诉大模型“请求是否被接收”至于“动作是否完成”必须由设备的反馈来说明。改完之后你会发现群里那个“设备怎么又没反应”的抱怨终于变成了“这次终于动了”的确认。
)
