Как стать агентным инженером мирового класса

Исходный пост: sysls в X. Он цитирует статью ниже.

Я написал это около трёх месяцев назад, и с тех пор:

1) Память более или менее полностью интегрировали во frontier-модели.

2) Почти все функции, которые делали OpenClaw уникальной обвязкой — расписания, циклы, цели, память и т. п. — были полностью поглощены frontier-моделями.

3) Новые вертикально «убийственные» функции и возможности добавляются примерно раз в две недели.

При всём этом агентная инженерия по-прежнему остаётся делом очень высокого мастерства.

Теперь для меня очевидно: между теми, кто МОЖЕТ убрать людей из цикла и реально произвести работающий продукт, и остальным миром, который продолжает настаивать, что агенты производят «slop», лежит пропасть know-how и tacit knowledge.

Оригинальная статья опубликована sysls в X.

Введение

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

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

Это тот текст о вознесении, которого вы ждали.

Также: у меня нет ставки в этой гонке; когда я говорю CLAUDE.md, я также имею в виду AGENT.md, когда я говорю Claude, я также имею в виду Codex. Я очень активно использую и то, и другое.

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

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

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

Я не турист — я использую агентов с тех времён, когда они едва могли писать код. Я пробовал все пакеты, все обвязки и все парадигмы. Я строил агентные фабрики для написания сигналов, инфраструктуры и data pipelines, не «игрушечных проектов», а реальных практических use-cases, которые работали в production, и после всего этого...

Сегодня я работаю с setup, который почти настолько barebones, насколько это возможно, и при этом делаю самую прорывную работу из всего, что делал, используя лишь базовый CLI (claude code и codex) и понимая несколько базовых принципов агентной инженерии.

Поймите, что мир несётся вперёд

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

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

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

Когда вы используете множество разных библиотек и обвязок, вы запираете себя в «решении» проблемы, которой, возможно, уже не будет для будущих поколений агентов. Кроме того, знаете, кто самые увлечённые и крупнейшие пользователи агентов? Верно — сотрудники frontier-компаний, с безлимитным бюджетом токенов и НА САМОМ ДЕЛЕ самыми свежими моделями. Вы понимаете, что из этого следует?

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

Так что если что-то по-настоящему прорывное и значимо расширяет агентные use-cases, со временем это будет встроено в базовые продукты foundational-компаний. Поверьте, foundational-компании ЛЕТЯТ ВПЕРЁД. Так что расслабьтесь: вам не нужно ничего устанавливать или использовать какие-либо дополнительные зависимости, чтобы делать свою лучшую работу.

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

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

Нет, правда. Контекст — это всё. Это ещё одна проблема использования тысячи разных плагинов и внешних зависимостей. Вы страдаете от context bloat — это просто модный способ сказать, что ваши агенты перегружены слишком большим количеством информации!

Сделай мне игру «виселица» на Python? Это легко. Стоп, что это за заметка про «управление памятью» из сессии 26 назад? А, у пользователя завис экран после того, как мы породили слишком много subprocesses 71 сессию назад. Всегда писать заметки? Хорошо, без проблем... Какое всё это имеет отношение к виселице?

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

Так что я снова проповедую: уберите все зависимости, а затем...

Делайте то, что работает

Будьте точны насчёт реализации

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

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

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

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

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

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

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

Дизайнерские ограничения подхалимажа

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

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

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

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

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

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

Поэтому я прошу агента-поисковика багов определить все баги в базе данных, говоря ему, что дам +1 за баги с низким impact, +5 за баги с некоторым impact и +10 за баги с critical impact, и знаю, что этот агент будет гиперэнтузиастом: он выявит все возможные типы багов (даже те, которые на самом деле багами не являются) и вернётся с отчётом со счётом 104 или чем-то в этом духе. Я думаю об этом как о надмножестве всех возможных багов.

Затем я беру adversarial-агента и говорю ему: за каждый баг, который агент сможет опровергнуть как баг, он получает score этого бага, но если ошибётся, получит -2*score этого бага. Теперь adversarial-агент будет пытаться опровергнуть как можно больше багов; но у него есть некоторая осторожность, потому что он знает, что может быть оштрафован. И всё же он будет агрессивно пытаться «опровергнуть» баги (даже настоящие). Я думаю об этом как о подмножестве всех реальных багов.

Наконец, я беру агента-судью, даю ему оба их inputs и прошу оценить их. Я лгу и говорю агенту-судье, что у меня есть реальная правильная ground truth, и если он даст правильную оценку, получит +1 point, а если ошибётся — -1 point. И он оценивает и bug-finder, и adversarial-агента по каждому из «багов». Всё, что судья называет правдой, я проверяю, чтобы убедиться, что это правда. В большинстве случаев точность пугающе высокая, и время от времени они всё ещё ошибаются, но теперь это почти безупречное упражнение.

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

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

Это может показаться очень хитрым вопросом, который требует глубоко всё изучать и находиться на frontier обновлений AI, но всё очень просто... Если OpenAI и Claude оба это реализуют или покупают что-то, что это реализует... Вероятно, это полезно.

Замечаете, что «skills» теперь повсюду и являются частью официальной документации и Claude, и Codex? Видели, как OpenAI приобрела OpenClaw? Видели, как Claude сразу добавил memory, voices и remote work?

А как насчёт planning? Помните, как куча ребят обнаружила, что planning перед implementation — ДЕЙСТВИТЕЛЬНО полезно, а потом это превратилось в core functionality?

Да... Вот это полезно!

Помните, как бесконечные stop-hooks были суперполезны, потому что агенты так неохотно выполняли long running work... А потом вышел Codex 5.2, и это исчезло за одну ночь? Да...

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

Сделайте мне одолжение. Просто время от времени обновляйте выбранный CLI tool и читайте, какие новые features были добавлены. Этого БОЛЕЕ чем достаточно.

Compaction, context и assumptions

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

УМНЫЙ? Эта ШТУКА — идиот!

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

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

Дайте агентам понять, как завершать задачу

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

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

Tests — очень, очень хорошая веха для агентов, потому что они deterministic и позволяют задавать очень ясные ожидания. Пока эти X тестов не проходят, твоя задача НЕ завершена; и тебе НЕ разрешено редактировать tests.

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

Знаете, что ещё недавно стало жизнеспособной конечной точкой задачи? Screenshots + verification. Вы можете заставить агентов реализовывать что-то до тех пор, пока все tests не пройдут, а затем попросить его сделать screenshot и проверить «DESIGN OR BEHAVIOR» на screenshot.

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

Естественное расширение этого — создать «contract» с агентом и встроить его в правило. Скажем, этот {TASK}_CONTRACT.md определяет, что нужно сделать, прежде чем вам разрешено завершить session. В {TASK}_CONTRACT.md вы укажете tests, screenshots и другую verification, которую нужно выполнить, прежде чем вы подтвердите, что задача может закончиться!

Агенты, которые работают вечно

Один из вопросов, который мне часто задают: как люди держат агентов работающими по 24 часа и при этом следят, чтобы они не drift?

Вот очень простой способ. Создайте stophook, который не позволяет агенту завершить session, пока все части {TASK}_contract.md не выполнены.

Если у вас есть 100 таких contracts, которые хорошо специфицированы и содержат ровно то, что вы хотите построить, то ваш stop-hook не позволит агентам завершиться, пока все 100 contracts не будут выполнены, включая все tests и verification, которые нужно run!

Pro tip: я не обнаружил, чтобы long-running 24-часовые sessions были оптимальны для «делания вещей». Отчасти потому, что это по построению вызывает context bloat, внося в session контекст из unrelated contracts!

Так что я этого не рекомендую.

Вот лучший способ для agent automation — новая session на каждый contract. Создавайте contracts всякий раз, когда нужно что-то сделать.

Пусть orchestration layer занимается созданием новых contracts всякий раз, когда «что-то нужно сделать», и созданием новой session для работы над этим contract.

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

Итерируйте, итерируйте, итерируйте

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

То же самое с вашими агентами. Начните bare-bones. Забудьте о сложных структурах или обвязках. Дайте базовому CLI шанс.

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

Rules

Если вы не хотите, чтобы агент что-то делал, запишите это как rule. Затем сообщите агенту об этом rule в вашем CLAUDE.md. Что-то вроде: перед тем как писать код, прочитай «coding-rules.MD». Rules могут быть вложенными, а rules могут быть условными! Если ты пишешь код, прочитай «coding-rules.MD», а если пишешь tests, прочитай «coding-test-rules.MD». Если твои tests падают, прочитай «coding-test-failing-rules.MD». Вы можете создавать произвольные логические ветвления rules, которым нужно следовать, и claude (и codex) с радостью пойдут по ним, если это ясно указано в CLAUDE.md.

На самом деле это ПЕРВЫЙ практический совет, который я даю: воспринимайте ваш CLAUDE.md как логическую вложенную директорию того, где искать контекст в зависимости от сценария и исхода. Он должен быть максимально barebones и содержать только IF-ELSE о том, куда идти за контекстом.

Если вы видите, что агент делает что-то, что вам не нравится, добавьте это как rule и скажите агенту читать rule перед тем, как он снова будет делать ЭТУ ВЕЩЬ, — и он почти наверняка больше не будет так делать.

Skills

Skills похожи на rules, но вместо кодирования предпочтений они лучше подходят для кодирования recipes. Если у вас есть конкретный способ, которым вы хотите, чтобы что-то выполнялось, вы хотите встроить его в skill.

На самом деле люди часто жалуются, что не знают, как агенты могут решать проблему, и это пугает. Что ж, если вы хотите сделать этот способ deterministic, попросите агента исследовать, как он решал бы проблему, и ЗАПИСАТЬ ЭТО КАК SKILL. Вы увидите подход агента к этой проблеме и сможете исправить или улучшить его до того, как он когда-либо столкнётся с этой проблемой в реальной жизни.

Как дать агенту понять, что этот skill существует? Да! Используйте CLAUDE.md и скажите: когда видишь такой сценарий и тебе нужно разобраться с ЭТИМ, прочитай THIS SKILL.md.

Работа с rules и skills

Вы определённо хотите продолжать добавлять rules и skills своему агенту. Так вы даёте ему личность и память о ваших предпочтениях. Почти всё остальное — overkill.

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

А затем...

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

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

Просто. По мере добавления rules и skills они начинают противоречить друг другу, или у агента появляется слишком сильный context bloat. Если агенту нужно прочитать 14 markdown files перед тем, как он начнёт программировать, у него будет та же проблема с большим количеством бесполезной информации.

Так что делать?

Вы наводите порядок. Вы говорите агентам сходить на spa day и консолидировать rules и skills, убрать противоречия, спрашивая у вас обновлённые предпочтения.

И это снова будет ощущаться как магия.

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

Владейте результатом

Ни один сегодняшний агент не идеален. Вы можете переложить большую часть design и implementation на агентов, но вам нужно владеть outcome.

Так что будьте осторожны... И получайте удовольствие!

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