Перевод форматов вызова инструментов между LLM-провайдерами
Запустить привычный coding harness на модели другого провайдера кажется задачей для небольшого адаптера. На деле схема инструмента является лишь частью протокола. В нем есть порядок сообщений, идентификаторы вызовов, потоковые аргументы, подсказки кэширования и иногда состояние рассуждения, специфичное для провайдера.
Можно переводить внутренний протокол harness или использовать harness, который уже поддерживает нужного провайдера. Оба пути возможны. Выбор зависит от того, сколько поведения необходимо сохранить.
Где форматы расходятся
В Anthropic Messages вызовы и результаты инструментов передаются блоками tool_use и tool_result внутри сообщения. В OpenAI Chat Completions вызовы лежат в массиве tool_calls, а результаты возвращаются сообщениями с ролью tool. У OpenAI Responses другой формат: элементы function_call связываются через call_id.
Аргументы тоже отличаются. Anthropic передает объект в tool_use.input, а OpenAI обычно передает JSON-строку. Прокси должен обработать пустые аргументы, ошибочный JSON и идентичность каждого вызова. Он также должен переводить выбор инструмента и возможности JSON Schema только тогда, когда у целевого API есть эквивалентное поведение.
В обычном запросе эти различия решаемы. Сложность появляется на полном цикле работы агента.
Потоковый режим требует автомата состояний
В потоковом режиме вызов инструмента приходит частями. Шлюз должен собрать ID, имя, фрагменты аргументов и сигнал завершения для каждого вызова, прежде чем выдать последовательность событий в формате другого провайдера. Текст вместе с вызовами, параллельные вызовы, повторы и прерванные потоки делают это сложнее простого переименования полей.
В issue-трекерах LiteLLM, Bifrost, Portkey и других шлюзов есть примеры ошибок конкретных версий. Это полезные тест-кейсы, а не доказательство того, что любой шлюз всегда ломается. Если прокси входит в coding workflow, проверьте потоковые вызовы с обязательными аргументами, несколькими вызовами, текстом вместе с вызовами и поврежденной историей.
Состояние рассуждения и кэш
Некоторые провайдеры добавляют непрозрачные поля к блокам рассуждения. Правила их сохранения зависят от модели и версии API. Однозначное преобразование истории Anthropic в OpenAI Chat Completions может не перенести все это состояние, даже если обычные вызовы инструментов переводятся правильно.
С кэшированием похожая ситуация. Anthropic дает явные элементы управления кэшем, а другие API могут использовать неявное кэширование или иной механизм. Переводчик должен сообщать, что он сохранил, а что отбросил. Не стоит считать, что более низкая цена токена переживет изменение cache hit rate.
Где провести границу интеграции
LiteLLM, Bifrost, Portkey, claude-code-router и похожие проекты подходят, когда нужен перевод протоколов, роутинг, failover или единый учет затрат. Их возможности быстро меняются, поэтому проверяйте актуальную документацию и тестируйте конкретную связку провайдера, модели и функций.
Совместимые эндпоинты провайдеров могут уменьшить объем перевода, но это все равно контракт конкретного провайдера. Перед подключением coding harness проверьте документацию, поддержанные функции и условия работы.
Есть и другой путь: оркестрировать harness-процессы выше по уровню. Claude Code, OpenCode, Codex и другие инструменты могут сами вести свой протокол с провайдером. Внешняя система передает задачи через поддерживаемые CLI или API, получает структурированные результаты и распределяет работу, не переписывая внутренние вызовы инструментов. Это сокращает прямой перевод протоколов, но не отменяет права доступа, состояние, оценку результатов и восстановление после ошибок.
MCP связан с задачей, но не решает ее
MCP помогает находить и передавать инструменты. Harness все равно преобразует MCP-инструмент в нативное определение для своего провайдера, а модель выдает вызовы в нативном формате провайдера. Поэтому MCP не убирает различия схем и потоков, описанные выше.
Практическое правило простое: переводите только ту границу, которую можете проверить целиком. Если нужно сохранить внутреннее поведение другого harness, по возможности используйте его нативный путь к провайдеру. Если важнее выбор модели и роутинг, слой оркестрации выше может быть проще в эксплуатации, чем постоянный мост между wire-протоколами.
Полезные ссылки: extended thinking Anthropic, санитизация сообщений LiteLLM, инструменты Vercel AI SDK и MCP.