案例研究 · 客服自动化
该客服智能体耗费在工具定义上的上下文，多于工单本身。
某客服团队的 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 个，且该节省在每张工单的每一轮中反复兑现。
- 更省、更快的回复。 每次调用的输入令牌更少，意味着更低的账单与更快的首次响应，而智能体的触达范围毫发无损。
- 更稳健的多步骤处理。 上下文聚焦于工单而非工具箱，智能体得以在退款、账户查询与升级上报的全程保持思路连贯。
切换的当天，智能体便变得更快、更省，而我们并未移除任何一款工具。它只是不再把全部工具都塞进每一条消息。