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