Длительные задачи AI-агентов требуют больше, чем большого контекстного окна. Если агент несколько часов анализирует документы, готовит изменения или обрабатывает очередь, он должен переживать перезапуск процесса, недоступность поставщика и отзыв прав. После продолжения важно понимать, что уже сделано, что только планировалось и какие действия нельзя повторять без сверки.
Для этого нужна управляющая среда, часто называемая agent harness: компоненты вокруг модели, которые задают жизненный цикл работы, хранят состояние, вызывают инструменты и проверяют результат. Модель предлагает следующий шаг, а долговечность и полномочия обеспечиваются системой. Продолжение разговора и безопасное продолжение операции — разные технические задачи.
Ниже практическое руководство для платформенных команд и руководителей разработки. Первичные источники проверены 6 октября 2026 года. Схемы состояния и сценарии отказов — авторские рекомендации для проектирования, а не описание гарантированных возможностей конкретного SDK или Codenik.
Почему длинная задача не равна длинному разговору
Контекст модели содержит инструкции, найденные данные и историю рассуждений. Он помогает выбрать следующее действие, но не заменяет учёт выполненных операций. Если процесс остановился после записи в корпоративную систему, последняя реплика может ещё не содержать подтверждения. Новый запуск не должен считать отсутствие реплики отсутствием изменения.
Anthropic в Effective harnesses for long-running agents рассматривает работу через несколько контекстных окон и передачу структурированных артефактов между сессиями. В материале Harness design for long-running application development обсуждается разделение планирования, исполнения и оценки. Эти подходы полезны для организации работы, но сами по себе не обеспечивают транзакционность корпоративных API.
Практическое следствие: итог задачи должен находиться в проверяемом состоянии систем, а не только в тексте агента. Для изменения кода это конкретный коммит и результаты проверок. Для создания документа — идентификатор и версия документа. Для обработки обращений — набор фактических переходов статусов, который можно сверить.
Сначала определите единицу работы. Задача «обработать все обращения» плохо ограничена: новые обращения могут приходить бесконечно. Задача «обработать согласованный список на момент запуска» имеет границу. Именно эту границу можно сохранять, проверять и показывать пользователю после продолжения.
Разделите план, выполнение и доказательства
План отвечает на вопрос, что агент собирается сделать. Состояние выполнения показывает, какой шаг сейчас активен. Доказательства фиксируют фактические результаты. Если хранить всё в одном текстовом файле, эти категории легко смешиваются: фраза «создать отчёт» постепенно превращается в «отчёт создан», хотя ссылки на результат нет.
Для каждого шага задайте входы, ожидаемый результат и условие завершения. Условие должно быть доступно системе проверки. Если итогом является таблица, укажите проверяемый набор источников и требования к полноте. Если агент меняет запись, сохраните идентификатор объекта и ожидаемую версию после изменения.
Не требуйте от модели самой себе выставлять доказательство успеха. Она может подготовить описание результата, но решение о завершении лучше опирать на ответы инструментов и независимую сверку. Для творческих задач человеческая оценка остаётся частью процесса; это нужно явно записать, а не скрывать под автоматическим флагом.
Полезно также хранить причину пропуска шага. «Не требуется», «не удалось выполнить» и «ещё не начинали» — разные состояния. После перезапуска они ведут к разным действиям. Чёткий словарь статусов уменьшает риск, что новый контекст заполнит пробел наиболее удобным предположением.
Что должно входить в checkpoint
Checkpoint — сохранённая точка, из которой можно восстановить работу с понятными ограничениями. Она включает идентификатор задачи, версию плана, набор входных объектов, выполненные шаги, ссылки на артефакты, ожидающие операции и причину остановки. Сам текст разговора можно хранить дополнительно, но он не должен быть единственным источником состояния.
В checkpoint полезно записывать версию политики, действовавшую при выполнении шага. Это помогает расследованию, однако не даёт права использовать старую политику после возобновления. Новый запуск читает действующие разрешения и проверяет, доступен ли следующий шаг сейчас. Историческая версия нужна для объяснения прошлого действия.
Секреты, токены и полные чувствительные ответы в checkpoint обычно избыточны. Вместо токена сохраните ссылку на управляемое подключение. Вместо полного документа — идентификатор и версию, если система позволяет получить его заново. При необходимости сохранять данные задайте доступ и срок хранения отдельно.
Ниже учебный формат, а не схема готового продукта:
{
"task_id": "task-example",
"plan_version": 3,
"input_snapshot": "snapshot-example",
"completed_steps": ["read_sources", "prepare_draft"],
"next_step": "review_draft",
"artifacts": [{"id": "draft-example", "version": 2}],
"pending_operations": [],
"stop_reason": "waiting_for_review"
}Запись должна быть атомарной на уровне выбранного хранилища. Частично сохранённый checkpoint хуже явно отсутствующего: он выглядит пригодным для продолжения, но может потерять связь между выполненным изменением и его доказательством. Проверяйте восстановление после искусственного сбоя в момент записи.
Состояния задачи и единственный владелец исполнения
Начните с понятной машины состояний: запланирована, выполняется, ожидает, требует сверки, завершена, отменена. Для каждого перехода укажите инициатора и условие. Например, переход из ожидания в выполнение допускается после события или срока, но не после любого нового сообщения, если оно не относится к ожидаемому действию.
Два исполнителя не должны одновременно продолжать одну задачу. Для этого нужен механизм владения: lease, блокировка или иной предусмотренный хранилищем способ координации. Кроме исключения параллельного старта, продумайте защиту от старого исполнителя, который потерял владение, но продолжил работу после сетевой задержки.
Один из вариантов — возрастающий номер поколения исполнения. Операции приходят с текущим поколением, а доверенный брокер отклоняет запросы устаревшего владельца. Конкретный механизм зависит от архитектуры. Важно проверить сам отказ: наличие поля generation в JSON не делает старый процесс неспособным записывать данные напрямую.
Завершение тоже требует перехода по условиям. Если агент сообщил «готово», но один шаг находится в состоянии неизвестного результата, задача не завершена. Интерфейс должен показывать потребность в сверке и ссылку на операцию. Такая честная неопределённость позволяет оператору продолжить безопасно.
Учебный сценарий: подготовка отчёта по фиксированному списку
Рассмотрим задачу подготовки еженедельного отчёта. Пользователь согласовал конкретный проект, период и список источников. Агент должен прочитать задачи, сопоставить статусы, подготовить черновик и передать его на проверку. Отправка отчёта внешним получателям не входит в поручение.
При старте система фиксирует снимок входной выборки либо способ воспроизвести её с теми же границами. Агент обрабатывает источники небольшими блоками. После каждого проверенного блока сохраняются идентификаторы просмотренных объектов и промежуточный артефакт. Если одна система недоступна, работа может остановиться с указанием, какая часть ещё не прочитана.
После перезапуска новый исполнитель читает checkpoint, проверяет права и сравнивает доступные версии источников. Если версия документа изменилась, нужно решить по правилам задачи: использовать сохранённый снимок или обновить соответствующий блок отчёта. Нельзя незаметно смешать данные разных периодов и назвать их одним снимком.
На финальном этапе проверяется полнота: все согласованные источники либо обработаны, либо отмечены как недоступные. Черновик содержит ссылки на основания выводов и явные оговорки. Пользователь видит статус «подготовлен черновик, один источник не проверен», если это соответствует фактам, вместо уверенного «все данные учтены».
Этот сценарий удобен для первого пилота. В нём можно отработать checkpoints, изменение входов и восстановление без массовой записи в рабочие системы. Затем отдельно добавлять сценарий публикации с собственным подтверждением и журналом фактической отправки.
Как продолжать после неизвестного результата записи
Самый сложный сбой происходит между успешным действием внешней системы и получением ответа исполнителем. Например, агент создал черновик, но соединение оборвалось до записи его идентификатора. Если новый запуск повторит создание, появятся два документа. Если решит, что всё готово, может оставить задачу без доступного результата.
До вызова сохраните намерение операции с устойчивым идентификатором. Используйте идемпотентный механизм API, если он предусмотрен, либо согласованный способ поиска результата по этому идентификатору. После ответа сохраните доказательство. Если ответ не получен, операция переходит в состояние «требует сверки», а не автоматически возвращается в очередь на повтор.
Сверка должна спрашивать состояние у системы, которая могла выполнить действие. Если документ найден и соответствует ожидаемым параметрам, продолжение использует его. Если система подтверждает отсутствие операции и повтор безопасен, выполняется повтор. Если нельзя отличить оба случая, нужен оператор или предусмотренная процедура восстановления.
Особенно внимательно проверяйте API без устойчивого ключа операции. Поиск по названию документа может найти чужой результат, а поиск по времени зависит от часов и задержек. Такой способ нужно обозначать как ограниченный, а не как гарантию отсутствия дублей. Подробнее этот класс задач разобран в материале об идемпотентности.
Права после возобновления и срок подтверждений
Разрешение на старт задачи не обязательно разрешает все будущие действия. Пользователь мог покинуть организацию, доступ к проекту мог быть отозван, интеграция могла быть выключена. После возобновления исполнитель должен заново подтвердить действующий контекст, а каждое чувствительное действие — пройти проверку текущих прав.
При этом проверка права читать checkpoint и права продолжать работу — разные проверки. Оператор может иметь возможность расследовать задачу, но не выполнять её от имени прежнего пользователя. Не превращайте кнопку «возобновить» в механизм передачи чужих полномочий. Отдельно определите, кто может назначить нового владельца и как меняется область доступа.
Подтверждение операции должно иметь границы: объекты, тип изменения, версию плана и срок действия. Если агент продолжил через сутки, прежнее согласие на изменившийся набор документов может уже не соответствовать действию. Система показывает обновлённый план и запрашивает необходимое подтверждение по правилам этого сценария.
Сам checkpoint не может быть источником полномочий. Если в нём записано «разрешено обновлять проект», это историческая информация. Доверенный брокер сверяет её с актуальной политикой. Иначе изменение содержимого сохранённого файла становится способом выдать агенту новые права без владельца доступа.
Не доверяйте сохранённому контексту как инструкции
Длинная задача постепенно накапливает найденные документы, ответы инструментов и заметки. Среди них может оказаться внешняя инструкция, которую агент пересказал в промежуточном резюме. После продолжения такой пересказ выглядит как собственная память системы и получает незаслуженное доверие.
Разделяйте происхождение данных. Административные правила, поручение пользователя, план агента и текст источника должны иметь разные поля и понятные метки. Сохранённое резюме документа остаётся данными из документа. Оно не должно автоматически менять допустимые инструменты, область проекта или требования подтверждения.
Для важных выводов сохраняйте ссылку на исходный объект и версию. Если резюме утверждает, что пользователь разрешил отправку, система должна проверить само событие подтверждения в доверенном журнале. Уверенный текст в памяти не заменяет такого события. Это относится и к сообщениям, которые выглядят как внутренний регламент.
При восстановлении полезно формировать минимальный рабочий контекст: текущая цель, проверенные результаты, следующий разрешённый шаг и необходимые данные. Не нужно безусловно возвращать всю историю в модель. Но сокращение истории должно сохранять оговорки и неизвестные результаты, иначе удобная компактизация удалит именно информацию, которая предотвращает опасный повтор.
Бюджеты, ожидание и отмена
Длительная задача должна иметь общий бюджет и бюджет каждого шага. Время, число обращений к модели, число инструментальных операций и объём полученных данных ограничиваются независимо. Тогда можно объяснить, почему задача остановилась и какое действие требуется для продолжения, вместо общего сообщения «что-то пошло не так».
Ожидание ответа человека или внешнего события лучше выражать отдельным состоянием. Процесс не обязан постоянно работать, удерживая память и соединения. Сохранённое задание продолжения содержит условие пробуждения, срок и допустимый следующий шаг. При наступлении события система всё равно проверяет, не отменена ли задача и действуют ли права.
Отмена не равна уничтожению истории. После отмены нужно запретить новые операции и сохранить сведения о выполненных действиях. Если запрос уже ушёл во внешнюю систему, она может завершить его позже. Пользователь должен видеть эту границу: «новые шаги остановлены, одна операция ещё сверяется», если именно таково состояние.
Для общего бюджета предусмотрите правило его изменения. Агент не должен самостоятельно расширять лимиты только потому, что задача оказалась сложнее. Он может предложить новый план с оценкой оставшейся работы. Решение принимает владелец задания или заранее заданная политика, а изменение фиксируется как отдельное событие.
Проверка результата и роль отдельного оценщика
Оценщик может помогать обнаруживать ошибки результата: пропущенные требования, противоречия или недостаточно понятное объяснение. Но второе мнение модели не заменяет детерминированную проверку там, где доступен фактический критерий. Если документ должен существовать, проверьте его идентификатор и доступность, а не убедительность описания.
Для задач с кодом нужны соответствующие проверки проекта и доказательство, что они выполнялись на нужной версии. Для отчёта — полнота согласованной выборки и связь выводов с источниками. Для изменения данных — сверка состояния после операции. Критерий выбирается по типу результата, а не по общему желанию «оценить качество».
Проверка может не состояться. Источник недоступен, окружение сломано, тест не запустился. Такой исход следует показывать как непроверенный. Не засчитывайте отсутствие обнаруженной ошибки как успех, если оценщик не получил объект. Перед основной приёмкой полезен контрольный пример, который гарантированно должен провалить проверку.
Для смысловых критериев заранее подготовьте рубрику и примеры. «Хороший отчёт» слишком неопределённо. «У каждого вывода указан источник, ограничения данных названы, действия отделены от наблюдений» уже можно обсуждать и проверять. Решение о публикации чувствительного результата может оставаться за человеком, даже если технические проверки прошли.
Как испытать восстановление до запуска на рабочих данных
Подготовьте стенд с управляемыми точками сбоя. Остановка процесса до вызова инструмента, после отправки запроса, после ответа и во время сохранения checkpoint должна давать разные, заранее описанные состояния. Один тест «перезапуск прошёл» не охватывает эти границы.
| Сбой | Что должно остаться | Как проверить продолжение |
|---|---|---|
| До отправки операции | Намерение без результата | Безопасный первый вызов |
| После отправки, до ответа | Неизвестный результат | Сверка перед повтором |
| После ответа, до checkpoint | Факт в целевой системе | Восстановление идентификатора операции |
| Во время сохранения состояния | Целая старая или новая версия | Отказ от частично записанных данных |
| После отзыва доступа | История без новых полномочий | Запрет следующего защищённого вызова |
| Два одновременных продолжения | Один действующий владелец | Отказ устаревшему исполнителю |
Сначала подтвердите работу стенда. Тестовый сервис должен регистрировать вызовы и уметь показывать известный результат. Иначе сценарий с нулём записей может выглядеть успешным только потому, что запросы вообще не доходят до системы. Контрольный разрешённый вызов помогает отделить проверку от неисправного окружения.
Повторите сценарии с частичными ошибками и изменением входов. Например, часть документов обновилась во время ожидания, один проект стал недоступен, пользователь отменил задачу перед пробуждением. Система должна сохранять границы старого задания и явно объяснять необходимость нового решения, а не незаметно начинать работу с другим набором данных.
Как организовать эксплуатацию и разбор зависших задач
Оператору нужен список задач с фактическим состоянием: кто владелец, когда было последнее подтверждённое действие, что ожидается и где лежит checkpoint. Просто возраст процесса не показывает, зависла ли задача. Некоторые задачи законно ждут человека, другие остановились на неизвестном результате внешнего API.
Для каждого состояния назначьте понятный следующий шаг. Ожидание проверки ведёт к владельцу результата. Исчерпание бюджета — к решению о плане. Неизвестная запись — к сверке операции. Отказ доступа — к владельцу подключения. Автоматический повтор всех зависших задач смешивает эти ситуации и может создавать дубли.
В журнале связывайте события пользователя, поколения исполнения и вложенные операции. Для разбирательства важна последовательность решений, а не только текст последнего ответа модели. После инцидента оператор должен восстановить, какие полномочия действовали в момент действия и почему система считала его следующим разрешённым шагом.
Наблюдайте долю задач с непроверенным результатом, время в ожидании, частоту повторных операций и полноту артефактов. Число завершённых задач без этих показателей может скрывать ошибки классификации. Регулярно выбирайте несколько завершённых задач и независимо сверяйте результат с корпоративными системами, соблюдая права доступа к их данным.
Где Codenik вписывается в длительную работу
Codenik можно рассматривать как управляемый слой доступа между AI-агентом и корпоративными системами. Для длительной работы полезно отделить планировщик и хранилище checkpoints от управления подключениями, секретами, правами и аудитом. Ни одна из этих ролей не должна считаться автоматически реализованной только из-за наличия MCP.
При обсуждении решения с Codenik сформулируйте требования к конкретному окружению: после продолжения проверяются актуальные права, вызовы связаны с заданием, секреты остаются за слоем доступа, а неизвестные результаты можно восстановить по журналу. Совместимость с выбранным harness и долговечность его состояния нужно подтверждать отдельно.
Для первой интеграции выберите читающую задачу с фиксированными входами и явным черновиком результата. Так команда сможет проверить контроль области доступа без риска массового изменения данных. Далее добавляйте запись как самостоятельный сценарий с адресным подтверждением, устойчивым идентификатором операции и сверкой.
Связанные темы — жизненный цикл агента и наблюдаемость действий. В длительной задаче они сходятся в одном вопросе: может ли команда доказать, что продолжение сохранило первоначальную цель, текущие полномочия и фактический результат предыдущих шагов.
FAQ и минимальный план запуска
Достаточно ли сохранить историю чата? Нет. История помогает восстановить смысл, но может не содержать факта операции, выполненной перед сбоем. Нужны отдельно сохранённые намерения, доказательства, идентификаторы результатов и состояние неизвестных операций. Историю используйте как дополнительный источник, а не как журнал транзакций.
Нужно ли оставлять процесс работать всё время? Не обязательно. Ожидание человека или события удобно хранить как состояние задачи с условием продолжения. Новый процесс восстанавливает checkpoint и актуальные права. Это требует инфраструктуры пробуждения и учёта, но не требует бесконечно удерживать один разговор в памяти.
Можно ли автоматически повторять любой неуспешный шаг? Нет. Ошибка получения ответа не означает, что внешнее действие не состоялось. Для чтения повтор часто проще, для записи сначала нужна сверка либо предусмотренная идемпотентность. Невозможность сверки должна быть видимым состоянием, а не поводом предположить успех или отсутствие действия.
Когда задача действительно завершена? Когда выполнены согласованные критерии, сохранены доказательства и разрешены неизвестные результаты. Для задач с человеческой приёмкой также требуется соответствующее событие проверки. Формулировка агента «готово» может быть сообщением о состоянии, но не должна сама создавать это состояние.
Начните с ограниченной задачи, опишите её входы и критерии, введите checkpoints и журнал операций. Затем испытайте остановки на границах, отзыв права и двойное продолжение. Только после подтверждённого восстановления расширяйте длительность и область действий. Продолжительность сама по себе не является показателем зрелости; важнее проверяемость каждого перехода.
Источники
- Anthropic: Effective harnesses for long-running agents — передача состояния между сессиями, 26 ноября 2025 года.
- Anthropic: Harness design for long-running application development — организация планирования, исполнения и оценки, 24 марта 2026 года.
Дата проверки: 6 октября 2026 года. Checkpoint JSON, машина состояний и контрольные сценарии — авторская архитектура для обсуждения и испытаний, не описание интерфейсов SDK.