Токен-оптимизация агентов: на что уходит контекстное окно MCP

Чем больше задач берёт на себя агент, тем чаще он упирается не в качество модели, а в контекстное окно: туда нужно уместить инструкции, историю диалога, схемы инструментов и всё, что эти инструменты возвращают. Я считаю, что токен-оптимизация агентов — то, как мы расходуем это окно — станет одним из ключевых направлений ближайших лет, наравне с выбором модели и качеством промпта.

Разберём конкретный пример — обратимся к цифре, которую обычно приводят в статьях об оптимизации работы с MCP. В них GitHub MCP оценивают в районе 42 000–55 000 токенов на ~93 определения инструментов — около четверти контекстного окна Claude ещё до первого запроса. Цифра разошлась широко, однако у неё две проблемы. Во-первых, она не воспроизводима: не указаны ни токенизатор, ни охват измерения (только схемы или ещё инструкции сервера?), ни версия сервера, а разбивки по инструментам авторы таких оценок и сами помечают как «illustrative, not precise». Во-вторых, и это важнее, она указывает не на ту часть расхода. Чтобы это показать, контекстная стоимость MCP измерена родным токенизатором Claude (count_tokens), а не приближённой оценкой.

Стоимость схем: сколько занимает сам набор инструментов

Начнём с того, что и принято измерять, — со схем. По tools/list определения инструментов сервера попадают в каждый запрос как поле tools Anthropic-API: модель должна их видеть, чтобы вызывать. Это фиксированная стоимость — её платят один раз и держат всю сессию.

Замер текущего официального github-mcp-server и нескольких популярных серверов через count_tokens:

Дефолтный GitHub — 10 928 токенов, 5,5% окна; со всеми наборами инструментов — 20 404 (10,2%). Это меньше, чем 42–55K: та оценка считала больше инструментов (93 против сегодняшних 82) и, судя по охвату, включала инструкции сервера и обёртку клиента сверху. Названная цифра не столько неверна, сколько шире по охвату и без указанного метода. Здесь же измеряется ровно tools-payload — каноническая стоимость схемы, то есть нижняя граница того, что реально добавляет конкретный клиент. Стоимость реальна и ощутима. Но это разовый расход — и, как окажется, не основной.

Ответы инструментов: основная статья расхода

Схемы не просто лежат в контексте — инструменты на вызовы отвечают, и каждый ответ тоже попадает в окно и остаётся там до конца сессии. Эти ответы кратно больше схем.

Один вызов browser_snapshot у Playwright MCP — снимок accessibility-дерева одной страницы GitHub — занимает 38 831 токен: 19,4% контекстного окна с одного вызова. Это примерно в 8 раз больше, чем вся схема Playwright (4 633). И, в отличие от схемы, которую загружают однократно, каждый следующий вызов добавляет новый ответ — они накапливаются.

Отсюда практический вывод. Один многословный ответ — снимок страницы, листинг каталога, результат запроса на несколько десятков строк — за один ход способен перекрыть весь бюджет схемы и продолжать это делать на каждом вызове. Ленивая загрузка инструментов и search_tools, которые обычно предлагают как решение, экономят разовую стоимость схем — но не трогают ту часть, что растёт всю сессию.

Как это измерялось — и почему не оценкой

Чтобы числам можно было доверять, важны два принципа.

Первый — реальный счёт, а не приближение. ContextTax считает через Anthropic count_tokens — тот же токенизатор, по которому Claude тарифицируется, — а не библиотекой вроде tiktoken/o200k. Разница не косметическая: сверка офлайн-оценки o200k с count_tokens показывает, что она ошибается в обе стороны — занижает оценку схем на 16–43%, но завышает оценку того самого большого ответа-снимка примерно на 7%. Прокси-токенизатор — небезопасная замена для числа, на которое потом ссылаются.

Второй — маржинальная дельта. Каждая цифра считается как разница, которую payload вносит в реальный запрос: count(с ним) − count(без него). Так измеряется именно то, что занимает окно, вместе с обрамлением — то, что API учитывает как вход. (Prompt caching может удешевить цену этих токенов на повторных вызовах, но не место, которое они занимают.) При зафиксированных версии сервера и модели замер повторяется один в один.

Разовый налог и рекуррентный

Сведём вместе. Стоимость схем — разовый налог: его платят один раз за сессию, и ленивая загрузка его снижает. Стоимость ответов — рекуррентный налог: он начисляется на каждый вызов и накапливается. Если где-то и есть рычаг для оптимизации, то именно в ответах — в их пагинации, усечении и суммаризации, а не в очередном урезании схем.

И здесь стоит вернуться к тезису из начала. По мере того как агенты берут на себя всё более длинные задачи, контекстное окно становится главным ограничением — а значит, то, чем и как мы его заполняем, превращается в отдельную инженерную дисциплину. Стоимость схем против стоимости ответов — лишь один её срез, зато измеримый. Дальше будут другие: что держать в истории, что выгружать, что суммаризировать, когда звать инструмент, а когда обойтись без него. Объединяет их одно требование — сначала измерить настоящим счётом, потом оптимизировать.

Как померить свой стек

Цифры выше — отправная точка, а не вердикт: значение имеют ваш набор инструментов, ваши серверы и ваши типичные ответы. Поэтому полезнее измерить их самому.

ContextTax — однофайловый CLI для macOS, Linux и Windows (MIT). Он берёт схемы у живого сервера из вашего конфига и считает их стоимость; он же считает стоимость произвольного ответа инструмента — через пайп.

# установкаcurl -fsSL https://github.com/PavelTkachenk0/ContextTax/releases/latest/download/install.sh | sh# стоимость схемы живого сервера из вашего конфигаcontexttax measure --server github# стоимость любого ответа инструмента — пайпом# (pbpaste — macOS; на Linux: xclip/wl-paste, на Windows: Get-Clipboard)pbpaste | contexttax response

Есть и офлайн-режим без ключа (-e) — он считает той самой o200k-оценкой и честно помечает результат как приближённый (≈).

Репозиторий и инструкции по воспроизведению — github.com/PavelTkachenk0/ContextTax.