Версионирование промптов: как не сломать мультиагентную систему

Почему промпт нужно версионировать так же, как код

Команда меняет одну фразу в системном промпте координатора — и агент-исполнитель, который зависел от строгого формата JSON на выходе координатора, начинает отдавать текст с пояснениями. Пайплайн падает не там, где правили, а через два узла ниже по цепочке. Логов достаточно, чтобы увидеть сбой, но недостаточно, чтобы понять, какая именно правка промпта его вызвала — потому что правку никто не фиксировал отдельно от остального деплоя.

В одноагентном чат-боте с этим ещё можно жить: промпт один, автор один, откат — это git revert по коммиту. В мультиагентной системе промптов десятки, они ссылаются друг на друга через формат данных, а меняют их разные люди, включая не-инженеров — продакт-менеджеров и доменных экспертов. Здесь версионирование перестаёт быть гигиеной и становится условием, без которого систему нельзя ни отлаживать, ни катить на прод.

Что именно ломается без версий

Три типовых сценария, из-за которых команды приходят к версионированию промптов уже после первого болезненного инцидента.

• Тихий регресс. Правка улучшила поведение на одном классе запросов и незаметно ухудшила на другом. Без привязки метрик к конкретной версии промпта вы узнаете об этом из жалоб пользователей, а не из дашборда.
• Нет отката. Промпт лежит строкой внутри деплоя приложения. Чтобы вернуть прошлую версию, нужно откатывать весь релиз — вместе с исправлениями, которые к промпту отношения не имеют.
• Рассинхрон между агентами. Агент A ждёт от агента B ответ в старом формате, а B уже обновили. В монолитном коде это поймал бы компилятор. С промптами — только прод.

Промпт в мультиагентной системе — это не текст, а контракт между агентами. Меняя его без версии и без теста на совместимость, вы меняете API, о котором никто не договаривался явно.

Из чего складывается версионирование промпта

Версионировать одну строку недостаточно. У воспроизводимого запуска агента есть несколько составляющих, и все они влияют на результат:

1. Текст промпта — системный и шаблоны пользовательских сообщений.
2. Модель и её параметры — конкретная версия модели, температура, лимит токенов. Один и тот же промпт на разных версиях модели ведёт себя по-разному.
3. Схема входа и выхода — какой формат агент ожидает получить и обязан вернуть. Именно она и есть контракт между агентами.
4. Инструменты и их описания — набор функций, доступных агенту, и то, как они описаны в промпте.

Если версионировать только текст, а модель и параметры дёргать отдельно, воспроизвести старое поведение не выйдет. Поэтому версия — это снимок всего набора, а не одной строки.

Семантическое версионирование для промптов

Схема major.minor.patch переносится на промпты неплохо, если договориться, что именно считать ломающим изменением:

• major — поменялась схема входа или выхода. Другими словами, сломался контракт с соседними агентами. Такое изменение нельзя катить, не обновив зависимые агенты.
• minor — расширили поведение, добавили обработку нового случая, но старый формат сохранён.
• patch — переформулировка, исправление опечатки, уточнение тона без изменения формата.

Где хранить промпты: три подхода

Выбор влияет на то, кто и как быстро может менять промпт и насколько легко откатиться.

Цены на внешние сервисы меняются часто и зависят от объёма трасс и запросов — актуальные тарифы смотрите на страницах самих продуктов, а не полагайтесь на цифру из статьи. Для небольшой команды разумный старт — промпты как отдельные файлы в git с явной версией в имени или метаданных: почти бесплатно и уже даёт откат и историю.

Тесты, без которых версия ничего не гарантирует

Версия сама по себе не защищает от регресса — она лишь даёт точку, к которой можно вернуться. Защищает набор проверок на каждую новую версию:

• Проверка формата. Выход агента валидируется по схеме. Если контракт нарушен — версия не проходит.
• Golden-набор. Фиксированный набор входов с ожидаемым поведением. Прогоняете новую версию и сравниваете с эталоном.
• Проверка совместимости с соседями. Прогон связки агентов целиком, а не одного в изоляции. Именно здесь ловится рассинхрон форматов.

Оценка выхода LLM редко бывает бинарной, поэтому часть проверок делают через модель-судью^* или через метрики на golden-наборе — но и их результат надо привязывать к версии промпта, иначе снова непонятно, что с чем сравнивать.

Кому это пригодится, а кому нет

Пригодится, если:

• у вас больше двух агентов, которые обмениваются структурированными данными, и любой сбой формата рушит цепочку;
• промпты правят несколько человек, включая не-инженеров;
• система на проде и вам нужен быстрый откат без полного релиза;
• вы измеряете качество ответов и хотите видеть, какая правка что изменила.

Скорее избыточно, если:

• у вас один агент и один промпт, который меняется раз в месяц — здесь достаточно git;
• вы на стадии прототипа и формат ещё не устоялся: жёсткие контракты между агентами будут только мешать искать саму архитектуру;
• промпт не влияет на структуру данных, а лишь на тон ответа для конечного пользователя.

Правило простое: чем сильнее агенты завязаны друг на друга форматом данных, тем раньше стоит вводить версии и тесты совместимости. Стоимость внедрения — часы на настройку реестра и написание golden-набора. Стоимость отсутствия — ночной инцидент, который нечем откатить.

^* Модель-судья (LLM-as-a-judge) — приём, когда качество ответа одной модели оценивает другая модель по заданным критериям. Быстрее и дешевле ручной разметки, но сама оценка тоже подвержена ошибкам, поэтому её калибруют на размеченных примерах.