Самая неприятная поломка у агента, которому дали работу на несколько дней, может проявиться не при запуске, а спустя много шагов работы. Представим такой сценарий: часть задачи сделана, часть переделана дважды, а письмо клиенту ушло в двух экземплярах. Никто ничего не взламывал и не выходил из-под контроля — просто где-то оборвался поток, где-то агент упёрся в лимит сессии, а приложение на всякий случай повторило команду целиком.
10 сентября 2026 года OpenAI открыла публичную бету Agents API — набора инструментов для агентов, которые живут в задаче долго, работают с файлами, кодом и внешними сервисами и оставляют после себя промежуточные результаты. Звучит как заявка на сотрудника, который трудится, пока вы спите. Но интереснее в этом релизе другое: API построен вокруг довольно трезвой мысли, что долгая работа — прежде всего инженерия состояния, а не чат, растянутый по времени.
Сессия вместо одного запроса
Главная единица работы в Agents API — долговечная сессия. Она хранит конфигурацию агента, историю взаимодействия, ходы выполнения и сохранённые результаты. Когда один ход закончен, приложение может отправить новую задачу в ту же сессию, не собирая весь контекст заново.
Здесь важно не перепутать три разные вещи. Agents API — вариант, где OpenAI управляет сессией и окружением Codex. Agents SDK оставляет разработчику больше контроля. Responses API — более низкоуровневый путь для тех, кто хочет собирать всё руками. Публичная бета — именно первый вариант, где больше контроля остаётся у OpenAI, а не у разработчика, что одновременно и удобно, и ограничивает.
И оговорка, без которой конструкция читается неправильно: долгая сессия не означает, что агент предоставлен сам себе. Он может остановиться в состоянии requires_action — например, когда ему нужен результат функции, подключение окружения или другое действие со стороны приложения. Это штатный режим работы, а не сбой. Приложение обязано заметить такое состояние и продолжить выполнение, иначе агент останется стоять с поднятой рукой.
Память не равна пониманию задачи
Вторая опора — compaction, сжатие истории. В долгой сессии накапливаются старые сообщения, результаты инструментов, повторы и устаревшие детали, и всё это начинает мешать. Compaction уменьшает объём предыдущего контекста, сохраняя состояние, необходимое для дальнейшей работы.
Тут легко обмануться формулировкой «агент сжимает память и помнит главное». По документации OpenAI результат серверного сжатия передаётся в специальном компактном формате и не предназначен для человеческого чтения: это служебная упаковка состояния для следующего окна контекста, а не конспект для вас. И она не гарантирует идеального сохранения каждой детали — как и сохранения первоначального замысла.
На мой взгляд, именно здесь проходит самая недооценённая граница. «Не забыть задачу» — не магия модели, а работа того, кто её запускает. Критические требования, запреты и критерии готовности надёжнее держать в явных инструкциях и проверяемом состоянии, чем надеяться, что модель сама вспомнит абзац из начала трёхдневной переписки.
Руки, инструменты и песочница
Агент в Agents API не просто рассуждает. Он может работать в песочнице на стороне OpenAI, в инфраструктуре разработчика или вовсе без отдельного вычислительного окружения. В песочнице он запускает команды, пишет код, редактирует файлы и создаёт артефакты. Инструменты подключаются через функции приложения, MCP-серверы, встроенный поиск и вычислительную среду, а сложную задачу можно делить между субагентами — у каждого будет свой рабочий контекст.
В официальном quickstart агент создаёт файл tree.py, запускает его и возвращает структуру каталога. Пример нарочно простой, но показывает главное: модель, код, файлы и результат связаны в один цикл. С 29 сентября 2026 года в Agents API для окружения на стороне OpenAI появились и браузерные действия — при этом разрешения на доступ к сайтам и вход в аккаунты обрабатывает приложение, а не сама браузерная функция.
Дальше начинаются последствия. Пока агент только рассуждает и не вызывает инструментов, внешних эффектов нет. Как только он меняет файлы, обращается к внешним сервисам и ходит по сайтам, ошибка перестаёт быть неудачной фразой в логе.
Где начинаются неприятности
Документация честно перечисляет состояния отказа: превышение бюджета сессии, ошибки песочницы, тайм-ауты, перегрузка сервиса, сбои подключения, проблемы авторизации, нарушения политик. Список скучный ровно до того момента, пока не осознаёшь, что каждый пункт может случиться в середине многошаговой работы.
И ключевое предупреждение OpenAI: ошибка хода не означает, что агент ничего не успел сделать. Перед повтором нужно проверить сохранённые результаты, файлы и вызовы внешних инструментов — неудачный ход мог успеть изменить файл или выполнить внешнее действие до сбоя.
Двойной побочный эффект выглядит буднично. Агент отправил письмо, получил тайм-аут, приложение механически повторило шаг — и клиент получил второе письмо. Или, например, агент перезаписал отчёт, упал на следующем шаге, а повтор стартовал с начала и затёр уже проверенный результат. Никакого злого умысла, просто повтор не равен откату.
С обрывом потока та же логика. Приложению нужно получить сохранённые элементы сессии, восстановить локальное состояние и проверить ожидающие действия, а не отправлять исходную команду заново. Запросы на разрешение браузерных действий документация советует сопоставлять по идентификатору запроса, а не подтверждать всё подряд повторно.
Отсюда простое правило: рискованные операции должны проходить через разрешение приложения или человека. Но разрешения не отменяют риск. Если приложение подтверждает действие, не глядя на аргументы, кнопка «Одобрить» ничего не спасает — она лишь красиво оформляет автоматическое «да».
Что на самом деле показывают примеры
Стоит честно обозначить природу доказательств. Всё, что мы знаем о поведении таких агентов, — официальная документация и примеры самой OpenAI, а не независимые многодневные испытания на живых проектах. Разница между «убедительно на демо» и «выдержит три дня на рабочем проекте» здесь принципиальная.
Показателен сценарий реагирования на инцидент: агент расследует проблему, а восстановительные действия выполняет только после запроса разрешения. Хорошая иллюстрация границы между «посмотреть и предложить» и «поменять систему». Второй пример — сравнение документов или релизных заметок, где субагенты параллельно разбирают части материала, а основной агент собирает итог. Разделение контекста помогает, но не отменяет проверки: субагент мог понять свою часть иначе, и склейка этого не покажет.
Отсюда аккуратный вывод. Архитектура рассчитана на долгие и асинхронные задачи — да. Но из этого не следует, что любой сценарий безопасно оставлять без присмотра на несколько дней. «Агент работает дни напролёт» и «агент работает дни напролёт при грамотной обвязке» — разные утверждения.
Смысл задачи тонет тише, чем контекст
Самое хрупкое в долгой сессии — не объём памяти, а исходное намерение. Через сутки сжатий и десятки ходов «сделай нормальный отчёт» и «сделай отчёт, который не стыдно показать клиенту» вполне могут слиться в одно — а это разные задачи с разными критериями приёмки.
Поэтому практический минимум для того, кто такое строит, выглядит не очень эффектно: ключевые требования и запреты — в явных инструкциях, состояние — в проверяемых данных, результат — в понятных критериях готовности. Compaction управляет длиной контекста, но не страхует от смысловых потерь. И ответственность здесь разделена: OpenAI управляет своей частью инфраструктуры и даёт механизмы сессий и восстановления, а инструменты, права, проверку аргументов и последствия внешних действий обеспечивает приложение разработчика.
Почему автономия упирается в разрешения
Чем больше агент умеет сам, тем важнее точки, где он обязан остановиться. requires_action — не досадная помеха, а тормоз, который отличает управляемую систему от лотереи. Рабочий набор невелик: ограничить число повторов, проверять фактическое состояние перед повтором, делать операции идемпотентными, выдавать отдельные права рискованным инструментам, сопоставлять запросы на разрешение по идентификатору. Скучно? Да. Но именно эта скука позволяет агенту работать долго, не превращая один сбой в серию побочных эффектов.
По-моему, большинству бизнесов нужен вовсе не автономный исполнитель на три дня без присмотра, а помощник, который замечает изменение ситуации и готовит действие к одобрению. Идею в этом духе можно представить и в логике подхода Market-GPT: агент следит за состоянием клиентов и маркетинга, показывает, что изменилось, и готовит конкретный шаг к одобрению, а решение остаётся за человеком. Не потому, что людям нравится всё контролировать, а потому, что цена ошибки в работе с клиентами выше экономии на одном клике.
Agents API — серьёзный шаг к агентам, которые живут в задаче долго. Но заявленные дни работы требуют не идеального промпта, а инженерной обвязки: журнала, проверок, разрешений и умения вовремя остановиться. Хороший долгий агент — не герой, который всё помнит, а исполнитель, который умеет отчитываться, не повторять опасное действие дважды и вовремя говорить: здесь нужен человек.