Будущее кодинговых агентов Моя римская империя в последнее время – это рекурсивные языковые модели и то, какой потенциал они скрывают для кодинговых агентов. Уже прошло два месяца с момента выхода пейпера, а его авторы вместе с авторами DSPy всё никак не могут донести этот потенциал до масс. На мой взгляд они слишком много напирают на юзкейсы связанные с делёжкой контекста. Попробую-ка я зайти с другой стороны. Для начала что такое RLM: это агент, которому дают тул с REPL какого-то языка программирования. Казалось бы, сейчас любой кодинговый агент может и любит гонять скриптики на питоне по любому поводу. В чём новизна? Дьявол в деталях – в рантайме этого REPL должны быть три сущности – переменная с текстом промпта, функция вывода результата пользователю и... фукнция вызова субагента с заданым аргументом-промптом. Угадайте что есть у этого агента? Тот же тул с REPL! Вот где рекурсия! И это то, что их пейпер не может обьяснить нормально из-за баззвордов про символьные вычисления в токен-пространстве. А теперь какой в этом смысл? Разве нет ли сейчас в каждом агенте возможность вызова субагентов? 😑 (даже в курсор завезли их уже!). Любой агент уже может разбить задачу на подзадачи и раздать их субагентам. Прикол в том, что вызов субагента – это тулколл. И мы должны обьяснять агенту как вызывать задачи, что вызывать параллельно, что последовательно, как ретраить. И потом надеяться что он вызовет их правильно, согласно плану и не забудет спустя 20 субагентских вызовов вызвать ревью. Учитывая что каждая проблема требует немного своего подхода, вынося это в промты мы получим ни-рыба-ни-мясо подход типа современного SDD или ральфа. Достаточно абстрактный, чтобы решить любую задачу неоптимальным способом. А теперь представьте, что план выполнения задачи – это код на питоне: while (reviewSubagent.check() != "DONE"): val task = plannerSubagent.pick() TaskSubagent().run(task) Пожалуйста – и не надо никаких плагинов для ralph loop 😎! И мы можем попросить модель, например, работать по TDD, или закодировать задачи как граф и обходить его по BFS. И всё это будет работать и на лету менять алгоритм оркестрации, адаптируя его под задачу. Я вообще представляю легковесную модель-оркестратор, имеющую только возможность строить workflow других моделей. Если взять небольшую модель и дофайнтюнить на это, она может хорошо справляться. Второе следствие наличия REPL – оркестратору не надо читать вывод субагентов. Это же возвращаемое значение функции! Можно это схоронить в переменную, можно сразу передать, например, ревью субагенту. А можно вообще субагенту дать в замыкании список задач и он может, выполнив свою задачу, закинуть обратно в список follow-up задачки на доделку. По моему мнению – это будущее агентской архитектуры. Для кодинга точно, но, возможно, и для всего остального. Я хотел бы попробовать собрать PoC на основе легковесного агента https://shittycodingagent.ai. Но у меня всегда проблемы с тем чтобы доводить свои идеи до воплощения на практике, поэтому тут я попрошу помощь у вас, любимые подписчики ❤️. Если кого-то заинтересовало – пишите в комменты, давайте попробуем это сделать вместе, ведь так веселее!