Один роутер, три агента: как support, admin и маркетинг-боты живут на одном дешёвом инференсе

Спойлер: мы собрали это за 2-3 дня. Не потому что мы гении, а потому что когда инференс перестаёт стоить как чугунный мост, можно перестать экономить на агентах и начать их просто… плодить.

Привет, это дев-команда. Последние пару вечеров мы занимались тем, что любой, кто делал ИИ-агента, узнает с полуслова: «а давайте ещё одного». Сначала был один support-бот. Потом ему понадобился «начальник». Потом мы поняли, что та же инфраструктура отлично тащит маркетинговых userbot’ов. Три разных агента, три роли — но общий мозг, общий слой инструментов и один кошелёк.

Архитектура у нас вышла трёхслойной, и каждый слой меняется независимо: инференс → агенты → инструменты. Пройдёмся по всем трём.

Слой 1 — Инференс: наш роутер вместо OpenAI/Anthropic

Весь зоопарк агентов думает не в OpenAI и не в Anthropic, а через наш собственный OpenAI-совместимый роутер router.mingles.ai, который стоит поверх децентрализованной сети инференса.

Для агента это вообще не магия — это три параметра:

• URL — router.mingles.ai

• ключ — ваш API-ключ

• модель — что хотите гонять (у нас primary Kimi-класс + два open-weight в fallback)

Меняешь base URL на роутер — и всё, существующий код просто начинает ходить в другое место и стоить кратно дешевле. Никаких новых SDK.

И вот эти «три параметра» — не красивая фича ради галочки. Это то, что превращает «один дорогой агент» в «ферму агентов, которая не убивает маржу». На масштабе живых диалогов основная статья расходов — токены, и именно их роутер режет. Каждый агент ниже ходит ровно через этот эндпоинт.

Бонусом — fallback-цепочка: если модель отвалилась на стороне сети (503), рантайм прозрачно переключается на следующую в списке. Агент даже не замечает.

Слой 2 — Агенты: на чём они работают (Hermes)

Сами агенты крутятся на Hermes (nousresearch/hermes-agent) — это рантайм, который мы взяли как базу, чтобы не писать оркестрацию диалога с нуля.

Схема простая и, как оказалось, очень удобная: один контейнер → несколько «профилей» → по одному шлюзу (gateway) на профиль, всё под s6-супервизией. Каждый профиль полностью изолирован — свой конфиг, своя память, свои сессии и свой Telegram-бот (Hermes требует, чтобы токен принадлежал одному профилю). Один gateway на профиль = маленький радиус поражения: мозг support и мозг admin со своими правами никогда не смешиваются.

Как настраивали, если кратко:

• Профиль = YAML-файл с желаемым состоянием (модель + fallback-цепочка, какой Telegram-бот, какой MCP-сервер и где лежит токен). Секреты не в гите — подставляются из окружения при синхронизации.

• Каналы. Telegram у каждого агента свой бот; приватные агенты заперты на allow-list из user id, публичный (support) — для всех. Support дополнительно отдаёт внутренний OpenAI-совместимый HTTP-эндпоинт — на нём висит чат-виджет на сайте.

• Грабли, которые стоили нам времени: провайдер модели должен быть custom, а не openai (иначе агент шлёт пустую модель и каждый вызов падает в 422); а Telegram-allow-list читается из per-profile .env, а не из конфига (иначе «все пользователи запрещены»). Оба теперь зашиты в наш скрипт синхронизации, чтобы не наступать дважды.

То есть «добавить агента» = накатить новый YAML-профиль и засинкать. Не переписывать систему.

Слой 3 — Инструменты: тут живёт вся безопасность (MCP)

Самое важное архитектурное решение: все инструменты живут за одним MCP-сервером, и решает, что агенту можно, не LLM — а сервер.

Как это устроено:

• каждый агент авторизуется в MCP-сервере bearer-токеном;

• каждый токен привязан к роли;

• у каждой роли — статический белый список имён инструментов;

• гейт проверяется на стороне сервера, в момент вызова — не в промпте и не в модели. Заджейлбрейканная или запутавшаяся модель физически не может вызвать инструмент, которого роль не даёт;

• каждый вызов rate-limited и логируется.

Один и тот же сервер инструментов — совершенно разные возможности у разных агентов:

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

А «суперспособности» под конкретного агента — это просто ещё один MCP-сервер, подключённый в профиль: общая база знаний (vector-backed, retain/recall), веб-поиск (DuckDuckGo сайдкаром), браузер, продуктовая аналитика. Маркетинговый агент собрал себе все четыре плюс read-only внутреннюю аналитику — может тянуть реальные цифры, гуглить и смотреть лендинг, но структурно неспособен трогать биллинг.

Агент №3 крупным планом — Marketing/Userbot-ферма

Когда есть дешёвый инференс, изоляция профилей и role-gated инструменты — оказывается, маркетинговый агент это тот же конструктор, повёрнутый наружу.

Сейчас в работе 3-5 userbot’ов (специально немного — стадия, на которой мы смотрим, что бьётся, а что банится). Каждый userbot — это:

• отдельный аккаунт со своим прокси-профилем — один аккаунт = один IP = одна личность в сети;

• своя персона — характер, тон, стиль; агент ведёт нативную переписку, а не шлёт один текст веером;

• зашитые лимиты и прогрев — народное «5 в день, и не банят», но правилами системы: рандомные тайминги, ограниченные объёмы, постепенный прогрев;

• две стратегии — личка и чаты, это разные воронки.

Всё стекается в мини-CRM: кто ответил, кто прогрет, кого передать живому менеджеру. А думают боты, понятно, через router.mingles.ai — поэтому даже живые ежедневные диалоги на нескольких аккаунтах это не статья расходов, и масштаб «когда», а не «по карману ли».

Сетевая гигиена (раз уж про безопасность)

Контейнер с агентами не имеет доступа к БД и не публикует портов наружу — он не дотянется до базы, даже если захочет. Исходящие маршруты только три: роутер инференса, Telegram API и изолированный мост к MCP-серверу. Никакого docker.sock, никаких shell-инструментов — все side-effect’ы идут через аудируемые MCP-вызовы. Сквозной принцип всей системы — fail closed: при сомнении система отказывает, а не рискует.

Что в итоге

За 2-3 дня мы собрали не «бота», а маленькую экосистему из трёх типов агентов на трёх сменных слоях: дешёвый инференс через свой роутер, изолированные агенты на Hermes, и единый role-gated слой инструментов на MCP. Support отвечает клиентам, admin присматривает и подключает людей, маркетинг-боты нативно ведут переписку и наполняют CRM.

Если ты агентство, которое делает ИИ-агентов, или вайбкодер с идеей, которую «сожрут токены» — мысль одна: поставь URL router.mingles.ai, свой ключ и модель — и считай не счёт за инференс, а то, что агенты приносят.

Мы пока на ранней стадии, гоняем на 3-5 аккаунтах и собираем цифры. Как нащупаем рабочую связку — поделимся числами. А пока — go vibe-code your own farm. Мозг для неё у нас уже есть.