Агент переименовал поле в одном сервисе. Локально всё зелёное, тесты проходят. А два нижележащих микросервиса молча рассинхронизировались, и продакшен сломался. Знакомо? Авторы пишут: модель часто оптимизирует то, что видит перед собой, и не видит системы целиком. Разрыв между «сырым» интеллектом модели и надёжной поставкой это не в первую очередь вопрос качества модели.
Авторы Jaya Simha Reddy Nandyala и Prabina Pani формулируют ключевую формулу: агент это модель плюс обвязка. Модель даёт рассуждение, обвязка даёт структуру, ограничения и обратную связь. Без обвязки даже сильная модель выдаёт локально красивый и системно опасный результат.
Что входит в обвязку
Обвязка состоит из двух слоёв и точечных человеческих шлюзов. Первый слой — это направляющие: они действуют до действия агента и задают рамки. Второй слой — это датчики: они проверяют результат после действия. Человек подключается только там, где цена ошибки высока. В материале Thoughtworks как примеры необратимых решений названы изменение контракта между несколькими репозиториями, миграции схемы и правки публичного API.
Направляющие: что ограничить заранее
Четыре приёма из материала Thoughtworks.
Инструкции с ограниченной областью действия. Один большой файл правил на все случаи быстро забивает окно контекста и размывает внимание модели. Правила грузят только когда агент трогает релевантную область: например, правила для схемы подгружаются при работе с файлами схемы. В материале это называют прогрессивным раскрытием: документацию обходят по дереву по мере надобности, а не загружают заранее.
Инструменты с минимальными привилегиями. Просить модель «не пушить код» в промпте ненадёжно. Агент для проверки кода или ответов на вопросы лучше просто лишить возможности писать файлы. Запрет становится структурным, а не словесным.
Явные умолчания вместо догадок. Когда входной параметр опционален, обвязка требует явного «пропустить» и фиксирует это решение. Догадка спрятана и опасна; умолчание видно и проверяемо.
Подтверждение только там, где последствия необратимы. Если меняется контракт между сервисами — нужен человеческий шлюз. Низкорисковые решения идут с разумными умолчаниями.
Датчики: что проверить после действия
Датчики — это обычные проверки из инженерии, встроенные в цикл работы агента: юнит-тесты, линтеры, проверка типов, архитектурные правила. Авторы предлагают правило «тихий успех, громкий провал». Когда проверка прошла минимум вывода, чтобы не тратить токены и внимание. Когда упала подробный отчёт со стектрейсом, ошибками линтера и diff падающих тестов, который агент получает обратно и сам исправляет.
Авторы советуют продвигать правила из прозы в код. Если команда раз за разом дописывает в промпт «не забывай про X», это сигнал, что правило пора превратить в линтер или архитектурный тест. Прозаическое правило — это стартовая точка; механическое — более сильный вариант.
Как работает обвязка в пайплайне
Авторы показывают это на примере с тремя микросервисами: billing-service владеет полем discount_rate, а checkout-service и invoicing-service это поле читают. Без общей обвязки агент внутри одного репозитория переименует поле локально, свои тесты пройдут, а два нижележащих сервиса молча рассинхронизируются. С общей обвязкой тот же запрос проходит иначе.
Сначала агент сканирует граф зависимостей по всем репозиториям и видит, что правка в billing-service затрагивает ещё два сервиса. Обвязка понимает, что правка выйдет за рамки одного репозитория, и останавливает выполнение перед человеческим шлюзом подтверждения. После одобрения агент обновляет контракт и код сразу в трёх репозиториях и прогоняет мультисервисные тесты, чтобы проверить согласованное изменение.
Почему это работает
Авторы описывают главный сдвиг так: просить модель быть осторожной принципиально отличается от среды, где нарушения предотвращаются или ловятся механически. Обвязка действует в обе стороны: до действия сужает пространство решений и неявные правила переводит в явные ограничения; после действия даёт автоматический сигнал вместо самооценки модели. Авторы называют это ограниченной автономией и сбалансированным контролем.
Как применить
- Возьмите последние пять сбоев агента в вашем проекте. Выпишите, какие из них можно было поймать линтером, тестом или проверкой прав доступа, а не человеком.
- Для каждого правила, которое живёт в системном промпте, решите: это правило можно закодировать? Если да — переносите в линтер, type check или отдельный скрипт, а из промпта удаляйте.
- Разделите инструменты агента по принципу минимальных привилегий: агенту-ревьюеру только чтение, агенту-имплементатору файлы и тесты, но без команды на деплой. Права выдаются кодом обвязки, а не просьбой в промпте.
- Правила в файлах обвязки грузите скоупированно: только когда агент работает с релевантной частью проекта. Общий «монолит правил» размывает внимание модели и стоит дороже по токенам.
- Человеческое подтверждение оставьте только для необратимых действий: изменение публичного API, миграции схемы, правки в нескольких репозиториях. Механически исправимые сбои пусть закрывают датчики автоматически.
- После каждого релиза модели пройдитесь по обвязке: какие правила больше не нужны, потому что модель стала справляться сама? Удалять лишнее правило стоит дороже, чем кажется.