Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 28
Количество статей об агентах начинает утомлять.
Хотя, наверняка до сих пор пишутся книги в стиле "Как стать миллионером, не вставая с дивана".
Как побороли неспособность моделей надёжно формировать diff? Вообще кто-то из крупных игроков (Cursor, Copilot, Claude Code, …) использует diff как основной формат для редактирования файлов моделями?
Удалось ли полностью избавиться от использования шелла для тех задач, которые решать должен другой инструмент?
Codex использует немного модифицированный Unified Diff (тот что уже сто лет использует git) - поэтому OpenAI модели очень хорошо умеют под него генерировать изменения, даже множественных файлов в одном вызове - с этим не было проблем. И на сколько понимаю это стандарт, все модели стараются уметь под него генерировать патч. Вот так же сделано и в OpenCode который использует это для разных моделей.
А избавится от использования шелла полностью конечно ж не получается, причем чем больше контекста, тем более вероятно модель будет использовать только shell - в codex/opencode в общем то такая же проблема (видно по трейсам последнем скрине)
Aider вообще отказался от tool_call для правок. Модель пишет search/replace блоки прямо в тексте ответа, парсер на клиенте их вытаскивает и применяет. Не надо выбирать инструмент, не надо считать строки в diff - и фоллбэков в shell заметно меньше
Отказался или изначально не поддерживал? Я на него последний раз смотрел давно, и мне тогда показалось, что он просто отстал от актуальных технологий и отказался от реализации того, что сделали все остальные и что уже стало стандартом. Может, конечно, у Aider просто свой путь, это тоже норм. Но с точки зрения обычных юзеров этот путь явно менее привлекательный, чем путь Cursor/Copilot/Claude Code/etc.
Большинство существующих агентов для коддинга - мусор. И судя по написанному в статье, ваш не исключение, без обид. Создание качественного агента это не промпт за бутылкой пива, а серьёзная исследовательская работа. То, как агент взаимодействует с моделью, операционной системой и пользователем напрямую влияет на инференс. Поэтому когда на просторах интернета вайбкоддеры начинают сравнивать модели, используя, при этом разные агенты, не вызывает у меня ничего кроме желания сделать facepalm.
RAG? Спасибо, нет
Что же, жаль что вы не смогли осознать как его применять в коддинге. Это весьма полезная вещь если уметь её готовить. Проблема состоит лишь в том, что для конкретного проекта нужен свой подход в применении RAG. Если для вас работа с кодом с помощью LLM это только написание промпта и ожидание результата - то это тот самый вайбкоддинг, от которого ожидать что-то кроме нейрослопа не следует.
Создание качественного агента это не промпт за бутылкой пива, а серьёзная исследовательская работа.
именно такой и был посыл в статье!
то что все пишут что это простой цикл с вызовом тулов - большое заблуждение
К сожалению, ваш агент не далеко ушёл от этого самого простого цикла.
Вот простой минимум контрольных вопросов.
Меняет ли ваш агент системный промпт после первого сообщения пользователя? Например: вы работаете с моделью делая предварительный ресёрч перед запуском основного флоу. Вы задали изначальный промпт (не важно, будет это текст или файл с промптом), после чего получили ответ и продолжаете итеративно менеджить процесс. В первом сообщении, у вас должен быть один системный промпт, в последующих - другой. И так не только для ресёрчей.
Использует ли ваш агент кеш?
Есть ли инструмент позволяющий автоматически запускать субагентов? А не автоматически?
Допустим есть. А как он это делает? Как будет обработан агентом результат работы субагента? Какие инструкции будут даны основному агенту вместе с результатом работы субагента?
Использует ли агент LSP? А как использует? Какие инструкции получает модель вместе с результатом работы LSP?
Использует ли ваш агент правила? Какие инструкции получает модель от агента вместе с правилами?
Про MCP я вообще промолчу.
И повторю, это лишь несколько примеров из того что ваш агент должен уметь для того что бы не быть очередным мусором.
Ну и не могу не упомянуть про суммаризацию. По своей сути, этот механизм был придуман для вайбкодеров, которые не особо то думают головой когда используют LLM для разработки. При более качественном подходе в работе с LLM, этот механизм не нужен вообще. Если в вашей работе с LLM вам необходима суммаризация - вы вероятно не умеете планировать и ставить задачи.
вот это вы токенов потратили на то чтобы сказать то что и так написано в статье: это поделка, учебный пет-проект, конечно там много чего нет и миллион компромиссов
В первом сообщении, у вас должен быть один системный промпт, в последующих - другой.
Чтобы что? В системном промпте обычно задаётся общее поведение агента, та его часть, которая не специфична ни для конкретного проекта, ни для конкретной задачи. Информация о проекте берётся из файлов вроде AGENT.md. Она обычно тоже передаётся в системном промпте, но она тоже не специфична для конкретной задачи. Информация о текущей задаче передаётся в обычном промпте пользователя. Да, к ней иногда желательно прикладывать контекст в стиле AGENT.md только специфичный для конкретного типа задач, и да, этот контекст тоже идёт в системный промпт - но в этом возникает необходимость не настолько часто, чтобы требовать обязательно разных системных промптов в каждом запросе, как это описали Вы.
Есть ли инструмент позволяющий автоматически запускать субагентов?
Субагенты сегодня - довольно сомнительная фича. Мне вообще кажется, что её придумали ради кратного увеличения затрат на токены. Допускаю, что в каких-то задачах/workflow от них есть польза, но вряд ли это тянет на обязательное критичное требование для абсолютно всех агентов.
Ну и не могу не упомянуть про суммаризацию. По своей сути, этот механизм был придуман для вайбкодеров, которые не особо то думают головой когда используют LLM для разработки. При более качественном подходе в работе с LLM, этот механизм не нужен вообще.
Оставим за кадром вопрос пруфов на тему для кого был придуман этот механизм, давайте обсудим определение "более качественный подход".
Довольно очевидно, что для того, чтобы не возникало нужды в продолжении текущей задачи в новом чате, необходимо чтобы текущая задача была завершена полностью (не важно успехом или провалом) в рамках одной сессии. Лично мне не известны рабочие способы решения этой проблемы: невозможно заранее предсказать сколько токенов потребуется модели для обработки запроса, и не превысит ли это количество оставшееся количество токенов в текущей сессии.
А когда сессия оборвалась в процессе работы над задачей нам в любом случае нужно какое-то саммари для продолжения работы в новой сессии. Генерировать его автоматически и использовать без ревью - да, это типичный выбор вайб-кодеров. Но никто же не мешает генерировать его и использовать результат как вспомогательный материал для ручного формирования первого промпта в новой сессии.
Автоматизированные агенты могут использовать саммари оборванной сессии для того, чтобы попытаться переформулировать/декомпозировать задачу оборванной сессии, чтобы повысить шанс что новая попытка выполнения задачи впишется по объёму в новую сессию.
Ну т.е. говорить о полной бесполезности и ненужности саммари довольно странно. Если у вас есть рабочее решение этой проблемы, конкретное описание упомянутого Вами "более качественного подхода" - расскажите, что это за подход и как он решает эту проблему.
Чтобы что?
Речь не о замене промпта на что-то принципиально другое6 а добалении инструкций говорящих модели об итерации. И это не я придумал.
Субагенты сегодня - довольно сомнительная фича. Мне вообще кажется, что её придумали ради кратного увеличения затрат на токены.
Использование субагентов позволяет атомизировать подзадачи, и как следствие - повышать их качество выполнения за счёт маленьких, но гарантированно решаемых задач. Вопрос токенов тут не стоит. Как показывает практика, затраты токенов на применение субагентов, примерно равносильны затратам при их неиспользовании. Это происходит из-за увеличения итераций доработок при линейном подходе.
Оставим за кадром вопрос пруфов на тему для кого был придуман этот механизм, давайте обсудим определение "более качественный подход".
В чём необходимость пруфов не ясно. Однако ясно, появление механизма сжатия - это решения проблемы переплонения контекстного окна в угоду процесса (именно процесса, который для многих кажется правильным, когда готовият огромную задачу и тупо ждут результата). С момента появления механизма сжатия контекста, мне ни разу он не понадобился, с учётом большого количества решаемых задач с помощью LLM.
А когда сессия оборвалась в процессе работы над задачей нам в любом случае нужно какое-то саммари для продолжения работы в новой сессии.
Повторю, при атомарности задач и контроля их размера это не нужно. Ты просто повторяешь задачу и если надо, с чекаутом предыдущих изменений либо указанием предварительно проанализировать прогресс. Проблемы нет от слова совсем. И это так же может быть автоматизировано в выбранном флоу.
В чём необходимость пруфов не ясно.
Ну, вы сделали сомнительное заявление что фича была разработана именно для нужд вайб-кодеров, отсюда и необходимость пруфов - если бы для меня было важно для кого её разрабатывали, но мне не важно, так что пруфы можно опустить. Впрочем, если они у Вас есть - я бы с интересом почитал, чисто для самообразования.
Повторю, при атомарности задач и контроля их размера это не нужно
Идея что "маленькая" задача не потребует большого количества токенов - это иллюзия. Типичный пример: багфикс. Вроде баг мелкий, на первый взгляд. Но количество дополнительной работы в процессе фикса может в любой момент взорваться по токенам - потому что вылезет что-то не предусмотренное и пойдёт процесс отладки в процессе понять, что происходит и почему. Да, можно отловить необходимость этого процесса отладки и выделить его в отдельную подзадачу, но никаких гарантий что эта подзадача влезет в контекст у нас всё-равно нет.
Саммари в таких ситуациях позволяет получить обзор того, что уже было попробовано и не дало результата плюс идей которые запланировали попробовать но на которые не хватило предыдущей сессии.
Использование субагентов позволяет атомизировать подзадачи, и как следствие - повышать их качество выполнения за счёт маленьких, но гарантированно решаемых задач.
Давайте возьмём для примера самый типичный кейс: промпт пользователя просит добавить фичу (уже спроектированную, с описанием как именно её добавлять) либо починить баг (с описанием как он проявляется и как его воспроизвести). Для решения задачи модели нужно: проанализировать код, реализовать функционал, покрыть его тестами, прогнать форматирование/линтеры/тесты и исправить все проблемы. Обычно всё это делается одним промптом, результат в 95% случаев влезает в одну сессию. Как именно тут помогут субагенты? Это же традиционный цикл построить теорию → изменить код → прогнать тест → повторить пока не заработает, и для его качественного выполнения на следующих шагах нужно знать историю предыдущих шагов, а разделив его на несколько сессий субагентов мы эту историю… того.
Я уже молчу о том, что при использовании тарифных планов с оплатой за запросы, а не токены, вместо оплаты одного запроса (которого часто хватает на полное решение вышеупомянутых задач) будет дробление на субагенты и N запросов вместо 1.
Лично мне не известны рабочие способы решения этой проблемы: невозможно заранее предсказать сколько токенов потребуется модели для обработки запроса, и не превысит ли это количество оставшееся количество токенов в текущей сессии.
Лично мне известно несколько таких способов. Самый простой из них, когда ты просишь создать задачи на основе ресёрча бизнес-задачи, указать, что каждая задача не должна превышать например 2 или 3 или сколько ты хочешь (вычисляется эмпирическим путём) дней по оценки трудозатрат. Таким образом, задачи будут созданы с учётом этого и будут предсказуемы. Если вы не используете разделение задач контроль их размера - вы получаете проблему о которой сами же и сказали.
Проблема состоит лишь в том, что для конкретного проекта нужен свой подход в применении RAG.
Расскажите подробнее, о чём речь. Потому что, насколько я понимаю, консенсус на сегодня заключается в том, что работа с кодом требует чтобы модель видела код полностью, причём в его текущей версии, а не выдернутые из RAG кусочки, причём нередко не содержащие самых последних изменений сделанных секунды назад. Т.е. RAG остался для документов, но для кода от него практически отказались. Плюс размер контекста сильно вырос с тех времён, когда придумали RAG, так что никакой проблемы сегодня модели читать (полностью или кусками) реальные файлы с кодом уже нет. Сейчас в качестве RAG для кода экспериментируют с использованием AST для поиска всего нужного кода, этот подход хотя бы гарантирует что будут найдены абсолютно все нужные части кода и выданы цельными кусками (напр. функция целиком), причём используя текущий, актуальный вариант кода. Но и это пока на уровне экспериментов, и пока неясно, даст ли это что-то полезное в сравнении с прямым чтением файлов с кодом моделью.
Если для вас работа с кодом с помощью LLM это только написание промпта и ожидание результата - то это тот самый вайбкоддинг, от которого ожидать что-то кроме нейрослопа не следует.
Это чушь и передёргивание. Вайбкодингом оно станет только если сгенерированный код принимать без тщательного ревью. А с ревью это очень близко к обычному процессу парного программирования.
Расскажите подробнее, о чём речь. Потому что, насколько я понимаю, консенсус на сегодня заключается в том, что работа с кодом требует чтобы модель видела код полностью, причём в его текущей версии
Не следует в RAG хранить код. В RAG есть документация проекта. При этом, для корректной работы, документация должна быть соответствующе подготовлена. Таким образом, задавая контекст, какие то вещи будут взяты моделью из базы знаний. База знаний пополняется по мере работы над проектом и это должно входить в флоу работы с LLM. Например, предоставив модели тул с описанием, что тул предоставляет оглавления документации, позволит модели посмотреть оглавления и вызвать нужное если это потребуется.
Это чушь и передёргивание. Вайбкодингом оно станет только если сгенерированный код принимать без тщательного ревью. А с ревью это очень близко к обычному процессу парного программирования.
Ревью обязателен в любом случае. Однако ревью целого проекта или всей бизнес-задачи созданного одним промптом и ревью небольших итераций (в том числе по средствам самой LLM) это не одно и тоже.
Зачастую люди применяют второе, отсюда и разговоры, что LLM может гененировать только нейрослом.
Ревью целого проекта - это отдельный сложный проект, обычно называемый аудитом. Применять это в ежедневной разработке - нереально.
Отношение к ревью небольших итераций определяется исключительно тем, что в эту итерацию включить. Если только генерацию кода моделью - да, это будет нейрослоп, на ревью которого будет уходить неоправданно много усилий. Если генерацию кода, тестов, выполнение линтеров/тестов и исправление ошибок - то никакого нейрослопа не будет, будет совершенно обычное ревью типичного PR.
При этом нужно заметить, что второй вариант (с тестами) полностью подходит под Ваше определение:
Если для вас работа с кодом с помощью LLM это только написание промпта и ожидание результата - то это тот самый вайбкоддинг, от которого ожидать что-то кроме нейрослопа не следует.
что означает, что, как минимум, это определение неверно в текущей формулировке и требует дополнительных уточнений.
Не следует в RAG хранить код
Расскажите, зачем вообще нужен RAG в 2026 году? Получать ответ за одну итерацию инференса? Добивать промт от юзера релевантным мусором? Я просто хочу разобраться.. как это ПРАВИЛЬНО готовить? Поверх серч резалтов выполнять саммаризацию, как это делает гугл? Но компилятору требуется точный ответ, а не отписка... Какой профит с этого? Наличие полученной по неизвестным для модели правилам RAG-выдачи в контексте как-то побуждает её серьезнее относиться к задаче, она будет меньше сочинять и выдумывать? Где эта ниша, где RAG -- непоколебимый король?
Я бы не давал полный доступ ИИшке к шеллу. Вместо этого создал бы обёртку над bash. В этой обёртке есть разрешенные команды-алиасы. На некоторые требуется подтверждение, на некоторые - нет. Это и будет набором инструментов, только которые интуитивно понятны системе. Если ИИ пытается выполнить `cat largefile.txt` - выдаётся ошибка "файл слишком большой. Укажите диапазон в формате старт:стоп", или что-то подобное. Команд для записи просто не должно быть - всё через патчи. На npm/TS/RS/PHP/docker/yarn и т.д. будут "прозрачные" алиасы без подтверждений. Или с подтверждением. На остальные команды писать "permission denied" или "unsupported in this project"
Получится как middleware для шелла. Полная изоляция, абсолютно интуитивное управление. Можно будет сколько угодно инструментов впихнуть. Попробуйте :)
Все верно! Именно так и сделано 👍
Не совсем)) Вы же говорите, что ИИ читает текст через cat вместо вашего инструмента. Так что мешает подменить реализацию самого cat? Просто сделайте его своим инструментом) тогда даже инструкций для ИИ не нужно будет писать
Так же можно сделать и с остальными командами. Запретить ей писать в файлы в обход патчей на уровне middleware шелла - и все проблемы, описанные в статье, решатся (на мой взгляд)
прямо запрет не работает, увы. точнее он работает в начале, когда контекста мало, пока модель еще не потупела, а когда контекста уже становится заметно, она быстро сдается встретив такие жесткие рамки - и либо крутит по кругу попытки обойти ограничения пока не упрется в лимит вызовов, либо просто начинает текстом объяснять вместо того чтобы делать
такое же можно наблюдать и у зрелых агентов, только вчера наблюдал как Claude Code на Opus 4.6 пытался менять файлы через sed -i.
Вы не понимаете)) запрет на уровне шелла. Я предлагаю вам написать свой шелл
так модель будет всегда идти в обход чего-то кастомного в пользу того что она умеет, а она намного лучше умеет использовать существующие команды типа "cat/head/sed/grep/find/rg/python" чем то что вы опишите в промпте или будете лимитировать ограничениями своего шелла
если делать более умную обертку - модель вообще сойдет сума, потому что она будет ждать ожидаемый результат от shell команд - а получая кастомный результат, будет действовать на ошибочных выводах - привет бесконечный цикл ошибок и попыток
Так я говорю: создайте свой cat. У него будет идентичное название и идентичный способ использования. Когда ИИ будет вызывать "bash -c cat filename.txt", он на самом деле будет вызывать не встроенный cat, а вашу реализацию. И теперь смотрите, какая магия. Если файл превышает заданное ограничение на размер, команда, которая выглядит и вызывается точно так же, как падает с вашей кастомный ошибкой: "file too large. Please use 'cat filename.txt START:END'". То есть код ошибки сразу же подсказывает ИИшке правильное использование команды. Второй пример: ИИ пытается использовать sed. Но для sed у вас своя реализация, который на любой вызов говорит: "sed is not supported. Please use git patch". ИИ сразу вспоминает, что нужно использовать. А для docker/npm/etc. так же будет своя реализация, которая просто является алиасом: она перехватывает все аргументы, переданные ИИ, и вызывает реальную команду. Таким образом, у вас будет собственный клиентский шелл для ИИ, изменяющий поведение УЖЕ СУЩЕСТВУЮЩИХ команд, с ПОЧТИ ИДЕНТИЧНЫМ API. Вот что я имел ввиду. Если нужны подробности, предлагаю перейти в ЛС, а то эта ветка совсем разбухнет))
Есть проекты которые запускают агенты в отдельном докер контейнере.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Что можно понять, только написав своего агента для кодинга