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

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

Автор: sysls

Перевод: Deep潮 TechFlow

Обзор Deep潮: разработчик-блогер sysls с 2,6 миллионами подписчиков написал длинную практическую статью, которую перепостили 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 разговором назад застрял из-за слишком большого количества подпроцессов. Всегда писать заметки? Хорошо… А какая связь с игрой «угадай слово»?

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

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

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

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

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

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

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

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

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

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

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

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

Ограничения из-за склонности к угождению

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Есть очень простой способ. Создайте 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) похожи на правила, только скорее описывают «шаги операции». Если у вас есть конкретный способ, которым должна выполняться задача, запишите его в навык.

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

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

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

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

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

И тут…

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

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

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

Что делать?

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

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

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

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

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

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

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