Сначала я был уверен, что мой coding‑агент просто тупит. Он игнорировал свежие требования, изредка терял файлы, а иногда даже генерировал что-то совсем уж не в тему. Потом я открыл свои старые сессии — и стало неловко, потому что во всем виноват только один из нас — я. Я увидел, как сам ломаю контекст: смешиваю разные задачи, таскаю старое ТЗ и не вычищаю ненужные хвосты, когда уже пора.
Поразмыслив, я понял, что переоцениваю «магичность» модели и недооцениваю дисциплину использования. Ведь для успешного применения агентов важно, как построены сессии, заданы инструкции, настроены субагенты, команды и устойчивые skills — в общем, контекст, который мы закладываем в модель.
Эта статья предназначена для специалистов, работающих с LLM- и AI-агентами или планирующих их внедрение. Она будет полезна разработчикам, промпт-инженерам, специалистам по контекст-инжинирингу и техническим лидерам. В ней вы найдете мои советы по оптимизации AI-агентов для автоматизации задач, а после прочтения лучше поймете, как управлять контекстом.
Поводом к этой статье стал свежий гайд Sankalp Shubham про Claude Code 2.0 и мои размышления о контекст‑инжиниринге. Здесь я совмещаю мини‑перевод ключевых идей с собственной практикой, чтобы показать, как приемы из гайда переложить на работу с любыми coding‑агентами (да и на работу вообще).
Я довольно плотно работаю с coding‑агентами в живых проектах. За это время я много раз видел одни и те же тупняки, корень которых почти всегда оказывался не в модели, а в том, как пользователь обращается с контекстом. Попробую разложить по полочкам, что именно мы делаем не так и почему.
Что такое контекст и как он разваливается
Контекст, или контекстное окно coding‑агента, — это все, что модель видит в момент ответа. Это история диалога, все загруженные файлы, выдержки из документации, системные инструкции, планы и заметки. По сути, это набор токенов, которые надо уместить в агента и получить от него максимум пользы с минимумом шума.
Контекст начинает деградировать (или, как мне нравится говорить, плывет) по нескольким причинам.
Во‑первых, по мере роста истории старые, но важные детали вытесняются и попадают в слепую зону attention. Получается эффект lost in the middle, когда модель прекрасно помнит начало и конец разговора, но вот середину теряет.
Во‑вторых, мы сами раздуваем context bloat. Тащим лишние файлы, старые варианты требований, дублирующиеся инструкции, и модель тратит бюджет внимания на борьбу с противоречиями вместо решения задачи.
Отсюда вылезают такие бесячие, но почти привычные симптомы:
агент опирается на устаревшие требования и игнорирует свежие правки;
игнорирует файлы или модули;
забывает о ранее согласованном плане.
Кажется, что «модель глючит», хотя по факту мы просто не управляем тем, какие именно куски истории и артефактов попадают в окно внимания, а какие тихо выпадают из него.
В своем гайде Sankalp Shubham как раз показывает, как бороться с этим расползанием контекста через отдельные опорные артефакты и инструменты: CLAUDE.md с инвариантами проекта, scratchpad для черновых заметок, таск‑инструменты и субагенты для подзадач, регулярный compact истории чата. По сути, это разные способы вытащить важное из бесконечного диалога в более стабильные формы и осознанно управлять тем, что попадет в контекстное окно, а что останется за его пределами.
Инструменты контекст‑инжиниринга: субагенты, команды, skills
Если посмотреть на приемы из гайда чуть шире, то получается, что три основных инструмента контекст‑инжиниринга — это субагенты, команды и устойчивые skills. В разных продуктах они называются по‑разному, но цель у них одна — разгрузить окно внимания, отделить тяжелое чтение и анализ от основной задачи и подмешивать важные знания в контекст аккуратно, а не горстью.
Субагенты
Идея субагентов проста: вместо одного перегруженного чата выносить чтение и анализ в отдельные инстансы со своим контекстом. Например, «агент‑разведчик» может изучать документацию или репозиторий, а «агент‑планировщик» — строить план работ. А в основной контекст они отдадут резюме и готовые решения, а не сырой шум.
Практически это означает, что под крупные подзадачи заводятся отдельные сессии или субагенты (аудит модуля, анализ багре��ортов, генерация плана), которые потом отдают выжимку в основной поток. В итоге внимание главного агента разгружается, и он работает с компактным слоем «что я уже знаю», а не пытается держать весь контекст разом.
Команды
Команды (слеш‑команды и их аналоги) фиксируют типовые сценарии работы с контекстом и снимают необходимость каждый раз придумывать промпты с нуля. В гайде Sankalp Shubham это и встроенные /compact, и кастомные команды вроде /handoff, которые явно задают правила: какие артефакты подключить, в каком формате ожидать ответ, как относиться к уже существующей истории.
Команда — это не просто «сокращенный промпт», а способ минимизировать шум. Она каждый раз одинаково подготавливает контекстное окно под задачу и задает структуру ответа. В итоге два похожих запроса, отправленных через одну и ту же команду, дают более стабильный результат, чем два свободно сформулированных сообщения в чате.
Skills и хуки
Skills в гайде Sankalp Shubham выступают как долговременный слой знаний и шаблонов поведения агента. Это могут быть описания проекта (аналог CLAUDE.md), правила код‑стайла и архитектуры, типовые решения и антипаттерны — все, что не хочется каждый раз пересказывать в начале сессии. Важное различие skills и команд состоит в том, что первые применяются к разным сессиям и сценариям, а вторые — только разово и к конкретному сценарию.
Хуки и system‑reminders дополняют эту картину: они помогают регулярно подкручивать контекст, напоминая агенту о важных ограничениях и привычках даже тогда, когда пользователь о них не написал в текущем сообщении. Вместе skills и хуки прев��ащают контекст из разового промпта в более стабильную среду: можно один раз оформить все важные моменты в явном виде, а затем использовать их в новых сессиях и субагентах без копипаста.
Понятно, что все это полезно и правильно, как делать зарядку по утрам. Но как использовать эти инструменты в реальной работе с coding-агентами? Дальше перейду к тому, как применять субагентов, команды и skills, как заводить сессии, читать код, планировать изменения так, чтобы агент не выпадал из контекста.
Практики работы с контекстом в повседневной разработке
В гайде Sankalp подчеркивает: один чат под все случаи жизни почти гарантированно убивает контекст. Правильный подход — отдельные сессии под крупные задачи и опорные артефакты с инвариантами проекта (CLAUDE.md, README, заметки), которые живут вне чата и подмешиваются в него по мере надобности.
На практике это значит, что у вас всегда есть один файл для агента про проект. В нем описано, что мы делаем, какие есть сервисы и модули, правила код‑стайла и архитектуры, важные ограничения. Любого coding‑агента — в IDE, чате, внутреннем инструменте — нужно приучить работать с этим файлом, как с базой: не пересказывать все заново, а давать ссылку или фрагменты, когда вы заводите новую задачу.
В том же Claude Code этот опорный файл можно не собирать руками с нуля. Я обычно задаю жесткую структуру: «Сгенерируй CLAUDE.md из репозитория с такими секциями: Build & Run c конкретными командами, модули и границы между ними, инварианты по данным (где что хранится и в каком виде), код‑стайл с 3–4 примерами хорошего и плохого кода, как со мной разговаривать: формат ответов, когда обязательно спрашивать уточнения».
Каждый раз вбивать текст руками не надо, технически это один markdown‑файл с соответствующим содержанием, например .claude/commands/init-claude-md.md. В новом проекте просто вызываю созданную команду /init-claude-md, Claude пробегает по package‑файлам, docker‑конфигам и docs и собирает первый черновик по этим разделам — остается только выкинуть лишнее и дописать то, чего в коде не видно.
Дальше я пишу (или вызываю уже готовую команду): «Каждый раз, когда мы договариваемся о новом правиле по логированию, о формате ошибок, о требованиях к тестам, сначала предложи патч к CLAUDE.md, а уже потом меняй код». В результате в кодовой базе появляется живой артефакт с правилами, и любой новый чат с агентом начинается не с угадывания контекста, а с чтения этого файла.
Планы и TODO в markdown, а не в голове
Мне очень понравилась идея Sankalp о том, чтобы фиксировать историю чата в markdown‑файлы. В своем workflow он описывает, что именно добавляет в них, и, по сути, это почти все необходимое: планы, промежуточные решения и TODO. Так и агент, и человек видят актуальное состояние задачи в структурированном виде.
И это та практика, которую очень легко перенести на работу с любым другим coding‑агентом:
Под каждую нетривиальную задачу завести короткий task.md, где хранятся принятые решения, постановка, текущий план и чек‑лист.
Просить агента обновлять этот файл по мере работы вместо того, чтобы переписывать планы в свободном тексте.
Субагенты и таск‑инструменты как рабочие лошади
Продолжая историю workflow от автора гайда, отмечу еще один классный способ структурировать работу. Sankalp показывает, как разбивает задачу между основным агентом и субагентами: один собирает контекст, второй анализирует код, третий выполняет конкретный шаг плана. Таск‑инструменты помогают управлять этим зоопарком так, что получаются зафиксированные роли и шаги, которые не надо придумывать заново каждый раз.
Мне понравился подход, когда tasks.md считается единственным источником правды по задаче. Я прошу агента: «Создай файл tasks.auth.md для доработки авторизации. Разбей работу на фазы (подготовка, миграции, обновление API, UX-фиксы, регрессия), внутри каждой фазы — конкретные шаги и тесты. После завершения фазы сам помечай ее выполненной и добавляй краткий лог: что именно поменяли и где».
Если поменялись требования или в проекте много изменений, я прошу: «Синхронизируй tasks.auth.md с текущим состоянием репозитория и предложи новый план, который учитывает уже сделанные коммиты». Получается нормальный replan по живому проекту, а не повторение всей истории с нуля.
А в работу с разными coding-агентами это можно внедрить так:
Завести «ролевых» субагентов или хотя бы отдельные шаблоны чатов, если есть регулярные повторяющиеся типы задач. Например, для ревью кода, разбора багрепортов или рефакторинга.
Заставить основного агента работать координатором: отдавать подзадачи субагентам и использовать ответы-выжимки от них как часть своего контекста.
Например, у меня это превратилось в пайплайн: первый агент — «прочитать и законспектировать код», второй — «спланировать изменения», третий — «внести правки по плану». Их роли жестко разделены: «читалка» выдает code-review.md с обзором модулей и списком подозрительных мест, «планировщик» на основе этого файла и ТЗ строит tasks.feature.md, а основной рабочий чат вообще не ходит по сырому коду — он берет план и делает диффы по шагам.
Если вы используете агент в CLI (как Claude Code) или через Cursor, это хорошо ложится на разные команды: одна всегда запускает «читалку», другая — «планировщик», третья — «исполнитель плана». Главное — не смешивать всех агентов в одном бесконечном чате, а заставить себя и агента уважать разные режимы работы.
MCP-тулы и внешние системы
Отдельный уровень контекста — это MCP-серверы, которые подключают агента к внешним источникам данных: базе, таск-трекеру, мониторингу, CI. Вместо того чтобы тащить в чат километры логов или текст тикета, я прошу агента: «Через MCP-клиент для Jira подтяни ISSUE-12345, сформируй краткое описание проблемы и список шагов воспроизведения». В контекст попадает уже структурированная выжимка, а не сырое содержимое тикета.
В похожем духе работает связка с БД: с MCP-сервером поверх Postgres агент не просит у меня дамп таблиц, а выполняет конкретные запросы вроде «покажи последние 50 ошибок по пользователям с такими-то флагами» и сверяет гипотезу прямо на данных. MCP требует настроек и разграничения прав, но если один раз продумать этот слой, то управлять контекстом задач становится сильно удобнее.
Результат вызова MCP, например описание тикета, я тоже прошу сохранять в отдельный markdown рядом с таск-файлами и в следующей сессии только обновляю данные, если над��.
Правда, если не управлять интеграциями, тоже можно получить раздутый контекст. Агент может подтягивать лишние логи и тикеты «на всякий случай», поэтому я стараюсь явно проговаривать: «Для этой задачи используй Jira и БД, мониторинг трогай, только если я отдельно попрошу».
Прием «сначала читать и планировать, потом трогать файлы»
Агент, который сразу бросается что‑то менять в коде, почти всегда делает лишние или случайные шаги: он еще не успел собрать целостную картину, а контекст уже начал плыть. Надежнее заставить его пройти три обязательных шага: сначала прочитать и законспектировать, затем спланировать и только потом править.
На практике это превращается в стабильный шаблон диалога с любым coding‑агентом:
«Сначала прочитай вот эти файлы и опиши, как сейчас устроен модуль и где могут быть баги».
«Теперь предложи план изменений в несколько шагов, не правь код».
«Дальше вноси правки строго по плану, если от него отходишь, то объясни почему».
Когда я перестал разрешать агенту сразу править код, исчезла целая категория ситуаций: лишние регенерации диффов, попытки «угадать» архитектуру по одному фрагменту. По ощущениям, это дало плюс не столько к скорости, сколько к плотности работы: на одну и ту же фичу стало уходить меньше сессий и промптов, где я объясняю одно и то же разными словами. Токены тратятся на продвижение по плану и на полезную работу, а не на проверки и переделки того, что уже сделано раньше.
Регулярное сжатие истории и handoff
Кроме того, важно не тащить одну сессию до бесконечности, и об этом автор гайда тоже говорит. Вместо этого время от времени нужно останавливать диалог и просить агента сделать компактное резюме: что мы уже поняли, какие решения приняли, какие TODO остались.
Дальше это резюме лучше сохранить как опорный артефакт (файл, комментарий в таске, заметка) и продолжать работу уже от него, а не от километров старой переписки. Правильный момент «убить» чат — не тогда, когда все развалилось, а когда накопился первый цельный кусок результата: план, архитектурное решение, серия коммитов. В новой сессии вы даете только это резюме и актуальное ТЗ — так агент меньше утонет в старом шуме.
Handoff я стараюсь формулировать максимально утилитарно. Типичный запрос выглядит так: «Собери резюме нашей работы в 30–40 строк для новой сессии: контекст задачи, принятые архитектурные решения, ключевые файлы, список открытых TODO. Не пересказывай историю чата, только текущее состояние файлов и факты».
Это резюме я кладу в отдельный markdown в ту же директорию, где лежат CLAUDE.md и таск‑файлы, или прикрепляю в комментарий к задаче в трекере. Именно поэтому для следующего захода у меня всегда есть одна ссылка вида handoff‑reporting‑2025‑11‑15.md, которую можно отдать новому агенту.
System‑reminders
Дельная мысль из гайда — system‑reminders и похожие механизмы, которые тихо подмешивают в контекст «правила жизни», даже если не повторять их в каждом сообщении. Это могут быть требования к стилю кода, ограничения по безопасности, договоренности по логированию, форматам ошибок и любым другим инвариантам проекта.
Можно эмулировать system‑reminders через первые сообщения новой сессии: вставлять туда короткий блок с правилами и ссылками на опорные файлы, чтобы агент видел их с самого начала, а не где‑то посередине истории.
Если внедрить все практики и привыкнуть ими пользоваться, получается стройная и удобная система, в которой контекст не уплывает. Выглядит примерно так:
Вместо вывода: о чем на самом деле эта история
Если все это собрать, контекст‑инжиниринг для coding‑агентов сводится к простой мысли: модель реже тупит, когда мы относимся к ее контекстному окну как к ограниченному инженерному ресурсу, а не как к бесконечной мусорке. Отдельные сессии под задачи, опорные файлы с инвариантами, субагенты под тяжелые шаги, команды и skills, markdown‑планы, регулярные резюме и system‑reminders — это не украшения, а способ сделать работу агента предсказуемой и воспроизводимой.
Если вы хотите глубже покопаться в том, как эти идеи реализованы именно в Claude Code 2.0, очень рекомендую прочитать оригинальный гайд Sankalp Shubham: там больше деталей по конкретным командам, устройству субагентов и примерам CLAUDE.md и workflow. Да и в целом это очень подробная инструкция к тому, как жить с coding-агентами в ладу.
Ну а я приглашаю вас обсудить в комментах идеи из гайда или этой статьи.