什么是 MHS？

加州一家生物科技公司，一台液体处理工作站正在做实验，每次移液，摄像头都会拍一张照片，视觉算法要识别画面里有没有异常。这一次，它在吸头里发现了气泡异常。

收到警报的 AI Agent 判断，问题大概率出在源试剂，通过低速离心的操作可以消除气泡。

于是它调度机械臂把孔板移下工作台、自动封板，再通过 Slack 发消息通知实验员把板子搬到旁边的离心机；离心完成后，再搬回、去封、放回工作站重试，整个实验没有因此中断。

听着像是一个机器人在实验室独自完成了这些操作，但其实是 AI 把液体工作站、相机、机械臂、离心机这些来自不同厂商的设备，全部组织在了一起，给 Agent 调用。

图｜Claude 可以使用 MHS 系统操作摄像头，拍摄每次移液过程的照片。这些照片由计算机视觉算法处理，以识别移液错误，例如气泡和泡沫。一旦检测到错误，Claude 就可以进行干预。

让这件事成为可能的，正是 MHS 在其中所起到的作用，一套让 AI Agent 安全操控物理设备的共享规范。

如果在我们日常的生活办公里，Agent 也可以借用不同设备的眼睛、耳朵和手脚，我们一直在设想的AI 终端，它还必须是一台独立的硬件吗？

MCP 的硬件版？不够全面

就像现在所有的办公/本地 Agent 里，一定会有一个页面叫「技能/连接器/专家」，里面的连接器可以帮助用户将 Agent 连接到不同的应用。

这是大多数都是依靠应用的 MCP 协议（Model Context Protocol，模型上下文协议）。2024 年 11 月底，Anthropic 推出了这项开放标准，用来统一大模型与外部数据源和工具之间的通信协议。

和今天的 MHS 很像，一个用来统一大模型与软件，一个用来统一大模型与硬件。

但严格来说，MHS 不是MCP 的硬件版本，它更像是和 MCP 一样，作为 AI 连接世界的一个环节。

MCP、命令行和 API，只是控制 MHS 设备的三种入口。MCP 解决的是 AI 怎样调用软件；MHS 解决的是 AI 怎样认识一台陌生机器、知道它能做什么，以及最多能做到哪一步。

这条控制链可以简化为：用户目标 → AI Agent → MCP / CLI / API → MHS 驱动 → 物理设备

还是用实验室来举例子，Anthropic 也提到希望 MHS 一开始用来加速科学研究。在一间典型的实验室里，显微镜、分析仪、机械臂往往来自不同厂商，这些设备之间互相不通信，要靠专家手写定制的集成软件。

过去，想让这些设备协同工作，一台相机和一个显微镜的载物台，研究员需要在它们之间构建一个定制的软件集成方案，而每增加一台设备，情况就会变得更复杂。

使用 MHS，每个设备只需要通过接口连接一次，任何支持 MHS 协议的设备都能与其他同样支持 MHS 协议的设备通信，且所有的设备可以直接以裸机速度进行通信。

最通俗地说，它给每台机器配了一套 AI 看得懂的“万能遥控器 + 电子说明书 + 设备通讯录 + 保险丝”，让设备能够把自己的信息处理成 Agent 可以读懂的上下文信息，并让 Agent 控制操作。

这些信息可能包括设备介绍、当前的运行状态、可接受的操作、边界声明，以及是否能被发现和被组网等。

Anthropic 提到这套设计的应用价值能够降低成本，原本要几周甚至几个月的多设备集成，有希望缩短到几个小时或几分钟。

卡内基梅隆大学的早期案例中，Agent 跨三台电脑编排四类设备，把实验跑得比以前快约 3 倍。

这套实验装置分散在三台电脑上，机械臂靠把任务文件丢进指定文件夹启动，液体处理器使用旧式接口，分析仪器没有 API，只能操作图形界面。每台设备都有自己的状态、报错方式和启动顺序。

MHS 试图在现有设备接口之上增加共同的描述与调用方式：驱动封装不同机器的读写和操作，参考文件说明设备能力与安全限值，发现机制让 Agent 找到已经接入的设备。

每接入一台新设备，开发者仍要先写好驱动。毕竟 MHS 统一的是设备被描述和调用的方式，无法凭空获得机器原本没有开放的控制能力。

这些案例也说明了 MHS 这套设计能让 Agent 更好地理解陌生设备，除了提供按钮，还把设备自重、能力、参数这些原本需要翻手册，和只在工程师经验里的知识，转成机器可读的信息。

以及从遥控单机升级为跨设备编排，Agent 可以查看实验室里有哪些设备、判断谁能解决问题，再调度它加入工作流。

图｜Claude 正在独自操作一台徕卡显微镜，它负责聚焦显微镜，寻找细菌，并决定接下来要捕获什么

另外一个比较有意思的案例是，量子计算公司 QuEra 采用 MHS 帮助他们更准确的操作设备。

在量子计算机里，一束激光偏离目标频率，整台机器都可能停下来。过去，这类少见而棘手的故障往往要请熟悉整套光路的专家处理，人工重新锁定通常需要 5—10 分钟。

QuEra 让 Claude 在一套价值约 70 万美元的专用测试台上尝试恢复方法。人类先规定可操作范围、逐步审查动作，并定义什么才算恢复成功；Claude 再提出方案、上机测试，最后把找到的逻辑写成一套自动复锁程序。

团队随后人为制造了 700 次故障，分成 7 类、每类 100 次，程序成功恢复 695 次，成功率 99.3%。简单故障耗时 0.9—5.4 秒，最难的一组也只用了 10—14 秒。

Agent 最有价值的位置，未必是永远握着控制杆，也可以是在受限环境中处理未知，把验证过的方法固化成可检查的流程。

此外，这套设计就像 MCP 一样，不仅仅面向 Claude。在每台设备的驱动写好之后，用于控制的 Agent 可以不用是 Claude。

它适配任何带可编程接口的设备，也和基础模型的种类无关——任何 Agent 框架，都可以通过 MCP 这样的标准协议接入。

这一点其实也是把硬件和模型从捆绑中解放了出来，厂商也不用再给每台机器内置一个专属 AI 助手，只要把能力标准化地暴露出来，同一台设备，云端的通用模型能调，本地的小模型也能调。

就像USB-C 统一的是设备怎么接上电脑，MHS 想统一的是设备怎么向 AI 介绍自己。在未来的 AI 硬件里，模型说不定是最容易替换的那个零件。

AI 终端，未来不再是一台终端

MHS 的首批案例都在实验室和先进制造环境里。

从实验室往更大众化的场景看，在消费电子领域，其实已经有一种更封闭的跨设备协作，那就是苹果/小米/鸿蒙生态等等。

苹果的 Continuity 能让 iPhone 临时充当 Mac 的摄像头，也能把任务从一台设备接到另一台设备；HomePod 或 Apple TV 4K 可以充当家庭中枢，接入 Apple Home 的兼容配件负责开灯、上锁与调温；App Intents 则让开发者预先声明应用可供系统调用的动作。

这些体验和 MHS 不是同一种技术，但指向同一个趋势，一个真正的 AI 终端不需要一副新的形态，只需要能随时被 Agent，或其他程序调用。

这其中的区别在于今天的跨设备协同更像一支提前排练好的乐队，协同方式由厂商和开发者预先写好。

MHS 则更像 Agent 的智能编排，依靠模型的能力，AI 可以根据任务动态决定调用哪些设备。交互的单位，也会从打开哪个 App转向完成什么任务。

我们买一副 AirPods，得到了苹果生态里的一双耳朵。

而在 MHS 这种模型硬件标准下想象的未来是，任何合规的摄像头、麦克风、手表或机器，都能在获得许可后，暂时成为任何 Agent 的眼睛、耳朵和手。

顺着这个逻辑，未来判断一款硬件是否AI 原生，不能只看有没有 NPU、聊天框或内置大模型，可能还要看这个设备，

能否向 Agent 清楚地暴露自己的能力；

能否进入跨品牌、跨设备的任务流；

是否拥有可靠的传感器和执行器；

是否保留本地的安全否决权；

以及用户能否查看、暂停和接管 Agent 等。

AI 硬件也会从比较内置了谁家的大模型，变成能否被发现、理解、组合和安全调用，要让 Agent 获得许可后，能把身边已有的设备临时组装成一副身体。

图｜使用 MHS 接入你的设备

当前，MHS 仍处于申请制的研究预览，也并没有像 MCP 协议一样开源，离真正的行业标准可能还有距离。

在早期的测试案例里，Anthropic 也记录了一些翻车的案例，他们认为 Claude 是通过文本和图像学习物理世界的，空间和物理推理仍有明显局限，现阶段离不开专家监督。

这也是为什么，AI 从软件世界走进物理世界之后，可调用必须和可约束同时存在。代码写错了还能回滚，但机械臂已经撞下去、试剂已经倒出来，现实世界没有 Ctrl+Z。

不过 MHS 真正值得关注的地方，或许正是在这里：它开始尝试把硬件可以被 Agent 安全调用变成一种基础能力。

等摄像头、麦克风、机械臂乃至家里的各种设备，都能被 Agent 发现、理解和组合，我们可能不再需要为 AI 单独造出一双眼睛、一双耳朵和一双手。

它只需要获得许可，然后暂时借用我们身边已经存在的这一切。