OpenClaw: если ваша задача не переживёт перезапуск, это всё ещё чат-сессия

Пост на r/clawdbot делает острое замечание о рабочих процессах OpenClaw: если ваша задача не может пережить перезапуск, это всего лишь чат-сессия. Автор утверждает, что рассматривать историю чата как авторитетную запись для длительной работы — значит готовить почву для провала.

Почему история чата не является состоянием задачи

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

Пост описывает, что каждая серьезная задача должна хранить вне разговора:

• Стабильная идентичность — уникальный идентификатор задачи
• Текущий шаг — где она находится в рабочем процессе
• Ожидаемый результат — как выглядит «готово»
• Состояние подтверждения — ожидаются ли или предоставлены пользовательские/автоматические подтверждения
• Исключения — что пошло не так, если что-то пошло
• Доказательства — журналы, результаты или выходные данные, собранные на данный момент
• Следующее безопасное действие — точное действие для выполнения при возобновлении

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

Настоящая проблема: внешние побочные эффекты

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

Решение состоит в том, чтобы свериться с провайдером перед повторной попыткой. Это означает проверку с внешней службой (например, API электронной почты, платформой развертывания или издателем контента), чтобы увидеть, действительно ли действие выполнено или все еще ожидается — затем решить следующий безопасный шаг.

Практический тест на возобновляемость

Пост предлагает простой эксперимент:

1. Остановите рабочий процесс сразу после его первого внешнего побочного эффекта (например, сразу после отправки электронного письма).
2. Перезапустите OpenClaw.
3. Наблюдайте, что происходит.

Может ли он различать:

• Завершено — побочный эффект произошел успешно
• Попытка — он пытался, но не удалось
• Ошибка — произошла ошибка
• Неизвестно — неясно, что произошло

Может ли он возобновиться с следующего безопасного шага без воспроизведения всего разговора? Если нет, рабочий процесс не является по-настоящему возобновляемым — он просто надеется, что стенограмма останется доступной.

Суть

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

В оригинальной ветке на r/clawdbot есть раздел комментариев, где разработчики делятся своими подходами — стоит прочитать, если вы создаете производственные агентские рабочие процессы.