過去十年間，物聯(lián)網(wǎng)平臺行業(yè)經(jīng)歷了一輪完整的產(chǎn)業(yè)周期。早期階段，資本與技術(shù)熱情疊加，市場呈現(xiàn)“百家爭鳴”的格局——云廠商、設(shè)備商、工業(yè)企業(yè)、初創(chuàng)公司紛紛入局，打著“平臺化”的旗號爭奪入口。2019 年，IoT Analytics 發(fā)布的一項分析顯示，全球有 620 個物聯(lián)網(wǎng)平臺在運營，比 2017 年類似分析發(fā)現(xiàn)的數(shù)量多出 450 個，這也是物聯(lián)網(wǎng)平臺的高光時刻。
然而，火熱激情褪去后，行業(yè)進(jìn)入殘酷的整合期。部分平臺因商業(yè)模式不清、交付能力不足或資金鏈斷裂而退出；部分被大型企業(yè)收購整合；還有一些則收縮為垂直行業(yè)解決方案。2022 年是行業(yè)標(biāo)志性轉(zhuǎn)折年，彼時至少有谷歌、愛立信、SAP、IBM、博世等多個領(lǐng)域全球領(lǐng)先的企業(yè)對物聯(lián)網(wǎng)業(yè)務(wù)進(jìn)行大幅調(diào)整。自此，物聯(lián)網(wǎng)產(chǎn)業(yè)客戶逐漸意識到，“能接設(shè)備”不等于“能支撐業(yè)務(wù)”，平臺能力的深度、可擴展性和長期成本結(jié)構(gòu)開始成為核心考量。
如今，物聯(lián)網(wǎng)平臺市場已步入相對成熟階段。表面上看，主流廠商格局趨穩(wěn)，產(chǎn)品形態(tài)趨于標(biāo)準(zhǔn)化，技術(shù)架構(gòu)也更加云原生化、模塊化。但成熟并不意味著風(fēng)險消失。相反，在平臺能力日益復(fù)雜、客戶需求持續(xù)升級的背景下，選型錯誤所帶來的隱性成本和長期鎖定風(fēng)險，反而比早期更高。
也正是在這樣的產(chǎn)業(yè)背景下，圍繞“如何正確選擇物聯(lián)網(wǎng)平臺”的討論變得尤為重要。近日，IoTellect 首席產(chǎn)品市場專家 Igor Lenskii 發(fā)布了一篇文章，從實踐角度揭示了企業(yè)在平臺選型過程中最容易忽視、卻足以影響多年盈利能力的關(guān)鍵陷阱，筆者將對其中的精華內(nèi)容進(jìn)行分享：
陷阱一：你評估的，其實只是“做儀表盤的工具”，而不是平臺
在物聯(lián)網(wǎng)平臺選型過程中，這是最常見、也最容易被忽視的誤判——當(dāng)企業(yè)計劃部署物聯(lián)網(wǎng)平臺時，他會開始選擇、考核相應(yīng)的供應(yīng)商，然而，很多物聯(lián)網(wǎng)平臺廠商的演示往往從“看起來很完整”的界面開始：實時曲線、設(shè)備狀態(tài)、告警提示一應(yīng)俱全，數(shù)據(jù)通過 MQTT 流入后臺，幾分鐘內(nèi)就能搭出一個“可運行”的系統(tǒng)。這種體驗極具迷惑性，很容易讓人誤以為已經(jīng)找到了合適的平臺。但問題在于，這類系統(tǒng)本質(zhì)上只是“數(shù)據(jù)展示工具”的延伸——它解決的是“看數(shù)據(jù)”的問題，而不是“用數(shù)據(jù)驅(qū)動業(yè)務(wù)”的問題。
一個集成了 MQTT 服務(wù)器的儀表盤工具并非物聯(lián)網(wǎng)平臺；一個帶有 Web 界面的設(shè)備管理工具也不是；而最糟糕的情況可能是，將單一垂直領(lǐng)域的解決方案重新包裝成“通用”產(chǎn)品：乍一看似乎很有說服力，但當(dāng)你嘗試將其應(yīng)用到該領(lǐng)域之外時，就會發(fā)現(xiàn)它根本行不通。一個真正的物聯(lián)網(wǎng)平臺，不僅要能展示數(shù)據(jù)，更要能承載復(fù)雜業(yè)務(wù)邏輯、支持系統(tǒng)演進(jìn)，并在不同項目之間實現(xiàn)復(fù)用。
更隱蔽的風(fēng)險在于，這類“偽平臺”通常通過拼接實現(xiàn)：一個 MQTT Broker、一個時序數(shù)據(jù)庫、再加一個前端界面，就被包裝成“平臺方案”。在小規(guī)模試點階段，這種架構(gòu)或許足夠，但一旦進(jìn)入實際業(yè)務(wù)——涉及多協(xié)議接入、設(shè)備雙向控制、復(fù)雜告警聯(lián)動、跨系統(tǒng)集成時，問題就會迅速暴露。此時企業(yè)不得不不斷引入新的組件進(jìn)行補丁式擴展，系統(tǒng)復(fù)雜度和運維成本隨之失控。
從長期看，這種誤判的代價并不體現(xiàn)在初期投入，而是體現(xiàn)在后續(xù)每一個項目中：開發(fā)越來越依賴定制、功能難以復(fù)用、系統(tǒng)邊界不斷膨脹，最終侵蝕利潤空間。
因此，一個關(guān)鍵判斷標(biāo)準(zhǔn)是：你選擇的到底是一個“工具集合”，還是一個具備統(tǒng)一架構(gòu)與能力邊界的平臺。在評估其他任何內(nèi)容之前，請確保該平臺涵蓋絕對最低限度的功能：
多協(xié)議連接，尤其適用于工業(yè)物聯(lián)網(wǎng)場景（不僅限于 MQTT/HTTP）
雙向設(shè)備控制，而不僅僅是“數(shù)據(jù)攝取”
結(jié)構(gòu)化分層多層數(shù)據(jù)建模（不僅僅是“設(shè)備孿生”）
高級事件驅(qū)動處理（規(guī)則、操作、警報、關(guān)聯(lián)和根本原因分析）
原生可視化（網(wǎng)頁儀表盤、可打印報告）
通過 API 進(jìn)行外部系統(tǒng)集成
真正強大且靈活的安全模型（不僅限于 TLS+ 密碼）
如果缺少上述任何一項，那么這都不是企業(yè)級物聯(lián)網(wǎng)平臺。
陷阱二：“支持 MQTT 和 REST”不等于連接戰(zhàn)略
在很多物聯(lián)網(wǎng)平臺的宣傳中，“支持 MQTT 和 REST”幾乎成為標(biāo)配賣點，這也很容易讓人產(chǎn)生一種錯覺：連接問題已經(jīng)被徹底解決。但實際上，這只是一個“起點”，遠(yuǎn)遠(yuǎn)談不上完整的連接戰(zhàn)略。
在項目初期，這種能力通常足夠應(yīng)對需求——現(xiàn)代傳感器、智能設(shè)備大多原生支持 MQTT 或基于 HTTP 的接口，接入過程順暢、開發(fā)成本低，團隊也因此對平臺能力建立起信心。然而，一旦業(yè)務(wù)從“樣板項目”走向規(guī)模化落地，復(fù)雜性就迅速顯現(xiàn)。工業(yè)現(xiàn)場中的 PLC、Modbus、OPC UA，乃至大量仍在運行的串口設(shè)備，并不會主動“升級”到 MQTT 體系。此時，如果平臺缺乏對工業(yè)協(xié)議和異構(gòu)設(shè)備的支持，接入能力就會成為瓶頸。
即使你今天只開發(fā)一個解決方案，也要考慮未來，你的下一個客戶或行業(yè)幾乎肯定會帶來不支持 MQTT 的設(shè)備。更現(xiàn)實的問題在于成本結(jié)構(gòu)。如果每接入一種新設(shè)備，都需要額外采購協(xié)議網(wǎng)關(guān)，或依賴廠商提供定制開發(fā)服務(wù)，那么連接能力就從“技術(shù)問題”變成了“成本黑洞”。隨著項目數(shù)量增加，這種邊際成本會持續(xù)侵蝕利潤，甚至讓原本可復(fù)制的解決方案變成一次性工程。
因此，真正的連接戰(zhàn)略，應(yīng)當(dāng)具備更強的前瞻性和開放性：客戶真正需要的是涵蓋 IT 和 OT 的廣泛工業(yè)協(xié)議支持、可供自行使用的 SDK 或驅(qū)動程序框架，以及無需每次都聯(lián)系供應(yīng)商即可構(gòu)建自定義協(xié)議適配器的能力；網(wǎng)關(guān)和邊緣連接應(yīng)該是協(xié)議的一部分，而不是單獨出售的、需要額外付費的產(chǎn)品。
換句話說，“支持 MQTT 和 REST”只能說明平臺“能連接一部分設(shè)備”，而一個成熟的平臺，必須回答的是：當(dāng)設(shè)備類型不斷變化時，你是否還能持續(xù)、低成本地連接一切。
陷阱三：數(shù)據(jù)建模能力薄弱——隱形的利潤黑洞
數(shù)據(jù)建模的問題，在演示階段幾乎看不出來。但當(dāng)項目真正進(jìn)入交付階段，它就會成為最大的麻煩。很多平臺所謂的“設(shè)備孿生”或“數(shù)字孿生”，本質(zhì)上只是一個扁平結(jié)構(gòu)：每個設(shè)備一組屬性，加點元數(shù)據(jù)，做監(jiān)控大屏夠用，但做真正的解決方案遠(yuǎn)遠(yuǎn)不夠。
現(xiàn)實場景需要的是層級結(jié)構(gòu)，例如：
企業(yè) → 工廠 → 車間 → 產(chǎn)線 → 設(shè)備
建筑 → 樓層 → 區(qū)域 → 房間 → 傳感器
這些層級不僅是形式問題，它決定了：數(shù)據(jù)如何流轉(zhuǎn)？權(quán)限如何分配？告警如何傳遞？以及運維人員如何操作系統(tǒng)？企業(yè)在選擇物聯(lián)網(wǎng)平臺供應(yīng)商時必須問清楚：是否有統(tǒng)一、正式的平臺級數(shù)據(jù)模型？是否支持可視化構(gòu)建業(yè)務(wù)對象層級，而不是簡單設(shè)備列表？是否支持參數(shù)、操作、事件類型定義及對象間動態(tài)綁定？是否可跨項目復(fù)用？
一個簡單的測試方法：用平臺 Demo 去搭建你真實的資產(chǎn)結(jié)構(gòu)，而不是供應(yīng)商給的樣例。如果一天時間還搭不順，你已經(jīng)得到答案。
數(shù)據(jù)模型一旦薄弱，每個項目都會變成定制開發(fā)。本應(yīng)可配置的內(nèi)容被硬編碼，本應(yīng)可繼承的內(nèi)容被重復(fù)編寫，每個新客戶都會使問題成倍增加，而不是復(fù)用解決方案。這就是為什么系統(tǒng)集成商最終會在那些提案階段看起來有利可圖的項目上賠錢的原因。
陷阱四：只支持云部署，是一種被低估的戰(zhàn)略風(fēng)險
過去幾年，“云原生”幾乎成為物聯(lián)網(wǎng)平臺的標(biāo)配標(biāo)簽，不少廠商也順勢將架構(gòu)全面押注在公有云之上。從技術(shù)演進(jìn)角度看，這一方向并沒有問題——云計算在彈性擴展、資源調(diào)度和快速部署方面確實具備明顯優(yōu)勢。但問題在于，一旦從“云優(yōu)先”走向“只支持云”，風(fēng)險就開始顯現(xiàn)。
在實際產(chǎn)業(yè)環(huán)境中，尤其是工業(yè)、能源、電信和政府領(lǐng)域，大量客戶對數(shù)據(jù)部署位置有著嚴(yán)格要求。出于數(shù)據(jù)主權(quán)、合規(guī)審計或生產(chǎn)安全考慮，很多企業(yè)明確要求系統(tǒng)必須運行在本地數(shù)據(jù)中心或私有云環(huán)境中，核心數(shù)據(jù)不得出域。這并不是個別需求，而是大規(guī)模存在的現(xiàn)實約束。
如果平臺只能運行在廠商自有云或單一公有云上，就意味著企業(yè)在一開始就放棄了一部分客戶市場。同時，這也帶來更深層的“鎖定效應(yīng)”：數(shù)據(jù)、應(yīng)用和架構(gòu)全部依賴某一家云廠商，一旦未來需要遷移或調(diào)整部署策略，成本將非常高昂。
更值得警惕的是，一些廠商會承諾“未來支持本地部署”或“可以做私有化版本”，但從架構(gòu)上看，云到本地并不是簡單遷移，而是完全不同的設(shè)計問題。如果一開始沒有考慮多部署形態(tài)，后期補齊往往代價巨大，甚至難以實現(xiàn)。
因此，從選型角度看，真正穩(wěn)健的平臺，應(yīng)具備多種部署能力：既支持公有云，也支持私有云和本地部署，并能夠靈活構(gòu)建混合架構(gòu)，同時保持對云廠商的獨立性。這不僅是技術(shù)能力問題，更是企業(yè)在未來市場拓展與風(fēng)險控制上的戰(zhàn)略空間。
陷阱五：邊緣和云各是一套系統(tǒng)
在“邊云協(xié)同”成為主流敘事的當(dāng)下，幾乎所有物聯(lián)網(wǎng)平臺廠商都會強調(diào)自己具備完整的邊緣+云能力。但在實際落地中，一個被頻繁忽視的問題是：所謂的“邊云一體”，很可能只是兩套系統(tǒng)的拼接。
不少平臺的邊緣產(chǎn)品與云平臺并非同源架構(gòu)，而是基于不同代碼庫開發(fā)，甚至來自不同階段的產(chǎn)品或并購整合。它們通過 API 或數(shù)據(jù)同步機制“連接”在一起，在演示中看似協(xié)同順暢，但一旦進(jìn)入真實項目，就會暴露出明顯割裂：云端開發(fā)的功能無法直接下沉到邊緣，邊緣側(cè)的邏輯也難以回傳復(fù)用。
直接結(jié)果是，企業(yè)不得不維護(hù)兩套體系：一套面向云，一套面向邊緣。開發(fā)團隊需要掌握兩種技術(shù)棧，應(yīng)用邏輯需要分別實現(xiàn)，部署流程也被拆成兩條線。原本希望通過“邊云協(xié)同”提升效率，反而演變?yōu)橹貜?fù)開發(fā)和運維復(fù)雜度上升。更關(guān)鍵的是，這種架構(gòu)會直接影響解決方案的可復(fù)制性。每個項目都需要針對邊緣側(cè)進(jìn)行單獨適配，導(dǎo)致交付周期拉長，成本增加，規(guī)模化能力受限。
真正意義上的邊云一體，應(yīng)當(dāng)建立在統(tǒng)一架構(gòu)之上：同一套代碼庫、同一套開發(fā)工具，當(dāng)一個在云端設(shè)計的模型、儀表盤或告警規(guī)則無需修改即可部署到邊緣節(jié)點時，這才是真正的邊緣云兼容性。否則，每個項目都需要花費數(shù)月時間。
因此，在平臺選型時，一個簡單但關(guān)鍵的問題是：邊緣產(chǎn)品是否與云平臺共享同一技術(shù)底座。如果答案是否定的，那么所謂的“協(xié)同”，很可能只是表面現(xiàn)象。
寫在最后
平臺選型不僅僅是連接和部署問題——還要考慮供應(yīng)商的成熟度、人工智能就緒度（畢竟現(xiàn)在已經(jīng)是 2026 年了，MCP 服務(wù)器和開發(fā)代理也成了討論的話題）、安全架構(gòu)、價格透明度，以及一個令人不安的問題：如果供應(yīng)商倒閉了該怎么辦？
平臺一旦選定，往往會伴隨企業(yè)多年，其影響不僅體現(xiàn)在技術(shù)層面，更會延伸到成本結(jié)構(gòu)、交付效率乃至企業(yè)口碑。很多問題不會在初期暴露，而是在項目規(guī)模擴大之后，逐漸侵蝕利潤空間。因此，與其追求“功能看起來足夠”，不如回到一個更本質(zhì)的問題：這個平臺，是否真正支撐未來三到五年的業(yè)務(wù)發(fā)展。如果答案不夠確定，那么謹(jǐn)慎，往往比選擇更重要。
