Anthropic научила Claude строить приложения часами: три агента и 4 критерия

Anthropic опубликовала инженерный разбор того, как строить harness для длинных автономных сессий кодинга. Автор, Prithvi Rajasekaran из команды Labs, несколько месяцев решал две связанные задачи: заставить Claude делать сильный фронтенд-дизайн и собирать целые приложения без участия человека. Итог: трёхагентная архитектура planner–generator–evaluator, которая в многочасовых сессиях выдаёт насыщенные full-stack продукты. Принцип заимствован у генеративно-состязательных сетей (GAN).

Где ломаются одиночные агенты

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

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

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

Дизайн: четыре критерия вместо «красиво»

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

• Design quality: цельность настроения и идентичности, а не набор деталей.
• Originality: осознанные авторские решения вместо шаблонов, дефолтов библиотек и «AI-слопа» вроде фиолетовых градиентов на белых карточках.
• Craft: типографская иерархия, отступы, контраст. Здесь Claude и так силён.
• Functionality: удобство независимо от эстетики.

Вес выставили в пользу качества и оригинальности, потому что именно там модель выдавала пресные результаты. Оценщика откалибровали few-shot примерами с разбором баллов, чтобы не плыли оценки. Цикл собрали на Claude Agent SDK. Оценщик получил Playwright MCP, сам ходил по живой странице, делал скриншоты и писал критику. Один прогон занимал 5–15 итераций и до четырёх часов.

Любопытно, что формулировки критериев влияли на результат сильнее ожидаемого. Фраза «лучшие дизайны уровня музея» сводила работы к определённой визуальной стилистике. Улучшение шло не строго линейно, и автор нередко предпочитал промежуточную итерацию финальной. В примере с сайтом голландского музея на девятой итерации получилась аккуратная тёмная посадочная страница. На десятой модель отказалась от неё и сделала 3D-комнату с шахматным полом на CSS perspective, картинами на стенах и навигацией через дверные проёмы.

Три агента для full-stack

Для разработки приложений роль дизайн-оценщика взяли на себя QA и код-ревью. Opus 4.5 в значительной мере убрал «тревогу контекста», так что сбросы убрали: сессия идёт непрерывно, а рост контекста гасит автоматическая компакция SDK.

Planner превращает запрос из 1–4 предложений в полную продуктовую спецификацию. Его намеренно держали на уровне продукта и высокоуровневой архитектуры: ошибка в гранулярных технических деталях каскадом пошла бы в реализацию. Generator работает спринтами, по одной фиче, на React, Vite, FastAPI и SQLite (позже PostgreSQL), с git и самопроверкой перед передачей QA. Evaluator через Playwright MCP кликает по запущенному приложению как пользователь, проверяет UI, API и состояние базы. Оценивает баги и критерии: глубина продукта, функциональность, дизайн, качество кода. У каждого критерия жёсткий порог, и провал любого проваливает спринт.

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

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