LINE AI 客服底層邏輯解析：Webhook、Reply Token 與 6 大設計原則

這篇教學會拆解 LINE AI 客服的運作邏輯與 6 大設計原則，帶你搞懂 Webhook、Reply Token、Push API 等關鍵名詞。學會這些底層觀念後，未來不管用什麼工具或 AI 寫程式，你都能自己架設、維護並排除錯誤。

重點摘要

• 掌握 LINE 訊息傳遞的 6 大步驟與伺服器運作邏輯。
• 搞懂 Webhook 被動接收機制與 Channel Secret 驗證。
• 破解 Reply Token 30 秒限制，善用 Push API 處理超時訊息。
• 學會 3 種 AI 延遲應對策略與 6 大核心設計原則。

影片章節

1. 00:00 為什麼你需要了解 Line AI 運作邏輯？
2. 03:54 訊息傳遞的 4 大步驟流程
3. 06:47 Webhook 連結的作用與被動接收觀念
4. 07:38 Reply Token 是什麼？免費回覆額度怎麼算？
5. 08:51 Push API 是什麼？何時會用到主動推播？
6. 14:34 必備驗證：Channel Secret 與 Access Token
7. 17:05 AI 模型選擇與 Reply Token 30秒限制解法
8. 20:12 Line AI 客服的 6 大核心設計原則

為什麼你需要懂 LINE AI 客服的底層邏輯？

懂底層邏輯才能在系統出錯時自己抓漏，而不是只能依賴別人的模板或自動化平台。之前我教過大家用 Make 等自動化平台，或是拿我寫好的 GitHub 專案搭配 Netlify 與 Supabase 來架設 LINE AI 客服。這些方法雖然不用寫程式就能快速上線，但缺點很明顯：一旦平台功能更新、AI 模型改版，或是遇到未知的錯誤，整個客服就會當機，而多數人完全不知道該從何修起。

為了解決這個痛點，這次我會先帶大家釐清 LINE AI 客服的整體設計流程與核心邏輯。只要你搞懂這些觀念，下週我們就能直接請 AI 幫忙寫程式，親手打造出穩定且專屬的 LINE AI 客服。

LINE 訊息傳遞的 6 大步驟

一則訊息從使用者發出到 AI 回覆，總共會經過使用者、LINE 伺服器、你的伺服器與 AI 模型這 4 個角色的接力處理。具體的流動步驟如下：

1. 使用者發送訊息：使用者在自己的 LINE App 上打字並送出訊息。
2. LINE 伺服器接收：你的 LINE 官方帳號（也就是 LINE 的伺服器）收到這則訊息。
3. 推送到你的伺服器：LINE 官方帳號會透過你在後台設定的 Webhook 連結，將這包訊息資料推送到你自己架設的伺服器。
4. 呼叫 AI 模型：你的伺服器收到訊息並整理好後，會將問題（以及你設定的知識庫內容）發送給第三方的 AI 模型。
5. 回傳 Reply Token：AI 模型生成解答後回傳給你的伺服器，接著你的伺服器會拿著 LINE 附上的 Reply Token，將解答送回 LINE 伺服器。
6. 使用者收到回覆：LINE 伺服器將解答顯示在使用者的 LINE App 上。

在這個過程中，使用者端和 LINE 伺服器端我們不用管，我們真正要處理的是「自己的伺服器」以及「串接付費 AI 模型的 API」。

核心名詞解析：Webhook、Reply Token 與 Push API

要串接 LINE Message API，你必須先搞懂這三個用來接收與發送訊息的關鍵機制。很多人在設計流程時會卡關，通常是因為誤用了這三個功能。

Webhook：被動接收訊息的大門

Webhook 是一個生成在你伺服器上的網址，用來被動接收 LINE 推送過來的訊息。你必須將這個網址填入 LINE 官方帳號後台的 Message API 設定中。當使用者傳訊息給官方帳號時，LINE 就會主動「敲門」把訊息送到這個網址。請注意，這個網址必須是公開且具備 HTTPS 加密的，不能使用本機端的 localhost 網址。

Reply Token：30 秒效期的免費回覆金鑰

Reply Token 是當使用者傳訊息給你時，LINE 附上的一把「回覆鑰匙」。只要你使用 Reply Token 來回覆訊息，就不會消耗 LINE 官方帳號每個月 200 則的免費額度，無論你回覆幾次都一樣。但它有兩個致命限制：第一，它是一次性的，用過就失效；第二，它的有效期限只有 30 秒。如果你伺服器處理超過 30 秒，這把鑰匙就會作廢，訊息就傳不回去了。

Push API：主動推播訊息的付費管道

Push API 允許你透過程式主動發送訊息給使用者，前提是你要先取得對方的 User ID（例如透過過去的對話紀錄或 LINE 登入取得）。與 Reply Token 不同，使用 Push API 發送的每一則訊息都會消耗你每個月的免費額度，超過額度就需要付費。通常 Push API 會用在訂單通知、課程排程提醒、行銷推播，或是當 AI 處理時間超過 30 秒時的補救措施。

安全與驗證：Channel Secret 與 Access Token

在設計伺服器程式時，有兩把金鑰絕對不可或缺，它們分別負責驗證身分與保護伺服器安全。

• Channel Access Token（通行證）：這是你呼叫 LINE API 的身分證。無論你要用 Reply API 回覆、用 Push API 推播，或是傳送圖文選單，都必須在程式裡附上這把鑰匙，LINE 才會允許你執行動作。
• Channel Secret（防護罩）：這是用來驗證「訊息真的是從 LINE 官方傳來的」。如果你的 Webhook 網址沒有設定 Channel Secret 的簽章比對驗證，任何駭客都可以隨意傳送假訊息到你的伺服器，導致嚴重的資安漏洞。很多網路教學會忽略這一步，但這在實際應用中非常重要。

破解 Reply Token 30 秒限制的 3 種策略

因為 Reply Token 只有 30 秒的壽命，但 AI 生成內容有時會因為伺服器塞車而超時，我們必須在程式中設計應對策略來防呆。

1. 打字爭取時間（最佳解）：選擇回覆速度快且邏輯清晰的 AI 模型（例如 GPT-5 Nano 等輕量級模型），確保生成時間控制在 5 到 10 秒內，直接用 Reply Token 完美免費回覆。
2. 先回「思考中」再 Push：如果你的 AI 處理時間注定較長，可以在收到訊息時，先用 Reply Token 回覆一句「思考中，請稍候」，接著讓背景繼續運算。等 AI 算出答案後，再透過 Push API 主動推播給使用者。這雖然會消耗推播額度，但能避免使用者因為等太久而狂發重複訊息。
3. 非同步背景任務（高流量適用）：當瞬間湧入上千則訊息時，絕對不能讓伺服器同時呼叫 AI，否則一定會當機。這時要設計排隊機制，將訊息丟入背景佇列（Queue）依序處理，處理完再透過 Push API 回覆。

打造 LINE AI 客服的 6 大設計原則

總結來說，未來不管你是要自己寫程式，還是請 AI 幫忙寫程式，只要把這 6 個設計原則寫進提示詞裡，就能打造出穩定的系統：

1. 被動接收，不亂輪詢：Webhook 是被動等待 LINE 敲門的，不要設計成主動去抓資料。
2. 能 Reply 就 Reply：優先使用 Reply Token 在 30 秒內回覆，節省推播額度。
3. 用引導讓對話延續：利用圖文選單等介面引導使用者點擊發送文字，藉此不斷觸發新的 Reply Token。
4. 長任務拆成兩段：遇到需要長時間運算的任務，先 Reply 安撫使用者，算完再 Push。
5. 兩把鑰匙各司其職：Channel Secret 用來驗證來源防駭客，Access Token 用來授權發送訊息。
6. 每則訊息要有獨立 ID：記錄 LINE 傳來的訊息 ID，避免伺服器重試時發生重複回覆的災難。

掌握了這些底層邏輯後，下一篇 LINE AI 客服建置實戰教學 PART II！實戰製作篇，我就會帶大家實際運用這些原則，一步步把專屬的 AI 客服做出來！

本文整理自阿湯的 YouTube 影片〈LINE AI 客服建置實戰教學 PART I，設計概念基礎篇！〉，實際操作畫面請看影片；更多 AI 實用教學，歡迎訂閱 I'm 阿湯 YouTube 頻道。

常見問題