Кордони замість інструкцій: як зберігати контроль над автономними 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 — попередня стаття серії: експеримент, у якому зібрані описані інциденти.