Эксплуатация агента

Предположим, команда обновила backend, и часть задач стала выполняться иначе. Если в журнале записано только название инструмента, трудно установить, какая версия работала раньше и кто может её вернуть.

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

Заведите запись об исполнителе

Для одного runner хватит файла в репозитории. Реестр как отдельный сервис пока не нужен. В шаблоне укажите:

Поле	Что записать для учебного v03
Назначение	Применяет подготовленные файлы и запускает проверки ALGI.
Backend	scripted; модель не вызывается.
Версия	Коммит репозитория курса и путь к fixture harness-v03.
Владелец	Человек, которому передают сбои и предложения изменений.
Ограничения	Проверка команд и путей по local-dev.json; изоляции процесса нет.
Проверки	Ссылки на выполненные сценарии проверки runner и их результаты.
Журналы	runs/ рядом с исполняемым файлом; права доступа и срок хранения задаются отдельно.
Приёмка	Ручное ревью изменений, затрагивающих отчёты и данные.

Не записывайте «сеть запрещена», если это только фраза в инструкции. Укажите, где запрет реализован и каким испытанием проверен. Аналогично список планируемых eval не стоит выдавать за уже выполненный набор.

Перед обновлением

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

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

Изменение prompt, tool description или skill тоже может поменять поведение исполнителя. Их версии стоит связывать с запуском так же, как версию кода.

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

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

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

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

Когда выводить версию из работы

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

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