当AI学会了“动手”，谁教它“看懂”设备？

lhg09

最近科技圈有个很火的话题：Anthropic发布了模型硬件标准（MHS），被业界称为“物理世界的MCP”。通过这套标准化驱动，AI已经能够直接操控显微镜、机械臂、液体处理器这类高端设备，把集成周期从数周压缩到数小时。有媒体甚至把MHS比作“AI设备时代的USB-C”。

这件事释放了一个强烈的信号：AI正在从数字世界走向物理世界。它已经学会了“动手”。

但作为一个常年跟MCU打交道的嵌入式工程师，我看到这条新闻时，脑子里浮现的是另一个问题：

我的设备，什么时候能被AI“看懂”？

AI的“手”伸出来了，但“眼睛”还没睁开

MHS很强大，但它有一个前提条件：设备必须具备可编程接口，并且能够接入MHS标准。目前MHS的研究预览版，主要面向的是运行Linux、有网络接口、有成熟软件控制层的高端设备——显微镜、机械臂、液体处理器。

这可以理解。MHS是Anthropic面向科研和先进制造场景的第一步棋，先解决“高价值设备”的操控问题，是合理的商业选择。

但全球还有数以百亿计的嵌入式MCU设备呢？它们跑在电机控制器里、跑在电源模块里、跑在传感器节点里。没有操作系统，只有串口和几KB内存。它们同样需要被AI理解、被AI调试、被纳入物理世界的协作网络。但它们离MHS的标准还差得很远。

更根本的问题在于：这些设备的能力，目前没有被结构化地表达出来。

技术文档人能读但机器读不了；私有协议每家不同，换设备就重写适配层；调试经验散落在工程师脑子里，A工程师离职B工程师从头学起。AI虽然学会了“动手”，但它找不到足够多的设备让它“动手”——因为大量嵌入式设备的“能力”，从来没有被翻译成机器能理解的语言。

一个务实的思路：让设备“自己说话”

我业余时间一直在折腾一个叫Connecting的小项目，想从设备端解决这个问题。

思路不复杂：在设备固件中用宏标记需要暴露的变量、服务和事件，编译后自动提取一份设备能力模型（DCM）。这份DCM是机器可读的结构化文件，包含设备的数据流、可执行服务、事件通知和类型系统。

它不是给人看的文档，而是给机器读的“说明书”。

和MHS的关系可以这样理解：

对比	MHS	Connecting
目标	AI如何控制设备	设备能力如何被描述和发现
设备要求	有可编程接口，支持完整驱动	集成轻量中间件，编译时生成DCM
适用平台	实验室仪器、机械臂	MCU、嵌入式控制器、资源受限设备
描述生成	驱动生成参考文件	从编译产物自动提取

Connecting不是MHS的竞争者，而是它的上游。 它让那些无法直接接入MHS的设备，通过DCM获得被AI理解的基础能力。MHS解决“AI如何操控设备”，Connecting解决“设备如何被AI发现和描述”。这两层结合起来，才是完整的“AI+嵌入式”闭环。

当前进展

之前我在论坛发过一个帖子，分享了用正点原子探索者F407跑通这套工具链的完整流程——包括中间件集成、ELF文件提取、DCM生成、上位机导入和实时波形显示。工具链目前已经能实现：读取设备信息、实时状态监测、变量读写、实时波形绘制、日志打印、服务调用等功能。

帖子链接在这里：[分享] 折腾了一个通用的调试小工具（F407跑通，可移植到其他MCU）
也可以去gitee  仓库了解一下，connecting 如何连接AI 和设备，Gitee组织：https://gitee.com/connecting_repo

如果你对这个方向感兴趣，欢迎去原帖看看，也欢迎在评论区聊聊你的想法。

AI的“手”已经伸出来了，接下来该轮到嵌入式设备“开口说话”了。