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

ИТ-администратор, обслуживающий около 60 сотрудников, описал рабочий прототип профильного ИТ-суперагента для Claude Code. Задача возникла после того, как компания начала выдавать каждому сотруднику своего ИИ-агента: управлять ими оказалось сложнее, чем раздать.

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

Две проблемы после переезда в веб

Часть сотрудников получила Claude Code с преднастроенными инструкциями и доступом к инфраструктуре на чтение: аналитика и задачи, 1С, CRM, сайты, почта. Сначала всё работало на виндовом терминальном сервере, где администратор видел профили и мог управлять агентами. Но несколько человек с несколькими сессиями Claude съели всю оперативку терминала, и агенты переехали на домашние машины сотрудников через VPN.

После этого появились две проблемы: пропало централизованное управление, так как доступа к md-файлам и конфигам Claude на домашних компьютерах у администратора нет, и возникла «админ-прокладка» — агент сотрудника писал письмо администратору, тот передавал его своему Claude, а ответ пересылал обратно.

Как устроен суперагент

Прототип — около 4 тысяч строк на Python, FastAPI + MCP, SQLite в режиме WAL. Крутится на внутреннем сервере за nginx, снаружи доступен только через VPN. Для агентов сотрудников суперагент выглядит как MCP-сервер (streamable HTTP), подключается одной командой с личным токеном.

После подключения у агента появляются инструменты: ask — детали инфраструктуры, get_instructions — правила работы и права сотрудника, inspect — проверка факта на сервере, consult — беседа, когда нужно решение администратора, check — забрать ответ администратора.

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

Два RAG-источника

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

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

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

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