先看訊息長什麼樣子

看見的情況優先檢查要留下的證據
固定招呼＋Bot 答案內建回應與 Webhook 同時開啟兩則內容、回應設定
相同答案出現兩次事件重送、程式重試或重複工作事件 ID、執行與發送紀錄
兩段不同措辭回答同一問題AI 生成工作是否重跑生成工作 ID、草稿版本
隔一段時間又收到一次佇列重試、逾時後補送原事件與每次重試時間
真人接手後 Bot 還在回對話接手狀態未同步接手時間、回覆產生時間

第一種：內建自動回應與外部 Bot 都有回

LINE 官方建置說明確認，內建歡迎訊息、自動回應與 Messaging API 可以並用。開啟 Webhook 不會替你把其他回覆來源關掉。

同一句詢問，可能走進兩條回覆路徑

LINE 官方帳號後台

  1. 客戶傳訊息例如詢問營業時間
  2. 內建自動回應命中既有規則
  3. 固定答案從官方帳號送出

你的 AI 客服

  1. 同一則訊息產生 Webhook 事件
  2. AI 產生回答根據已核准的資料
  3. 另一則答案也從官方帳號送出
回覆來源圖解。兩條路徑都可能用同一官方帳號顯示，聊天畫面不容易分辨。

到 LINE Official Account Manager 檢查自動回應、關鍵字規則與歡迎訊息，安排誰負責哪種情況。例如保留加入好友的歡迎訊息，一般問答交給外部 Bot；若 Bot 也處理 follow 事件，就要避免再發一次相同招呼。

測試時每次只調整一項，用測試帳號傳一則容易辨認的訊息，觀察哪一則消失。若是營運中的帳號，先記錄原設定與恢復方式，再安排測試時段。

第二種：同一個 Webhook 被處理了兩次

網路中斷或接收端沒有正常回應，都可能讓事件再送一次。依 LINE 的 Webhook 說明，應使用 webhookEventId 辨識重複事件。deliveryContext.isRedelivery 是線索，但不能單獨代表「上次已經處理完」。

AI 已寫好的草稿，發送重試時不用再生成一版

第一次處理

  1. 事件 E-01 入列建立唯一生成工作
  2. AI 草稿完成保存草稿與版本
  3. 檢查並發送確認對話尚由 Bot 處理

推播暫時失敗

  1. 查原發送工作辨識同一事件與收件者
  2. 取出原草稿只有需改內容時才另行核准
  3. 依 API 規則重試支援的推播沿用 Retry Key

接收事件去重、生成工作去重與發送重試是三件事，要分別留下狀態。

AI 客服處理流程示例；事件編號為示意。Reply 與 Push 的重試限制不同，不能共用同一套假設。

只寫「先查 ID 有沒有，再新增」還有漏洞：兩個程序可能同時查到沒有，接著都開始做。實作要讓任務取得具有唯一性，例如資料庫唯一限制搭配交易；同時保留處理中、已完成、失敗及重試資訊。

也不要在還沒可靠保存事件前就回傳成功，否則後續工作失敗，可能失去補處理線索。接收、儲存、背景處理與對外發送需要各自有紀錄。

AI 回答不同，也可能是同一份工作重跑

傳統固定回覆重複時，兩則文字常常一模一樣。生成式 AI 可能每次寫出不同句子，所以不能只靠答案字面判斷。要把一次處理串起來看：LINE 的事件 ID、內部生成工作 ID、使用的知識版本、草稿版本，以及實際發送結果。

例如第一次已經生成草稿，只在推播時逾時，背景工作卻從第一步重新跑，模型就可能再回答一次。把生成結果保存下來，依工作狀態續做發送，會比遇錯就整條流程重跑更容易追查。

如果使用者真的又傳了一則訊息，即使文字相同，也可能是新的追問。這時要依新事件和對話脈絡處理，不能因為「今天回答過同樣文字」就全部擋掉。

AI 慢回時，先確認是哪一段等待

讀取知識庫、模型生成與工具執行都可能增加等待時間。LINE 官方建議非同步處理事件；實作上可先可靠保存工作，再由背景處理生成與發送，並另外處理等待提示。

等待提示可以用固定文字說明正在查詢，最後再送一份結果。如果結果還沒產生，就不要每次重試都重發提示。測試也要包含模型逾時、知識來源缺漏和發送失敗，觀察是否真的只產生預期的一份正式答案。

第三種：送出逾時後，程式又推播一次

發送端逾時，只能代表沒有及時拿到結果，不一定代表 LINE 沒有接受。若程式立刻再推播，就可能讓客戶收到兩次。

LINE 的 API 重試文件建議，支援的推播 API 從第一次請求就帶上 X-Line-Retry-Key，同一個發送工作的重試沿用相同 Key。這套機制適用官方列出的 Push、Multicast、Narrowcast 和 Broadcast，不適用 Reply API。每次重試換一個 Key，仍會被視為新的工作。

如果設計本來就是先回「已收到」，處理完再推播結果，兩則訊息是預期行為。此時要檢查它們是否各有目的，並把等待提示與最終結果寫清楚。

第四種：真人接手了，背景的 AI 回覆還沒停

對話轉人工時，除了更新畫面上的接手狀態，背景工作在真正發送前也要再檢查。AI 在接手前已經開始生成，幾秒後才完成的情況很常見；若只在工作開始時檢查，仍可能插話。

10:00:00　收到客戶問題，建立 AI 工作
10:00:01　AI 開始讀取資料與生成
10:00:03　客服接手，對話狀態改為人工處理
10:00:04　AI 草稿完成

發送前檢查：目前已由真人處理
處理結果：保留草稿供客服參考，不自動送出

以上是虛構時序。正式系統還要處理「檢查完狀態、正準備送出時，真人才接手」的競爭情況，安排清楚的發送鎖定或工作取消機制，並說明已發出的訊息無法靠停止背景工作收回。

團隊可以先定義 Bot、等候人工、人工處理及恢復 Bot 四種狀態，並指定誰能恢復。詳細流程可接著看 LINE AI 助理與真人接手。

提示詞能改善回答，發送控制要另外做

提示詞可以要求 AI 在資料不足時追問、保留來源，或把回答寫得簡短；它無法知道另一個伺服器上的工作是否已送出訊息。若發生重複發送，先查流程紀錄，再調整模型與回答內容。

需要核對客服草稿時，可要求 AI 輸出「回答草稿、引用資料、待人工確認項目」，由程式驗證後再顯示或發送。結構化輸出文件說明了固定格式的方式，但格式驗證不會替你完成事件去重、事實查核或發送授權。

常見問題

開啟 Webhook，就會自動停用 LINE 內建自動回應嗎？

不會。內建自動回應與 Messaging API 可以同時運作。需要到 LINE Official Account Manager 檢查回應設定，並決定每種情況由哪一條流程回覆。

收到 isRedelivery 為 true 的事件，可以直接丟掉嗎？

不建議一律丟掉。它可能是第一次真正成功進入你系統的事件。應以 webhookEventId 查詢處理狀態，區分未完成、處理中與已完成，再決定續做或略過。

X-Line-Retry-Key 可以解決所有重複回覆嗎？

不能。它用於官方列出的 Push、Multicast、Narrowcast 與 Broadcast API 重試，不適用 Reply API，也無法阻止內建自動回應與外部 Bot 同時送出不同訊息。

在提示詞寫「不要重複回覆」就有用嗎？

提示詞可以調整同一份答案的內容，無法阻止兩個背景工作各自生成或發送。要先用事件 ID、生成工作和發送紀錄管理唯一性，再確認真人接手狀態。

排查時請帶這些紀錄

兩則回覆內容與時間、回覆來源、事件 ID、重送標記，以及後端每次發送的結果就很有用。密鑰、完整權杖和客戶個資不用貼出來。如果訊息根本進不了 Bot，而是 Webhook 回 404，改看 Webhook 路由排查那一篇。

資料查核：2026 年 10 月 27 日。AI 工作與時間順序為實作示例；API 行為請對照上述官方文件。