【2026 最新】Model Hardware Standard（MHS）是什麼？用 Mock Device 搞懂「硬體版 MCP」與安全閘門

Model Hardware Standard（MHS） 是 Anthropic 在 2026 年 8 月公開的研究預覽：它以共同的 Driver、設備描述與 read／write primitives，讓上層 AI Agent 透過一致邊界操作異質設備，降低反覆撰寫跨設備 glue code 的工作；每種設備仍需相應 Driver。你可以先把它粗略類比成「硬體版 MCP」；Anthropic 公告中的正式定位則是讓 AI Agent 安全操作實體設備的 shared specification，而 MCP 只是控制／存取機制之一。

這篇文章先用白話拆解 MHS，再做一個明確不是 MHS Driver、也不是相容性測試的 Python Mock Device（Mock 溫控器）。你會親手驗證越界寫入、過期讀值、斷線、重複命令與急停狀態是否被安全閘門擋下，並看懂為什麼「API 呼叫成功」和「物理世界安全」是兩回事。

先說結論：Model Hardware Standard（MHS）解決哪一層？

把一個硬體 Agent 想成實驗室裡的四個角色：

• Agent 像研究助理：理解「把溫度調到 30°C」這個目標，決定下一步。
• MHS 像共同語言與轉接頭：告訴助理有哪些設備、能讀什麼、能寫什麼，以及設備怎麼接受命令。
• 確定性控制器 像熟練技師：負責毫秒級、可預測的控制迴路，不等待模型逐步思考。
• 安全閘門（Safety Gate） 像保險絲與安全門：在危險命令真正碰到 actuator（加熱、移動等執行元件）前，獨立檢查界限、狀態與授權。

最小心智模型：硬體 Agent ＝ Agent（決策）＋ MHS（翻譯）＋確定性控制（執行）＋ Safety Gate（最後煞車）。

後兩層的分工尤其重要。MHS 官方資料提到 Driver 的參考文件可描述安全限制；對長時間或快於模型線上推理的操作，Agent 也可把 Driver 命令串進 code files，避免每一步都等待模型。但截至本文查核日，官方公開資料不足以證明 MHS 已提供 safety-rated 急停、硬即時保證或完整的功能安全認證。因此，本文的 Safety Gate 是一般工程實務的教學模型，不是 MHS 已公布的強制規格。

MHS 是什麼？先看它現在的真實狀態

依 Anthropic 在 2026 年 8 月 27 日發布的研究預覽，MHS 是一項源於 Anthropic 與 HHMI Janelia 合作的 shared specification，先開放給部分實驗室與製造商申請。官方的一般說明把範圍放在具備 programmable interface 的設備；同頁另有 GUI 自動化案例，兩者的正式邊界尚待公開材料釐清。

關鍵字是研究預覽。截至 2026 年 8 月 31 日，Anthropic 明文表示 MHS 尚未開源；在本文查核的官方公告與 MHS 官方入口中，未找到可供公開實作的完整 specification、公開 SDK、Driver code 或 conformance test 連結。官方表示會先和早期夥伴建立安全評估與最佳實務，再走向開源。因此，現在可以教公開概念與安全邊界，不能把本文 Mock 冒充真正的 MHS Driver。

MHS 也不是世界上第一個硬體互通方案。實驗室與工業領域早已有 OPC UA LADS、SiLA 2、OPC UA、ROS 與各種 fieldbus。MHS 想補的缺口更窄：用面向 AI Agent 的共同 Driver 與自然語言描述，降低上層串接異質設備時的客製工作。它能否與既有堆疊穩定共存，仍要看後續公開規格與更多獨立驗證。

Model Hardware Standard（MHS）與 MCP 有什麼不同？

如果你讀過 AlphaLab 的 MCP 基礎設施解析，可以把 MCP 理解成 Agent 應用程式與外部工具／資料之間的通用溝通協定；它會列出工具，讓模型發出 tool call。MHS 則更靠近設備：它處理設備 discovery、Driver，以及透過 tags 與 reference file 描述設備特性、可量測／調整項目與安全限制。

• MCP 問：Agent 要如何列出並呼叫一個工具？
• MHS 問：不同設備要如何用一致的 Driver 與描述，讓上層知道能讀寫什麼？
• 兩者交會：MHS 官方把 MCP 列為存取設備的三條路之一；另外兩條是 CLI，以及 code／API。

所以「硬體版 MCP」適合當第一分鐘的比喻，卻不適合當技術定義。MHS 可以透過 MCP 暴露給 Agent，也可以直接從命令列或程式碼呼叫；MCP 不是 MHS 唯一的控制／存取機制，MHS 也不只是替設備包一層 MCP Server。

MHS 公開概念的六個零件

1. Device discovery：先知道有哪些設備

Agent 不能只收到一串 IP 或序號。官方說明中的設備會以標準格式變得 discoverable，讓設備與 Agent 能在網路上互相找到並通訊；UW 與 Tetsuwan 案例另示範讀取設備狀態、查找相容設備與學習 Driver interface。截至 2026 年 8 月 31 日，本文查核的 Anthropic 公告與 MHS 官方入口未列出 discovery schema、registry 或 availability 的正式語義。

2. Driver：把廠商差異翻成共同介面

每台設備背後仍可能使用不同 SDK、COM、檔案監看、GUI 或 API。MHS Driver 扮演轉譯層，把上層的共同操作轉成特定設備能理解的指令。它不會神奇地消除底層差異，而是把差異收進一致邊界。

3. read／write：讀狀態與改變狀態

read 可以是取得目前溫度，write 可以是設定目標溫度。軟體工具的失敗常只是回傳錯誤；硬體的 write 卻可能加熱、移動、加壓或開啟雷射。這就是為什麼本文把所有危險思考集中在 write path，而不是只看 API 是否連得上。

4. Tags 與 reference file：把參數意思說清楚

官方描述中，設備可以用自然語言 tags 說明特性，並生成參考文件，讓 Agent 知道可量測與可調整項目，以及會執行的安全限制。這有助於模型理解工具，但自然語言描述不是物理保證；單位、座標、變化率、有效狀態與硬限制仍應由確定性程式驗證。

5. MCP／CLI／code：三條控制路徑

互動探索時，Agent 可以經 MCP 呼叫；工程師也可從 CLI 操作，或在程式與 API 中組合命令。這種分層很實用：同一個 Driver 不必綁死在某個聊天介面或特定模型。

6. 確定性程式：快速迴圈不要每一步都問模型

Anthropic 指出，對長時間或快於模型線上推理的操作，Agent 可把 Driver 命令串進 code files，讓設備不必逐步等待模型推理；官方雷射案例則把學到的流程寫成 deterministic script。這不等於 MHS 已有 hard real-time 的 latency／jitter（延遲與波動）保證；工程上，毫秒級控制仍應留在 PLC（可程式邏輯控制器）、韌體或其他可驗證控制器。

動手做：建立一個「非 MHS」Mock Device（Mock 溫控器）

由於官方公開入口目前未提供足以自行實作並判定 MHS 相容性的材料，本文改做一個概念 Mock。它不模擬任何廠牌，也不聲稱欄位符合 MHS；用途只有一個：驗證一條物理 write 在送出前，能否經過明確的停止條件。

環境只需要 Python 3，不需安裝套件。建立空資料夾，將下面程式存成 mock_device.py：

#!/usr/bin/env python3
"""Concept lab only: this is NOT an MHS driver or conformance test."""

import json
import time
from pathlib import Path

TRACE = Path("mock-trace.jsonl")
STATE = {
    "target_c": 22.0,
    "sampled_at": time.time(),
    "network_ok": True,
    "emergency_stop": False,
}
RESULTS = {}


def record(command, result):
    with TRACE.open("a", encoding="utf-8") as f:  # append mode, not tamper-resistant
        f.write(json.dumps({
            "recorded_at": time.time(),
            "command": command,
            "result": result,
        }) + "\n")


def write_target(command_id, target_c, *, dry_run=True, approved_by=None):
    command = {
        "id": command_id,
        "target_c": target_c,
        "dry_run": dry_run,
        "approved_by": approved_by,
    }

    if command_id in RESULTS:  # retry must not execute twice
        previous = RESULTS[command_id]
        if previous["command"] != command:
            conflict = {
                "status": "blocked",
                "reason": "command_id_payload_conflict",
            }
            record(command, conflict)
            return {**conflict, "deduplicated": False}
        duplicate_result = {**previous["result"], "deduplicated": True}
        record(command, duplicate_result)
        return duplicate_result

    if STATE["emergency_stop"]:
        result = {"status": "blocked", "reason": "emergency_stop_active"}
    elif not STATE["network_ok"]:
        result = {"status": "blocked", "reason": "device_unreachable"}
    elif time.time() - STATE["sampled_at"] > 5:
        result = {"status": "blocked", "reason": "telemetry_stale"}
    elif not 15 <= target_c <= 35:
        result = {"status": "blocked", "reason": "target_out_of_bounds"}
    elif not dry_run and not approved_by:
        # A real gate must authenticate and authorize the human approver.
        result = {"status": "blocked", "reason": "approval_marker_required"}
    else:
        result = {"status": "would_apply" if dry_run else "applied"}
        if not dry_run:
            STATE["target_c"] = target_c

    RESULTS[command_id] = {"command": command, "result": result}
    record(command, result)
    return {**result, "deduplicated": False}


def check(label, expected, **kwargs):
    got = write_target(**kwargs)
    assert got["status"] == expected, (label, got)
    print(label, got)


check("dry-run", "would_apply", command_id="c1", target_c=30)
check("approval-marker-missing", "blocked",
      command_id="c2", target_c=30, dry_run=False)
check("approval-marker-present", "applied",
      command_id="c3", target_c=30, dry_run=False, approved_by="operator")
assert write_target("c3", 30, dry_run=False,
                    approved_by="operator")["deduplicated"]
check("id-conflict", "blocked", command_id="c3", target_c=31,
      dry_run=False, approved_by="operator")
check("bounds", "blocked", command_id="c4", target_c=80)

STATE["sampled_at"] = time.time() - 60
check("stale", "blocked", command_id="c5", target_c=24)
STATE["sampled_at"] = time.time()

STATE["network_ok"] = False
check("network", "blocked", command_id="c6", target_c=24)
STATE["network_ok"] = True

STATE["emergency_stop"] = True
check("e-stop", "blocked", command_id="c7", target_c=24)
print("PASS: unsafe writes never reached the mock actuator")

在終端機執行：

mkdir mhs-mock-lab
cd mhs-mock-lab
# 將上方程式存成 mock_device.py
python3 mock_device.py
wc -l mock-trace.jsonl

本文將上方同一份程式存檔，並在全新的測試資料夾實際執行後，得到 9 筆 trace。七個 command ID 中，只有帶著非空 approved_by 標記的 c3 改變 Mock 狀態；相同 ID、相同 payload 的第二次呼叫被去重，相同 ID 若換 payload 則被拒絕。這個字串只用來驗證分支，不代表真的完成身分或人工核准驗證。

dry-run {'status': 'would_apply', 'deduplicated': False}
approval-marker-missing {'status': 'blocked', 'reason': 'approval_marker_required', ...}
approval-marker-present {'status': 'applied', 'deduplicated': False}
id-conflict {'status': 'blocked', 'reason': 'command_id_payload_conflict', ...}
bounds {'status': 'blocked', 'reason': 'target_out_of_bounds', ...}
stale {'status': 'blocked', 'reason': 'telemetry_stale', ...}
network {'status': 'blocked', 'reason': 'device_unreachable', ...}
e-stop {'status': 'blocked', 'reason': 'emergency_stop_active', ...}
PASS: unsafe writes never reached the mock actuator

逐項驗收：五種故障為什麼都要停？

越界寫入：語法正確，不代表物理合理

80°C 是合法數字，卻超出 Mock 的 15–35°C 範圍。真正系統還要檢查單位、變化率、設備狀態與製程條件；而且低階控制器應有獨立硬限制，不能只相信 Agent 前方的一個 Python if。

過期讀值：舊狀態可能讓新決策變成危險命令

Mock 用五秒 TTL（資料有效期限）示範 freshness gate。五秒不是通用安全值，真實門檻必須依設備與風險分析決定；資料也應帶 timestamp、sequence 與 quality。只要狀態過期，就先重新讀取或停在已知狀態，不讓模型把昨天的事實當成現在。

網路中斷：timeout 不代表命令沒有執行

這個簡化 Mock 在送出前就知道設備不可達，因此直接阻擋；真實網路卻可能在命令已執行後才丟失回覆。此時盲目重試可能加熱兩次或移動兩次。實務上要給命令唯一 ID、在設備端保存去重狀態，並在重連後先查詢與 reconcile 實體狀態。

重複命令：傳輸重試不等於物理 exactly-once

c3 第二次以相同 payload 出現時只回傳舊結果，不再觸發 actuator；若沿用 c3 卻把 30°C 改成 31°C，則回傳 command_id_payload_conflict。這仍只是程序記憶體內的教學示範；正式設計要跨重啟持久保存 command ID、規範化 payload 與 outcome，拒絕「相同 ID、不同 payload」，定義保留期，並把訊息去重與實體副作用是否只發生一次分開驗證。

急停：聊天視窗的 Stop 不是 E-stop

Mock 的 emergency_stop 只是一個布林值，用來測試軟體流程；它不是 safety-rated 急停。真實 E-stop／interlock 不應依賴 Agent、雲端或同一條一般網路，而且解除後不應自動重啟危險動作。OPC UA Safety 的官方範圍說明也明確區分一般通訊與 safety communication：使用一種協定，本身不足以讓普通設備取得安全資格。

這個 Mock 證明了什麼，又沒有證明什麼？

它證明的是策略順序可以被測試：先檢查軟體停止旗標、連線與資料新鮮度，再檢查 bounds 與 approval marker，最後才改變狀態；同一 ID 與相同 payload 不重複執行。每次判斷也寫入 JSONL（每行一筆 JSON 的紀錄格式），方便回放 command payload、本機記錄時間與 Gate 為何允許或拒絕；這份 trace 沒有經驗證的呼叫者身分、可信時間戳或完整性保護，因此不能證明誰發出或核准命令。

它沒有證明 MHS 相容、硬體安全、網路可靠或 real-time。Mock 預設感測器與 actuator 都很理想，approved_by 也只是可任意填入的字串，不是身分驗證；open(..., "a") 只代表程式採追加寫入，任何有檔案權限的人仍可能修改 trace，狀態更新與寫入 trace 也不是同一筆 transaction，程序中斷時可能只完成其中一邊。正式系統還需要 HIL（hardware-in-the-loop，讓軟體接上真控制器）測試、低能量 commissioning（受控試車）、獨立感測與 interlock（條件不符就阻止動作的聯鎖），以及防竄改、可保留的稽核管線。

NIST SP 800-82 Rev. 3 對 OT（營運技術系統）的提醒很適合放在這裡：工業系統要同時考慮安全、可靠度與 fail-to-known-state（回到預先定義的已知狀態）；網路中斷時的安全反應也未必永遠是立刻停機，因為某些製程突然停止反而會製造次生危害。安全狀態必須由場景風險分析決定，不是由聊天模型臨場猜測。

真正上硬體前，建議走四級放行

1. Read-only／shadow：Agent 只能讀狀態與提出建議，不能 write；先量測錯誤判斷率。
2. Mock／simulation：像本文一樣注入 stale telemetry（過期設備狀態）、bounds、斷線、重複命令與急停，要求每項都有可判分結果。
3. HIL／低能量 commissioning：接真 Driver 與真控制器，但限制速度、力量、溫度或樣本價值，由操作員監看。
4. Bounded production：只開放通過驗收的動作；高風險 write、提高界限、首次運轉與故障恢復仍需分級核准，Safety PLC 與 SIS（安全儀控系統）等安全功能應維持獨立；本文不把尚無公開 safety-rating 證據的 Agent／MHS 路徑當作安全功能。

如果你還不熟悉 Agent 的模型、工具、迴圈與停止條件，先看 AI Agent Harness 完整解析；若要自己搭最小迴圈，可接著做 Agent Harness 實作教學。真正進入生產環境時，還要把本文的 physical safety 與 Agent 身分、最小權限、撤銷與歸因合併，不能只選其中一套。

新手最容易踩的五個坑

1. 把 MHS 寫成已開源標準：目前仍是限量研究預覽；本文查核的公開入口未提供足以自行判定相容性的實作材料。
2. 把 MCP 與 MHS 畫上等號：MCP 是存取路徑之一，MHS 的重點是設備 Driver、描述、discovery 與 read／write。
3. 讓 LLM 跑快速控制迴路：模型可規劃與監督，deadline 明確的 loop 要交給確定性控制器。
4. 把重試當成無害：實體副作用可能已發生；timeout 後應先查狀態，而不是再送一次。
5. 把軟體 Guard 當成安全認證：bounds、核准與 trace 很有用，卻不能取代獨立 E-stop、interlock、SIS 或適用的功能安全驗證。

MHS 官方案例應該怎麼讀？

這些內容是 Anthropic 整理的 Genentech、華盛頓大學、CMU、QuEra、Tetsuwan 等 early projects；其中 Genentech 與華盛頓大學明稱 proof of concept。本文因此不把整組案例當成獨立 benchmark 或 safety certification。這些案例說明共同 Driver 可能讓 Agent 跨設備協作，也暴露物理世界比軟體更棘手：在 Genentech 案例中，模型把起泡視為可重試的軟體問題，重試反而讓情況惡化，最後仍需要專家指導。

這個反例比順利展示更重要。Anthropic 指出，Claude 主要透過文字與影像學習物理世界，spatial／physical reasoning 仍有限；Genentech 的起泡故障就是公開例子。想進一步理解「模型會控制機器人」與「設備整合標準」的差別，可讀 Gemini Robotics 2 與具身模型解析；兩者都碰物理世界，但前者偏模型能力，MHS 偏控制介面與設備抽象。

截至 2026 年 8 月 31 日，Anthropic 公開頁面尚未說明哪些事情？

• 完整 normative specification、公開 SDK、授權與 conformance suite。
• 權限、身分、命令原子性、去重、斷線恢復與 audit schema 的正式語義。
• 安全限制在哪一層 enforce，以及如何與既有 PLC、SIS、interlock 和產業標準整合。
• latency、jitter、deadline 等 hard real-time 指標，以及獨立的量產可靠度資料。
• 何時開源、哪些硬體類別優先，以及 programmable interface 的正式邊界；官方總結與 CMU 的 GUI-only 案例仍需一併解讀。

這些不是小字細節，而是判斷 MHS 能否進入真實工廠與實驗室的核心證據。若 Anthropic 之後公開 schema、Driver contract 與測試向量，本文 Mock 才能改寫成可公開驗證的相容實作教學。

常見問題 FAQ

MHS 已經開源了嗎？

還沒有。截至 2026 年 8 月 31 日，MHS 是需要申請的 limited research preview；官方表示會在和早期夥伴建立安全評估與最佳實務後走向開源，但本文查核的公告與官方入口未列出開源日期。

MHS 就是「硬體版 MCP」嗎？

不是，只能當粗略比喻。MCP 是 MHS 的一種 Agent 存取方式；MHS 更靠近設備 Driver、發現、描述與 read／write 介面，也能從 CLI 或 code／API 使用。

現在可以照本文寫出真正的 MHS Driver 嗎？

不能只靠本文。本文程式是 AlphaLab 的概念 Mock，不使用 MHS schema，也不主張 protocol conformance。研究預覽夥伴已在實作 Driver；其他讀者若要做相容實作，須取得研究預覽存取，或等待 Anthropic 公開足以實作與驗證相容性的材料。

MHS 可以直接控制任何硬體嗎？

不能這樣說。官方的一般說明稱 MHS 適用於具 programmable interface 的設備，也稱目前不支援欠缺該介面的硬體；但同頁 CMU 案例又示範一台只有 GUI、沒有 programmatic interface 的讀板機由 MHS 自動化操作。公開材料尚未明確定義 GUI automation 是否算在 programmable interface 範圍內；每台設備仍需要相應 Driver 與風險驗證。

MHS 能取代 PLC 或 Safety PLC 嗎？

目前不能依 Anthropic 的公開資料把 MHS 當成替代品。本文查核的官方頁面未宣稱 MHS 具備 hard real-time 或功能安全認證；快速控制與最終安全功能仍須交由符合場景要求的控制器與安全系統。

人工核准是不是每次 write 都要做？

不一定，應依風險分級。高危 write、提高界限、首次執行與故障恢復值得要求人類核准；低風險、已驗證且範圍固定的動作可自動化，但仍要有獨立限制與可撤銷機制。

為什麼不能在 timeout 後直接重試？

因為回覆遺失不等於動作沒發生。命令可能已讓設備移動，只是成功訊息沒有回來。應由設備端持久保存 command ID、規範化 payload 與 outcome，拒絕相同 ID 對應不同 payload；重連後仍要先查詢並 reconcile（重新核對）實體狀態，再決定恢復方式。

Mock 測試通過，就能接真硬體嗎？

不能直接上線。Mock 只驗證理想化邏輯；接下來還要做 HIL、低能量 commissioning、故障與網路測試、獨立安全系統驗證，以及操作員演練。

新手先記住這五件事

1. MHS 目前是研究預覽，不是已公開完成的業界標準。
2. MHS 讓 Agent 更容易理解設備；MCP 只是可用的存取方式之一。
3. read 是觀察，write 會改變物理世界；兩者的風險不能等量齊觀。
4. 模型負責高階決策，快速迴圈交給確定性控制器，最終安全交給獨立安全層。
5. Mock 的價值是讓錯誤可注入、結果可判分；它不是硬體安全證明。