AfterShip 如何用 AI Agent 重塑客服體驗？

你一定經歷過這樣的崩潰時刻：

點開客服對話框，結果機器人卻像復讀機一樣「請問有什么可以幫您」。

無論你怎么描述問題，它永遠只會甩給你幾篇 FAQ 鏈接。

最后，你不得不在「轉人工」按鈕上瘋狂點擊，然后在漫長的等待中懷疑人生。

但如果我告訴你，有一家公司把 AI 客服的問題解決率從 25% 提升到了 43%，并 讓它真正能像人類客服一樣能查系統、看截圖、主動追問、甚至還會主動幫你接入人工客服，你相信嗎？

這不是概念，而是 AfterShip 的算法和技術團隊最近完成的一次技術升級。

今天，我們就來揭秘這次客服系統升級背后的故事。

一、為什么要升級 ？當客服團隊被淹沒在重復的海洋里

作為全球領先的電商 SaaS 平臺，AfterShip 每個月要處理幾十萬條客戶咨詢。其中大部分都是重復性問題，比如：

「我的包裹到哪了？」「為什么物流狀態不更新？」「訂單怎么查不到？」

這些問題看似簡單，卻消耗了客服團隊的大量精力。

更致命的是，這些咨詢者很多并非 AfterShip 的直接客戶，而是「客戶的客戶」——使用 AfterShip 服務的電商平臺和品牌的 C 端用戶。

結果就是：

客服團隊的精力，被 C 端用戶的海量低價值問題分散，而真正需要深度服務的 Enterprise（企業級）客戶，反而得不到足夠關注。

傳統的解決做法是招更多客服，但這只會讓成本不斷飆升，并且治標不治本。

而上一代 AI 客服？只會查知識庫和機械式復讀的客服機器人，問題解決率僅有 25%。

于是，AfterShip 決定重新設計客服系統，迭代 Support 聊天機器人為客服 AI Agent，讓 AI 真正變成既能思考、也能執行的「數字員工」。

二、技術架構：讓 AI 既能思考，也會執行

2.1 無狀態設計：簡單，但更高效

大多數 AI 客服系統會在后端保存完整對話歷史，構建“記憶系統”。

但 AfterShip 選擇了另一條路——無狀態設計。

每次請求時，業務系統會將完整的歷史對話上下文傳入，Agent 處理后返回結果，自身不保留狀態。

這種看似“舍棄記憶”的做法，背后其實是深思熟慮的權衡：

• 對話記錄早已有存儲：業務數據庫和前端都已保存完整對話。
• 減少重復維護：Agent 側再建一套 Memory，不僅浪費資源，還帶來數據一致性風險。
• 系統更易擴展：任何調用方都能輕松接入，Agent 無需依賴上下文緩存。

只有在確實需要“長期記憶”時（如上下文摘要、Agent 學習記錄），系統才會啟用輕量級 Memory 模塊。

這讓維護成本降低約 80%，同時為未來的 Context Engineering（上下文工程）留出了空間。

2.2 模型選擇：平衡速度、可靠性與成本

選擇大模型就像選車：你不可能同時要速度快、性能好、還便宜。

AfterShip 技術團隊總結了 Agent 的「不可能三角」：

• 可靠性 (Reliability)：回答準確、工具調用穩定
• 速度 (Speed)：響應快、生成快
• 成本 (Cost)：API 調用費用低

經過大量測試，團隊總結了部分大模型的特點：

在 Support Agent 這個場景下，對 Agent 能力要求如下：

• 生成速度快：推理速度要快。在實時對話場景中，無法實現“打字機”效果，因此僅有較快的 TTFT（Time to First Token）無法提升用戶體驗，必須保證端到端（TTFT + TPS + Tool Calling）的快速輸出。
• 生成結果可靠：要求模型至少達到 Top-1 水平，能夠處理各種邊界情況，同時保證 Tool Calling 過程的穩定性。
• Context 容量較大：由于當前 Agent 的相關基建還在持續建設，很多 Context Engineering 的技巧還無法盡情施展。為了可以讓 Agent 能接收較多的 Context，LLM Context 容量也需要相對較大。
• 支持多模態輸入：用戶經常會上傳截圖詢問客服，少數會話甚至包含音頻、視頻。因此，所選模型必須具備多模態處理能力。
• 成本友好：模型的使用成本需與當前業務場景匹配。

綜合判斷下來，我們選擇 gemini-2.5-flash 作為常規模型。

當然，隨著接入工具增多、調用鏈路變復雜，2.5 Flash 未來可能需要升級到 Gemini 2.5 Pro，以應對更復雜場景。

2.3 工具體系：從「查答案」到「真干活」

這是本次升級的核心亮點。傳統 AI 客服只會查知識庫，而 AfterShip 的 Support Agent 擁有完整的內外部工具調用能力：

內部工具（提升對話質量）：

• 知識庫查詢（匹配 How-to 文檔、FAQ）
• 問題分類（自動打標簽）
• 智能判斷何時需要人類介入
• 對話摘要生成（轉人工時提供上下文）

外部工具（真正的干活能力）：

• Tracking Tool：當用戶問「為什么物流不更新」，AI 會自動調用接口刷新狀態
• Courier Tools：查詢快遞公司信息
• Order Tools：查詢訂單詳情
• Detect Tools：問題檢測與診斷

舉個實際案例：用戶：「我的包裹顯示已簽收，但我沒收到！」

傳統 AI：復讀 FAQ → 用戶崩潰 → 轉人工

AfterShip AI Agent 客服：

調用 Order Tool 查詢訂單號 ? 調用 Tracking Tool 查看物流詳情 ? 發現物流商數據異常 ? 調用 Refresh Tool 刷新狀態 ? 發現實際未簽收，向用戶解釋并提供追蹤鏈接 ? 如仍無法解決，生成問題摘要轉人工

這使得 AI 不再只是一個問答機器，而是真正能“動手”解決問題的數字同事。

2.4 協議層：AG-UI 協議的標準化和靈活性

為了讓前端、后端、不同業務模塊的 Agent 能高效協作，AfterShip 采用了 AG-UI（Agent UI）協議，這是一套標準化的 Agent 通信規范。

時序圖：

為什么要選擇標準協議？主要有三個考量：

一是解耦前后端：前端不需要關心后端用什么框架（LangChain、LangGraph 還是其他）。

二是能快速接入：任何遵循協議的客戶端都能直接調用 Agent。

三是全鏈可監控：每個事件節點都能追蹤，便于調試。

目前，Agent 之間的調用，也通過 A2A（Agent-to-Agent）協議 實現標準化互通，為多 Agent 協作奠定了基礎。

三、從細節出發：優化落地體驗

3.1 多模態理解：看懂用戶的截圖

過去，當用戶上傳截圖時，AI 只能機械回復「請描述您的問題」，體驗極差。現在，AfterShip 的 Agent 已能直接識別圖片內容。

例如，當用戶上傳一張「Error 403: Access Denied」的截圖時，系統會： 1?? 識別截圖文字； 2?? 判斷為權限問題； 3?? 查詢用戶賬戶狀態； 4?? 返回具體解決方案。

這種能力的背后，是多模態識別在客服場景的首次深度應用。它讓 AI 能“理解”用戶所見，減少了來回溝通。

3.2 主動追問：AI 學會了「反問」

早期版本中，如果用戶問題模糊（比如輸入「創建不了」），AI 通常會直接調用知識庫，結果往往答非所問。

升級后，AI 會主動追問：

• 「您具體是在創建什么時遇到問題？」
• 「方便提供截圖或錯誤信息嗎？」
• 「這個問題是從什么時候開始的？」

這種「追問能力」讓問題解決率提升了 15 個百分點。

3.3 防偷懶機制：讓 Agent 強制按規則執行

大語言模型有個「壞習慣」：在多輪對話中喜歡偷懶，不調用工具。

比如業務要求每條 Query 都要生成 Category 分類標簽，但測試發現 AI 在第 3、4 輪對話時，經常「忘記」調用分類工具。

為此，團隊增加了一個后處理層：系統會在每次 Agent 輸出后自動檢測是否調用了指定工具；如未調用，則強制補調。

這種「防偷懶機制」讓工具調用率保持在 100%，也體現了團隊對「AI 不可全信」的工程理解 ——關鍵邏輯，必須有護欄。

3.4 安全防護：從 MCP 漏洞中學到的教訓

在升級的前一天，安全團隊提前發現了一個由 MCP 引發的潛在漏洞：

攻擊者有可能可以通過精心設計的 Prompt，讓 AI 調用了 Tracking 查詢工具，獲取其他節點信的數據！

問題暴露后，團隊立即采取措施：

• 關閉存在風險的 MCP Server
• 推行 JWT 鑒權機制：所有工具調用必須帶用戶身份 Token
• 在工具層做二次校驗：拒絕任何異常參數請求。

這次事件讓團隊重新認識到：

再強的 Prompt 防護，都不如代碼級別的安全限制。

涉及用戶數據的調用，永遠需要“人類思維”來兜底。

四、效果與挑戰：43% 只是開始

AI 升級上線的第一個月，團隊重點關注了 4 個核心指標：問題解決率、延遲、工具調用、以及多模態支持。

4.1 數據說話

43% 并不是一個“炫目”的數字，但它意味著：

• 每月減少上萬次人工客服介入低價值問題
• 客服團隊可以專注 Enterprise 客戶
• 用戶平均等待時間從 15 分鐘降至 5 分鐘

這些變化的背后，不僅是模型的升級，更是架構與流程的整體優化。

4.2 剩下的 57%，為什么還解決不了？

團隊系統分析了所有轉人工的 Case，發現主要原因有：

這些數據讓團隊更清楚地看到下一步優化的方向：

• 擴展工具權限：讓 AI 能安全執行部分低風險操作（如查詢、修改基礎字段）。
• 情緒識別與優先轉接：識別憤怒語氣并自動安撫或轉人工。
• 用戶角色澄清：在界面明確提示「我是 AfterShip 客服，不是商家客服」。

4.3 技術瓶頸：Prompt 的盡頭是什么？

隨著系統復雜度提升，AfterShip 團隊也發現僅靠「調 Prompt」和「加記憶」難以持續提升。

目前的迭代過程是：收到 Bad Case → 人工分析 → 調整 Prompt → 上線測試

這個循環效率低、可遷移性差，也容易陷入“人工修補循環”。

于是我們開始探索一種新的方式：Agent 微調（Fine-tuning for Agents）。

傳統模型微調是調參數，但 Agent 微調是調 Memory：

• 收集 Good Case 和 Bad Case
• 讓 AI 學習「在場景 A 用方法 A 成功了」
• 讓 AI 學習「在場景 B 用方法 C 失敗了」
• AI 自動構建決策 Memory，下次遇到類似場景時調用最優策略

未來，Agent 還將具備「自我改進（Self-Improvement）」能力： 當系統檢測到用戶不滿意時，AI 會自動復盤并更新內部策略，下次遇到類似問題時嘗試不同解法。

目前，這套機制仍在測試階段，但它標志著 AfterShip 正在向真正的「可自我優化系統」邁進。

五、給開發者和企業的啟示：打造 Super Agent 的 4 條經驗

如果你也想構建類似的客服 AI Agent 系統，這里有 4 條血淚經驗：

1?? 選模型看場景，不要迷信「最強」

• 實時對話場景：速度 > 能力，選 Gemini Flash
• 復雜推理場景：能力 > 速度，選 Claude 或 GPT
• 成本敏感場景：優先開源模型 + 自建推理

2?? 無狀態設計是銀彈還是陷阱？

• 如果業務側已有完整存儲，Agent 就該無狀態
• 如果依賴上下文推理和多步任務 → 適度引入有狀態緩存或短期記憶；
• 錯誤做法：業務側和 Agent 側存兩份一樣的數據

3?? 安全是生命線

• 原則 1：涉及隱私數據的工具，必須后端二次校驗
• 原則 2：用 JWT 而非 API Key 做鑒權
• 原則 3：定期做滲透測試，別等安全團隊找上門

4?? 建立 Human-in-the-Loop 機制，讓 AI 和人類真正協作

• 讓客服團隊評估 AI 回答質量，按滿意度分級
• 收集 Bad Case 但不要只靠人工修復
• 終極目標：讓 AI 從 Bad Case 中自我學習

六、未來已來：Agent 時代的客服長什么樣？

AfterShip 的客服 Agent 升級只是開始。

可以預見未來 3 年內，Agent 會成為每個部門和職場人的標配：不只客服，銷售、財務、HR 都會有專屬 Agent。

隨著 Agent 能力以及 多 Agent 協作的不斷成熟，系統將逐步邁向 Zero Human Intervention —— 95% 的常規問題將實現完全自動化解決。

但無論 AI 多么強大，有一點始終是不會變的：

真正需要同理心、創造力和戰略決策的工作，依然屬于人類。

AI 的到來，不是為了取代人，而是來把我們從重復勞動中解放出來去做更有價值的事。

AfterShip 的這次升級，真正核心的地方，并不是 43% 的數字成果，而是團隊在每一個技術決策和落地上的克制與務實。

沒有追逐最“炫”的技術，而是選擇最合適的方案；沒有為了噱頭而堆功能，而是專注讓每次回答更準確一點。

這才是工程師文化的核心：注重細節，并用極客精神探索最合適的技術，解決最真實的問題。