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

Цель

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

Предварительные условия

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

Шаги

1. Зафиксируйте контракт выполнения. Сохраните редакцию цели, разрешённые ресурсы и действия, место для результатов, срок действия, бюджет и порядок эскалации. Выделите службе собственную учётную запись с ограниченными правами и отдельно укажите пользователя, инициировавшего запуск. Не настраивайте учётную запись службы копированием хранилища учётных данных интерактивной сессии.
2. Предоставьте только необходимый доступ. Используйте средства платформы для идентификации рабочих нагрузок. Документация Kubernetes по служебным учётным записям описывает отдельные идентичности рабочих нагрузок и automountServiceAccountToken: false для Pod, которым не следует автоматически подключать учётные данные API. Ограничивайте разрешения на стороне ресурса, к которому обращается агент. Обновление учётных данных не должно незаметно продлевать срок разрешения на выполнение задачи.
3. Задайте бюджет всей задачи. Сохраняйте совокупный расход с учётом дочерних агентов, повторных попыток и перезапусков процессов. Определите лимиты времени, вызовов модели и инструментов, параллельности, объёма хранения и платных сервисов. Резервируйте ресурсы перед отправкой работы, если параллельные исполнители могут превысить общий лимит. Укажите, какие ограничения действительно обеспечивает супервизор или шлюз: фраза в промпте остаётся лишь просьбой.
4. Создайте независимый механизм остановки. По истечении срока действия или по команде оператора блокируйте отправку новой работы, отключайте автоматический перезапуск для этого запуска и запрашивайте отмену отслеживаемых операций. Если доступен шлюз записи, обеспечьте на нём прекращение полномочий по истечении срока. Прежде чем сообщать о завершённой остановке, выясните результаты операций, уже принятых удалённой стороной. Сохраняйте видимость невыясненных последствий и предотвращайте повторы без проверки после перезапуска.
5. Точно сопоставляйте средства контроля платформы с их действием. Kubernetes Jobs поддерживают activeDeadlineSeconds и приостановку. Приостановка Job завершает её активные Pod; возобновление сбрасывает таймер допустимого времени активности. Поэтому храните абсолютный срок окончания полномочий отдельно от этого таймера. Рассматривайте приостановку как управление жизненным циклом процессов; для восстановления нужны надёжно сохранённые контрольные точки приложения, а результаты удалённых операций следует проверять отдельно.
6. Обеспечьте возможность проверить состояние работы без оператора. Записывайте идентификаторы задачи и попытки, редакцию цели, ссылку на учётную запись, расход бюджета, результат инструмента и причину остановки, не включая секреты. Распространение контекста в OpenTelemetry связывает трассировки между сервисами. Выгружайте необходимые журналы до удаления рабочей нагрузки. Для Kubernetes Job команда kubectl get job JOB -o yaml показывает зафиксированное состояние; kubectl logs jobs/JOB — отправная точка для просмотра вывода, а не полная история всех попыток.

Ожидаемый результат

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

Ограничения и основание проверки

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