Инженерия сдерживания: почему затраты на ИИ-агентов растут стремительно

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

Две компании, два сигнала к пробуждению

В конце 2025 года Microsoft предоставила Claude Code своим внутренним инженерным командам. Этот инструмент глубоко интегрировался в ежедневную работу, и разработчикам он понравился. К середине 2026 года компания начала отзывать эти лицензии, направляя сотрудников на более дешевые внутренние решения, такие как GitHub Copilot CLI.

Ситуация с Uber была ещё более серьезной. В апреле 2026 года их технический директор признался, что весь бюджет на инструменты для программирования с использованием ИИ на 2026 год был исчерпан всего за четыре месяца. Инструменты стали использоваться 84% инженеров, их применение превратилось в своего рода соревнование внутри компании, а один из руководителей отдела разработки потратил 1200 долларов на токены во время одной двухчасовой демонстрации.

ИИ продолжал работать, но стал неприемлемо дорогим. Для тех, кто создаёт агентные системы, это означает наличие лимита, который легко достигается: затраты на обработку данных автономного цифрового сотрудника могут превысить зарплату человека, которого он должен заменить.

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

Почему агенты стоят в несколько раз дороже чат-ботов

Пrompt для чата и автономный агент — это совершенно разные вещи. Когда вы задаёте вопрос стандартной языковой модели, происходит один этап обработки: вы задаёте вопрос, она отвечает, и процесс завершается.

Агент же имеет цель с открытым окончанием. Если ему поручают исправить баг, он читает файлы, составляет план, пишет исправления, запускает тесты и оценивает результаты. При неудачном тесте цикл начинается заново, и агент снова анализирует ситуацию, переписывает код и тестирует его. За каждый шаг взимается плата.

В реальной разработке программного обеспечения это создаёт серьёзные финансовые риски. SWE-bench — это стандартный отраслевой тест, составленный из багов из реального производственного кода, и лучшие существующие агенты справляются менее чем с половиной его задач. Следовательно, для более чем половины багов агент пробует, терпит неудачу, пытается снова, снова терпит неудачу и в конце концов сдаётся.

Представьте себе сантехника, который берет полную стоимость за час каждый раз, когда падает его гаечный инструмент, взимает плату за каждый шаг к фургону и уходит, пока труба все еще капает. В масштабах предприятия неудачно выполненная задача агента — это и есть такой сантехник; за «упавший» инструмент все равно приходится платить полную сумму.

Потребление токенов не просто удваивается при работе с чат-окном. В среднем агент тратит в 5–30 раз больше токенов, а агент, выходящий из-под контроля в сложной ситуации с отладкой, может потреблять более чем в 1000 раз больше токенов, чем обычный запрос.

Две кривые затрат, разходящиеся

Экономика человеческого труда и экономика ИИ следуют разным кривым. По мере совершенствования младшего разработчика объем его работы растет, в то время как зарплата остается примерно неизменной. Он просто становится быстрее и эффективнее.

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

Улучшения в аппаратном обеспечении не помогают, поскольку спрос на программное обеспечение превышает получаемую экономию. Чипы Maia 200 от Microsoft, используемые сейчас в их центрах обработки данных, обеспечивают значительно больше токенов за доллар по сравнению с более старым оборудованием. Однако нагрузки, возникающие при работе агентов, мгновенно поглощают всю эту экономию. Дешевле токены — не значит, что агенты будут запрашивать их в меньшем количестве.

Поэтому идея выпуска агента во всю корпоративную базу кода и оставления его без присмотра отвергнута, так как математика этого не поддерживает. Однако агенты не бесполезны. Архитектура, предназначенная для их работы, должна измениться, и притом быстро.

Инженерия контроля

Для тех, кто разрабатывает ИИ-приложения, инжиниринг промптов больше не является единственной задачей. Настоящей задачей становится инжиниринг контейнментации: установление строгих ограничений, лимитов состояния и финансовых триггеров вокруг моделей, чтобы машина доказала свою ценность до того, как возникнут значительные расходы.

Проблема вполне реальна. Представьте систему управления запасами на базе Next.js 16, TypeScript и Azure OpenAI. Задержки и галлюцинации здесь почти не имеют значения по сравнению с опасением, что автономный агент застрянет в цикле рассуждений и за одну ночь исчерпает кредиты облака. Аналогичные опасения существуют и при обработке геномных данных на платформе Modal, где анализируются тысячи последовательностей из ClinVar, и при достижении строгого временного лимита в два часа процесс останавливается. Это была обычная вычислительная работа, оплачиваемая за секунду. Рекурсивный агент, оплачиваемый за каждый токен, в такой же ситуации мог бы накопить огромные расходы.

Четыре подхода делают контейнентацию практически применимой.

1. Маршрутизация запросов по уровню сложности

Самая распространённая ошибка — направление каждого запроса к флагманской модели, такой как GPT-5 или Claude 4.5 Opus. Это метод грубой силы, который быстро истощает ресурсы. Вместо этого на самом начале стека должен находиться слой маршрутизации. Маршрутизатор — это лёгкая, чрезвычайно дешёвая модель, которая анализирует каждую поступающую задачу и определяет, какая именно LLM подходит для её обработки.

[ Incoming User Request ]
           |
      [ Router ]
      /        \
[ Simple ]  [ Complex ]
      |          |
[ Llama 3 ] [ Flagship LLM ]

Простая выгрузка данных или базовая форматирование могут выполняться с помощью модели с открытым исходным кодом объемом 8 миллиардов параметров или настроенной мини-модели. Задачи, требующие сложной логики, решаются с использованием дорогостоящих флагманских моделей. Это единственное изменение может сократить расходы на API на 80%, при этом качество приложения останется неизменным.

2. Никогда не разрешайте бесконечный цикл попыток

Агенту, у которого есть возможность писать код, тестировать его и повторять попытки при неудаче, необходимо жестко заданное ограничение на количество попыток. Однако простого целого числа недостаточно, поскольку контекст увеличивается с каждой попыткой. Третья попытка обходится значительно дороже первой, так как в запросе теперь содержится информация о двух предыдущих неудачах.

Необходимо установить лимит расходов. Перед тем как агент начнет следующий рекурсивный шаг, функция промежуточного уровня оценивает стоимость токенов для входящего запроса. Если суммарные расходы сессии превысят заранее установленный предел, процесс немедленно прерывается, и ситуация фиксируется для проверки человеком-разработчиком.

3. Ограничение объема контекста

После неудачной попытки агент обычно добавляет необработанный журнал ошибок к своему предыдущему запросу и пытается снова. Именно отсюда и возникает экспоненциальная кривая затрат. Ограничение объема контекста противодействует этому. Вместо того чтобы передавать полную подробную историю сбоев в основную модель, более дешевая модель-маршрутизатор сжимает информацию о состоянии сбоя.

Необходимо передать объемный журнал ошибок в дешевую модель с инструкцией вроде «Выделите точную техническую причину этого сбоя в двух кратких предложениях». Только эти два предложения возвращаются основному агенту для следующей попытки. Окно контекста намеренно сокращается, поэтому количество токенов растет линейно, а не экспоненциально.

4. Использование человека в качестве финального рычага контроля

Долгое время наличие человека в процессе работы рассматривалось как временная мера безопасности. Теперь же это строгое финансовое требование. Роль разработчика заключается в наблюдении за агентом и немедленном пресечении любых ситуаций, когда тот попадает в дорогостоящее состояние сбоя: проверке результатов работы, подтверждении технического направления и остановке неуправляемого процесса до того, как он исчерпает бюджет срока разработки.

Что означает эта смена подхода

Недавно Duolingo смягчило свою публичную позицию по вопросу замены работников ИИ. Вместе с Microsoft и Uber оно столкнулось с простым фактом: люди — это самые дешевые «мыслительные машины», доступные на рынке. Гибкий ум разработчика функционирует благодаря сэндвичу и хорошему сну, и он никогда не будет брать с компании завышенную плату лишь за то, чтобы остановиться и подумать.

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

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