Anthropic Model Hardware Standard 给实体 AI Agent 划出新的安全边界

Anthropic Model Hardware Standard 让实验设备变成可发现的 Agent 工具。对运营方来说,真正要处理的是路由权限、安全限制和触碰硬件前的审计路径。

发布于 来源 Anthropic

归档条目:由 AI 根据所引信源辅助生成,发布时未经逐篇审阅。责任编辑:Joe Werner。

Anthropic Model Hardware Standard 路由图,AI Agent 通过受审计的硬件驱动连接实验仪器

Anthropic 的 Model Hardware Standard 很容易被看成一条机器人新闻。做 router 的人应该换个角度读。原来会调用搜索工具、写文件的 Agent,现在可以通过一层通用驱动发现显微镜、移液工作站、机械臂、摄像头和量子激光控制系统。模型一旦从文本走到设备动作,路由策略管的就不再只是成本和延迟,也要管物理世界里的权限。

边界从 API 响应移到了设备动作

Anthropic 在 8 月 27 日开放了 Model Hardware Standard 的研究预览。这个规范给可编程设备提供标准化 driver,里面有 read 和 write 这类基本动作,也有机器可读的发现信息、自然语言硬件标签,以及说明设备能测量什么、能调节什么、会强制哪些安全限制的参考文件。Agent 可以通过 MCP、命令行接口或代码文件控制设备。

运营团队要盯住代码文件这条路。在 Anthropic 的激光校准例子里,Claude 先探索硬件回路,通过摄像头观察调整结果,随后把学到的步骤打包成确定性代码,让校准可以用一条命令跑完。对 gateway 来说,这会形成两类请求。交互式推理轮次可以逐 token 监控。把多个 driver 命令串起来的代码文件,执行速度会快过在线审查。它们需要不同的批准、日志和回滚规则。

这次预览只面向研究实验室和先进制造伙伴,Anthropic 也说明 MHS 只适用于带可编程接口的设备。可这已经覆盖了 Agent 出错代价很高的环境,湿实验室、机器人单元、电子产线、显微成像系统和量子硬件都在其中。

它不只是又一个 MCP 工具面

MCP 已经给 Agent 提供了访问软件工具的通用方式。MHS 把同一种模式推进到硬件里。它很有用,同时也打破了多 provider 路由里一个舒服的前提。一次坏调用如果只是多花 token 或返回错误 JSON,fallback 和重试还能消化很多损失。一次坏的硬件命令可能浪费试剂,让机械臂走向碰撞路径,毁掉生物样本,或者让实验系统失稳。

这会改变控制平面必须保存的内容。模型选择只是路由的一部分。路由还要写清设备类别、允许的命令集合、最长运行时间、需要人工批准的阈值,以及 Agent 是否可以生成一个代码文件,在没有下一次模型判断的情况下连续执行多个 write 操作。

跨 provider 的上下文也重要。Anthropic 把 MHS 和 MCP、Claude 示例放在一起,AWS 已经出现在预览支持名单里,会通过 Strands Robots 接入,Hugging Face 也计划在 LeRobot 中支持它。如果 MHS 后续开源,它大概率不会停留在单一模型的小岛上。团队应该预期 Agent harness 会把硬件工具当成普通工具暴露出来。gateway 要回答得很具体,哪些 provider、哪些模型、哪些身份可以访问某个设备命名空间。

路由策略要写设备名,而不只写模型名

实用的策略应该先把观察和动作分开。read 命令暴露状态,可以放得更宽。write 命令会改变现实世界,应该走更窄的路线。第一版生产策略更像一张运维矩阵,而不是模型 allowlist。

  • 摄像头、plate reader、日志和环境传感器的 read 访问,可以交给标准 Agent 模型,同时保留正常审计日志。
  • 修改查询参数、移动虚拟载台这类低风险 write 访问,应该要求已批准的设备 profile 和有边界的取值。
  • 机械臂运动、移液、热循环、激光控制这类高风险 write 访问,应该要求明确批准、签名后的代码产物,以及模型无法绕过的设备侧安全限制。
  • 串联多个设备命令的生成脚本应该按部署处理。执行前保存脚本、模型、prompt、操作者身份和 driver 版本。

迁移路径很具体。MHS 之前,很多实验室是由人类操作者或专门集成程序决定模型建议何时变成设备命令。MHS 之后,Agent harness 可能把设备当作普通工具展示出来。更安全的路线是在 harness 和 MHS driver 之间放一个 gateway 或 policy broker,让请求从直连设备变成带路由元数据的受检调用。

{
  "model": "claude-opus-5",
  "tool": "mhs.write",
  "device": "laser_controller_3",
  "operation": "set_frequency",
  "approval": "required",
  "max_duration_seconds": 30
}

这套思路和模型路由相同,但 fallback 规则要改。硬件操作失败时,不该自动换一个模型重试。重试策略应该属于设备 profile,并且区分网络故障、安全拒绝、物理故障和模型不确定。

TheRouter 用户现在应该关注什么

TheRouter 用户今天不一定要路由实体设备,也能从 MHS 里学到东西。关键教训是 Agent 工具会越来越复杂,gateway 需要携带的上下文会超过 model、messages 和 stream。如果团队已经在路由 coding agent 或 MCP tool call,可以先检查日志能不能回答四个问题。模型提出了什么动作,由谁批准,哪个工具命名空间执行,最后是哪条策略放行或拦截。

对当前 API 流量来说,TheRouter 的稳定起点仍然是通过开发者文档接入 OpenAI-compatible routing,并通过模型目录查看可用模型。对未来的硬件 Agent,真正的观察点是 MHS driver 能不能暴露足够结构化的元数据,让 gateway 在 write 到达设备前执行策略。如果能,硬件操作就可以像高风险工具一样治理。如果不能,MHS 会缩短集成时间,同时把安全责任重新推回各家实验室自己的软件里。

帮助与联系