Архитектура ИИ-ассистента: LLM, память, инструменты, маршрутизация, наблюдаемость

Продолжающий работу ИИ-ассистент — это не «языковая модель с промптом». Это система, которая принимает намерения пользователя, сохраняет состояние, принимает решения о том, когда извлекать данные или выполнять действия, и предоставляет достаточно деталей времени выполнения для отладки сбоев.

Системный взгляд на эту архитектуру рассматривается в кластере «Системы ИИ», когда ассистенты выходят за рамки единого вызова модели.

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

Наиболее чистая архитектура разделяет ответственность на пять слоев: LLM (языковая модель), Память, Инструменты, Маршрутизация и Наблюдаемость. Такое разделение соответствует возможностям, предоставляемым API основных провайдеров, протоколом MCP, локальными средами выполнения, такими как vLLM и llama.cpp, а также реальными системами ассистентов, такими как OpenClaw и Hermes.

Память следует рассматривать не просто как «более длинный контекст». Системы поиска превращают внешние знания в явную непараметрическую память — ту же область дизайна, которая подробно рассматривается в статье о Генерации, дополненной поиском (RAG) — и как руководства Anthropic по контексту, так и статья «Lost in the Middle» предупреждают, что простое впихивание большего количества токенов в контекст не гарантирует надежного запоминания.

Использование инструментов — это контрактная граница, а не магия. Вызов функций OpenAI, использование инструментов Anthropic и MCP опираются на один и тот же паттерн: модель генерирует структурированный запрос, среда выполнения выполняет его, а результат возвращается в разговор. Если эта граница размыта, ассистент становится ненадежным.

Моя позиция проста: начинайте с простого. Один оркестратор, один путь к долговременной памяти, одна трассировка на запрос и одна явная политика для выполнения инструментов. Многоагентные графы полезны, но только после того, как вы сможете объяснить случаи отказа одного агента без догадок.

Что такое система ИИ-ассистента

Практическое определение таково: система ИИ-ассистента — это среда выполнения, которая преобразует намерения пользователя в ответ или действие, комбинируя интерфейс модели, сборку контекста, выполнение инструментов, управление состоянием и телеметрию. Именно поэтому полезные документы — это не просто карточки моделей. Полезные документы — это справочники по API, контракты инструментов, руководства по поиску, документы по маршрутизации и трассировке. API Responses от OpenAI предоставляет взаимодействия с сохранением состояния, встроенные инструменты и вызов функций. API Claude от Anthropic предоставляет прямой доступ к Сообщениям, а также Управляемых Агентов. OpenClaw и Hermes идут на шаг дальше и показывают, что происходит, когда вы выводите эти возможности за стойкие шлюзы, каналы, сессии и память.

Другими словами, у системы ассистента контракт шире, чем у простого завершения чата. Хороший внутренний контракт выглядит примерно так:

AssistantRequest  = намерение пользователя + идентификатор + сессия + вложения + политика
AssistantResponse = ответ + действия + цитаты + изменения состояния + идентификатор трассировки

Этот контракт важен, потому что каждое производственное разногласие в конечном итоге сводится к одному из этих вопросов: какой контекст был видим, какой инструмент был выполнен, какая модель ответила, какая память была прочитана или записана, и где трассировка показывает, что система потратила время. OpenTelemetry определяет трассировки как путь запроса через приложение, что является именно той абстракцией, которая нужна серьезным ассистентам. LangSmith и OpenLIT затем специализируют эту идею для LLM, инструментов, векторных хранилищ и рабочих процессов агентов.

Основные компоненты и интерфейсы

Разделение компонентов, приведенное ниже, является наиболее устойчивым, как мне кажется. Кроме того, это разделение лучше всего согласуется с официальными API и открытыми средами выполнения, которые люди действительно используют.

Таблица выше основана на официальных интерфейсах провайдеров, MCP, документации по векторным базам данных и документации по средам выполнения vLLM, llama.cpp, OpenClaw и Hermes.

Слой LLM должен хорошо выполнять три вещи: потреблять текущий рабочий контекст, испускать либо окончательный ответ, либо структурированный запрос на действие, и возвращать достаточно метаданных для поддержки повторных попыток и трассировки. API Responses от OpenAI явно разработан для взаимодействий с сохранением состояния, а также для встроенных инструментов и вызова функций. API Messages от Anthropic предоставляет тот же основной цикл через блоки tool_use и возвраты tool_result, в то время как Управляемые Агенты дают вам размещенную среду, если вы не хотите создавать цикл самостоятельно. Локальные среды выполнения, такие как vLLM и llama.cpp, важны, потому что они сохраняют знакомые интерфейсы в стиле провайдеров, позволяя вам размещать вывод внутри своей собственной среды.

Слой памяти следует мысленно разделить на три категории: рабочая память, долговременная символическая память и семантическая память, доступная для поиска. Эмбеддинги OpenAI возвращают векторы, которые можно индексировать и искать; Поиск файлов и документов OpenAI затем накладывает семантический и ключевой поиск поверх векторных хранилищ. Pinecone, Weaviate, pgvector и Milvus представляют четыре распространенные формы хранения: полностью управляемые, векторно-нативные с открытым исходным кодом, нативные для Postgres и распределенные векторные базы данных. Hermes и OpenClaw добавляют полезное напоминание о том, что не вся память должна находиться в векторном хранилище: заметки на основе файлов, проверенные продвижения и снимки сессии часто являются более честным дизайном. Системы памяти в ИИ-ассистентах отображает кросс-фреймворковую модель; Система памяти агента Hermes раскрывает ограниченную базовую память и замороженные снимки сессии в одном продукте.

Слой инструментов — это место, где ассистент перестает быть суммаризатором и начинает быть программным обеспечением. Вызов функций OpenAI рассматривает инструменты как функциональность, определенную схемой, которую модель может решить вызвать. Anthropic говорит то же самое более явно: использование инструментов — это контракт между вашим приложением и моделью, и модель никогда не выполняет ничего самостоятельно. MCP обобщает этот контракт в клиент-серверный протокол, где хосты подключаются к одному или нескольким серверам, которые предоставляют инструменты, промпты и ресурсы — ту же границу, которая описана пошагово в Сервер MCP на Go. LangChain и LlamaIndex комфортно уживаются здесь как библиотеки оркестровки: LangChain фокусируется на предварительно созданной архитектуре агентов и интеграциях, в то время как LlamaIndex фокусируется на доступе к данным с дополнением контекста, движках запросов и рабочих процессах.

Слой маршрутизации существует потому, что вопрос «какая модель?» никогда не является единственным. Вам также нужны «какой путь провайдера, какой арендатор, какой бюджет, какой класс задержки и какой резервный вариант?». LiteLLM полезен, потому что его официальная документация поразительно конкретна: взвешенный выбор, наименее загруженный, маршрутизация на основе задержки, маршрутизация на основе стоимости и ограниченные переключения являются первоклассными паттернами. OpenClaw расширяет маршрутизацию вверх до изоляции каналов и агентов, в то время как Hermes расширяет ее вниз до слотов моделей для основных и вспомогательных задач, таких как суммаризация, сжатие контекста и маршрутизация инструментов MCP. Это правильная ментальная модель: маршрутизатор выбирает не только модель, он выбирает полосу выполнения.

Слой наблюдаемости — это то, что предотвращает превращение архитектуры в фольклор. OpenTelemetry дает вам абстракцию трассировки. LangSmith дает вам сквозную видимость шагов приложения LLM и поддерживает облачные, гибридные и локальные формы развертывания. OpenLIT дает вам нативную наблюдаемость ИИ на базе OpenTelemetry с вариантами без кода и ручной инструментации, включая поддержку LLM, фреймворков агентов, векторных баз данных и GPU. Для производственных метрик, трассировок и паттернов SLO по всему выводу и рабочим процессам агентов см. Наблюдаемость для систем LLM. Если у вашего ассистента нет трассировки на запрос, нет спана на вызов модели и нет истории событий для выполнения инструментов, у вас еще нет архитектуры. У вас есть лишь ощущения.

Захват, обогащение, ответ

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

Шаг захвата обычно важнее, чем кажется. И OpenClaw, и Hermes помещают стойкий шлюз перед ассистентом, потому что входной трафик — это не просто ввод текста. Он включает метаданные канала, идентификаторы, авторизацию, границы сессии, прямые сообщения, группы, таймеры cron и семантику доставки. Если вы пропустите этот слой и полагаетесь на абстракцию виджета чата, вы в конечном итоге прикрутите его обратно как ad-hoc посредника.

Шаг обогатения — это место, где зрелые системы расходятся с демонстрационными примерами. Поиск и Поиск файлов OpenAI делают поиск явным через векторные хранилища и вызовы поиска. LlamaIndex формализует тот же паттерн через коннекторы данных, индексы, движки запросов и рабочие процессы. Hermes идет дальше, разделяя парк моделей на основные и вспомогательные слоты, перекладывая такие задачи, как сжатие, суммаризация и маршрутизация, на более маленькие или специализированные модели. Это паттерн дизайна, который стоит украсть: не тратьте токены самой дорогой модели на рутину.

Шаг ответа — это не «генерация текста». Это «закрытие текущего цикла». Если модель может ответить напрямую, она это делает. Если ей нужен инструмент, она испускает структурированный запрос. Контракт использования инструментов Anthropic и руководство по вызову функций OpenAI делают это явным. Причина, по которой это важно с архитектурной точки зрения, заключается в том, что выходные данные теперь включают как язык, так и поток управления. Ваш объект ответа — это частично проза, а частично план выполнения среды.

Шаг записи — это место, где проявляются семантики согласованности. Pinecone разделяет пути записи и чтения и обрабатывает записи после долговременного подтверждения. Память Hermes инъектируется как замороженный снимок для каждой сессии, чтобы сохранить производительность префиксного кэша, что означает, что новые записи не появляются автоматически в промпте текущей сессии. Система Dreaming от OpenClaw продвигает только проверенные, обоснованные кандидаты в MEMORY.md, и это опция, а не всегда включенная функция. Практический урок заключается в том, что память редко бывает истинно «чтение после записи» на каждом слое. Вам нужно проектировать для поэтапной видимости.

OpenClaw и Hermes как референсные системы

OpenClaw и Hermes являются полезными референсными случаями, потому что они не являются просто обертками вокруг одного API провайдера. Оба представляют ассистента как долгоживущую систему с шлюзами, сессиями, инструментами, памятью и несколькими бэкендами моделей.

Это отображение основано на официальной документации и репозиториях OpenClaw и Hermes. OpenClaw документирует архитектуру шлюза, многоагентную маршрутизацию, поддержку кастомных и локальных провайдеров, включая vLLM и Ollama, опциональную активную память и продвижение на основе Dreaming. Hermes документирует шлюз сообщений, центральный цикл AIAgent, основные и вспомогательные слоты моделей, встроенную память и нативную интеграцию MCP.

Моя слегка предвзятая интерпретация такова, что обе системы выдвигают один и тот же архитектурный аргумент с разными акцентами. OpenClaw сильно ориентирован на шлюз. Hermes сильно ориентирован на цикл агента. Но оба отвергают поверхностную идею о том, что ассистент — это просто «промпт плюс модель». Они моделируют каналы, идентификаторы, семантику памяти, поверхности инструментов и гетерогенность бэкендов как первоклассные проблемы. Именно это и должна делать производственная архитектура.

Практический гибридный стек, вдохновленный обеими системами, выглядит так:

edge:
  gateway: hermes or openclaw

routing:
  proxy: litellm
  policy: latency and budget aware
  tenancy: session and channel scoped

llm:
  primary: openai responses or anthropic messages
  local_fallback: vllm
  local_dev: ollama or llama.cpp

memory:
  session: sqlite or postgres
  semantic: pgvector or weaviate
  embeddings: openai embeddings or ollama embeddings

tools:
  contract: json schema tools plus mcp
  examples: filesystem, browser, web search, internal APIs

observability:
  traces: opentelemetry
  ai_dashboards: openlit or langsmith
  evals: openai evals plus app-specific regression sets

Этот стек является обоснованным паттерном развертывания, а не прописанным вендором чертежом. Он работает, потому что официальные интерфейсы согласуются: OpenAI и Anthropic предоставляют ориентированные на инструменты API, vLLM и llama.cpp эмулируют конечные точки в стиле провайдеров, Ollama обрабатывает локальные модели и эмбеддинги, MCP стандартизирует внешние инструменты, LiteLLM обрабатывает маршрутизацию и переключение, а совместимые с OpenTelemetry платформы могут трассировать весь путь.

Паттерны, таблицы и компромиссы

Существует несколько повторяющихся паттернов ассистентов, которые стоит назвать. Управляемый ассистент держит большую часть среды выполнения внутри API провайдеров. Ассистент, ориентированный на поиск, рассматривает память и поиск как главное отличие. Ассистент, ориентированный на инструменты, ведет себя больше как оператор, чем как чат-бот. Ассистент шлюза приоритизирует постоянный доступ через поверхности сообщений. Специализированная сеть декомпозирует работу на нескольких агентов или маршруты. Официальная документация OpenAI, Anthropic, LlamaIndex, LiteLLM, OpenClaw и Hermes поддерживает версии этих паттернов, даже если они называют их по-разному.

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

Эта таблица паттернов является синтезом из документации провайдеров, документации фреймворков и референсных систем, а не утверждением какого-либо одного вендора.

Примечания к таблице: Размещенный поиск файлов OpenAI — это управляемый инструмент, Anthropic предлагает управляемую среду, Pinecone — управляемая векторная служба, в то время как vLLM, llama.cpp, Ollama, pgvector, Weaviate, Milvus, локальный LangSmith и OpenLIT поддерживают самостоятельное или гибридное управление в той или иной степени.

Примечания к таблице: Pinecone документирует управляемую контрольную плоскость и региональные плоскости данных. Weaviate документирует векторные и инвертированные индексы с несколькими типами векторных индексов. pgvector добавляет точный и приблизительный поиск ближайших соседей в Postgres. Milvus позиционирует себя как высокопроизводительную масштабируемую векторную базу данных с открытым исходным кодом, с Zilliz Cloud как управляемым вариантом.

Примечания к таблице: OpenAI документирует Responses как свой продвинутый интерфейс для состоятельных ответов и встроенных инструментов. Anthropic документирует API Messages и контракт использования инструментов отдельно от Managed Agents. vLLM предоставляет сервер, совместимый с OpenAI, плюс поддержку API Messages Anthropic. Ollama документирует локальные рабочие процессы эмбеддингов и моделей. llama.cpp документирует чат, ответы и маршруты эмбеддингов, совместимые с OpenAI, плюс чат-завершения, совместимые с Anthropic.

Эта матрица компромиссов является архитектурным выводом из официальной документации, а не бенчмарком вендора. Строка согласованности важнее, чем многие блоги признают: Pinecone разделяет пути записи и чтения, Hermes замораживает память в промпты начала сессии, а OpenClaw продвигает долговременную память через поэтапный обзор. Это означает, что «память обновлена» и «память видна текущему ответу» часто являются разными истинами.

Режимы отказа и смягчения

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

База доказательств для этой таблицы широка, но последовательна. Документация инструментов Anthropic ясно дает понять, что использование инструментов — это контрактная граница. Ограждения OpenAI включают обнаружение галлюцинаций по справочной базе знаний через Поиск файлов. SelfCheckGPT показывает, что само-согласованность по образцам может помочь обнаружить необоснованные утверждения. Результаты «Lost in the Middle» и руководство Anthropic по контексту оба усиливают тот же операционный урок: больше токенов не устраняют необходимость в кураторстве контекста.

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

Дополнительное чтение

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

• OpenAI: Обзор Responses, Вызов функций, Использование инструментов, Поиск, Поиск файлов, Оценки и MCP для удаленных серверов инструментов.

• Anthropic: Обзор API, Использование инструментов, контракт использования инструментов, Управляемые Агенты, Контекстные окна и коннектор MCP.

• Сам MCP: Обзор архитектуры и Спецификация заслуживают прямого чтения, потому что они чисто объясняют хосты, клиенты, серверы, инструменты, промпты, ресурсы, транспорты и переговоры о возможностях. Для практического сравнения MCP с протоколом Agent2Agent и когда многоагентная система нуждается в обоих слоях, см. A2A vs MCP: Действительно ли ИИ-агентам нужны оба протокола? и для самих концепций A2A — Карточки Агентов, жизненный цикл задач, сообщения, части и артефакты — см. Что такое протокол A2A? Объяснение Карточек Агентов и Задач.

• Фоновые и проактивные ассистенты: слой инструментов — это только часть того, как ассистенты действуют. Для того, как сделать ассистента, который наблюдает, решает и действует самостоятельно — планировщики, рабочие на основе очередей, протоколы претензий, долговременные рабочие процессы и семантическое опросы — см. Агенты опроса в ИИ-ассистентах: 11 паттернов реализации.

• Протокол A2A и принятие: когда агенты развернуты независимо и должны сотрудничать через границы владения, A2A становится актуальным. Для практического взгляда 2026 года на то, где A2A действительно имеет поддержку, вопросы безопасности, которые он вызывает, и рамки принятия решений о том, когда его применять, см. Протокол Google A2A в 2026 году: Принятие, Гипс и Реальность. Когда эти агенты обмениваются долгоживущими задачами, а не одиночными ходами чата, Потоковая передача A2A и асинхронные задачи для долгоживущих рабочих процессов агентов охватывает SSE, push и дизайн input_required на границе протокола.

• Фреймворки и маршрутизация: Обзор LangChain, документация LlamaIndex по дополнению контекста, документация LiteLLM по маршрутизации, документация LangSmith по наблюдаемости.

• Локальные среды выполнения и системы ассистентов: vLLM, сервер llama.cpp, эмбеддинги Ollama, документация и репозиторий OpenClaw, документация и репозиторий Hermes.

• Хранение и наблюдаемость: Pinecone, Weaviate, pgvector, Milvus, OpenTelemetry, OpenLIT.

• Исследовательские статьи: Генерация, дополненная поиском, для задач NLP, интенсивно использующих знания, Lost in the Middle и SelfCheckGPT.