Посмотрел выступление 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
Схема такая:
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