Anthropic 开放模型硬件标准MHS研究预览让 AI 智能体安全操作物理设备的共享规范如果说过去两年 AI 智能体最热闹的领域是“会写代码、会调用 API”那么接下来真正难啃、也更有价值的战场是让智能体走出沙箱、去操作真实的物理设备控制机械臂、调度产线设备、启停实验仪器、管理智能楼宇中的配电回路。这件事听起来很酷但落地时几乎所有团队都会撞上同一堵墙设备厂商接口不统一、权限模型五花八门、操作缺少审计、出了事故找不到回溯链路。模型能力反而不是最大的瓶颈真正的瓶颈是物理世界不像软件世界有 HTTP 和 REST API 那样一套事实标准AI 智能体拿什么去安全地操作不同厂商、不同协议、不同安全等级的设备Anthropic 近期放出的“开放模型硬件标准MHS研究预览”正是冲着这个方向去的。它试图定义一套让 AI 智能体安全操作物理设备的共享规范。网上关于它的讨论还不多很多信息也还停留在“研究预览”阶段。这篇文章不打算替官方背书而是从技术原理、安全设计、落地路径三个角度拆解这个方向为什么重要、标准可能长什么样、以及做 AI 智能体开发的团队今天应该提前做哪些准备。1. 这篇文章真正要解决的问题先给一个明确判断AI 智能体操作物理设备难点不在“智能”而在“信任”和“互操作”。什么叫信任一个纯软件场景下智能体调用 API 出错最坏结果是数据污染还可以回滚、补偿、删库重跑。但物理设备不一样。你让智能体给机械臂发一个“启动”指令一旦参数错误、权限校验缺失、执行时序出错轻则产品报废重则人员受伤。物理操作天然是不可逆的设备一旦动了没有 CtrlZ。什么叫互操作今天的智能体要控制设备通常要做大量定制开发。比如设备 A 用 Modbus TCP设备 B 用 OPC UA设备 C 只有一个私有的 HTTP 接口。每台设备的“启动”“停止”“查询状态”语义还不一样有的叫start有的叫run有的叫power_on。权限体系更是千差万别有的设备带用户体系有的设备默认不鉴权直接裸奔。审计日志要么没有要么存在设备本地要么格式完全不通用。这些问题叠加在一起导致一个现实智能体接入物理设备的成本比接入 100 个 SaaS API 还要高。这篇文章要解决的就是帮助读者理解MHS 这种“共享规范”到底在什么层面解决问题一个安全的设备操作规范在技术上应该包含哪些核心模块如果你今天就在做智能体设备控制可以参考什么样的架构和落地路径有哪些安全设计是绝对不能省掉的。无论 MHS 最后以什么形态落地这个方向对 AI 智能体开发者、IoT 平台工程师、工业自动化团队都有实际参考价值。2. 为什么智能体操作物理设备需要“共享规范”2.1 从 MCP 说起软件世界已有答案Anthropic 此前发布过 Model Context ProtocolMCP它解决的是 AI 模型与外部数据源、工具之间“怎么连接”的问题。有了 MCP一个智能体可以通过统一协议去访问数据库、调用内部服务、读写文件不需要为每个工具定制一套接入逻辑。MCP 的价值在于把“工具接入”标准化了。AI 应用开发者只需要面向协议编程工具提供方只需要实现协议兼容两边解耦。但 MCP 解决的是软件工具的连接问题。物理设备相比软件工具有几个根本差异设备是物理实体存在状态、故障、磨损、环境参数不能像重启进程一样随意恢复。设备有实时的安全边界比如机械臂的运动范围、电气设备的最大电流、压力容器的压力上限。设备的操作权限往往是分级的普通操作员、维护工程师、系统管理员能做的操作完全不同。设备操作需要和物理流程耦合不是一次请求/响应就能完事可能需要持续监控执行状态。2.2 物理设备场景下的“标准缺口”假设一个智能体要控制一条小型测试产线产线上有传感器、传送带、分拣机械臂三个设备。如果没有共享规范开发流程大概率是这样的为三台设备分别写适配器手动定义每个设备的指令集和参数格式在智能体代码里硬编码每个设备的访问地址和凭证为每个设备单独实现安全检查和日志逻辑一旦加一台新设备重复步骤 1 到 4。这套流程的问题不是不能跑而是不可维护、不可审计、不可推广。每次接入新设备都是重新造轮子而且安全问题高度依赖开发者的个人意识。共享规范要解决的就是这个“标准缺口”定义一套统一的设备接入模型、操作指令模型、权限模型和审计模型让所有设备和所有智能体在同一个框架下对话。2.3 从一个类比理解 MHS 的定位可以把 MHS 类比为“AI 世界的 USB 接口”。USB 的出现让不同品牌的键盘、鼠标、硬盘可以通过统一接口连接电脑不需要为每台外设定制专用接口。MHS 想做的事情类似让不同厂商的物理设备可以通过一套统一、安全的标准被不同类型的 AI 智能体连接和操作。当然这个类比有一个重要区别USB 只管“连接”不管“权限”和“安全操作”。而物理设备的操作风险远高于外设连接所以 MHS 这类标准必须把安全作为一等公民纳入设计而不是事后补丁。3. 解读 MHS 研究预览三个关键词背后的技术含义目前公开渠道能获取的 MHS 细节非常有限它仍处于“研究预览”阶段。以下分析是基于标题关键词、Anthropic 在 MCP 上的技术路径以及行业对物理设备 AI 操作的主流共识所做的技术推断不等于官方规范原文。3.1 关键词一“开放”“开放”意味着这是一套公开标准而不是 Anthropic 私有协议。这一点非常关键。如果 MHS 是 Anthropic 私有的那就只对 Claude 生态有意义但如果它是一套开放规范整个 AI 行业和硬件厂商都可以参与、实现、扩展。从 MCP 的发展路径看Anthropic 更倾向于推动开放标准来构建生态。开放之后开发者可以自主实现客户端、网关或 SDK只要遵循规范即可。对硬件厂商来说开放标准的吸引力在于一次适配可以接入所有遵循 MHS 的 AI 智能体而不是为每个 AI 厂商各写一套适配器。3.2 关键词二“模型硬件标准”这个名字值得仔细咀嚼。“模型硬件标准”不是“硬件标准”也不是“模型标准”而是介于两者之间它是让 AI 模型和硬件设备对接的边界标准。我们可以把标准关注的问题拆成几个层面层面要解决的问题示例设备描述层设备是什么、能做什么、有哪些参数设备能力清单、操作指令集、状态属性操作语义层智能体如何表达“我想做什么”统一的指令格式、参数约束、期望结果安全模型层谁有权限做什么、什么情况下允许做身份认证、角色授权、约束条件、审批流程执行反馈层操作结果如何返回、异常如何处理成功响应、失败原因、状态回调、超时策略如果 MHS 真的在这四个层面定义了规范它就能成为 AI 操作物理设备的“通用语言”。3.3 关键词三“研究预览”“研究预览”这个定位很重要。它暗示这是早期阶段的技术提案不是生产级标准。类似的概念在历史上有很多W3C 的工作草案、IETF 的 RFC 草稿、Linux 基金会下的沙箱项目。研究预览的价值是让社区提前参与讨论尽早暴露问题而不是等完整标准落地后才发现设计缺陷。对开发者来说现在关注研究预览的价值在于在早期阶段就能理解方向提前在自研架构中预留兼容空间。等到标准成熟再跟进反而要重写很多代码。4. AI 智能体操作物理设备的技术参考架构抛开 MHS 的特定实现细节从通用架构角度看AI 智能体安全操作物理设备通常遵循一个分层模型。这个模型也大概率是 MHS 这类规范的基础。4.1 四层架构总览--------------------------- | AI 应用层 | | Agent / 编排 / 决策 | --------------------------- | 标准协议层 | | 统一指令 / 权限模型 | --------------------------- | 设备网关层 | | 连接管理 / 协议转换 | --------------------------- | 物理设备层 | | PLC / 机械臂 / 传感器 | ---------------------------AI 应用层负责任务规划、工具调用、结果分析。这一层通常跑在云服务器或边缘服务器上不直接接触设备。标准协议层这是 MHS 的核心所在。它定义智能体与设备之间的统一交互协议包括指令格式、权限校验规则、审计事件格式。设备网关层承担协议转换功能。因为现场设备往往使用 Modbus、OPC UA、CAN、私有 TCP 协议设备网关负责把这些异构协议转换成标准协议层能理解的格式。物理设备层即真实的硬件设备。它只需与设备网关通信不需要直接理解 AI 智能体。4.2 一个典型的操作流程一次完整的设备操作流程在理想架构中应该是这样的智能体发起操作意图我想把机械臂速度设为 30% 并启动。标准协议层将意图转换成标准操作请求附上 AI 智能体的身份标识。设备网关层校验身份和权限该智能体是否有此设备的操作权限当前时间是否允许此操作权限校验通过后网关将标准指令翻译成设备原生协议下发到物理设备。物理设备执行操作实时上报状态。网关收集执行结果转换成标准响应格式返回给智能体。审计模块记录完整操作链谁、什么时间、通过什么方式、对哪台设备、做了什么、结果如何。这个流程本身并不神秘难的是把每个环节标准化让不同厂商的实现能够互操作。5. 安全设计是 MHS 的核心而不是附加项如果要在所有技术要素中选一个最关键的那就是安全。AI 操作物理设备的安全设计比软件 API 调用复杂得多。下面是几个必须考虑的安全层次。5.1 身份与权限从“能否访问”到“能做什么”软件世界通常通过 API Key 或 OAuth Token 做身份认证权限控制到“接口级别”。但物理设备需要更细粒度同一个智能体可能可以查看设备状态但不能启动设备可以启动一条产线但不能修改设备参数可以执行常规操作但在异常条件下会被自动拦截。一个合理的权限策略模型至少包含三层角色Role智能体或用户扮演的角色。设备范围Device Scope允许操作哪些设备、哪些设备组。操作类型Action允许执行哪些操作比如read_status、start、stop、update_config。下面给出一个参考权限策略配置示例注意这是一个概念演示不是某家厂商的官方格式# 概念示例设备访问权限策略 apiVersion: mhs.acme.dev/v1alpha1 kind: DeviceAccessPolicy metadata: name: factory-line-policy spec: subjects: - agent: agent-scheduler-001 roles: [operator] - agent: agent-maintainer-002 roles: [maintainer] roles: operator: permissions: - device: factory-robot-arm-01 actions: [read_status, start, stop] constraints: timeWindow: 08:00-18:00 maxConcurrency: 1 maintainer: permissions: - device: * actions: [read_status, start, stop, update_firmware] constraints: requiresApproval: [update_firmware]在这个示例里有几个值得强调的设计operator 角色只能操作特定设备而且只能在 8 点到 18 点之间操作同一时间最多一个并发操作。maintainer 角色可以操作所有设备但执行update_firmware这种高风险操作需要审批。权限是配置化的不是硬编码在智能体代码里的这样安全团队可以集中审计和变更。5.2 操作的请求与响应模型智能体向设备网关发起操作时请求里应该携带足够的信息供网关决策和审计。参考请求格式{ protocolVersion: mhs-v0.1-preview, requestId: req_9f2c4a3e, agent: { id: agent-scheduler-001, displayName: 产线调度智能体 }, operation: { deviceId: factory-robot-arm-01, action: start, parameters: { speedPercent: 30, durationSeconds: 60 } }, safety: { requireApproval: false, autoAbortOnError: true, maxExecutionSeconds: 90 } }这个请求里有几个安全细节值得注意requestId每次操作的唯一标识后续审计和排查都靠它。agent.id操作者的身份标识不能在服务端信任前端传值必须由网关从认证上下文注入。safety.maxExecutionSeconds最大执行时间防止操作卡死导致设备长期处于未知状态。safety.autoAbortOnError出错时自动中止避免错误指令持续执行。5.3 高风险操作的双人复审和保险机制在工业场景中高风险操作除了权限校验之外通常还需要“双人复核”或者“二次确认”。AI 智能体操作设备时也应该引入类似机制。一种可行的设计是当操作的风险等级超过阈值时网关自动转入“待审批”状态由人工或指定的安全代理审核确认后才会真正下发到设备。这个机制可以防止以下问题智能体上下文被注入恶意指令模型在长链路任务中产生错误的操作参数配置变更操作在无人值守时出错。这类“安全闸门”不应该依赖模型自律而应该在网关层面强制执行。6. 一个最小可落地的参考实现思路虽然 MHS 还没有完整落地但我们可以基于上述架构思想构建一个最小可用的“设备操作网关”原型。这个原型不需要真实设备可以用模拟设备代替目的是验证流程和权限机制。6.1 定义设备网关的 HTTP 接口假设设备网关提供一个统一接口/v1/devices/{deviceId}/operations智能体通过 POST 请求发起操作openapi: 3.0.3 info: title: MHS Device Gateway Reference API version: 0.1.0 paths: /v1/devices/{deviceId}/operations: post: summary: Execute an operation on a device parameters: - name: deviceId in: path required: true schema: type: string requestBody: required: true content: application/json: schema: $ref: #/components/schemas/OperationRequest responses: 202: description: Operation accepted content: application/json: schema: $ref: #/components/schemas/OperationResponse 403: description: Permission denied 409: description: Device busy or conflict这个接口设计有三个有意为之的选择用202 Accepted而不是200 OK表示操作被接受、正在执行后续通过回调或查询获取最终结果。权限校验失败返回403表示网关层面已经拦截不会到达设备。设备忙返回409这是物理设备场景很重要的一点设备不支持并发操作时必须明确拒绝。6.2 Python 参考客户端下面是一个概念性的 Python 客户端演示智能体如何调用设备网关# 概念示例智能体侧设备操作客户端 import os import requests DEVICE_GATEWAY_URL os.getenv(DEVICE_GATEWAY_URL, https://gateway.example.com) def execute_device_operation(agent_id, device_id, action, parameters, safetyNone): 向设备网关发起一次物理设备操作请求。 注意agent_id 必须由网关从认证上下文读取不能直接信任请求体。 headers { Authorization: fBearer {os.getenv(AGENT_TOKEN)}, Content-Type: application/json, } payload { protocolVersion: mhs-v0.1-preview, requestId: new_request_id(), agent: {id: agent_id}, operation: { deviceId: device_id, action: action, parameters: parameters, }, safety: safety or { autoAbortOnError: True, maxExecutionSeconds: 60, }, } resp requests.post( f{DEVICE_GATEWAY_URL}/v1/devices/{device_id}/operations, headersheaders, jsonpayload, timeout10, ) if resp.status_code 202: return resp.json() # 包含 operationId可用来轮询执行状态 elif resp.status_code 403: raise PermissionError(fPermission denied for operation on {device_id}) elif resp.status_code 409: raise RuntimeError(fDevice {device_id} is busy) else: resp.raise_for_status() def new_request_id(): import uuid return freq_{uuid.uuid4().hex[:12]} if __name__ __main__: result execute_device_operation( agent_idagent-scheduler-001, device_idfactory-robot-arm-01, actionstart, parameters{speedPercent: 30, durationSeconds: 60}, ) print(Operation accepted:, result[operationId])这段代码展示了一个很好的实践客户端只负责构造请求真正的权限校验和风险控制在网关侧完成。客户端代码尽量保持轻量避免把安全逻辑分散到各个智能体实现中。6.3 操作状态轮询与结果验证设备操作是异步的客户端发起操作后需要轮询或等待回调获取最终结果。参考轮询接口# 查询操作执行状态 curl -X GET https://gateway.example.com/v1/operations/{operationId} \ -H Authorization: Bearer ${AGENT_TOKEN}成功响应示例{ operationId: op_8f3b12, deviceId: factory-robot-arm-01, action: start, status: SUCCEEDED, startedAt: 2025-06-01T10:15:30Z, completedAt: 2025-06-01T10:16:25Z, result: { finalSpeedPercent: 30, durationMeasuredSeconds: 55 }, auditLogRef: audit://2025-06/op_8f3b12 }判断成功的关键字段是status而不是 HTTP 状态码。一个操作可能先被接受202执行期间出错最终以FAILED结束。客户端一定要处理这种异步失败场景。7. 常见问题与排查思路在接入智能体操作物理设备的过程中最容易遇到的几类问题我整理成了一张排查表问题现象可能原因排查方式解决方案智能体无法连接到设备网关网络策略限制、网关地址配置错误检查容器/VPC 网络连通性curl 网关健康检查接口调整网络安全组规则确认网关 endpoint 可用操作总是返回 403 权限拒绝智能体未获得设备操作授权或角色配置有误查看审计日志中的授权失败记录检查权限策略配置在权限策略中为该智能体分配正确角色和设备范围操作返回 409 设备忙设备正在执行其他操作或状态机处于异常态查询设备状态接口确认当前状态等待设备空闲后重试或在客户端实现指数退避重试操作超时设备执行时间超过maxExecutionSeconds查询操作详情查看设备原生日志根据实际工艺时间调整安全超时配置检查设备机械/电气异常审计日志缺失网关未正确配置审计输出或日志被误删检查网关日志配置和存储配额启用审计日志持久化配置集中日志采集如 ELK非法操作参数未被拦截网关缺少参数校验规则对比设备参数范围与网关校验规则在网关层增加参数范围约束做到发布前校验几个排错思路值得强调先看审计日志再看智能体日志。设备操作系统里审计日志是判断“发生了什么”的第一依据因为它记录了完整的操作链路。不要把网关报错直接丢给模型去“反思”。很多团队在智能体操作失败后让大模型根据报错信息自行调整参数重试。这在低风险场景可以但在物理设备场景非常危险。建议建立“重试预算”超过阈值必须转人工处理。区分“连接失败”和“权限失败”。连接失败往往提示网络或配置问题权限失败则要检查身份和角色系统。两者修复路径完全不同不要混淆。8. 最佳实践与工程建议8.1 从第一天就设计“安全边界”而不是最后补很多智能体项目一开始只跑通“能控制设备”安全验证全部省略等要上生产才发现权限和审计缺失再补成本极高。建议在项目初期就建立以下安全基线所有设备操作必须经过网关不允许智能体直连设备 IP。所有操作必须有全局唯一的操作 ID。所有操作必须记录审计日志最少保存 90 天。默认拒绝未被显式授权的操作。8.2 设备接入前先做“能力声明”一个设备接入平台时应该先声明自己的能力支持哪些操作、每个操作的参数范围是什么、是否支持并发、是否支持安全停止。设备能力清单是智能体决策和网关校验的基础。参考能力声明格式{ deviceId: factory-robot-arm-01, capabilities: [ { action: start, parameters: { speedPercent: {type: integer, min: 0, max: 100}, durationSeconds: {type: integer, min: 1, max: 3600} }, concurrency: false, requiresApproval: false }, { action: update_firmware, parameters: {}, concurrency: false, requiresApproval: true } ] }有了能力声明智能体在发起操作前就可以检查参数是否合法网关也可以在请求到达时做二次校验。这是一种“防御纵深”不要依赖单层防护。8.3 用“平台工程”思维治理智能体接入如果一个企业要接入大量智能体到物理环境靠每个业务团队各自开发组件一定会失控。参考平台工程思路由中央平台团队维护设备网关和权限策略服务。业务团队只需要关注智能体业务逻辑调用平台提供的标准 API。平台统一管理身份、权限、审计、监控告警。新设备接入遵循一致的生命周期流程能力声明、测试环境验证、灰度上线。8.4 安全测试和生产发布规范在物理设备场景强烈建议建立类似以下的分级发布流程在模拟环境中验证智能体操作流程和权限校验。在测试设备/测试产线中验证真实操作观察设备状态变化。小范围灰度先让智能体操作非关键设备运行一段时间验证稳定性。全面上线前完成应急预案演练网络中断、设备故障、误操作如何处置。每次发布都必须有回滚方案。软件可以回滚物理设备操作同样需要“回滚预案”比如设备停止流程、故障隔离流程。8.5 关于合规和用户授权如果智能体操作的是面向个人用户的物理设备例如智能家居设备、个人办公设备那么用户授权是绕不开的问题。需要明确用户是否明确授权智能体控制该设备授权范围是什么比如只允许在工作时间控制某台设备。用户如何撤销授权操作记录是否对用户透明可查这些不仅是产品设计问题也可能涉及法规合规要求。建议在标准协议中预留授权生命周期管理的接口而不是每次操作都临时获取授权。9. 总结与后续学习方向MHS 研究预览透露出的方向是清晰的AI 智能体从软件世界走向物理世界需要一套统一、安全、开放的设备操作规范。这套规范的价值不在“新”而在“标准化”和“安全化”——把设备接入、操作、权限、审计这些散落在各家厂商私有协议里的能力收敛成一套可比拟 USB 之于外设的标准协议。对于开发者有几个现实建议先掌握 AI 智能体操作物理设备的通用架构特别是“AI 应用层 / 标准协议层 / 设备网关层 / 物理设备层”的分层思想。这套架构大概率不会因为 MHS 最终形态变化而失效。把安全设计内建到系统里不要幻想模型能自己判断哪些操作危险。权限、审批、审计必须由平台层强制执行。关注开放标准而不是绑定单一厂商。无论 MHS 还是其他协议开放标准更值得投入因为它能降低长期集成成本。MHS 目前仍处于研究预览阶段距离完善的规范还有很长的路。但趋势已经明确AI 智能体的下一步是从控制 API 到控制设备从数字世界走向物理世界。对这个方向保持关注提前在自研架构中预留标准化和安全化的空间是当下最值得做的准备。