ИИ-сотрудник не просит отпуск. Зато может за вечер перечитать весь ваш каталог тридцать раз. Счёт оплачивает человек. Разбираем токены нейросети и экономику агента без магии «один запрос — одна копейка».
Токены нейросети — единицы обработки входных данных и ответа. Бюджет ИИ-агента зависит от всех вызовов модели, контекста, повторов, инструментов и проверки результата. Для бизнеса полезнее считать стоимость принятой задачи, а не цену одного запроса. Этот разбор — для владельцев компаний и руководителей, которые уже подключают агентов или выбирают подрядчика. Расчёты ниже учебные, тарифы условные: это способ проверить смету, а не прайс конкретного сервиса.
Агент ответил одной строчкой. Почему счёт на страницу?
Представим рабочий день. Менеджер просит ИИ: «Подготовь ответ клиенту про поставку». На выходе четыре предложения. На вид работа скромная. Даже обидно: за такие деньги мог бы хотя бы поставить красивую запятую.
За кадром агент прочитал инструкцию компании, схему инструментов, историю переписки, карточку сделки, каталог, условия доставки и результат поиска по складу. Потом выяснил, что в карточке два адреса. Сходил уточнять. Получил длинный технический ответ. Переспросил модель. На третьем проходе составил письмо. На четвёртом проверил его. Финальная строчка похожа на кончик чека: сам чек уехал под стол.
Это не обязательно ошибка. Несколько действий могут быть нужны для полезного результата. Ошибка начинается, когда никто не знает, какие именно действия были необходимы, сколько стоил каждый этап и почему одна задача внезапно оказалась в десять раз дороже соседней. Приложение показывает «готово», финансовый отчёт показывает «здравствуйте».
У человека тоже есть подготовка: открыть документы, вспомнить разговор, проверить остатки. У агента эта подготовка превращается в измеряемые обращения к модели и сервисам. Если считать только последний ответ, вы оплачиваете ресторан по количеству крошек на тарелке. Система может работать прекрасно. Просто способ оценки выбран странный.
Мой критерий для такого проекта: руководитель должен видеть не только сколько денег ушло, но и на какую полезную работу они ушли. Если этой связи нет, покупать ещё больше автономности рано. Сначала нужен прибор учёта. Умный сотрудник без учёта иногда становится очень творческим потребителем бюджета.
Что такое токен и почему «тысяча слов» не равна счёту
Текст поступает в модель не как привычная человеку стопка абзацев. Он разбивается на токены. Конкретный фрагмент может быть словом, частью слова, знаком или другой единицей представления. Разбиение зависит от модели и токенизатора. Русский текст, английский текст, таблица, код и строка с артикулами могут иметь разное соотношение символов и токенов.
Поэтому универсальное правило «один токен — четыре символа» годится разве что для очень грубой прикидки в подходящих условиях. Для сметы рабочего агента оно слишком самоуверенное. Особенно если вы отправляете товарные обозначения, длинные идентификаторы, выгрузки или смешанные языки. Считайте реальный типовой запрос выбранным способом подсчёта, а не средней температурой интернет-форума.
В документации Claude по подсчёту токенов описан отдельный механизм оценки входа до отправки запроса. Это полезная предварительная проверка. Фактическое использование после выполнения всё равно нужно сохранять: план и завершённая работа отвечают на разные вопросы.
Разделяйте вход и выход. На входе модель получает задание и контекст. На выходе создаёт ответ. У поставщика могут быть разные ставки для разных типов использования, кешированных данных или дополнительных режимов. Для конкретной модели смотрят действующие условия и поля использования. Нельзя переносить знакомую цену одного режима на любой другой и потом удивляться арифметике.
Ещё одна ловушка — смешать подписку сотрудника на чат и расходы приложения через API. Это разные продукты, лимиты и правила учёта. То, что менеджер пользуется чатом за фиксированную сумму, не означает фиксированную стоимость тысяч автоматических задач вашей CRM. Смета должна называть конкретный способ доступа, а не просто слово «нейросеть».
Для голосового или визуального сценария одной текстовой таблицы может не хватить. Распознавание речи, синтез голоса, изображения, хранение и внешний поиск считаются по своим правилам. Их нужно вывести отдельными строками. Иначе экономия на тексте выглядит героически, пока основная сумма спокойно живёт в соседнем сервисе.
Контекст — рабочая папка агента, а не музей компании
Контекст — сведения, доступные модели в конкретном вызове. Для агента продаж это могут быть правила общения, текущая задача, подтверждённые данные клиента, нужный фрагмент прайса и результаты выполненных действий. Ключевое слово здесь — нужный. Не всё, что существует в компании, помогает ответить на вопрос о доставке одного товара.
Компания часто начинает с понятной идеи: загрузим агенту все документы, пусть знает бизнес. Затем к документам добавляют письма, историю, правила для другого отдела и выгрузку на сто колонок. Получается цифровой сотрудник, которого перед каждым вопросом заставляют заново пройти корпоративную библиотеку. Он ещё не поработал, а уже прочитал биографию принтера.
В материале Anthropic о проектировании контекста рассматривается подбор полезной информации для агента, а также загрузка данных по мере необходимости. Это техническое основание для простого управленческого вопроса: почему сведения попали в этот вызов и какое решение они помогают принять?
В условной задаче про поставку агенту нужны артикул, количество, актуальный остаток, адрес и правило обещаний. Полная история клиента за три года нужна только при особом основании. Можно хранить историю целиком вне контекста, дать агенту средство получить релевантный фрагмент и сохранять ссылку на источник. Это не обязывает систему всегда работать одинаково: выбор способа загрузки проверяют на реальных сценариях.
Опасна и противоположная крайность: резать всё ради низкой суммы. Агент без правил скидок может обещать невозможное, а без актуальных условий — красиво написать старую неправду. Экономия закончится ручной переделкой и разговором с клиентом. Вопрос не в минимальном количестве токенов любой ценой. Вопрос в достаточном контексте для правильного результата.
Практический контроль: для каждого блока контекста записать владельца, дату актуальности, назначение и способ получения. Система должна отличать инструкцию от данных клиента, а подтверждённый факт — от предположения. Старые рекомендации не превращаются в действующие правила только потому, что их удобно скопировать в общий промпт.
Пять мест, где агент тихо подъедает бюджет
Повторная отправка истории
В многошаговой задаче каждый следующий вызов может получать значительную часть прежнего контекста. Финансово это не одна беседа, а последовательность операций. Если история растёт, последующие этапы могут стоить дороже предыдущих. При анализе смотрят распределение входного объёма по шагам, а не только общую сумму за день.
Разговорчивые инструменты
Агент просит остаток товара и получает огромный ответ со служебными полями, внутренними комментариями и сотней ненужных позиций. Технический запрос прошёл успешно. Задача получила мусор. Интерфейс инструмента стоит проектировать под решение: возвращать достаточные данные, ясный статус, источник и ограничения. Подробный документ можно запросить отдельно, если он действительно нужен.
Бесконечное «попробую ещё раз»
Ошибка интеграции вызывает повтор, повтор вызывает уточнение, уточнение запускает новый поиск. Самое дорогое слово иногда не «анализ», а «ещё». Для повторов нужен предел и понятный выход: отложить задачу, передать человеку или сообщить о невозможности продолжения. Повтор должен иметь основание, а не просто надежду на хорошее настроение сервера.
Несколько агентов без разделения работы
Пятеро цифровых коллег одновременно читают один и тот же архив, чтобы затем обсудить, кто будет писать два предложения. Красиво на схеме. Сомнительно в счёте. Несколько ролей полезны, когда у них разные задачи и измеримый вклад. Проверьте, нельзя ли передать короткий проверенный результат следующему участнику вместо полного дублирования всех входных данных.
Ответы, которые никто не принимает
Агент генерирует десять вариантов, сотрудник использует один и переписывает половину. В панели активности десять результатов. В бизнесе один черновик с доработкой. Без признака принятия команда оптимизирует производство текста, а не полезную работу. Расход на отвергнутые варианты тоже существует: спрятать его в «эксперименты» навсегда не получится.
Все пять причин проверяются журналом выполнения и выборкой задач. Не нужно сразу обвинять модель или подрядчика. Бывает, что длинный контекст обязателен, а повтор действительно спасает результат. Но у обязательного расхода есть объяснение. У привычного расхода обычно есть только традиция.
Цена принятой задачи: формула без маркетингового фейерверка
Для сравнения вариантов задайте единицу результата. Например, письмо по актуальным данным, которое сотрудник одобрил без существенной переделки. Или корректно заполненная карточка, прошедшая проверку. «Вызов модели» единицей результата становится только в техническом отчёте: руководителю обычно нужен завершённый рабочий сценарий.
Стоимость принятой задачи = расходы на модель, необходимые инструменты и человеческую проверку за выбранную выборку / число принятых результатов этой выборки. Указывайте границы расчёта. Разработка, внедрение и поддержка могут считаться отдельно; тогда не называйте полученное число полной стоимостью владения. Для общей экономики системы есть отдельный разбор TCO AI-системы.
Учебный пример. Мы взяли 200 одинаково отобранных задач. Вариант А потратил 2 400 условных рублей на модель и инструменты; принято 160 результатов. Проверка заняла 240 минут, час сотрудника для расчёта оценён в 600 рублей. Значит, проверка стоит 2 400 рублей, вся выборка — 4 800, один принятый результат — 30 рублей.
Вариант Б потратил 1 800 рублей на сервисы, но принято только 120 результатов. Проверка и исправления заняли 360 минут: ещё 3 600 рублей. Итого 5 400 рублей, или 45 на принятый результат. На витрине Б дешевле. В рабочем процессе А выгоднее по выбранному показателю. Победитель меняется, если изменятся данные, требования или цена проверки.
| Показатель | Вариант А | Вариант Б |
|---|---|---|
| Входящих задач | 200 | 200 |
| Принятых результатов | 160 | 120 |
| Сервисы | 2 400 ₽ | 1 800 ₽ |
| Проверка и исправления | 2 400 ₽ | 3 600 ₽ |
| За принятый результат | 30 ₽ | 45 ₽ |
Эти числа придуманы для объяснения арифметики, они не описывают клиента и не обещают будущую экономию. Для собственного расчёта собирайте фактические расходы и одинаково определяйте принятие. Если один вариант оценивали по лёгким запросам, а другой по конфликтным обращениям, таблица сравнивает характер выборки, а не решения.
Также отдельно отмечайте задачи без результата. Они входят в расход, но не исчезают из рабочего дня. Часть можно безопасно перенести человеку, часть — отложить до появления данных. Доля таких случаев и время передачи показывают, насколько удобно жить с агентом за пределами удачного демо.
Кеширование: экономия на повторе, а не амнистия за беспорядок
Кеширование позволяет при подходящих условиях повторно использовать уже обработанный общий фрагмент входа. Для рабочих агентов это может быть стабильная инструкция или другой повторяющийся блок. Но доступность, сроки, ограничения и стоимость зависят от поставщика и режима. Слово «кеш» само по себе ничего не гарантирует.
Документация Claude по кешированию промптов описывает требования к совпадению кешируемого содержимого и отдельный учёт его записи и чтения. Для сметы это означает: ожидаемую экономию нужно подтвердить данными использования на вашей нагрузке. Галочка в конфигурации — ещё не сумма сэкономленных денег.
Если стабильный блок меняется при каждом запросе, ожидаемое повторное использование может не случиться. Например, внутрь общего префикса вставили текущее время, случайный идентификатор или меняющийся список задач. Поэтому сначала разберите структуру входа. Условия, правила и переменные сведения должны попадать в нужные места по осмысленному правилу.
Кеширование не решает проблему качества источника. Повторять устаревшую инструкцию дешевле — всё равно повторять устаревшую инструкцию. Нужны версия, механизм обновления и проверка результатов после изменения. На уровне бизнеса важно, чтобы агент использовал действующие условия, а не чтобы красивый процент попаданий в кеш радовал инженера.
Учёт строят раздельно: обычный вход, запись кеша, чтение кеша, выход и другие применимые категории. Сравнивают итоговую стоимость задачи и время ответа до и после настройки. При редкой нагрузке результат может отличаться от частого повторения. Не переносите эффект лабораторной серии из ста одинаковых запросов на поток, где каждый документ новый.
И не отдавайте агенту лишнюю информацию ради попадания в кеш. Если в ответах инструмента живут закрытые сведения другого клиента, их нельзя оправдать экономией. Финансовая оптимизация работает внутри заданных границ доступа, актуальности и назначения данных.
Нужна ли самая сильная модель для каждого шага?
Есть соблазн отправлять всю работу самой дорогой доступной модели: пусть думает максимально хорошо. Есть обратный соблазн — выбрать минимальную ставку и объявить цифрового сотрудника практически бесплатным. Обе идеи пропускают главное: разные этапы имеют разные требования, а качество проверяется на задаче.
Разобрать простое подтверждённое поле, найти подходящий документ, сформулировать ответ в спорной ситуации и проверить критичное обещание — разные работы. Часть операций вообще лучше выполнять обычным кодом. Если нужно прибавить срок к подтверждённой дате по строгому правилу, незачем организовывать нейросетевой философский клуб.
Маршрутизация — выбор способа обработки по характеристикам задачи. Простой путь может закрывать типовые случаи, сложный подключаться при конкретном основании. Например, нехватке данных, конфликте источников или неудаче проверяемого результата. Переключение должно оставлять след: почему выбрали маршрут, чем он закончился и сколько стоил.
Нельзя доказать правильность маршрута уверенным тоном самой модели. Уверенность текста и корректность действия разные вещи. Нужен независимый критерий: обязательные поля, ссылки на действующие условия, запрет неподтверждённых обещаний, проверка результата инструмента. Для оценки до запуска полезен набор испытаний ИИ-агента.
Проверяйте и стоимость перехода между маршрутами. Слишком агрессивная экономия на первом шаге создаёт лишние повторы и затем всё равно приводит к дорогому варианту. В сумме получается хуже, чем сразу выбрать подходящий путь. Это цифровая версия ремонта: сначала сделали дёшево, затем заплатили за разбор, затем за нормальное решение.
Для сравнения храните тип задачи, выбранный маршрут, результат, время, причину передачи человеку и фактический расход. Сводка должна показывать, где распределение помогает, а где только добавляет движений. Количество моделей в архитектуре не является показателем зрелости бизнеса.
Лимиты: где агенту пора сказать «стоп»
У бюджета нужны границы по задаче и по периоду. Дневной предел защищает общий счёт, но не объясняет, почему одна операция поглотила половину суммы. Лимит этапов и повторов помогает остановить неудачный сценарий раньше. Конкретные значения выбирают по данным пилота и цене последствий, а не по красивому круглому числу.
Остановка должна оставлять полезное состояние: что подтверждено, чего не хватает, какие действия выполнены и кто продолжает работу. Если после лимита задача просто исчезает, деньги вы, возможно, сэкономили, но процесс потеряли. Для клиента это выглядит как молчание, а для сотрудника — как очередной квест «найди, что сделал робот».
Особенно осторожно с повтором внешнего действия. Повторить анализ текста и повторить отправку сообщения — не одно и то же. После сбоя неизвестный результат отправки сначала проверяют. Иначе агент экономически дисциплинирован, но клиент получает три одинаковых письма. Учёт расхода не заменяет защиту от повторных операций.
Разделите технический предел и деловое разрешение. Даже при свободном бюджете агент не получает право изменить цену, подписать документ или отправить чувствительные сведения. А при достижении лимита нельзя автоматически ухудшать правила проверки. Ограничение денег не является разрешением рисковать чужой сделкой.
Хороший статус остановки понятен без чтения всей трассировки: «остаток не подтверждён, письмо не отправлено, нужна проверка склада». Такой результат не выглядит эффектно в рекламе автономности, зато сотрудник может продолжить работу. Удобная передача иногда приносит больше пользы, чем ещё одна круговая попытка сделать всё самому.
Какие цифры попросить у подрядчика вместо «всё оптимизировано»
Нужен отчёт по рабочему сценарию, а не только агрегат поставщика модели. Минимальная строка задачи: идентификатор без лишних персональных данных, тип работы, версия правил, число этапов, объём входа и выхода по применимым категориям, внешние расходы, время, принятие или причина отказа. Разрешённые подробности доступны ответственным сотрудникам, а не всем подряд.
Смотрите медиану и дорогой хвост. Средняя стоимость может выглядеть спокойно, пока редкие зависания съедают существенную часть бюджета. Для управленческой сводки полезно выделить самые дорогие типы задач и причины отклонения. Если дорогие задачи действительно создают ценность, их не надо уничтожать. Надо понимать, что вы покупаете.
Попросите раскрыть единицу расчёта тарифного предложения. «Оплата за диалог» бывает удобной, но важно знать, что считается диалогом, что входит, какие ограничения действуют и что оплачивается сверх пакета. «Безлимитный агент» без границ нагрузки, инструментов и поддержки превращает коммерческий разговор в гадание по мелкому шрифту.
Для фиксированной подписки тоже можно считать цену принятой задачи: берут относимую стоимость периода и число результатов. Не путайте этот показатель с прямыми затратами исполнителя или своей маржой. Если платформа обслуживает несколько процессов, правила распределения общей суммы фиксируют заранее.
Главный вопрос на встрече: «Покажите одну типовую завершённую задачу от входа до принятия, все расходы и один неудачный случай». Ответ на него полезнее слайда с обещанием экономии. Демонстрация только счастливого пути показывает талант продавца. Учёт неудач показывает пригодность системы к понедельнику.
План проверки: сначала десять трассировок, потом масштаб
Начните с узкого сценария. Например, подготовка ответа по поставке без самостоятельной отправки. Определите входные данные, допустимые источники, критерии принятия и что делает человек. Сложность отбора важнее количества: одинаковые простые вопросы не покажут поведение на спорных остатках и отсутствующих адресах.
- Соберите небольшую обезличенную выборку с обычными, длинными и неудачными случаями.
- Запишите все этапы и фактическое использование, включая результаты инструментов.
- Отметьте принятые ответы, переделки, остановки и время сотрудника.
- Найдите основную причину расхода: контекст, повторы, неудачный маршрут или внешние услуги.
- Измените один элемент и повторите сравнение на сопоставимых заданиях.
- Расширяйте работу после проверки качества, бюджета и передачи человеку.
Десять подробных трассировок могут помочь увидеть механизм, но не доказывают устойчивую экономию на всём потоке. Для решения о масштабе нужна более широкая репрезентативная выборка и проверка редких дорогих ситуаций. Не превращайте удобную стартовую цифру в универсальный стандарт пилота.
Изменения проверяйте отдельно. Сократили контекст — убедитесь, что не выросли неверные обещания. Подключили кеш — проверьте фактические категории использования. Заменили модель — проверьте принятие и человеческое время. Убрали проверку — не объявляйте полученную экономию победой, если часть ошибок теперь просто никто не замечает.
Для работы в нескольких ролях, как в агентской AI-CRM «Цифра», делите учёт по сценарию и роли. Аналитик, продавец и помощник руководителя создают разные результаты. Это рекомендация к внедрению и приёмке, а не заявление о наличии конкретной панели расходов в любой версии продукта. Нужный состав контроля согласуют для вашего процесса.
Финиш пилота — ясное решение. Продолжаем, потому что подтверждённая работа стоит приемлемо. Меняем конкретный этап, потому что найдено ограничение. Или оставляем задачу человеку, потому что автоматизация пока невыгодна. Все три исхода нормальны. Самый дорогой исход — продолжать ради красивого слова «агентский».
Что сделать завтра утром
Не начинайте с просьбы «снизить токены на 30%». Попросите показать принятый результат и его путь. Затем выберите один повторяющийся расход, который не добавляет полезности. Возможно, это каталог целиком. Возможно, повтор при известной ошибке. Возможно, пять вариантов письма, хотя сотруднику нужен один.
Запишите владельца процесса, единицу результата и правила учёта. Подставьте текущие ставки своего поставщика, а не числа из старой презентации. Отдельно посчитайте время проверки. После изменения сравните качество и цену принятой задачи. Именно эта связка отличает работу с экономикой от соревнования «кто меньше отправил текста».
ИИ-сотрудник может быть выгодным. Но отсутствие зарплаты не означает отсутствие себестоимости. У него тоже есть подготовка, ошибки, инструментальная работа и контроль. Когда это видно, бюджет перестаёт быть загадкой. А у руководителя появляется право требовать полезный результат, вместо того чтобы каждый месяц оплачивать цифровое чтение корпоративной библиотеки.