Почему большинство ИИ-агентов погибают после одной сессии, а те, что работают долго, выживают

Почему столько агентов кажутся временными

Любой, кто использовал ChatGPT, Claude или другого агента для вызова инструментов, видел типичную схему:

1. Вы задаёте цель.
2. Агент приступает к работе.
3. Он вызывает несколько инструментов.
4. Беседа затягивается.
5. Ответы становятся хуже, или сессия просто заканчивается.

Таков опыт обычного чат-агента. Он подходит для кратких задач и теряет эффективность, когда работа занимает часы или дни.

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

Начните с простого: что такое агент, работающий длительное время

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

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

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

Хранение состояния вне модели и его чистое восстановление являются ключевыми аспектами того, что называют инженерией инструментов.

Три стены

Почти каждый долгосрочно работающий агент сталкивается с теми же тремя проблемами.

1. Ограниченный контекст. У каждой модели есть ограниченное окно контекста, и даже большие окна со временем заполняются. Когда оно заполняется, старая информация удаляется или сжимается, что приводит к ухудшению решений агента. Это часто называют «порчей контекста».
2. Отсутствие постоянного состояния. Новая сессия обычно начинается с пустой памяти. Поскольку нет внешнего источника для сохранения прогресса, каждая перезагрузка похожа на приход нового сотрудника, который ничего не знает о прошлом проекта.
3. Слабая самопроверка. Модели склонны к оптимизму. Когда их спрашивают, завершена ли работа, они часто отвечают утвердительно, даже если она выполнена лишь частично. При отсутствии внешней проверки незавершенная работа считается завершенной.

Эти три проблемы объясняют, почему простые агенты не могут надежно работать в течение длительного времени.

От основ до полезных шаблонов

Как только препятствия устранены, возникает вопрос о том, как люди смогут их преодолеть. Постоянно возвращаются четыре основных подхода.

• Пункты контроля и возобновление работы. Агент периодически сохраняет прогресс в структурированном виде. Если что-то идет не так, он возобновляет работу с последнего успешного пункта контроля, а не с начала.
• Внешняя память. Важные данные хранятся вне контекста модели — в файлах, базе данных или хранилище сессий, — и агент читает их в начале каждой новой сессии.
• Участие человека. При принятии важных решений агент делает паузу, ожидает одобрения или отклонения от человека, а затем продолжает работу. Этот механизм необходимо тщательно спроектировать, чтобы состояние агента не устаревало во время ожидания.

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

По отдельности эти подходы просты, но вместе они обладают огромной силой.

Ментальная модель

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

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

Что становится возможным

Когда агенты могут существовать дольше, открываются новые виды задач:

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

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

От демо-версии к продакшену

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

1. Точка контроля и возобновление

Это самый важный шаблон, поскольку наиболее частой проблемой при длительной работе является потеря прогресса. Представьте агента, который обработал 200 документов и столкнулся с ошибкой при обработке 201-го. Без точки контроля, то есть копии состояния памяти или процесса, вся работа теряется зря. Многие агенты решают проблему путём полного перезапуска процесса, что требует большого количества ресурсов.

Хорошая система регулярно сохраняет информацию о прогрессе, записывая:

• что уже выполнено;
• что ещё остаётся незавершённым;
• любые важные промежуточные результаты.

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

2. Память вне модели

Обычно существует два вида:

• Рабочая память — это то, что нужно агенту прямо сейчас, в текущем контексте.
• Постоянная память — это то, что должно сохраняться после окончания сессии, и она хранится внешне.

Постоянная память может находиться в структурированных файлах, таких как progress.txt, plan.json или notes.md, в базе данных, в хранилище сессий или в специализированной службе памяти. Принцип прост: модель может забыть, но система вокруг неё — нет.

3. Разделяйте генерацию и оценку

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

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

4. Правильное утверждение человеком

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

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

5. Координация множества агентов

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

• планировщики изучают проблему и делят её на задачи;
• исполнители выполняют конкретные этапы;
• судьи определяют, достаточно ли хороша текущая итерация.

Сообщается, что Cursor перешел к такому подходу после неудачных попыток координации ранее. Это снижает хаос и предотвращает взаимные конфликты между агентами.

Как выглядит стек производства

Реалистичный стек обычно состоит из трех слоев:

1. Логика агента, то есть пункты ввода данных, инструменты и цикл принятия решений.
2. Механизм управления, включающий управление сессиями, контроль рабочего процесса, повторные попытки и восстановление.
3. Управляемые примитивы, такие как надежное хранилище, планирование, инструменты длительной работы, триггеры событий и возможности мониторинга.

Например, ADK от Google предоставляет элементы для создания сессий, которые сохраняются, для выполнения кода, способного продолжать работу после перезагрузки, а также триггеры, запускаемые событиями. Благодаря этому агент может долгое время находиться в неактивном состоянии и всё равно правильно продолжить работу позже. В статьях Anthropic о механизмах управления подчеркивается необходимость разделения «мозга» — модели и её цикла принятия решений, — от «рук» — среды выполнения, — и от сессии — надежного журнала событий.

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

Правила проектирования, способствующие этому

Эти привычки надежно делают системы более надежными:

• Каждый раз записывайте важную информацию о ходе работы в надежное хранилище.
• Вместо данных, хранящихся в памяти в виде обычного текста, предпочитайте структурированные форматы, такие как JSON, логи в формате Markdown и списки задач.
• Рассматривайте сбои как часть нормы и планируйте на них реагирование заранее.
• Восстановление работы должно происходить по умолчанию, а не в качестве особого случая.
• Когда важна качество, разделяйте компоненты, отвечающие за генерацию данных, и те, что их оценивают.
• Используйте методы сжатия или обобщения, когда объем контекста становится слишком большим.
• Целенаправленно включайте точки проверки проекта с самого начала, а не добавляйте их позже.

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

Оставшиеся ограничения

Даже при хорошей архитектуре существуют неизбежные ограничения:

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

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

Что это дает вам

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

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

Связанные материалы

• Практические рекомендации: проектирование кэша для AI-агентов: его внедрение в производство — Подробное руководство по практическим рекомендациям по проектированию кэша для AI-агентов и его внедрению в производство: контракты, проверки и готовые блоки кода для команд, использующих эту схему.

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

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