Попробовал организовать работу через мультиагентов. Такая шляпа получилась ?
На бумаге идея выглядит отлично. Целый штат специалистов: архитектор, разработчик, QA, девопс. Один ставит задачу другому, все специализируются, работают параллельно и во благо общей цели.
В реальности довольно быстро выяснилось, что я зачем-то добровольно тащу в работу с LLM весь налог на распределённые системы.
Агент "А" передал задачу агенту "Б", тот спросил "В". "В" вернул что-то правдоподобное, "Б" добавил свою интерпретацию, "А" получил результат уже как будто проверенный факт.
Тут чей косяк?
А если девопс-агент не ответил после команды на релиз, нужно повторить запрос? А если первая команда на самом деле ещё выполняется? А если два агента одновременно полезли менять один ресурс?
Здравствуйте, идемпотентность, трассировка, владельцы задач и прочие термины, которые я вообще не планировал вспоминать, когда хотел просто несколько умных помощников на проектах.
С правами ещё веселее. Допустим, агент-разработчик не имеет доступа к проду. Отлично.
Но если он может попросить инфраструктурного агента выполнить там произвольную команду, то формально доступа к проду у него нет, а фактически — вполне себе есть ?
Значит, мало раздать агентам разные SSH-ключи. Нужно ещё продумывать, какие действия вообще можно вызывать через других агентов, кто кому что имеет право делегировать и кто в итоге отвечает за исходную задачу.
В какой-то момент я задумался: а зачем я вообще строю микросервисы из LLM?
Проблемой оказались не несколько агентов сами по себе. Проблемой оказалась идея свободно общающейся "ИИ-команды", где одна работа искусственно нарезана между зоопарком виртуальных коллег.
В такой схеме сложность растёт гораздо быстрее, чем польза.
Но.
Есть сценарии, где общение агентов выглядит совсем иначе. Бывает, что граница между агентами придумана не искусственно, а уже существует в реальности.
Недавно рассказывал про переделку легаси-проекта с интеграцией с 1С.
Там на проекте работало сразу два агента.
Первый — внутри контура заказчика. Он имел доступ к Windows-серверу, 1С, iis-у, их журналам и т.д. Второй работал на стороне разрабатываемого приложения. Кодовая база и старая интеграция, новая реализация и общая логика проекта.
Связь между ними обеспечивал я, ручками.
Спрашиваем первого:
«Что реально крутится на сервере? Какая версия? Куда ходит обмен? Что видно в логах?»
Получаем ответ и несем во вторую сессию:
«Вот что выяснилось на стороне заказчика. Теперь проверь реализацию с учётом этого».
Две картины системы не сошлись.
На одной стороне выходило, что обмен должен происходить четыре раза в день. На другой — никаких следов такого поведения.
Если бы агент видел только одну половину системы, он вполне мог бы взять за истину первую правдоподобную версию.
А тут пришлось сверять обе стороны, искать реальные точки входа, смотреть логи и докапываться до того, как интеграция работает на самом деле.
В этом кейсе связь между агентами уже выглядит гораздо интереснее.
Агент проекта спрашивает у агента заказчика о конкретном факте, получает ответ и продолжает работу, не получая доступ к чужой инфраструктуре.
Агент 1С знает свой контур и контракт интеграции, но ему совершенно незачем видеть весь остальной проект.
Для себя пока сформулировал так:
Не надо дробить одну работу на пять агентов просто потому, что у Гермеса появилась такая фича в последнем релизе.
Мультиагенты становятся оправданными только там, где уже существуют реальные границы систем, контекста, владельцев и доступа.
Вот это нам надо.