Agent 從回答問題走向執行任務，第一步是取得工具；從數位環境走進實驗室、工廠與裝置現場，還要面對另一種難度：每台設備有不同介面、狀態、時間尺度與安全限制。
Model Context Protocol（MCP）與 Model Hardware Standard（MHS）分別處理這兩個層次。MCP 讓 Agent 以一致方式連接數位資源與能力；MHS 是 2026 年公開的研究預覽，探索如何描述、發現、讀寫與協調物理設備。
MCP 讓 Agent 能連接數位能力；Model Hardware Standard 嘗試讓 Agent 以一致、且受安全邊界約束的方式操作物理設備。
兩者可以一起使用，但 MHS 不是 MCP 2.0，也不是已經併入 MCP 的新版本。把它們理解成互補層，比理解成前後代產品更準確。
MCP 解決數位能力如何被發現與調用
MCP 2026-07-28 架構規格採 host、client、server 架構。Host 管理多個 client、使用者授權與安全政策；每個 client 對應一個 server；server 則提供聚焦的 resources、tools 與 prompts。這個分工讓 Agent 應用不必替每個資料源與工具各寫一套專用整合。
在知識工作裡，MCP server 可以提供筆記搜尋、文件讀取、資料庫查詢或外部服務操作。協定本身負責交換與能力協商，至於什麼資訊要交給模型、何時能調用工具、結果能否相信，仍由 host 與應用架構負責。
這個邊界很重要。MCP 並不自動讓 Agent 擁有完整個人脈絡，也不保證每次工具調用都正確。它解決的是連接問題：讓原本分散的數位能力有共同介面，並維持明確的安全邊界。
MCP 的 2026 roadmap持續處理 transport、scalability、agent identity、server-initiated events、result types 與企業授權等議題。這說明 MCP 正從早期工具連接走向正式部署需求，但 roadmap 代表方向與優先順序，不等於所有工作已經完成。
MHS 解決物理設備的描述、狀態與控制
Anthropic 在 2026 年 8 月 27 日公布 Model Hardware Standard research preview。專案起源於 Anthropic 與 HHMI Janelia Research Campus 的合作，截至 2026 年 10 月仍以 limited research preview 方式邀請科學研究與先進製造夥伴參與。
MHS 官方網站明確表示，團隊要先建立安全評估與最佳實務，之後才計畫開源。因此，現在不應把 MHS 描述成已公開、可自由部署的成熟標準，也不能因為名稱裡有 Standard，就推定它已經獲得產業標準組織採納。
依 Anthropic 發布的技術說明，MHS 包含幾個關鍵設計：
- 用標準化 driver 連接具有可程式化介面的設備。
- 以
read、write等基本操作讀取感測值或設定設備參數。 - 讓設備以一致格式被發現，並描述可量測內容、可調整參數與安全限制。
- 以自然語言標籤補入程式介面之外的機器特性與操作知識。
- 透過共同狀態表示，讓不同程序與設備交換即時狀態。
- 提供 MCP、CLI 與 code API 等控制路徑，讓 Agent 或確定性程式進行協調。
這裡最關鍵的不只是「Agent 能動硬體」，而是物理世界需要更完整的狀態與限制。數位 API 呼叫失敗，常可以重試或回滾；機械手臂撞擊、樣本受污染或雷射參數錯誤，可能留下不可逆後果。因此，設備能力不能只描述「可以做什麼」，還要描述範圍、單位、速率、互鎖、即時狀態與禁止條件。
MCP 與 MHS 是互補層，不是替代關係
MHS 官方說明它是 model-agnostic，任何 Agent harness 都可以透過 MCP、CLI 或 code API 存取。這句話指出兩者的關係：MHS 建立物理設備的 driver、狀態與安全描述；MCP 可以成為 Agent 存取這些能力的其中一條標準路徑。
可以用四層來理解：
- Personal Context：這是誰的任務、目標與限制，任務進度如何。
- MCP：有哪些數位資料、工具與服務可以被發現及調用。
- MHS：有哪些實體設備、可讀狀態、可寫參數與安全邊界。
- Agent Experience：行動是否真的產生預期結果，如何驗證、反思並回寫經驗。
MCP 與 MHS 都不應被塞進 memory。它們屬於能力與環境層；Personal Context 屬於任務與個人脈絡層；結果驗證與經驗回寫則是另一個循環。分清楚之後，才能避免「工具接上了，就等於 Agent 已經懂情境、會安全工作」的誤判。
同樣地，MHS 也不宜被宣稱會取代 ROS 2、OPC UA、PLC 或既有工業控制系統。現有技術各自處理即時通訊、控制、設備互通與產業安全。依截至 2026 年 10 月的公開資料，MHS 比較像加在既有設備與控制軟體上的 Agent 可理解介面與協調層；它是否、以及如何與既有標準長期分工，仍要等研究預覽與後續公開規格才能判斷。
官方案例顯示可行性，也揭露限制
Anthropic 的發布材料列出顯微鏡、液體處理設備、機械手臂與量子運算設備的雷射校準等合作案例，也描述整合時間縮短與回饋循環實驗的結果。這些案例是由計畫發起方與合作夥伴提供的 proof of concept，足以說明技術路徑值得測試，但還不是跨場域、第三方重複驗證的通用結論。
同一份官方資料也揭露幾個限制：截至 2026 年 10 月，MHS 只能連接有可程式化介面的設備；模型對空間與物理世界的理解仍有限；遇到硬體本體問題時仍需要專家；Agent 對風險不確定時可能停下等待人工確認；要完成任務，也需要提供大量實驗與設備脈絡。
這些限制不是附帶問題，而是 Physical AI 的核心。物理系統的可靠性不能只靠模型更聰明，還需要確定性控制、硬體互鎖、即時監測、人工接管與可重現的驗證。
從工具調用走向安全控制迴路
若把 MCP server 接上硬體 API，只做到「模型可以發出命令」。要讓系統成為可工作的物理 Agent，至少還要補上五個機制。
能力與狀態要分開
「可以設定溫度」是能力，「設備顯示 82°C、正在升溫、門已開啟」是狀態。Agent 在執行前必須同時看到兩者，並理解單位、有效範圍與資料新鮮度。
安全限制要在模型之外執行
模型可以提出動作，但硬限制應由 driver、控制器或獨立 policy enforcement 執行。超出壓力、溫度、速度與工作區域的命令，不應因為 prompt 寫得合理就被放行。
長任務要有確定性執行層
需要毫秒反應或長時間穩定循環的工作，不適合讓模型每一步在線推理。Anthropic 的 MHS 說明也提到，Agent 可以把學到的步驟封裝成 code files，讓設備以確定性程式執行。Agent 適合在決策點介入，控制器則承擔高速與穩定迴路。
結果要由感測與外部狀態驗證
發出 write 不等於設備已達到目標。系統要查回感測值、影像、錯誤碼與產出品質，才能判斷成功、重試、停止或要求人工介入。
每次行動都要能追溯
誰提出命令、使用什麼脈絡、經過何種核准、driver 實際執行什麼、感測器回傳什麼，都應形成可稽核事件。這不只為了除錯，也是讓後續反思不會把錯誤推論寫成永久經驗。
團隊現在應該如何評估 MCP 與 MHS
如果工作仍以文件、資料庫與 SaaS 為主，先把 MCP 的能力邊界、授權、結果驗證與錯誤處理做好，不需要因為 MHS 出現就重建架構。如果已經有實驗室、製造或 IoT 場景，則可以先從低風險、可回復、有感測回饋的設備開始盤點。
實作前至少回答以下問題：
- 裝置是否已有穩定 API、SDK 或可控介面？
- 哪些變數只是可讀，哪些可以寫入，單位與範圍是否明確？
- 哪些安全限制由硬體、driver 或獨立控制器強制執行？
- 哪些動作必須人工核准，緊急停止與人工接管如何運作？
- 成功由什麼外部訊號判定，失敗後能否安全恢復？
- 執行紀錄如何連回任務、版本、操作者與後續經驗？
MCP 與 MHS 的組合，真正有價值的地方不是讓模型「碰得到更多東西」，而是把數位能力與物理設備納入同一個可描述、可授權、可觀察的工作環境。可連接只是起點，安全完成才是目標。
從 Personal Context → Agent Experience 的角度看，這也補上完整循環的行動與環境層：個人脈絡告訴 Agent 為誰、為何與在什麼限制下工作；MCP 與 MHS 提供可用能力；感測與外部系統回報實際結果；反思再把經驗寫回規則、技能與脈絡。任何一層單獨存在，都還不是完整的 Agent Experience。
完整的層次與回寫關係可見Personal Context → Agent Experience母文；MCP 與 MHS 在其中屬於能力與環境層，不應被誤寫成記憶或治理本身。