统一 Driver：设备被压缩为 read / write + 可发现能力
MHS 为设备引入标准 Driver，用 read / write 这类简单原语暴露传感和执行能力，并让设备以统一格式被发现。目标是把过去按设备定制的“翻译器”收敛成标准接口。
Deep Research Topic
Anthropic · Model Hardware Standard
2026-09-29 · v1
图解更新 2026-10-06 · SVG v2
MHS：让慢速 Agent 控制高速物理世界的关键，不是“更快地思考”，而是“把学会的控制下沉为确定性程序”
Anthropic 的 Model Hardware Standard（MHS）表面上是一个 AI-to-Hardware 标准，真正值得研究的是它隐含的控制架构：用标准 Driver 把异构设备暴露成可发现的 read/write 原语和带安全边界的能力描述；让 Agent 在低频决策点探索、推理、调参和学习；一旦任务需要长时间运行或速度高于在线推理，就把多设备命令链固化为代码文件，由设备/本地程序自行执行。MHS 因而不是实时控制器，而是连接“概率智能控制面”和“确定性执行面”的桥。
🎞️ 表示本节含 SVG 动画。
一、核心判断：MHS 的本质不是“自然语言控制硬件”，而是 Agent 控制系统的分层
把官方已证事实、LRI 工程判断和仍待验证的假设分开。
能力描述不只来自 API，还包含物理语义与安全限制
Driver 的 tags 可以记录代码本身看不出的物理特性，例如机械臂重量、可测量/可调参数以及将被强制执行的安全限制；这些信息被整理成参考文件供 Agent 使用。
真正创新点是“Exploration → Program Synthesis → Fast Path”
Agent 先像科学家一样探索：调一次、看结果、再调；当规律稳定后，把行为打包成确定性脚本。之后高速/长时任务由代码执行，Agent 退到监督、异常和策略更新层。
MHS 不是 RTOS、Servo Bus，也不是高频机器人控制器
公开材料没有给出 hard real-time scheduling、jitter bound 或 servo-loop 保证。高频闭环最终仍需要本地程序、设备控制器、固件或专用实时栈；MHS 解决的是统一可编程接口和 Agent 可理解性。
最强证据：最终控制器脱离 Agent 运行
QuEra 案例中，Claude 通过 MHS 反复实验并改写激光重锁脚本；最终盲测 700 次成功 695 次（99.3%），而成品是“deterministic, fully inspectable script”，生产运行时不需要 AI Agent 控制。
标准是否能从实验室走向通用工业控制，仍未闭环
MHS 截至本专题日期仍处于 limited research preview，尚未公开完整规范/开源实现；驱动兼容、实时语义、版本治理、权限租约、审计和认证等生产问题仍需等待公开标准与独立验证。
一句话：如果 MCP 解决“Agent 如何调用软件工具”，MHS 试图解决“Agent 如何理解并安全调用物理设备”；而从慢速模型跨到高速设备的核心桥梁，是 把模型学到的控制策略变成可验证、可回放、可独立运行的确定性程序。
二、MHS 到底标准化什么？
不是统一所有硬件通信协议，而是定义一个 Agent 可消费的硬件抽象层。
Driver
设备适配层
在操作系统/计算机与具体设备之间建立标准 Driver；底层仍可使用厂商 SDK、串口、网口、专用总线等。
Primitives
read / write
把“读温度、取相机状态、设定温度、移动执行器”等动作统一成少量基本操作，降低 Agent 面向不同厂商接口的复杂度。
Tags / Reference
机器可读物理语义
用自然语言 tags 补充设备能力、物理特性和安全上限，再自动形成 Agent 的设备参考文件。
Control Paths
MCP / CLI / Code
官方明确给出三种控制机制：MCP、命令行和代码文件/API。它们共享同一设备抽象，但适合不同控制频率和任务形态。
| 问题 | MHS 的回答 | 没有回答的部分 |
|---|---|---|
| 设备如何被 Agent 找到？ | 统一发现与标准化设备描述 | 大型 fleet registry、跨域发现和租约治理的完整规范尚待公开 |
| Agent 如何知道设备能做什么？ | Driver + tags + reference file | 物理语义是否有强类型 ontology / formal schema 尚不清楚 |
| Agent 如何操作设备？ | MCP / CLI / code file | 硬实时调度、确定 jitter、总线级 QoS 不属于已公开主张 |
| 如何限制危险动作？ | 设备参考中声明并 enforce safety limits | 安全规则的形式化能力、组合安全和证明机制仍需验证 |
| 多设备如何协同？ | Agent 在统一接口上编排，代码文件可串联多设备命令 | 事务语义、锁、并发冲突、故障域隔离仍需更多规范 |
三、五层架构：MHS 应该放在控制栈的哪一层？
把“智能”“接口”“确定性程序”“实时控制”“物理安全”拆开，才能理解它为什么能跨越模型与设备。
L0 · Reasoning
Agent / LLM
目标理解、实验规划、异常解释、假设生成、参数策略与程序生成。自由度最高，但延迟和输出不确定性也最高。
L1 · Agent I/O
MCP / CLI
面向 Agent 的调用入口，适合发现、单步读写、调试和低频交互；MCP 是可选标准协议，不等于 MHS 本身。
L2 · Hardware Abstraction
MHS Driver
把各厂商设备映射为统一原语，承载能力描述、物理语义与设备侧安全约束。
L3/L4 · Fast Control
Code + Device Controller
确定性脚本、控制器、固件和实时循环承担长时、高频、低抖动执行；Agent 不必参与每一个控制 tick。
关键边界：MHS 把“会不会操作设备”的知识标准化，但不应该把“每个控制周期都由 LLM 决定”当成目标。可靠物理系统需要把硬安全、实时循环和大部分重复控制移到模型之外。
🎞️ 四、低 Hz 智能 vs 高 Hz 硬件：MHS 如何弥合控制频率鸿沟？
下面的频率只是工程量级示意，不是 MHS 规范保证；不同设备可相差数个数量级。
图中周期与计数是明确设定的数值例子：2 秒窗口分别按 2 秒、100 毫秒、10 毫秒和 1 毫秒周期计算。密集刻度聚合显示，12 秒播放周期不代表真实时间。可暂停、拖动进度、切换播放速度和全图/清晰视图。
| 层 | 典型节奏（示意） | 适合做什么 | 为何不能都交给 LLM |
|---|---|---|---|
| Agent 在线推理 | 亚 Hz ～ 数 Hz | 规划、假设、选择实验、异常处理 | 网络/推理延迟高，尾延迟不可预测，输出概率化 |
| 任务/参数编排 | 数 Hz ～ 数十 Hz | 状态观察、参数更新、步骤切换 | 仍可能受 RPC、进程调度和模型调用影响 |
| 本地确定性程序 | 几十 Hz ～ kHz 级（依设备） | 重复动作链、条件分支、持续采样与反馈 | 需要可重复、低开销、可审计 |
| 固件/Servo/硬实时控制 | 百 Hz ～ 多 kHz（依设备） | 电机、PID、保护环、同步采样 | 必须有严格时序与安全闭环，不能依赖在线大模型 |
阶段 A · Agent 探索
模型通过 MHS 读传感器、改参数、观察结果，建立因果/经验模型。这个阶段可以慢，因为价值来自试错和推理。
阶段 B · 策略固化
模型把反复成功的动作链写成 if/then、循环、状态机或优化程序，并定义成功判据、超时和异常路径。
阶段 C · Fast Path 执行
控制程序直接调用多个 MHS Driver；设备自行运行，Agent 只接收摘要、异常和需要升级判断的状态。
核心洞察：解决 Hz 鸿沟的不是“让模型从 1 Hz 提升到 1 kHz”，而是 让模型只参与信息增益最高的少数决策，把可重复部分编译成高速控制程序。这与现代 CPU/GPU 中 control plane 与 data plane 的分工更相似。
五、从一次性 Agent 操作到可生产控制器：MHS 暗示了一条新的 Agent 生命周期
QuEra 案例显示，Agent 的最终产物可以不是“完成一次任务”，而是“生成一个以后不需要 Agent 的控制程序”。
1 · Discover
发现设备与约束
读取能力、状态、可调参数、物理属性和 safety limits。
2 · Explore
在受控环境试验
通过 read → write → observe 循环建立对设备行为的经验，记录失败模式。
3 · Synthesize
生成确定性程序
把有效动作序列重构成条件树、状态机、优化器或控制脚本。
4 · Validate & Deploy
脱离 Agent 验证
用随机扰动/盲测验证脚本；通过后进入生产 fast path，Agent 仅在异常和重学习时回到环内。
LRI 推论：未来 Physical Agent Runtime 可能需要把“程序合成、沙箱执行、trace、回放、A/B、版本化、回滚”做成一等能力。模型本身只是控制器生成器/升级器，而不是永远在线的执行器。
六、真实案例：MHS 已经证明了什么？
案例均来自 Anthropic 研究预览材料，属于一手 partner evidence，但不是独立通用 Benchmark。
激光重锁：58% / 150s → 99.3% blind test
原有人类经验脚本约 58% 成功、每次约 150 秒；Claude 通过 MHS 在夜间循环中提出假设、改脚本、真实执行并复盘。开发过程达到约 6 秒/96%；最终固定脚本在 700 次随机扰动盲测中成功 695 次（99.3%）。困难扰动 10–14 秒，简单扰动约 0.9–5.4 秒。最终脚本在生产中可脱离 Agent 运行。
七套厂商程序 → 共享设备状态与 Agent 决策点
两光子显微系统原本由不同厂商设备与 MATLAB/Python/C# 控制程序拼接。MHS 把 rig 状态统一到标准接口，Agent 可在真正需要判断的位置选择成像区域、参数和分析方式，而采集/分析的确定性环路继续高速执行。
液体处理 + 机械臂 + 读板仪
BCA 蛋白实验需要三类设备协同。MHS 用统一接口降低定制机器人代码的门槛，但也暴露模型缺少物理直觉：遇到泡沫导致的运行错误时，Claude 最初把它当成可重试的软件问题，反而制造更多气泡，最终需要专家指导。
LeRobot / Raspberry Pi 等早期接入
Anthropic 公告称 Hugging Face 正在为 LeRobot 增加 MHS 支持，Raspberry Pi 也在基于 Camera MHS Driver 推动多款产品接入。说明 MHS 的目标不仅是实验室设备，也试图进入开源机器人和通用边缘硬件生态。
七、技术比较：MHS 不应该替代谁？
把协议、硬件抽象、机器人中间件、VLA 和实时控制放在正确层次。
| 技术 | 主要职责 | 与 MHS 的关系 |
|---|---|---|
| MCP | Agent 与工具/资源之间的标准协议与调用模型 | MHS 可通过 MCP 暴露；MCP 是 Agent I/O，不定义具体硬件物理语义 |
| MHS | Agent-facing 硬件 Driver、能力描述、统一 read/write、安全边界 | 位于 Agent 和具体设备接口之间，是本专题研究对象 |
| Vendor SDK / Device API | 访问具体厂商设备 | 可作为 MHS Driver 的底层实现；MHS 试图消除上层对厂商差异的感知 |
| ROS 2 / ros2_control | 机器人消息、节点、硬件接口、控制器与生态 | 更完整的机器人 runtime/control stack；MHS 更像 Agent-facing 抽象，两者可互补而非简单替代 |
| VLA / Robot Policy | 从视觉/语言/状态预测动作或 action chunk | 负责“决定怎么动”，MHS 负责“如何以统一、安全接口触达设备”；高频动作仍常需本地 controller |
| RTOS / Servo / Firmware | 硬实时闭环、同步、保护、低 jitter 控制 | 是 MHS 下方的执行层；公开 MHS 材料没有取代这些能力 |
八、安全：物理 Agent 的关键不是“模型更聪明”，而是“模型不能突破设备边界”
MHS 的价值高度依赖安全限制是否在模型之外被可靠执行。
把 limits 写入 Driver/Reference
最大速度、温度、功率、行程、工作区等约束不应依赖 prompt 记忆；MHS 的公开设计方向是由设备描述声明并 enforce。
语言模型会把物理故障误判成软件故障
Genentech 的泡沫案例说明：即使设备接口完全标准化，模型仍可能不理解流体、碰撞、惯性、热效应等真实物理过程。
生成脚本必须比模型单步操作更严格
脚本一旦下沉，就会更快、更久地执行错误。因此需要静态检查、权限最小化、仿真/影子运行、硬限幅、超时、Watchdog、审计和一键停机。
需要标准明确回答的问题
多 Agent 同时控制一个设备时谁持有 lease？如何定义 emergency stop？write 是否幂等？如何表达跨设备 interlock？断网/进程崩溃后的 fail-safe 状态是什么？driver/schema 如何版本化？
当前证据边界
官方案例证明“可工作”与“可显著提效”的可能性，但并不能证明 MHS 已经具备工业功能安全、hard real-time 或形式化安全保证。研究预览应按 preview 对待。
🎞️ 九、对 Agent Runtime 的架构启发
MHS 最值得借鉴的不是某个 API，而是把智能控制拆成可治理的两条路径。
长期资产中心不是“对话中的 Agent”，而是 Program + Policy + Evidence：Observe → Reason → Synthesize → Validate → Deploy → Execute；遇到 fault/novelty 后携带真实 trace 回到改进环。在线任意改代码并热切换仍是研究假设，不作为 MHS 已证事实。
1. Slow Path：模型只负责高信息增益决策
目标、规划、未知故障、策略搜索、参数空间探索由模型承担；常规重复控制不消耗 frontier reasoning。
2. Fast Path：程序是 Agent 的“动作记忆”
成功动作序列应能被版本化为代码/状态机，而不是永远保留在对话上下文。程序可以复用、测试、diff、回放和回滚。
3. Portable Sandbox 值得研究
官方案例使用 Python 脚本，但从系统设计看，受限 Wasm/DSL 等可验证运行时可能更适合跨设备、安全权限和资源配额；这是 LRI 假设，不是 MHS 当前设计结论。
4. Observation → Program Improvement Loop
设备 trace 不只是日志，而可以成为 Agent 重新合成控制器的训练/搜索证据；QuEra 的四角色循环就是一个原型。
5. Safety Kernel 必须与模型解耦
无论模型、脚本还是 VLA，都只能在 driver/controller 明确允许的 envelope 内动作；安全边界不能由模型自己解释。
6. “AI 控制世界”最终可能是程序生成系统
高 Hz 世界不会等待逐 token 推理。更可扩展的模式可能是：模型不断生成、验证、升级局部控制程序，物理世界主要由这些程序运行。
十、LRI 验证计划：不要只看 Demo，要测控制系统指标
重点不是“Claude 能不能动机械臂”，而是分层架构是否在速度、安全、泛化和运维上成立。
| 实验 | 问题 | 关键指标 | 通过标准方向 |
|---|---|---|---|
| E1 · Direct vs Code Fast Path | 逐步 Agent/MCP 控制与本地代码链差多少？ | P50/P95/P99 latency、jitter、控制频率、网络占比 | 代码 fast path 明显降低尾延迟并稳定频率 |
| E2 · Safety Fuzz | 错误/越界 write 能否被模型之外阻断？ | 违规拦截率、误拦截率、E-stop latency | 危险命令 100% 在硬边界前阻断 |
| E3 · Controller Synthesis | Agent 是否能把探索结果变成更优脚本？ | 成功率、执行时间、试验次数、脚本复杂度 | 盲测脚本优于初始人工/线性 baseline |
| E4 · Failure Recovery | 断线、设备重启、传感器异常怎么办？ | 恢复时间、错误传播、状态一致性 | fail-safe 且可从 trace 重建状态 |
| E5 · Integration Cost | MHS 是否真的降低多厂商接入成本？ | 设备接入人时、driver LOC、重复代码比例 | 新增设备边际成本显著下降 |
| E6 · Sandboxed Fast Path | Python vs 受限 Wasm/DSL 是否更适合生产？ | 启动、RSS、权限粒度、确定性、可移植性 | 在不损失主要性能的情况下明显收窄攻击面 |
最小 PoC：两类设备（传感器 + 执行器）即可验证核心假设：先让 Agent 通过标准接口完成探索式闭环，再要求它生成一个脱离模型运行的控制程序，随后用随机扰动测试 success rate、tail latency、safety violations 和 recovery。
十一、持续跟踪：什么变化会真正改变对 MHS 的判断？
研究预览阶段最重要的是标准细节，而不是更多演示视频。
P0 · 开源规范
正式 spec、reference driver、license、schema、conformance test 是否公开。
P0 · Safety Contract
limits、interlock、lease、E-stop、审批、审计是否成为规范级能力。
P0 · Runtime Semantics
并发、事务、超时、断线、设备重连、版本兼容以及实时能力边界。
P1 · Ecosystem
LeRobot、Raspberry Pi、科研仪器厂商是否形成可互操作 Driver 生态。
升级判断的信号
独立第三方在多品牌硬件上复现；reference driver 大量出现；安全/兼容测试体系成熟；Agent framework 原生支持；真实制造/实验室长期运行。
降级判断的信号
Driver 仍高度定制；物理语义主要靠自然语言且不可验证；安全策略无法组合；高频控制仍需完全绕开 MHS；标准长期不开放或生态碎片化。
🎞️ 十二、MHS 会不会成为具身智能的另一种控制范式？
截至 2026-10-07，证据已从实验室仪器推进到多机器人协同与多控制抽象评测；关键问题正在从“用哪一种控制”转向“如何路由不同动作表示”。
动画读法：先选择 Policy / Program 两种动作表示，再由本地控制器或已部署技能执行；异常摘要经红色路径返回 Agent。设备接口、控制器、固件与安全机制的职责分别保留。本图是 LRI 混合架构推演，不是 MHS 官方完整分层或安全认证声明。
Universal Robots：4 台 cobot 被 Agent 作为一个单元编排
UR 报告 MHS 研究预览中，Agent 能发现、配置并协调四个独立机器人应用完成 payload handoff；设备边界与 interlock 由 MHS 表达，而 UR 自身安全架构仍在底层保持最终控制权。
具身智能自身也在分层：Reasoner / VLA / Fast Controller
Gemini Robotics 2 已把 embodied reasoning 与 VLA motor control 分成协作层；LeRobot 的 Unitree G1 路线由 π0.5 预测 SONIC motion tokens，再由本地高速 whole-body controller 解码为稳定 29-DoF 动作。
不是 Policy vs Program，而是 Action Representation Router
Anthropic 的机器人评测直接比较 torque direct control、controller code、RL policy 与 pretrained policy，且同一模型会因控制抽象不同表现巨大差异。未来 Physical Agent Runtime 更可能把 learned policy、program/state machine、device procedure 与受限 direct command 都视为一等动作表示，由 Reasoner 按任务、时延、不确定性与安全边界路由。
MHS 的抽象已经比 read/write 更丰富
CMU 案例把 job-file、Windows COM 和 GUI-only 三种完全不同控制方式统一成 states + procedures manifest；Agent 在同一接口上完成设备编排、结果判断和自主重跑。这更接近 Physical Agent 的 capability/state plane，而不是单纯 RPC 包装。
控制接口本身就是系统能力的一部分
Anthropic 机器人研究显示，模型直接驱动关节时多数困难任务表现很弱；接入 controller code 或 pretrained policy 后能力明显提高。因此不能脱离 action interface 单独评价“模型会不会机器人”。
Capability Plane 有雏形，Production Contract 仍缺
已有 states/procedures、共享状态、limits/interlocks 和多设备案例，但公开材料仍不足以证明统一 lease/ownership、事务、一致性、版本兼容、断线语义、功能安全认证与完整 conformance suite。现在适合称“强方向信号”，不适合称成熟工业标准。
新的核心架构判断：Reasoner → Action Representation Router → [VLA Policy / Program Skill / Device Procedure / Bounded Direct Command] → Capability & State Plane → Local Controller → Firmware / Safety / Hardware。其中 MHS 最可能占据的是 Capability & State Plane；Router 是我们从现有证据推导出的上层运行时能力，不是 MHS 官方已宣布组件。
Capability Contract：我能做什么？
states、procedures、capability metadata、limits、interlocks、E-stop 等描述设备可观察状态、可执行动作和允许边界。MHS 当前最接近这一层。
Routing Contract：这一步该怎么做？
根据任务连续性、控制频率、环境不确定性、可审计需求和风险，选择 VLA、程序、设备 procedure 或受限 direct command。Anthropic 的机器人评测说明“接口选择”会显著改变同一模型的能力表现。
Safety/Execution Contract：什么绝不能越界？
实时稳定性、firmware 保护、认证安全功能和最终硬件约束必须继续由模型之外的控制栈承担。UR 的表述非常明确：intelligence sits on top，原有 safety architecture 仍保持最终控制。
为什么这三个合同必须拆开：统一设备接口不能自动解决物理推理；会生成程序也不能自动获得实时性；模型能监督 VLA 也不能替代底层 safety。把三者混成“AI 控机器人”会掩盖真正的系统边界。
融合架构：Agent/Reasoner → [Program/Skill Path + VLA/Policy Path] → Fast Controller → Hardware。离散、可解释、可复用的任务逻辑优先程序化；视觉运动、接触与难以符号化的连续控制交给 learned policy；两者共享设备状态、能力描述、安全 envelope、trace 与版本证据。
同一个任务不要求选择唯一范式：纯 VLA 把动作能力主要压入权重，Program 路径把能力显式固化为 Skill，而 Hybrid 把导航、抓取、设备 procedure 等子任务路由到最合适的动作表示。
不能把 MHS 直接称为第二条通用具身路线
MHS 仍是 limited research preview；现有机器人案例证明 orchestration 与受限设备操作，不等于已经证明复杂开放环境中的通用 manipulation、locomotion 或在线程序自进化。
真正要比较的是 Policy Learning vs Program Learning
同一任务分别用 VLA action policy、Agent 生成程序和混合方案实现，比较成功率、样本效率、tail latency、能耗、可解释性、故障恢复、跨设备迁移与安全验证成本。
十三、证据来源与边界
以官方一手材料为主，辅助独立新闻和相邻技术资料；案例数据不外推为通用 Benchmark。
Primary · Anthropic
Previewing the Model Hardware Standard
MHS 定义、Driver/read/write、tags/reference、安全边界、MCP/CLI/code、Janelia/Genentech/QuEra 等完整 partner case。
Primary · ProjectModel Hardware Standard
研究预览状态、项目起源、申请入口，以及未来开源方向。
Independent · ReutersAnthropic unveils framework for physical devices
独立确认 MHS 发布、研究预览、适用硬件范围与科学/制造定位。
Adjacent StandardMCP 2026-07-28 Specification
用于区分 MCP 的 Agent/tool transport 角色与 MHS 的硬件语义/Driver 角色。
Adjacent RuntimeHugging Face LeRobot
对比机器人 policy、硬件接口与 MHS 可能的 agent-facing 硬件标准位置。
证据边界：可以高置信描述 MHS 的公开设计和 Anthropic/partner 案例；可以中等置信推导“慢 Agent + 快程序”的系统架构；不能把 MHS 研究预览视为已具备 hard real-time、工业功能安全或跨厂商成熟互操作性的生产标准。