Vendor lock-in в агентных платформах: как не привязаться намертво

За 2024 год агентные платформы превратились из библиотек для энтузиастов в полноценные коммерческие продукты. У OpenAI появился Assistants API, у Amazon — Bedrock Agents, у Google — Vertex AI Agent Builder, у Microsoft — Azure AI Agent Service, LangChain выпустил облачный LangGraph Platform и наблюдаемость LangSmith. Каждый обещает запуск агента за дни вместо недель. Расплата приходит позже: когда вы решаете сменить провайдера, оказывается, что состояние диалогов, инструменты и логика оркестрации намертво вшиты в чужой формат.

Vendor lock-in — это не абстрактный риск для архитекторов. Это конкретные деньги и недели работы, которые вы потратите, если поставщик поднимет цены, закроет продукт или упрётся в лимиты, которые вас не устраивают. Разберём, где именно возникает привязка в агентных платформах и что делать, чтобы переезд занимал дни, а не кварталы.

Где именно защёлкивается замок

Агент — это не одна модель¹. Это связка из нескольких слоёв, и залипнуть можно на каждом.

• Модель. Промпты, заточенные под особенности конкретной модели, и обращения к closed-weights API вроде GPT-4o или Claude, которые нельзя развернуть у себя.
• Оркестрация. Логика «модель вызвала инструмент, получила результат, решила, что делать дальше». У каждого фреймворка свой способ её описывать.
• Состояние и память. История диалогов, треды, векторные хранилища. Формат Assistants Threads не совместим с форматом Bedrock Sessions.
• Инструменты (tool calling). Описание функций, которые агент умеет вызывать. Схемы у OpenAI, Anthropic и Google похожи, но не идентичны.
• Наблюдаемость. Трейсы, оценки качества, дашборды. LangSmith привязан к экосистеме LangChain, и экспорт истории — отдельная задача.

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

Переезд с одной модели на другую — это правка пары строк с ключом API. Переезд с одной платформы оркестрации на другую — это переписывание бизнес-логики агента с нуля.

Сравнение подходов к привязке

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

Открытый фреймворк тоже не гарантия свободы: код LangGraph написан под свои абстракции графа состояний, и переезд на LlamaIndex или CrewAI потребует переписать оркестрацию. Разница в том, что исходники у вас на руках, а не заперты в чужом дашборде.

Что снижает привязку на практике

Полностью избежать lock-in нельзя — любая абстракция во что-то упирается. Задача в том, чтобы стоимость переезда была предсказуемой и укладывалась в дни. Несколько работающих приёмов.

1. Держите оркестрацию в своём коде. Если основной цикл агента (вызов модели, выбор инструмента, обработка результата) написан вами, а не собран в визуальном конструкторе вендора, вы контролируете главный слой.
2. Абстрагируйте вызов модели. Прослойка вроде LiteLLM или собственный тонкий адаптер дают единый интерфейс поверх OpenAI, Anthropic, Google и локальных моделей. Смена провайдера — правка конфига.
3. Храните состояние у себя. Треды и историю диалогов пишите в свою базу (PostgreSQL, Redis), а не полагайтесь на управляемое хранилище платформы. Векторное хранилище выбирайте с открытым API.
4. Ставьте на открытые протоколы для инструментов. Model Context Protocol² от Anthropic, открытый в конце 2024 года, описывает единый способ подключать инструменты и источники данных к агентам независимо от модели.
5. Проверяйте условия выхода до подписания. Есть ли экспорт данных, в каком формате, сколько времени хранятся логи после отключения. Это пункт договора, а не техническая деталь.

Кому это пригодится, а кому нет

Управляемый облачный сервис подойдёт, если вы делаете прототип или внутренний инструмент, который проживёт несколько месяцев, а команда маленькая и без инфраструктурных ресурсов. Скорость запуска здесь важнее теоретической свободы, и переплата за привязку не наступит, если проект короткий.

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

Гибрид — частый разумный вариант: оркестрация и состояние у вас, а модель дёргается через управляемый API. Так вы платите за качество модели, но не сдаёте в аренду бизнес-логику.

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

Цена вопроса в цифрах

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

Цены на управляемые сервисы меняются каждые несколько месяцев, поэтому конкретные ставки за токены и за вызовы Assistants API сверяйте на официальных страницах OpenAI, AWS и Google Cloud перед выбором. Заложите в расчёт не только текущую цену, но и сценарий её повышения на 20-30% — вопрос не в том, случится ли это, а в том, насколько дорого вам будет уйти, когда случится.

¹ Агент — программа, которая с помощью языковой модели сама решает, какие действия и в каком порядке выполнить для достижения цели: вызвать поиск, обратиться к базе, запустить код, а затем оценить результат и продолжить.

² MCP (Model Context Protocol) — открытый протокол, предложенный Anthropic, для стандартного подключения внешних инструментов и источников данных к языковым моделям, чтобы не писать интеграцию заново под каждого вендора.