Посмотрел выступление Anthropic про то, как они собирают агентов, которые могут работать часами.

Схема такая:

planner → agent → evaluator

Это маленькая продуктовая команда из агентов. У каждого своя роль, свой контекст и своя зона ответственности. Но есть важные нюансы.

1. Planner: верхний план и спринты

Planner получает короткий запрос и превращает его в структуру работы:

— что собираем
— какие большие части нужны
— в какой последовательности идти
— какие спринты должны получиться

Важная деталь: planner не расписывает всю техническую реализацию заранее.

Если в начале придумать подробный план на 200 шагов и ошибиться, ошибка потом поедет каскадом через несколько часов работы.

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

2. Agent: сборка следующего спринта

Agent берёт следующий спринт и собирает фичу.

Но перед началом работы он сначала договаривается с evaluator, что именно будет считаться готовым результатом.

Это главный механизм всей системы.

В обычной агентской работе часто бывает так: дал задачу, агент что-то сделал, сам себя проверил, сказал “готово”, а потом выясняется, что половина сценариев не работает.

Anthropic решает это через contract.

3. Contract: договорённость о готовом результате

Agent пишет: я соберу такую фичу, проверять её надо вот так.

Evaluator отвечает: добавь такой сценарий, такой edge case, такое состояние интерфейса, такую проверку.

Они обмениваются markdown-файлами и уточняют критерии, пока не сходятся на contract.

Contract — это список конкретных проверяемых утверждений.

Дальше evaluator проверяет уже не исходный расплывчатый запрос пользователя, а этот contract.

Например, исходный запрос:

“сделай retro game maker”

А contract превращает его в конкретику:

— можно создать новый проект
— есть sprite editor
— есть play mode
— сохраняется состояние
— canvas работает корректно
— основные сценарии кликаются в браузере

В примере Anthropic для одного приложения получилось 27 contract criteria.

Если критерии расплывчатые, critique тоже будет расплывчатой. Agent получает “ну как-то не очень” и не понимает, что именно чинить.

Если критерии конкретные, он видит точную проблему.

4. Evaluator: жёсткая проверка через браузер

Evaluator — это отдельный агент-критик.

Он открывает приложение через Playwright, кликает по интерфейсу, делает скриншоты, проверяет сценарии, пишет критику и отдаёт её обратно agent.

Отдельного критика проще настроить быть жёстким. У него отдельный контекст, отдельная роль и отдельная инструкция.

Agent собирает.
Evaluator атакует результат.

За счёт этого появляется нормальное давление на качество.

5. Финальный цикл

Итоговый процесс выглядит так:

1. planner разбивает задачу на спринты
2. agent берёт следующий спринт
3. agent и evaluator согласуют contract
4. agent строит
5. evaluator проверяет через браузер
6. agent чинит
7. цикл повторяется

С новыми моделями эту схему можно делать проще. Иногда agent может два часа спокойно собирать продукт, а потом evaluator прогоняет проверку.

Но суть остаётся: качество держится не на “модель умная”, а на архитектуре процесса.

6. Как собрать похожее самому

Нужны понятные примитивы:

— subagents для отдельных ролей
— Playwright / Chrome MCP для проверки интерфейса
— skills / rubrics для критериев качества
— auto mode / permissions для долгой автономной работы
— contract files для договорённости о “готово” до начала реализации

—

Я сам дошёл до части этих принципов: независимое тестирование, контракт (у меня назвался definition of done, dod). Теперь хочу попробовать воспроизвести целиком.

Видео:
https://youtu.be/mR-WAvEPRwE