/goal в Claude Code: автономный режим и Agent View в 2026

Каждый день в Telegram-канале и MAX - что нового в вайб-кодинге: инструменты, примеры, ошибки. Подпишись, чтобы быть в курсе актуального.

Что такое /goal в Claude Code?

Раньше Claude Code останавливался после каждого ответа и ждал твоего следующего промпта. Это работало для коротких задач, но ломалось на длинных: миграция API, починка 12 падающих тестов, рефакторинг файла на 800 строк - такие задачи требуют 20-30 итераций, и каждая из них вызывала тебя обратно к терминалу.

/goal решает эту проблему через простую идею: разделить «того, кто работает» и «того, кто решает, что закончено». Главный агент пишет код. Отдельный evaluator (быстрая модель Haiku) после каждого хода читает разговор и отвечает на один вопрос - «условие выполнено?». Если нет - агент стартует следующий ход. Если да - управление возвращается тебе.

В официальной документации Anthropic определение звучит так:

Boris Cherny, создатель Claude Code в Anthropic, в интервью Sequoia Capital 4 мая 2026 года описал свой режим работы так:

Тысячи агентов ночью с телефона - это не маркетинг, а текущая практика инженера Anthropic. И механизм, который делает это возможным - связка /goal + Agent View, появившаяся в одном релизе 11 мая 2026.

Зачем нужен автономный режим: что было до и после 11 мая 2026?

Идея «оставить ИИ работать ночью» существовала с осени 2025 года, когда Cursor Composer и Cline auto mode уже могли крутиться в фоне. Но в Claude Code до 11 мая 2026 для этого приходилось писать обвязку руками: cron-таск, который дёргает claude -p каждые N минут, или wrapper, который смотрит на статус git и запускает следующий промпт.

Эта самодеятельность регулярно приводила к катастрофам. 22 мая 2026 года MakeUseOf описал историю разработчика, который оставил такой скрипт на ночь и проснулся с счётом на $6 000. Корень проблемы: Anthropic незаметно сменил cache TTL для Claude Code с одного часа на пять минут без анонса. Cron дёргал прод каждые 30 минут - между запусками кэш успевал умереть. Каждый запуск пересобирал историю на 800 000 токенов с нуля. Запись свежих данных в кэш стоит сильно дороже, чем чтение из активного.

Разработчик не делал ничего экзотического - он использовал инструмент ровно так, как Anthropic его рекламировал.

/goal решает эту проблему встроенной архитектурой:

1. Supervisor process, который держит сессию вне твоего терминала и переживает закрытие окна и сон ноутбука.
2. Evaluator на Haiku - дешёвая модель проверяет каждый ход, токены evaluator'а копеечные.
3. Hard turn limit в condition - можно явно прописать or stop after 20 turns, и сессия гарантированно остановится.
4. Worktree-изоляция для фоновых сессий - изменения идут в отдельную ветку, не трогая твою рабочую копию.

Разница с подходом «свой bash-скрипт» - в том, что Anthropic делает все эти механизмы первоклассными гражданами инструмента, не сторонним хаком.

Как включить /goal за 3 шага

Шаг 1. Обнови Claude Code до 2.1.139 или новее.

Проверь версию:

claude --version

Если меньше 2.1.139 - обнови:

claude update
# или принудительно через npm
npm install -g @anthropic-ai/claude-code@latest

Релизы между 12 и 19 мая 2026 закрыли важные баги первой версии. В 2.1.140 пофиксили тихий висяк, когда disableAllHooks блокировал evaluator. В 2.1.143 пришёл worktree.bgIsolation: "none" и фикс зацикливания stop hooks. В 2.1.144 (от 19 мая) - --resume для background-сессий и agents --json для скриптинга. Минимум - 2.1.143.

Шаг 2. Напиши /goal с условием.

Открываешь обычную сессию Claude Code, набираешь команду:

/goal все тесты в test/auth проходят и линтер чист, или стоп через 15 ходов

Отдельный промпт после этого посылать не нужно - команда сразу запускает первый ход. Условие можно писать на русском, английском, смешанном - модель понимает оба языка. Лимит длины - до 4 000 символов.

Шаг 3. Наблюдай через live overlay.

После запуска /goal внизу терминала появится живая панель:

/goal active · 3 turns · 12m elapsed · 18,400 tokens · last: tests in test/auth/login.test.ts still fail

Что показывает:

• Turns - сколько ходов уже сделано
• Elapsed - сколько прошло времени с момента запуска
• Tokens - суммарно потрачено токенов (главное для контроля бюджета)
• Last - последняя причина evaluator'а, почему он сказал «not yet»

Полезный приём - если evaluator три хода подряд возвращает одну и ту же причину, это сигнал, что ты в петле. Тогда жмёшь Ctrl+C или вводишь /goal clear (синонимы: stop, off, reset, cancel), переформулируешь condition и запускаешь заново. Это правило встречается в community-гайдах по /goal как главный признак зацикливания: «застрял на одной причине три раза - это loop, выйди».

Как написать хорошее condition: 5 правил + 5 примеров

Anthropic в документации описывает три обязательных элемента хорошего condition:

Apidog предложил готовый шаблон, который покрывает все три элемента в одной строке:

Пять правил, на которых ломается большинство:

Правило 1. Конечное состояние - проверяемое командой, не вкусом.

Не «сделай красиво», а npm test exits 0. Не «улучши UX», а Lighthouse Performance score выше 90. Evaluator читает только транскрипт - он не запускает команды и не смотрит на скриншоты. Если результат нельзя зафиксировать текстом, evaluator никогда не скажет «да».

Правило 2. Constraints явные и узкие.

Без constraints Claude может починить тесты, удалив сами тесты или закомментив падающие assertions. Прописывай without modifying any file outside /auth, without removing existing assertions, without bumping major versions of dependencies.

Правило 3. Hard turn limit обязателен.

Добавь or stop after N turns в каждое condition. Это спасательный круг от бесконечной петли. Apidog честно описал последствия отсутствия лимита:

Правило 4. Описывай WHAT, не только HOW.

Это правило открыл Jason Croucher через эксперимент:

Если ты не упомянул визуал в condition - Claude его не сделает. Если condition требует только «тесты проходят», Claude может закомментить сложные тесты. Описывай ЧТО ты хочешь, а не только КАК проверишь.

Правило 5. Заставляй Claude выводить evidence в чат.

Evaluator не запускает команды - он только читает то, что Claude уже вывел. Если condition требует «npm test зелёный», но Claude в транскрипте не показал вывод npm test - evaluator скажет «not yet» бесконечно. В condition добавляй фразу «show the output of <команды> in the conversation».

Пять рабочих примеров для типовых задач:

1. Миграция API:
/goal каждый вызов getUser() заменён на fetchUser(), npm test проходит, npm run build зелёный, никакие другие имена API не тронуты, или стоп через 30 ходов

2. Починка тестов:
/goal все падающие тесты в test/auth теперь зелёные (npm test покажет 0 fails в чате), без изменения assertions, без удаления тестов, или стоп через 20 ходов

3. Code quality (размер файла):
/goal src/legacy/UserService.ts разбит на файлы меньше 200 строк каждый, все импорты обновлены, npm run build зелёный, или стоп через 25 ходов

4. Закрытие backlog:
/goal обработай каждый issue с лейблом 'good-first-issue': прочитай описание, реализуй фикс в worktree-ветке, открой PR. Продолжай, пока очередь не пустая или не обработано 6 issue

5. Security audit:
/goal каждая уязвимость npm audit severity >= high закрыта, все существующие тесты проходят, без breaking API changes, или стоп через 15 ходов

Хочешь не только запустить /goal, но и собрать связку, в которой автономный режим действительно работает на твоём проекте? /goal - только финальное звено. Перед ним должны быть в порядке три кита: ИИ-клон (твоя методология в Skills и Subagents), второй мозг (CLAUDE.md и папка plans/), контекст-инжиниринг (Plan Mode и /compact). На практикуме за 3 эфира собираешь все три - именно эта связка делает Claude стабильным.

Практикум по вайб-кодингу

+Твой второй мозг

3 вечера - стек, метод, первый проект

Старт 26–28 мая  ·  2 000 ₽

Записаться →

5 примеров, где /goal реально работает

Anthropic в документации даёт четыре типа задач, на которых /goal приживается:

Разбираю пять примеров с готовыми condition - бери и адаптируй под свой проект.

Пример 1. Миграция модуля на новый API.

Сценарий: ты переходишь с REST на GraphQL, или меняешь старую функцию getUser() на новую fetchUser(), или мигрируешь с Yandex.Pay v1 на v2. Задача механическая, но затрагивает 30-50 файлов.

Condition:

/goal каждый getUser() в src/ заменён на fetchUser(), все вызовы обновлены под новый interface (id вместо userId), npm test проходит, никакие файлы вне src/ не тронуты, или стоп через 30 ходов

Почему работает: end state проверяется командой grep -r getUser src/ | wc -l (должно быть 0) и npm test exits 0. Constraint защищает test-файлы.

Пример 2. Починка падающих тестов.

Сценарий: после обновления библиотеки сломались 15 тестов. Знаешь, что починка механическая - обновить mocks, поправить assertions под новый формат. Не хочется делать руками.

Condition:

/goal все падающие тесты в test/ теперь зелёные, npm test покажет результаты в чате с 0 failures, без удаления тестов и без закомментирования assertions, или стоп через 25 ходов

Apidog приводит этот пример как канонический:

Пример 3. Разбиение god-класса.

Сценарий: один файл на 1 200 строк, в нём всё - модель, сервис, утилиты, API-клиент. Хочешь разбить по принципу «один файл - одна ответственность», все импорты обновить, тесты не сломать.

Condition:

/goal src/legacy/UserService.ts разбит на файлы меньше 200 строк, каждый файл отвечает за одну ответственность (model, repository, api-client, validator), все импорты обновлены, npm run build зелёный, существующие тесты проходят, или стоп через 25 ходов

Пример 4. Закрытие issue backlog ночью.

Сценарий: у тебя open-source репозиторий с 20 issues, помеченных good-first-issue. Хочешь, чтобы Claude прошёлся по ним за ночь.

Condition:

/goal обработай каждый issue с лейблом 'good-first-issue': прочитай описание, реализуй фикс в отдельной worktree-ветке worktree-issue-N, открой PR с описанием. Продолжай, пока очередь не пустая или не обработано 6 issue, или стоп через 80 ходов

Цифру 6 я ставлю не случайно - реалистичный потолок для одной ночи на Pro-плане. Boris Cherny делает «тысячи» агентов, но это его единичный случай, не reproducible default.

Пример 5. Security audit.

Сценарий: npm audit показывает 8 уязвимостей высокой важности. Хочешь, чтобы Claude закрыл их без апдейта major-версий.

Condition:

/goal каждая уязвимость npm audit severity high+ закрыта, npm audit покажет 0 high в чате, все существующие тесты проходят, без breaking API changes, без бампов major version пакетов, или стоп через 15 ходов

Это пример из explainx.ai - его берут разработчики, которые автоматизируют ежемесячную проверку зависимостей.

Что НЕ делать через /goal:

Croucher в своём field guide формулирует правило выбора жёстко: не используй /goal для задач, где «закончено» означает «выглядит хорошо», «ощущается правильно», «хорошо спроектировано» или «весело». Evaluator читает только транскрипт - он не запускает инструменты и не может оценить, как работает результат. Это правило отсекает 80% субъективных задач, на которых /goal зацикливается без полезного выхода.

Когда /goal сжигает деньги впустую: 3 антипаттерна

Антипаттерн 1. Vague condition без hard turn limit.

Самая частая ошибка - condition вида «улучши код» / «сделай хорошо» / «оптимизируй». Без turn limit такой агент крутится, пока не выжжет квоту.

Findskill описал реальный случай:

$200 за 14 часов на расплывчатом condition - это весь weekly-лимит на Max-плане. Утром ты просыпаешься без квоты и без полезного результата.

Защита: каждое condition заканчивается словами or stop after N turns (для лёгких задач - 15, для тяжёлых - 50, для overnight - 100 максимум).

Антипаттерн 2. Рекурсивный loop с broken caching.

История из MakeUseOf 22 мая 2026 года - $6 000 за ночь из-за того, что Anthropic тихо сменил cache TTL с часа на 5 минут. Разработчик не использовал /goal напрямую, но логика та же: автономный loop с cron-таймером 30 минут пересобирал 800 000-токенную историю каждый раз с нуля.

Корень проблемы - external automation не знала про внутренние изменения провайдера. То же может случиться с /goal, если ты пускаешь его на 8 часов без supervision: токены растут нелинейно, prompt cache работает не так, как ты думаешь.

Защита:

1. Не запускай /goal на 8+ часов без промежуточных проверок.
2. Включи usage limits в Settings → Usage (новая защита после истории на $6 000).
3. Открой claude agents дважды за ночь - peek через Space, посмотри что turn count не растёт быстрее ожиданий.
4. Для тяжёлых model-чейнов (Opus 4.7) ставь turn limit жёстче - 30 максимум.

Антипаттерн 3. Креатив через /goal.

Croucher запустил /goal на сборку игры - condition включал детерминизм, инварианты, проверку прохождения уровня. Игра собралась, тесты прошли, evaluator сказал «достигнуто». Визуала в игре не было - условие не упоминало графику.

Это иллюстрирует общее правило: evaluator оптимизирует ровно то, что ты измеряешь. Если в condition нет визуала - визуала не будет. Если в condition только тесты - может закомментить assertions.

Защита: для всего, что про вкус (дизайн, тексты, UX), /goal не используй. Возвращайся к обычной сессии или Plan Mode - они оставляют тебя в петле решений.

Что такое Agent View и как открыть дашборд

Если /goal - это команда «работай, пока не закончишь», то Agent View - это диспетчерская, в которой видно все такие команды разом. Anthropic описывает её так:

Команда открытия:

claude agents

Откроется TUI-интерфейс - текстовый дашборд внутри терминала. Слева список сессий, справа peek-панель с последним сообщением активной строки.

Шесть состояний сессии:

Главные шорткаты:

↑ / ↓             перемещение по списку сессий
Space             peek-панель (просмотр без attach)
Enter / →         attach к сессии (войти в неё)
←                 detach (выйти, не убивая)
Ctrl+T            pin (защищает сессию от автоостановки)
Ctrl+X            stop сессию, ещё раз в 2 сек - delete
Ctrl+R            rename
Ctrl+S            переключить группировку (state ↔ directory)

Как запустить фоновую сессию:

Из интерактивного Claude Code:

/bg исправь падающий тест test/auth/login.test.ts

Или сразу из шелла:

claude --bg "исправь падающий тест test/auth/login.test.ts"

Или с именем (тогда видно в Agent View под понятной строкой):

claude --bg --name "flaky-test-fix" "исправь test/auth/login.test.ts"

Подключается фоновая сессия к Agent View автоматически - запустил с --bg, открыл claude agents, видишь её в списке.

Главная фишка - сессии переживают сон ноута и закрытие окна:

Но shutdown ноут или ручной reboot - и фоновые сессии в Failed. Все Cherny-style «несколько тысяч агентов за ночь» работают на ноуте, который не выключают.

Worktrees - как Claude изолирует параллельные сессии

Worktrees решают главную проблему параллельной автономки: что, если две сессии одновременно пытаются править src/auth.ts? До 2.1.139 такие сессии буквально перетирали изменения друг друга. С Agent View Anthropic ввёл автоматическую изоляцию:

Как работает на практике:

# Запустил три фоновые сессии:
claude --bg --name "fix-tests" "почини падающие тесты в test/"
claude --bg --name "add-oauth" "добавь Google OAuth по плану в plans/oauth.md"
claude --bg --name "split-userservice" "разбей UserService.ts на модули"

# Структура файлов после старта:
.claude/worktrees/
├── fix-tests/             # отдельная копия репо на ветке worktree-fix-tests
├── add-oauth/             # отдельная копия на ветке worktree-add-oauth
└── split-userservice/     # отдельная копия на ветке worktree-split-userservice

Каждая сессия работает в своей копии. Когда задача закончена, ты делаешь merge нужных веток в main.

Опасная ловушка - удаление сессии удаляет worktree.

Если ты в Agent View убил сессию (Ctrl+X дважды), worktree исчез. Все uncommitted изменения пропали. Перед удалением сессии в Agent View - всегда коммит или push.

Опт-аут (для редких случаев):

Если у тебя репозиторий, где git worktrees не работают (например, специфический setup с symlinks или большой monorepo с медленным checkout), можно выключить изоляцию:

// .claude/settings.json
{
  "worktree": {
    "bgIsolation": "none"
  }
}

Тогда фоновые сессии будут править твою рабочую копию напрямую. Этот опт-аут появился в 2.1.143 после жалоб от команд с большими monorepo.

Параллельность жжёт квоту:

Это значит, что Pro-плана ($20/мес) хватит на 1-2 параллельные сессии за ночь, не на десять. Если хочешь стиль Cherny с тысячами агентов - нужен Max или Enterprise.

Связка /goal + Plan Mode + subagents для длинных задач

Типичный фейл - сразу написать /goal сделай новую фичу. Это не работает, потому что evaluator не знает, как выглядит «сделанная фича». Нужен план с чек-боксами, который evaluator сможет проверить пункт за пунктом.

Слой 1. Plan Mode пишет план с фазами.

В Plan Mode ты просишь Claude составить детальный план изменений, разбитый на 5-7 фаз с проверяемыми чек-боксами. Сохраняешь как plans/2026-05-24-google-oauth.md. Каждая фаза - 3-7 чек-боксов с конкретными действиями.

Слой 2. Субагенты делят работу по фазам.

Если план параллелизуется (например, фазы независимы - бэкенд-эндпоинт + фронтенд-форма + миграция БД), каждую фазу можно запустить в отдельной фоновой сессии через claude --bg --name "<phase>". Каждая сессия получит свой worktree.

Слой 3. /goal крутит цикл до закрытия чек-боксов.

/goal все фазы 1-7 из plans/2026-05-24-google-oauth.md выполнены и отмечены [x], все тесты в test/auth проходят (npm test показывает 0 failures), npm run build зелёный, или стоп через 50 ходов

Evaluator после каждого хода читает план, проверяет какие чек-боксы закрыты, и если что-то осталось - агент продолжает.

Эта связка - то, что Артемий называет «3 кита»:

• контекст-инжиниринг: правильный контекст в plans/ - evaluator его читает
• второй мозг: папка plans/ хранит план между сессиями
• ИИ-клон: CLAUDE.md задаёт правила, по которым агент работает

Без CLAUDE.md /goal может предложить решение, ломающее архитектуру. Без плана в plans/ evaluator не знает критерии успеха. Без субагентов параллельных фаз не будет, всё последовательно.

Andrej Karpathy 19 мая 2026 ушёл в Anthropic в команду pre-training. До этого его подход к CLAUDE.md и автономным агентам, собранный в репозитории multica-ai/andrej-karpathy-skills, набрал больше 150 000 звёзд на GitHub. Один из его четырёх ключевых принципов работы с Claude называется Goal-Driven Execution - «определи критерии успеха, зацикливайся пока не проверено». Это ровно описание /goal.

Чем /goal отличается от Codex Auto и Cursor Composer

Чтобы понять, когда выбирать /goal, полезно знать его место в экосистеме.

/goal vs Codex CLI autonomous mode:

Paweł Józefiak в апреле 2026 года провёл независимое сравнение AI-coding harness'ов. Главный практический вывод по его исследованию: для ночной автономной работы стоит брать Claude Code, несмотря на 3-4x худшую token-эффективность, потому что выигрыш в coherence на длинных задачах перекрывает стоимость токенов. Для коротких feature-задач с чётким спеком - Codex CLI: GPT-5.4 даёт более чистый код на изолированной фиче. Цифры из его Terminal-Bench 2.0 теста: Claude Code 92.1%, Codex CLI 77.3%.

Терминал-Bench 2.0 показывает разницу для agentic тасков: Claude Code - 92.1%, Codex CLI - 77.3%.

/goal vs Cursor Composer:

Cursor не имеет аналога /goal - он сделан для supervised работы в IDE с клавиатуры. Cursor выигрывает на inline editing, autocomplete, active in-IDE coding. Claude Code выигрывает на deep codebase reasoning и autonomy.

/goal vs Cline auto mode:

Cline auto mode = approve каждый tool call автоматически, но НЕ stops via evaluator. Это auto mode без /goal-обёртки. Anthropic в документации описал разницу так:

/goal vs /loop:

/loop - другая команда того же релиза, запускает периодические задачи на time interval (раз в N минут). /goal - на condition-basis (пока не выполнено). Используй /loop для cron-like задач, /goal для discrete достижения цели.

Из документации Anthropic:

Чек-лист перед запуском /goal: 7 пунктов

Чек-лист перед каждым /goal:

1. Версия Claude Code 2.1.139+ - проверь через claude --version, обнови если меньше. Минимально рекомендованная - 2.1.143 (15 мая 2026) с фиксом зацикливания stop hooks.

2. Condition содержит verifiable end state - вместо «улучши» прописывай npm test exits 0. Если ты не можешь придумать команду bash, которая проверит результат - /goal не для этой задачи.

3. Есть hard turn limit - в каждом condition прописано or stop after N turns. Для лёгких задач - 15, тяжёлых - 50, overnight - 100 максимум.

4. Constraints явные и узкие - without modifying files outside /auth, without removing existing assertions, without bumping major versions. Без них Claude может починить тесты, удалив сами тесты.

5. Все важные изменения закоммичены или запушены - если ты работаешь не в worktree (например, worktree.bgIsolation: "none"), Claude правит твою рабочую копию. Любая ошибка - и теряешь несохранённое.

6. Включены usage limits в Settings → Usage - это новая защита после истории на $6 000. Лимит на день, на сессию, на месяц.

7. Открыт Agent View claude agents в отдельном окне - на длинных задачах заглядывай через peek (Space) раз в час. Если turn count растёт быстрее ожиданий или evaluator повторяет одну и ту же причину три хода - Ctrl+C и переформулировка.

Восьмой пункт, который я добавил для себя - никогда не запускай /goal с --dangerously-skip-permissions на чужом или незнакомом коде. Эта связка отключает любые проверки и даёт агенту делать всё что захочет в твоём проекте. Я использую её только в свежем worktree, где терять нечего.

/goal - мощная фича, но не магия. Она работает ровно настолько хорошо, насколько ты можешь сформулировать condition. Если ты можешь словами описать «закончено» так, что оно проверяется командой - /goal сделает остальное. Если не можешь - возвращайся в обычную сессию или Plan Mode.

Полная схема по вайб-кодингу за вечер: ИИ-клон + Второй мозг + Контекст-инжиниринг. 3 эфира, 2 000 ₽. Записи остаются у тебя.

Практикум по вайб-кодингу

+Твой второй мозг

3 вечера - стек, метод, первый проект

Старт 26–28 мая  ·  2 000 ₽

Записаться →