前面幾篇講的是防禦節點怎麼把事件送進 BeakPlatform、平台怎麼把決策送回防火牆。這一篇換到平台這一側，講一件更根本的事：資安案件的處置流程是用「節點」拼出來的，而節點是可以自己加的。本篇用兩個真的做出來的節點當例子，並記下一個實驗：把開發指南直接交給 AI 程式助理當指令，看它能不能做出可用的節點、哪裡會做錯。主機沿用防禦節點那一套：主機 A（192.168.0.111）是 BeakPlatform。

先講結論。 一個節點由兩樣引擎認得的東西（資料庫裡的一筆定義、一支 Python 處理器）加十一樣配套組成，漏掉配套不會報錯、只會沒效果。把這 13 層與三個設計決定寫成文件後，AI 照著做出了兩個可用的節點，但人工反向檢查仍抓到三個測試全綠、真實環境會出事的問題。文件寫得到「AI 照著做會做出東西」的粒度，驗收卻不能只看它做了什麼。

一、為什麼需要自己加節點

平台的流程設計器出廠有 28 種節點：簽核、分支、延遲、Email、Telegram、寫入欄位、人事取值、OS 命令、防禦決策等等。資安案件走的「SOC 團隊版」「單人版」流程，就是這些節點接出來的。

認真用一陣子就會撞到兩個缺口：

這兩個缺口是一對的。補第一個不補第二個，流程就是半盲的：送得出去、收不回來。所以本篇的兩個範例是 HttpRequest（HTTP 呼叫）與 ExternalWait（等待外部回呼），接起來是完整的 webhook 往返：

HttpRequest（把回呼網址一起送出） → ExternalWait（停住，等對方打回來） → Branch（依回呼內容分路）

節點本身的用法在使用手冊裡，本篇不重複。本篇講的是一個節點由什麼組成、加一個節點要碰哪些地方、哪些地方漏掉會不報錯但沒效果，以及把這些寫成文件之後，AI 照著做會做到什麼程度。

二、一個節點是什麼

流程引擎只認兩樣東西：資料庫裡的一筆節點定義（設計器靠它畫出工具列、知道這個型別叫什麼、用哪個圖示），與一支 Python 的處理器（執行期靠它跑）。其餘都是讓人用得順的配套。但配套不是可選的：缺了面板，設計者填不了設定；缺了儲存時的收集，面板填了卻存回舊值；缺了種子匯出，你的機器有、別人全新安裝的機器沒有。

（圖01：一個節點在設計期與執行期各由誰負責，右側是加一個節點要碰的 13 層。設計期看到的是資料庫的「定義」與 JS 的「面板」，執行期用到的是 Python 的「處理器」，三者靠 node_type 這個字串對上。）

13 層列成表之後，最有用的不是表本身，而是一個找法：挑一個與你最像的既有節點，在整個原始碼目錄把它的型別名稱 grep 一遍。跑出來的每個檔案都問一次「我的節點要不要也出現在這裡」。這比任何清單都可靠，因為清單會過時，grep 不會。

三、動手前要先決定的三件事

這三個決定不是風格問題，選錯會留下靜默的錯誤。

四、第一個範例：HttpRequest

這顆節點讓流程呼叫任何 HTTP(S) API，把狀態碼、標頭、內容與 JSON 解析結果寫進流程變數。有了它，Slack、Teams、Discord 的 incoming webhook、工單系統建單、自家系統的 REST API，全都不必再各寫一個節點。它刻意不做成「webhook 節點」而是通用的 HTTP 呼叫，因為差別只在 body 範本，而 body 範本是設計者填的。

它的安全設計比功能本身重要，因為「讓流程設計者對任意網址發請求」就是教科書上的 SSRF。平台的做法：

這一版沒有秘密儲存。 標頭值寫在流程圖裡，能編輯流程的人都看得到。文件明說了這一點，並建議把長期金鑰放在 API 端只允許特定來源 IP 的設定上。這是刻意留下的邊界：秘密儲存牽涉另一套設定組與加密，不該混進「第一個節點」的範圍。

五、第二個範例：ExternalWait，以及「等」為什麼難

處理器回 waiting 之後，那個佇列項目進入 WAITING，不會有任何東西自動再碰它，除非符合執行器輪詢的某個條件：

不在任何條件內的 WAITING 節點就是死的：流程停住、不報錯、流程管理頁一切正常。平台歷史上一個叫 Converge 的節點就是這樣死掉後被刪除的。

ExternalWait 用的是最單純的組合：條件 A 加一個「推一下」的 API。進入等待時把 scheduled_at 設成逾時時刻；回呼端點收到合法回呼時先把內容寫進流程變數，再把 scheduled_at 改成現在；執行器下一輪就把它當成「時間到」撿起來重跑處理器，處理器看到變數裡已有回呼內容就完成。整個機制只多了兩個字串（名單兩處）與一支 API。

回呼網址從哪裡來

回呼網址要在 HttpRequest 送出時就存在，但那時 ExternalWait 還沒跑，沒有機會「發一個 token 存起來」。所以 token 不存資料庫，用可重算的 HMAC：以平台密鑰派生一把 key，對「流程實例代碼｜等待節點 id」簽章，取前 32 個十六進位字元。端點拿路徑裡的三段重算一次、常數時間比對。流程實例代碼本身不可猜，再加簽章，拿到網址的只有收到那一則 HttpRequest 的對方；簽章綁定實例與節點，同一流程裡兩個 ExternalWait 的網址互不相通。

設計者這一側只需要在 HttpRequest 的 body 寫 ${cb.node-Wait}，變數系統多了一個 cb. 前綴，解析成那顆等待節點在這個實例的回呼網址。

回呼比節點更早到

對方處理太快、或流程在兩顆節點之間還夾了別的節點，回呼可能在 ExternalWait 尚未進入等待時就到了。不處理這個 race，症狀是「偶爾卡死、不報錯」，很難重現。解法是端點永遠先寫變數，不管節點到了沒；處理器進入時永遠先查變數，有就直接完成、不等。這樣早到、準時、晚到走的是同一條路。

（圖02：webhook 往返的三條泳道。平台在對方處理期間完全不消耗資源，靠回呼端點把等待中的節點叫醒；回呼若比等待節點更早到，端點照樣寫變數，處理器進入時先查變數就直接完成。）

同一個等待只收一次：第二次打同一網址得到 409，逾時後打回來也是 409。回呼網址等同一次性密碼，不要寫進 log 與聊天工具。

六、文件就是 prompt：一個驗收實驗

兩個節點的開發指南寫在原始碼目錄的 docs/develop/，分兩篇：第一篇是 13 層、三個決定與 HttpRequest 的完整規格；第二篇是等待型節點、免登入端點的規則與 ExternalWait 的完整規格。寫的時候就決定了驗收方式：把指南原文交給 AI 程式助理當指令，它能據此做出可用的節點，指南才算寫對。 這比請人審閱嚴格，因為 AI 不會腦補，文件沒寫的它就會猜，猜錯就是文件的洞。

兩輪的結果：

兩輪都通過了「做得出可用節點」這個門檻，但通過不等於沒錯。人工反向檢查（對每個防線問「有沒有繞過它的直接寫法」）抓到三件 AI 做出來、測試也全綠、卻會在真實環境出事的問題：

這個實驗真正證明的事：文件寫到「AI 照著做會做出東西」的粒度是做得到的，而且比想像中便宜（兩篇指南各約 250 到 400 行）。但它不會取代反向檢查。AI 的自我檢查表會勾、測試會綠、端對端會過，三者加起來仍然漏掉一個會在升級後炸掉的 schema 問題與一個偶發的 race。驗收的工作不是確認「做了」，是去找「繞過它的寫法」。

七、讀者可以怎麼做

1. 在主機 A 的原始碼目錄讀 docs/develop/custom_node.md 與 custom_node_wait.md。兩篇都是公開文件，與本篇不同的是它們寫到可以照著做的粒度。
2. 先把兩個範例節點跑起來：示範資料裡有兩條流程（node展覽館 的 B17、B18），搭配原始碼附的 scripts/examples/http_mock_server.py，不需要任何外部服務。白名單出廠是空的，記得把測試伺服器的位址用 IP 寫法加進去（loopback 屬私有範圍，主機名寫法放不行）；ExternalWait 另需要先在主機設定填「系統對外網址」。
3. 想加自己的節點時，先回答第三節的三個問題，再 grep 一個最像的既有節點，照它的檔案集合逐一比對。
4. 如果你用 AI 寫程式，直接把指南全文當 prompt 餵進去，再加上你自己的本機事實（目錄、資料庫、怎麼重啟服務）。然後做反向檢查，不要只看它的回報。

八、沒做的事與邊界