Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Команды часто считают, что риск автономного агента можно ограничить подтверждением критичных действий человеком. Margaret Mitchell, Avijit Ghosh и Samir Passi утверждают, что этого недостаточно: оператору приходится одновременно следить за планом, инструментами, промежуточными результатами и последствиями действий, а длительная работа с автоматизацией снижает внимание и ослабляет предметные навыки. Авторы предлагают проектировать не только возможности агента, но и «когнитивные опоры» для оператора: контролируемые паузы, подходящие точки подтверждения, восстановление контекста, обучение, ротацию и разделение ролей. Это препринт версии 1, выложенный авторами на arXiv и не проходивший рецензирования.
Что измеряли
Собственного эксперимента, набора данных или сравнительного теста в работе нет. Авторы называют материал position paper: он формулирует проблему, связывает исследования автоматизации и человеко-компьютерного взаимодействия с устройством AI agents, а затем предлагает набор технических и организационных мер.
Предмет анализа — надзор за системами, которые выполняют многошаговые процессы с ограниченным непосредственным участием человека. В отличие от проверки одного ответа модели, оператор такого агента должен учитывать выбранные инструменты, переданные им аргументы, изменения плана, обмен данными между компонентами и уже совершённые действия. В multi-agent-системах добавляются ошибки передачи информации между агентами и оркестратором.
Авторы рассматривают две связанные нагрузки. Первая возникает во время выполнения задачи: человек должен сохранять ситуационную осведомлённость, замечать отклонения и оценивать последствия до того, как агент продолжит работу. Вторая накапливается со временем: передача анализа и принятия решений автоматизации может сокращать практику, необходимую для сохранения предметной квалификации.
Работа опирается на ранее опубликованные исследования и наблюдения из разных областей. Однако авторы не описывают систематический протокол поиска литературы, критерии включения работ или процедуру количественного объединения результатов. Поэтому материал следует читать как аргументированную проектную позицию, а не как метаанализ.
Что показали
Главный вывод авторов состоит в том, что присутствие человека в процессе не равно эффективному контролю. Интерфейс может регулярно запрашивать подтверждение и при этом не давать оператору достаточно информации, времени и когнитивных ресурсов для осмысленного решения.
Повторяющиеся запросы на продолжение работы создают approval fatigue. Если большая часть подтверждений рутинна, оператор начинает применять быстрые эвристики: доверять плану агента как описанию его будущих действий, считать прошедшие тесты достаточным признаком корректности или воспринимать наличие ссылок и уверенный стиль как признаки точности. По позиции авторов, такие сокращения особенно опасны в многошаговом процессе, где ранняя ошибка может повлиять на последующие действия.
Увеличение объёма журналов само по себе проблему не решает. Оператору приходится обрабатывать большой поток разнородной информации быстрее, чем он способен внимательно его проверить. Объяснения также могут создавать ложную уверенность или становиться якорем для решения. Поэтому прозрачность без управления объёмом, моментом показа и структурой информации может увеличить нагрузку вместо улучшения контроля.
Авторы выделяют два уровня вмешательства. На уровне runtime предлагаются стратегические точки трения, action gating, пакетная проверка действий, мониторинг поведения и интерфейсы, помогающие восстановить состояние задачи во время и после работы агента. Смысл таких механизмов — не запрашивать больше подтверждений, а выбирать моменты, когда решение человека действительно может изменить ход выполнения.
На организационном уровне работа предлагает обучение распознаванию усталости, перерывы и ротацию, упражнения для сохранения навыков и назначение операторов с достаточной предметной компетенцией. Отдельная рекомендация — разделять роль проверяющего и роль человека, заинтересованного в быстром одобрении результата. Метрики производительности также не должны наказывать оператора за остановку процесса и дополнительную проверку.
Ограничения
Работа не проверяет предложенные меры в действующей agentic-системе. В ней нет данных о том, насколько action gating, пакетная проверка, перерывы или ротация уменьшают число ошибок, сколько времени они добавляют и как влияют на стоимость процесса. Не определены пороги автономности или риска, при которых конкретная мера становится необходимой.
Авторы не сравнивают несколько интерфейсов на одной задаче и не измеряют качество надзора у операторов разной квалификации. Нет выборки компаний, длительности наблюдения, числа участников или контролируемой группы. Работа также не показывает, как быстро развивается профессиональная деградация именно при использовании AI agents и насколько она обратима после возвращения к ручной работе.
Значительная часть аргумента переносит результаты исследований GenAI, автоматизации и других интерфейсов на agentic-системы. Авторы объясняют, почему многошаговое выполнение может усиливать известные проблемы, но отдельного количественного подтверждения масштаба этого усиления не дают.
Предложенные меры перечислены как направление проектирования, а не как готовый стандарт. В работе нет сравнительной матрицы, позволяющей выбрать архитектуру контроля для конкретной отрасли, уровня риска или частоты операций. Не названы и случаи, когда человеческий надзор следует признать технически или экономически невозможным вместо добавления новых интерфейсных механизмов.
Что это значит
Работа не требует отказываться от agentic-архитектуры, но меняет требования к её внедрению. Если команда уже строит агента с внешними инструментами, разрешениями и необратимыми действиями, одного шага «approve» в плане недостаточно. Надзор следует проектировать как отдельную подсистему с собственными сценариями, состояниями и критериями качества.
На уровне архитектуры это означает разделение действий по последствиям. Операции с файлами, публикацией данных, транзакциями, доступом к закрытой информации и изменением внешних систем требуют заранее определённых точек остановки. Оператору нужен не весь поток внутренней информации, а контекст решения: цель, текущее состояние, уже выполненные шаги, предлагаемое действие и доступные способы отмены или прекращения процесса.
На уровне продукта полезно проверять не только task success, скорость и throughput. Из позиции авторов следует необходимость тестировать, способен ли оператор после длительной сессии объяснить состояние процесса, обнаружить отклонение и безопасно перехватить управление. Конкретных метрик работа не предлагает, поэтому команде придётся определять их для своего процесса.
Для пилота с низкими последствиями выводы статьи скорее добавляют пункты в план наблюдения и UX-тестирования. Для систем, которые получают доступ к критичным данным или могут совершать необратимые операции, они затрагивают саму архитектуру: полномочия агента, журналирование, остановку выполнения, распределение ответственности и график работы операторов.
Практический итог работы — human in the loop нельзя считать готовым механизмом безопасности. Это только заявленная роль. Чтобы она работала, система должна сохранять способность человека понимать происходящее и вмешиваться, а организация — выделять на это время, компетенции и стимулы.
Источники
- AI Agents Push Humans Out of the Loop — Margaret Mitchell, Avijit Ghosh, Samir Passi, arXiv:2608.23642v1.
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
