在開發 Edge AI Application 的過程中，我曾經思考過一個問題：

既然我們已經有 AI Detection、Event、Alert、Recording 等功能，為什麼不直接使用 Node-RED，把這些流程串起來？

Node-RED 本身是一個很方便的 Flow-based Programming 工具，可以透過視覺化節點，把資料來源、條件判斷、API 與通知服務連接起來。

對於 IoT、設備整合與快速 PoC 來說，它確實能降低開發門檻。

但在評估 Edge AI Product 的架構時，我發現：

一個工具能夠做到某件事，不代表產品就一定需要它。

所以，這個階段我們選擇先不把 Node-RED 當成 Edge AI Application 的必要元件。

原因不是 Node-RED 做不到，而是我們必須先回答：導入它，究竟能解決什麼目前無法解決的問題？

一、我們的核心需求，是完成 AI 應用，而不是建立流程編輯器

先回到這個專案的起點。

我們希望在 Qualcomm QCS6490 上，完成一個可以實際運作的 Edge AI Application，讓系統能夠從影像中偵測人物、判斷場景條件，並進一步產生事件。

以四樓機房的巡檢 PoC 為例，我們實際驗證了六種情境：

• S1：入侵者開門進入機房
• S2：入侵者操作 Panel
• S3：入侵者操作配電盤
• S4：巡檢員未穿 Vest
• S5：巡檢員未戴 Helmet
• S6：正常巡檢

這些情境都有明確的需求與判斷條件。

例如，系統偵測到人物後，還需要根據指定區域、物件類別或其他條件，判斷是否符合預期的事件情境。

在這個階段，我們最需要解決的是：

1. AI Model 能不能在目標設備上運作？
2. Detection 結果能不能轉換成正確的事件？
3. 事件能不能觸發對應的應用行為？
4. 整個流程能不能在實際場域中驗證？

這些都是產品本身的核心能力。

如果目前的流程相對固定，而且主要由開發團隊負責設計與維護，直接在 Application 中實作，往往就足以滿足需求。

這時候額外加入 Node-RED，未必能帶來相對應的價值。

二、原因一：我們不需要為了固定流程，再增加一層編排

假設一個入侵偵測流程如下：

Camera / RTSP
      ↓
AI Detection
      ↓
Restricted Area Check
      ↓
Intrusion Event
      ↓
Alert + Recording

如果使用 Node-RED，可以把資料來源、條件判斷與後續動作配置成一組 Flow。

但如果這條流程已經由產品定義好，使用者只需要設定攝影機、管制區域與警示條件，那麼 Application 直接處理這些邏輯，可能會更簡單。

我們不需要為了串接固定的功能，再額外引入一套流程執行環境。

當然，如果未來需要讓客戶自行組合複雜流程，情況就不同了。Node-RED 的視覺化編排能力，可能會變成值得投資的功能。

是否需要流程引擎，取決於流程是否需要被使用者自由組合，而不是取決於系統裡有多少個功能。

三、原因二：Edge Device 的資源必須花在有價值的地方

這次的 PoC 使用 Qualcomm QCS6490。

在 Edge AI 的環境裡，我們不只要考慮 CPU 與記憶體，還要考慮影像解碼、Video Pipeline、NPU 推論，以及各個服務之間的資源競爭。

我們曾經觀察到，在特定測試條件下，NPU 使用率已經達到約 70～90%，而 Node-RED 的 CPU 使用率約為 20～30%。

但這裡必須說清楚：這些數字只是當時測試環境的觀察值，不能直接推論 Node-RED 就是效能瓶頸。

Node-RED 是否造成明顯負擔，仍然需要透過實際測試比較，例如導入前後的 CPU、記憶體、延遲與長時間運作情況。

所以，我不會單純因為它是額外的元件，就認定它一定不好；但也不會在沒有明確需求的情況下，先增加一個需要部署、設定與維護的執行環境。

對資源有限的 Edge Device 來說，每一個額外元件都應該有清楚的理由。

四、原因三：我們不想讓產品核心邏輯分散在不同地方

假設未來的 Edge AI Application 同時包含：

• AI Model 推論
• Geofence 與 Tripwire 判斷
• Event Trigger
• Alert
• Recording
• Event History

如果部分邏輯寫在 Application，部分放在 Node-RED Flow，還有部分寫在其他服務中，整體架構並非一定會出問題，但團隊需要更清楚地管理各個元件之間的責任。

例如，當入侵事件沒有觸發時，我們需要知道問題出在哪裡：

是 AI 沒有偵測到人？

是 Geofence 條件不成立？

是 Event 沒有建立？

還是 Node-RED Flow 沒有成功執行？

這些問題本來就需要良好的 Logging、Monitoring 與錯誤處理機制。引入 Node-RED 不代表一定會讓除錯更困難，但它確實增加了一個需要管理的執行環境與流程設定層。

因此，在第一版產品中，我們希望先建立清楚的模組分工，讓核心流程容易追蹤與測試。

例如：

AI Inference
      ↓
Rule Logic
      ↓
Event Service
      ↓
Action Handler
   ├─ Alert
   ├─ Recording
   └─ Upload

這些模組可以先放在同一個 Application 裡，不一定要拆成獨立服務，也不一定需要 Node-RED。

重點不是把架構拆得越細越好，而是讓每個模組的責任清楚、方便驗證，並且符合目前的開發規模。

五、原因四：我們目前不需要讓客戶自由編輯整個工作流程

Node-RED 最有吸引力的地方之一，是使用者可以透過視覺化介面組合流程。

但這個能力也意味著產品必須回答更多問題：

• 客戶可以修改哪些節點？
• 能不能直接執行自訂程式碼？
• 如何管理不同客戶的 Flow 版本？
• Flow 更新失敗時，如何回復？
• 如何避免錯誤設定造成告警中斷？
• 如何管理流程的權限與安全性？

這些並不是 Node-RED 的缺點，而是當我們把流程編輯能力交給客戶時，產品必須一起考慮的管理問題。

對目前的 PoC 來說，客戶主要需要設定的是 AI Scenario 的參數，而不是自行設計整套工作流程。

例如，選擇影像來源、設定管制區域、調整偵測條件，以及決定是否啟用錄影或警示。

這些需求可以先透過 Application 自己的設定介面完成。

等到未來客戶真的需要自行組合「事件發生後要做什麼」，再評估導入 Node-RED 或其他 Workflow Engine，會更符合產品發展的節奏。

六、不使用 Node-RED，不代表不需要 Event Engine

這裡有一個很重要的觀念需要釐清。

Node-RED、Event 與 Rule Engine 並不是同一件事。

• Event：代表系統判定發生了一件有意義的事情，例如未授權人員進入管制區。
• Rule Logic / Rule Engine：根據偵測結果與條件，決定是否產生事件。
• Node-RED：可以把事件、條件與後續動作編排成流程的工具。

我們完全可以不使用 Node-RED，但仍然保留 Rule Logic 與 Event 的設計。

例如：

Person Detection
      +
Restricted Area
      +
Business Rule
      ↓
Intrusion Event
      ↓
Alert / Recording / Upload

這裡真正重要的是事件如何定義、規則如何執行，以及後續動作如何處理。

至於這些邏輯應該由 Application 直接實作、由獨立的 Rule Engine 負責，還是透過 Node-RED 編排，就要看產品需求與系統複雜度。

甚至在第一版產品中，Rule Logic 與 Event Service 都可以先是 Application 內部的模組，沒有必要為了架構完整而先拆成多個服務。

七、什麼時候，我會重新考慮 Node-RED？

我並不認為 Edge AI Product 永遠不需要 Node-RED。

如果未來出現以下需求，我會重新評估：

第一，客戶需要自行設計工作流程。

例如客戶希望自行設定事件發生後要寄 Email、呼叫 REST API、寫入資料庫，或觸發其他設備動作。

第二，不同客戶需要大量不同的整合方式。

如果每次客製化都需要工程師修改程式、重新編譯與部署，視覺化流程編排可能有助於降低整合成本。

第三，產品要支援更多 IoT 與企業系統。

當需要串接 MQTT、HTTP API、資料庫、第三方服務或其他設備時，Node-RED 的節點生態系可能可以加速開發。

不過，這些需求也不代表一定要選 Node-RED。我們仍然需要比較自建 Workflow Engine、其他整合平台，以及 Node-RED 在安全性、維護成本與擴充性上的差異。

工具應該跟著需求進來，而不是讓需求跟著工具走。

這次的 Edge AI PoC，讓我重新思考了一件事：

在產品開發過程中，我們很容易因為某個工具很方便，就想把它加進架構裡。

但對只有一位 PM、一位工程師的小團隊來說，每多一個元件，就多了一份整合、部署、測試與維護的責任。

因此，現階段我們選擇先把重點放在 AI Detection、Rule Logic、Event 與 Application 的核心流程上，讓產品先具備完整、可驗證的功能。

未來如果客戶需要自由組合工作流程，我們再評估 Node-RED 是否值得加入。

我不是因為 Node-RED 不好才不用它，而是因為在目前的產品階段，我還沒有足夠的理由，讓它成為必要元件。

對我來說，這也是 AI PM 在架構決策中很重要的一件事：

不是證明我們能使用多少工具，而是知道什麼時候需要它，以及什麼時候不需要。