Пример внедрения · Автоматизация клиентской поддержки
Агент поддержки тратил на определения инструментов больше контекста, чем на само обращение.
ИИ-агент команды поддержки был подключён к десятку MCP-серверов и топил каждый промпт в схемах инструментов. Переход на Code Mode в onemcp вернул контекст к проблеме клиента и снизил стоимость и задержку каждого ответа.
- Отрасль
- Клиентская поддержка SaaS
- Команда
- команда поддержки около 15 человек
- Стек
- Zendesk · Stripe · Postgres · внутренний API заказов · Slack
# Кратко
- Накладные на инструменты за запрос снижены примерно на 90%
- Схема инструментов на вызов — с примерно 15 000 до около 500 токенов
- Снижение стоимости и задержки в каждом ответе
Иллюстративный сценарий по мотивам типичных внедрений onemcp. Команда является собирательным образом, а не названным клиентом; приведённые цифры носят представительный характер и не являются измеренными.
Предыстория
Команда поддержки SaaS построила ИИ-агента для сортировки и обработки обращений. Чтобы действительно работать, ему требовался широкий охват: Zendesk для обращения, Stripe для платежа, Postgres и внутренний API заказов для состояния учётной записи, Slack для эскалации. Каждый из этих сервисов был MCP-сервером, подключённым к агенту напрямую.
Агент был полезен с первого дня. Он же был медленным и дорогим — так, что команда не могла до конца это объяснить, пока не рассмотрела, что на самом деле содержится в каждом промпте.
Задача
Каждый MCP-сервер, к которому подключался агент, при каждом запросе вставлял в контекст полную схему своих инструментов. При десятке подключённых серверов это означало сотни определений инструментов и параметров, сопровождавших каждое обращение, — независимо от того, нужны ли они текущему обращению.
Цена проявлялась трояко:
- Растраченный контекст. Около 15 000 токенов инструментального шаблона предваряли реальный вопрос клиента в каждом промпте. В длинных цепочках определения вытесняли сам разговор.
- Более высокие счета и задержка. Эти входные токены оплачивались и обрабатывались на каждом шаге, умноженные на тысячи обращений в неделю.
- Больше простора для ошибок. Более крупный и зашумлённый промпт давал модели больше возможностей выбрать не тот инструмент или потерять нить в многошаговом обращении.
Подход
Команда поместила все серверы агента за единый портал onemcp и заставила агента общаться с ним через Code Mode.
Вместо предзагрузки каждого определения портал раскрывает три мета-инструмента:
search— найти инструменты, относящиеся к текущему обращению.describe— по запросу получить точную сигнатуру именно этих инструментов.execute— выполнить короткий скрипт, вызывающий их, за один цикл.
Так обращение о возврате средств загружает нужные ему инструменты Stripe и заказов — и ничего больше. Полный каталог по-прежнему доступен; он просто не втягивается в каждый промпт.
Результаты
- Примерно на 90% меньше накладных на инструменты за запрос. Схема инструментов на вызов снизилась примерно с 15 000 до около 500 токенов. Экономия повторяется на каждом шаге каждого обращения.
- Более дешёвые и быстрые ответы. Меньше входных токенов на вызов означало более низкий счёт и более быстрый первый ответ — при этом охват агента остался нетронутым.
- Более устойчивая многошаговая обработка. С контекстом, обращённым к обращению, а не к набору инструментов, агент удерживал нить на всём пути возвратов, поиска по учётным записям и эскалаций.
Агент стал быстрее и дешевле в тот же день, когда мы переключились, и мы не убрали ни одного инструмента. Он просто перестал таскать их все в каждое сообщение.