Десятки тысяч токенов на перезапуск — реальная стоимость сбоев в обвязке
Потеря контекста, дублирование записей во внешние базы и списанные в пустоту токены превращаются в прямые операционные издержки, когда агентная система сталкивается с сетевым тайм-аутом. Если автономный агент подготовил ответ на обращение, запустил сохранение черновика и оборвался по тайм-ауту, система встает перед выбором: повторять запись, проверять результат или останавливать выполнение. Подобный инцидент сразу ставит вопрос об ответственности: после перезапуска ему повторить запись, проверить результат или остановиться?
От выбора этой логики напрямую зависят появление дубликатов, потерянная работа и степень доверия к отчетам агента. Надежность автономной системы определяется архитектурной обвязкой (harness) — программным слоем вокруг модели, который берет на себя управление контекстом, инструментами, состоянием и выполнением задачи. В описании Google Cloud к этому уровню официально отнесены цикл исполнения, сохранение состояния, инструменты, память и ограничения. При этом повторные вызовы и сбои обвязки напрямую влияют на стоимость и надежность работы системы.
Контуры управления и изоляция инструментов
Модель лишь предлагает действие, тогда как обвязка вместе со средой исполнения определяет доступность операций и правила обработки результатов. Возможности готовых агентных сред наглядно демонстрируют решения вроде Codex, Claude Agent SDK, Gemini CLI и Hermes Agent от Nous Research, в то время как LangGraph и Google ADK показывают управление процессом непосредственно в коде. Существует и Harness² — исследовательский подход к изменению самой обвязки. Материалы по этим архитектурам были проверены 20 октября 2026 года.
В описании Google Cloud к этому слою отнесены цикл исполнения, сохранение состояния, инструменты, память и ограничения.
Инфраструктура вендоров постепенно берет контроль на себя: в официальном описании Codex harness OpenAI выделяет состояние диалога, поток событий, инструменты, sandbox и политики подтверждений. Через app-server вызывающее приложение может создавать threads, запускать turns, получать события и обрабатывать запросы разрешений. Однако подключенный сервер инструментов сам по себе еще не описывает весь процесс управления и восстановления после сбоя. Кто в таком случае отвечает за передачу состояния между сессиями?
Механизмы сохранения и иллюзия автоматической надежности
Ответ кроется в жесткой передаче структурированных артефактов между сессиями. В эксперименте Anthropic с длинными задачами начальный агент подготавливает рабочее окружение и список требований, а следующие сессии реализуют изменения шаг за шагом. Для передачи работы используются артефакты: список функций, журнал прогресса, историю Git и проверки приложения, поскольку простое сжатие диалога само по себе не решило проблему.
Существует позиция, согласно которой готовые агентные среды из коробки решают проблемы сбоев и управления состоянием, поэтому разрабатывать кастомную обвязку избыточно. Однако документация инструментов опровергает универсальность стандартных решений.
У Gemini CLI есть checkpointing: перед изменением файлов поддерживаемым инструментом сохраняются снимок проекта, история разговора и ожидающий вызов.
Встроенная команда /restore позволяет вернуться к этому сохраненному состоянию, но в проверенной документации эта функция отключена по умолчанию и включается только через настройки. Кроме того, локальный откат снимка проекта не способен отменить выполненный запрос к стороннему сервису.
Схожие архитектурные ограничения видны и в работе с памятью. В документации по памяти разделены компактные устойчивые факты и поиск прошлых сессий. Факты попадают в системный контекст снимком на старте сессии, поэтому запись на диск не означает, что текущая запущенная сессия перечитала эти данные. Для процедур система skills хранит процедуры, загружаемые по требованию, а через skill_manage агент может создавать и менять их. Для контроля записи предусмотрена опция skills.write_approval, подготавливающая изменения для человеческой проверки перед применением.
Индустрия рассчитывала, что подключение готовых агентных сред и расширение контекста автоматически устранят инфраструктурные сбои при выполнении сложных задач. На практике базовые модели по-прежнему требуют жестких внешних контрактов фиксации состояния, без которых любая ошибка исполнения оборачивается неконтролируемым ростом затрат на повторные прогоны.
Как менялась картина
Раньше устойчивость AI-агентов пытались обеспечить простым сжатием истории диалога, но реальная надежность уперлась в жесткую передачу структурированных артефактов и контроль сетевых тайм-аутов. Сама модель только генерирует действие, а зацикливание, лишние траты токенов и дублирование внешних записей ложатся на архитектурную обвязку вокруг нее. Даже готовые инструменты вроде команды /restore не спасают от побочных эффектов автоматически — эта функция в проверенной документации отключена по умолчанию и не может отменить уже ушедший запрос к стороннему сервису. Каждый сбой на границе сессий превращает архитектурный недочет обвязки в прямую оплату лишних токенов и исправление дубликатов в базах данных.
Источник: Хабр ML