HI！大家好，我是 Shammi 😊

終於來到 Day 22 了！回顧這段時間，我分別在 Colab 環境下挑戰了 LINE 機器人（使用 Webhook 模式）和 Telegram 機器人（最終採用長輪詢模式）。這兩段旅程，雖然目標都是讓 AI 機器人動起來，但實際的開發經驗和遇到的「地雷」卻是天差地別！

今天，我要來個大總結，好好比較一下這兩個平台的開發心得，聊聊那些技術挑戰和我是怎麼克服的！

🌐 LINE 機器人開發經驗：Webhook 模式的愛恨交織

LINE 機器人是我們最早接觸的平台，它從一開始就預設要用 Webhook 來接收訊息。

👉 開發流程回顧：

1. 在 LINE Developers 後台設定機器人，取得金鑰。
2. 在 Colab 裡架設 Flask 網頁伺服器。
3. 透過 ngrok 隧道，把 Colab 裡面的 Flask 伺服器公開到網際網路。
4. 把 ngrok 產生的 URL 貼回 LINE Developers 當作 Webhook URL。
5. 然後再寫程式碼處理 LINE 傳來的 Webhook 請求。

👉 心得：Webhook 的優點（在 Colab 環境下的感受）

• 即時回應： 一旦設定成功，LINE 的訊息幾乎是秒回，沒有什麼延遲。這感覺真的很棒，像機器人真的活著一樣！
• 專業感： 畢竟 Webhook 是業界主流，學會了感覺就像是跟真實的生產環境接軌，比較有成就感。

👉 心得：Webhook 的「踩雷」經驗（在 Colab 環境下的痛點）

• 複雜的環境設定：不得不說， 我在 Flask 和 ngrok 的搭配一開始困難重重，因為要確認語言模型回覆的正不正確，但常常遇到埠號被佔用（Address already in use）或是ngrok 連接不穩定、隧道意外斷線等問題，雖然這些都是家常便飯的問題，所以每次重啟都要提心吊膽的想「今天又會遇到什麼挑戰呢？」。
• 多執行緒與異步的「戰爭」： 在 Colab 這個單一的 Python 環境中，要同時運行 Flask 的 Web 伺服器和 LINE Bot SDK 的內部處理邏輯，常常會碰到 RuntimeError: This event loop is already running 這種錯誤。這表示 Python 裡面的「大腦」不知道該聽誰的指令，程式直接崩潰！為了處理這些，我得不斷地重啟 Colab 執行階段，非常耗時間的。
• 除錯困難： 錯誤訊息可能來自 Flask、ngrok 或是 LINE Bot SDK 內部，要追蹤問題的源頭真的像大海撈針，常常不知道該從哪裡下手。

🌐 Telegram 機器人開發經驗：從 Webhook 掙扎到長輪詢的救贖

Telegram 機器人一開始我也想挑戰 Webhook，但很快我就「投降」了，轉向了長輪詢 (Polling) 模式。

👉 開發流程回顧（長輪詢模式）：

1. 透過 BotFather 建立機器人，取得金鑰。
2. 直接使用 python-telegram-bot 函式庫的 Application.run_polling() 功能。
3. 程式碼在 Colab 中直接運行，週期性地向 Telegram 伺服器查詢是否有新訊息。

👉 心得：長輪詢的優點（在 Colab 環境下的感受）

• 簡潔穩定： 這是最大的優點！程式碼裡面沒有 Flask、沒有 ngrok，也不用煩惱那些複雜的 Webhook 路由。機器人直接跟 Telegram 對話，整個流程變得超級簡單，而且運行起來超穩定，幾乎不當機！
• 除錯方便： 所有的錯誤都直接在 Colab 的輸出視窗中顯示，不用猜測是網路問題還是伺服器問題，除錯效率大幅提升！這對我這種參賽者來說，簡直是福音！
• Colab 友好： 這種模式最適合 Colab 環境了，雖然 Colab 本身有執行時間限制，但至少在運行期間，機器人可以非常可靠地運作。

👉 心得：長輪詢的缺點（可接受的妥協）

• 輕微延遲： 因為機器人是每隔幾秒才去問一次，所以回覆訊息會比 Webhook 模式稍微慢一點點。
• 非生產級： 這種模式通常不適用於大規模、高併發的生產環境，但對我的參賽專案來說，完全足夠了！
• Colab 斷線問題： Colab 執行階段一旦中斷（例如閒置），機器人就會停止，在換24/7的環境前，這問題是無法避免的。

🌐 踩雷心得總結：技術挑戰與解決方案

綜合這兩個平台的開發經驗，我學到了幾個關鍵的技術教訓和解決方案：

1️⃣ Colab 的部署策略：『單一模式，穩定優先』

• 在 Colab 這種雲端筆記本環境，長輪詢模式才是王道。它避免了 Webhook 模式下，Flask 伺服器、ngrok 隧道以及 Python 異步事件循環之間複雜的衝突。
• 解決方案： 果斷放棄在 Colab 中執著於 Webhook，轉向簡潔的 run_polling()。

2️⃣ 事件循環衝突：asyncio 的魔法

• RuntimeError: This event loop is already running 這個錯誤真的讓我很頭痛。它發生在我嘗試在已經運行 Flask 事件循環的環境中，再啟動 Telegram Bot 的輪詢循環時。
• 解決方案： 對於長輪詢模式，python-telegram-bot 函式庫本身會處理其異步邏輯。而在 Webhook 模式下（如果真的要挑戰），則需要小心處理 Flask 的同步特性和 Telegram SDK 的異步功能，可能需要 nest_asyncio 或是更進階的異步設計模式。但我的最終經驗是，直接用輪詢最省心。

3️⃣ 知識庫管理：一次準備，多平台共用！

• 我的 RAG 系統需要 sdgs_faiss.index 和 stored_chunks.pkl 這兩個知識庫檔案。
• 解決方案： 我發現這些知識庫檔案只需要生成一次。無論是 LINE 還是 Telegram 機器人，只要確保這些檔案存在於 Colab 環境中（例如在 Colab 的檔案系統裡），它們就可以直接被載入和共用，不需要每個機器人筆記本都重新生成一次。這大大節省了時間，也簡化了部署流程。

4️⃣ Colab 執行階段管理：『重啟大法』是萬靈丹！

• 埠號被佔用、程式碼莫名其妙當掉，這些都可能是 Colab 執行階段不乾淨導致的。
• 解決方案： 每次切換機器人、或是遇到奇怪的問題時，都無腦地使用 Colab 的「執行階段」->「重新啟動並執行所有項目」。這招真的超有用，它能徹底清空當前環境，確保每次都是從一個乾淨的狀態開始，但也為此寫了一段可清空的程式碼。

總結

這次的跨平台機器人開發經驗，讓我學到了最重要的就是：選擇適合的工具和策略，遠比硬著頭皮跟環境過不去重要！ 在 Colab 這種限制較多的環境下，長輪詢模式讓我成功地讓機器人擁有「智慧回應」的能力，這已經是一個巨大的勝利了。

雖然 LINE 和 Telegram 有各自的部署特性，但它們都成功地讓我整合了 RAG 知識庫。這讓我對 AI 機器人的潛力更有信心了！這次的學習，不僅完成了專案，更讓我對實際開發中可能遇到的挑戰，有了更深、更實務的理解。