Anthropic написал
статью, как они строили
harness для долгих автономных задач, прежде всего для:
• генерации качественных интерфейсов,
• многочасовой разработки полноценных приложений без постоянного участия человека.
Главная идея: проблема не только в модели, а в
архитектуре процесса вокруг модели.
───
Ключевые выводы статьи
1) Для длинных задач одного агента мало
На длинных прогонах агент:
• теряет нить,
• начинает “закругляться” раньше времени,
• переоценивает качество собственной работы.
Поэтому они ушли от наивного solo-agent режима к
многоагентной схеме.
───
2) Они используют роли: planner / generator / evaluator
Planner
• берет короткий пользовательский запрос,
• разворачивает его в полноценный product spec.
Generator
• делает работу по спринтам/частям,
• реализует фичи одну за другой.
Evaluator
• независимо проверяет результат,
• ищет баги и оценивает качество,
• дает обратную связь генератору.
Это важно:
агент не должен сам себя честно оценивать — он слишком снисходителен к собственной работе.
───
3) Для долгих задач важна работа с контекстом
Они отдельно подчеркивают проблему
context anxiety:
• модель, чувствуя длинный контекст, начинает prematurely wrap up,
• или просто деградирует по качеству.
Раньше они боролись с этим через
context resets:
• новый агент,
• чистый контекст,
• структурированный handoff-файл между сессиями.
Позже с Opus 4.5 смогли больше полагаться на
compaction, но сама идея осталась:
нельзя просто бесконечно тянуть один и тот же контекст.
───
4) Коммуникация между агентами — через файлы/артефакты
Вместо хаотичного общего чата они передают состояние через
структурированные файлы:
• контракт спринта,
• замечания,
• QA-отчеты,
• handoff-артефакты.
Это делает систему устойчивее и понятнее.
───
5) Для субъективных задач они формализуют критерии
На примере frontend-дизайна они показывают, что даже субъективные вещи можно оценивать по критериям:
• design quality
• originality
• craft
• functionality
После этого evaluator может не просто говорить “нравится / не нравится”, а давать направленную обратную связь.
───
6) Для full-stack разработки они используют “спринт-контракты”
Перед началом спринта generator и evaluator
договариваются, что именно считается done.
Это очень сильная идея:
• спецификация сверху остается high-level,
• но на каждый спринт есть конкретный контракт,
• evaluator потом проверяет именно его.
───
Что у них получилось
По их словам:
• solo-agent сделал заметно хуже,
• полный harness работал
намного дольше и дороже,
• но качество итогового продукта было существенно выше.
Пример из статьи:
• solo run: ~20 минут, ~$9
• full harness: ~6 часов, ~$200
То есть главный trade-off:
качество и автономность растут, но резко растут цена, время и сложность orchestration.
───
Статья не про “волшебную модель”, а про инженерную правду:
1.
долгие задачи = это проблема процесса, а не только LLM2.
независимая оценка критична3.
артефакты и контракты важнее длинного чата4.
контекст надо управлять, а не просто копить
