Плагин Keystone научил Claude Code ставить LLM-шлюз: 8 скиллов, ключи вне чата

Если попросить агента «поставь нам LLM-шлюз», он уверенно придумает переменные окружения, которых не существует, и вы потом час будете искать, почему конфиг не работает. LLM-шлюз — это одна точка, через которую все ваши сервисы ходят к OpenAI, Anthropic, Gemini и другим провайдерам: он хранит ключи, выбирает модель и переключается при сбоях. Авторы self-hosted шлюза Keystone (KTMS, написан на Go) решили проблему не уговорами в промпте, а инженерно: выпустили плагин для Claude Code с 8 скиллами — готовыми инструкциями, которые знают настоящие команды, флаги и поля конфига, — и MCP-сервером, через который агент видит, что именно запущено. Ключи при этом в чат не попадают.

Что умеют 8 скиллов

Установка — две команды: добавить маркетплейс ai-process/ktms и поставить плагин ktms@ai-process. Отдельно нужен CLI ktms в PATH (из архива релиза или через go install). Версия плагина совпадает с версией Keystone.

Скиллы покрывают весь путь: assess (оценка системы и вердикт, нужен ли шлюз), deploy (Compose или Helm, секреты, порядок первого запуска), integrate (перевод вызовов LLM одного сервиса на шлюз), configure (маршрутизация, ключи и лимиты в ktms.yaml с планом изменений), migrate (переезд с другого шлюза или с прямых вызовов SDK), node (локальная GPU-нода с фолбэком в облако), usage-reports (расходы, отчёты, алерты) и production-review (проверка до и после запуска). Названия помнить не нужно: агент сам берёт подходящий скилл, а слеш-команда запускает его явно.

Чтобы скиллы не устаревали, CI Keystone читает каждый SKILL.md и падает, если там упомянута команда, флаг, инструмент MCP или раздел README, которых в этой версии нет. Это снимает типичную беду: инструкция называет флаг, удалённый два релиза назад, и агент начинает импровизировать.

Как это выглядит на демо-проекте

В примере три сервиса: бот поддержки на OpenAI SDK, поиск на Anthropic SDK с эмбеддингами OpenAI и ночной воркер, который около 40 000 раз за ночь зовёт Gemini. Скилл assess ничего не меняет: он находит все пять вызовов LLM с файлом и строкой и замечает то, о чём не спрашивали. Все сервисы грузят общий env_file, поэтому каждый получает все три ключа вендоров. Параметр temperature=0.3 в одном из вызовов шлюз проигнорирует, так что качество ответов после переключения нужно проверить. Ещё скилл заметил, что rerank.ts ничего не переранжирует, а только объясняет результаты.

Вердикт честный: шлюз оправдан, но если бы в системе был только бот поддержки на gpt-4o, он был бы не нужен. План начинается с ночного воркера: там основные деньги и риск, пользователи вызов не видят, а неудачную ночь можно просто перезапустить.

Скилл integrate собирает адрес, ключ, таймауты, ретраи и атрибуцию расходов в один небольшой клиентский модуль. Зашитую модель он заменяет уровнем сложности с обоснованием в одну строку: low для классификации и коротких ответов, medium для обычной генерации, high для рассуждений и длинных документов. Ретраи SDK он отключает и один раз реализует контракт ошибок: ждать Retry-After при 429, отступать при 503, не повторять ошибки конфигурации. Проверка в конце идёт по реальной маршрутизации: команда ktms route explain (вывод Keystone 1.3.6) показывает цепочку моделей. Если она заканчивается статусом kept — всё в порядке, а no_vendor_key означает, что не хватает ключа, и это видно ещё до выкатки сервиса.

Где проходит граница доверия

Команду ktms init агент намеренно оставляет человеку: она в вашем терминале без эха спрашивает админский ключ и ключи вендоров, пишет ktms.yaml с моделями и правилами по умолчанию, показывает план и применяет его.

Дальше configure работает как Terraform: правка, ktms config plan, показ плана человеку, применение только после согласия. Ограничения зашиты в инструменты, а не в промпт:

• MCP-сервер по умолчанию только читает, инструменты записи появляются с флагом --allow-write;
• config_plan возвращает plan_id, а config_apply применяет ровно этот план один раз и откажется, если конфигурация успела измениться;
• ключ вендора берётся только из переменных KTMS_VENDOR_KEY_*, поэтому агент не подсунет в конфиг админский ключ или другой секрет;
• имена и значения, пришедшие из Keystone, помечены как данные, а не инструкции.

Ограничения и что взять на практике

Это плагин самих авторов шлюза, и работает он только с Keystone. OpenAI-совместимый API шлюза игнорирует temperature, top_p, stop и seed, а эмбеддингам нужен точный id модели, поэтому часть вызовов переносится не один в один. Примеры получены на демо-проекте, а не на чужом продакшене.

Урок шире самого шлюза. Если хотите, чтобы агент настраивал инфраструктуру, дайте ему скиллы, сверяемые в CI с версией продукта, MCP в режиме чтения по умолчанию и план с подтверждением вместо прямой записи. Секреты оставьте человеку. Скиллы — обычные Agent Skills, то есть папки с SKILL.md, поэтому их можно скопировать в Codex, Cursor или другой агент, который их читает, и подключить два MCP-сервера. Для ассистентов без скиллов и MCP те же инструкции лежат в виде промптов.