Google предлагает перестать считать системный промпт текстовым файлом и начать обращаться с ним как с программой: разбивать на модули, собирать, проверять и только потом отправлять агенту. Это не очередная техника формулировки инструкций. Это попытка вынести логику агента из хрупкой простыни текста в нормальный build-процесс.
Для команды, которая только запускает одного агента, идея может показаться преждевременной инженерией. Для бизнеса, где инструкции уже копируются между продуктами, окружениями и сценариями, преждевременным скоро станет как раз отсутствие такого слоя.
Что предлагает Google
В Google Developers Blog описана типичная траектория агентного продукта. Сначала одного системного промпта достаточно: несколько инструкций, пара определений инструментов, один читаемый файл. Затем в него добавляются политики безопасности, отраслевые правила, требования к формату и сценарии эскалации. В итоге весь управляющий слой агента оказывается внутри одного документа.
Google выделяет три режима поломки. Первый: непонятный радиус изменения. Одна добавленная фраза способна повлиять на поведение агента в другом сценарии, а увидеть это по diff сложнее, чем в обычном коде. Второй: дрейф копий. Общие инструкции по работе с внутренними сервисами, PII, безопасностью или эскалациями расходятся по приложениям и постепенно перестают совпадать. Третий: ошибки, отложенные до рантайма. Шаблон может сломаться из-за отсутствующей переменной или неверного пути импорта только в редком рабочем сценарии.
Ответ Google: хранить поведение в модульных skill-файлах, собирать их верхнеуровневым шаблоном и прогонять через транспилятор. На выходе получается полностью развернутый артефакт, который можно тестировать, аудировать и сравнивать до отправки модели.
Сборщик должен проверять отсутствующие импорты, неопределенные переменные и циклические зависимости. Граф зависимостей позволяет обнаруживать рекурсивные импорты, а CI может заново генерировать golden file и сравнивать его с закоммиченным артефактом. Если результаты различаются, сборка падает. Так команда получает проверяемую связь между исходниками в репозитории и тем, что действительно работает в продакшене.
Главная выгода не в красоте промптов
Практический смысл этой схемы в разделении двух вещей, которые сейчас часто склеены: логики поведения и текста, потребляемого конкретным агентом. Модуль может описывать правило эскалации или границу безопасности, а сборочный слой решает, как включить его в итоговый артефакт.
Отсюда возникает и более дешевая миграция между моделями и агентными рантаймами. Google прямо не обещает универсальной переносимости и не приводит расчетов экономии. Но архитектурное следствие понятно: если различия целевых систем локализованы в шаблонах и сборке, менять приходится не каждую копию промпта, а правила генерации артефакта. Это особенно полезно там, где маршрутизация между моделями становится частью продукта, а не разовым экспериментом.
Транспиляция также делает тестирование содержательнее. Команда может проверять не только ответы модели, но и сам состав инструкции: какие модули вошли в сборку, какие переменные подставлены, нет ли лишней зависимости. Радиус изменения становится хотя бы обозримым. Для недетерминированной системы это уже немало.
Но бесплатной надежности не бывает. Собственный prompt build-layer нужно проектировать, версионировать и наблюдать. Ошибка в общем модуле или сборщике получит больший радиус поражения, чем ошибка в одном вручную написанном промпте. Централизация убирает дрейф копий, но одновременно создает центральную точку, к качеству которой придется относиться как к инфраструктуре.
Не все инструкции должны жить в контексте
Google отдельно предлагает progressive disclosure. Стабильный управляющий слой с идентичностью агента и обязательными ограничениями компилируется в базовый промпт. Специализированные навыки агент получает во время выполнения через инструмент, только когда они нужны для задачи. Это сокращает расход контекста и снижает шум от инструкций, не относящихся к текущей работе.
Следующий шаг выглядит еще интереснее: агент может предложить новый skill-модуль после решения незнакомого инцидента, обновить импорты и открыть pull request. Он не переписывает собственные правила на лету. Изменение проходит сборку, валидацию, evals и человеческое ревью как обычный код.
Что делать билдеру сейчас: хранить повторяемую логику отдельно от финальных промптов, определить явные зависимости и собирать артефакты для каждого агента через CI. Не обязательно сразу писать универсальный компилятор. Достаточно перестать считать ручную склейку строк архитектурой.
Маркер зрелости здесь конкретный: смена модели или добавление нового агента не требует копировать и вручную править общие политики. Если команда меняет сборочную цель, прогоняет тесты и получает воспроизводимый артефакт, транспиляция действительно снижает стоимость контура. Если каждый новый рантайм порождает еще одну ветку шаблонов и исключений, build-слой просто превратился в монолитный промпт, только с более серьезным названием.