Стоимость ИИ-агентов: как резервный сценарий незаметно съел бюджет

Стоимость ИИ-агентов: что зафиксировал сбой

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

В период 2026-09-18 → 09-19 два автономных агента для публикации контента действовали по одной общей схеме: автор в песочнице готовил статью, после чего сайт её публиковал. Один из агентов перед этим был перезапущен на новом сервере. За двенадцать часов он выпустил 18 статей, и во всех 18 пакетах были описания изображений, но не было ни одного файла с изображением.

Сайт воспринял эти описания как запросы на генерацию. Через платную модель изображений он создал 18 обложек и около 26 иллюстраций — примерно по $0.45 на статью. Обе публикационные системы расходовали общий баланс тарифицируемого шлюза. К 01:15 UTC сумма на нём сократилась с $8.30 до $0.

Количество изображений и стоимость одной статьи указаны приблизительно и должны оставаться приблизительными. По этим данным нельзя точно восстановить движение средств на общем балансе. Два показателя недостающих результатов тоже относятся к разным наблюдениям: по ним нельзя вывести общее число уникальных затронутых статей.

Все улики ведут к границе загрузки файлов

Пакеты, журналы и баланс указывают на один и тот же разрыв: автор мог описать изображение, но не мог передать сам файл.

• Во всех 18 пакетах были описания сцен и не было ни одного файла изображения. Это не мелкая проблема качества рендеринга. Артефакт вообще не пересёк границу системы публикации.
• В одном журнале инструмент для изображений упомянут 10 раз, в другом — 0. У обоих агентов была одна версия CLI, один доступный инструмент и одинаковые флаги. Значит, техническая возможность существовала, но второй автор не мог добраться до неё по своему рабочему маршруту.
• Общий баланс сократился с $8.30 до $0 к 01:15 UTC, пока сайт превращал описания в платные изображения. Когда платёжный маршрут остановился, в обеих публикационных системах начали пропадать обложки и эмбеддинги.

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

Как безопасная песочница оставила только платный маршрут

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

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

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

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

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

Почему статус done оказался неверным

Платёжная ошибка должна была изменить итоговый статус задания. Вместо этого ответ 402 обработали как мягкий сбой: система зарегистрировала или допустила ошибку и продолжила работу, а не остановила задание.

Так завершение задачи отделилось от готовности результата. Текст статьи можно было опубликовать, поэтому задание получало статус done, даже если обязательной обложки или эмбеддинга не существовало.

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

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

Что это меняет для разработчиков, операторов и покупателей

Один и тот же инцидент влияет на три разных типа решений.

Разработчикам: проектируйте передачу артефактов, а не только песочницу

Разработчикам стоит явно обозначить границу учётных данных и назначить исполнителя каждому шагу, который её пересекает. «Автор не может получить ключ» — это правило безопасности. Требование «автор загружает файл с этим ключом» не может одновременно оставаться частью процесса.

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

Операторам: следите за зависимостью, общей для нескольких продуктов

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

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

Покупателям: выясняйте, что произойдёт после сбоя основного сценария

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

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

Исправлять сейчас, подождать или ничего не менять

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

Что переоценено: больше резервных сценариев не значит выше надёжность

Само по себе продолжение работы ещё не делает резервный сценарий отказоустойчивым. Надёжность появляется только тогда, когда понятны его стоимость, зависимости, качество результата и состояние при отказе.

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

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

Инженерные правила, которые делают стоимость резервных сценариев видимой

Сначала исправьте распределение ответственности, затем сделайте явными стоимость и условия завершения.

Храните учётные данные в доверенном процессе

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

Разделите файлы и описания на разные классы входных данных

Файл — готовый артефакт. Описание — рецепт его создания. Если считать их взаимозаменяемыми, от наблюдения скрываются и стоимость, и поведение при сбое.

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

Привяжите done к обязательным результатам

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

Отделите состояние зависимости от журналов заданий

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

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

// Illustrative only. This is not production source.
const handoff = {
  payload: writerOutput.payload,
  pictureFiles: writerOutput.pictureFiles,
  pictureDescriptions: writerOutput.pictureDescriptions,
};

const stagedFiles = await trustedProcess.stage(
  handoff.pictureFiles,
  "presigned PUT",
);

const fallbackRender = stagedFiles.complete
  ? null
  : await paidFallback(handoff.pictureDescriptions);

if (fallbackRender?.status === 402) {
  failJob("Paid fallback unavailable");
}

const publishableArtifacts = mergeArtifacts(
  stagedFiles,
  fallbackRender,
);

const rewrittenPayload = rewritePictureReferences(
  handoff.payload,
  publishableArtifacts,
);

rewrittenPayload.pictureDescriptions = handoff.pictureDescriptions;

assertRequiredArtifacts(rewrittenPayload);
markDone();

Главное здесь — порядок действий: автор создаёт файлы, не получая ключ сайта; доверенный процесс размещает их в хранилище; пакет ссылается на сохранённые артефакты; и только проверенное завершение превращается в done.

Передача, которая останавливает утечку

Надёжное исправление состоит из двух частей: автор рендерит, доверенный процесс размещает.

Автор складывает файлы изображений рядом с пакетом в результаты, которые ему уже разрешено создавать. Доверенный процесс за пределами песочницы принимает файлы и отправляет их через presigned PUT — загрузку, авторизованную специально для такой передачи. В предоставленных данных не определены ни срок действия, ни права этой ссылки, поэтому они остаются параметрами реализации, а не установленными фактами.

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

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

Что сделать в понедельник

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

FAQ

Получайте следующие разборы продакшен-инцидентов в рассылке.