Anthroic 發布的 MHS（Model Hardware Standard，模型硬體標準）

WrightWu

— 5 min read
Anthroic 發布的 MHS（Model Hardware Standard，模型硬體標準）
Photo by Jainath Ponnala / Unsplash

從 Gateway 領域的角度來理解，MCP（Model Context Protocol） 解決了「AI 連接雲端 API、資料庫與軟體工具」的標準化；而 MHS 就是「實體設備與硬體領域的 MCP」，專門用來讓 AI Agent（如 Claude）能直接辨識、監控並安全操作實體可程式化設備（如機械手臂、顯微鏡、移液機器人、量測儀器等）。

MHS 根本解決了什麼問題？

在傳統 OT、工業自動化或實驗室自動化中，最大的痛點是硬體協議極度碎片化：

  1. 整合成本高昂：每新增一台設備，就得為該設備的私有 API / SDK、Modbus、CAN bus 或專用串口通訊撰寫適配層（Adaptor），整合動輒耗時數週至數月。
  2. AI 無法「語意化」理解硬體能力：傳統 SDK 只提供函式名稱，AI 不知道這台設備的實體物理極限（例如：最高轉速、最大承載重量、安全運轉溫度範圍）。
MHS 解決的核心問題：

消弭 AI Agent 與各種實體硬體驅動之間的驅動牆，提供統一的抽象層，讓 AI 能以「自然語言 + 標準原語」直接調度物理設備。

MHS 的架構與運作方式 (How it works)

對於具備 Gateway 背景的人來說，MHS 的架構非常直覺，主要由三個關鍵機制組成：

核心元件 / 機制概念說明與 Gateway 的類比
MHS Driver相當於 Gateway 內部的 Protocol Driver / Adaptor Layer。將底層各種私有 SDK/API 封裝成統一原語（如 read 讀取狀態、write 變更參數），讓上層 AI 不需要關心設備傳輸細節。
Device Discovery相當於 Gateway 的 mDNS / UPnP 自動發掘與 Profile 報到機制。設備連接後會主動宣告自我能力（如：我是幾軸機械手臂、支援哪些量測功能），AI 一連上就能取得設備清單與可行動作。
Semantic Metadata在 Driver 中嵌入自然語言標籤（描述物理邊界、安全條件、量測範圍）。AI 讀取後就能自動理解「這台設備不能超過多少轉速」、「操作時的危險限制」等安全邊界。

一圖解析：傳統整合 vs. MHS 架構

【傳統方式】 AI Agent / 軟體 ──(專用 SDK A)──> 機械手臂
                          ──(專用 SDK B)──> 顯微鏡
                          ──(專用 API C)──> 溫控儀器
（每一條線都要客製化寫程式，開發週期長）

【MHS 標準】 AI Agent (Claude)
                 │ (統一 MHS Protocol / 類似 MCP 語意化介面)
                 ▼
          [ MHS Driver Layer ]
          ├── MHS Driver A  ──> 機械手臂
          ├── MHS Driver B  ──> 顯微鏡
          └── MHS Driver C  ──> 溫控儀器

目前 Anthropic 剛發布的 Model Hardware Standard (MHS) 確實處於 Research Preview（研究預覽） 階段，採取的是「邀請制／申請審核」。官方與業界透露未來開源（Open Source）的歸納資訊如下：

1. 開放時程與策略 (Open Source Plans)

  • 時間軸：Anthropic 官方表示 「Open Source Timing and Scope will follow」（開源的具體時程與範圍會在後續公開）。目前先由合作夥伴（如 AWS、Doosan Robotics、Universal Robots、Raspberry Pi 等）進行封閉測試與規格驗證。
  • 複製 MCP 模式：從 Strategy 來看，Anthropic 很可能會走之前 MCP (Model Context Protocol) 的路線——先透過 Research Preview 建立早期生態系，收齊工業界與實驗室反饋後，再正式釋出 GitHub 儲存庫並開源 Specification 與 SDK。

2. 未來預計會「開放」的核心項目 (What will likely be Open)

當 MHS 開源時，依據目前發布架構，開放的內容預計會包含以下層級：

開放範疇預計 Open Source 的內容與價值
MHS Specification (標準規範)協議文本與 Schema 格式。定義 MHS Manifest JSON/YAML 格式（宣告設備能力、物理邊界、安全極限）與 Device Discovery 協議。
Core MHS Driver SDK (驅動開發套件)多語言底層框架（如 Python / Rust SDK）。讓硬體廠商或 Gateway 開發者可以基於 SDK 自行撰寫各種設備的 MHS Driver，免去自行從零定義原語。
Reference Drivers (參考驅動與範例)官方預計會開源幾款標準設備（如通用機械手臂、量測儀器、Serial/Modbus 轉 MHS 範例）的原始碼，作為生態系的範本。
Agent / MCP Bridge (AI 銜接層)將 MHS 原語轉譯為 AI 能夠讀取的 MCP Tool / CLI 工具鏈原始碼。

總結 (Key Takeaways)

  1. 定位：MHS 是硬體領域的通用抽象介面，目標是讓 AI 能夠「跨廠牌、即插即用」地操控實體設備。
  2. 與 Gateway 的關係：未來 MHS Driver 可以直接運行在 Edge Gateway 上，Gateway 向上對 AI Agent 暴露 MHS 介面，向下轉譯成 Modbus/CAN/EtherCAT/RS485 等實體現場總線。
  3. 商業價值：將硬體系統整合（SI）開發週期從「數月」縮短至「幾天」，大幅降低 AI 進入工業、醫藥與自動化實驗室的落地門檻。
  4. 現階段（Closed Preview）：Anthropic 正在收集特定領域（Lab & Industrial Automation）的實體限制資料，藉此微調 Claude 在實體控制上的 Prompting 與 Safety Policy。
  5. 團隊現在能做什麼：雖然 2026/8 當下原始碼尚未公開，但 MHS 的核心理念（Device Manifest + Standard Read/Write Primitives + Semantic Metadata）架構已經確定。Gateway 團隊現在就可以將內部設備的 Data Model 抽象化，預先定義好設備的物理極限與語意屬性，未來等 MHS 開源時就能無縫接軌。

Read more