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. долгие задачи = это проблема процесса, а не только LLM
2. независимая оценка критична
3. артефакты и контракты важнее длинного чата
4. контекст надо управлять, а не просто копить