2026 Linux 雲 VPS 部署多智能體流水線：LangGraph 編排 vs OpenClaw Gateway 執行面分工、systemd 常駐與分層排障 FAQ

上週我們協助一個團隊，把 多智能體流水線架構文 的 Supervisor + Worker 拓撲原封不動搬到 Linux VPS。白天壓測都過，晚上還能回 Slack；結果週末例行重啟後，症狀一次爆出來：通道事件還在進、回覆卻開始錯序，等待人工批准的任務全失憶，Cron 任務還把舊 checkpoint 當成新工單重跑。真正的問題不是模型智商，而是把 LangGraph 與 OpenClaw Gateway 綁在同一個臨時會話裡，等於把生產穩定性交給運氣。

我們後來在客戶現場反覆驗證的結論很一致：多智能體上線不是「多開幾個 Python」，而是兩層職責一定要切乾淨。LangGraph 管圖、狀態、checkpoint、並行邊與人機 interrupt；OpenClaw Gateway 管入口、排程、通道政策、長時間常駐與觀測。本文就是給 Linux VPS 落地用的實戰清單：決策矩陣、最小可重現拓撲、交接契約、systemd 片段與 L0-L3 排障順序。若你要先補 Gateway 長駐與日誌對照，可先看 OpenClaw Linux 常駐排障 FAQ；成本與 token 預算可搭配 Agent 成本帳單文 一起做治理。

為什麼 VPS 上一定要拆「編排」與「執行面」

在本機 Demo，你用一個 while True 就能串 Planner、Coder、Reviewer。到了 Linux VPS 面向真實使用者，現實壓力會同時出現：

• 入口型態很多：Slack 指令、私訊、Webhook、Cron 報表，若都寫進圖節點，入口規則會迅速失控。
• 狀態必須可持久：人工批准可能隔 6-8 小時才回來，重啟後若 checkpoint 遺失，流程就會斷鍊。
• 權限邊界要清楚：對外通道的 Gateway 不該握有高權限 MCP 金鑰，重工具權限應留在對應 Worker。
• 觀測域要能拆：TLS、Webhook 驗簽、403 屬於 Gateway；圖節點死循環、狀態合併衝突屬於 LangGraph，混在一起只會延長故障時間。

因此我們給團隊的基線是：LangGraph 僅開內網或回環埠，專注圖狀態與可恢復執行；OpenClaw Gateway 獨立常駐，負責把通道事件翻成結構化意圖，再以穩定 thread_id 觸發圖。這不是兩套系統重疊，而是工程責任分層。分層後你會發現：安全審查更好做、值班交接更明確、回滾範圍更可控。

拓撲決策矩陣：Linux VPS 常見三種形態

同一台 VPS 可以跑不同組合，選型關鍵看三件事：是否需要 7x24 通道、是否要持久化 interrupt、重工具放哪裡執行。

形態 A 是最容易起步、也最容易踩坑的型態。2 vCPU / 4 GB 的 VPS 能跑通，但前提是 checkpoint 寫進持久卷，不進 /tmp；且重工具不要與 Gateway 搶資源。形態 B 更適合要跑長時瀏覽器、編譯、索引大倉庫的團隊：Gateway 與圖維持輕量常駐，重活交給雲 Mac。形態 C 則適合流程簡單的團隊，不必為了「看起來先進」而過早引入圖編排複雜度。

LangGraph 對多智能體節點與 handoff 的建模可參考 Multi-agent 概念文件；OpenClaw 通道與網關配置見 Gateway 配置文件。兩份文檔合看，才能把責任邊界一次設對。

最小可重現拓撲（形態 A）

以下是我們在客戶環境最常落地的最短路徑，假設 VPS 已具備 TLS 與基礎反向代理：

1. LangGraph API：以 FastAPI 封裝，監聽 127.0.0.1:8123；checkpoint 落盤到持久目錄或外部資料庫。
2. OpenClaw Gateway：依 OpenClaw CLI 文件 安裝，入口綁內網，TLS 交給 Nginx/Caddy。
3. 橋接規則：通道事件先由 Gateway 正規化，再以固定 schema 呼叫圖執行端點，不讓自然語言直接決定系統行為。
4. systemd 雙單元：langgraph-api.service 與 openclaw.service 分開管理，設定 Restart=on-failure。

# /etc/systemd/system/langgraph-api.service
                [Unit]
                Description=LangGraph multi-agent API
                After=network-online.target

                [Service]
                User=deploy
                WorkingDirectory=/opt/langgraph-app
                Environment=CHECKPOINT_DIR=/var/lib/langgraph-checkpoints
                ExecStart=/opt/langgraph-app/.venv/bin/uvicorn main:app --host 127.0.0.1 --port 8123
                Restart=on-failure
                RestartSec=5

                [Install]
                WantedBy=multi-user.target

啟用服務後，請用 ss -lntp 檢查公開埠。理想狀態是只有反代對外提供 443，圖服務只留內部可達。這個步驟看似基本，卻能避免大量安全事故與誤暴露。當 ingress 與 orchestration 分離後，你也能在不停 Gateway 的情況下調整圖節點，或在不破壞 checkpoint 的前提下滾動更新入口。

節點交接契約：Gateway 到圖要交什麼

實務上最常翻車的是交接資料結構飄移。建議固定 schema 並做版本治理，禁止 Gateway 把整段聊天記錄不加約束丟給圖狀態：

• thread_id：穩定會話鍵，同一通道 thread 必須映射同一條狀態線，才能可靠 resume。
• intent：限定為 new_task / approve / cancel / status，不要讓 Planner 猜按鈕語意。
• payload：結構化任務上下文（repo、路徑、單條指令）；大檔案用物件儲存指標。
• caller_scope：通道與使用者範圍，供圖內二次授權；即使 Gateway 白名單已過，圖內仍要驗證。

LangGraph 的 Memory / checkpoint 模型 天生適合承載長流程世界狀態；Gateway 應保持可重啟、低狀態。若兩邊各自維護一份狀態機，最後就會出現分裂：通道顯示已完成，圖內卻仍在跑舊 worker，值班人員也很難判斷誰才是權威狀態。

L0-L3 分層排障：先分層，再動手

當使用者說「機器人沒反應」，請先按層次拆解，不要同時改兩邊設定。

L0：systemd 與埠口

先看 systemctl status openclaw langgraph-api 是否都為 active，再檢查監聽埠。若圖 API 掛了，Gateway 仍可能收到事件，表面像通道問題，實際是上游不可用。

L1：OpenClaw 通道與橋接日誌

用 openclaw logs 驗證事件是否到達、簽名與橋接 URL 是否正確。TLS、Webhook 403、重試風暴都屬於 L1，先在入口層處理。

L2：LangGraph trace 與 checkpoint

以同一 thread_id 查詢圖狀態，確認卡在哪個節點。若 checkpoint 權限或掛載錯誤，症狀通常是每次都像新會話；並行節點衝突則要檢查狀態合併與檔案鎖。

L3：跨機 Worker 與 MCP 邊界

形態 B 下重工具在外部主機執行。這層重點看網路可達、NO_PROXY、token 失效與遠端配額。Gateway 正常不代表 Worker 正常，別在 L3 問題上反覆重裝入口層。

上線前清單（30 分鐘自檢）

• LangGraph 僅監聽內網或回環；對外只暴露 Gateway。
• checkpoint 使用持久卷與備份策略，不放容器易失層。
• Gateway 到圖的超時小於通道重試窗，避免重複觸發。
• 每個節點工具白名單明確；Reviewer 不得有生產寫權。
• 演練 VPS 重啟：中斷後可 resume，Cron 不雙跑。
• 全鏈路 trace id 一路透傳，故障可一條線追到底。

FAQ