Современный самолёт умеет долго лететь на автопилоте. Система выдерживает маршрут, высоту и скорость, снимая с экипажа часть рутинной нагрузки. Но из кабины не исчезает пилот. Он выбирает режим автоматизации, следит за ним и должен быть готов вмешаться, если условия изменились или система повела себя не так.
Этот принцип хорошо описан в материалах EASA об автоматизации: она освобождает внимание пилота для принятия решений, но экипаж должен выбирать подходящий уровень автоматизации и контролировать его.1
Примерно к такой модели я пришёл в работе с AI-агентами.
Я не хочу следить за каждой командой в терминале и каждым заполнением контекста. Но и идея «дать агенту задачу и забыть» меня не устраивает. Между постоянным ручным управлением и бесконтрольной автономностью нужен рабочий режим, в котором агент получает свободу внутри заранее определённых границ.
Для себя я называю его AI-автопилотом.
Сначала был один профиль на все проекты
Первое время я работал с Hermes через один профиль. Когда нужно было перейти к другому проекту, я вызывал соответствующий skill.
Такой skill переключал рабочую папку и сразу просил агента прочитать проектную документацию, актуальный план и handoff: короткую запись о текущей фазе, выполненных действиях, известных ограничениях и следующем безопасном шаге.
После этого агент понимал, что мы строим, где находится бизнес-логика, какие решения уже приняты и что нельзя трогать без отдельного согласования.
Эта схема хорошо работает, пока проекты идут последовательно. Но когда я занимался одним проектом, остальные ждали. Один профиль физически не мог одновременно вести несколько длительных задач.
Поэтому я разделил Hermes на проектные профили. У каждого появился собственный контекст, Telegram-бот, история сессий и рабочие правила. Об устройстве профилей, памяти и общей библиотеки skills я подробно писал в статье «Профили Hermes: отдельный контекст, общие навыки».
После разделения проектный агент мог оставаться внутри своего проекта и продолжать согласованный план. Но почти сразу возник следующий вопрос: кто будет следить за самими агентами?
Основной профиль стал диспетчером
Я оставил основной профиль Hermes над проектными агентами. Его задача состоит не в том, чтобы повторно писать за них код. Он следит за ходом длительной работы.
Обычно процесс начинается вручную. Я прихожу к проектному агенту, формулирую задачу, обсуждаю архитектуру, ограничения и критерии готовности. Мы составляем план. Агент начинает работу.
Когда маршрут понятен и безопасная рабочая фаза уже началась, я возвращаюсь в основной профиль и прошу его подхватить управление проектным агентом.
С этого момента основной профиль:
- читает сообщения проектного агента;
- проверяет, соответствует ли работа согласованному плану;
- следит за контекстом сессии;
- организует handoff и переход в новую сессию;
- не разрешает перезапуск во время незавершённой операции;
- проверяет Git, документацию и доступное live-состояние;
- принимает или отклоняет отчёт о завершении.
Так выглядит нажатие кнопки «Автопилот». Я перестаю наблюдать за каждым инструментальным вызовом, но не теряю контроль над маршрутом и критическими точками.
Одного промпта оказалось мало
Правила можно записать в системном prompt, проектной документации и памяти. Я так и делал. Но длинная задача постоянно меняет состояние.
В начале мы только исследуем систему. Затем редактируем код. Потом проверяем dev-контур. Иногда отдельно открываем production. После завершения нужно остановить новые действия, сохранить handoff и убрать временные процессы.
Агенту недостаточно знать общие правила проекта. Ему нужно понимать текущий режим работы прямо сейчас.
Для этого я сформулировал рабочий контракт и вместе с Hermes оформил его в пользовательский плагин Work Governor.
Он добавляет к каждому ходу короткий рабочий контракт:
| Поле | Что оно определяет |
|---|---|
| Project | Какой проект сейчас активен |
| Mode | Идёт аудит, работа с кодом, dev-проверка или production |
| Defaults | Какие действия разрешены в этом режиме |
| Delegation | Можно ли подключать других агентов |
| Completion | Кто и по каким доказательствам принимает завершение |
Вместо одного размытого разрешения «работай» появляются отдельные состояния.
| Режим | Граница работы |
|---|---|
audit | Только чтение и анализ |
code | Локальные изменения без деплоя |
dev | Проверка и выпуск в тестовый контур без production |
prod | Явно открытая работа с production |
wrapup | Фиксация результата и безопасная уборка |
stopped | Новые побочные эффекты запрещены |
done_waiting_owner | Результат принят, агент ждёт нового решения владельца |
Мне нравится эта часть авиационной метафоры. Автопилот не получает абстрактное право «управлять самолётом как угодно». Он работает в выбранном режиме, внутри эксплуатационных ограничений и с понятным способом отключения.
Почему Work Governor пока только наблюдает
Сейчас плагин работает в shadow-режиме. Он добавляет контракт, классифицирует действия и записывает решения would_block, но пока не блокирует каждый подозрительный вызов инструмента физически.
Это намеренное ограничение. Политика безопасности тоже может ошибаться. Если включить жёсткое применение сразу, неверно сформулированное правило способно остановить нормальную работу в самый неподходящий момент.
Сначала я хочу увидеть ложные срабатывания, исправить противоречия и проверить поведение на реальных сценариях. Только после этого можно переводить отдельные правила в режим enforce.
Такой подход кажется мне надёжнее красивого обещания полной автономности. Сначала наблюдение, затем ограниченное применение и лишь потом расширение полномочий.
Handoff — это передача управления
Контекст любой длинной сессии заканчивается. Продолжать работу до последнего токена опасно: модель начинает хуже удерживать ранние решения, а важные ограничения растворяются среди сотен сообщений и результатов инструментов.
Поэтому проектный агент должен вовремя остановиться в безопасной точке и подготовить factual handoff.
В нём фиксируются:
- текущее состояние Git и рабочей ветки;
- что уже сделано и чем это подтверждено;
- какие файлы изменены;
- какие процессы ещё выполняются;
- что запрещено делать без новой команды;
- следующий проверяемый шаг.
Перед новой сессией основной профиль проверяет handoff. В проектном каталоге должен остаться один актуальный документ, без конкурирующих старых версий и без секретов. Затем запускается новая сессия, агент читает handoff и заново проверяет Git и live-состояние.
Это важное различие. Handoff не переносит слепую уверенность старой сессии. Он переносит утверждения, которые новая сессия должна перепроверить по первоисточникам.
Семь часов на автопилоте
Первую полноценную проверку этой схемы я провёл на одном из проектов.
Проектный агент закончил большую локальную фазу и сообщил, что контекст подходит к пределу. Впереди оставались review, commit, CI, merge, выпуск в dev-контур и публичная приёмка.
Я поручил основному профилю вести его дальше до полного завершения плана. Основной профиль запросил handoff, прочитал его обратно, открыл проектному агенту новую сессию и потребовал начать с нового Git-preflight.
Затем он создал периодический надзор. Примерно каждые десять минут отдельный запуск проверял сообщения проектного агента, состояние задачи и ближайший контрольный рубеж. Если агент был занят длительной операцией, надзор не мешал ему и не перезапускал сессию. Если контекст приближался к пределу, применялся тот же протокол: безопасная точка, handoff, read-back, новая сессия.
От передачи управления до принятого завершения прошло около семи часов.
Но важен не сам срок. Основной профиль не ограничился пересылкой оптимистичных отчётов другого агента.
Когда проектный агент объявил работу завершённой, надзор независимо прочитал сообщения, проверил Git и актуальную документацию. Оказалось, что техническая работа действительно закончена, но в канонических документах остались противоречащие друг другу утверждения о текущем состоянии.
Основной профиль не принял completion. Он вернул проектному агенту одну узкую задачу: исправить расхождение, не расширяя scope и не затрагивая runtime. Только после отдельного изменения, проверок и повторного чтения документации работа была принята.
Именно в этот момент схема перестала быть для меня красивой диаграммой. Автопилот поддерживал движение по маршруту и обнаружил, что формально выполненная работа ещё не соответствует критериям завершения.
Остановка не должна создавать новую аварию
У управления агентами есть неприятная тонкость. Фраза «остановись» может означать разные вещи.
Чаще всего я хочу запретить новые действия: не начинать следующий этап, не создавать новый PR, не выполнять deploy. Но это не означает, что нужно оборвать запись файла или убить процесс посередине критической операции.
Поэтому Work Governor различает естественную остановку и принудительную команду /stop.
Обычная фраза «не продолжай» переводит работу в состояние stopped: новые эффекты запрещены, но уже запущенные процессы не уничтожаются автоматически. Принудительное завершение фоновых процессов остаётся отдельным явным действием.
Похожим образом устроено завершение задачи. После принятого completion контракт переходит в done_waiting_owner. Разрешены read-only проверка и безопасная уборка, но агент не может сам придумать следующую задачу. Временный надзор удаляется, а проектный агент ждёт новой команды.
Кто за что отвечает
В этой системе нет одного «самого умного» агента, которому можно передать всё.
| Участник | Ответственность |
|---|---|
| Я | Цель, приоритеты, архитектурные решения, допустимый риск и открытие production |
| Основной профиль | Надзор, handoff, смена сессий, независимая проверка и completion gate |
| Проектный агент | Выполнение согласованного плана внутри проекта |
| Субагенты | Узкие независимые исследования, реализация или review |
| Work Governor | Текущий режим, границы побочных эффектов и переходы между состояниями |
Проектному агенту можно дать постоянное разрешение работать как lead и подключать субагентов. Но такое разрешение не открывает production и не снимает с него обязанность самостоятельно проверить их результат.
Основной профиль тоже не принимает продуктовые решения за меня. Он должен вернуть управление, если изменились условия, возник новый риск или работа вышла за согласованный маршрут.
Что автоматизация действительно изменила
Раньше длительная агентная работа требовала постоянного присутствия. Нужно было замечать заполнение контекста, просить записать handoff, открывать новую сессию, повторять ограничения, следить за CI и разбираться, можно ли верить финальному отчёту.
Теперь значительную часть этой нагрузки берёт на себя основной профиль.
Я всё ещё начинаю задачу сам. Я определяю маршрут и критические ограничения. Я отдельно открываю опасные этапы и принимаю результат. Но между этими точками мне не нужно смотреть на каждую команду.
Это и есть полезная для меня автономность: не отсутствие человека, а правильно выбранное расстояние между его вмешательствами.
Work Governor пока развивается. Shadow-режим нужно пройти на большем количестве сценариев, а правила ещё будут меняться. Проектные агенты тоже ошибаются, как и основной профиль, который за ними наблюдает. Поэтому независимые источники, тесты, Git и публичная приёмка никуда не исчезают.
Я не строю беспилотную разработку. Я строю автопилот, который берёт на себя рутину, соблюдает режимы и возвращает управление там, где требуется решение пилота.
Если вы ведёте несколько проектов и хотите передать AI-агентам длительную работу без потери контроля, я могу помочь разделить проектные профили, настроить handoff и собрать проверяемый контур управления агентами. Опишите вашу задачу.
Sources
1 https://www.easa.europa.eu/sites/default/files/dfu/sms-docs-EASp-SYS5.6---Automation-Policy---14-Jan-2013.pdf — EASA Automation Policy: Bridging Design and Training Principles
