Журнал SkillMetric

Обвязка агента для длительной разработки приложений

Планировщик, генератор и оценщик: передача контекста, критерии дизайна, контракты спринтов, проверка приложений и расходы экспериментальных запусков.

Как довести замысел до работающего приложения

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

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

В опубликованном 24 марта 2026 года эксперименте Anthropic такую систему проверяли на двух разных задачах: создании выразительных интерфейсов и разработке полноценных приложений. Работа продолжала эксперименты с навыком `frontend-design` и средой для длительного программирования. Для интерфейсов использовалась пара «генератор — оценщик», для приложений к ней добавили планировщик. Различие между внешне убедительным и работающим результатом особенно хорошо видно в двух примерах: редакторе ретроигр и браузерной музыкальной студии.

Почему длинный запуск сам по себе не решает задачу

Первые решения для длительной работы обычно строятся вокруг повторения. Агент получает задачу, делает часть работы и запускается снова, пока не объявит её завершённой. В более раннем эксперименте Anthropic агент-инициализатор превращал спецификацию продукта в список задач, а агент-разработчик реализовывал их по одной функции и оставлял материалы для следующего сеанса. Похожую идею использует подход Ralph Wiggum: скрипты или хуки — действия, запускаемые при определённых событиях, — поддерживают непрерывный цикл итераций.

Такой цикл создаёт возможность работать дольше, но ещё не обеспечивает правильное направление работы. В эксперименте выделились две устойчивые проблемы.

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

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

Эти проблемы требуют разных механизмов. Состояние длинной работы нужно сохранять и передавать, а результат — проверять по заранее определённым критериям. Дополнительное время полезно только тогда, когда следующие действия опираются на найденные расхождения.

Сжатие и сброс контекста: разные способы продолжить работу

Уменьшить накопившуюся историю можно двумя способами. При сжатии, или *compaction*, ранние части разговора заменяются кратким изложением, и тот же сеанс продолжается с укороченной историей. При сбросе, или *context reset*, контекст очищается целиком, запускается новый агент, а нужное состояние он получает из отдельного документа передачи — *handoff*.

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

Claude Opus 4.5 в этих экспериментах значительно реже демонстрировал описанное поведение. В новой обвязке принудительные сбросы убрали: работа шла непрерывно, а рост контекста обрабатывало автоматическое сжатие в Claude Agent SDK. Это набор средств для запуска агента, предоставления инструментов и управления его выполнением.

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

Пример документа передачи для разработки редактора уровней может выглядеть так:

Такая запись позволяет восстановить ход задачи по проверяемым сведениям. Формулировки «почти готово» или «всё основное работает» не дают следующему агенту достаточного основания для продолжения.

Отдельный оценщик и проверяемая обратная связь

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

Идея была вдохновлена генеративно-состязательными сетями, или GAN: в них создание результата и его оценка выполняют разные роли. В описанной обвязке речь идёт об организации работы агентов во время выполнения задачи. Эксперимент не предполагает обучения новой GAN или изменения весов модели после каждого замечания.

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

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

Как превратить требования к дизайну в критерии

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

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

Оценщика калибровали с помощью нескольких примеров с подробной разбивкой баллов — приёма *few-shot*. Примеры показывали, какие свойства результата соответствуют конкретной оценке. Это помогало приблизить суждения модели к предпочтениям человека и уменьшить дрейф: ситуацию, когда одинаковое качество на разных итерациях получает несопоставимые баллы.

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

Как работал цикл улучшения интерфейса

Оркестрация была построена на Claude Agent SDK. Генератор создавал интерфейс на HTML, CSS и JavaScript по запросу пользователя. Оценщику предоставили Playwright MCP — доступ к инструментам автоматизации браузера через Model Context Protocol, протокол подключения внешних инструментов к агенту.

Оценщик самостоятельно открывал работающую страницу, переходил по ней, делал скриншоты и изучал поведение. После этого выставлял оценки по четырём критериям и писал подробные замечания. Результат передавался генератору для следующей итерации. За один прогон выполняли от 5 до 15 таких итераций; полный запуск мог занимать до четырёх часов. Значительную часть времени требовали действия в браузере.

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

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

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

Показательный пример — сайт вымышленного голландского художественного музея. На девятой итерации получилась аккуратная тёмная посадочная страница. На десятой генератор полностью сменил подход: построил трёхмерную комнату с клетчатым полом средствами CSS-перспективы, разместил картины на стенах и сделал переходы между залами через дверные проёмы. Так последовательная оценка привела к изменению самой модели взаимодействия с сайтом.

Три роли для разработки полного приложения

При переходе к разработке всего приложения к генератору и оценщику добавили планировщик. Каждый агент закрывал определённый недостаток прежних запусков.

**Планировщик** получал короткий запрос из одного–четырёх предложений и разворачивал его в спецификацию продукта. В прежней обвязке подробную спецификацию должен был предоставлять пользователь. Теперь планировщик описывал назначение приложения, пользовательские сценарии, состав функций и техническое устройство на высоком уровне. Ему предлагали мыслить достаточно широко и искать уместные функции ИИ внутри продукта.

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

**Генератор** реализовывал функции по одной, объединяя работу в спринты — ограниченные этапы с согласованным результатом. Использовался стек React и Vite для интерфейса, FastAPI для серверной части, SQLite для хранения данных; позже SQLite заменили PostgreSQL. Git сохранял историю изменений. В конце каждого спринта генератор проводил собственную проверку, затем передавал приложение на отдельную оценку.

**Оценщик** проверял работающее приложение через Playwright MCP. Он выполнял действия пользователя в интерфейсе, проверял точки доступа API и состояние базы данных. Критерии были адаптированы к полноценному продукту: глубина проработки, функциональность, визуальный дизайн и качество кода. У каждого критерия был обязательный порог. Если хотя бы один результат оказывался ниже порога, спринт не принимался, а генератор получал подробное описание проблем.

Контракт спринта связывает замысел с проверкой

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

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

Пример контракта для такого инструмента:

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

Взаимодействие агентов было организовано через файлы. Один агент записывал документ, другой читал его и отвечал в том же файле или создавал следующий. После согласования генератор работал по контракту и передавал результат оценщику. Например, в своём проекте можно разделить `product-spec.md`, `sprint-contract.md`, `qa-report.md` и `progress.md`. Имена здесь иллюстративные; смысл разделения — различать требования, соглашение о текущей работе, наблюдения и состояние выполнения.

Для каждого замечания полезно сохранять привязку к критерию:

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

Редактор ретроигр: один агент и полная обвязка

Первую версию системы проверяли на Claude Opus 4.5. Одному агенту и полной обвязке дали одинаковый запрос: создать редактор двухмерных ретроигр с редактором уровней, редактором спрайтов, поведением объектов и режимом пробного запуска. Спрайт — небольшое изображение игрового объекта; тайл — элемент, из которого собирается карта уровня.

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

Восемь иллюстраций интерфейса ниже — перерисовки по исходным скриншотам.

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

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

Планировщику предоставили навык `frontend-design`. Он прочитал его и включил в спецификацию визуальный язык приложения. Перед каждым спринтом генератор и оценщик уточняли контракт: детали текущей реализации и наблюдаемое поведение, по которому проверялось завершение.

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

Встроенная интеграция с Claude позволяла создавать части игры через запросы на естественном языке. Это ускоряло работу пользователя: часть действий с редакторами можно было поручить ИИ.

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

Какие ошибки находил оценщик

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

Во втором случае оценщик предложил заменить условие обработчика на:

В третьем случае сообщение FastAPI содержало причину: `unable to parse string as an integer`. Такая ошибка показывает, почему проверка API важна даже для визуального редактора: действие пользователя зависит от маршрутизации на сервере. Наличие функции или обработчика в коде не подтверждает, что нужная ветвь действительно вызывается.

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

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

Почему обвязку пришлось упростить

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

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

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

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

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

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

ИИ внутри приложения должен управлять его функциями

Одновременно улучшали промпты для создания встроенных ИИ-функций. Генератор должен был построить полноценного агента, способного вызывать инструменты самого приложения. Для редактора игр это означает связь с созданием и изменением игровых объектов; для музыкальной студии — с дорожками, нотами, темпом и эффектами.

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

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

Браузерная музыкальная студия: результаты обновлённой системы

Следующей задачей стала DAW — Digital Audio Workstation, цифровая звуковая рабочая станция. Это программа для сочинения, записи, аранжировки и сведения музыки. Запрос требовал создать полнофункциональную DAW в браузере с использованием Web Audio API — программного интерфейса браузера для работы со звуком.

Ожидаемый сценарий включал создание мелодий, гармоний и ударных партий, сборку песни и помощь встроенного агента. Планировщик снова превратил одну строку в спецификацию. Генератор продумал приложение и устройство встроенного агента, подключил его и проверил перед QA. Первая сборка продолжалась более двух часов без деления на спринты, которое использовалось с Opus 4.5. Общий запуск занял около четырёх часов и стоил 124,70 доллара в расходах на токены.

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

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

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

В итоговом приложении работали основные элементы музыкальной программы: окно аранжировки (*arrangement view*), микшер и транспортная панель (*transport*) для управления воспроизведением. Встроенному агенту удалось поручить создание короткого музыкального фрагмента: он установил темп и тональность, построил мелодию и ударную партию, отрегулировал уровни микшера и добавил реверберацию.

Как применять этот подход в своей разработке

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

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

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

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

Порядок работы нужно задать и на уровне управляющей программы. Генератор не должен завершать весь процесс собственным сообщением «готово»: после сборки следует проверка. Неуспешная проверка возвращает конкретные замечания, а принятая версия сохраняется вместе с подтверждениями. Упрощённую логику можно выразить таким псевдокодом; имена функций обозначают операции обвязки, а не методы Claude Agent SDK:

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

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

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

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

Пример спецификации планировщика: RetroForge

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

RetroForge — браузерная творческая среда для создания игр в эстетике 8- и 16-битных систем. Она сочетает редактор уровней на основе тайлов, редактор пиксельных спрайтов, визуальное задание поведения сущностей и немедленный запуск игры для проверки. Помощь Claude включена в создание спрайтов, уровней и поведения через запросы на естественном языке.

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

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

Автор и источник

**Максимов Егор Васильевич** исследователь промптов и разработчик

Prithvi Rajasekaran. [Harness design for long-running application development](https://www.anthropic.com/research/harness-design-long-running-apps). Anthropic, 24 марта 2026 года.