Как я перестал быть прокладкой между ИИ-агентами: ИТ-суперагент для Claude Code сотрудников

Сейчас у нас, как и почти везде, идёт переход на ИИ: каждому сотруднику пытаются выдать своего ИИ-агента. Очень быстро выяснилось, что раздать агентов — полдела. Дальше начинается управление ими: кто агенту говорит, что ему можно, откуда он знает, как устроена компания, и кто отвечает на его вопросы, когда он упирается в стену.

У нас на этом месте оказался я — единственный администратор примерно на 60 сотрудников. Агенты сотрудников писали мне письма, я пересылал их своему агенту и отправлял ответ обратно. Пользователи шутят, что мы стали прокладками между несколькими ИИ.

В статье — как мы пришли к профильному ИТ-суперагенту, как он устроен внутри (MCP, два RAG-источника, права, проверки на серверах, эскалация в мессенджер) и на какие грабли наступили. Это не продукт и не реклама — рабочий прототип, который сейчас крутится в пилоте.

Что пробовали до этого

Сначала делали агентов под конкретные задачи. Каждый раз оказывалось, что не учтены нюансы, о которых знает только конкретный исполнитель. Допиливание растягивалось надолго.

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

Claude Code сотрудникам и две проблемы

Дальше пошли проще. У нас было несколько сотрудников, которые давно и грамотно работали с ИИ в вебе. Им выдали Claude Code с преднастроенными инструкциями и доступом к инфраструктуре на чтение: аналитика и задачи, 1С, CRM, сайты, почта.

Сначала всё жило на виндовом терминальном сервере. Я как администратор видел их профили и мог своим Claude поправить им инструкции, разрешения, режимы — фактически управлял их агентами. Но два-три человека с несколькими сессиями Claude быстро съели всю оперативку терминала. Выделять каждому виртуалку мы не стали: всё давно ушло в веб, люди работают с домашних машин через VPN. Агенты переехали туда же.

И появились две проблемы:

1. Централизованное управление пропало. Доступа к их md-файлам и конфигам Claude на домашних компьютерах у меня нет.

2. Админ-прокладка. Агент сотрудника не находит что-то в инфраструктуре или ему не хватает прав — он пишет мне письмо. Я отдаю письмо своему Claude, который знает, как всё устроено, он готовит ответ для агента сотрудника, я пересылаю.

Идея: профильный суперагент

Сеть агентов — идея не новая. Но в мультиагентных платформах всё замкнуто в одной программе. Мне хотелось наоборот: у каждого сотрудника свой агент, любой, а в компании есть профильный суперагент, к которому эти агенты обращаются.

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

Как устроено

Прототип — около 4 тысяч строк на Python, FastAPI + MCP, SQLite в режиме WAL. Собирал несколько дней, в паре с Claude Code. Крутится на внутреннем сервере за nginx, снаружи доступен только через VPN.

Подключение: MCP поверх HTTP

Суперагент — обычный HTTP-сервис, а для агентов сотрудников он выглядит как MCP-сервер (streamable HTTP). Сотрудник подключает его одной командой с личным токеном:

claude mcp add --transport http superagent https://<внутренний-адрес>/superagent/mcp \
  --header "Authorization: Bearer <личный-токен>"

После этого у агента появляются инструменты:

Агенту без разницы, что внутри, а суперагенту без разницы, какой у сотрудника агент. Сейчас это Claude Code, но MCP понимают и другие клиенты.

Централизованное управление — одним файлом

Это решило первую проблему. Правила для агентов лежат в одном markdown-файле на стороне суперагента. MCP-сервер отдаёт их в instructions при подключении, и они же приходят в каждом ответе. Поправил файл, перезапустил сервис — поменялось поведение всех подключённых агентов, где бы они ни работали.

Со стороны сотрудника в его CLAUDE.md достаточно пары строк вроде:

Факты по инфраструктуре — superagent.ask, права на задачу — superagent.get_instructions. Если нужно спросить администратора (нет данных, нужен доступ, решение) — superagent.consult. Изменения в пределах прав выполняй сам.

Знания: два RAG-источника

Суперагент отвечает не «из головы» модели, а из двух баз знаний.

Первая — административная: каталог серверов, который я веду для своего Codex/Claude. По папке на сервер, внутри meta, os, software, configs, network, changes, notes. Каталог синхронизируется через GitLab, суперагент держит зеркало и раскладывает его в отдельную векторную таблицу: около 570 файлов, порядка 940 фрагментов, разбиение по заголовкам с перекрытием. Полная индексация на CPU — минут девять, дальше инкрементально по хешам файлов, раз в 10 минут.

Отдельная таблица — не случайность. Админские знания живут своим циклом (меняются каждый день вместе с инфраструктурой) и фильтруются по правам до фрагмента: сотрудник никогда не получит кусок описания сервера, которого он не видит.

Вторая — общая корпоративная база знаний компании на pgvector: регламенты, описания процессов, инструкции. Суперагент берёт из неё ИТ-область и добавляет к ответу вместе с источниками. Доступна она тоже не всем, а только ролям с широкой видимостью.

Поиск по админской части гибридный: SQLite FTS5 плюс эмбеддинги (локальная Ollama), результаты сливаются через RRF. На каждый вопрос агент сотрудника получает отобранные фрагменты с указанием, откуда они взяты, — так ответ можно проверить, а не верить на слово.

Файл с доступами (access.md) в индекс не попадает вообще. Из него суперагент берёт только хост и порт. Логины и ключи он не выдаёт и не хранит: у каждого сотрудника свои учётки, и всё, что он делает, записывается на него.

На обычные вопросы — без LLM

Неочевидная, но очень полезная вещь. На ask и get_instructions суперагент модель не вызывает. Код проверяет права, отбирает из реестра только то, что сотруднику видно, и отдаёт агенту контекст плюс правила. Формулирует ответ уже агент сотрудника — на своей подписке.

У каждого сотрудника своя подписка Claude. LLM на стороне суперагента нужна только там, где надо подумать: беседа consult и разбор ответов администратора. Так быстрее и не съедает общий лимит.

Права проверяет код

Сотрудники в группах, у групп — гранты на серверы (имя, IP или маска вроде 1c-*):

Плюс личные гранты со сроком — «дежурство на неделю». Модель в проверке прав не участвует, поэтому уговорить её бесполезно. Нет прав — агент получает «доступ запрещён, обратитесь к администратору». Сразу оговорюсь про слабое место: тип действия в запросе пока определяется по ключевым словам. Для пилота это терпимо, потому что у сотрудников только чтение, а всё, что они меняют, они меняют сами под своими учётками.

LLM без рук

Модель на стороне суперагента запускается вообще без инструментов: claude -p с пустым списком tools, без MCP, в отдельном рабочем каталоге с запретом всего. Зайти на сервер или выполнить команду она не может.

Если в беседе ей нужно что-то проверить, она возвращает в JSON-ответе просьбу вида {"inspect": [{"server": "...", "check": "disk"}]}. Выполняет код — с правами того сотрудника, который ведёт беседу, не больше трёх проверок за ответ и не больше двух раундов. Результат возвращается модели следующим сообщением.

Сами проверки ограничены ещё и на серверах. Там заведена учётка без sudo, а её ключ привязан к одной команде:

command="/usr/local/bin/sa-inspect",no-port-forwarding,no-pty,no-agent-forwarding,from="<IP суперагента>" ssh-ed25519 AAAA...

sa-inspect понимает только имена проверок из белого списка: disk, mem, svc, journal, pg-dbs, pg-activity, my-processlist и т. п., с валидацией аргументов и ограничением вывода. Роли в БД — pg_monitor в PostgreSQL и PROCESS без SELECT в MariaDB: статистика есть, данных нет. Даже если ключ утечёт, выполнить произвольную команду с ним не выйдет.

Администратор — одной кнопкой

Это решило вторую проблему. consult — многоходовая беседа агента сотрудника с суперагентом. Каждый ответ модели — один из статусов: answered, need_info, escalate, resolved. В большинстве случаев они договариваются сами.

При escalate мне в Яндекс Мессенджер приходит готовый вопрос: что просят, зачем, что суперагент предлагает, и кнопки ✅ / ❌. Нажал — решение ушло в беседу, агент сотрудника забирает его через check. Если отвечаю текстом, его разбирает отдельный LLM-помощник и превращает в решение или сообщение агенту. Обо всём, что решилось без меня, в 19:00 приходит дайджест.

Безопасность и журнал

Прозрачность — то, чего мне не хватило в Paperclip, — закладывал с первого дня:

• журнал всех вызовов: кто, что спросил, что получил, какие проверки, решения администратора; хранится 90 дней;

• аудит всех изменений прав (кто, когда, через что: CLI, админка или бот) — в той же транзакции, что и изменение;

• маскирование секретов в контексте, ответах и журнале;

• детектор ПДн: телефоны, email, ИНН и СНИЛС с проверкой контрольных сумм, карты по Луну, паспорт рядом со словом «паспорт». Больше 10 записей в ответе — маскирование, больше 50 или любые карты/паспорта — сигнал мне;

• сигналы: всплеск запросов относительно обычного поведения сотрудника, серия отказов по правам, «выгрузи всех клиентов» / pg_dump / SELECT * без WHERE, просьбы паролей, попытки prompt injection, ночные обращения к проду;

• квоты на сотрудника и на сам суперагент; если не удалось проверить лимит — отказ, а не «авось».

Почему так строго: агент сотрудника работает на домашнем компьютере, а «только чтение» базы — это тоже возможность всё слить. Заодно, пока внедряли, нашли у себя несколько старых дыр в инфраструктуре. Часть закрыли, часть в плане.

Где я ошибся в идее

Главной фишкой я считал проверку планов: агент сотрудника готовит план, суперагент правит его с учётом реальности, агент выполняет — как будто им руководит профильный специалист. Метод review_plan был готов в первый же день.

В пилоте его убрали из MCP. У сотрудников права только на чтение — проверять нечего. А мне ревьюить собственные планы своим же агентом бессмысленно. Метод остался в REST как «второе мнение по запросу». Подозреваю, что для юристов и маркетинга он вернётся, но пока это открытый вопрос.

Что пригодится, если будете делать похожее

Несколько вещей, на которые я потратил время и которые можно не повторять.

Длинные ответы — асинхронно, и поднимите таймаут клиента

Ответ суперагента с LLM может идти до двух минут, а у Claude Code таймаут на вызов MCP-инструмента короче. Клиент обрывает вызов, сервер ответ дописывает и сохраняет, но агент сотрудника его уже не получит. Снаружи это выглядит как «суперагент молчит».

Два вывода. Первый — таймаут на клиенте поднимается переменной окружения в ~/.claude/settings.json:

{
  "env": {
    "MCP_TOOL_TIMEOUT": "330000"
  }
}

Второй, важнее: всё долгое лучше сразу делать асинхронно. У меня так устроена пара consult / check: беседа живёт на сервере, и даже если вызов оборвался или ответ ждёт решения администратора, агент заберёт его следующим check. Ничего не теряется.

Внутренний сервис по HTTPS: Claude Code не доверяет самоподписанному сертификату

Claude Code — это Node.js, и самоподписанный сертификат сервера он не примет. Правильный путь — выпустить сертификат от корпоративного CA и сказать клиенту, что этому CA можно доверять:

{
  "env": {
    "NODE_EXTRA_CA_CERTS": "/Users/you/.claude/company-ca.crt"
  }
}

Если своего CA в компании нет, его можно поднять за пару минут — для внутреннего сервиса этого достаточно:

# корневой CA (ключ храните отдельно и с правами 600)
openssl req -x509 -new -nodes -newkey rsa:4096 -days 3650 \
  -keyout ca.key -out ca.crt -subj "/CN=Company Internal CA"

# сертификат сервиса, подписанный этим CA
openssl req -new -nodes -newkey rsa:2048 \
  -keyout server.key -out server.csr -subj "/CN=ai.company.local"
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial \
  -days 825 -out server.crt \
  -extfile <(printf "subjectAltName=DNS:ai.company.local")

server.crt и server.key — в nginx, ca.crt — сотрудникам (заодно отпечаток, чтобы они могли сверить). Обратите внимание на subjectAltName: без него современные клиенты сертификат не примут, даже если имя в CN совпадает.

LLM на сервисе — общий ресурс, ставьте предохранитель

У подписки есть лимит в скользящем окне. Если сервис может упереться в него вместе с другими потребителями той же подписки, рано или поздно упрётся — и откажет всем сразу. Что помогло:

• не звать LLM там, где хватает кода: у меня ask и get_instructions вообще без модели;

• один вызов LLM за раз, очередь с таймаутом, потолки в час и в сутки;

• перед каждым вызовом — проверка общего расхода, и fail-closed: если проверить не получилось, лучше честный отказ, чем внезапный 429 у всех.

Эмбеддинги и русский язык

Популярные англоязычные модели эмбеддингов плохо ищут по русскому тексту вперемешку с именами серверов, IP и аббревиатурами вроде 1С. Помогли две вещи: многоязычная модель (bge-m3 через Ollama) и гибридный поиск с FTS5, где точные совпадения по именам и адресам добирает полнотекстовый индекс. Качество поиска меряю небольшим набором эталонных вопросов — без этого любые «стало лучше» на глаз ничего не значат.

Бот на long-poll и шумный httpx

Бот администратора опрашивает Яндекс Мессенджер long-poll запросами через httpx. А httpx по умолчанию пишет в лог на уровне INFO каждый HTTP-запрос — то есть каждый пустой getUpdates. У меня это около 8 тысяч строк в сутки, за которыми не видно ничего полезного. Если делаете бота на long-poll — сразу приглушите логгер:

import logging
logging.getLogger("httpx").setLevel(logging.WARNING)

Что есть на рынке

Я не первый, кто думает о сети агентов. Есть Paperclip, CrewAI, LangGraph. Есть протокол A2A для общения агентов разных производителей — он под Linux Foundation и, если понадобится общение между компаниями, его можно поднять поверх. Есть корпоративные инструменты управления агентами у самих вендоров.

А вот профильного суперагента, который знает практику конкретной компании и через которого идут и знания, и права, и решения администратора, я в готовом виде не нашёл. Если вы видели — напишите в комментариях, правда интересно.

Что получилось и что дальше

Пилот: группа аналитики продаж, четыре человека, чтение баз 1С и CRM. Подключение нового сотрудника по инструкции — минут десять. Письма мне больше не пишут: агенты договариваются с суперагентом сами, а я отвечаю кнопкой, когда нужно решение. Правила для всех агентов меняются в одном месте.

Открытых вопросов больше, чем закрытых:

• как заставить агента сотрудника идти к суперагенту, а не изобретать своё (MCP не принуждает, сейчас это держится на инструкциях);

• как масштабировать на всю компанию и не упереться в лимиты;

• как наполнять базу знаний не только документацией, но и живым опытом.

По последнему пункту уже работаем. RAG есть и используется — дальше вопрос, чем его наполнять. Задача от руководителя: общая база должна пополняться из того, как сотрудники обучают своих агентов, из транскрибаций конференций, общения с клиентами и записей звонков. По сути — источник того самого человеческого опыта для суперагентов. Плюс через неделю-другую пилота будут цифры: сколько вопросов закрывается без меня и сколько доходит до кнопки. Расскажу в следующей части.

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

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