AI-агент теряет контекст длинного процесса: как сохранить состояние

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

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

Что проверить в первую очередь

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

• Определите, какие сведения агент забывает: цель, ограничения, выполненные шаги или данные инструмента.
• Измерьте размер prompt и момент, когда начинается усечение истории.
• Проверьте, сохраняются ли результаты API вне текста диалога.
• Сравните повторный запуск с одной контрольной точки на одинаковых входных данных.

Почему возникает проблема

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

• Вся память хранится как неструктурированный transcript.
• Суммаризация удаляет важное исключение или точное значение.
• Инструмент возвращает большой результат, который вытесняет план и ограничения.
• Параллельные ветки перезаписывают одно поле состояния.
• После retry агент повторяет действие, не видя сохраненного результата.

Пошаговая диагностика

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

• Логируйте идентификатор run, step и версию состояния без секретов.
• Сохраните prompt до вызова модели и проверьте фактическое усечение.
• Отделите модельную память от базы фактов и журналов инструментов.
• Воспроизведите сбой с детерминированными заглушками внешних API.
• Проверьте конкурентные обновления и идемпотентность каждого действия.

Какие данные должны жить вне контекстного окна

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

• Goal содержит цель, критерий завершения и жесткие ограничения.
• Plan хранит шаги и зависимости с явными статусами.
• Facts содержит подтвержденные сведения с источником и временем.
• Tool results сохраняются по idempotency key и не зависят от пересказа модели.
• Checkpoint фиксирует версию состояния и безопасную точку продолжения.

Как исправить проблему

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

• Вынесите состояние процесса в БД или workflow engine с версионированием.
• Суммаризируйте историю по схеме, не изменяя числовые значения и запреты.
• Перед каждым действием загружайте только релевантные факты и текущий шаг.
• Добавьте optimistic locking и запрет параллельной записи устаревшей версии.
• Требуйте подтверждение перед необратимыми действиями и сохраняйте их результат.

Безопасный порядок внедрения

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

Как проверить результат

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

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

Типичные ошибки при исправлении

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

Как предотвратить повторение

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

• Опишите схему состояния и инварианты до расширения числа инструментов.
• Храните исходные результаты API и ссылки на них отдельно от summary.
• Тестируйте восстановление после сбоя на каждом важном шаге.
• Контролируйте размер контекста, частоту повторов и количество незавершенных run.

Что подготовить для технического разбора

• Описание ожидаемого и фактического поведения с точной последовательностью действий.
• Время проблемы, идентификатор тестового объекта и версии затронутых компонентов.
• Фрагменты журналов до и после ошибки без секретов и персональных данных.
• Перечень последних изменений и уже выполненных проверок.
• Безопасный доступ к тестовой среде либо способ воспроизвести сбой без влияния на клиентов.

Частые вопросы

Достаточно ли подключить векторную базу?

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

Можно ли просто увеличить контекст модели?

Это отсрочит усечение, но не решит конкурентные обновления, повтор действий и проверяемость состояния.

Когда нужна помощь специалиста

Если AI-агент забывает контекст или повторяет действия, я могу спроектировать хранение состояния, checkpoints, безопасные tool calls и восстановление процесса без потери результатов.