使用Claude Code和MCP自動化一線客服支援

過去十週，我的Mac上每天清晨6點自動執行Claude Code，根據單一指令檔案執行任務。它透過MCP伺服器拉取流量、新的生產錯誤和執行時間，在我坐下來工作前將一份報告傳送到我的郵箱。迄今為止已成功執行67次——穩定可靠，正是目的所在。

本週，我將這一流程擴充套件到早間最耗時的任務：客服收件箱。首次執行處理了5個工單執行緒，在我的郵件客戶端中建立了3份回覆草稿，並正確跳過了2個。本文包含完整設定，包括指令檔案，以便您構建同樣的系統。其中沒有任何針對SiteSpeak的特定內容：任何配備MCP伺服器的支援工具都能工作。

收件箱為何成為手動環節

我們的AI聊天機器人已經處理了sitespeak.ai上的第一線問題，這部分自動化已執行多年。真正的手動工作是機器人升級的問題：錯誤報告、賬單諮詢和想與真人交談的潛在客戶。這些資訊都落入收件箱，每天早上我需要閱讀每條對話，判斷哪些“它壞了”是真的出了問題，然後撰寫回復。

數量從來不是問題——每天只有少量工單，單憑節省的時間不足以證明自動化的價值。問題在於一致性：正確的回覆需要檢查錯誤日誌、閱讀相關程式碼、核實文件後再作答。每天清晨，在所有其他事務之間，徹底完成每個工單，正是擁有合適工具的代理應該為您做的工作。

設定一覽

四個元件：

• Claude Code，按計劃無頭執行：透過launchd任務執行claude -p "/morning-report"（在Linux上可使用cron）
• 四個MCP伺服器：支援工具的收件箱、Sentry、Nightwatch以及我的郵件客戶端
• 一個Markdown技能檔案，描述工作流程、分類規則和硬性限制
• 一個JSON狀態檔案，記錄每個已處理的工單，確保執行冪等

沒有膠水程式碼，沒有API整合專案。代理依據指令檔案，將四個伺服器組合成一個小型代理工作流。這就是MCP的實際優勢：每個工具通常需要的整合工作消失了，“整合”變成了一份人類可以閱讀和編輯的文件。

執行的實際操作

根據技能檔案的逐步流程：

1. 透過支援工具的MCP伺服器列出開放收件箱工單，只保留上次執行後有活動的工單。狀態檔案過濾掉已處理的。
2. 讀取訪客自己的訊息（而非僅機器人回答）。對每個工單分類：緊急（現有客戶、故障、計費、要求轉人工）、潛在客戶（評估、定價、“能否做X”）或噪音（垃圾郵件、空會話、測試）。
3. 在草擬前進行調查。錯誤報告對照Sentry和Nightwatch匹配生產錯誤，並檢查倉庫中的相關程式碼。“如何做”類問題則核實線上文件。這一步的效果令我驚訝。
4. 先檢查郵件。在草擬前，代理搜尋過去30天內來自同一地址的現有郵件執行緒。人們常常在聊天機器人告知有人會跟進後，立即透過郵件聯絡支援。如果對話已在郵件中發生，則跳過該工單。
5. 在郵件客戶端中建立草稿。不允許傳送。每個草稿等待我審閱。
6. 歸檔工單，並將訪客ID、所採取的行動和原因記錄到狀態檔案中。跳過的工單也要記錄，否則下次執行會重新讀取相同的垃圾郵件。
7. 報告。支援部分與錯誤、流量和執行時間等資訊一同出現在同一封早間郵件中，每行對應一個工單，並附帶草稿連結。

整個執行有20分鐘超時，因此掛起不會阻塞第二天的執行。

兩條最重要的規則

以上都是基礎架構。技能檔案中的兩行規則才真正使輸出可信。

“永不猜測。草稿中的每個宣告必須在本會話中驗證，否則不得出現。”沒有這條規則，LLM會愉快地編造您不擁有的功能，以自信友好的語氣對付費客戶說。有了這條規則，一個宣告要麼在執行期間對照程式碼、文件或錯誤日誌進行了檢查，要麼就不出現。遵循此規則的草稿讀起來像是由真正調查過問題的人寫的——因為確實如此。

“絕不傳送。僅草稿。”技能的硬性限制部分完全禁止傳送工具。回覆到達客戶的唯一方式是我在郵件客戶端中點選傳送。這是最純粹的人機協作形式。這並非出於對可靠性的顧慮——大多數草稿未經編輯就直接發出。但偶爾需要人工編輯的草稿往往是發給不滿客戶的，而這種訊息一旦發出就無法撤回。

首次執行捕捉到的問題

最初48小時內，三件事讓我確信這一流程物有所值：

• 跨通道去重第一天就生效了。五個工單中有一個被跳過，因為訪客已透過郵件直接聯絡我們並得到了回覆。如果沒有“先檢查郵件”步驟，他們將從同一家公司收到第二份略有不同的回覆。這會讓您的支援顯得像機器人農場。
• 它標記了聊天機器人的錯誤。分類發現一段對話中機器人告訴客戶某個設定不存在。事實上該設定存在，只是位於不同的設定頁面。報告標註為“可能錯誤，需要當天人工回覆”。我本可能會直接跳過該工單，信任機器人的回答，因一句錯誤的話而失去客戶的信任。
• 潛在客戶不再等待。評估產品的客戶會收到創始人當天上午傳送的簡短個人郵件，其中已包含經過驗證的正確答案。此前，該工單會一直擱置到我有空處理，有時甚至要等好幾天。

誠實的侷限性

這是創始人級別的設定，而非企業支援管道。每天少量工單，由一人稽核所有內容。如果您深陷數百個工單的泥潭，僅草稿模式並不能消除瓶頸，您需要以不同方式看待它。

另外，代理無法接觸生產環境中的賬戶資料，這是有意為之。賬單類問題會生成草稿，表明問題已記錄並詢問人類所需的具體細節，而非對其無法檢視的賬戶狀態做出承諾。

而且，必須強制執行“驗證或省略”規則。請像對待新支援人員的入職說明一樣對待技能檔案：明確的規則、明確的護欄，並假設任何未寫下的內容最終都會出問題。

自行構建

經過清理的技能檔案、README以及launchd/cron示例配置已在開放倉庫中：github.com/sitespeakai/support-inbox-agent。將MCP伺服器名稱替換為您自己的工具，並根據與客戶溝通的方式編輯規則。

您需要：

• 一個代理CLI。我使用Claude Code。任何能載入MCP伺服器並遵循指令檔案的工具都可。
• 一個支援工具，帶有MCP伺服器。SiteSpeak提供了這樣的伺服器：可以列出收件箱工單、閱讀完整對話、拉取潛在客戶資訊以及歸檔工單。如果您使用SiteSpeak，最快的方式是透過我們的Claude Code外掛：/plugin marketplace add sitespeakai/sitespeak-claude-plugin，然後/plugin install sitespeak-chatbot-manager@sitespeak-plugins，並使用您的API令牌進行認證。
• 一個錯誤追蹤工具，帶有MCP伺服器（如果您需要調查步驟）。Sentry有官方MCP伺服器。
• 一個郵件客戶端或郵件API，帶有用於草稿的MCP伺服器。
• 一個排程器。macOS使用launchd，其他系統使用cron，並加上超時封裝。

從僅分類版本開始：分類和報告，不生成草稿。執行一週，閱讀它產生的內容。當您信任分類後再加入草稿功能，並永遠保持手動傳送。這個順序也是我構建它的方式：報告執行了十週後，我才讓它接觸客戶回覆。

常見問題

這需要SiteSpeak嗎？ 不需要。該技能適用於任何支援工具，只要其MCP伺服器能列出工單、閱讀對話、返回訪客郵箱並歸檔工單。SiteSpeak的MCP伺服器與技能示例工具名稱完全匹配，因此是零修改的路徑，但工作流程本身與工具無關。

代理能自動傳送郵件嗎？ 不能。技能的硬性限制部分完全禁止傳送工具，因此代理只能建立草稿。每個回覆都經過人工稽核和傳送。大多數草稿未經編輯直接發出，但偶爾需要修改的草稿往往是高風險的。

需要哪些MCP伺服器？ 兩個是必需的：支援工具的收件箱和能處理草稿的郵件客戶端。錯誤追蹤工具（如Sentry）是可選的，但它驅動了調查步驟——在代理寫字之前，將錯誤報告與真實生產環境問題進行匹配。

如果您還沒有處理第一線支援的聊天機器人，這部分比代理更重要。本文討論的收件箱之所以保持小而精，正是因為機器人回答了大多數問題，使其不會到達人工。您可以免費試用SiteSpeak，今天就在您的網站上執行第一線支援，包括MCP伺服器。