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

Промышленный ИИ-ассистент — это не «LLM с промптом». Это система, которая принимает намерение, сохраняет состояние, принимает решения о поиске или выполнении действий и предоставляет достаточно информации о времени выполнения для отладки сбоев.

Именно этот системный взгляд исследует Клuster ИИ-систем в тех случаях, когда ассистенты выходят за рамки единого вызова модели.

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

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

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

Использование инструментов — это граница контракта, а не магия. OpenAI function calling, Anthropic tool use и MCP опираются на одну и ту же схему: модель выпускает структурированный запрос, какое-то время выполнения (runtime) выполняет его, а результат возвращается в разговор. Если эта граница нечеткая, ассистент становится неуклюжим.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

edge:
  gateway: hermes или openclaw

routing:
  proxy: litellm
  policy: осведомленная о задержке и бюджете
  tenancy: ограниченная сеансом и каналом

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

memory:
  session: sqlite или postgres
  semantic: pgvector или weaviate
  embeddings: openai embeddings или ollama embeddings

tools:
  contract: инструменты json schema плюс mcp
  examples: файловая система, браузер, веб-поиск, внутренние API

observability:
  traces: opentelemetry
  ai_dashboards: openlit или langsmith
  evals: openai evals плюс специфичные для приложения наборы регрессии

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

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

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

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

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

Примечания к таблице: OpenAI hosted File Search — это управляемый инструмент, Anthropic предлагает управляемый каркас, Pinecone — это управляемый векторный сервис, в то время как vLLM, llama.cpp, Ollama, pgvector, Weaviate, Milvus, LangSmith self-hosted и OpenLIT все поддерживают self-managed или гибридную работу в различных степенях.

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

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

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

Режимы сбоя и смягчения

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

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

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

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

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

• OpenAI: Responses Overview, Function Calling, Using Tools, Retrieval, File Search, Evals и MCP для удаленных серверов инструментов.

• Anthropic: API Overview, Tool Use, контракт использования инструментов, Managed Agents, Context Windows и коннектор MCP.

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

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

• Полномочия принятия решений: о том, какие решения модель должна принимать, рекомендовать или только информировать — пять ролей решений, маршрутизация на основе доверия к наименьшему компетентному уровню и шлюзы согласования, sized по blast radius — см. Решающие LLM: Когда модель должна решать — и когда не должна.

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

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

• Self-hosted среды выполнения и системы ассистентов: vLLM, сервер llama.cpp, встраивания Ollama, документы и репозиторий OpenClaw, документы и репозиторий Hermes.

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

• Исследовательские статьи: Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, Lost in the Middle и SelfCheckGPT.