軟體 API 寫錯，通常會留下 error、失敗的 job，或一份還能丟掉的 diff。硬體介面比較麻煩：設備回傳 write: success 時，溫度、位置或轉速可能已經改變了。

成功送出命令，只能證明命令抵達。它沒有證明這個動作此刻可以做，也沒有證明設備最後停在安全狀態。

Anthropic 在 2026 年 8 月 27 日發布 Model Hardware Standard（MHS）research preview，嘗試用標準化驅動程式、裝置探索與 read／write primitives，讓 agent 透過 MCP、CLI 或程式碼檔案控制實驗室與製造設備。這個方向很值得注意，但官方同時把專家監督與安全評估列為必要條件。它目前仍是 research preview，不能當成已經補齊授權、interlock、rollback 或 functional safety 的成熟標準。

對準備把 agent 接進 IoT、機器人或測試台的團隊來說，介面標準化只完成前半段。後半段得由使用設備的人自己定義。

把「連得上」和「可以動」拆開

我會把硬體 agent stack 分成三層來看。

第一層是 driver 與 transport，負責辨識設備、讀取狀態、送出命令。第二層是 device capability，描述這台設備有哪些感測值與可改變的狀態。最後一層是團隊維護的 action contract：什麼條件下允許寫入、誰要核准、如何驗證結果、何時停手，出事後由誰接管。

MHS research preview 主要推進前兩層的互通性。Google 的 Agent Plugins 與 AWS Agent Toolkit 則透露另一個趨勢：skill、工具和 MCP 設定正逐漸變成可打包、安裝與更新的能力層。這對軟體工具很方便，搬到實體設備卻會多出一個不能忽略的落差。

同一份 plugin 可以成功安裝在兩個 agent client，不代表兩邊的核准流程、逾時處理與停止行為相同。相同的 set_target 動作放到兩台設備上，也不代表它們有相同的限制與失效方式。可攜性處理的是「怎麼呼叫」，執行安全得回答「這一次能不能呼叫」。

最小 action contract 要寫下什麼

下面是一份團隊自用的 pseudo-YAML。它不是 MHS、MCP、Anthropic、Google 或 AWS 的官方 schema；欄位名稱也不是重點。重點是讓每次實體狀態變更都有可檢查的入口與出口。

device:
  id: bench-thermostat-a
  expected_identity: validated-device-profile

action: set_target_temperature

preconditions:
  equipment_mode: idle-test
  sensor_freshness: within-team-policy
  operator_state: available

allowed_range:
  source: approved-test-profile

requires_approval: true
timeout: team-defined

postconditions:
  - independent_readback_matches_request
  - measured_state_remains_within_policy

evidence:
  - pre_action_snapshot
  - approval_record
  - command_receipt
  - independent_readback

stop_rule: "unknown, stale, out-of-range, or unverifiable => stop"
recovery_owner: lab-operator

這份契約刻意把「允許送出」與「確認完成」分開。Tool call 回傳 success 只能當 command receipt，不能兼任完成證據。設備可能接受了命令，感測器卻沒有反映預期狀態；也可能讀值看似正常，但讀取和寫入共用同一個故障中的控制器。

recovery_owner 也不該寫成 agent。遇到未知設備狀態時，模型不會因為多看幾段 prompt 就突然具備現場判斷能力。責任必須落到真的能檢查設備、啟動安全停機或隔離現場的人。

用測試台溫控器走一次流程

假設 agent 要調整一座低風險測試台的溫控器設定。它不該拿到目標值後立刻執行 write，而是先產生一份 plan，列出設備身分、目前讀值、感測資料的新鮮度、測試模式、允許範圍與操作員狀態。

接著由 policy engine 檢查 action contract。需要人工核准時，系統必須等到明確的 approval record，不能把聊天室裡一句含糊的「可以」猜成授權。檢查通過後才送出 guarded write，並在逾時前完成獨立 read-back 與 postcondition check。最後保存命令、讀值、核准與交接紀錄。

這條流程可以縮成：

observe / plan
  -> policy check / approval
  -> guarded write
  -> independent read-back
  -> postcondition check
  -> evidence / handoff

其中任何一步出現下列狀況，就停在寫入前或進入安全停止狀態：

• 感測資料已過期，無法確認目前狀態；
• 目標值超出核准的測試範圍；
• 寫入後無法取得可信的 read-back；
• 需要接管的操作員不在線。

在這裡，fail closed 得落成具體的產品行為。UI 要顯示為何停止、缺哪份證據、誰能解除阻擋；稽核紀錄則要保留 agent 看到了什麼，以及哪一條 policy 拒絕了動作。只丟出「工具呼叫失敗」對現場人員幾乎沒有幫助。

實體世界的 rollback 常常只是想像

軟體系統習慣把 rollback 當最後一道保險。硬體不一定給你這個選項。

把設定值寫回原本數字，無法消除已經發生的升溫、移動、磨耗或材料變化。外部副作用也可能早已離開設備邊界。對可逆性未知或影響範圍較大的動作，契約應直接拒絕自動執行，要求額外 interlock 或專家確認。設備若已進入異常狀態，優先做的是安全停止與交接，不是讓 agent 猜一個反向 write。

這也改變了測試方式。團隊除了驗 happy path，還要刻意餵入 stale sensor、錯誤設備身分、逾時、read-back 不一致與核准者離線等狀況，確認系統真的會停。Agent 說「我會停止」不算測試通過；執行層必須留下拒絕紀錄，而且設備狀態沒有被改變。

MHS 這類介面標準若繼續發展，確實可能讓更多 agent 找得到、讀得懂、叫得動設備。但「叫得動幾台」不適合拿來衡量系統成熟度。每一次實體狀態變更能否提出允許條件、獨立驗證結果，並在資訊不足時確實停下來，才是團隊該驗收的能力。

參考來源

• Previewing the Model Hardware Standard
• Agent Plugins package your skills, tools, and more
• Get started with the Agent Toolkit for AWS in the AWS CLI