Как Cockroach Labs сокращала инструкции

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

В истории Cockroach Labs на HN я узнал похожую проблему с другой стороны: инструкции копятся, а проверять их как код начинают позже.

В статье Cockroach Labs про MOLT Sinai авторы описали аудит 25 skill-файлов объемом больше 100 тысяч слов. Около 23 тысяч слов, то есть примерно 23%, они отметили как удаляемые без изменения обязательных проверок, команд, шаблонов и контрольных маркеров. Это количественная оценка текста, помеченного аудитом. Она не измеряет сэкономленные токены или деньги. Соавтор уточнил на HN, что при первом проходе агенты действительно убрали около 18% текста. Критерии проверки составил человек; команды, пороги и шаблоны менять запрещалось, различия проверяли отдельно.

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

Три предложения вместо проверки существующего

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

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

Конкретный пробел нашли в проверенном снимке от 9 октября: сохранение baseline - результата для будущего сравнения - теряло счетчики прогонов. Ошибка запуска оценщика и содержательный отказ сценария возвращали одинаковое False, хотя причина различалась текстом. Получился один бриф на доработку хранения и типов исходов вместо трех широких предложений. На этом этапе действующие правила не меняли.

Восемь проверок на отдельном Linux-сервере работали с искусственными данными и подмененными ответами процесса. Они проверили механику учета. Живые модели, производственные задачи и качество оценщика не проверялись. Мой пилот не измеряет пользу нового правила или надежность живого агента. Он показывает, какую конкретную доработку имеет смысл обсуждать.

Сначала найти воспроизводимый пробел

В следующем предложении я бы начал с пяти строк:

• Наблюдаемый сбой и вход, на котором он повторяется.

• Механизм, который уже регулирует это поведение.

• Точное место и минимальный объем изменения.

• Проверка, которая отличит исправление от прежнего поведения.

• Статус: идея, бриф или принятое решение.

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

В моем случае эта проверка сократила объем предложения. Дописывать общую инструкцию про повторы не требовалось: повторные прогоны уже работали. Требовалось сохранить их результаты так, чтобы их можно было сравнить.

Как вы проверяете новое правило для агента перед добавлением: на воспроизводимом сбое, по ревью текста или уже после очередной ошибки?