案例研究 · 客服自動化
該客服代理耗費在工具定義上的情境，多於工單本身。
某客服團隊的 AI 代理接入了十餘個 MCP 伺服器，令每次提示都淹沒於工具結構描述之中。改用 onemcp 的 Code Mode 後，情境得以重新聚焦於客戶的問題，每次回覆的成本與延遲亦隨之下降。
- 產業
- SaaS 客戶支援
- 團隊
- 約 15 人的客服團隊
- 技術棧
- Zendesk · Stripe · Postgres · 內部訂單 API · Slack
# 概覽
- 每次請求的工具開銷降低約 90%
- 每次呼叫的工具結構描述從約 15,000 個權杖降至約 500 個
- 每次回覆的成本與延遲均有下降
本文為基於常見 onemcp 部署的示例情景。文中團隊係綜合虛構，並非具名客戶；相關數字為代表性示意，而非實測結果。
背景
某 SaaS 客服團隊建構了一款用於分流與解答工單的 AI 代理。為切實完成工作，它需要廣泛的觸達能力：以 Zendesk 處理工單，以 Stripe 查詢扣款，以 Postgres 與一款內部訂單 API 取得帳戶狀態，並以 Slack 進行升級呈報。上述各項均為 MCP 伺服器，直接接入該代理。
該代理自上線之日起便頗為實用，卻也在某種難以盡述的層面上既慢且貴——直至團隊審視每次提示中究竟包含了什麼。
挑戰
該代理所接入的每個 MCP 伺服器，都會於每次請求時將其完整的工具結構描述注入情境。在接入十餘個伺服器的情形下，這意味著數百份工具與參數定義隨每一張工單一同傳送——無論當前工單是否需要它們。
其代價體現於三處：
- 情境的浪費。 約 15,000 個權杖的工具樣板先於客戶的實際問題出現在每次提示中。在冗長的會話裡，定義甚至會擠占對話本身。
- 更高的費用與延遲。 這些輸入權杖於每一輪都被計費並處理，再乘以每週數千張工單，代價可觀。
- 更大的出錯餘地。 更龐大、更嘈雜的提示，給了模型更多選錯工具或在多步驟工單中迷失方向的機會。
方法
該團隊將代理的全部伺服器置於單一的 onemcp 入口之後，並令代理經由 Code Mode 與其通訊。
入口不再預先載入每一份定義，而是僅公開三個中繼工具：
search—— 找出與當前工單相關的工具。describe—— 按需拉取上述工具的確切簽章。execute—— 於一次往返中執行呼叫這些工具的簡短指令碼。
如此，一張退款工單只載入其所需的 Stripe 與訂單工具，別無其他。完整目錄依然可用——只是不再被拖入每一次提示。
結果
- 每次請求的工具開銷降低約 90%。 每次呼叫的工具結構描述從約 15,000 個權杖降至約 500 個，且該節省於每張工單的每一輪中反覆兌現。
- 更省、更快的回覆。 每次呼叫的輸入權杖更少，意味著更低的帳單與更快的首次回應，而代理的觸達範圍毫髮無損。
- 更穩健的多步驟處理。 情境聚焦於工單而非工具箱，代理得以在退款、帳戶查詢與升級呈報的全程保持思路連貫。
切換的當天，代理便變得更快、更省，而我們並未移除任何一款工具。它只是不再把全部工具都塞進每一條訊息。