ИИ-системы: самохостед-ассистенты, RAG и локальная инфраструктура

Содержимое страницы

Большинство локальных конфигураций ИИ начинаются с модели и среды выполнения.

Вы скачиваете квантованную модель, запускаете её через Ollama или другую среду выполнения и начинаете формировать запросы. Для экспериментов этого более чем достаточно. Но стоит выйти за рамки простого любопытства — когда вам начинают важны память, качество поиска релевантной информации, решения по маршрутизации или осознанность затрат, — как простота начинает демонстрировать свои ограничения.

Этот кластер статей исследует другой подход: рассматривание ИИ-ассистента не как единого вызова модели, а как скоординированной системы.

На первый взгляд это различие может показаться незначительным, но оно полностью меняет ваш подход к локальному ИИ.

Оркестрация систем ИИ с локальными LLM, RAG и слоями памяти

Что такое система ИИ?

Система ИИ — это больше, чем просто модель. Это слой оркестрации, связывающий инференс, поиск, память и выполнение в нечто, что ведет себя как связный ассистент.

Запуск модели локально — это работа с инфраструктурой. Проектирование ассистента вокруг этой модели — это системная работа.

Если вы уже изучали наши более общие руководства по темам:

вы уже знаете, что инференс — это лишь один слой стека.

Кластер систем ИИ находится поверх этих слоев. Он не заменяет их — он объединяет их.

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

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

Когда одного ассистента недостаточно и несколько агентов должны координировать свои действия, выбор паттерна координации определяет всё: задержки, отказоустойчивость, стоимость и отлаживаемость. Паттерны оркестрации мультиагентных систем: практическое руководство рассматривает шесть канонических паттернов — оркестратор-рабочий, последовательный конвейер, fan-out, иерархический, рой (swarm) и mesh — с конкретными режимами отказа и фреймворком для выбора правильной архитектуры.

OpenClaw: самодостаточная система ИИ-ассистента

OpenClaw — это open-source, self-hosted ИИ-ассистент, предназначенный для работы через мессенджеры при запуске на локальной инфраструктуре.

На практическом уровне он:

  • Использует локальные среды выполнения LLM, такие как Ollama или vLLM
  • Интегрирует поиск по индизированным документам
  • Поддерживает память за пределами одной сессии
  • Выполняет инструменты и задачи автоматизации
  • Поддерживает инструментирование и наблюдение
  • Работает в рамках аппаратных ограничений

Это не просто обертка над моделью. Это слой оркестрации, связывающий инференс, поиск, память и выполнение в нечто, что ведет себя как связный ассистент.

Быстрый старт и архитектура:

  • Быстрый старт с OpenClaw — установка на основе Docker с использованием либо локальной модели Ollama, либо облачной конфигурации Claude
  • Обзор системы OpenClaw — архитектурное исследование того, чем OpenClaw отличается от более простых локальных конфигураций
  • Гид по NemoClaw для безопасных операций с OpenClaw — безопасный путь работы с OpenClaw с песочницей OpenShell, уровнями политик, маршрутизируемым инференсом и эксплуатацией после развертывания

Контекст и анализ:

Расширение и конфигурация OpenClaw:

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

Hermes: персистентный агент с навыками и песочницей инструментов

Hermes Agent — это self-hosted, независимый от модели ассистент, сфокусированный на персистентной работе: он может работать как долгоживущий процесс, выполнять инструменты через конфигурируемые бэкенды и со временем улучшать рабочие процессы через память и переиспользуемые навыки.

На практическом уровне Hermes полезен, если вы хотите:

  • Терминально-ориентированный ассистент, который также может мостить в мессенджеры
  • Гибкость провайдеров через OpenAI-совместимые конечные точки и переключение моделей
  • Границы выполнения инструментов через локальные и песочные бэкенды
  • Эксплуатацию “второго дня” с диагностикой, журналами и гигиеной конфигурации

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

Персистентные знания и память

Некоторые проблемы не решаются только увеличением окна контекста — им нужны персистентные знания (графы, конвейеры приёма) и плагины памяти агентов (Honcho, Mem0, Hindsight и подобные бэкенды), интегрированные в ассистенты, такие как Hermes или OpenClaw.

MCP: Серверы протокола контекста модели

Протокол контекста модели (MCP) — это открытый стандарт, введенный Anthropic для подключения моделей языковых моделей ИИ к внешним источникам данных, инструментам и системам. Он решает проблему интеграции N×M, предоставляя универсальный интерфейс — представьте его как порт USB-C для приложений ИИ. Создание серверов MCP позволяет расширять ИИ-ассистенты с помощью кастомных интеграций для файлов, баз данных, API и вызываемых инструментов, используя простой протокол на основе JSON-RPC через stdio или HTTP.

  • Навыки агентов против серверов MCP: фреймворк принятия решений — практический фреймворк для определения, когда использовать навыки, когда строить серверы MCP, и как паттерн тонкого сервера объединяет оба подхода
  • Сервер MCP на Go — архитектура протокола, структура сообщений JSON-RPC, согласование возможностей, официальный Go SDK и пошаговое руководство по строительству серверов MCP на Go
  • Создание серверов MCP на Python — практическое руководство по реализации на Python, охватывающее серверы MCP для веб-поиска и скрапинга, транспортные механизмы stdio и SSE, а также интеграцию с Claude Desktop

A2A: Протокол взаимодействия агентов

Протокол Agent2Agent (A2A) — это открытый стандарт для связи между независимо развёрнутыми системами ИИ-агентов. Если MCP подключает агента к инструментам, то A2A подключает агентов к другим агентам — позволяя им обнаруживать друг друга через Карточки Агентов, обмениваться задачами и сообщениями, стримить прогресс и возвращать типизированные артефакты. A2A предназначен для систем, где агенты принадлежат разным командам, созданы с разными фреймворками или развёрнуты как отдельные сервисы, которым нужна интероперабельность.

Чем системы ИИ отличаются

Несколько характеристик делают системы ИИ достойными более пристального внимания.

Маршрутизация моделей как выбор дизайна

Большинство локальных конфигураций по умолчанию используют одну модель. Системы ИИ поддерживают осознанный выбор моделей.

Это вводит следующие вопросы:

  • Должны ли небольшие запросы использовать более маленькие модели?
  • Когда обоснованность рассуждений оправдывает более большое окно контекста?
  • Какова разница в стоимости на 1000 токенов?

Эти вопросы напрямую связаны с компромиссами производительности, обсуждаемыми в руководстве по производительности LLM, и решениями по инфраструктуре, изложенными в руководстве по размещению LLM.

Системы ИИ выносят эти решения на поверхность, а не скрывают их.

Поиск рассматривается как развивающийся компонент

Системы ИИ интегрируют поиск по документам, но не как примитивный шаг “встроить и искать”.

Они признают:

  • Размер чанка влияет на полноту извлечения и стоимость
  • Гибридный поиск (BM25 + векторный) может превосходить чисто плотный поиск
  • Переранжирование улучшает релевантность ценой задержки
  • Стратегия индексирования влияет на потребление памяти

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

Разница в том, что системы ИИ встраивают поиск в живой ассистент, а не представляют его как изолированную демонстрацию.

Память как инфраструктура

Бессоостоятельные LLM забывают всё между сессиями.

Системы ИИ вводят персистентные слои памяти. Это сразу же вызывает вопросы дизайна:

  • Что следует хранить долгосрочно?
  • Когда контекст следует суммировать?
  • Как предотвратить взрыв количества токенов?
  • Как эффективно индексировать память?

Эти вопросы непосредственно пересекаются с соображениями по слою данных из руководства по инфраструктуре данных. Для Hermes Agent в частности — ограниченная двухфайловая память, префиксное кэширование, внешние плагины — начните с Система памяти Hermes Agent и межфреймворкового сравнения Сравнение провайдеров памяти для агентов. Хаб памяти систем ИИ перечисляет связанные руководства по Cognee и слою знаний.

Память перестает быть функцией и становится проблемой хранения.

Наблюдаемость не является опциональной

Большинство локальных экспериментов с ИИ останавливаются на этапе “он отвечает”.

Системы ИИ позволяют наблюдать:

  • Использование токенов
  • Задержки
  • Использование аппаратных ресурсов
  • Паттерны пропускной способности

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

Если ИИ работает на железе, он должен быть измерим, как любая другая нагрузка.

Как это ощущается в использовании

Со стороны система ИИ может по-прежнему выглядеть как интерфейс чата.

Под поверхностью происходит больше.

Если вы попросите его суммировать технический отчет, хранящийся локально:

  1. Он извлекает соответствующие сегменты документа.
  2. Он выбирает подходящую модель.
  3. Он генерирует ответ.
  4. Он записывает использование токенов и задержки.
  5. Он обновляет персистентную память, если необходимо.

Видимое взаимодействие остается простым. Поведение системы многоуровневое.

Именно это многоуровневое поведение отличает систему от демонстрации.

Где системы ИИ находятся в стеке

Кластер систем ИИ находится на пересечении нескольких слоев инфраструктуры:

  • Размещение LLM: Слой среды выполнения, где выполняются модели (Ollama, vLLM, llama.cpp)
  • RAG: Слой поиска, который предоставляет контекст и заземление
  • Производительность: Слой измерения, который отслеживает задержки и пропускную способность
  • Наблюдаемость: Слой мониторинга, который предоставляет метрики и отслеживание затрат
  • Инфраструктура данных: Слой хранения, который обрабатывает память и индексацию

Понимание этого различия полезно. Запуск этого самостоятельно делает разницу еще яснее.

Для минимальной локальной установки с OpenClaw см. Быстрый старт с OpenClaw, который шаг за шагом проводит через настройку на основе Docker с использованием либо локальной модели Ollama, либо облачной конфигурации Claude.

Если ваша конфигурация зависит от Claude, это изменение политики для инструментов агентов проясняет, почему теперь требуется тарификация API для сторонних рабочих процессов OpenClaw.

Связанные ресурсы

A2A: Протокол взаимодействия агентов:

Серверы MCP:

Руководства по ИИ-ассистентам:

Слои инфраструктуры:

Подписаться

Получайте новые материалы про системы, инфраструктуру и AI engineering.