Фьючерсы
Доступ к сотням фьючерсов
TradFi
Золото
Одна платформа мировых активов
Опционы
Hot
Торги опционами Vanilla в европейском стиле
Единый счет
Увеличьте эффективность вашего капитала
Демо-торговля
Начало фьючерсов
Подготовьтесь к торговле фьючерсами
Фьючерсные события
Получайте награды в событиях
Демо-торговля
Используйте виртуальные средства для торговли без риска
Запуск
CandyDrop
Собирайте конфеты, чтобы заработать аирдропы
Launchpool
Быстрый стейкинг, заработайте потенциальные новые токены
HODLer Airdrop
Удерживайте GT и получайте огромные аирдропы бесплатно
Launchpad
Будьте готовы к следующему крупному токен-проекту
Alpha Points
Торгуйте и получайте аирдропы
Фьючерсные баллы
Зарабатывайте баллы и получайте награды аирдропа
Инвестиции
Simple Earn
Зарабатывайте проценты с помощью неиспользуемых токенов
Автоинвест.
Автоинвестиции на регулярной основе.
Бивалютные инвестиции
Доход от волатильности рынка
Мягкий стейкинг
Получайте вознаграждения с помощью гибкого стейкинга
Криптозаймы
0 Fees
Заложите одну криптовалюту, чтобы занять другую
Центр кредитования
Единый центр кредитования
Клод и 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, вы застреваете в рамках одного «решения», но в следующем поколении агенты могут этого решения просто не требовать. Знаете, кто самый активный и преданный пользователь агента? Правильно — сотрудники передовых компаний, у которых безлимитный токен-бюджет и самые новые модели. Понимаете, что это значит?
Это значит, что если существует реальная проблема и есть хорошее решение, то передовые компании станут их крупнейшими пользователями. А что они сделают дальше? Они интегрируют это решение в свои продукты. Подумайте: почему одна компания позволит другому продукту решать реальные боли и создавать внешние зависимости? Как я могу это узнать? Посмотрите на навыки, системы памяти, harness, субагентов — всё начинается с решения реальной проблемы, проверенного на практике и доказавшего свою полезность.
И если что-то действительно прорывное и способное масштабировать применение агентов в значимой мере, рано или поздно оно станет частью ядра продукта компании. Поверьте, компании движутся очень быстро. Так что расслабьтесь — вам не нужно ничего устанавливать или зависеть от внешних источников, чтобы делать отличную работу.
Я предсказываю, что в комментариях скоро появится: «SysLS, я использовал такой-то harness, и у меня получилось перепроектировать Google за один день!» — и скажу вам: поздравляю! Но вы не целевая аудитория. Вы — представитель очень узкой, действительно разбирающейся в инженерии агентов группы.
Контекст — всё
Честно говоря, контекст — всё. Ещё одна проблема при использовании множества плагинов и внешних зависимостей — это «раздувание контекста» — когда ваш агент поглощён слишком большим объёмом информации.
Давайте сделаем игру в угадайку слов на Python? Просто. Подождите, а что за заметка «управление памятью» перед 26-м разговором? А, пользователь за 71 разговор до этого застрял из-за слишком большого количества подпроцессов. Всегда писать заметки? Хорошо, без проблем… А какая тут связь с игрой в угадайку?
Понимаете. Вы хотите дать агенту только ту информацию, которая действительно нужна для выполнения задачи — ни больше, ни меньше! Чем лучше вы контролируете это, тем лучше работает агент. Как только вы начинаете вводить странные системы памяти, плагины или слишком много запутанных навыков с разными именами и вызовами, вы даёте агенту инструкцию по взрывному устройству и рецепт торта одновременно, а вам нужно, чтобы он написал короткое стихотворение о красных секвойях.
Поэтому я снова проповедую — избавляйтесь от всех зависимостей, и…
Делайте действительно полезное
Точно описывайте детали реализации
Помните, что контекст — всё?
Помните, что вы хотите дать агенту только ту информацию, которая действительно нужна для выполнения задачи, и ничего лишнего?
Первый способ добиться этого — разделить исследование и реализацию. Вы должны быть очень точны в том, что просите агента сделать.
Что произойдет, если вы будете неточны? «Создай систему аутентификации». Агент начнет исследовать: что такое система аутентификации? Какие есть варианты? Какие плюсы и минусы? Сейчас он пойдет искать в интернете кучу информации, которая ему не пригодится, и в контексте будет полно возможных реализаций. Когда придет время реализовать, он может запутаться или начать фантазировать о неактуальных деталях.
Обратная ситуация: скажите «Реализуй JWT-аутентификацию с bcrypt-12, ротацией токенов, сроком жизни 7 дней…» — и он сразу поймет, что вам нужно, и заполнит контекст деталями реализации.
Конечно, вы не всегда знаете детали реализации. Часто вы не знаете, что правильно, и иногда хотите поручить агенту решить, как реализовать. Что делать в этом случае? Очень просто — создайте задачу исследования, чтобы изучить возможные реализации, или сами решите, какую выбрать, или пусть агент решит, какую использовать, а другой агент с новым контекстом реализует.
Когда вы начнете так думать, вы заметите, где в рабочем процессе контекст загрязнен лишней информацией, и сможете создать «барьеры» — отделить ненужные сведения, оставить только то, что нужно для хорошей работы в задаче. Помните: у вас есть очень талантливый и умный член команды, который знает все о вселенной — но если вы не скажете ему, что нужно сделать, чтобы создать пространство для танцев и развлечений, он будет постоянно рассказывать о преимуществах сфер.
Ограничения дизайна, основанного на угождении
Никто не хочет использовать продукт, который постоянно критикует вас, говорит, что вы ошибаетесь, или полностью игнорирует ваши команды. Поэтому эти агенты будут стараться соглашаться с вами и делать то, что вы хотите.
Если вы заставите их вставлять после каждых трех слов «счастливый», они постараются — большинство людей это понимает. Их послушание — причина, почему они так хороши. Но есть очень интересная особенность: это значит, что если вы скажете «Найди мне баг в кодовой базе», — он найдет баг, даже если его придется «сделать». Почему? Потому что он очень хочет слушаться вас!
Большинство быстро жалуются на галлюцинации и выдумывание несуществующих вещей у LLM, не осознавая, что проблема в них самих. Вы говорите, что искать — он ищет. Вы говорите, что делать — он делает, даже если немного растягивает факты!
Что делать? Я обнаружил, что «нейтральные подсказки» очень эффективны — не давать агенту склонности к определенному результату. Например, вместо «Найди баг в базе данных» я говорю «Просканируй всю базу данных, попытайся понять логику каждого компонента и сообщи все находки».
Такая нейтральная подсказка иногда обнаружит баг, иногда просто опишет, как работает код. Но она не склоняет агента к предположению, что баг обязательно есть.
Еще один способ бороться с склонностью — превратить её в преимущество. Я знаю, что агент старается угодить и слушается меня, — я могу этим управлять.
Например, я создаю агент по поиску багов и говорю ему: «Каждый низкоimpact баг — +1 балл, среднеimpact — +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 (то есть после каждого сжатия) сначала прочитать это правило. В рамках правил получения контекста — несколько простых команд могут иметь огромное значение: перечитать план задачи и перед продолжением — перечитать связанные файлы.
Как сообщить агенту, как завершить задачу
У нас, людей, есть довольно ясное ощущение, что задача «завершена». У агента же самая большая проблема — он знает, как начать задачу, но не знает, как её закончить.
Это часто приводит к очень разочаровывающим результатам: агент просто реализует несколько заглушек и останавливается.
Тесты — очень хороший ориентир, потому что они детерминированы, можно задать очень четкие ожидания. Пока эти X тестов не пройдены — задача не завершена; и тесты нельзя менять.
После этого достаточно проверить тесты — и можно быть уверенным. Можно автоматизировать этот процесс, но главное — помнить, что «завершение задачи» для человека — естественно, а для агента — нет.
Знаете, что недавно стало возможной точкой завершения задачи? Скриншоты + верификация. Можно заставить агента реализовать что-то, пока все тесты не пройдены, а потом — сделать скриншот и проверить, соответствует ли дизайн или поведение тому, что нужно.
Это позволяет агенту итеративно приближаться к нужному дизайну, не боясь, что он остановится после первой попытки!
Естественное продолжение — создание «контракта» с агентом и внедрение его в правила. Например, этот {TASK}CONTRACT.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)
Skills похожи на правила, только скорее — это описание «операционных шагов». Если у вас есть конкретный способ, которым должна выполняться задача, запишите его как навык.
На самом деле, многие жалуются, что не знают, как агент решит проблему, и это вызывает тревогу. Если хотите сделать решение более предсказуемым — пусть агент сначала изучит, как он собирается решить проблему, а потом запишет это как навык. Тогда вы заранее увидите, как он собирается решать, и сможете исправить или улучшить до того, как он столкнется с задачей.
Как сообщить агенту о существовании этого навыка? Правильно! В CLAUDE.md напишите: «Когда сталкиваешься с этим сценарием — читай этот SKILL.md».
Обработка правил и навыков
Вы, конечно, захотите постоянно добавлять правила и навыки. Это — способ придать агенту индивидуальность и запомнить ваши предпочтения. Всё остальное — лишнее.
Когда вы начнете так делать, ваш агент будет казаться магией. Он будет «делать так, как вы хотите». И вы наконец почувствуете, что «поняли» инженеринг агентов.
И тут…
Производительность начнет снова падать.
Что происходит?!
Очень просто. Чем больше правил и навыков вы добавляете, тем больше они начинают противоречить друг другу или вызывают сильное раздувание контекста. Если вам нужно, чтобы агент перед программированием прочитал 14 markdown-файлов, — у вас возникнет та же проблема с бесполезной информацией.
Что делать?
Очистить. Пусть ваш агент «делает спа», объединяет правила и навыки, и через уточнение ваших новых предпочтений устраняет противоречия.
И снова он будет казаться магией.
Вот и всё. Это — секрет. Держите всё просто: используйте правила и навыки, воспринимайте CLAUDE.md как каталог, и внимательно следите за их контекстом и ограничениями.
Ответственность за результат
Сегодня нет идеальных агентов. Вы можете поручить им много проектных и технических задач, но за результат всё равно отвечаете вы.
Поэтому будьте осторожны… и наслаждайтесь!
Играть с игрушками будущего (при этом, очевидно, делая серьезные вещи) — настоящее удовольствие!