最近 Anthropic 又推出了一个值得关注的概念：MHS（Model Hardware Standard） 。
如果说 MCP 解决的是：
AI Agent 怎么调用软件、API 和数据？
那么 MHS 想解决的是：
AI Agent 怎么发现、理解并操作真实世界的硬件？
例如机器人、显微镜、液体处理设备、摄像头、实验室仪器等。
Anthropic 于 2026 年 8 月 27 日开放了 MHS 的研究预览，目前主要面向科研实验室和先进制造场景。
一、为什么需要 MHS？
现在的硬件世界其实非常碎片化。
一台显微镜可能有自己的 SDK：
Microscope SDK一个机械臂可能提供：
Robot API另一个实验设备可能只能通过：
arduino
CLI / Serial / TCP / Vendor SDK如果我们想让一个 AI Agent 同时控制这些设备，就需要大量的胶水代码。
以前可能是：
AI Agent
↓
Microscope SDK
AI Agent
↓
Robot SDK
AI Agent
↓
Liquid Handler API
AI Agent
↓
Camera API每接入一个设备，就需要重新开发一套适配逻辑。
MHS 想做的事情，就是把这些设备统一到一个标准化接口下面。
二、MHS 可以理解成"硬件版 MCP"
可以用一个非常简单的方式理解：
markdown
AI Agent
│
MCP
│
┌─────────┴─────────┐
│ │
软件工具 MHS
│
┌───────┼───────┐
↓ ↓ ↓
机械臂 显微镜 实验设备MCP 更偏向：
Agent → SoftwareMHS 更偏向：
Agent → Hardware所以很多人会把 MHS 简单理解成：
MCP for Hardware
不过严格来说，两者不是竞争关系，而是可以组合使用的两个层次。
三、MHS 最核心的东西：Driver
MHS 的核心概念之一就是 MHS Driver。
可以把 Driver 理解成：
AI Agent
↓
MHS Driver
↓
具体硬件Driver 把设备厂商自己的 API、SDK 等复杂细节隐藏起来，对外暴露统一的设备能力。
例如一个温控设备可能有：
arduino
read temperature
write temperatureAgent 不需要知道厂商内部到底使用什么协议。
它只需要知道：
读取当前温度
设置目标温度这就是标准化接口的价值。
Anthropic 对 MHS 的描述中，也强调了类似 read、write 这样的基础操作，以及设备状态、能力和相关描述信息。
四、MHS 不只是"API 统一"
真正有意思的地方，其实是：
硬件不是普通的软件 API。
如果 AI 调用：
scss
get_user()调用错了，最多返回错误。
但如果 AI 调用：
scss
move_robot_arm()参数错误可能意味着：
撞击设备
损坏实验器材
伤害人员所以 MHS 必须考虑：
设备状态
参数范围
物理限制
安全边界
权限
异常处理例如：
ini
temperature = 20°C正常。
但是：
ini
temperature = 5000°C就不能简单地交给模型执行。
因此一个重要思想是：
安全约束应该尽可能放在硬件控制层，而不是只依赖 Prompt。
这也是 MHS 与普通 Tool Calling 很大的区别。
五、MHS + MCP
如果把整个 AI Agent 系统放在一起看，会更加清楚：
markdown
AI Model
│
↓
AI Agent
│
┌────┴────┐
↓ ↓
MCP MHS
│ │
↓ ↓
软件工具 硬件设备
│
┌──────┼──────┐
↓ ↓ ↓
Robot Camera MicroscopeMCP 负责：
Agent 如何访问工具MHS 负责：
硬件如何被标准化描述和控制两者结合之后，Agent 就可以从：
调用 API进一步走向：
markdown
调用 API
↓
获取设备状态
↓
制定操作计划
↓
控制设备
↓
观察结果
↓
继续决策这就开始接近真正的 Physical Agent（物理智能体） 。
六、一个简单例子
假设实验室里面有：
显微镜
机械臂
液体处理器
摄像头传统自动化可能需要：
Python
↓
显微镜 SDK
↓
机械臂 SDK
↓
液体处理器 SDK
↓
摄像头 SDK开发者需要自己编排整个流程。
而未来的 Agent 可以理解成：
用户：
观察这个样本，
拍摄图片，
然后根据结果决定是否进行下一步实验。Agent：
markdown
1. 查询显微镜状态
2. 调整显微镜参数
3. 获取图像
4. 分析图像
5. 控制机械臂
6. 控制液体处理器
7. 获取新的实验结果
8. 决定下一步操作这时候 AI 不再只是：
Chatbot而开始变成：
markdown
Reasoning
↓
Planning
↓
Tool Calling
↓
Hardware Control
↓
Observe
↓
Reasoning这才是 MHS 真正值得关注的地方。
七、MHS 对 Agent 开发者意味着什么？
过去我们开发 Agent，重点通常是：
LLM
↓
Prompt
↓
RAG
↓
Tools
↓
MCP未来可能进一步变成：
sql
LLM
↓
Agent
↓
MCP
↓
MHS
↓
Hardware
↓
Real World也就是说：
Agent 的边界正在从数字世界向物理世界扩展。
这和机器人、自动驾驶、智能制造、实验室自动化等方向都有关系。
八、MHS 目前还处于什么阶段？
这里需要注意一个重要事实：
MHS 目前还是研究预览，而不是一个已经成熟、广泛可用的开源标准。
Anthropic 当前邀请科研和工业合作伙伴参与测试，并计划在进一步完善安全评估和最佳实践之后开放源码。
所以现在更适合把 MHS 当成：
一个值得研究的 Agent × Hardware 架构方向而不是：
马上用于生产环境的成熟基础设施九、作为开发者应该关注什么？
如果你已经在学习：
AI Agent
MCP
Tool Calling
Workflow
Multi-Agent那么 MHS 可以作为一个很自然的下一步：
markdown
Software Agent
↓
MCP
↓
Physical Agent
↓
MHS
↓
Real World尤其值得关注三个问题：
1. Agent 如何理解硬件？
不仅要知道：
这个设备有什么 API？还要知道：
这个设备能做什么？
限制是什么？
当前是什么状态？2. Agent 如何安全控制硬件？
不能只依赖：
Prompt：
"请不要把温度设置得太高。"而应该在 Driver / Control Layer 中真正限制：
min_temperature
max_temperature
allowed_operations
permission
emergency_stop3. Agent 如何处理实时状态？
软件 Agent 更多是：
vbscript
Request → Response物理 Agent 则更像：
Observe
↓
Think
↓
Act
↓
Observe
↓
Think
↓
Act这会让 Agent 架构从传统的 Tool Calling，逐渐走向真正的闭环控制。
总结
MHS（Model Hardware Standard）可以看成 AI Agent 连接物理世界的一层标准化基础设施。
MCP 让 Agent 更容易调用软件工具，而 MHS 进一步尝试让 Agent 用统一方式发现、理解和操作真实硬件。
它真正有意思的地方，不是"又出现了一个协议"，而是：
AI Agent 正在从操作软件，逐渐走向操作现实世界。
这可能会成为未来 Agent、机器人、智能制造和自动化实验室之间的重要连接层。