想讓 openclaw 更穩定，不如只讓 AI 做該做的事：從 AI agent skill 遷移到 n8n 自動化工作流
用嘴說說就能建出日報、情報蒐集這類自動化 skill，這是 AI Agent 平台最吸引人的地方。但跑了一段時間之後，LLM 不穩定、token 撐不住、換個模型又要重調——這篇記錄把一個 openclaw skill 遷移到 n8n 的過程與觀念。
AI Agent 的魅力
openclaw 這類 AI Agent 平台的核心概念很直觀：描述你要做什麼，系統幫你串接工具、呼叫 API、發送結果。
不需要從頭寫程式，一個「每天早上爬取資訊、整理成報表、推送到 Telegram」的 skill，下午就能跑起來。進階一點的——多個資料來源、條件篩選、多平台推送——同樣在描述清楚之後就能成形。「說清楚你要什麼，剩下的交給 AI」，確實讓自動化的門檻低了很多。
跑了一陣子之後
LLM 的輸出不穩定
LLM 的天性是「生成」，不是「執行」。同樣的 prompt，今天輸出的格式和明天的可能不一樣；資料少的時候排得整齊，資料多了開始偷懶——省略連結、發明「(略)」這種純文字，或是無聲無息漏掉幾筆。
這在 skill 裡特別難抓，因為每次執行看起來都成功了，但輸出的品質在悄悄飄移。
資料一多，token 就撐不住
早期 skill 每天只處理幾十筆資料，完全沒問題。但資料來源增加、歷史紀錄累積之後，整包丟給 LLM 的 prompt 開始逼近 context window 的上限。輕則回應變慢、費用暴增，重則直接截斷、輸出不完整。
這個問題通常不是從一開始就看得到的，幾個月後才炸。
換了 AI 模型，又要重新調整
AI 模型一升級或替換——從舊版換新版、從貴的換便宜的——輸出的格式和行為就跟著變。原本調好的 prompt，換了模型之後可能開始破格、多出不必要的說明文字，或是截斷在奇怪的地方。
然後就是一輪又一輪的重新調整 prompt，直到新模型的輸出再次穩定。穩定多久？等下次模型更新再說。
Telegram 的 Markdown 很脆弱
Telegram 的解析器很嚴格，訊息裡有未跳脫的底線、連結格式多了一個括號，整則訊息直接空白。而這些字元通常出自 LLM 的輸出，沒辦法完全控制。
切換成 HTML 模式（<b> 和 <a href="">）之後，格式完全由程式決定，這個問題就消失了。
把確定性的事交給程式碼
遷移到 n8n 之後，最核心的改變是：LLM 只做需要它的事，其他交給 Code 節點。
資料過濾、格式化、字串組合——這些有固定規則的事，用幾行 JavaScript 就能搞定，速度快、結果穩定、不花 API 費用。LLM 留下來處理真正需要理解和生成的部分。
Skill 的目錄結構，在 n8n 裡也能對應
openclaw 的 skill 通常有自己的目錄結構——腳本、設定、依賴套件各放各的。遷移到 n8n 時，這個結構可以直接在 n8n 的設定目錄裡對應過來。
程式碼部分頂多是從 .py 改成 Node.js 的 .js，邏輯本身不需要大改。這樣做的好處是：未來要再搬到其他平台，或在不同專案間複製這套流程，只需要把對應目錄整個帶走。
openclaw 很適合快速驗證想法。但如果一個 skill 要讓它每天自己穩定跑，n8n 的視覺化排程、錯誤重試、執行紀錄，是值得花時間遷移的理由。