使用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服務器。