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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

OpenClaw: self-hosted система ИИ-ассистента

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

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

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

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

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

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

Расширение и конфигурирование 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, согласование возможностей, официальный SDK Go и пошаговое руководство по построению серверов MCP на Go
  • Создание серверов MCP на Python — практическое руководство по реализации на Python, охватывающее серверы MCP для веб-поиска и скрейпинга, транспорт stdio и SSE, а также интеграцию с Claude Desktop

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

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

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

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

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

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

Это вводит вопросы:

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

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

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

Извлечение информации рассматривается как развивающийся компонент

Системы ИИ интегрируют извлечение информации из документов, но не как примитивный шаг «векторизация и поиск».

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

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

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

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

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

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

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

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

Эти вопросы пересекаются с соображениями на уровне данных из руководства по инфраструктуре данных. Для агента Hermes в частности — ограниченная двухфайловая память, префиксное кеширование, внешние плагины — начните с Системы памяти агента Hermes и межокодрового сравнения Сравнение провайдеров памяти агентов. Автоматический захват и рефлексия также могут превращать собственный вывод модели в будущие «доказательства» — см. Саморепродуцирующиеся циклы памяти в ИИ-агентах для режима отказа и Mnemosyne для агента Hermes для консервативной локальной реализации. В хабе памяти систем ИИ перечислены связанные руководства по Cognee и слоям знаний.

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

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

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

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

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

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

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

Каково это — использовать

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

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

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

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

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

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

Где системы ИИ занимают место в стеке

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

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

Понимание этого различия полезно. Самостоятельный запуск делает разницу более ясной.

Для минимальной локальной установки с OpenClaw см. [быстрое руководство по OpenClaw](https://www.glukhov.org/ru/ai-systems/openclaw/quickstart/, которое описывает настройку на основе Docker с использованием либо локальной модели Ollama, либо облачной конфигурации Claude.

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

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

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

Серверы MCP:

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

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

Подписаться

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