Системы ИИ: самостоятельно размещаемые ассистенты, RAG и локальная инфраструктура

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

OpenClaw: Самохостинговая система ИИ-ассистента

OpenClaw — это система ИИ-ассистента с открытым исходным кодом, предназначенная для работы на собственных серверах и функционирующая через платформы обмена сообщениями, используя локальную инфраструктуру.

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

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

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

Начало работы и архитектура:

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

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

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

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

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

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

  • Ассистент, ориентированный на терминал, который также может интегрироваться с приложениями для обмена сообщениями
  • Гибкость провайдеров через конечные точки, совместимые с OpenAI, и переключение моделей
  • Границы выполнения инструментов через локальные и изолированные (песочные) бэкенды
  • Операции второго дня с диагностикой, журналами и гигиеной конфигурации

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

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

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

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

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

  • Сервер 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 + векторный) может превзойти чистый плотный поиск
  • Переоценка (reranking) улучшает релевантность ценой задержки
  • Стратегия индексирования влияет на потребление памяти

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Серверы MCP:

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

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

Подписаться

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