建築自動化產業正面臨一個結構性矛盾：建築的生命週期長達 50–80 年，但控制系統的技術迭代週期僅 10–15 年。當業主在 2010 年安裝了 Siemens Desigo CC、2018 年擴建時改用 Johnson Controls Metasys、2024 年再加入 Schneider EcoStruxure 的能源管理模組，三套系統各自為政、資料格式互不相通的困境便成為常態[1]。Anthropic 於 2024 年 11 月發布的 Model Context Protocol（MCP）開放標準[2]，雖然最初設計用於 AI 模型與外部工具的整合，但其架構邏輯——一個通用的資料存取層連接異質系統——恰恰回應了建築自動化領域數十年來懸而未決的互通性難題。本文將從空調工程的實務視角，探討 MCP 協定如何為智慧建築管理開啟新的整合範式。

一、廠牌壁壘：建築自動化的結構性困境

全球建築自動化系統（Building Automation System, BAS）市場長期被四大廠牌主導：Siemens 的 Desigo CC、Johnson Controls 的 Metasys、Honeywell 的 Niagara Framework，以及 Schneider Electric 的 EcoStruxure Building[1]。這些廠牌各自發展出完整的生態系統——從現場控制器、通訊協定、到上位監控軟體——形成高度垂直整合的封閉架構。

廠牌鎖定的成本代價

廠牌鎖定（Vendor Lock-in）對建築業主造成的成本代價是多層次的。首先是採購成本：當一棟建築已經部署了特定廠牌的控制器與通訊基礎設施，後續的擴充與維護幾乎只能選擇同一廠牌的產品，業主失去了在市場上議價的籌碼。其次是整合成本：當不同區域或不同系統（空調、照明、電力監控）使用不同廠牌的控制器時，系統整合需要透過中間件（Middleware）或閘道器（Gateway）進行協定轉譯，每一個轉譯節點都增加了成本、延遲與故障點。

根據 ASHRAE 的技術報告，在一棟典型的 50,000 平方公尺商辦大樓中，BAS 系統的生命週期整合成本可占初始安裝成本的 150–200%[3]。其中，跨廠牌整合的工程費用往往是最大的隱性支出。

資料孤島與能源管理的困境

廠牌壁壘造成的更深層問題是資料孤島（Data Silo）。一棟現代建築可能擁有數千個感測點位——溫度、濕度、CO2 濃度、冰水流量、電力負載——但這些數據分散在不同廠牌的控制器中，使用不同的資料模型與命名慣例。空調系統的冰水出水溫度在 Siemens 系統中可能標記為「CHW_Supply_Temp」，在 Honeywell 系統中則是「CW_ST」，在 Schneider 系統中又變成「ChilledWater.Supply.Temperature」。這種語義不一致使得跨系統的能源分析與最佳化幾乎不可能自動化執行。

二、傳統協定：BACnet、Modbus 與 LonWorks 的互通挑戰

建築自動化產業並非沒有嘗試建立開放標準。過去三十年，業界發展出多種通訊協定，試圖解決設備間的互通性問題。

BACnet（ASHRAE Standard 135）

BACnet 是目前建築自動化最廣泛採用的開放協定，由 ASHRAE 於 1995 年制定為 ANSI/ASHRAE Standard 135，並於 2003 年成為 ISO 16484-5 國際標準[4]。BACnet 定義了建築控制設備之間的資料通訊規範，涵蓋物件模型（Object Model）、服務（Services）與網路層（Network Layer）。其物件模型將建築控制元素抽象為 Analog Input、Analog Output、Binary Value 等標準物件類型，每個物件具有 Present Value、Status Flags 等標準屬性。

然而，BACnet 的實際互通性遠不如標準文件描述的那樣理想。首先，BACnet 允許廠商定義私有物件（Proprietary Objects）與私有屬性（Proprietary Properties），各廠牌大量使用這些擴充來實現差異化功能，導致 BACnet 設備之間的「互通」往往僅限於基本的讀寫操作，進階功能仍需依賴廠牌專屬的軟體。其次，BACnet 的物件命名不具語義約束——同樣是一個 Analog Input 物件，不同廠牌對 Description 與 Object Name 的填寫方式完全不同，機器無法自動理解其代表的物理意義[5]。

Modbus 與 LonWorks

Modbus 是工業自動化領域最古老的通訊協定之一，由 Modicon（現 Schneider Electric）於 1979 年開發。其簡單的暫存器讀寫架構使其在空調設備（冰水機、空調箱、變頻器）中被廣泛採用，但 Modbus 缺乏物件模型與語義描述能力——暫存器地址 40001 儲存的是溫度還是壓力，完全仰賴設備廠商的文件說明，不同廠商的暫存器映射（Register Map）毫無一致性可言。

LonWorks（由 Echelon Corporation 開發）與 KNX（歐洲主導的建築自動化標準）則在特定市場擁有一定的佔有率，但它們與 BACnet 之間的轉譯仍然需要專用閘道器，每增加一種協定的互聯就需要一層轉譯，系統複雜度呈指數成長。

語義互通性的根本缺口

上述傳統協定解決的是「通訊互通性」（Communication Interoperability）——設備之間可以交換數據位元組——但未能解決「語義互通性」（Semantic Interoperability）——系統之間能自動理解數據的含義、上下文與關聯性。這正是 Project Haystack 等語義標記框架試圖填補的缺口[6]。

三、MCP 是什麼？——AI 工具整合的開放協定

Model Context Protocol（MCP）是 Anthropic 於 2024 年 11 月公開發布的開放標準，定義了 AI 模型（如 Claude）與外部資料來源及工具之間的通用通訊協定[2]。MCP 的核心理念是：與其為每一個外部系統開發專屬的 API 整合，不如建立一個標準化的介面層，讓 AI 模型能夠以統一的方式存取任何符合 MCP 規範的資料來源。

MCP 的技術架構

MCP 採用客戶端—伺服器（Client-Server）架構，基於 JSON-RPC 2.0 訊息格式[2]。其核心組件包括：

  • MCP Host：發起連線的應用程式（如 Claude Desktop、IDE 插件），負責管理與多個 MCP Server 的連線
  • MCP Client：運行在 Host 內部，與單一 MCP Server 維持一對一的有狀態連線（Stateful Session）
  • MCP Server：輕量級的服務程式，透過標準化介面向 Client 暴露三類能力——Resources（資料資源）、Tools（可執行的操作）與 Prompts（預設的互動範本）

MCP 的傳輸層支援 stdio（本地程序間通訊）與 HTTP+SSE（Server-Sent Events，適用於遠端通訊），且允許擴充自訂傳輸協定。連線建立時，Client 與 Server 進行能力協商（Capability Negotiation），確保雙方支援的功能相容[2]。

MCP 與建築自動化的結構對應

MCP 的架構邏輯與建築自動化系統的整合需求存在驚人的結構對應。將 MCP 的概念映射到建築領域：

MCP 概念 建築自動化對應 具體範例
MCP Host 建築管理平台 / AI 代理 統一的 BMS 儀表板或 AI 最佳化引擎
MCP Server 各廠牌 BAS 系統的介面層 Siemens Desigo MCP Server、Honeywell Niagara MCP Server
Resources 建築感測器數據與設備狀態 冰水出水溫度、空調箱運轉狀態、能耗數據
Tools 設備控制操作 調整冰水機設定點、切換空調箱運轉模式
Prompts 預設的運維查詢範本 「查詢3樓空調異常」、「生成月度能耗報表」

這種對應不是巧合。MCP 要解決的問題——讓 AI 以統一方式存取異質資料系統——在本質上與建築自動化長期追求的跨廠牌互通性是同一個工程挑戰的不同表述。

四、OpenClaw 與 MCP 的生態系統擴展

MCP 的開放性質催生了快速成長的開發者生態系統。OpenClaw 計畫是其中的重要推動力量，作為 MCP Server 的開源登錄與發現平台，OpenClaw 讓開發者能夠發布、搜尋與部署各類 MCP Server[7]。截至 2026 年初，OpenClaw 上已登錄超過數千個 MCP Server，涵蓋資料庫連接、API 整合、檔案系統操作、IoT 設備管理等範疇。

從軟體整合到物理系統控制

MCP 生態系統的擴展正從純軟體領域向物理系統控制延伸。已有開發者建構了針對 MQTT（IoT 通訊協定）、OPC UA（工業自動化通訊協定）的 MCP Server，這些協定正是智慧建築感測器與控制器的核心通訊管道。一個運行 BACnet/IP 通訊的 BAS 控制器，透過 BACnet-to-MQTT 閘道器將數據發布至 MQTT Broker，再由 MQTT MCP Server 將這些數據以標準化的 Resource 格式暴露給 AI 代理——這條技術路徑在今天已經完全可行。

OpenClaw 的登錄機制為這個生態系統帶來了關鍵的可發現性（Discoverability）。想像一個場景：當一位建築設施管理者在其 AI 助手中搜尋「Siemens Desigo BACnet」，OpenClaw 可以回傳相應的 MCP Server 套件，管理者安裝後即可讓 AI 代理存取 Desigo 系統的數據——無需開發專屬的 API 整合代碼[7]。

五、AI 代理如何橋接異質 BAS/BMS 系統

MCP 的真正威力在於它使 AI 代理（AI Agent）能夠同時連接多個異質系統，並在這些系統之間進行跨系統的推理與操作。這正是傳統 BAS 整合中最困難、成本最高的部分。

多系統同時存取的架構

在 MCP 架構下，一個 AI 代理可以同時連接：

  • Siemens Desigo MCP Server——存取空調系統的運轉數據與控制點位
  • Schneider EcoStruxure MCP Server——存取電力監控與能源管理數據
  • Honeywell Niagara MCP Server——存取照明控制與安防系統數據
  • 氣象 API MCP Server——取得即時天氣預報與歷史氣象數據
  • 電力公司 API MCP Server——取得即時電價與需量反應訊號

AI 代理透過各 MCP Server 提供的 Resources 獲取數據，利用其語言理解能力自動解析不同命名慣例的語義（「CHW_Supply_Temp」與「CW_ST」代表相同的物理量），再透過 Tools 執行跨系統的協調操作。這種能力是傳統中間件所無法比擬的——傳統中間件依賴預先定義的映射規則，每新增一個設備都需要工程師手動配置；AI 代理則能透過上下文推理自動理解新數據點的含義。

跨系統最佳化的實例

假設一棟商辦大樓的 AI 代理同時連接了空調 BAS（Siemens）與電力監控（Schneider），它可以執行以下跨系統最佳化邏輯：

  1. 從氣象 MCP Server 獲知未來 4 小時的氣溫預報將持續上升至 35°C
  2. 從電力公司 MCP Server 接收到下午 2–4 點的尖峰電價訊號
  3. 從 Siemens MCP Server 讀取當前冰水系統的運轉負載與蓄冷槽容量
  4. 從 Schneider MCP Server 讀取各樓層的即時電力需量
  5. 綜合判斷後，透過 Siemens MCP Server 的 Tool 調高冰水機的目前出水溫度設定（在尖峰時段前預先蓄冷），同時透過 Schneider MCP Server 的 Tool 通知需量控制系統預留空調負載的調降空間

這類跨系統、跨廠牌的協調最佳化，在傳統架構下需要昂貴的系統整合工程與客製化開發；在 MCP 架構下，只要各系統提供標準化的 MCP Server，AI 代理即可自主完成。

六、AI 代理在建築工作中的實踐趨勢

AI 代理進入建築管理領域並非遙遠的未來。AutomatedBuildings.com 在 2026 年的專題報導中指出，AI 代理正從「輔助決策工具」轉變為「自主行動的建築運維夥伴」[8]。該報導描述了幾個關鍵趨勢：

  • 自然語言操作介面：設施管理者可以透過對話方式查詢建築系統狀態、下達操作指令，取代了傳統的圖控軟體操作
  • 預測性維護：AI 代理持續監控設備運轉數據，識別異常模式（如冰水機冷凝壓力異常升高），在故障發生前主動發出維護提醒
  • 自適應控制策略：AI 代理根據即時環境條件、使用者行為模式與能源市場訊號，動態調整空調運轉策略，而非依賴固定的排程與設定點

這些趨勢的共同基礎是 AI 代理對建築系統數據的廣泛存取能力——而這正是 MCP 架構所能提供的。

七、IT 與 OT 的融合：從隔離到整合

建築產業長期存在資訊技術（IT）與營運技術（OT）的分裂。IT 部門管理網路、伺服器與應用系統；OT 部門（通常歸屬於設施管理或工務部門）管理空調、電力、消防與安防等建築控制系統。兩個領域使用不同的通訊協定、不同的安全架構、不同的管理流程，形成深刻的組織與技術鴻溝。

MCP 作為 IT/OT 融合的橋樑

MCP 架構天然適合作為 IT/OT 融合的橋樑層。從 IT 側看，MCP 使用標準的 JSON-RPC 與 HTTP/SSE 傳輸——這是任何 IT 工程師都熟悉的技術棧。從 OT 側看，MCP Server 可以封裝各種 OT 協定（BACnet、Modbus、LonWorks、KNX）的通訊細節，將 OT 數據轉譯為 IT 世界可理解的標準化資源描述。

更重要的是，MCP 的安全模型與 OT 系統的安全需求相容。MCP Server 可以實施精細的存取控制——AI 代理可以讀取冰水機的運轉數據（Resources），但不被授權直接啟停冰水機（Tools 被設定為唯讀）。這種基於能力的存取控制（Capability-Based Access Control）符合 IEC 62443 工業控制系統安全標準的「最小權限」原則[9]。

邊緣運算與雲端的協作

在實際部署中，建築 OT 系統的 MCP Server 通常運行在本地的邊緣運算設備上，而非雲端。這確保了即使網際網路連線中斷，建築控制系統仍能正常運作。AI 代理可以部署在本地邊緣設備上執行即時控制邏輯，同時將歷史數據同步至雲端進行深度分析與模型訓練——形成「邊緣即時控制＋雲端長期最佳化」的雙層架構。

八、既有開放標準的互補：Project Haystack 與 Brick Schema

在探討 MCP 對建築自動化的潛在影響時，不能忽略兩個已在業界廣泛採用的語義標記框架——Project Haystack 與 Brick Schema。

Project Haystack

Project Haystack 是一個由建築 IoT 社群驅動的開放專案，自 2014 年以來持續發展，目前最新版本為 Haystack 4[6]。Haystack 定義了一套結構化的標籤（Tag）系統，用於描述建築設備、點位與它們之間的關係。例如，一個冰水機的出水溫度感測點可以標記為：

chilled, water, leaving, temp, sensor, point, equipRef:@chiller-01

這套標籤系統使不同廠牌、不同安裝的建築系統數據具有統一的語義描述，機器可以自動理解數據的物理意義與設備關聯。ASHRAE 已將 Haystack 4 的核心概念納入其 Standard 223P 的開發基礎[10]。

MCP 與 Haystack 的互補關係

MCP 與 Project Haystack 解決的是不同層次的問題，兩者具有高度的互補性：

  • Project Haystack：解決「語義層」問題——數據代表什麼意義、設備之間有什麼關係
  • MCP：解決「存取層」問題——如何以標準化方式連接異質系統、讀取數據與執行操作

在理想的架構中，MCP Server 暴露的 Resources 應遵循 Haystack 的語義標記規範。當 AI 代理從 Siemens Desigo MCP Server 獲取一個 Resource 時，其描述遵循 Haystack 標籤格式，AI 代理便能自動理解這個數據點的物理意義——無需預先為每個廠牌的命名慣例編寫映射規則。這種「MCP 提供通道，Haystack 提供語義」的分層架構，是目前看來最務實的整合路徑。

九、台灣建築自動化市場的機遇

台灣的建築自動化市場具有幾個獨特的特徵，使得 MCP 架構的導入具有特別的意義。

多廠牌並存的現況

台灣的大型商辦與廠房建築普遍存在多廠牌 BAS 並存的情況。公共工程採購法的最低價或最有利標制度，使得不同期的工程標案可能由不同的系統整合商得標，各自採用不同廠牌的控制系統。一棟 20 年以上的醫院或購物中心，內部同時運行三到四個廠牌的 BAS 並不罕見。

EEWH 綠建築與能源管理需求

台灣的 EEWH 綠建築標章制度要求建築物進行系統化的能源管理[11]。2024 年啟動的碳費制度更進一步要求企業進行碳盤查與減碳規劃。這些法規驅動力使得建築業主對跨系統能源數據整合的需求急速升高。然而，多廠牌 BAS 並存的現況使得能源數據的統一蒐集與分析成為實務上的巨大挑戰。MCP 架構提供了一條可能的突破路徑。

高雄地區的智慧建築發展

高雄市作為台灣南部的工業與商業中心，近年來在智慧建築與綠色能源轉型方面投入大量資源。從高雄展覽館、衛武營國家藝術文化中心，到亞灣區的新建商辦群，這些大型建築物的設施管理都面臨多系統整合的挑戰。對高雄地區的空調工程技師而言，理解 MCP 等新一代開放協定的技術架構與應用潛力，將成為提供進階空調系統設計與整合顧問服務的重要知識基礎。

十、未來展望：開放協定驅動的智慧建築管理

展望未來 5–10 年，建築自動化的技術架構將經歷一次深刻的典範轉移。這個轉移的方向是：從廠牌專屬的封閉系統，走向以開放協定為基礎、AI 代理為核心的智慧建築管理平台。

短期（1–3 年）：MCP Server 生態系統建立

各主要 BAS 廠牌或第三方開發者將逐步推出針對 BACnet、Modbus、LonWorks 等 OT 協定的 MCP Server。建築設施管理者可以在既有系統上疊加 MCP 介面層，讓 AI 代理存取多廠牌的建築數據。這個階段的重點是「讀取」——AI 代理作為智慧化的建築數據分析師，提供能源報表、異常偵測與維護建議。

中期（3–5 年）：AI 代理參與控制迴路

隨著 MCP Server 的 Tool 能力擴展至設備控制操作，以及 AI 代理在建築控制領域的可靠性經過充分驗證，AI 代理將開始參與部分控制迴路。例如：自動調整空調設定點、最佳化冰水機群組排程、協調需量反應。這個階段需要嚴謹的安全框架設計，確保 AI 代理的操作不會危及建築安全與舒適性[12]。

長期（5–10 年）：自主營運的智慧建築

最終願景是自主營運的智慧建築——AI 代理持續學習建築的使用模式、設備特性與環境條件，自主調整控制策略以最小化能源消耗、最大化使用者舒適度。建築不再需要固定的排程與設定點，而是由 AI 代理根據即時條件動態決策。在這個願景中，MCP（或其後繼的開放協定）作為通用的資料存取層，使 AI 代理能夠無縫連接建築內的所有系統，不受廠牌壁壘的限制。

結語

建築自動化的廠牌壁壘不是技術問題，而是商業模式問題——各廠牌透過封閉生態系統鎖定客戶、維持利潤。打破這個壁壘需要的不是又一個「更好的」專屬協定，而是一個足夠開放、足夠簡潔、且有足夠生態系統支撐的通用資料存取標準。Anthropic 的 MCP 協定雖然不是專為建築自動化設計，但其架構邏輯——讓 AI 以標準化方式連接異質系統——恰恰為建築產業提供了一個可借鏡的範式。

對空調工程技師而言，這個技術趨勢意味著專業能力的邊界正在擴展。未來的空調系統設計不僅需要考慮冷凍噸數、風管截面與管路水力計算，還需要思考系統的資料架構、通訊協定選擇與 AI 整合介面。從 BACnet 物件模型到 Haystack 語義標籤，從 MCP Server 的 Resource 定義到 AI 代理的控制邏輯——這是空調工程從「機電設計」走向「機電＋資訊」跨域整合的必然方向。

正在評估建築自動化系統的跨廠牌整合方案？技師チームにご相談ください，取得符合台灣在地市場的 BAS 整合策略建議。