Claude и Codex становятся тупее по мере использования? Потому что ваш контекст слишком раздут.

Автор: sysls

Адаптация: TechFlow

Введение от TechFlow: Блогер-разработчик sysls с аудиторией в 2,6 миллиона человек написал практическое руководство, которое переслали 827 раз и лайкнули 7000 пользователей. Его главный тезис прост: ваши плагины, системы памяти и различные harness скорее мешают, чем помогают. Эта статья не преподносит абстрактных теорий — это набор прикладных принципов, выведенных из реальных производственных проектов. От контроля контекста и работы со склонностью ИИ к угодничеству до определения условий завершения задач — на сегодняшний день это самое ясное руководство по инженерии работы с Claude/Codex, с которым мне приходилось сталкиваться.

Полный текст статьи:

Введение

Вы разработчик, который ежедневно работает с Claude и Codex CLI и постоянно задается вопросом, удается ли вам по-настоящему использовать весь потенциал этих инструментов. Иногда вы видите, как они творят совершенно безумные вещи, и не понимаете, почему одни люди, кажется, строят ракеты на базе ИИ, а вы еле справляетесь даже с тем, чтобы устойчиво сложить два камня.

Вы вините во всем свой harness, плагины, терминал или что-то еще. Вы используете beads, opencode, zep, а ваш CLAUDE.md занимает уже 26 000 строк. Но сколько бы вы ни экспериментировали, так и не можете понять, почему вы все дальше от идеала, пока другие играют с ангелами.

Это именно та статья, которую вы ждали.

Кроме того, здесь нет скрытых интересов. Когда я говорю CLAUDE.md, я имею в виду и AGENT.md. Когда я говорю Claude, я имею в виду и Codex — я активно использую оба инструмента.

За последние месяцы я заметил одну интересную вещь: практически никто по-настоящему не знает, как максимально раскрыть потенциал агентов.

Создается впечатление, что лишь горстка людей умеет заставлять агентов строить целый мир, в то время как остальные крутятся в бесконечном море инструментов, страдая от синдрома выбора и полагая, что нашли правильную комбинацию пакетов, навыков или harness, чтобы разблокировать AGI.

Сегодня я хочу разрушить этот миф и оставить вам всего одну простую и честную фразу, от которой мы и будем отталкиваться. Вам не нужен последний релиз агентного harness, не нужно устанавливать миллионы пакетов и вовсе не обязательно читать сотни статей, чтобы оставаться конкурентоспособным. На деле ваша избыточная увлеченность может нанести больше вреда, чем пользы.

Я не турист — начал пользоваться ими тогда, когда агенты едва справлялись с написанием кода. Я перебрал все пакеты, все harness и все парадигмы. Я использовал агентные фабрики для создания сигналов, инфраструктуры и конвейеров данных — это были не «играбельные прототипы», а реальные рабочие кейсы, развернутые в production. После всего этого…

сегодня моя рабочая конфигурация проста до невозможности: базовый CLI (Claude Code и Codex) плюс понимание нескольких фундаментальных принципов агентной инженерии — и именно так мне удалось совершить самые значительные прорывы в моей карьере.

Понимание скорости изменений

Во-первых, важно понять, что компании, разрабатывающие базовые модели, находятся на этапе революционного скачка, и замедляться они явно не собираются. Каждое улучшение «агентного интеллекта» меняет способ нашего взаимодействия с ними, поскольку агенты спроектированы так, чтобы всё охотнее следовать инструкциям.

Еще несколько поколений назад, если бы вы написали в CLAUDE.md «перед любыми действиями сначала прочитай READTHISBEFOREDOINGANYTHING.md», с вероятностью 50% он бы ответил матом и сделал бы всё по-своему. Сегодня он выполняет большинство команд, включая сложные вложенные инструкции — например, «сначала прочитай A, затем B, а если условие C выполнено, читай D». В большинстве случаев он с радостью будет выполнять такие цепочки.

Что из этого следует? Самый важный принцип заключается в осознании того факта, что каждое новое поколение агентов заставляет вас заново переосмысливать оптимальные решения, и именно поэтому здесь работает принцип «меньше — значит лучше».

Когда вы используете множество разных библиотек и harness, вы запираете себя внутри конкретного «решения», но для следующего поколения агентов эта проблема может вообще не существовать. Знаете ли вы, кто является самым преданным и наиболее активным пользователем агентов? Правильно — сотрудники передовых компаний. У них безлимитные бюджеты на токены, и они используют самые свежие модели. Вы понимаете, к чему я веду?

Это означает следующее: если существует реальная проблема и найдено эффективное решение, именно передовые компании станут его главными потребителями. А что они сделают дальше? Они интегрируют это решение в свои продукты. Подумайте сами, зачем корпорации позволят стороннему продукту решать их реальные боли и создавать внешнюю зависимость? Откуда мне это известно? Посмотрите на навыки (skills), harness для памяти, субагентов... Всё это начиналось как «подход» к решению конкретных проблем, прошло проверку в боевых условиях и доказало свою эффективность.

Таким образом, если технология действительно прорывная и способна существенно расширить сферы применения агентов, она рано или поздно войдет в базовые продукты вендоров. Поверьте мне, разработчики базовых моделей движутся очень быстро. Поэтому расслабьтесь: вам не нужно устанавливать ничего лишнего или зависеть от внешних зависимостей, чтобы достигать лучших результатов.

Я предсказываю, что комментарии вскоре заполнятся сообщениями вроде: «СисЛС, я использую такой-то harness, это невероятно! Я восстановил Google за один день!» — на что отвечу: поздравляю! Но вы не моя целевая аудитория. Вы представляете собой крайне узкую группу энтузиастов, которые действительно разобрались в агентной инженерии.

Контекст — это всё

Честно говоря, контекст — это абсолютно всё. Еще одна проблема использования тысяч плагинов и внешних зависимостей заключается в том, что вы страдаете от «раздувания контекста» — ваш агент просто тонет в избытке информации.

«Напиши игру в угадывание слов на Python»? Легко. Постойте, что это за заметка «Управление памятью» от 26 сессий назад? А, пользователь застрял в своем окне 71 сессия назад из-за того, что мы слишком много создавали дочерних процессов. Всегда оставлять заметки? Хорошо, принято... Как это связано с игрой в слова?

Вы понимаете о чем я. Вы хотите дать агенту ровно столько информации, сколько нужно для выполнения задачи — ни больше, ни меньше. Чем лучше вы контролируете этот параметр, тем эффективнее работает агент. Стоит вам начать внедрять странные системы памяти, плагины или слишком запутанные по названию и вызову навыки, как вы буквально даете ему инструкцию по изготовлению бомбы и рецепт торта, хотя просите написать лишь короткое стихотворение о секвойях.

Поэтому я вновь призываю вас — избавьтесь от всех зависимостей, а затем…

Займитесь действительно полезным делом

Точно описывайте детали реализации

Помните, что контекст — это всё?

Помните, что вы хотите дать агенту ровно тот объем информации, который необходим для задачи?

Первый способ достичь этого — разделить этапы исследования и реализации. Будьте предельно точны в том, чего именно вы требуете от агента.

К чему приводит неточность? Формулировка «Реализуй систему аутентификации» заставит агента самому исследовать: что такое система аутентификации? Какие есть варианты? Каковы их плюсы и минусы? Ему придется самостоятельно искать в интернете массу бесполезной информации, которая засорит контекст различными деталями реализации. Когда же дело дойдет до непосредственного написания кода, выше риск ошибки или появления галлюцинаций, несущих ненужные или нерелевантные детали выбранного подхода.

С другой стороны, если вы скажете: «Реализуй JWT-аутентификацию с использованием хеширования паролей bcrypt-12, ротацией refresh-токенов и сроком действия 7 дней...», агенту не придется искать альтернативы. Он поймет вашу задачу и сможет наполнить контекст исключительно нужными техническими деталями.

Очевидно, вы не всегда знаете все детали реализации. Часто вы не уверены в правильном подходе или даже хотите делегировать агенту выбор технических решений. Что делать в таком случае? Просто создайте исследовательскую задачу для анализа вариантов реализации. Решите сами или поручите агенту выбрать лучший подход, после чего передайте задачу другому агенту, который начнет работу с чистым контекстом.

Как только вы начнете мыслить в этом ключе, вы сразу увидите места, где контекст агента загрязнен лишней информацией в вашем рабочем процессе. Затем вы сможете возвести изоляционные стены в вашей агентной архитектуре, абстрагируя посторонние данные и оставляя только тот контекст, который позволяет агенту сиять. Запомните: вы работаете с невероятно талантливым и умным коллегой, который знает всё о всех видах шаров во вселенной. Но пока вы не скажете ему, что хотите спроектировать пространство для танцев и веселья, он будет часами перечислять вам свойства сферических объектов.

Ограничения дизайна, связанные со склонностью к угодничеству

Никому не хочется пользоваться продуктом, который постоянно критикует, говорит, что вы неправы, или полностью игнорирует ваши команды. Поэтому эти агенты будут стараться согласиться с вами и сделать именно то, что от них требуется.

Если вы попросите вставить слово «радость» каждые три слова, оно попытается выполнить просьбу — это понятно большинству. Именно послушание делает эти инструменты такими удобными. Но здесь есть интересный нюанс: это означает, что если вы скажете «найди баг в моем репозитории», агент обязательно его найдет — даже если придется его искусственно создать. Почему? Потому что агенты чрезвычайно мотивированы следовать вашим указаниям!

Большинство пользователей скоро начинают жаловаться на галлюцинации LLM и придумывание несуществующего, даже не подозревая, что проблема кроется в них самих. Даете команду найти что-то — получаете результат, пусть даже с натяжкой реальности!

Что с этим делать? Я обнаружил, что «нейтральные промпты» работают отлично — они не задают направление к конкретному результату. Например, вместо «найди мне баг в базе данных» я пишу: «Отсканируй всю базу данных, проследите логику каждого компонента и отчитайтесь обо всех найденных особенностях».

Такие нейтральные запросы иногда находят реальные ошибки, а иногда просто объективно описывают работу кода. При этом они не формируют у агента предвзятости в сторону наличия багов.

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

Поэтому я даю агенту для поиска ошибок задачу идентифицировать все потенциальные недочеты в базе данных. Я назначаю баллы: легкий дефект — +1, умеренный — +5, критический — +10. Я заранее знаю, что этот агент с энтузиазмом выдаст список всех возможных отклонений (даже тех, что не являются ошибками), и представит отчет, например, с результатом «104 балла». Для меня это надмножество всех возможных проблем.

Затем я подключаю агент-контраргументатор. Его задача — оспаривать каждую найденную ошибку. За успешное опровержение он получает баллы соответствующей ошибки, а за ложное утверждение теряет двойную сумму баллов. Этот агент постарается оспорить максимум пунктов, но благодаря системе штрафов будет проявлять осторожность. Он все равно активно будет «опровергать» находки (включая настоящие баги). Это множество становится подмножеством истинных ошибок.

На финальном этапе судья агрегирует результаты обоих агентов и ставит оценки. Я объясняю судье, что существует единственный верный ответ: +1 за правильное совпадение, -1 за ошибку. Судья оценивает вклады первого и второго агентов по каждой точке. То, что подтвердит судья, я беру на верификацию. Чаще всего этот подход демонстрирует удивительно высокую точность. Время от времени сбои случаются, но система работает почти безошибочно.

Возможно, для кого-то хватит одного поискового агента, но данный метод отлично работает для меня, потому что он эксплуатирует фундаментальную запрограммированную особенность каждого агента — стремление угодить.

Как определить, что полезно, а что стоит применять?

Этот вопрос кажется сложным, будто для ответа на него нужно углубленное изучение и постоянное слежение за трендами в области ИИ. На деле всё просто: если OpenAI или Anthropic внедрили подобный функционал или приобрели компанию, его разработавшую... скорее всего, это действительно полезно.

Заметили ли вы, что «навыки (skills)» стали универсальным стандартом и частью официальной документации как для Claude, так и для Codex? Замечали ли вы покупку OpenClaw компанией OpenAI? Замечали ли вы, что Anthropic тут же добавила функции памяти, голосового ввода и удаленной работы?

Что касается планирования (planning)? Помните, как многие обнаружили неоценимую пользу последовательности «планирование перед реализацией», после чего это стало ключевой встроенной функцией?

Да, это действительно стоящие вещи!

Вспомните бесконечные хаки stop-hooks, которые были жизненно необходимы, потому что агенты категорически отказывались долго работать... а затем появился Codex версии 5.2, и эта потребность мгновенно исчезла.

Это всё, что вам нужно знать... Если технология действительно важна и полезна, Claude и Codex внедрят её сами! Поэтому вам не стоит слишком волноваться насчет использования новых фишек или необходимости постоянно обучаться. Даже поддерживать знания в актуальном состоянии необязательно.

Сделайте мне одолжение. Периодически обновляйте выбранный CLI-инструмент и читайте списки новых возможностей. Этого более чем достаточно.

Компрессия, контекст и гипотезы

При работе с агентами некоторые пользователи сталкиваются с серьезной проблемой: иногда они кажутся самыми разумными существами на планете, а порой вы просто отказываетесь верить, что вас в очередной раз обманули.

"Он умный? Да он просто идиот!"

Главное отличие кроется в том, заставляете ли вы агента принимать решения на основе предположений или «заполнять пробелы». В наше время они всё ещё ужасно справляются с задачей «связывания точек», «восполнения недостатка данных» или формирования собственных гипотез. Как только они начинают так поступать, вы это сразу замечаете, а качество работы резко падает.

Одно из важнейших правил в CLAUDE.md касается процесса получения контекста. Укажите агенту, что первым делом при каждом обращении к файлу (а это происходит после любой компрессии контекста) он должен прочитать именно это правило. В рамках настройки получения контекста пара простых директив способна творить чудеса: перечитывать план задачи и вновь открывать связанные с текущей задачей файлы перед продолжением работы.

Объясняйте агенту, когда задача завершена

Для нас, людей, понятие «задача выполнена» вполне очевидно. Самая большая проблема современных агентов заключается в том, что они прекрасно знают, с чего начать, но совершенно не понимают, когда пора остановиться.

Это нередко приводит к крайне разочаровывающим результатам: агент пишет кучу заглушек и считает, что работа окончена.

Тестирование — отличный ориентир для агента, поскольку тесты детерминированы, и вы можете задать предельно четкие критерии успеха. Пока не пройдут X проверок, ваша задача не считается выполненной; при этом запрещено изменять сами тесты.

Затем вам останется лишь проверить результаты, и когда все тесты пройдены, вы будете спокойны. Автоматизацию тоже можно подключить, но главное запомнить: «конец задачи» интуитивно понятен человеку, но совершенно нет — агенту.

А знаете, что еще недавно стало рабочей меткой окончания задачи? Скриншоты и их верификация. Вы можете поручить агенту дорабатывать функцию до прохождения всех тестов, а затем попросить сделать скриншот интерфейса и сравнить визуальный результат с ожидаемым дизайном или поведением.

Это позволяет Агенту продолжать итерации и приближаться к желаемому дизайну, не опасаясь, что он бросит работу после первой попытки!

Логичным продолжением этой идеи станет создание «соглашения» (contract) с агентом и его интеграция в правила. Например, файл `{TASK}CONTRACT.md` регламентирует обязательные шаги перед разрешением завершить сессию. Внутри этого документа вы пропишете тесты, создание скриншотов и иные проверки, которые необходимо выполнить до вашего подтверждения о готовности задачи.

Агенты на постоянном ходу

Меня часто спрашивают: как заставить агента работать непрерывно 24 часа, гарантируя при этом, что он не сорвется с пути?

Есть простое решение. Настройте stop-hook, который не позволит агенту закрыть сессию, пока не будут выполнены абсолютно все пункты из `{TASK}_CONTRACT.md`.

Если у вас есть 100 подобных четко регламентированных соглашений, описывающих ваше видение проекта, stop-hook будет блокировать завершение работы, пока все 100 контрактов не будут исполнены вместе с необходимыми тестами и проверками!

Совет профессионала: я выяснил, что длительные 24-часовые сессии структурно неэффективны для самой работы. Частично это связано с тем, что такой формат неизбежно провоцирует раздувание контекста, ведь сведения из unrelated контрактов смешиваются в одном сеансе!

Поэтому я не рекомендую так поступать.

Существует более эффективный подход к автоматизации: создавайте новую сессию для каждого отдельного контракта. Каждый раз, когда требуется выполнить задачу, оформляйте ее в виде соглашения.

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

Это полностью трансформирует ваш опыт взаимодействия с агентами.

Итерация, итерация, итерация

Вы наняли помощника: ожидаете ли вы, что он узнает ваше расписание с первого дня? Или знает, как вы пьете кофе? Отдаете предпочтение ужину в 18:00, а не в 20:00? Конечно, нет. Предпочтения вырабатываются постепенно.

С агентами то же самое. Начните с минимально возможной конфигурации. Забудьте о сложных структурах или излишнем инструментарии — дайте шанс базовому CLI.

Затем постепенно внедряйте свои предпочтения. Как именно?

Правила

Если вы не хотите, чтобы агент выполнял определенные действия, оформите это как правило. Пропишите его в CLAUDE.md. Например: «Перед написанием кода прочитай `coding-rules.md`». Правила могут быть вложенными и условными! Пишете код — читаете `coding-rules.md`; пишете тесты — читаете `coding-test-rules.md`. Тесты падают — применяете `coding-test-failing-rules.md`. Вы можете создавать сколь угодно сложные логические ветвления правил, которыми будет следовать агент, главное — четко задокументировать их в CLAUDE.md.

Фактически, это мой первый практический совет: рассматривайте CLAUDE.md как логичный вложенный каталог, указывающий, где брать контекст для конкретных сценариев. Документ должен быть предельно лаконичным и содержать исключительно логику типа IF-ELSE, определяющую, куда обращаться в той или иной ситуации.

Заметили, что агент совершает действие, с которым вы не согласны? Добавьте запрет в качестве правила, обязывающего агента перед повторением данного действия ознакомится с ним снова, и подобные ошибки точно не повторятся.

Навыки

Навыки (Skills) похожи на правила, но вместо личных предпочтений в коде они эффективнее фиксируют конкретные «шаги по выполнению операций». Если у вас есть определенный алгоритм того, как должна решаться определенная задача, вынесите его в навык.

Чаще всего люди жалуются на непредсказуемость действий агента, что вызывает беспокойство. Чтобы обеспечить детерминированность результата, попросите агента сначала проанализировать, каким образом он решил бы эту проблему, а затем запишите полученный алгоритм в файл навыка. Вы заранее увидите подход агента к решению задачи и сможете скорректировать или улучшить его до начала реальной работы.

Как сообщить агенту о существовании такого навыка? Верно! Вы прописываете в CLAUDE.md, что при столкновении с данной сценой необходимо открыть `SKILL.md`.

Управление правилами и навыками

Будет естественным желанием постоянно добавлять агенту новые правила и навыки. Именно так вы придаете ему индивидуальность и закрепляете ваши предпочтения. Почти всё остальное — лишний шум.

Как только вы начнете действовать по этой схеме, ваш агент заработает словно волшебство. Он начнет действовать «так, как хотите вы». Наконец-то вы ощутите, что постигли суть агентной инженерии.

Но потом…

Вы заметите, что качество работы снова начнет падать.

Что происходит?!

Ответ прост. По мере накопления правил и навыков они начинают противоречить друг другу, либо агент начинает страдать от критического раздувания контекста. Вы заставляете его перед началом работы изучать 14 файлов Markdown, и он сталкивается с тем же перенасыщением бесполезными данными.

Что делать?

Проведите уборку. Позвольте агенту пройти процедуру «СПА»: консолидируйте правила и навыки, устранив противоречия путем актуализации ваших новых предпочтений.

После этого магия вернется.

На этом всё. Вот в чем настоящий секрет. Сохраняйте простоту, используйте правила и навыки, относитесь к CLAUDE.md как к каталогу и бережно относитесь к ограничениям контекста и особенностям проектирования.

Несите ответственность за результат

Идеального агента сегодня не существует. Вы можете делегировать значительную часть проектных и implementационных работ, однако полную ответственность за итог несете вы.

Поэтому действуйте осторожно... и получайте удовольствие!

Играться с игрушками будущего (параллельно решая серьезные задачи) — настоящее удовольствие!