Клод и Codex становятся всё глупее? Потому что ваш контекст слишком раздутый.

Автор: sysls

Перевод: Deep潮 TechFlow

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

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

Введение

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

Вам кажется, что проблема в вашем harness, плагинах или терминале. Вы используете beads, opencode, zep, у вас есть CLAUDE.md на 26000 строк. Но что бы вы ни делали, вам всё равно кажется, что вы всё дальше от рая, а другие играют с ангелами.

Именно такую статью вы давно ждали.

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

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

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

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

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

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

Понимание, что мир движется очень быстро

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

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

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

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

Это значит, что если есть реальная проблема и есть хорошее решение, то передовые компании станут их крупнейшими пользователями. А что они сделают дальше? Встроят это решение в свои продукты. Подумайте: почему одна компания разрешит другому продукту решать реальные боли и создавать внешние зависимости? Как я могу это знать? Посмотрите на навыки, системы памяти, sub-агентов — всё начинается с решения реальной задачи, проверенной в практике и доказавшей свою пользу.

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

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

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

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

Давайте сделаем игру в угадайку слов на Python? Просто. А что, если я скажу, что в этом же диалоге есть комментарий «управление памятью» за 26 сообщений назад? Ага, пользователь за 71 сообщение до этого застрял из-за слишком большого количества подпроцессов. Нужно ли всегда писать комментарии? Хорошо, без проблем… А как это связано с игрой в угадайку?

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

Поэтому я снова проповедую — избавляйтесь от всего лишнего, и…

Делайте действительно важное

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

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

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

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

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

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

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

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

Ограничения, связанные с угождением

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

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

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

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

Такая нейтральная подсказка иногда обнаружит баг, иногда просто опишет, как работает код. Но она не склоняет агента к предположению, что баг обязательно есть.

Еще один способ — превратить склонность к угождению в преимущество. Я знаю, что агент старается меня угодить, и могу немного «подталкивать» его в нужную сторону.

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

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

И наконец, я создаю судейского агента, который объединяет оба мнения и выставляет итоговую оценку. Я говорю ему, что у меня есть истинный ответ: правильный — +1, неправильный — -1. Он оценивает оба агента по каждому «багу». И если судья говорит, что это правда, я проверяю. В большинстве случаев этот метод очень точен, иногда ошибается, но это почти безошибочная система.

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

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

Этот вопрос кажется сложным, будто нужно постоянно учиться и следить за новинками в ИИ. Но на самом деле всё очень просто… если OpenAI и Claude реализовали или приобрели компанию, которая реализует это — значит, это, скорее всего, полезно.

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

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

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

И помните бесконечные stop-hooks — очень полезны, потому что агенты очень неохотно делают долгие задачи… А как только вышел Codex 5.2, эта необходимость исчезла за одну ночь?

Это всё, что вам нужно знать… если что-то действительно важно и полезно, Claude и Codex реализуют это сами! Поэтому вам не нужно переживать о «новых вещах» или «знакомых новинках», вам даже не нужно «оставаться в курсе».

Помогите мне: иногда обновляйте выбранный CLI-инструмент, читайте, что нового добавили. Это уже достаточно.

Сжатие, контекст и гипотезы

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

«Это умный? Да он же дурак!»

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

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

Как указать агенту, как завершить задачу

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

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

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

После этого достаточно проверить тесты — и можно быть уверенным. Можно автоматизировать этот процесс, но главное — помнить, что «завершение задачи» для человека — естественно, а для агента — нет.

Знаете, что еще стало возможной точкой завершения задачи? Скриншоты + проверка. Можно заставить агента реализовать что-то, пока все тесты не пройдут, а затем сделать скриншот и проверить, соответствует ли дизайн или поведение ожидаемому.

Это позволяет агенту итеративно улучшать результат, не останавливаясь после первой попытки!

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

Постоянно работающий агент

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

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

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

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

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

Лучше — для каждого контракта создавать отдельную сессию. Каждый раз, когда нужно что-то сделать, создавайте новый контракт.

Организуйте слой оркестрации, который при необходимости создает новый контракт и новую сессию для его выполнения.

Это кардинально изменит ваш опыт работы с агентами.

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

Вы наняли помощника, и ожидаете, что он с первого дня знает ваш график? Или как вы пьете кофе? Обедаете в 6 вечера, а не в 8? Очевидно, что нет. Вы со временем формируете предпочтения.

То же самое и с агентами. Начинайте с простых конфигураций, забудьте о сложных структурах и harness’ах, дайте шанс базовому CLI.

Постепенно добавляйте свои предпочтения. Как?

Правила

Если не хотите, чтобы агент делал что-то — напишите правило. И скажите ему в CLAUDE.md. Например: «Перед написанием кода прочитать coding-rules.md». Правила могут быть вложенными, условными! Если пишете код — читаем coding-rules.md; если пишете тест — читаем coding-test-rules.md; если тест не прошел — читаем coding-test-failing-rules.md. Можно создавать любые ветвления правил, и Claude (и Codex) с удовольствием следуют им, если в CLAUDE.md есть четкие инструкции.

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

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

Навыки (Skills)

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

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

Как сообщить агенту о существовании навыка? Очень просто! В CLAUDE.md напишите: «Когда встречаешь такой сценарий — смотри в SKILL.md».

Обработка правил и навыков

Вы, конечно, хотите постоянно добавлять правила и навыки. Это — способ придать агенту индивидуальность и закрепить ваши предпочтения. Всё остальное — лишнее.

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

И тут…

Производительность снова начнет падать.

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

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

Что делать?

Очистить. Пусть ваш агент «делает spa», объединяет правила и навыки, и через уточнение ваших новых предпочтений устраняет противоречия.

Тогда он снова станет казаться магией.

Вот и всё. Это — секрет. Держите всё просто, используйте правила и навыки, воспринимайте CLAUDE.md как структуру, и внимательно следите за их контекстом и ограничениями.

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

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

Будьте осторожны… и наслаждайтесь!

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