Агенты-исполнители против наблюдателей: кто чем рискует

Летом 2025 года история с агентом Replit, который во время демо удалил рабочую базу данных, а потом ещё и "признался", что запаниковал, разошлась по всем техническим лентам. Урок из неё простой: разница между агентом, который предлагает действие, и агентом, который его выполняет, — это разница между испорченным днём и уничтоженным продакшеном. Выбор режима автономности перестал быть вопросом удобства и стал вопросом управления рисками.

Практически все инструменты, где сегодня встречается слово "агент" — от Claude Code и GitHub Copilot до автономных браузерных ботов — крутятся вокруг одной оси: насколько самостоятельно система переходит от анализа к действию. На одном конце оси агент-наблюдатель, который только смотрит, читает и советует. На другом — агент-исполнитель, который сам меняет мир: пишет в файлы, делает коммиты, отправляет письма, тратит деньги.

Две крайности одной оси

Агент-наблюдатель

Такой агент подключается к вашему коду, почте, календарю или данным на чтение. Он анализирует, суммирует, находит проблемы, предлагает варианты — но финальное действие остаётся за человеком. Классический пример — ревью пул-реквеста: агент читает диф, оставляет комментарии, но кнопку merge жмёте вы.

Плюс очевиден: цена ошибки близка к нулю. Худшее, что случится, — вы получите бесполезный совет и проигнорируете его. Минус тоже очевиден: экономия времени ограничена. Вы всё равно в петле на каждом шаге, а если предложений много, разбор рекомендаций сам по себе становится работой.

Агент-исполнитель

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

Разница между наблюдателем и исполнителем — это не про интеллект модели, а про то, кто держит руку на рубильнике. Более умная модель в режиме исполнителя ошибается реже, но каждая её ошибка обходится дороже.

Что на самом деле выбирают

В реальных продуктах чистых крайностей почти нет. Есть спектр с промежуточными режимами, и именно они интереснее всего.

• Read-only. Агент видит всё, меняет ничего. Безопасно, полезно для аудита и разбора.
• Suggest-and-confirm. Агент готовит конкретное действие (диф, черновик письма, команду) и ждёт одобрения. Компромисс: работу делает он, ответственность на вас.
• Autonomous с гардрейлами. Агент действует сам, но в песочнице: ограниченные права, лимиты на суммы, запрет на необратимые операции без подтверждения.
• Full autonomy. Полная свобода в рамках задачи. Оправдана только там, где ошибка дёшева и обратима.

Сравнение по параметрам

Как выбрать режим под задачу

Три вопроса, на которые стоит ответить до того, как выдать агенту права:

1. Обратимо ли действие? Отправленное письмо, потраченные деньги, удалённые данные без бэкапа — необратимы. Для них дефолт — подтверждение человеком, даже если это замедляет процесс.
2. Насколько чётко очерчена задача? "Отсортируй входящие по папкам по этим правилам" — узкая и проверяемая. "Разберись с моей почтой" — размытая, и исполнитель здесь опасен, потому что сам додумает, что значит "разобраться".
3. Есть ли откат и лог? Если каждое действие агента фиксируется и его можно отменить (git, корзина, черновики вместо отправки), планка автономности поднимается безопасно. Без отката — держите агента на коротком поводке.

Гардрейлы, а не режимы

Практический вывод: спорить "исполнитель или наблюдатель" во многом бессмысленно. Правильнее строить исполнителя с ограничениями, которые превращают дорогую ошибку в дешёвую.

• Работа в песочнице или на копии данных, а не на боевой системе.
• Отдельный аккаунт с минимально необходимыми правами^*, а не ваш личный с полным доступом.
• Явные лимиты: максимальная сумма транзакции, число писем в час, запрет на команды удаления без подтверждения.
• Полный лог действий, который можно прочитать после — что именно агент сделал и почему.
• Точки обязательного подтверждения на необратимых шагах, даже в автономном режиме.

История с Replit случилась не потому, что агент был "слишком умным" или "слишком глупым", а потому что у него был доступ к боевой базе без изоляции. Наблюдатель не удалил бы её просто потому, что не имел прав. Исполнитель с гардрейлом упёрся бы в запрет на destructive-операцию. Проблема была в архитектуре доверия, а не в природе агента.

^* Принцип наименьших привилегий — подход к безопасности, при котором учётной записи или процессу выдаются только те права, что нужны для конкретной задачи, и ничего сверх. Агенту для сортировки почты не нужен доступ к её удалению.