Двухуровневая автономность агента — рутина автономно, решения через согласование

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

***Паттерн, который я называю Двухуровневая автономность агента. Всё пространство действий агента явно и заранее разделено на два уровня: действия, которые агент может выполнять без одобрения, и действия, которые обязательно проходят через оператора. Разделение — не «всё, кроме критичного», а перечисление, по чату и по направлению, в операционном конфиге агента (в развёртывании OpenClaw — AGENTS.md). Работа агента — понимать, к какому уровню относится действие, и по умолчанию выбирать уровень с согласованием, если есть сомнение.

Механизм — перечисление плюс fallback СТОП. Конфиг перечисляет автономные действия позитивно (подтвердить получение фидбека, отправить статусное обновление, запросить файлы/спеки/референсы у клиента, передать фидбек клиента команде своими словами, проактивно проверить блокеры у команды) и согласуемые действия — также позитивно (результаты работы клиенту, запросы фидбека у клиента, дедлайны, scope, решения, любое упоминание стоимости). Любая ситуация, не покрытая ни одним из списков, запускает третий стейт: СТОП — не отвечать, уведомить оператора, ждать указаний. Двухуровневый список плюс СТОП — это вся модель управления.

Почему один уровень всегда ломается

Один уровень автономии ломается одним из двух способов. Полная автономия ломается через overreach — агент генерирует правдоподобные решения от имени оператора, и чат принимает их как авторитетные; восстановление дорогое, потому что слова уже отправлены. Нулевая автономия ломается через элиминацию — каждый ответ ждёт человека, ценность агента сводится к автокомплиту, оператор перестаёт доверять, что что-то происходит без него.

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

Уровни по чатам

Уровни не глобальные. Агент кейса ведёт три параллельных проекта с тремя разными конфигурациями уровней:

• Швейцарский часовой проект имеет два чата с разной уровневой настройкой внутри одного проекта (см. two-chat-architecture). Внутренний командный чат: полная автономия по координации, статусам, подтверждениям, проверкам блокеров. Клиентский чат: каждый ответ проходит через оператора, включая подтверждение.
• Ритейлерный проект ведёт клиентский чат в третьем режиме — чистое наблюдение. Агент читает всё, отвечает только при прямом обращении небольшим набором подтверждений («приняли», «подумаем — вернёмся», «спасибо, забрали»). Любое суждение — согласуемое.
• Hiring-канал работает как пайплайн — автономность scoped по стадиям воронки, и агент должен эскалировать, когда ответ кандидата не подходит под переход стадии.

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

Уровни по направлению

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

Причина — асимметрия обратимости. Неидеальная внутренняя перепись клиентского сообщения для команды поправляется в командном чате без ущерба. Преждевременное клиентское сообщение — нет.

Что попадает на каждый уровень (рабочий список из кейса)

Автономно — агент кейса делает это без уведомления оператора:

• Подтверждение получения фидбека («Принято, отправила в команду»)
• Статусные ответы на прямой запрос («Статус: Иван дорабатывает правки, ререндер сегодня»)
• Запрос файлов, спек, референсов у клиента
• Передача фидбека клиента команде своими словами (никогда не forward оригинала)
• Проактивные проверки блокеров и прогресса у команды
• Часовое heartbeat-присутствие (молча, если нечего отвечать)

Согласуемо — агент кейса останавливается и уведомляет на этих:

• Результаты команды клиенту
• Запросы фидбека у клиента
• Любое упоминание дедлайнов, scope или обязательств
• Любое упоминание стоимости, дополнительных затрат, цен
• Любое назначение новой задачи члену команды
• Любой ответ на вопрос, сформулированный как решение («как считаешь — стоит ли…?»)
• Любое сообщение с конфликтным тоном в чате

СТОП — всё, что не в одном из списков, включая неоднозначные случаи. Агент не импровизирует.

Протокол СТОП как несущий третий стейт

Двухуровневые системы обычно ломаются на шве: возникает ситуация, не вписывающаяся ни в один уровень, и агент догадывается. Третий стейт — СТОП — несущий элемент. Без него агент трактует out-of-scope-ситуации как автономные по умолчанию («просто вежливо подтвержу») и тихо превышает полномочия.

Правило СТОП: если ситуация не покрыта автономным списком и не покрыта согласуемым списком — не отвечать. Уведомить оператора через приватный канал уведомлений. Ждать инструкции. Работа оператора при настройке агента — перечислить достаточно щедро, чтобы СТОП был редкостью, но не настолько щедро, чтобы автономный уровень накапливал полномочия, которых ему не положено.

В кейсе СТОП срабатывал чаще всего на вопросы о стоимости («сколько за дополнительную анимацию?»), запросы мнения («как думаешь, что делать?») и конфликтные обмены. Ни у одного из этих случаев нет безопасного автономного ответа.

Когда расширять автономный уровень

Автономный уровень должен расти, когда паттерны повторяются достаточно, чтобы их можно было промоутировать. После месяца эксплуатации в кейсе автономный список вырос на три позиции — продвинутые наверх из согласуемого уровня — потому что оператор заметил, что они утверждаются дословно каждый раз. Каждое продвижение пришло с проработанным примером в конфиге: «Статусные ответы вида “X работает по Y, ожидается Z” могут отправляться автономно, если команда подтвердила статус во внутреннем чате за последние 24 часа».

Автономный уровень должен сокращаться — позиции возвращаются в согласуемый — когда инцидент показал, что автономная версия небезопасна. Паттерн здесь тот же, что в incident-driven-configuration.

Где паттерн подходит

• Продакшн-конвейерные агентские системы, где один агент ведёт несколько параллельных контекстов с разной системой управления.
• Customer-facing-копайлоты, которые должны быть быстрыми на FAQ и подтверждениях, но осторожными на всём, что связано с обязательствами.
• Кодовые агенты в общих репозиториях, где автономные мелкие коммиты полезны, а автономные мерджи в main — катастрофичны.
• Операционные агенты для триажа тикетов, где подтверждение и тегирование — автономно, а решения о маршрутизации и закрытии — нет.

Слабее всего в одноразовых агентах без управленческого измерения — one-shot-ресечер-резюмист не нуждается в уровнях, потому что никогда ничего не отправляет третьей стороне.

Три режима отказа

• Уровни без перечисления. Конфиг, который говорит «действуй по обстоятельствам, эскалируй при сомнении», наследует все проблемы одноуровневой автономии, потому что модель интерпретирует «обстоятельства» как «уверенность». Решение: назвать автономные и согласуемые действия позитивно, с примерами, и использовать СТОП для остаточного.
• Одни и те же уровни для всех чатов. Глобальное правило «автономно по статусам, эскалация по стоимости» ломается, когда один из чатов — клиентский чат, где даже статусные ответы требуют проверки. Решение: уровни по чату (и по направлению в чатах, где направление важно).
• Нет стейта СТОП. Агент трактует «не в согласуемом списке» как «автономно». Любая неоднозначность получает вежливый автономный ответ, который технически является решением. Решение: явное правило СТОП; доверять оператору быть на связи.

См. также

• two-chat-architecture — геометрия чатов из кейса, где этот паттерн работает чище всего
• persona-through-prohibitions — голос агента остаётся одинаковым на обоих уровнях; уровни управляют что сказано, персона управляет как
• lock-layer-pattern-paper — preservation как слой; конфигурация уровней — поведенческий родственник identity-preservation
• openclaw-autonomous-agent-paper — полный кейс, где паттерн развёрнут