Даже постоянно работающему агенту нужно условие остановки

29 сентября OpenAI представила dots — агентов, способных продолжать работу на собственных облачных компьютерах. Этот запуск делает конкретным важный вопрос проектирования: если агент может работать после завершения разговора, как он поймёт, что поручение больше не актуально? [1]

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

OpenAI отделяет проактивный поиск dots от последующих действий. В описании защиты сказано, что такой фоновый поиск использует инструменты только для чтения; дальнейшие действия подчиняются обычным правилам и проверкам. Это ограничение конкретного режима поиска нельзя переносить на любую разрешённую задачу, которая продолжается в фоне. [2]

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

Документация OpenAI по MCP Events описывает асинхронную обработку, повторные попытки доставки и возможное поступление событий не по порядку. Она требует сохранять идентификатор события при повторах и делать инструменты записи идемпотентными, чтобы повторный вызов не дублировал изменение. Поэтому подтверждение доставки и завершение порученной работы — разные этапы. Это документированные правила интеграции, а не свидетельство того, что мы проверили конкретный плагин. [3]

В процессе работы с видео два уведомления о загрузке не должны приводить к двум одинаковым публичным публикациям. И старый комментарий рецензента не должен перезаписывать более новую одобренную версию. Один из практических подходов — вместе учитывать исходный объект, его версию и намеченное действие, а перед повторной записью проверять это сочетание. Ответственный должен различать состояния: получено, готовится, ожидает решения, завершено и остановлено. Общая пометка «выполняется» скрывает именно то различие, которое нужно для решения о вмешательстве.

То же руководство по MCP Events требует учитывать окончание срока действия ограниченных по времени подписок и прекращать доставку событий при отзыве доступа. Срок подписки управляет доставкой; сам по себе он не определяет, когда бизнес-цель перестаёт быть актуальной. Эту вторую границу нужно задать отдельно. [3]

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

В разделе вопросов и ответов о dots OpenAI объясняет: отключение плагина прекращает новый доступ, но не стирает уже сохранённый контекст. Там же удаление dot отделено от удаления файлов и разговоров, хранящихся отдельно. Это сведения о конкретном продукте; более общий практический вывод — точно называть состояние, которое меняется. [4]

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

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

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