Терминальный агент ИИ на 9 провайдеров: как собрать мультимодельный чат в 5 строк кода

Если у вас ключи от нескольких LLM-провайдеров (большие языковые модели как сервис) и вы хотите использовать их в одном терминальном чате с общей историей, эта инструкция покажет, как устроена мультипровайдерная архитектура на примере открытого проекта execai.

Разработчик открытого терминального ИИ-агента execai (написан на Go, работает как локальный инструмент в терминале в духе Claude Code) опубликовал на Хабре детальный разбор архитектуры, которая позволяет девяти провайдерам жить за одним интерфейсом из пяти строк кода. Суть: переключение между моделями на лету, общий контекст диалога и полная изоляция биллинга, ваш ключ ходит напрямую к провайдеру, без промежуточного бэкенда.

Что понадобится?

• Терминальный ИИ-агент execai (открытый код на Go, буфер терминального интерфейса на bubbletea)
• API-ключи хотя бы от двух провайдеров. Поддерживаются: Anthropic, OpenAI, Kimi Code, Kimi API (Moonshot Platform), Z.ai (GLM), Ollama (локально, бесплатно), Claude CLI, Codex CLI, собственный gateway execai
• Понимание двух «диалектов» API: OpenAI-совместимый и Anthropic-совместимый. Все девять провайдеров сводятся к этим двум форматам
• Время: настройка одного провайдера занимает несколько минут, основное время уходит на разбор биллинг-ловушек

Пошаговая инструкция: как подключить несколько провайдеров в один чат

1. Определите, к какому «диалекту» относится ваш провайдер.

По данным из источника, раскладка такая:

• OpenAI-совместимый (запрос POST /v1/chat/completions, авторизация через Bearer-токен): OpenAI, Kimi API (Moonshot Platform), Ollama, gateway execai
• Anthropic-совместимый (запрос POST /v1/messages, авторизация через заголовки x-api-key и anthropic-version): Anthropic, Kimi Code, Z.ai Coding Plan

Это критически важный шаг. Ошибка здесь стоит часов отладки.

2. Реализуйте единый интерфейс StreamingLLM.

Весь зоопарк провайдеров прячется за контрактом из пяти строк:

type StreamingLLM interface {
    Stream(ctx context.Context, messages []AIMessage,
        tools []map[string]any, cb StreamCallbacks) (*StreamResult, error)
}

На вход подаётся история сообщений и JSON-схемы инструментов. На выход: текст ответа, список вызовов инструментов (tool calls) и причина остановки.

3. Настройте колбэки для интерфейса.

Три колбэка отвечают за отображение в терминале:

• OnText: показывает текст по мере генерации
• OnToolCall: сигнализирует, что модель вызвала инструмент (например, Bash)
• OnReasoning: отображает цепочку рассуждений у thinking-моделей (рассуждающих моделей, которые «думают вслух»)

Нюанс: DeepSeek, GLM и Kimi передают рассуждения в разных полях (reasoning, reasoning_content, thinking_delta). Все три нужно свести в один колбэк OnReasoning.

4. Напишите переключатель провайдеров.

Переключение источника сводится к пересозданию клиента:

m.cli = m.makeLLMClient()

Внутри makeLLMClient обычный switch по источнику. Для Kimi Code, например:

case subscriptions.SourceKimi:
    base := active.BaseURL
    if base == "" {
        base = "https://api.kimi.com/coding"
    }
    return llm.NewAnthropicClient(base, active.APIKey,
        m.current.ID, m.cfg.ThinkingBudget)

А для Kimi API (Moonshot Platform) другой клиент и другой эндпоинт:

case subscriptions.SourceKimiAPI:
    base := active.BaseURL
    if base == "" {
        base = "https://api.moonshot.ai/v1"
    }
    return llm.NewGLMClient(base, active.APIKey, m.current.ID)

Итого на девять провайдеров хватает четырёх реализаций: клиент gateway, generic OpenAI-совместимый клиент, generic Anthropic-совместимый клиент и обёртки над локальными CLI.

5. Реализуйте SSE-парсер с аккумуляцией tool calls по индексам.

Модель отдаёт вызов инструмента не целиком, а «размазанным» по чанкам (порциям данных потока). В первом чанке приходит имя функции и начало аргументов, дальше только дельты. Склеивать нужно по индексу:

for _, tc := range ch.Delta.ToolCalls {
    idx := tc.Index
    existing, ok := toolByIdx[idx]
    if !ok {
        existing = &ToolCall{Index: idx, ID: tc.ID,
            Type: tc.Type, Function: tc.Function}
        toolByIdx[idx] = existing
    } else {
        existing.Function.Arguments += tc.Function.Arguments
    }
}

6. Подключите динамические каталоги моделей.

Для OpenAI-совместимых провайдеров при подключении вызывайте GET /v1/models и стройте каталог из того, что реально доступно конкретному ключу. Это избавляет от захардкоженных списков, которые устаревают через неделю.

/source kimi        ← переключились на Kimi K3
объясни этот код    ← отвечает Kimi
/source zai         ← переключились на GLM-5.2
продолжай           ← GLM видит ВСЮ историю, включая ответы Kimi

Что делать с этим прямо сейчас?

Автору на Дзене. Терминальный агент ИИ с несколькими провайдерами позволяет сравнить, как разные модели справляются с вашим черновиком или кодом, не выходя из одного окна и не теряя контекст. Если вы уже пробовали Claude Code, execai даёт похожий опыт, но с выбором модели под задачу.

Разработчику и маркетологу. Архитектура «один интерфейс, много провайдеров» экономит на подписках: дорогую модель используете для сложных задач, дешёвую или бесплатную (Ollama локально) для рутины.

Предпринимателю в РФ и СНГ. Из провайдеров, доступных без VPN, стоит присмотреться к Kimi и GLM: оба поддерживают русский язык и стоят дешевле западных аналогов ($18 и $19 в месяц за подписку). Но учтите биллинг-ловушки, описанные выше. Из российских аналогов подобного терминального агента пока нет, ближайшее по духу, работа с YandexGPT или GigaChat через API, но там нет готового мультипровайдерного переключателя.

Главный вывод из этого разбора практический: прежде чем подключать нового провайдера, проверьте не модель и не цену, а то, какой тип биллинга привязан к вашему ключу и на каком эндпоинте он реально принимается. Один вечер на эту проверку сэкономит три вечера на отладку «необъяснимых 429-х».