以 Claude Code 經 MCP 控制 Home Assistant：便利背後的權限界線

圖片：TechLab 自製資訊圖

TechLab 編輯部（譯）·2026-10-04

XDA Developers 作者 Anurag Singh 分享其個人 home lab 設定：透過 Home Assistant 內置的 Model Context Protocol（MCP）Server 整合，將指定智能家居實體交給 Claude Code 使用。完成連接後，Claude Code 可在同一段對話中讀取已暴露裝置的狀態，並執行例如開關燈等動作；若把既有 Home Assistant script 暴露為工具，agent 亦可觸發一組預先編排好的家居流程。

這不是 Claude Code 或 Home Assistant 宣布新增一項全面代管家居的官方服務，而是基於現有 MCP 整合的個人實作。對使用 NAS、迷你 PC 或其他 home server 運行 Home Assistant 的用戶而言，這個做法的價值在於把本來分散於 dashboard、script 與開發工作中的操作，收進 Claude Code 的對話介面；同時，風險亦隨之由「操作方便」轉為「agent 實際可碰到甚麼」。

MCP 把對話接到家居工具，但範圍有限

按原文所述，Home Assistant 的 MCP Server 整合會把 Assist API 暴露給 Claude Code。MCP 是開放標準，因此理論上，同一整合亦可配合其他兼容 MCP client。Home Assistant 會向模型提供已暴露實體的相關 context，讓它知道可用裝置及其狀態；工具層面則可支援查詢實體和執行動作，例如判斷某盞燈是否開啟，再將它關掉。

這種組合適合處理帶有上下文的即時指令。原文舉例，使用者可要求 Claude Code 關閉樓下的燈，但保留洗手間燈光；亦可先查詢樓下哪些燈仍然亮着，然後逐一關閉。當使用者本來已在 Claude Code 內處理程式或其他工作，少開一個 Home Assistant dashboard 的確較順手。不過，模型負責理解意圖及選擇工具，實際執行的能力仍取決於 Home Assistant 暴露了哪些實體和 script。

原文同時劃出重要界線：內置 Assist API 不會給 Claude 管理員權限。因此，啟動既有 script 與改寫 script 是兩回事；前者可透過這個整合執行，後者如建立 integration、修改 automation YAML，則需要另一條連接途徑。這項限制令 MCP 較像受控的操作層，而非讓 agent 接管整個 Home Assistant 管理面板，對家居環境而言是合理的預設。

以 Claude Code 經 MCP 控制 Home Assistant：便利背後的權限界線

圖片：Wikimedia Commons 檔案頁 — JohnWilliamDoe (CC BY-SA 3.0)

設定的第一步，是縮小可見實體

原文列出的 Home Assistant 設定路徑為「Settings → Devices & services → Add integration」，搜尋並加入「Model Context Protocol Server」，再啟用控制 Home Assistant 的選項。之後可到「Settings → Voice assistants → Expose」，選擇哪些實體交給 Assist 使用。這一層選擇會直接決定 Claude Code 可以讀取或控制甚麼，並非只是一項方便的介面設定。

較穩妥的做法，是先只暴露少量、後果低的裝置，例如個別燈光，驗證查詢和控制是否符合預期，再按需要擴大範圍。從原文的設定方式可見，agent 的能力由暴露面決定，故此不必一開始把全屋燈光、保安或其他關鍵設備全數交出。將多裝置流程收進一個既有 script，也能把動作次序、延遲與例外處理留在 Home Assistant 的既定流程內，而非每次由對話臨時拼湊。

作者以睡前程序作例子：其現有 Home Assistant 與 Node-RED 流程會關閉電視及喇叭、調整恆溫器、啟動保安，並讓洗手間燈保持昏暗五至十分鐘。他把觸發該程序的 Home Assistant script 暴露為 Claude 可呼叫的工具。這個安排的重點是讓 agent 只負責「啟動已定義程序」；涉及時間與裝置協調的邏輯仍由原有流程承擔，較容易檢視及維護。

長期 access token 與端點設定是安全重點

Claude Code 需要向 Home Assistant 驗證身分。原文的 token 方式是進入 Home Assistant 使用者 profile 的 Security 分頁，建立一枚 long-lived access token，複製後用於連接指令；連接須在電腦的終端機內設定，不是在已開啟的 Claude Code 對話中進行。其 HTTP MCP endpoint 格式為 Home Assistant 位址加上 :8123/api/mcp，並以 Bearer token 放進 Authorization header。

long-lived token 的含義很直接：取得該 token 的人或程式，可能在其權限範圍內使用這條家居控制通道。因此不應把 token 貼進對話、截圖、程式碼 repository 或不受保護的設定檔，也不宜把可從公開網絡任意到達的端點，與一枚長期有效 token 一起當作普通便利功能處理。原文使用的是 HOME_ASSISTANT_IP 形式的位址；在實作上，使用者應先釐清 Claude Code 所在裝置如何安全地到達自己的 Home Assistant，而不要為求連通而盲目擴大外部暴露範圍。

完成註冊後，作者會開啟新的 Claude Code session，使用 /mcp 檢查 Home Assistant 是否顯示為已連接，再先以「某盞已暴露的燈是否開啟」這類低風險查詢測試。這個驗證次序值得採用：先確認可見範圍和讀取結果，再嘗試單一、可逆的控制動作；如發現裝置對應或理解有誤，應先收窄暴露實體或修正命名，而不是立即加入更多控制權限。

保留自動化，讓 agent 處理按需操作

作者沒有以 Claude Code 取代 Home Assistant automation。排程動作和感應器觸發仍交由既有自動化負責；MCP 只是在使用者發出要求時，向 Claude 提供可調用的工具。換言之，這套組合不會自動變成全天候監察家居並自行作決定的服務。對希望維持可預測行為的 home lab 用戶，這種分工較清楚：automation 處理已知觸發條件，對話式 agent 處理人手提出、需要跨多項工作上下文理解的要求。

若 home server 還運行其他 app，原文指出每個要交給 agent 的功能都需要相應 MCP service 暴露出來。Claude Code 可連接 HTTP endpoint；另一個選項是在 server 上透過 SSH 啟動 stdio MCP process。這亦表示整合範圍可以逐項擴展，但每增加一項 service，便多一個要界定功能、驗證身分與審視權限的入口，並非單純加裝一個 AI 功能便可一勞永逸。

接下來較值得觀察的，是用戶會否把 MCP 控制維持在照明、查詢狀態及既有 script 觸發等低風險場景，還是逐步連接更多 home lab service。前者可先建立可靠的使用習慣；後者則要求更仔細管理實體暴露範圍、長期 token 與遠端連接。對已有 Home Assistant 的使用者，最實際的起點仍是小範圍測試，確認每一項可控制功能都符合自己原本的家居自動化設計。