Анкит Джайн, соучредитель и генеральный директор Aviator, рассказывает на портале The New Stack о том, почему контекстом вашего ИИ-агента следует управлять как ПО и как цикл разработки контекста улучшает качество навыков, тестирование и масштабируемость.

Навыки, конфигурации агентов, инструкции к промптам и файлы правил. Эти артефакты теперь определяют то, что создают ваши агенты по кодированию. Они определяют каждую строку сгенерированного кода, каждое архитектурное решение, каждое соглашение, которому агент следует или которое игнорирует. По сути, это ПО.

Но никто к ним так не относится. Команды пишут навыки, добавляют их в репозиторий и никогда не проверяют, работают ли они после обновления модели. Конфигурации агентов копируются и переносятся между командами без версионирования. Файлы правил теряют синхронизацию с кодовой базой, которую они описывают. Когда что-то ломается, об этом сигнализирует разработчик, заметивший странный вывод и пожаловавшийся в Slack.

Независимый ИТ-консультант Патрик Дюбуа предложил концепцию того, чего не хватает: цикл разработки контекста (Context Development Lifecycle, CDLC). CDLC — это не управление окном контекста или размещение большего количества токенов в запросе. Речь идёт об управлении качеством элементов, которые попадают в контекстное окно. Актуален ли навык? Действительно ли модель правильно реагирует на него? Предоставляете ли вы контекст, который модель уже знает? Если контекст — это новый код, каков его жизненный цикл разработки?

Четыре фазы жизненного цикла разработки контекста

CDLC имеет четыре фазы, которые напрямую соответствуют тому, что мы уже делаем с кодом.

Генерация — это то, с чего все начинают. Написание навыков, создание конфигураций промптов, настройка правил агента. Это эквивалент написания кода, и именно на это сегодня уходит бóльшая часть времени.

Оценка — это тестирование. Проверка правильности линтинга во фронтенде или не слишком ли длинный синтаксис. На более сложном этапе вы запускаете сценарии: загружаете навык, задаёте конкретный вопрос, проверяете, выдаёт ли агент ожидаемый результат. Вы тестируете разные модели и версии. Вы проверяете, не пишете ли вы контекст, который модель уже знает, что приводит к нерациональному использованию токенов. Вы проверяете, активируется ли навык по правильным ключевым словам.

Это цикл разработки через тестирование (TDD) для контекста. Пишите навык, пишите сценарий, проверяете результат, итерируете.

Дистрибуция — это доставка. На самом простом уровне это добавление навыка в репозиторий. На более зрелом уровне команды публикуют навыки в установленный реестр с версионированием, возможностью обнаружения и контролем доступа. Вставка навыка в канал Slack — это не дистрибуция, так же как отправка файла .jar по электронной почте — это не управление зависимостями.

Наблюдаемость — это мониторинг производственной среды. Используется ли навык? Выдает ли он правильные результаты? Сколько итераций проходит агент, прежде чем вмешается разработчик? Где разработчики переопределяют агента или исправляют его вывод? Это наблюдаемость для вашего контекста.

Не пропускайте тестирование

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

Это напрямую сравнимо с тем, как команды игнорируют разработку через тестирование, несмотря на указания делать это. Они не знают, что такое боль, поэтому сразу передают в производство.

Боль возникает, когда навык работает в одной версии модели, но ломается в следующей, или когда он срабатывает на неправильный вопрос и дает разработчику заведомо неверные инструкции. Когда соглашение, которое навязывал навык, было правильным полгода назад, но кодовая база с тех пор изменилась. Это те же самые режимы сбоев, которые мы видим в непротестированном коде. Регрессии, ложные срабатывания, устаревшие предположения.

В каждой кодовой базе есть шаблоны, в которых ИИ постоянно ошибается. Слепота к соглашениям, галлюцинаторные API, код карго-культа, избыточное проектирование. Мы называем это инвариантами, или реестром ошибок ИИ. И реестр навыков, и реестр ошибок ИИ иллюстрируют один и тот же основополагающий принцип на обоих концах жизненного цикла разработки: каталогизируйте свои инженерные стандарты и передавайте их агентам.

До генерации кода это означает навыки. На этапе проверки кода это каталог шаблонов, в которых ИИ постоянно ошибается на вашей кодовой базе. Реестр ошибок служит основой для автоматизированных проверок, выявляющих все, что осталось незамеченным. Вы не можете масштабировать качество кода, требуя от людей более тщательной проверки. Вы масштабируете его, инвестируя в механизмы контроля, которые кодифицируют ваши стандарты на обоих концах.

От 1x до 50x

Разработчик, оптимизирующий собственный цикл работы агента, получает лучшие индивидуальные результаты, но это улучшение остается с ним. Когда он исправляет ошибку в навыке, никто другой от этого не выигрывает. Когда он обнаруживает ошибку, никто другой извлекает из этого урок. ROI здесь однократный (1x).

Дюбуа схематизирует вопрос масштабирования, используя две метрики, которые лежат в основе традиционных показателей DORA.

Первая — это участие человека: как часто разработчику приходится вмешиваться в рабочий процесс конкретного агента? Каждое вмешательство — это сигнал о том, что контекст отсутствует или неверен. Сокращение участия человека — это прямой показатель того, насколько автономен цикл кодирования вашего агента, и он часто коррелирует со стоимостью, поскольку больше циклов означает больше затрат на агентов.

Вторая — это эффект повторного использования: сколько разработчиков получают выгоду от улучшения одного навыка? Если один разработчик исправляет навык, и только он получает от этого выгоду, это 1x. Если это исправление попадает в общий реестр, и его получают 50 разработчиков, это 50x.

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

Ваша команда платформы уже знает, как это делать

Организационная структура для этого уже существует. Платформенные команды потратили десятилетие на создание инфраструктуры, позволяющей командам разработчиков надежно выпускать код: системы контроля версий, конвейеры CI/CD, реестры артефактов, сканирование безопасности, управление зависимостями и контроль доступа. Этот подход практически напрямую применим и к разработке контекста.

То, что команда платформы делает для репозиториев кода, она делает и для навыков. Предоставляет реестр. Настраивает контроль доступа и разрешения для групп. Создает инфраструктуру для оценки. Запускает сканирование безопасности и сообщает о результатах. Создает дашборды, показывающие, какие навыки работают хорошо, а какие ухудшаются. Отслеживает ответственность, чтобы, когда навык ломается после обновления модели, был ответственный за его исправление.

Чего команда платформы не делает, так это не пишет навыки и не исправляет их, когда они ломаются. Команда, которая владеет предметной областью, владеет и навыком. Команда платформы предоставляет уровень управления и инструменты, здесь то же самое разделение ответственности, которое работает и для кода.

Проблема «осиротевших навыков» уже начинает проявляться. Разработчик пишет навык, делится им, переходит в другую команду, и теперь никто его не поддерживает. Обновление модели приводит к сбою, и команда платформы по умолчанию наследует эту проблему. Это снова история с осиротевшими репозиториями GitHub. Решение то же самое: политики владения, требования к поддержке, пути вывода из эксплуатации.

Советы Дюбуа звучат лаконично: «Не создавайте инструмент. Создайте инструмент, который создает инструмент. Команда платформы создает инструмент для тех, кто создает инструмент, который создает инструмент».

Замыкание цикла с помощью наблюдаемости

Наименее развитый этап в большинстве организаций — это наблюдаемость, хотя он и самый важный. Без него нет системы обучения. Вы вручную генерируете и распространяете контекст, надеясь, что это сработает, и исправляете ошибки, когда кто-то подает жалобу.

Наблюдаемость агентов все еще находится на ранней стадии. Стандарты только формируются. Agent MD уже широко используется. Стандарты навыков и плагинов относительно новые. Инструментарий еще не зрелый, но схема ясна: инструментируйте своих агентов, централизуйте сигналы и анализируйте их в разных командах.

По нашему мнению, петли обратной связи в производственной среде — это недостающий элемент в разработке с использованием ИИ. Когда что-то ломается в производственной среде, отследите это до изменения, определите категорию ошибки и передайте ее обратно как на уровень промптов, так и на уровень проверки. Этап наблюдаемости в CDLC расширяет эту идею от качества кода до качества контекста. Сигналы, собранные из журналов агентов, исправлений разработчиков и подсчета шагов, напрямую используются для создания более качественных навыков, написания более целенаправленных оценок и дистрибуции улучшенных версий.

Самосовершенствующаяся агентная разработка

Полностью замкнутый цикл выглядит как система, в которой журналы агентов используются для анализа, выявляющего пробелы. Эти пробелы генерируют новые навыки или обновления существующих. Обновленные навыки проходят оценку перед выпуском. Они распространяются через реестр с контролем версий. И цикл повторяется.

Дюбуа реалистично оценивает конечный результат. Видение «темной фабрики», где агенты создают код без участия человека, он называет «благородным направлением, но рискованной игрой». Команды, которые приближаются к этому (те, кто может с уверенностью сказать, что они больше не читают код), — это те, кто вложили значительные средства в контекст, тестирование и инфраструктуру наблюдаемости, которые делают их агентов достаточно надежными, чтобы требовать меньшего количество человеческих вмешательств в цикле.