Границы вместо инструкций: как сохранять контроль над автономными AI-агентами

Чем автономнее становятся AI-агенты, тем чаще мы пытаемся управлять ими привычным способом — пишем в промпте правила: «не трогай это», «работай только там», «никогда не делай того». Во время эксперимента с тремя параллельными агентами я за два дня собрал живую коллекцию случаев, где этот способ ломается — и где работает другой. Тезис статьи простой: инструкция — это просьба, которую агент исполняет с некоторой вероятностью; граница — свойство системы, которое от послушания не зависит. Пока агент был один и работал под присмотром, разница казалась стилистической. Когда агентов стало много, она оказалась архитектурной.

Пять инцидентов одной сессии

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

Инструкции не было — случилась авария. Агент, готовясь к своей задаче, выполнил git stash в общем каталоге и унёс в стэш мои незакоммиченные файлы, к его задаче не относившиеся. Никто ничего не «нарушил»: запрета просто не существовало. Это фундаментальное свойство инструкций — их пишут после аварий. Полный список того, чего агент не должен делать, написать невозможно.

Инструкция была — и не сработала. После первой аварии я добавил агентам явное правило: «работай строго в своей рабочей директории». Один из агентов всё равно выполнил git-команду в основном каталоге — просто обратился к нему по абсолютному пути. Не со зла и не от глупости: модель вероятностна, и соблюдение текстового правила — тоже вероятность, помноженная на длину контекста и число прогонов.

Техническая граница сработала молча. В том же эксперименте ни разу не случилась самая ожидаемая авария — «один агент переключил ветку всем». Не потому, что агенты были аккуратны, а потому, что git worktree физически не позволяет выписать одну ветку в две рабочие копии. Защита встроена в инструмент. Её не нужно помнить, ей не нужно следовать — она просто есть.

Инструкция стояла там, где должна стоять граница. Самое неприятное открытие: прод этого блога охраняла строчка в промпте. Push в master запускает автодеплой, и от каждого агента его отделял только текст «никакого git push». Он держался — но это везение, а не контроль: настоящая граница здесь — права доступа, protected branch, токен без права записи. Просьба стояла на месте замка.

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

Принцип не новый — новая только сущность

Инженерия проходила этот урок задолго до LLM. В производственной системе Toyota принцип называется poka-yoke: ошибку предотвращает устройство процесса, а не бдительность исполнителя. Деталь, которую можно вставить только правильной стороной, надёжнее плаката «вставляй правильно». В платформенной инженерии то же самое называют guardrails, в безопасности — defense in depth. Везде одна мысль: не полагайся на то, что исполнитель прочитал, понял и не забыл — сделай так, чтобы неправильное действие было невозможным или дорогим.

“Инструкция — это просьба. Граница — это свойство системы. Контроль, который держится на просьбах, — это не контроль, а везение с накопительным эффектом.”

– главный вывод двух дней работы с параллельными агентами

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

Как выглядят границы на практике

Слои, которые я выстроил после этой сессии — от файловой системы до верификации:

• Файловая система: каждому агенту — собственная рабочая копия (git worktree, который Anthropic рекомендует для параллельных сессий, в Claude Code он встроен), а на уровне ОС — песочница: sandboxing в Claude Code изолирует файловую систему и сеть штатными примитивами ОС — по данным Anthropic, это сократило их внутренние запросы разрешений на 84%, а успешная prompt-injection остаётся запертой внутри.
• Права на запись: прод и master защищаются правами, а не промптом — protected branch, токены без права push, отдельные учётки для агентов. Просьбы оставить в промпте можно, но как второй слой.
• Runtime: worktree не изолирует базы, порты и контейнеры — они общие у всех копий. Агентам, которые запускают тесты и серверы, нужны одноразовые ресурсы: временная БД, свой порт, контейнер на агента.
• Разрешения на действия: необратимые операции проходят через подтверждение или классификатор — как auto mode в Claude Code, который оценивает каждое действие вместо того, чтобы либо спрашивать обо всём, либо не спрашивать ни о чём. Это граница, которая двигается только явным решением человека.
• Верификация по артефактам: доверять не самоотчёту агента, а следам на диске. Мой зависший агент выглядел в интерфейсе работающим; диагноз поставило отсутствие новых файлов в его копии за двадцать минут. Коммиты в собственную ветку — та же идея: результат, который переживает и сбой, и оптимизм агента.

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

Честные оговорки

Граница — не абсолют: песочницы обходят, классификаторы ошибаются, и опубликованные разборы обходов это регулярно показывают. Поэтому границы строят слоями — как и всё в безопасности. И граница стоит дороже инструкции на старте: настроить worktree, права и песочницу — это часы, написать строчку в промпт — секунды. Асимметрия в другом: граница оплачивается один раз, инструкция — вероятностью отказа на каждом прогоне. У меня настройка изоляции окупилась первым же перезапуском эксперимента, который прошёл без единого конфликта.

Вывод

Вопрос серии — как встроить AI-агентов в реальную работу, не теряя контроль. Ответ этой статьи: контроль — это не то, что написано агенту, а то, что устроено вокруг него. Прежде чем добавлять в промпт очередное «никогда не делай X», стоит спросить себя: а можно ли сделать X технически невозможным? Если да — это и есть правильное место для усилий. Промпт пусть просит; запрещать должна система.

Источники и ориентиры

• Making Claude Code more secure and autonomous with sandboxing (Anthropic Engineering) — изоляция файловой системы и сети на уровне ОС; источник цифры 84%.
• How we contain Claude across products (Anthropic Engineering, 2026) — как устроены границы исполнения в агентных продуктах целиком.
• How we built Claude Code auto mode (Anthropic Engineering) — классификатор разрешений как граница между «спрашивать обо всём» и «не спрашивать ни о чём».
• Poka-Yoke (Lean Enterprise Institute) — классический принцип предотвращения ошибок устройством процесса.
• git-worktree и git-stash — официальная документация Git: механика рабочих копий и общего стэша.
• Claude Code: Best practices for agentic coding (Anthropic Engineering) — рекомендация worktree для параллельных сессий.
• Как честно сравнить LLM на своём коде: эксперимент с тремя моделями Claude — предыдущая статья серии: эксперимент, в котором собраны описанные инциденты.