WorkBuddy и несколько AI-моделей: воспроизводимая настройка через API

Рабочее пространство с AI-агентами становится полезным только тогда, когда его конфигурация воспроизводима: команда понимает, какой адрес вызывается, откуда берётся идентификатор модели, как хранится ключ и что именно проверять при ошибке. В этой статье разберём настройку пользовательских моделей в WorkBuddy через Ace Data Cloud. Подход подходит для разработчиков, работающих с несколькими моделями и желающих сохранить единый технический контур для диалоговых задач, анализа кода и инструментальных вызовов.

WorkBuddy — настольное рабочее пространство для Windows 10+ и macOS 12+. В его разделе моделей есть механизм пользовательского провайдера для API, совместимого с форматом OpenAI Chat Completions. Ace Data Cloud предоставляет такой маршрут: один базовый адрес, один API Token и выбор точного идентификатора модели. В результате приложение остаётся клиентом интерфейса, а выбор совместимых моделей и учёт вызовов происходят на уровне платформы.

Что подготовить до настройки

Сначала откройте русскую версию платформы Ace Data Cloud, затем перейдите в консоль приложений. Создайте или выберите нужное приложение и выпустите API Token. Не вставляйте рабочий ключ в репозиторий, скриншоты, баг-репорты и общие заметки. Для локальной проверки удобнее передавать его через переменную окружения.

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

export ACE_API_TOKEN="ваш_токен"

curl -sS https://api.acedata.cloud/v1/models \
  -H "Authorization: Bearer $ACE_API_TOKEN" \
  -H "Accept: application/json"

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

Базовый адрес и правило формирования пути

В форме добавления модели WorkBuddy укажите провайдера Custom, а в поле адреса — https://api.acedata.cloud/v1. Оставьте переключатель пользовательского протокола выключенным. В таком режиме WorkBuddy проверяет базовый адрес и сам добавляет стандартный путь /chat/completions. Это важно: если одновременно ввести полный путь и сохранить автоматическое дополнение, получится неверный адрес запроса.

Provider: Custom;
Interface Address: https://api.acedata.cloud/v1;
API KEY: API Token из консоли приложения;
Model Name: точный id из актуального каталога;
Input и Output: начните с варианта «использовать значение сервиса».

Полный URL вводят только при осознанной необходимости отправлять запрос ровно по указанному нестандартному адресу и при включённом пользовательском протоколе. Для стандартной интеграции это добавляет лишнюю переменную в отладку, поэтому базовый адрес предпочтительнее.

Проверка маршрута вне интерфейса

Прежде чем искать проблему в приложении, выполните минимальный запрос из терминала. Он показывает, принимается ли токен, существует ли идентификатор и отвечает ли маршрут Chat Completions. Подставьте модель, которую вы действительно увидели в каталоге, а не значение из этого шаблона.

curl -sS https://api.acedata.cloud/v1/chat/completions \
  -H "Authorization: Bearer $ACE_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "MODEL_ID_ИЗ_КАТАЛОГА",
    "messages": [
      {"role": "user", "content": "Ответь одним словом: готово"}
    ],
    "temperature": 0
  }'

Та же проверка на Python удобна для CI-проверок, внутренних утилит и воспроизводимого журнала. В реальном сервисе получайте токен из защищённого хранилища секретов, а не из литерала в исходном коде.

import os
import requests

base_url = "https://api.acedata.cloud/v1"
token = os.environ["ACE_API_TOKEN"]
payload = {
    "model": "MODEL_ID_ИЗ_КАТАЛОГА",
    "messages": [{"role": "user", "content": "Кратко опиши статус проверки."}],
    "temperature": 0,
}
response = requests.post(
    f"{base_url}/chat/completions",
    headers={"Authorization": f"Bearer {token}"},
    json=payload,
    timeout=45,
)
response.raise_for_status()
print(response.json()["choices"][0]["message"]["content"])

Как выставлять возможности модели

В разделе расширенной конфигурации WorkBuddy доступны флаги Tool Calling, Image Input и Inference Mode. Не включайте их «на всякий случай». Каждый флаг сообщает клиенту, как формировать и отображать запросы. Если задекларировать возможность, которой нет у выбранной модели, проявления будут неприятными: от неверного формата сообщения до ошибки в момент вызова инструмента.

Включайте Tool Calling только для моделей, у которых это подтверждено актуальным каталогом или профилем конфигурации.
Включайте Image Input лишь при документированной поддержке изображений.
Выбирайте Inference Mode только для моделей, для которых клиент ожидает соответствующий режим отображения.
После изменения параметров полностью перезапускайте WorkBuddy, чтобы исключить использование старой сессии.

Одним ключом можно добавить несколько записей Custom: для каждой повторите добавление, оставьте тот же базовый адрес и укажите другой точный идентификатор. Так модели будут видны вместе в группе пользовательских моделей, а переключение не потребует менять сетевые параметры. Однако способности и лимиты следует задавать отдельно для каждой записи.

Диагностика по слоям

Если тестовый запрос из терминала успешен, но ответа нет в WorkBuddy, проверьте в первую очередь базовый адрес, отсутствие полного пути при выключенном переключателе, точность идентификатора и перезапуск приложения. Ошибка класса 4xx обычно указывает на недопустимый идентификатор, область доступа или формат запроса; для неё полезно сохранить код и тело ответа без токена.

Если терминальный запрос тоже не проходит, не меняйте сразу несколько параметров. Последовательно проверьте срок действия ключа, приложение-владельца, список разрешённых API, баланс и повторный запрос каталога. Такой порядок отделяет проблему учётных данных от ошибки интерфейса. Расход зависит от фактически вызванной модели и списывается с баланса Ace Data Cloud; локальный клиент не заменяет контроль расходов в консоли.

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

Search This Blog

AceDataCloud