Архитектура ИИ-ассистента: 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, в то время как Managed Agents предоставляет вам размещенный каркас, если вы не хотите строить цикл самостоятельно. Автономные среды выполнения, такие как 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. Если у вашего ассистента нет трассировки для каждого запроса, спана для каждого вызова модели и истории событий для выполнения инструментов, у вас еще нет архитектуры. У вас есть «вайб».

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

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

sequenceDiagram
    participant U as Пользователь или Канал
    participant G as Шлюз или UI
    participant R as Маршрутизатор
    participant M as Память и Поиск
    participant L as LLM
    participant T as Инструменты или MCP
    participant O as Наблюдаемость

    U->>G: сообщение, файл или команда
    G->>O: начать корневую трассировку
    G->>R: запрос + идентификатор + сеанс + политика
    R->>M: загрузить состояние сеанса и получить контекст
    M-->>R: заметки, фрагменты, метаданные
    R->>L: промпт + контекст + схемы инструментов
    L-->>R: ответ или вызов инструмента
    alt вызов инструмента
        R->>T: выполнить инструмент или действие MCP
        T-->>R: результат инструмента
        R->>L: результат инструмента + обновленный контекст
        L-->>R: окончательный ответ
    end
    R->>M: сохранить изменения сеанса и кандидатов в память
    R->>O: спаны, метрики, события оценок
    G-->>U: ответ

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

Шаг обогащения — это место, где зрелые системы расходятся с демонстрационными роликами. Поиск и поиск файлов 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 Guardrails включает обнаружение галлюцинаций против справочной базы знаний через поиск файлов. SelfCheckGPT показывает, что само-согласованность между выборками может помочь обнаружить необоснованные утверждения. Результаты «Lost in the Middle» и рекомендации Anthropic по контексту оба усиливают тот же операционный урок: больше токенов не устраняют необходимость в кураторстве контекста.

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

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

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

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

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

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

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

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

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

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