Переосмысление LLM-интеграций: что произошло, когда я отправил целый диалог OpenAI другому агенту обычным текстом

Современные AI-приложения всё сильнее привязываются к конкретным провайдерам.

Проект начинается с простой интеграции с OpenAI.

А затем появляются:

• собственные инструменты;
• системы памяти;
• function calling;
• ролевые промпты;
• слои оркестрации;
• взаимодействие агент-агент;
• структурированные ответы;
• поведение, специфичное для конкретного провайдера.

Через несколько месяцев AI-модель перестаёт быть «просто API».

Она становится частью архитектуры самого приложения.

Именно в такой ситуации я оказался с одной из своих legacy-систем.

В проекте уже были:

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

Переписывание всего этого под другого провайдера потребовало бы огромного объёма работы.

Сначала очевидным решением казалось:

• воссоздать OpenAI-совместимый API;
• эмулировать function calling;
• построить слои совместимости протоколов;
• переписать логику оркестрации.

Но затем появилась другая идея:

а что, если вообще перестать заботиться о протоколе конкретного провайдера?

Вместо перестройки инфраструктуры — просто отправить весь диалог, включая роли, инструменты, системные промпты и технические метаданные, другому AI-агенту как обычный текст.

Этот эксперимент привёл к довольно неожиданным результатам.

Агент, использованный в эксперименте, был построен на базе open-source системы HAIH agent.

Основная идея

Изначально система использовала сообщения в стиле OpenAI:

[
  {
    "role": "system",
    "content": "Rules and instructions..."
  },
  {
    "role": "user",
    "content": "User request..."
  }
]

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

Вместо того чтобы переписывать всю архитектуру, я попробовал радикально более простой подход:

• взять весь массив сообщений;
• сериализовать его в текст;
• отправить другому агенту как одно пользовательское сообщение.

Не как структурированный API-вызов.

Не через нативный function calling.

Просто как сырой текст.

Концептуально это выглядело примерно так:

OPENAI_PAYLOAD:
[
  { role: "system", content: "..." },
  { role: "assistant", content: "..." },
  { role: "user", content: "..." }
]

TOOLS:
[...]

INSTRUCTION:
Interpret this conversation and continue it correctly.

На первый взгляд это кажется неправильным.

Многие разработчики предполагают, что:

• роли жёстко контролируются;
• системные промпты находятся в привилегированном канале;
• инструменты требуют нативных API;
• протоколы провайдеров фундаментально особенные.

Но эксперимент показал важную вещь:

большие языковые модели удивительно хорошо умеют восстанавливать семантику протокола из обычного текста.

Неожиданный результат

Эксперимент проводился на:

• Qwen 3.5 4B — локальной модели;
• Gemini Flash Lite.

Обе модели успешно:

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

Даже когда вся история диалога была помещена внутрь одного пользовательского сообщения.

В одном из тестов использовалось почти 70 000 входных токенов, содержащих:

• системные инструкции;
• записи памяти;
• внутренние правила;
• описания инструментов;
• предыдущие ответы ассистента;
• элементы базы знаний;
• логику оркестрации.

При этом сама финальная задача была тривиальной:

отформатировать информацию о бизнесе в Markdown.

И обе модели стабильно выдавали правильный результат.

Без нативного function calling.

Без API, специфичных для конкретного провайдера.

Без специальной обработки ролей.

Что на самом деле показывает этот эксперимент

Это не означает, что нативные API бесполезны.

Они по-прежнему дают:

• валидацию;
• constrained decoding;
• более высокую надёжность;
• поддержку стриминга;
• структурированные ответы;
• дополнительные runtime-механизмы безопасности.

Но эксперимент указывает на более глубокую вещь:

многие семантические элементы протоколов не являются жёсткими архитектурными требованиями.

Это выученные модели поведения.

И это важное различие.

Большая часть современной AI-инфраструктуры строится на предположении, что:

• системные роли фундаментально привилегированны;
• чат-протоколы являются строгими средами исполнения;
• function calling — обязательный архитектурный слой.

Но на практике многие из этих механизмов больше похожи на соглашения, чем на жёсткие границы.

Модель не «понимает» роли так, как операционная система понимает права доступа.

Она видит токены.

А современные модели чрезвычайно хорошо умеют восстанавливать намерение из структурированного текста.

Иллюзия безопасности

Этот эксперимент также показывает опасное заблуждение, существующее в AI-экосистеме.

Многие разработчики относятся к системным промптам так, будто это неизменяемые политики безопасности.

Но это не так.

Системный промпт — не sandbox.

Это не система контроля доступа.

И это не гарантия.

Это сильная вероятностная инструкция.

Разница особенно хорошо становится видна, когда начинаешь вручную сериализовать протоколы.

Если модель способна корректно интерпретировать:

role: system

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

И это одна из причин, почему prompt injection остаётся настолько сложной проблемой.

Модель фундаментально работает в языковой среде, а не в формально изолированной среде исполнения.

Почему это важно для legacy-систем

Практическое следствие здесь довольно серьёзное.

Сегодня многие команды тесно привязаны к:

• OpenAI API;
• специфичному поведению Anthropic;
• нативным инструментам провайдеров;
• оркестрации, завязанной на конкретные SDK.

Миграция с такого стека часто кажется почти невозможной.

Но этот эксперимент указывает на другой подход:

вместо переписывания слоя оркестрации можно виртуализировать сам протокол.

В некоторых случаях можно:

• сохранить существующую архитектуру;
• сериализовать рабочий контекст;
• передать его через другую модель;
• и продолжить работу с удивительно небольшим количеством изменений.

Это особенно полезно для:

• legacy-систем;
• экспериментальных агентских платформ;
• self-hosted моделей;
• multi-provider инфраструктур;
• сценариев быстрой миграции.

Важные ограничения

Этот подход не является магией.

У него есть компромиссы:

• более низкая надёжность;
• более слабые гарантии;
• увеличенные промпты;
• менее детерминированное поведение;
• большая сложность самих промптов.

Кроме того, разные провайдеры по-разному относятся к семантике ролей.

Например, модели Anthropic, судя по всему, сильнее зависят от структурированной обработки протокола и runtime-слоёв оркестрации, чем небольшие open-weight модели.

Поэтому результаты не будут полностью одинаковыми во всех LLM-экосистемах.

Но более широкий вывод остаётся важным:

современные LLM способны восстанавливать удивительно сложные протоколы взаимодействия из обычного текста.

И это меняет то, как стоит мыслить об AI-архитектуре.

Финальная мысль

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

Сама модель зачастую гораздо гибче, чем предполагает окружающая её инфраструктура.

На практике это означает, что:

• протоколы иногда можно виртуализировать;
• оркестрацию иногда можно отделить от провайдера;
• миграция может оказаться проще, чем кажется;
• а многие «жёсткие требования» на самом деле являются соглашениями, закреплёнными инструментальными слоями.

По мере того как AI-системы становятся всё сложнее, умение различать:

• поведение модели;
• поведение runtime;
• соглашения протокола;

может стать одним из важнейших инженерных навыков в этой области.