要理解 MHS 的工程意义,需要先理解 MCP 的设计假设。MCP 在 2024 年底首次提出时,核心目标是标准化"LLM 调用外部工具"这件事——之前每个 LLM 框架(AutoGPT、LangChain、CrewAI 等)都有自己的工具调用协议,跨框架不兼容,MCP 试图把这层协议统一。 MCP 协议默认的客户端假设是"软件服务":server 进程常驻、有充足内存与计算资源、支持现代 TLS(Transport Layer Security, 传输层安全)与 JSON-RPC 调用、能做完整的协议握手与加密协商。这套假设对于数据库、REST API、SaaS、文件系统都没问题,因为这些服务通常跑在 Linux/Windows/macOS 服务器上,内存与算力充裕。 但物理世界的主力设备是 MCU(Microcontroller Unit, 微控制器单元)。一个普通的 ESP32(常见的工业级 MCU)只有 520 KB RAM、4 MB flash,根本跑不动完整的 MCP server;更小尺寸的 Cortex-M0+ 系列只有 8-32 KB RAM,完全不在 MCP 的设计目标内。即使是 74 KB 内存的边缘网关版本 IoT-MCP,也只能覆盖中高端 MCU,而 90% 以上的工业 MCU 都比这更小。 更严重的是安全假设。MCP 默认假设 server 端是"可信任的代码运行环境"——调用方不需要验证 server 的能力边界,因为 server 是企业自己部署的。但当 MCP 触达物理硬件时,server 端代码可能运行在一个 8-bit MCU 上,根本没有完整的沙箱机制;一旦 LLM agent 发出错误的指令(比如幻觉或被 prompt injection),这些指令会直接传到硬件驱动层,产生真实的物理影响。 把这两个问题合起来:MCP 在协议设计上没有为硬件层留位置,在安全模型上没有为物理影响做防护。MHS 的工程意义正是同时解决这两个问题。

二、DCP 给出的轻量协议层

Yang 的 DCP(Device Context Protocol)工作在三个维度上同时回应了 MCP 触达硬件层的工程难题。

第一是协议尺寸。DCP 的典型帧只有 50 字节以下——6 字节头部 + CBOR(Concise Binary Object Representation, 简洁二进制对象表示)payload + 可选 16 字节 HMAC(Hash-based Message Authentication Code, 基于哈希的消息认证码)。这个尺寸让 DCP 能跑在 27.6 KB flash / 0.6 KB RAM 的 ESP32 上,也能进一步压缩到更小的 MCU。尺寸的压缩不是简单删字段,而是把 MCP 协议里"用于企业 SaaS 集成"的复杂字段全部去掉,只保留"硬件动作调用"必需的最小集合。

第二是协议层安全原语。DCP 把 capability scoping(能力范围限制)、range and type checks(范围与类型检查)、dry-run evaluation(试运行评估)、units-as-types(单位作为类型)作为协议层的原语,而不是由 server 端代码自己实现。这些原语意味着任何"不符合规则的调用"在协议层就被拒绝,根本不会传到硬件。

第三是 host-side Bridge(主机端桥接)。Bridge 是 DCP 架构里专门设计的"过滤层"——它跑在硬件与 LLM agent 之间,负责把 agent 的工具调用翻译成 DCP 帧、在翻译前做完整的安全校验、在校验通过后再下发到设备。Bridge 把"安全校验"的责任从 MCU 上移到算力更充足的主机端,既保证了 MCU 的资源效率,又保证了安全校验的完整性。

Yang 的实验数据很有说服力:对 675 次 LLM 工具调用(覆盖 DeepSeek、Alibaba、Zhipu、MiniMax 四家厂商的五个模型)在六类对抗性提示下的行为测试,DCP 拒绝了 100% 的能力升级尝试与 78% 的提示词注入尝试,而 Raw MCP 与 IoT-MCP 的对应数字只有 0-1%。三个数量级的差距,正是 MHS 标准需要从 DCP 这类工作中吸收的工程经验。

三、Hardware Keystores 给出的零信任栈

Sambrook 与 Sovio 的工作从凭据安全角度回应了另一个核心问题:agent 操控硬件需要密钥(签名、认证、加密),这些密钥放在哪里?

传统做法是把私钥放在软件可访问的位置:明文文件、环境变量、容器内存。任何有读取权限的进程都可以提取原始密钥材料。Sambrook 与 Sovio 在文章里引用了一起真实事件:某个广泛部署的框架在不到 5 分钟内被邮件注入外泄了私钥。这个数字与前面 Google 关于"AI agent 在 6 小时内窃取凭证"的研究遥相呼应——都是 agent 时代攻击速度的量化案例。

Hardware Keystores 的解法是用硬件隔离的密钥存储取代软件密钥。HSM(Hardware Security Module, 硬件安全模块)、TPM(Trusted Platform Module, 可信平台模块)、智能卡这些硬件设备在设备本身上执行密码学操作,主机只通过不透明句柄(opaque handle)接收结果。即使主机上的 agent 被 prompt injection 攻击,攻击者也只能看到句柄,看不到原始密钥。

但硬件密钥本身不足以解决全部问题。Sambrook 与 Sovio 在硬件隔离的基础上,又设计了一个五层零信任强制栈:

  • 第一层是 session identity(SAGA),给每一次 agent 会话发放独立的临时身份,而不是长期复用一个全局身份。第二层是 scope bounds(Smax),给每个会话设定明确的能力范围,超出范围的动作在协议层被拒绝。第三层是 semantic validation(RAV),对 agent 的动作意图做语义级校验,确保"请求做的事"与"被授权做的事"在语义上一致。第四层是 taint tracking(污染追踪),对从用户输入流入的数据做污染标记,被污染的数据不能直接用于高权限操作。第五层是 hardware execution boundary(硬件执行边界),所有高权限密码学操作只能在硬件设备内部完成。

这五层合在一起,在 12 类基于 AgentDojo 重要指令攻击模板的注入场景测试里,把 ASR 从基线模式的 19.3% 压低到受保护模式的 0%(95% 置信区间上限 2.0%)。同时,在四个良性任务场景里保持零误报——不会因为加了保护层就误拦正常操作。

四、MHS 与 DCP / Hardware Keystores 的关系

把 MHS 与两篇学术工作放在一起看,可以提炼出 MHS 标准设计需要回答的几个核心问题:

  • 第一个问题是硬件抽象的协议尺寸。MHS 必须像 DCP 一样,在协议层就把"硬件交互所需的字段"减到最小,把 MCP 默认里那些 SaaS 集成相关的复杂字段(认证协商、能力发现、状态推送等)剥离出去,只保留硬件控制必需的子集。
  • 第二个问题是协议层安全原语。MHS 必须像 DCP 一样,把 capability scoping、range and type checks、dry-run evaluation 作为协议层原语,而不是由各厂商自行实现。这条原语要求 MHS 提供严格的 manifest schema(清单格式定义),让任何不符合清单的调用在协议层就被拒绝。
  • 第三个问题是主机端桥接层。MHS 必须像 DCP 一样,定义明确的 Bridge 层,把所有 LLM agent 工具调用先经过 Bridge 过滤,再下发到硬件。Bridge 是 MHS 安全模型的核心组件。
  • 第四个问题是凭据的硬件化存储。MHS 必须像 Hardware Keystores 工作里强调的那样,把所有硬件设备身份认证、固件签名、操作日志签名所用的私钥放在 HSM/TPM/智能卡里,而不是软件可访问的位置。
  • 第五个问题是零信任五层强制栈。MHS 必须把 session identity、scope bounds、semantic validation、taint tracking、hardware boundary 五层组合在一起作为强制要求,任何 MHS 实现都不能跳过其中任一层。

把这五个问题的答案合起来,MHS 标准的完整形态就有了:它是 DCP 这类轻量协议的标准化 + Hardware Keystores 这类凭据安全方案的标准化,再加上 MCP 原本的语义层。Anthropic 把这套标准化称为"Model Hardware Standard",正好对应了"Model Context Protocol for hardware"这层语义。

五、企业 IT 应该怎么看待 MHS

把 MHS 放到企业 IT 的视角里,有几个具体的工程含义。

  • 第一个含义是 MCP 选型要开始考虑硬件集成维度。之前企业评估 MCP server 时,关注的是它支持哪些软件工具(数据库、API、SaaS);在 MHS 时代,还需要关注它支持哪些硬件设备、硬件调用的安全模型是什么、是否符合五层零信任强制栈。
  • 第二个含义是 agent 部署的安全审查需要扩展到硬件层。之前 agent 的安全审查关注的是工具调用权限、数据访问范围、网络出站规则;在 MHS 时代,还需要审查 agent 对硬件设备的控制权限、固件签名验证、操作日志签名、物理影响半径。
  • 第三个含义是 SIEM 与 SOAR 集成需要扩展到硬件事件。MHS 标准下的硬件操作会生成新的事件流——固件更新、配置变更、命令执行、状态异常——这些事件需要接入企业的 SIEM(Security Information and Event Management, 安全信息与事件管理)与 SOAR(Security Orchestration, Automation and Response, 安全编排自动化与响应)平台,纳入统一的安全运营视图。
  • 第四个含义是供应商评估需要考虑硬件供应链。MHS 把硬件供应商纳入了 MCP 生态——硬件驱动、固件、安全模块的供应链成熟度直接影响 MCP 部署的安全性。企业 IT 在评估 MHS 供应商时,需要把硬件供应链评估纳入整体供应商评估流程。
  • 第五个含义是合规审计需要扩展到物理影响评估。当 MCP 触达硬件层之后,一次错误的工具调用可能产生物理影响(机械臂误动作、医疗设备参数错误、工业 PLC 错误控制)。监管机构在评估 MCP 部署时,会要求企业提供"物理影响评估"——哪些动作可能产生物理影响、影响半径多大、应急停止机制是什么、谁有权触发应急停止。

六、MHS 是企业 AI 进入物理世界的入场券

把 MHS 放到更大的视野里看,它是企业 AI 从"屏幕内"走向"屏幕外"的关键基础设施。在 MHS 出现之前,企业 AI 的真实价值受限于"只能在数字世界做工作";在 MHS 出现之后,企业 AI 才能真正操控物理世界,产生真实世界的影响。

这个转变的工程门槛非常高。数字世界的错误可以通过回滚修复,物理世界的错误可能产生不可逆后果。数字世界的安全边界由软件定义,物理世界的安全边界由硬件与物理约束共同定义。数字世界的合规要求集中在数据层面,物理世界的合规要求延伸到安全、生命、环境保护层面。

MHS 作为一项"标准",真正的意义不在标准本身,而在它给整个生态——MCP 厂商、硬件厂商、LLM 厂商、企业 IT、监管机构——提供了一个共同讨论安全边界的语言。当这个共同语言建立起来之后,MCP 触达物理世界的工程门槛才能真正降低,企业 AI 才能从演示场景走到生产场景,从文档处理走到生产线控制。

Anthropic 选择"开放预览"而不是直接发布正式版,正是为了给整个生态足够的时间消化这套标准。学术界在 2026 年 5-8 月间集中发表的 DCP 与 Hardware Keystores 两类工作,正好填补了 MHS 在协议层与凭据层的技术空白。可以预期的是,未来 6-12 个月里会有更多工作进入这个领域,推动 MHS 从"开放预览"走向"正式发布"。

这件事的最终受益者是企业——只有当硬件驱动的接入有了统一的安全标准,AI 智能体才能真正进入生产车间的控制柜、医疗设备的参数面板、办公楼的智能门禁。企业 AI 的下一个十年,会从 MHS 这类基础设施开始。