AI Agent 与硬件

TL;DR

Anthropic 于 2026 年 8 月发布了模型硬件标准（MHS）：用“语义化硬件描述 + 读/写可编程接口”组成的标准驱动层桥接 LLM 与硬件，让 Agent 像操作软件一样操作物理设备，并推荐 MCP、命令行、API 三种桥接机制。
回顾我在 2022-2023 年落地的设备调度系统：用驱动定义设备的参数与指令，用脚本语言编排流程，这与 MHS 的可编程驱动思路有一些关联。当时试过让 LLM 写流程脚本和按需动态生成脚本两条路，只有前者划算；MHS 的案例大体也还是「让 Agent 写流程」，只是 Agent 现在能连驱动层一起探索并开发出来。
更激进的“让 LLM 实时生成代码直接控制设备”实验效果不佳：LLM 的吞吐速度跟不上精细控制的反馈频率。人形机器人领域的 VLA 模型（如 Figure AI 的 Helix）在这条路上走得更远，但 Claude 这种尺寸的模型接入控制端仍无成熟方案。
一个新的设想：不再把 LLM 约束成只会写静态 IF-ELSE 的工具，而是让它成为程序本身的一部分，催生具备学习能力的动态程序。对软件而言，LLM 若只提升产量而非质量，恐怕叩不开下一代工业革命的大门。

1. 背景

2026 年 8 月 27 日，Anthropic 发布了一篇有趣的文章 Previewing the Model Hardware Standard，介绍了一个他们提出的新概念，模型硬件标准（Model Hardware Standard，MHS），简单来说，Anthropic 希望通过这样的一套标准框架，让 LLM 或者说 AI Agent 能够像操作软件一样操作各种硬件，将 AI 能力扩展到物理世界。这是一个有趣的尝试，并且与我过去设计、开发的设备调度与集成系统有着紧密的联系，因此我想基于这篇文章，来谈一谈我理解的 AI 与硬件之间的关联和壁垒，以及是否有一种更新颖的方式将 LLM 的能力应用在系统工程与开发之中。

我会按下面这个步骤来整理我的观点：

简单讲讲 MHS 这篇文章
讲讲过去几年里我做过的相关的事情
我对在硬件系统里应用 LLM 的一些过往实验和基本的设计猜想（这些实验目前还没有特别让我满意的结果）
探讨一种新的方式将 LLM 集成在系统开发或者系统工程之中

2. MHS

我简略地概述一下 Anthropic 文章的主要内容，如果对细节感兴趣，请阅读原文，文中各个参与实验的合作例子都颇具启发性。

简单来说，MHS 的主旨在于通过一个标准硬件驱动层来桥接硬件与 LLM，驱动主要由 3 部分组成，第一是语义化的硬件描述，LLM 通过这些描述来建立对硬件的理解和认知；第二和第三分别是“读”与“写”这两类语义下的可编程接口，就像 PC 设备的 IO 一样，LLM 可以通过编程的方式来使用这些接口。此外，MHS 也简单规范了桥接的技术细节，它推荐了 3 个机制：MCP、命令行界面、API，这基本也对应了目前 AI Agent 控制其他软件最常用的 3 种技术方案。

文中给出了一些合作伙伴在 MHS 的指导思想下进行的实验，覆盖的基本是一些科研流程。LLM 在这个过程里表现出的有趣方面，我总结如下：

LLM 能够探索和实验各个硬件，理解事件的因果序列以及用户的目标要求，并最终通过编程的方式将学习到的内容固化，让它无需重复推理就可以操作硬件完成整个流程。
LLM 仍然发挥了它的编程优势，通过对设备的探索与理解，极大加速了开发一套设备集成系统的过程，并降低成本。

不过，一些合作总结也暴露出了 LLM 在这个领域的弱点，主要是它对真实世界的感知和推理仍然有局限，以至于在产生错误时，虽然会尝试自主纠正，但有时它的直觉和理念是不正确的。

3. 设备调度系统

在我过往的工作经历中，有两段经历都是从事设备调度系统相关的设计和开发工作，其中包括设备管理、调度算法、最优化等等诸多方面。业务场景集中在如何使用更多的自动化（智能）设备，将工厂、仓库内的各种生产流程进行编排、调度，合理地选择不同的机器参与并完成工作。

这种系统一开始我们做得很笨，甚至是不停地在为不同业务场景定制开发一些集成系统和算法。但最终我们开发了一套尽可能通用的软件，来统一处理不同的设备与问题。它的设计核心围绕如下两个概念：

驱动：定义各种设备的可读取的参数、可使用的指令
流程：一个复合的有向有环图，设定了整个业务的执行环节，包括使用何种设备的指令，以及指令之间的参数如何换算与传递。

在实际落地的场景中，我们把最优化算法的执行器也抽象成了一种设备，为它设计了驱动，从而能让它流转于业务环节当中，完成各种优化参数的功能，包括根据多个设备的状态和场内的环境来选择合适的设备完成任务、决策任务之间的冲突问题，甚至为那些移动类的设备做合理的路径规划和路径冲突决策。

更进一步，我们设计了一种简单的脚本语言来定义流程，这个语言包含了特定的分支与循环语法，甚至我们还为它设计了 IDE 上的代码插件。有了这套系统，开发一个新的定制化场景就非常容易，只要能定义出场景内的设备驱动、完成流程的脚本开发，剩下的就只有简单的调试工作。

这套体系完成并正式投产大约是在 2022-2023 年，在那个时候我们也试想过两种与 LLM 结合的方案：

让 LLM 替代工程师去开发流程脚本
让 LLM 能够根据用户的输入需求，动态生成流程脚本

这两种方案在试验场都可以很容易地落地，但实际使用中只有第一种具备更好的价值，理由很简单，第二个方向太贵了。

本质上，这种调度系统的设计理念其实和 MHS 是一致的，它们都围绕可编程驱动与过程来实现，这个过程的本质就是一段程序。但 3 年时间过去，LLM 的能力有了本质的飞跃，与这些概念结合起来，想象空间大了不少。不过，从 MHS 文中介绍的各种应用例子来说，这种应用还是停留在上述的第一种方案，只是覆盖面更大，Agent 可以把驱动层一并开发完成，并且可以自行探索来完成流程脚本代码的开发与迭代，而不完全依赖于工程师的先验知识。

4. 更为激进的实验——尝试让 LLM 直接实时控制设备

除了让 LLM 参与到设备的调度和基本使用之外，我也做过一些更加激进的实验，这个实验的启发是来自于一个设备供应商的控制器架构方案——他们把一个简版的 .NET 运行时环境嵌入到了设备的操作系统中，对外则不再提供 API，而是让用户上传 .NET 编译后的 DLL 文件，设备会根据 DLL 文件的内容来完成其中规定的动作。由此我们尝试把用户的要求和设备的实时数据输入给 LLM，让它直接生成代码，并把代码片段传输到机器上，让它执行动作。

这件事情的本质就是让 LLM 替代设备本身那些策略算法代码完成对设备的控制，例如运动控制、PID 等等。但整体效果并不理想，原因也显而易见，LLM 的吞吐速度太慢，以至于它没法合理地与精细控制的反馈频率相匹配。

这样的尝试方式和控制过程，在人形机器人上似乎逐渐被主流技术路线所接纳，甚至有专门的 VLA 模型来主导基于视觉传感的机器人动作，其中也不乏很多精巧的架构设计，来平衡模型输出频率与设备控制反馈频率之间的协调问题，让我印象深刻的是 Figure AI 提出的 Helix。但是把 Claude 这种尺寸的 LLM 接入到设备控制端，目前似乎仍然没有成熟的解决方案。MHS 提出未来准备兼容 LeRobot，或许会有有趣的发展。

5. 尝试一种新的将 LLM 集成进系统的方案

这个想法本身与 MHS 关系不大，但从 MHS 文章中的一些例子，又给了我一点启发。LLM 的一个有趣作用就是它能够承担更复杂的、代码无法完全表述出的逻辑判断。如果是纯代码，逻辑基本只能通过分支来表达，而后在面对更复杂的场景时，会加入一些算法，将信号转换成可编程的 IF-ELSE，例如 PID 算法、各种专用的深度学习模型等等。而今，我们也在使用类似的方式来将 LLM 约束到能够编写静态 IF-ELSE 的程度，但这显然不是 LLM 能做的全部。这样得到的仍然是静态的、缺少学习能力的代码片段。

而从 MHS 这些使用案例里，LLM 的自动探索能力以及根据用户的要求与说明实时做出调整与反馈的能力，几乎是完成场景中科研任务的必备条件。所以，也许可以考虑把 LLM 真正看作是图灵机的一部分，让它成为程序本身的一部分，而非仅仅扮演编程者的角色。由此催生的具备学习能力的动态程序，或许能帮助我们利用 LLM 技术开发出更高质量的产品。

毕竟，对于软件而言，如果 LLM 只是把产量提高而非质量提高，那么恐怕是无法叩开下一代工业革命的大门的。