Харнесс для автономных ИИ-агентов: как довести цикл разработки до результата, а не до зелёных тестов

Автор эссе разбирает, почему простой цикл «дать агенту план, гонять его, пока не позеленеют тесты» ломается, как только задача, вырастить продуктовую способность, которую ещё никто не понимает: тесты защищают только уже известное, а важные провалы лежат за их пределами. Экран может выглядеть готовым, но ничего не сохранять; агент может дать правильный ответ по неправильной причине; система оценки может поощрять поведение, которого не хочет ни один пользователь.

Решение, харнесс (обвязку) из двух агентов и трёх ролей вокруг них. «Агент разработки» меняет код фичи и знает ожидаемый результат. «Водитель» (driver) подходит к фиче через тот же интерфейс, что и обычный пользователь: браузер, API, команду или аппаратный симулятор. «Скорер» читает, что произошло, а «контроллер» на основе этого выбирает следующий пробел для закрытия; состояние решения переносится в репозиторий между сессиями. Если харнесс встраивает второго агента прямо в продукт, этот «продуктовый агент» получает только чистую сессию и те же инструменты, что и пользователь: если он разделит контекст с агентом разработки, тест обесценится, потому что продуктовый агент сможет пройти его со знанием, которого у реального пользователя никогда не будет.

Главный тезис: почти всё важное лежит не в промпте, а в мире вокруг него, данных, сервисах, модели, окружении и версии кода. Харнесс должен уметь воспроизводимо восстанавливать эту точку и доказывать (preflight), что восстановил именно её: если мир нездоров, результат не засчитывается, потому что поломка инфраструктуры, не доказательство провала фичи. Отдельно харнесс прогоняет через свежую сессию один реальный запрос из корпуса, одобренного человеком, и фиксирует не только ответ, но и вызовы инструментов, отклонённые действия и устойчивые эффекты в системе, потому что софт может красиво описать нужное действие, так и не выполнив его.

Автор разводит две разные меры: детерминированный «пол» (тесты, валидаторы, схемы, проверки эффектов), который стартует зелёным и держит уже заработанное поведение, если он покраснел, это становится следующей задачей; и «направление», которое задают более шумные сигналы вроде разбора одного реального запроса, скриншотов или оценки человека. Пол не подсказывает, что строить дальше, для этого нужен разбор конкретного провала.

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

Поскольку автономный цикл будет оптимизировать любую метрику, до которой дотянется, включая плохую, харнесс вводит модель прав из трёх уровней. «Свободные» файлы, обычные рычаги реализации, цикл может менять и измерять их в рамках своей зоны. «Предлагаемые» файлы пересекают границу: цикл может зафиксировать доказательства и предложить изменение, но решение, за человеком. «Замороженные» файлы задают сам экзамен: одобренный корпус запросов, фикстуры, существующие проверки, правила подсчёта очков и рубрика оценки. Цикл может добавить новую регрессионную проверку для замеченного провала, но не может ослабить существующую проверку или понизить порог, и не может в одном раунде менять продуктовый рычаг и меру этого же рычага, иначе он сам себе выставляет оценку. Обученные судьи (например, визуальные) считаются лишь доказательством, а не источником полномочий, пока их ранжирование не совпадёт с повторными оценками людей.

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

Автор выделяет три параллельных цикла разной скорости: продуктовый цикл закрывает один разрыв за раунд; цикл харнесса меняется, когда повторяющиеся доказательства вскрывают изъян самого процесса разработки; цикл направления стоит над обоими, человек читает пачку доказательств и решает, продолжать очередь задач, сменить направление или остановиться. Ничего из этого не может жить только в текущем диалоге с агентом: сессии заканчиваются, контекст сжимается, поэтому команда держит в репозитории небольшой пакет файлов goals/, где LOOP.md фиксирует процесс, а STATE.md обновляется после каждого раунда, это делает сессии одноразовыми, не делая работу забывчивой.

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

Ключевые факты

Простой цикл «план → тесты → фикс» ломается на задачах роста новой продуктовой способности: тесты защищают только уже известное, а важные провалы (пустой экран, правильный ответ по неверной причине, вознаграждение за нежелательное поведение) лежат за их пределами.
Харнесс разводит два агента: «агент разработки» меняет код и знает ожидаемый результат, «продуктовый агент» внутри фичи получает чистую сессию без общего контекста, иначе тест обесценивается.
Раунд харнесса, восемь шагов: восстановить фикстуру, прогнать детерминированный «пол», отправить один одобренный запрос через свежую сессию, зафиксировать поведение и устойчивые эффекты, классифицировать самый крупный разрыв, закрыть его по всей цепочке, добавить проверку, повторить запрос.
Права на изменения разбиты на три уровня: «свободные» файлы цикл меняет сам, «предлагаемые» пересекают границу и требуют решения человека, «замороженные» (корпус запросов, фикстуры, правила подсчёта) цикл не может ослабить ни при каких условиях.
Работают три параллельных цикла разной скорости, продуктовый (один разрыв за раунд), харнесса (меняется при повторяющихся сбоях процесса) и направления (человек решает на границе пачки из обычно трёх раундов: продолжать, сменить курс или остановиться).

Почему это важно

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

Кому это важно

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

Как это применить

Практический рецепт из текста: развести агента разработки и продуктового агента по разным сессиям без общего контекста; завести детерминированный «пол» из тестов и проверок эффектов, который стартует зелёным и не может тихо ослабляться; прогонять один реальный, одобренный человеком запрос через свежую сессию и фиксировать не только ответ, но и устойчивые эффекты в системе; закрывать за раунд ровно один причинный разрыв по всей цепочке от запроса до видимого доказательства; ввести три уровня прав на файлы (свободные / предлагаемые / замороженные), чтобы цикл не мог сам себе занизить планку; хранить процесс и состояние в репозитории (LOOP.md и STATE.md), а не только в текущем диалоге. Автор советует стартовать с минимума, три запроса, одна фикстура, одна команда оценки, один файл процесса, один файл состояния, бюджет в три раунда, и добавлять новый контроль только после конкретного провала, который его оправдал.

Можно ли доверять

Это авторское эссе-продолжение более раннего поста того же автора («The Convergence Problem»), опубликованное на личном блоге и обсуждаемое на Hacker News (26 голосов, 3 комментария на момент публикации). Автор указан, Jarred Kenny, CTO компании Tracktile, но в тексте нет ни названия конкретного продукта, ни какого-либо количественного результата, успешности, экономии времени или сравнения «до/после» для описанной системы; это архитектурное рассуждение и рекомендация, а не отчёт об измеренном эксперименте. Оценивать материал стоит как продуманный дизайн-документ, а не как проверенный на практике результат.

Риски и подводные камни

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

«Агент разработки может предложить новое направление. Но решить, что его собственный результат достаточно хорош, он не может.»

— автор эссе