Generative Ai

Посмотрел выступление 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