把 LINE 變成 AI 員工：從自動回應到真的會查資料、完成預約的 AI Agent 實作

如果只是想讓 LINE 自動回答「營業時間」、「地址」、「預約連結」，其實不一定需要 AI。

LINE 官方帳號本身，就已經可以透過歡迎訊息、自動回應、關鍵字與圖文選單，處理很多固定型的需求。

真正開始變得麻煩，是當客人不再照我們事先設定好的方式說話。

例如同樣是在問星期六有沒有營業，客人可能會說：

• 星期六有開嗎？

• 禮拜六幾點關門？

• 我星期六下班後過去還來得及嗎？

這些問題的意思接近，但說法完全不同。

再進一步，如果客人問的是：

下星期三下午還有時間嗎？

這就不只是「理解問題」而已。

系統還必須知道目前真正有哪些時段已經被預約。

而當客人接著說：

那幫我約三點。

這時候，AI 就不只是回答問題，而是必須真的去操作系統、建立一筆預約。

這也是這次實作真正想測試的事情：

LINE 能不能從一個會回話的聊天介面，變成一個真的可以完成工作的 AI Agent？

---

先搞懂：LINE 自動回應、AI 問答、AI Agent 差在哪裡？

在開始實作前，我先把它分成三個層次。

1. LINE 官方帳號自動回應

第一層，是最傳統的自動回應。

例如設定：

營業時間
→ 週一至週五 09:00–18:00

或者：

預約
→ 回覆預約網站連結

這種方式沒有問題，而且如果需求本來就很固定，其實非常實用。

它的核心是：

符合規則，就回覆事先準備好的內容。

2. AI 問答

第二層，是把 Gemini、OpenAI、Claude 這類 AI 模型接進來。

這時候，使用者不需要輸入固定關鍵字。

他可以直接說：

我星期五下午下班之後過去還來得及嗎？

AI 可以理解這句話真正想問的是營業時間。

如果再接上 Knowledge Base、搜尋服務或公司內部資料，它還可以根據這些資訊回答更多問題。

但這一層的核心仍然是：

理解問題，然後回答問題。

3. AI Agent

第三層才是 AI Agent。

Agent 不只是想：

我要怎麼回答？

而是進一步判斷：

現在下一步應該做什麼？

例如：

客人：下星期五下午還有時間嗎？

Agent 判斷這是一個需要即時資料的問題。

所以它不是自己編一個答案，而是呼叫工具去查預約資料。

接著客人說：

那三點的好了。

Agent 還必須繼續收集姓名、聯絡方式等必要資訊。

等全部確認完成後，再呼叫另一個工具：

建立預約。

這就是「會回答」和「會做事」之間最重要的差別。

---

這次實作的情境：解憂雜貨舖

為了讓整個測試比較有故事感，這次我把預約系統設定成：

解憂雜貨舖

它是一間提供傾聽、陪伴與想法整理的預約制小店。

目前提供四種服務：

• 第一次解憂

• 心事解憂

• 選擇整理

• 再次來坐坐

可預約日為週一至週五。

每天固定有五個預約時段：

09:00–10:00
10:30–11:30
13:30–14:30
15:00–16:00
16:30–17:30

這裡我刻意使用「固定時段」，因為這樣可以很清楚測試一件事情：

AI 能不能尊重系統規則，而不是自己隨便產生一個不存在的時間。

例如客人說：

我想約下午兩點。

系統不能直接建立 14:00 的預約。

它必須先查詢當天真正可用的固定時段，再告訴客人：

13:30–14:30
15:00–16:00

哪些還可以選。

---

這套 LINE AI Agent 的完整架構

用文字說明這一整個架構的資料流，就會像下面這樣：

客人 LINE
↓
LINE Messaging API
↓
Webhook
↓
Vercel 後端
↓
Gemini
↓
Tools
↓
Supabase

另外，預約建立成功之後，系統還會再走另一條流程：

後端
↓
LINE Push
↓
老闆 LINE

這裡最重要的觀念是：

Gemini 並不是直接進 Supabase 查資料或寫資料。

Gemini 負責的是理解需求與判斷下一步。

真正讀取或修改資料庫的，仍然是我們自己的後端程式。

---

LINE 如何把訊息送到我們的程式？

當使用者傳訊息給 LINE 官方帳號時，LINE 並不會直接把訊息送給 Gemini。

第一步，會先進到 LINE Messaging API。

接著 LINE 會透過 Webhook，把事件送到我們指定的網址。

這次後端部署在 Vercel，所以流程大致是：

使用者傳訊息
↓
LINE 收到
↓
LINE 呼叫 Webhook
↓
Vercel 後端接收訊息

後端收到訊息之後，才會決定接下來要怎麼處理。

這裡也有一個很重要的安全步驟：

Webhook 不能看到有人打 API 就直接相信。

為了避免其他人假冒 LINE 呼叫這個 Webhook，LINE 每次送出訊息時，都會附上一個叫做 x-line-signature 的驗證簽章。後端再利用 Channel Secret 驗證這個簽章，確認這則訊息確實是由 LINE 傳來的。

---

先把 Gemini 接進 LINE，還不代表有 Agent

剛開始實作時，我先只把 Gemini 接進 LINE。

這個階段其實已經很好玩了。

例如問：

請用一句話鼓勵今天努力工作的我。

Gemini 可以正常回覆。

但如果問：

下星期三下午兩點還有空嗎？

它會回答目前無法查詢真正的預約狀態。

如果問：

你能查今天天氣嗎？

它也無法取得即時天氣。

原因很簡單。

這時候 Gemini 可以使用的資訊只有：

• 目前這一則 LINE 訊息

• System Instruction

• 模型本身原本學到的知識

它沒有：

• Supabase

• Google Search

• Knowledge Base

• 預約查詢工具

• 建立預約工具

所以即使它很會聊天，也還不是我們今天想做的 Agent。

---

真正讓 AI 開始會做事的關鍵：Tools

這次我只給 Gemini 兩個主要工具。

• Tool 1：checkAvailability

它的工作很單純：

查詢指定日期，目前還有哪些固定時段可以預約。

例如 Gemini 判斷客人在問：

星期五下午還有時間嗎？

它就可以要求後端執行：

checkAvailability({
  date: "2026-09-04"
})

後端收到之後，再去 Supabase 查詢真正的預約資料。

回傳結果可能是：

13:30–14:30
15:00–16:00
16:30–17:30

Gemini 再把這個結果整理成人可以看懂的 LINE 回覆。

• Tool 2：createBooking

這個 Tool 才是真正負責建立預約。

它需要的資料包含：

• 姓名

• 聯絡方式

• 服務項目

• 預約日期

• 固定時段

• 備註

但 Gemini 不能想呼叫就呼叫。

在真正建立預約以前，系統會先確認：

1. 資料是不是完整

2. 日期是否合法

3. 是否為週一至週五

4. 時段是不是系統允許的固定時段

5. 該時段現在是不是真的還有空

6. 使用者是不是已經明確確認

只有通過這些檢查後，才真正寫入 Supabase。

所以這裡的角色分工其實很清楚：

AI 負責理解與判斷。

Tool 與後端程式負責真正執行。

---

為什麼不能只靠 Gemini 記住對話？

預約通常不是一句話就能完成。

真實對話可能是：

客人：我想預約第一次解憂。

AI：想預約哪一天？

客人：星期五。

AI：星期五目前有這些時段……

客人：下午三點好了。

AI：請問姓名與聯絡方式？

客人：meimei，0912345678

這些資訊是一點一點收集的。

所以系統不能只依賴 Gemini 的聊天上下文。

這次另外在 Supabase 建立了 Conversation State，用來保存目前正在進行中的預約狀態。

例如：

pending_service
pending_date
pending_time_slot
pending_customer_name
pending_contact
pending_notes
booking_state

這樣即使對話分成很多輪，後端仍然知道：

現在已經收集了哪些資料，還缺哪些。

而且真正建立預約時，也會以這份 structured state 為準，而不是只相信 AI 畫面上說了什麼。這一點在實測時其實非常重要。

---

一定要有「最後確認」

當預約資料全部收集完成後，我沒有讓 AI 直接建立預約。

而是先整理一份摘要，例如：

服務：第一次解憂
日期：2026-09-04
時段：15:00–16:00
姓名：meimei
聯絡方式：0912345678
備註：無

接著再請使用者確認。

只有使用者明確說：

確認

或者：

都正確

這類確認語句時，才真的執行 createBooking()。

這個步驟很重要。

因為 AI 可以協助理解自然語言，但真正會改變系統狀態的動作，最好還是保留清楚的確認機制。

---

預約成功後，真的發生了什麼？

當 Tool 回報建立成功後，客人的 LINE 會收到：

• 預約成功訊息

• 預約編號

• 預約日期

• 預約時段

• 服務內容

但我不想只看 LINE 顯示「預約成功」就相信它。

所以實測時，我又檢查了兩個地方。

第一個是管理後台。

可以看到剛剛從 LINE 建立的預約，真的已經出現在後台。

第二個，是老闆 LINE。

因為原本這套預約系統就有：

建立預約後通知老闆

的功能。

所以當 LINE AI Agent 建立預約成功時，老闆自己的 LINE 也會即時收到。

所以客人整個過程看起來只是在 LINE 裡聊天。

但背後真正完成的是：

理解需求
↓
查詢資料
↓
收集預約資訊
↓
確認
↓
寫入資料庫
↓
通知老闆

---

再測一次：AI 有沒有真的重新查資料？

我另外做了一個測試。

第一次成功預約：

星期五
15:00–16:00

之後，再用 LINE 詢問同一天、同一個時段。

這時候 AI 不應該只是記得：

剛剛好像有人約過。

而是要重新呼叫 checkAvailability()，查詢目前最新的資料。

因為剛剛那筆預約已經真的寫進 Supabase，所以再次查詢時，這個時段就不應該再出現在可預約清單裡。

這也是我覺得 Agent 很重要的一個差別：

回答不是建立在 AI 的猜測，而是建立在系統目前真正的狀態。

---

Webhook 重送會不會重複建立預約？

LINE Webhook 有可能因為網路或其他原因重送事件。

如果沒有處理好，理論上就可能發生：

使用者只按一次確認，系統卻建立兩筆預約。

因此這次也另外做了 idempotency。

系統會記錄每一個：

webhookEventId

如果同一個事件再次送進來，系統不會重新執行 Agent，也不會再建立一次預約。

資料庫本身另外也有唯一性限制，用來防止相同時段同時產生兩筆有效預約。

所以安全性不是交給 Gemini 判斷：

「我覺得應該沒有重複。」

而是由後端與資料庫規則真正負責控制。

---

為什麼這次選 Gemini、Vercel、Supabase？

這次實作使用：

LINE
+
Vercel
+
Gemini
+
Tools
+
Supabase

但這套組合不是唯一答案。

如果把架構再拉高一層，其實真正需要的是：

LINE
↓
Web Server
↓
AI Model
↓
Tools
↓
Data / Systems

例如：

• Web Server

這次使用 Vercel。

但也可以換成其他能執行後端程式的環境。

• AI Model

這次使用 Gemini。

其中一個考量，是可以先從免費額度開始測試，對教學與小型實驗來說門檻比較低。

實際可用額度仍以 Google 當下 API 規則為準。

但架構上也可以換成：

• OpenAI

• Claude

• 其他支援 Tool Calling 的模型

• Data / Systems

這次因為是預約系統，所以後面接的是 Supabase。

但如果今天是客服問答，也可以接：

• Knowledge Base

• 公司文件

• 產品資料

• FAQ

• 搜尋服務

如果要處理實際工作，也可以串：

• 訂單 API

• 會員系統

• 庫存系統

• 客服系統

• 公司內部後台

所以真正重要的不是平台名稱。

而是先問三個問題：

使用者會在 LINE 裡提出什麼需求？

AI 需要哪些資料？

又需要哪些工具，才能真的把事情完成？

---

這套架構還可以拿來做什麼？

把 checkAvailability 和 createBooking 換掉之後，同樣的架構其實可以延伸很多情境。

例如：

• 訂單查詢 Agent

使用者：

我的訂單現在到哪裡了？

Tool：

getOrderStatus()

• 會員服務 Agent

使用者：

我的會員什麼時候到期？

Tool：

getMembershipStatus()

• 庫存查詢 Agent

使用者：

黑色 M 號還有貨嗎？

Tool：

checkInventory()

• 客服 Agent

使用者描述問題後：

createSupportTicket()

直接建立客服案件。

• 公司內部 AI 助理

同仁可以直接從 LINE 問：

• 目前有哪些待處理案件？

• 某位客戶目前的狀態？

• 今天有哪些重要行程？

• 幫我建立一筆工作紀錄。

真正的重點都不是「LINE Bot」。

而是：

LINE 只是入口。

AI 負責理解需求。

Tools 才是讓 AI 能真正碰到公司系統、完成工作的關鍵。

---

這次實作最重要的幾個觀念

最後整理一下這次實作，我覺得最值得記住的幾件事。

1. 把 AI 接進 LINE，不等於 Agent

如果模型只能聊天，它仍然只是 AI Chatbot。

2. Tool 才讓 AI 開始會做事

查詢資料、建立預約、建立訂單，這些真正會改變系統狀態的能力，都來自 Tool。

3. AI 不應該直接相信

日期、時段、服務內容、即時空位，都應該由後端重新驗證。

4. 重要資料要有 structured state

不能只依賴 AI 的對話記憶。

5. 真正重要的操作需要確認

像建立預約這種動作，在執行前最好讓使用者最後確認一次。

6. 資料庫才是真實狀態

AI 說「有空」不算。

Tool 查到真的有空，才算。

---

結語

這次從 LINE 官方帳號開始，一路把 Webhook、Gemini、Tools、Supabase 和原本的預約系統串在一起。

最後客人可以直接在 LINE 裡：

問服務
↓
查時段
↓
選擇預約
↓
提供資料
↓
確認
↓
完成預約

預約完成後，資料真的寫進系統，老闆也同時收到 LINE 通知。

所以這次真正做的，不只是：

把 Gemini 接到 LINE。

而是建立了一套：

讓 LINE 可以透過 AI 理解使用者需求，再去呼叫真正系統功能的 Agent 架構。

會回答問題，只是 AI 的開始。

當它開始能查資料、呼叫工具，甚至真的完成一件事情，它才真正開始像是一個 AI 員工。

---