Claude Code

Ночью пришло сообщение от Anthropic, которое быстро взбудоражило всё сообщество — компания официально объявила, что подписка на её сервисы больше не покрывает использование сторонних агентов, в том числе OpenClaw. Понятно, что тут же начались возмущенные твиты “Я отказываюсь от подписки”, “Anthropic ненавидит open source” и так далее, но это всё шум. Реальность такова, что компания наконец-то высказалась ясно на тему использования лимитов подписки в сторонних агентах — это, на мой взгляд, хорошо и давно пора было. При этом публичные лица компании — начиная с Бориса Черни, руководителя Claude Code, — довольно подробно начали объяснять, что подписка оптимизирована под взаимодействие с нативными агентами и в условиях дефицита мощностей компания вынуждена приоритезировать их поддержку. Разумеется, это не мешает критикам возмущаться и дальше.

Есть много занятий, которыми можно заниматься постоянно и у меня к таким в последний год добавился регулярный анализ конфигурации всей моей AI-инфраструктуры, включая агентов. Тут, конечно, главное — вовремя остановиться в совершенствовании инструмента и перейти к его применению, но процесс все равно интересный.

Я регулярно нахожу самые разные советы, собираю целые фреймворки для работы, например, Claude Code, стараюсь анализировать, что нахожу, комбинировать со своими наработками.

Вот очень необычный и интересный совет, который я вытащил из фреймворка superpowers.

Автор фреймворка обнаружил явление, которое можно назвать утечкой workflow. В Claude Code широко распространены скиллы, описывающие порядок действий в определенных случаях, которые подгружаются в контекст агента в случае срабатывания триггеров. Триггеры ориентируются на описание (description) скилла, поэтому принято там описывать назначение. Так вот, оказывается, если описание содержит не только случаи, в которых должен сработать скилл, но и описание того, что скилл делает, то Claude Code (точнее, LLM) может проигнорировать всё остальное содержание, посчитав описание достаточной инструкцией для работы.

В случае у автора Claude, прочтя в описании “code review between tasks”, провел одно ревью вместо процедуры из нескольких этапов.

Простое исправление — перечислять в description собственно условия срабатывания скилла и не допускать описания непосредственно процесса.

Например, вместо “Comprehensive testing workflow with parallel unit/integration tests and gated E2E” написать “Use for ‘run tests’, ’test this’, ‘check test coverage’” или вместо “Bug investigation and resolution workflow. Routes to investigate, diagnose, implement” прописать “Use for ‘fix this bug’, ‘debug this’, ’this is broken’”.

Тестировать исправление очень просто — если скилл продолжает срабатывать в нужных случаях, значит, описание достаточное для этого. Если нет — добавьте еще триггеры. Но вы точно будете знать, что агент прочтет весь скилл, что повысит вероятность его следования полному набору инструкций.

Одна из главных проблем работы с кодинг-агентами — это контекст. Во-первых, размер контекста не бесконечный, во-вторых, даже очень большой контекст (как, например, 1 млн токенов у Gemini) не гарантирует, что модель с ним хорошо работает. Как тут не вспомнить принцип Шерлока Холмса, который сравнивал человеческий мозг с чердаком, где всё должно быть аккуратно разложено, чтобы им можно было воспользоваться.

Есть много способов организовать работу того же Claude Code, чтобы не захламлять контекст лишними токенами. Но так или иначе, по мере развития проекта, над которым вы работаете с агентом, в нем накапливается большое количество информации, которое хорошо бы держать доступной для агента. А если проектов много, какая-то информация, конфигурации, субагенты и скиллы начинают выноситься на уровень пользователя (не говоря о том, что часто типичная установка MCP серверов или скиллов норовит вписать себя именно на уровень пользователя) и присутствовать в результате в контексте вообще всех проектов.

Недавно Anthropic выложили очень полезную статью, подробно описывающую то, как Claude Code работает с памятью. Плохая новость — это не приводит к автоматической перестройке всех проектов. Этим придется заняться самому пользователю.

Хорошая новость — для этого можно привлечь сам Claude Code. Попробуйте для начала на одном проекте. Запустите Claude Code в проекте и дайте ему следующую инструкцию:

Прочитай https://code.claude.com/docs/en/memory. Проанализируй текущую память проекта и дай предложения в соответствии с рекомендациями статьи.

Claude Code прекрасно воспринимает инструкции на любом языке, можно не заморачиваться обязательным английским — тем более, что память он в итоге перепишет на английском. Скорее всего, он предложит превратить память проекта (~/.claude/projects/projectID/memory/MEMORY.md) в некое оглавление, а текущее содержание разделить на специфические файлы по темам — в этом случае на старте загружаться будут только несколько десятков строк основного файла, а файлы по темам будут подгружаться по необходимости. Кроме того, он увидит дублирующие инструкции в этих файлах и CLAUDE.md проекта и в итоге дойдет до ваших основных файлов (~/.claude/CLAUDE.md) и предложит переделать и их.

Вот тут удержитесь от полной переделки — проверьте, как это пройдет с одним проектом. Если он не предложит сделать бэкап текущих файлов, напомните про это, дайте сделать все правки. Перезайдите в сессию — claude –resume, — и посмотрите на результат.

Мне на довольно развесистом проекте с десятками сессий и большому количеству данных в памяти удалось снизить начальную занятость контекста до 11% от общего окна — это очень неплохой результат, в среднем без подобной реорганизации легко обнаружить начальный контекст на уровне 25-30%. Учитывая, что после 140-150k токенов (при общем окне в 200k) модели становится тяжело помнить начало сессии, выигрыш сразу становится ощутим в практической работе.

Оставайтесь с нами, у меня еще много всяких соображений накопилось на эту тему и не только.