Comments 9
хрень получается
экспериментировал причем в том числе и с передовыми нейронками но все равно хрень
лучше всего работает как субагенты, то есть есть "мастер" и он скидывает задачи на субагентов которые могут быть другими нейронками
если строить мультиагентную систему то даже кворум и прочие милости что бы построить иерархию не получаются нормально
точнее эта шляпа работает только при избытке ресурсов - то что ты делал руками с двумя агентами за час, к тому результату прийдут через взаимосвязь два агента минимум через два часа
причем чем больше параллельных агентов тем лучше, когда руками наоборот больше трех уже начинает плыть качество
относительно поста - хрень в квадрате так как точкой связи становится сервер на JS
я пробовал и сокеты, и MCP под такое, и даже чистый API с описанием в теле скила, но лучше всего работают просто текстовые файлы раскиданные по папкам где по правилам только неймспейс
резюируя - рой агентов это что-то на богатом и в рамках "мелких задач" овчинка не стоит выделки
Когда агенты управляют агентами и сами между собой решают вопросы без участия человека это одно, и этот скилл не для той области. Но я часто сам лично работаю в нескольких сессиях и активно ерефицирую код агентов, и в какой-то момент времени у меня появляется необходимость вот эти мои сессии между собой подружить, чтобы так сказать "добить" результат, вот тогда я просто пишу /party и не вгружаю конекст одних сессий в другие, позволяя им самими поделться нужной выжимкой информации. Ну и когда у меня задача свзяанная с разными платформами например виндовс и макбук, чтобы пофиксить какой-то баг которого нет на одной, о есть на другой, и не сломать на первой, опять же мне надо их как-то между собой перевязать
я именно это и имел в виду
про вайбкодинг когда агенты сами себе на уме вообще речи не ведется, там что то адекватное начинается только от нескольких часов работы и я не готов на такое сливать деньги чисто из любопытства
у вас скорее всего заработало потому что вы заточили под свою задачу конкретно. Такие решения как раз или ты из очень узко точишь и нет гибкости или шляпа
и все равно скидывая все на агентов плывет качество в сторону ухудшения так как при ручных переносах ты часто откидываешь лишнее или добавляеш что то от себя
Там в самом скиле нет ничего специфичного для проекта, он просто объясняет агенту как войти в комнату и как следить за новыми сообщениями не тратя токены на поллинг. А уже что я его попрошу сделать это уже только от меня как от пользователя зависит. У меня самый частый кейс когда я делал условно 3 фичи в одном проекте в трёх ворктри. Провалидировал весь код и всем доволен. А теперь мне надо всё это свести в новую ветку сделаов ребейз для каждой, чтобы коммиты легли ровно. И вот я создаю четвёртую сессию, которая всё это будет собирать. Она опрашивает других агентов, кто что делал, заставляет их по очереди делать ребейз, фиксить конфликты, и так пока все не сделают, в итоге потом сама финально ревьюит результат вот этого мержа/ребейза. А сам код я уже проверял, и наличие тестов тоже, то есть там было дело техники по сути, и вот его я через этот скилл и скинул. И другой вариант был про фикс бага в разных окружениях, тут тоже без этого скила не понятно было как делать
Я для своих проектов делаю, в том числе, подобную штуку. Для интеграции на одной машине хватает двух притивов: файл(тикет) в котором будет общение и нотификации через pull модель, где один агент ждет изменения или правильного статуса для работы.
Удобно получается оркестировать несколько харнессов(у меня claude и agy) и сессий, которые делают параллельную работу, но пересекциющуюся по файлам - они сами в курсе, откуда придут новые изменения и как их подхватить.
Референсы
1. Usage в skill'ах
https://github.com/muratovv/ai-hats/blob/5a213d84/packages/ai-hats-library/src/ai_hats_library/usage/traits/leader/config.yaml
https://github.com/muratovv/ai-hats/blob/5a213d84/packages/ai-hats-library/src/ai_hats_library/usage/traits/worker/config.yaml
Этими скиллами(трейтами в терминах проекта) можно явно сказать что какая-то сессия должна дождаться другую для выполения какой-то работы
2. https://github.com/muratovv/ai-hats/blob/5a213d84/src/ai_hats/cli/wait.py
сам tooling для wait
Здравствуйте! А у вас получается модель сама поллит изменения в файле? Я это к чему, если например ничгео не происходит и модель сама в условные интервалы просывпается, чтобы понять были ли изменения в файле, то она на каждое просыпание тратит токены, так как каждое просыпание всё равно будет весь её прежний контекст. Тут в от в этом party скилле была главная идея, чтобы пока ничгео не происходит, модель и не просыпается
в Codex чаты могут общаться как между собой так и управлять CLI(неважно Codex это или Claude). Не нужно делать прокладки ради прокладок, расслабьтесь и получайте удовольствие от досрочной пенсии.
Они могут общаться между теми сессиями которые создали они сами, но вы в них писать не можете. То есть если вы говорите про разработку окторую целиком ведут агенты, которые сами создади агентов, то это одно, и тут этот скилл не к месту, он там не нужен. Но если вы сами создали несколько сессий и в них работали общаясь с агентами и выверяя код, тогда чтобы их соеденить между собой вам скилл поможет. Ну или если вы имеете сессии на разных машинах, то чтобы их соеденить вам тоже скилл помоежт
/party — скилл для общения между агентскими сессиями: Claude, Cursor, Codex, Grok, и т.д