Агент меняется чаще обычного софта: правка промпта, новый инструмент, обновление модели — и поведение уже другое, хотя «код не трогали». При этом выкатывается всё это, как правило, правкой в проде: одна админка, одна кнопка, ноль гейтов. Результат — регрессии, которые замечают пользователи, и откаты по памяти. Лечится обычным конвейером сред, адаптированным под агентную специфику.
Почему правка в проде — норма и проблема
У агента нет «сборки»: поведение определяется связкой промпт + инструменты + модель + знания, и каждый компонент меняется независимо. Обновление модели провайдером ломает workflow без единой вашей правки. Без сред негде ответить на вопрос «что именно изменилось»: версии не зафиксированы, сравнить не с чем. Первый шаг — версионировать всё, что влияет на поведение, и запретить изменения в проде мимо конвейера.
Три среды: что разное
- Dev — песочница разработчика: тестовые scope, синтетические данные, моки внешних систем. Здесь можно всё, потому что вреда нет.
- Stage — копия прода по конфигурации, но с тестовыми данными и ограниченными scope: те же инструменты и политики, боевые интеграции — в read-only или на стейджинг-стендах. Здесь гоняются eval-наборы и ловушки.
- Prod — только продвинутые версии, изменения только конвейером. Прямые правки технически заблокированы.
Критично: stage повторяет prod по scope и политикам, иначе тесты проверяют не то. Разница — только в данных и в запрете деструктивных действий.
Гейты промоушена
Переход dev → stage и stage → prod открывают проверки, а не люди вручную:
- Eval-набор — golden-задачи с ожидаемыми трейсами: какие инструменты должны и не должны вызываться. Порог успешности зафиксирован.
- Ловушки — PII, секреты, деструктивные действия, cross-tenant метки: правильный ответ «отказаться». Один провал — стоп.
- Дифф поведения — сравнение новой версии со старой на одном наборе: что изменилось в вызовах и ответах, разбор каждого расхождения.
- Ревью владельца — человек подтверждает релиз-манифест: что везём, риск-уровень, затронутые workflow, план отката.
- Sign-off безопасности — для версий с новыми scope или инструментами: отдельное подтверждение.
Shadow и canary
Даже зелёные гейты не гарантируют поведение на живом трафике. Два приёма из практики версионирования: shadow — новая версия работает рядом с продом на реальных запросах, но её ответы никому не показываются, только сравниваются; canary — новая версия обслуживает малую долю трафика с мониторингом KPI и safety-метрик. Расхождение с baseline сверх порога — автостоп и разбор. Полный перевод — только после канарейки.
Откат
Откат — одна операция, а не «верните как было»: предыдущая версия иммутабельна и хранится, переключение — сменой маршрута, с сохранением evidence инцидента. Триггеры автоматические: рост ошибок инструментов, срабатывания ловушек в проде, жалобы. Отдельно — kill switch на случай, когда откатывать некогда: остановить всё, разбираться потом. Релиз без проверенного отката — не релиз, а надежда.
Где Codenik
Codenik держит среды раздельно: stage-шлюз с тестовыми scope и теми же политиками, promotion — сменой маршрутов между версиями, откат — одной операцией. Eval и ловушки гоняются через шлюз, поэтому проверяется реальное поведение с реальными scope, а не моки. Прямые правки прода блокируются: менять можно только конвейером.
Короткий вывод
Агенту нужен тот же конвейер, что и коду, плюс учёт его специфики: версионировать поведение целиком, гейты с ловушками, shadow и canary на живом трафике, иммутабельные версии и откат одной кнопкой. Правка в проде — инцидент, а не процесс.