Skip to main content
LLM не имеют собственной памяти — модель не помнит, что вы сказали мгновение назад. «Многоходовый диалог» на самом деле означает лишь отправку всей истории разговора с каждым запросом. Это руководство объясняет, как каждый из четырёх форматов вызова на APIYI сохраняет эту историю и какие подводные камни следует учитывать.
Примеры используют эндпоинт https://api.apiyi.com и ваш APIYI token. Упоминаемые модели: gpt-5.4-mini, deepseek-v4-pro, gemini-3.5-flash, claude-sonnet-4-6.

Основной принцип: ведите историю сами

Одной фразой: модель не сохраняет состояние; вы (клиент) ведете историю и отправляете ее целиком на каждом ходе.
На каждом новом ходе добавляйте предыдущее сообщение пользователя и ответ модели в конец массива истории, затем отправляйте его целиком. Единственные различия между форматами — как называется массив истории и как записываются роли.
На APIYI всегда используйте подход «ведите историю сами». Не полагайтесь на любое состояние разговора на стороне сервера (например, previous_response_id в OpenAI Responses) — через шлюз это не гарантированно работает, как подробно описано в разделе OpenAI native ниже.

OpenAI compatible mode (работает во всех моделях)

Самый универсальный подход, endpoint /v1/chat/completions. История хранится в массиве messages, при этом каждый элемент содержит role (system / user / assistant). Изменение строки model позволяет одному и тому же коду работать с разными моделями (gpt, deepseek, claude, gemini…).
Одна кодовая база, много моделей: измените model на deepseek-v4-pro, claude-sonnet-4-6, gemini-3.5-flash или любую другую модель — логика многоходового диалога останется прежней. См. Обзор моделей и тарифов.

Обработка истории для reasoning-моделей

Reasoning-модели, такие как deepseek-v4-pro, возвращают дополнительное поле reasoning_content (цепочка рассуждений).
Оставляйте в истории только content — не передавайте reasoning_content обратно. Это рассуждение — всего лишь промежуточный результат текущего хода; возврат его обратно впустую расходует tokens и нарушает правила upstream (в прямом API DeepSeek за это даже возвращается 400). При добавлении в историю берите только content:
Подробнее о разборе ответов reasoning-моделей см. Вывод reasoning-модели.

Нативный формат OpenAI (Responses API)

Эндпоинт /v1/responses. Для многотурового взаимодействия передавайте полную историю в массиве input (каждая запись с role / content) — тот же подход с самостоятельным управлением, что и в совместимом режиме:
Не полагайтесь на серверное состояние вроде previous_response_id / conversation / store. Проверено через шлюз APIYI: при передаче previous_response_id ошибка не возникает (возвращается 200), но на следующем ходе предыдущий ответ не запоминается, а GET /v1/responses/{id} недоступен. Поэтому в APIYI используйте Responses API с самостоятельно управляемой историей (массив input), как показано выше.

Нативный формат Gemini

Эндпоинт /v1beta/models/{model}:generateContent. История хранится в массиве contents. Обратите внимание, что роли — user / model (а не assistant), и содержимое каждой записи помещается в parts.
Еще проще: официальный google-genai SDK client.chats.create(...) сохраняет для вас историю contents — просто вызывайте send_message, без ручной сборки.
Ответы Gemini 3-series прикрепляют thoughtSignature к частям. Для обычного текста в несколько ходов достаточно возвращать только text для сохранения контекста (и это дешевле по token); только сценарии, требующие строгой непрерывности рассуждения, такие как вызов функций, требуют передавать thoughtSignature обратно без изменений — официальный SDK делает это автоматически. См. Нативные вызовы Gemini и Вызов функций.

Нативный формат Anthropic

Эндпоинт /v1/messages. История хранится в массиве messages с ролями user / assistant; content может быть обычной строкой. Обратите внимание, что max_tokens обязателен.
Вы также можете использовать официальный anthropic SDK, указав base_url на https://api.apiyi.com. Ответ представляет собой массив блоков content — подробности разбора см. в Claude Streaming & Responses.

Сравнение четырех форматов

Выбор: если вам нужен один кодовая база для нескольких вендоров → выбирайте режим, совместимый с OpenAI; если вам нужны только нативные функции конкретного вендора (Gemini thought signatures / code execution, Claude thinking blocks & caching, встроенные инструменты OpenAI) → используйте этот нативный формат.

Вопросы и ответы

Да. Каждый ход повторно отправляет всю историю, поэтому число input tokens растет с количеством ходов и стоимость соответственно увеличивается. Основной способ сэкономить — кэширование контекста: при идентичном префиксе истории автоматически срабатывает ставка кэша (намного ниже базовой цены). См. OpenAI caching, Claude caching, Gemini caching.
Четкого правила нет, но более длинная история обходится дороже и может превысить контекстное окно модели. Типичные стратегии: (1) скользящее окно — хранить только последние N ходов; (2) сжатие summary — сжимать более ранние ходы в абзац в system prompt; (3) всегда сохранять системную инструкцию и самые последние ходы. Сопоставляйте это с тем, сколько «памяти» нужно вашему сценарию.
Совместимые с OpenAI и Anthropic: в начале разговора (совместимые используют role:"system"; Anthropic использует верхнеуровневое поле system или первое сообщение). Gemini: используйте config.system_instruction. Системную инструкцию нужно задать только один раз — не нужно добавлять ее повторно на каждом ходе.
Нет. Рассуждение — промежуточный результат хода; в истории следует хранить только финальный content (для Gemini — только text). Возврат рассуждения впустую расходует tokens, и некоторые upstream его отклоняют. Исключение — thoughtSignature в function calling у Gemini: официальный SDK обрабатывает это автоматически.
В APIYI это не рекомендуется. previous_response_id в OpenAI Responses не гарантированно работает через шлюз (проверено: памяти нет). Используйте самостоятельно управляемую историю на стороне клиента везде — это самый стабильный и единообразный вариант для всех моделей.

Ссылки по теме