Когда в длинной сессии вы поручаете модели писать код, основная модель (исполняющая модель / executor) постепенно теряет из виду, «что в этом проекте изначально было самым важным». Например, она самовольно добавляет слой кеширования в инструмент, который не предполагает масштабирования, или подключает библиотеку, хотя вы не хотели увеличивать число зависимостей. Многие наверняка сталкивались с тем, что чем дальше идет контекст, тем сильнее модель тянет к ближайшей задаче и тем больше она отклоняется от общей линии проекта.
Именно здесь полезен советник (advisor) в Claude Code. Советник автоматически вызывается в важных точках и, более того, читает всю историю беседы. А значит, если заранее обратиться прямо к советнику и написать: «Суть этого проекта вот в чем», то каждый раз при вызове он будет сверять работу исполняющей модели с этой сутью. Иными словами, его можно использовать как «регулярное напоминание» для забывчивой исполняющей модели.
У такого подхода — «писать напрямую для советника» — есть основание в официальной документации. В этой статье я буду на нее ссылаться и доведу идею до практического примера CLAUDE.md, который можно использовать в реальной работе.
Исходные условия: что советник видит, а что не видит
Инструмент советника сейчас предоставляется в бета‑версии (идентификатор инструмента advisor_20260301, бета‑заголовок advisor-tool-2026-03-01). В Claude Code командой /advisor можно назначить более умную модель, чем исполняющая модель, в качестве собеседника для консультаций (например, Opus для исполнения на Sonnet). Исполняющая модель автоматически обращается к нему в моменты важных решений: перед тем как зафиксировать подход, когда зашла в тупик, перед объявлением о завершении и так далее. Момент вызова определяет сама исполняющая модель.
В механизме есть два свойства, которые напрямую связаны с темой этой статьи. Они явно описаны в официальной документации Advisor tool. Для использования в Claude Code требуется версия v2.1.98 или новее. Тип оплаты не важен: это работает и с подписками Pro / Max, и с аккаунтами с API‑биллингом. В случае подписки использование советника засчитывается в лимит плана и расходуется из общего пула, разделяемого с Claude Chat. Поскольку бэкенд работает на инфраструктуре Anthropic напрямую, инструмент нельзя использовать через Amazon Bedrock / Google Vertex AI / Microsoft Foundry. Так как это экспериментальная бета‑функция, поведение, цены и доступность могут измениться.
Советник получает весь транскрипт executor. Он видит системный промпт, все определения инструментов, все предыдущие ходы и все результаты выполнения инструментов.
В вызов советника нельзя передать аргументы. input у server_tool_use всегда пустой, и все, что executor положил бы в input, до советника вообще не дойдет. Серверная сторона сама автоматически строит поле зрения советника из «всей истории».
Из этого следует, что отдельного «поля ввода специально для советника» не существует. Нельзя «передать только советнику отдельный файл» или «добавить отдельный промпт в момент вызова». Инструкции для советника можно написать только внутри контекста, который видит executor: в системном промпте, пользовательских сообщениях и в CLAUDE.md. И ключевой момент в том, что этого достаточно, чтобы они до него дошли.
Ссылка: Advisor tool — Claude API Docs
Официальное основание: инструкции, обращенные прямо к советнику, работают иначе
В разделе Best practices той же документации (в части о сокращении вывода советника) есть фраза, на которой держится главный тезис этой статьи. Если пересказать ее кратко, смысл такой.
Советник читает и системный промпт, и пользовательские сообщения как «цитируемый контекст, относящийся к задаче executor». Поэтому инструкции, напрямую обращенные к советнику, выполняются гораздо надежнее, чем описания, написанные в третьем лице. В тестах Anthropic наиболее эффективным оказалось размещение одной строки внутри пользовательского сообщения в таком формате:
(Advisor: please keep your guidance under 80 words — I need a focused starting point, not a comprehensive plan.)
Здесь важно точно зафиксировать два момента.
Первое: это не «синтаксис», а прием. Слово Advisor: и двоеточие не парсятся системой каким‑то особым образом. Просто раз советник читает всю беседу, обычный текст с явным адресатом работает лучше, чем описание в третьем лице. Поэтому не нужно искать магическое ключевое слово. Суть лишь в том, чтобы обратиться ко второму лицу: «Советник, это для тебя».
Второе: официально приведенный пример касается контроля длины вывода. В примере выше речь тоже о длине: «ответь в пределах 80 слов». То, что я дальше предлагаю — передавать «суть проекта» — это применение официального наблюдения «прямое обращение выполняется надежнее» к другой цели. Сама эта цель в документации прямо не описана. Как техника это логично, но эффективность стоит проверять на своей рабочей нагрузке. Именно с такой температурой и стоит читать дальнейшее.
Логика: почему это работает как «напоминание о сути»
Если разложить по шагам, получается такая цепочка.
Исполняющая модель по мере удлинения сессии легко увлекается ближайшей задачей и теряет из виду общий курс проекта (recency bias / дрейф контекста).
Советник автоматически вызывается в важных точках: «перед тем как зафиксировать подход», «когда зашел в тупик», «перед объявлением о завершении» и так далее.
В этот момент советник читает всю историю беседы. Значит, содержимое CLAUDE.md тоже доходит до него как контекст, сопоставимый с системным промптом.
Если там во втором лице написать советнику: «Суть этого проекта вот в чем. Оцени действия executor через эту суть», то на каждом важном этапе автоматически появляется проверка: «Подожди, а мы не отклонились от исходной цели?»
В такой схеме надежнее не просто написать самой исполняющей модели «не забывай суть» (правило в третьем лице или правило для самой себя), а поручить советнику, который выходит на сцену в ключевые моменты, быть хранителем этой сути. Даже если исполняющая модель забудет, советник напомнит. Получается разделение ролей.
Пример CLAUDE.md
В качестве примера возьмем «персональный офлайн‑first инструмент». В проектах такого типа, если оставить исполняющую модель без присмотра, она часто возвращается к «общим best practices» и самовольно добавляет сетевую синхронизацию, телеметрию или абстракции для масштабирования. Это как раз тот случай, где легко «забыть суть».
В CLAUDE.md можно написать так. Блок для советника лучше писать во втором лице, а блок для исполняющей модели (когда обращаться к советнику) — как инструкцию для executor. Секрет в том, чтобы развести роли.
# Обзор проектаЭто офлайн-first персональный инструмент, которым «один пользователь пользуется для себя».Масштабирование и многопользовательский режим не являются целью. В приоритете ясность и минимум внешних зависимостей.## Для Advisor (каждый раз оценивайте решения executor через это)Advisor: вы — «хранитель сути» этого проекта. Когда к вам обращаются за консультацией,сначала оцените подход executor по следующим 3 пунктам и, если есть отклонение,укажите на него в первую очередь.1. Офлайн-first: не добавляет ли он сетевое взаимодействие, внешние API или телеметрию. «Было бы удобно» не является причиной. По умолчанию все должно завершаться офлайн.2. Не увеличивать зависимости: не добавляет ли он новый пакет для того, что можно сделать стандартной библиотекой.3. Ясность для одного пользователя: не вводит ли он ненужные сейчас абстракции или слой кеширования под предлогом масштабирования, параллелизма или будущей расширяемости.Если эти 3 пункта конфликтуют с удобством ближайшей задачи, отдавайте приоритет сути(этим 3 пунктам). Достаточно краткого совета по делу (длинный проектный документ не нужен).## Правила использования Advisor (для исполняющей модели: когда консультироваться)- Перед началом реализации сначала проконсультироваться с Advisor по направлению и дизайну.- Обязательно консультироваться перед изменениями в нескольких файлах, а также перед решением добавить новую зависимость или сетевое взаимодействие.- Если одна и та же ошибка повторилась 2 раза, не упираться самостоятельно, а обратиться к Advisor.- Перед объявлением о завершении сохранить / закоммитить результат и провести финальную консультацию.## Правила кодирования(Здесь правила, специфичные для проекта: тесты, форматтер, правила коммитов и так далее.)
Добавлю несколько пояснений.
Блок с обращением во втором лице (Advisor:) соответствует тому, что официальная документация называет «инструкцией с прямым обращением». Вместо того чтобы писать в третьем лице «советник должен…», мы обращаемся напрямую: «вы — хранитель».
«Правила использования Advisor» предназначены для executor. Это не приказ советнику, а инструкция исполняющей модели о том, когда его вызывать. Советник не полностью сам решает, когда выйти на сцену: его вызывает executor. Поэтому если вы хотите повысить частоту консультаций, нужно подталкивать именно executor. В официальной документации также сказано, что настройки, принудительно задающей число вызовов, нет, а частота направляется текстом инструкций.
CLAUDE.md загружается в контекст при старте сессии, а советник получает всю историю беседы целиком. Поэтому отдельный файл специально для советника не нужен. Суть можно собрать в CLAUDE.md.
Честное уточнение: официально «самым эффективным» в тестах был вариант с одной строкой внутри пользовательского сообщения, которую агент программно добавляет перед отправкой запроса. Размещение в CLAUDE.md — это практическое применение принципа «прямое обращение работает». Советник читает и системный промпт, и пользовательские сообщения, и содержимое CLAUDE.md, поэтому инструкция должна до него дойти, но сама по себе такая раскладка с CLAUDE.md официально не тестировалась. Если нужна максимальная надежность, ближе всего к официальной тестовой конфигурации будет продублировать строку, обращенную к Advisor:, еще и в начале реального промпта (пользовательского сообщения), либо держать ее в обоих местах.
Контроль длины вывода тоже стоит использовать
Если попросить советника «указать отклонения от сути», он легко становится многословным. С точки зрения стоимости это тоже важно: вывод советника является крупнейшим драйвером затрат и не ограничивается верхнеуровневым max_tokens. Поэтому вместе с официальным приемом стоит добавить ограничение длины тем же прямым обращением. В примере выше этой роли служит фраза «Достаточно краткого совета по делу».
Если нужен жесткий верхний предел, можно физически ограничить его через max_tokens в определении инструмента (минимум 1024, рекомендуемая стартовая точка — около 2048). Разделение такое: просьба в промпте — мягкое ограничение, max_tokens в определении инструмента — жесткий потолок.
Итоги
У советника нет отдельного поля ввода. Инструкции можно писать только в контексте executor, включая CLAUDE.md, и этого достаточно, чтобы они до него дошли.
Согласно официальным Best practices, инструкции, напрямую обращенные к советнику во втором лице, выполняются надежнее, чем описания в третьем лице. При этом официальный пример касается контроля длины вывода, а передача «сути проекта» — это применение этого принципа.
Советник автоматически выходит на сцену в важных точках и читает всю историю. Поэтому если во втором лице поручить ему роль «хранителя сути», он сможет каждый раз напоминать исполняющей модели о курсе, который та могла забыть.
В CLAUDE.md стоит разделять «обращение к Advisor» (второе лицо, суть проекта) и «обращение к исполняющей модели» (когда вызывать советника).
И еще раз напоследок: эффект зависит от задачи. Использование советника как «напоминания о сути» — не официальная гарантия, а практическое применение принципа из документации. Проверьте на своем проекте, действительно ли это работает.
Ссылки
Advisor tool — Claude API Docs
Escalate hard decisions with the advisor tool — Claude Code Docs
ссылка на оригинал статьи https://habr.com/ru/articles/1058718/