Мультимодальные AI-агенты: vision, audio и tools в одном

Короткая версия

В 2026 мультимодальные агенты обычно собираются из трёх практических lane'ов:

• Vision + tools: анализ экрана, документов, изображений, UI и computer use.
• Realtime audio: разговор в реальном времени с tool use и low-latency turn-taking.
• Video understanding: анализ длинного видео или live feed с временными метками.

Рынок сейчас удобно читать так:

• Anthropic силён в vision + computer use и desktop/browser automation.
• OpenAI даёт сильный realtime audio слой через gpt-realtime, а vision есть у latest general models.
• Google Gemini закрывает Live API, video understanding и Computer Use в одном family.

Построй агента для саппорта: клиент звонит, показывает экран, а агент ищет проблему в CRM и подсказывает следующий шаг.

1. Что такое мультимодальный агент на практике

Мультимодальный агент почти всегда состоит из трёх слоёв:

1. Perception layer
   Принимает text, image, audio, video.
2. Reasoning / routing layer
   Решает, что важно, какой tool нужен, нужен ли follow-up question или human approval.
3. Action layer
   Вызывает tools, возвращает speech/text, управляет браузером или desktop environment.

То есть useful multimodality в агентных системах возникает не потому, что “модель умеет картинки”, а потому что perception связан с действием.

2. Vision agents: документы, UI и computer use

Самая зрелая мультимодальная ветка сегодня — vision + tools.

Это сценарии, где агент:

• читает скриншот или изображение;
• распознаёт элементы интерфейса;
• извлекает данные из формы, PDF, таблицы или графика;
• принимает решение и либо отвечает, либо действует через browser / desktop tools.

Anthropic: vision + computer use

Anthropic сейчас особенно полезен в двух слоях:

• обычный vision для анализа изображений и документов;
• computer use tool для управления desktop/browser environment.

В docs Anthropic отдельно подчёркивает:

• Claude 3/4 family принимает изображения как часть Messages API;
• для больших изображений и множества image blocks есть реальные token/latency trade-offs;
• computer use остаётся beta capability и требует sandboxed execution environment.

Это важная рамка: Anthropic хорош не как “универсальный голосовой стек”, а как practical choice для screen-native workflows.

OpenAI: vision у latest models, computer use как отдельный tool

У OpenAI latest general models уже поддерживают text+image input, а для action layer есть отдельный computer tool. Это значит, что мультимодальный агент у OpenAI не обязан быть завязан на один historical brand вроде GPT-4o Realtime или Operator.

Полезнее думать так:

• gpt-5.x / latest general models для vision + reasoning;
• gpt-realtime для live audio conversation;
• computer tool для browser automation;
• Responses / tools / agent stack для orchestration.

Google: vision, video и computer use в одном family

Google сейчас интересен тем, что в Gemini family есть сразу несколько relevant capabilities:

• Live API для voice/video sessions;
• Video understanding для длинного видео с timestamps;
• Computer Use для browser-control scenarios.

Это делает Gemini удобным, когда нужен один vendor для voice + video + browser-oriented automation.

3. Voice agents: real-time audio как action surface

Вторая большая ветка мультимодальных агентов — voice agents.

Полезно различать два режима:

Cascaded voice stack

STT -> text LLM -> TTS

Плюсы:

• проще контролировать каждый слой;
• легче менять поставщиков;
• часто удобнее для call-center backends и analytics.

Минусы:

• выше latency;
• хуже естественность;
• сложнее держать truly conversational turn-taking.

Native realtime stack

Одна realtime-модель принимает audio input и отдаёт audio output, а также может вызывать tools в рамках живой сессии.

Это уже closer to natural conversation.

OpenAI: gpt-realtime

У OpenAI current voice framing лучше строить вокруг gpt-realtime, а не вокруг старого gpt-4o-realtime-preview.

По current model docs:

• gpt-realtime принимает text и audio input;
• поддерживает audio и text output;
• работает через WebRTC, WebSocket или SIP;
• умеет function calling;
• поддерживает image input, но не video.

Это делает его сильным choice для:

• phone/voice support;
• booking/assistant flows;
• realtime copilots с tool use;
• speech-first customer support.

Gemini Live API

У Google Live API framing чуть шире:

• low-latency live interaction;
• streaming audio и video в сессии;
• отдельный tool use для live sessions;
• session-level configuration;
• ограничения по modality и session duration, которые важно учитывать заранее.

По official docs там есть важные operational нюансы:

• Live API сейчас preview;
• одна session может отвечать либо TEXT, либо AUDIO, но не обеими модальностями одновременно;
• audio-only и audio+video сессии имеют разные duration limits;
• для client-side сценариев нужны ephemeral tokens и нормальная auth-модель.

Это уже не “просто поговорить с моделью”, а полноценная stateful multimodal session architecture.

4. Video agents: длинный контекст и temporal reasoning

Video agents полезны там, где картинка меняется со временем и важны события, а не один кадр.

Типичные use cases:

• support review и QA звонков;
• CCTV и operational monitoring;
• анализ product demos и user sessions;
• safety/incident detection;
• извлечение событий из длинных записей.

Gemini video understanding

Gemini сейчас даёт один из самых практичных official video stacks:

• можно передавать inline video для маленьких файлов;
• большие видео грузятся через Files API;
• можно ссылаться на timestamps;
• есть control over clipping intervals и FPS;
• docs прямо объясняют token economics для frame/audio processing.

Критично то, что Google не прячет компромисс:

• по умолчанию видео сэмплируется;
• default frame rate не подходит для очень быстрых сцен;
• low media resolution снижает цену и latency, но режет детали.

Это именно тот тип информации, который и нужен production-команде.

5. Не одна модель, а orchestration

Главная production-реальность мультимодальных агентов: одна модель редко оптимальна для всех модальностей сразу.

Частый healthy stack в 2026 выглядит так:

• realtime audio отдельным lane;
• vision/computer use отдельным lane;
• video understanding отдельным offline или nearline lane;
• tools и policy checks общие;
• orchestration layer маршрутизирует задачу.

Такой подход лучше, чем “пусть одна самая дорогая модель делает всё”, потому что:

• проще контролировать latency;
• проще считать cost;
• можно точнее управлять risk;
• легче добавлять handoff и fallback.

6. Security и privacy в мультимодальных агентах

Чем больше модальностей, тем шире attack surface.

Нормальный baseline:

Особенно опасны четыре антипаттерна:

• хранить raw multimodal traces без redaction;
• давать computer use агенту слишком широкие права;
• путать data stream и instructions;
• не разделять assistive mode и fully autonomous mode.

7. Когда мультимодальность реально нужна

Не добавляйте extra modality только потому, что это звучит современно.

Мультимодальный агент оправдан, если:

• важная часть сигнала не живёт в тексте;
• пользователь уже взаимодействует голосом, видео или экраном;
• без vision/audio/video агент теряет критический контекст;
• action quality становится выше при прямом восприятии интерфейса или media stream.

Не оправдан, если:

• всё можно решить text+tools;
• voice делается только “для вау-эффекта”;
• computer use закрывает то, что уже лучше закрывается API;
• video можно свести к дешёвому event detector + text pipeline.

Архитектура мультимодального оркестратора

Вместо одного “суперагента” полезнее разделять маршруты по modality:

from enum import Enum


class Lane(str, Enum):
    TEXT = "text"
    VISION = "vision"
    REALTIME_AUDIO = "realtime_audio"
    VIDEO = "video"
    COMPUTER_USE = "computer_use"


def route_task(task: dict) -> Lane:
    if task.get("live_audio"):
        return Lane.REALTIME_AUDIO
    if task.get("computer_control"):
        return Lane.COMPUTER_USE
    if task.get("video_uri"):
        return Lane.VIDEO
    if task.get("image") or task.get("pdf"):
        return Lane.VISION
    return Lane.TEXT

Этот уровень routing часто полезнее, чем попытка найти одну “лучшую мультимодальную модель”.

OpenAI-style realtime voice agent

Текущая OpenAI-рамка для voice agent'ов лучше строится через gpt-realtime:

import WebSocket from "ws";

const ws = new WebSocket(
  "wss://api.openai.com/v1/realtime?model=gpt-realtime",
  { headers: { Authorization: `Bearer ${process.env.OPENAI_API_KEY}` } }
);

ws.on("open", () => {
  ws.send(JSON.stringify({
    type: "session.update",
    session: {
      modalities: ["audio"],
      instructions: "Ты голосовой ассистент службы поддержки.",
      tools: [{
        type: "function",
        name: "lookup_ticket",
        description: "Найти тикет по номеру",
        parameters: {
          type: "object",
          properties: {
            ticket_id: { type: "string" }
          },
          required: ["ticket_id"]
        }
      }]
    }
  }));
});

Практически важно:

• считать audio-token economics отдельно от text;
• держать turn-taking и interruption handling;
• выносить sensitive actions за approval layer;
• логировать tool calls отдельно от raw audio.

Gemini-style live multimodal session

Gemini Live API удобен, когда нужна одна stateful session с live media и tools:

from google import genai

client = genai.Client()

session = client.live.connect(
    model="gemini-2.5-flash-native-audio-preview-12-2025",
    config={
        "response_modalities": ["AUDIO"],
        "tools": [{
            "function_declarations": [{
                "name": "create_callback",
                "description": "Создать обратный звонок",
                "parameters": {
                    "type": "object",
                    "properties": {
                        "phone": {"type": "string"}
                    },
                    "required": ["phone"]
                }
            }]
        }]
    }
)

Здесь ключевой operational момент в том, что Live API уже не просто inference endpoint, а session protocol со своими ограничениями по modality и duration.

Video processing без бессмысленного overspend

Для video agents не нужно отправлять весь поток на максимальной детализации по умолчанию. Стартовый production-паттерн обычно такой:

def choose_video_sampling(risk_level: str) -> dict:
    if risk_level == "high":
        return {"fps": 3, "resolution": "default"}
    if risk_level == "medium":
        return {"fps": 1, "resolution": "low"}
    return {"fps": 0.2, "resolution": "low"}

Сначала делайте дешёвый pass, а затем углубляйтесь только в подозрительные сегменты.

У нас voice support assistant с screen-sharing и occasional browser automation. Какой baseline stack взять?

Проверьте себя