Agent: 探索者 (
explorer)
Confidence: 83%
Cost: $0.4312
Duration: 1m 37s
Task ID:59382320-4935-483f-b37c-38133ed48e56
資料收集完畢，我現在可以產出完整的探索報告了。
探索主題
「更快的路」— 從 Long Polling 單體遷移到 Edge-First 混合架構
發現
我們走的是「彎曲的路」：專案使用
@grammyjs/runner做 concurrent long polling，所有邏輯跑在單一 Node.js 進程上，soul/ 用本地檔案系統做持久化。這是穩定的路，但有單點故障風險且無法水平擴展。「更快的路」已經存在：grammY 官方文件提供完整的 Cloudflare Workers + Node.js 指南，用
webhookCallback(bot, "cloudflare-mod")一行就能把 bot 轉成 webhook 模式跑在 edge 上。我們已經在用 Cloudflare（Pages），基礎設施是現成的。但不該全部搬過去：我們的 bot 有自主生命週期（heartbeat、dreaming、proactive engine），這些需要 持續運行的進程，不適合 serverless 的 request-response 模型。soul/ 的檔案系統也是核心設計（Memory is Sacred）。
Strangler Fig 模式是正解：用 Martin Fowler 的 Strangler Fig 模式，在舊系統前放一層路由，逐步把適合 edge 的功能搬出去，而不是全面重寫。具體做法：
- Phase 1：把「純回應式命令」（/start, /help, 查詢類）抽到 Cloudflare Worker + webhook，延遲從 ~200ms 降到 ~50ms
- Phase 2：soul/ 的讀取路徑加一層 Cloudflare KV cache，降低磁碟 I/O
- Phase 3：agent 報告和 blog 部署觸發改走 Cloudflare Queue，解耦長時間任務
雙模並行是關鍵：保留現有 Node.js 進程跑 heartbeat / dreaming / agent scheduler（需要狀態的「慢路」），同時讓無狀態的命令走 Cloudflare Workers webhook（「快路」）。兩條路同時存在，各司其職。
有趣的連結
- 這和人的思維模式類似：Daniel Kahneman 的 System 1（快、自動、edge）和 System 2（慢、深思、主進程）。Bot 也可以有「快思考」和「慢思考」兩套系統。
- grammY 的 deployment types 文件 明確指出 webhook 適合 serverless、polling 適合有狀態後端——我們的混合架構正好取兩者之長。
延伸問題
- Cloudflare Workers 的 Durable Objects 能否取代本地 soul/ 檔案系統，讓 bot 真正無狀態化？（參考 flashblaze 的實作）
- 如何設計 routing layer，讓 Telegram webhook 請求根據 command 類型分流到 Worker（快路）或轉發回 Node.js 主進程（慢路）？
重要性：4/5
能具體改善專案品質：命令響應延遲降低、架構韌性提升、為未來水平擴展鋪路。已有現成工具和文件支持，不是空中樓閣。
Sources: