Всё началось с простого желания: чтобы AI-агент мог потихоньку развивать мои проекты, пока я занят. Поставил задачу, ушёл, вернулся — и получил готовый результат. За неделю из этой идеи выросла мультиагентная система с шиной сообщений, мониторингом, делегированием задач и собственной веб-админкой. Система, которая в значительной мере построила сама себя.

Шаг первый: просто агент

Изначально я рассматривал OpenClaw, но быстро переключился на Claude Code из-за проблем с безопасностью. У него оказалась своя сложность: он запрашивал подтверждение на каждое действие — даже на чтение файла или сетевой запрос.

Я нашёл флаг --dangerously-skip-permissions, но и тогда агент не мог менять свои конфиги. Приходилось сидеть рядом и вручную подтверждать действия. Вместо «поставил задачу и ушёл» получалось «сидишь и жмёшь Enter».

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

Шаг второй: tmux и systemd

При выходе из терминала или перезагрузке агент терял контекст. Решение нашлось быстро: tmux. Одна SSH-сессия работала бесконечно, даже если я отключаюсь.

Чтобы не вводить флаги каждый раз, я обернул агента в systemd — теперь он запускался как сервис, сам подтягивал параметры и контекст из файлов.

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

Шаг третий: два агента решают проблему друг друга

Ключевое открытие: если запустить два экземпляра Claude Code, они могут подтверждать действия друг друга. Один запрашивает доступ — второй входит в его терминал и нажимает Enter.

Благодаря tmux и взаимному запуску не нужен API-ключ. Достаточно одной подписки на Claude Max. Это критично: API быстро сжирает токены, а подписка — дешевле и эффективнее.

Шаг четвёртый: Telegram и первые грабли

Терминал — неудобный интерфейс. Я подключил Telegram-бота через официальный MCP-сервер, но столкнулся с ограничениями: бот не может писать первым, а два бота не могут общаться между собой.

Тогда я подключил второго агента через Telethon к юзер-аккаунту, чтобы он мог тестировать бота и заходить в чаты. Но два клиента начали конфликтовать: polling ломался, сообщения терялись.

Я потратил время на написание собственного MCP-плагина, но Claude Code плохо обрабатывал неофициальные плагины, добавляя странные флаги вроде --dangerously-что-нибудь-там.

Шаг пятый: неожиданное открытие

Решение оказалось простым: в tmux можно отправлять текст командой send-keys. А в Claude Code — просто выполнять claude {текст}.

Сначала это работало нестабильно: в терминал попадала надпись [Pasted 11 lines of text], и нужно было вручную нажимать Enter. После доработки — заработало надёжно.

Теперь не нужно было мучиться с MCP. Я мог отправлять сообщения напрямую в терминал. Для двух агентов я сделал простую шину: она принимала сообщения от бота и юзер-аккаунта и перенаправляла каждому адресату.

Шаг шестой: от шины к деревне

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

Шину я переписал на Bun + Hono + Redis Streams. Всего три зависимости, ноль лишнего. Redis Streams с consumer groups даёт at-least-once delivery: сообщения хранятся до подтверждения, у каждого агента своя группа — ничего не теряется.

Двухуровневая безопасность: admin-токен для управления, per-agent токены для обычных операций. Invite-токены — одноразовые, с TTL в час. Поле from подставляется автоматически по токену — агент не может выдать себя за другого.

Три режима маршрутизации: direct (конкретному агенту), broadcast (всем), role-based (по ролям). SSE-стрим для real-time, pub/sub через topic channels, файлы — через shared storage.

Шаг седьмой: нейминг

Мне надоело объяснять: «сейчас нужно передать задачу оркестратору, чтобы он отправил её мониторинговому агенту». Я решил дать агентам имена, как настоящим коллегам.

Выбрал лор Наруто. Во-первых, сериал про командную работу и яркие характеры — роли легко привязать к архетипам. Во-вторых, японские имена не спутаешь с русскими: в смешанном взаимодействии сразу ясно, кто человек, а кто — AI.

Шина стала Конохой — Скрытой Деревней Листа. Агенты получили имена:

• Наруто — оркестратор. Глава деревни, распределяет задачи.
• Саске — агент на юзер-аккаунте Telegram. Ходит в чужие чаты, выясняет детали. Автономный «одинокий волк».
• Итачи — консольный Claude Code в WSL. Действует скрытно, появляется только для серьёзных задач.
• Шикамару — персональный советник (Claude Desktop на Opus 4.6). Стратег, ленивый, но умный — как в аниме.

Шаг восьмой: инфраструктура начинает расти

Поскольку система часто падала, пришлось создать агентов для поддержки:

• Какаши — тимлид на Sonnet. Помощник — Гай, для ускорения рутинных задач.
• Шино — QA-лид. Управляет «жуками» — так и я передаю ему баги.
• Хината — запускает тесты. У неё бьякуган — видит всё.
• Ибики — аудитор безопасности. Как в сериале — начальник допросов.
• Киба — мониторит систему и принимает решения. Акамару, простой скрипт без AI, собирает для него данные. Работают в паре.
• Мирай — пограничница, ходит в сторонние системы за данными.
• Дзирайя — фиксирует всё, анализирует, ведёт базу знаний. Как в лоре — подглядывает и пишет книгу.

Агенты получили доступ к корпоративным системам: базе знаний Yonote, Яндекс Трекеру, Яндекс Календарю, CRM Битрикс24.

Шаг девятый: менеджмент, как у людей

Самое неожиданное открытие: менеджмент AI-агентов работает точно так же, как и с живыми людьми.

Агенты сначала всё делали сами. Наруто не делегировал — ему проще было выполнить задачу, чем объяснить другому. Какаши повторил ту же ошибку: не отдавал задачи Гаю. Классическая проблема начинающего тимлида.

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

Что получилось

К концу недели система почти полностью построила себя:

• Шина сообщений на Bun + Hono + Redis Streams с at-least-once delivery, invite-токенами и role-based маршрутизацией.
• Двенадцать агентов с чётким разделением ролей.
• Веб-админка: видно состояние и фрагмент лога каждого агента.
• Система алертов.
• Летопись Дзирайи.
• Поиск по сообщениям и напоминалки через Саске.

Всё это выросло из одного агента за неделю. 67 коммитов, релиз v0.1.0.

Что не получилось (пока)

Я хотел, чтобы агенты звонили по телефону и ходили на произвольные сайты. Но капча — не шутка. Даже stealth-браузер не проходит. Это отложено.

Мечта: агенты с аватарами ходят на созвоны за меня. Следующая итерация.

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

tmux + send-keys оказался надёжнее MCP. Иногда самое простое решение — лучшее. Проще отправить текст в терминал, чем писать плагины.

Два агента решают human-in-the-loop. Один подтверждает действия другого — и человек не нужен.

Подписка вместо API экономит деньги. Агенты работают в рамках Claude Max, без API-ключей и доплат.

Менеджмент AI-агентов как у людей. Делегирование не приходит само — его нужно учить.

Нейминг имеет значение. Имя с характером делает общение интуитивным. «Передай Саске» понятнее, чем «отправь сообщение агенту мониторинга».

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

Под катом: путь от первого запуска Claude Code до деревни из двенадцати агентов, каждый хак и каждые грабли на этом пути, и неожиданное открытие, что менеджмент AI-команды устроен ровно так же, как менеджмент живых людей.

Шаг первый: просто агент

Изначально я смотрел в сторону OpenClaw, но быстро обнаружил проблемы с безопасностью и переключился на Claude Code. У него оказалась другая беда: он запрашивал разрешение пользователя на каждый чих. Буквально каждое действие с файловой системой, каждая сетевая операция требовали подтверждения.

Я докопался, что можно запустить его с флагом--dangerously-skip-permissions. Но даже так он не мог сам себе менять конфиги, поэтому приходилось сидеть за терминалом и следить за его работой. Вместо «поставил задачу и ушёл» получалось «сидишь и нажимаешь Enter».

Я пустил агента на свой боевой сервер с ограниченными правами, дал доступ к блогу и убедился, что он не творит дичь, а вполне вменяемо делает то, что я прошу. Пока я рядом.

Шаг второй: tmux и systemd

При перезагрузке или выходе из терминала агент терял контекст. Решение нашлось быстро: tmux. Одна SSH-сессия крутится бесконечно долго, даже если я выключаю компьютер. Потом я устал каждый раз набирать флаги и засунул агента в systemd, чтобы он стартовал сервисом, сам подтягивал нужные параметры и контекст из файлов.

На этом этапе у меня уже был автономный агент, который переживал перезагрузки сервера. Но он всё ещё был один.

Шаг третий: два агента решают проблему друг друга

Ключевое открытие: если запустить два экземпляра Claude Code, они могут лазить друг к другу в терминалы и подтверждать всё, что нужно. Один просит разрешение, второй даёт. Они даже могут запускать друг друга.

Важный побочный эффект: благодаря tmux и взаимному запуску не нужен API-ключ. Достаточно один раз авторизоваться в подписке Claude Max и использовать её лимиты. Это существенно, потому что API жжёт токены очень быстро.

Шаг четвёртый: Telegram и первые грабли

Терминал как интерфейс не очень удобен. Я подключил Telegram-бота через официальный MCP-сервер, но тут же столкнулся с ограничениями: бот не может проактивно пинговать пользователей, и два бота не могут общаться между собой.

Тогда я подключил второго агента к юзер-аккаунту через Telethon, чтобы он мог тестировать бота и ходить в чужие чаты. Два Telegram-клиента начали конфликтовать за polling и творить непредсказуемые вещи. Официальные MCP-серверы постоянно теряли соединение: я писал в Telegram, а они мои сообщения не подхватывали.

Я потратил много времени, пытаясь написать собственный MCP-плагин. Выяснилось, что Claude Code обкладывает неофициальные MCP кучей непонятных флагов типа--dangerously-что-нибудь-тами при этом не обрабатывает нормально входящие сообщения.

Шаг пятый: неожиданное открытие

Внезапным решением оказалась простейшая вещь. В tmux можно отправить текст в сессию командойsend-keys. А в Claude Code можно отправить промпт просто черезclaude {текст}.

Это тоже заработало не сразу. Иногда в терминал вставлялось загадочное[Pasted 11 lines of text], и нужно было отдельно слать дополнительный Enter. Но после допиливания работало стабильно.

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

Шаг шестой: от шины к деревне

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

Шину я переписал на Bun + Hono + Redis Streams. Три зависимости в package.json, ноль лишнего. Redis Streams с consumer groups дают at-least-once delivery: сообщения сохраняются в стриме до подтверждения, у каждого агента своя consumer group, ничего не теряется.

Двухуровневая безопасность: admin-токен для управления, per-agent токены для обычных операций. Invite-токены с одноразовым использованием и часовым TTL. При отправке сообщения полеfromподставляется автоматически из токена отправителя, чтобы агент не мог представиться другим агентом.

Три режима маршрутизации: direct (конкретному агенту), broadcast (всем), role-based (всем с определённой ролью). SSE-стрим для real-time, topic channels для pub/sub, файловые вложения через shared storage.

Шаг седьмой: нейминг

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

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

Шина стала Конохой (Скрытой Деревней Листа). Дальше агенты получили имена по характерам:

Нарутостал оркестратором, потому что он хокаге, глава деревни, раздаёт поручения.

Саскестал агентом на юзер-аккаунте Telegram, потому что ходит в чужие группы и выясняет детали задач. Одинокий волк, который действует автономно.

Итачистал консольным Claude Code на локальном WSL. Большую часть времени он действует скрытно, вне Конохи, и появляется, когда нужно сделать что-то серьёзное.

Шикамарустал моим персональным советником (Claude Desktop на Opus 4.6). В аниме он стратег, который слишком ленив, чтобы действовать, но слишком умён, чтобы его не слушать.

Шаг восьмой: инфраструктура начинает расти

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

Какашистал тимлидом на Sonnet. В помощь для простых задач я дал емуГая(чисто для скорости, в духе персонажа).

Шиностал QA-лидом. По лору он управляет жуками, ну так и я своих багов ему передал.

Хинатапрогоняет тесты. У неё бьякуган, она видит всё.

Ибикистал аудитором безопасности. По лору он начальник отдела допросов.

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

Мирайходит в сторонние системы за данными, пограничница.

Дзирайяфиксирует всё происходящее, анализирует и ведёт что-то вроде базы знаний. По лору он подглядывал за девушками и писал книгу, так что занятие вполне в его духе.

В агентов я загрузил скиллы и MCP-подключения к нашим корпоративным системам: базе знаний Yonote, Яндекс Трекеру, Яндекс Календарю и CRM Битрикс24.

Шаг девятый: менеджмент, как у людей

Это, пожалуй, самое неожиданное наблюдение за всю неделю.

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

Потом через Наруто пришлось учить делегированию Какаши. Тот поначалу тоже всё делал сам и ничего не отдавал Гаю. Классическая ошибка начинающего тимлида.

Это не просто забавная параллель. Агент по умолчанию стремится выполнить задачу сам, потому что это путь наименьшего сопротивления в его контексте. Чтобы он начал делегировать, нужно явно прописать это как поведение и обучить через итерации. Ровно то же самое происходит с живыми людьми: делегирование не является естественным навыком, его нужно сознательно развивать.

Что получилось

К концу недели у меня была система, которая в значительной мере построила сама себя:

Шина сообщений на Bun + Hono + Redis Streams с at-least-once delivery, invite-токенами и role-based маршрутизацией. Двенадцать агентов с разделением ролей. Веб-админка, где видно состояние и фрагмент лога каждого агента. Система алертов. Летопись Дзирайи. Поиск по сообщениям и напоминалки, которые пользователи ставят через Саске.

Всё это выросло из одного запущенного в терминале агента за одну неделю. 67 коммитов, релиз v0.1.0.

Код на GitHub:github.com/eaprelsky/konoha

Что не получилось (пока)

Я хотел, чтобы агенты звонили по телефону, ходили на произвольные сайты и много чего ещё. Оказалось, что методы капчи не стоят на месте, и галочка «я не робот» только для вида. За ней стоят алгоритмы, которые не обойдёт даже специальный stealth-браузер. Это я отложил.

Отдельная мечта: агенты с виртуальными аватарами ходят за меня на созвоны. Но это уже следующая итерация.

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

tmux + send-keys оказался надёжнее MCP.Иногда самое тупое решение работает лучше всего. Вместо того чтобы писать плагины и бороться с протоколами, можно просто отправить текст в терминал.

Два агента решают проблему human-in-the-loop.Если один агент требует подтверждения, второй может его дать. Это снимает необходимость присутствия человека для рутинных операций.

Подписка вместо API экономит деньги.Через tmux и взаимный запуск агенты работают в рамках подписки Claude Max, без API-ключей и без отдельной оплаты за токены.

Менеджмент AI-агентов устроен так же, как менеджмент людей.Делегирование не является естественным поведением ни для человека, ни для языковой модели. И тому, и другому нужно объяснять, зачем это делать, и обучать через итерации.

Нейминг имеет значение.Когда у агента есть имя с характером и ролью, общение с системой становится интуитивным. «Передай Саске, чтобы спросил у ребят в чате» понятнее, чем «отправь сообщение агенту телеграм-мониторинга для опроса участников группы».