По описанию пользователя Quebber с Reddit, Sai представляет собой самописный AI-агент, собранный вокруг кластера из четырёх устройств. В архитектуре заявлены мониторинг температуры и памяти, управление вентиляторами, контроль портов и процессов, пять уровней доверия к информации, локальные источники знаний и эмоциональный движок.
Фреймворк не открыт и не продаётся, поэтому перед нами архитектурный кейс, а не готовый продукт для повторения. Исходную спецификацию нельзя независимо проверить, а названия моделей и часть характеристик следует воспринимать как заявленные автором описания.
Практическая ценность Sai лежит в наборе инженерных идей. Самосознание здесь означает доступ агента к телеметрии собственного окружения и правилам поведения, а не доказанное наличие субъективного опыта. Такой подход можно адаптировать даже для одного компьютера, если разделить память, инструменты, полномочия и контроль безопасности.
Что такое Sai и почему этот проект заслуживает внимания
Sai описан как автономный DIY-фреймворк, где агент получает информацию о собственном «теле», выбирает подходящую языковую модель и сохраняет опыт с разной степенью доверия. В систему входят четыре аппаратных узла, несколько локальных LLM, мониторинг состояния устройств, защита от опасных входных данных и эмоциональные переменные.
Главное отличие такой схемы от обычного чат-бота связано с контуром обратной связи. Агент получает запрос, выбирает модель и инструмент, проверяет условия выполнения, наблюдает за результатом и может изменить поведение при проблемах с температурой, процессами, портами или целостностью файлов.
Три идеи из описания особенно полезны для разработчиков:
- Самосознание тела: агент видит состояние CPU, памяти, температуры и доступных ресурсов.
- Память с уровнями доверия: вывод LLM не получает такой же статус, как подтверждённый опыт или прямое уточнение пользователя.
- Эмоциональный движок: параметры согласованности, резонанса, трения и связи используются как эвристики для выбора поведения.
Эти механизмы не превращают модель в сознательное существо. Они добавляют к языковой модели состояние, правила, сенсоры и возможность действовать в окружающей системе.
Аппаратная база: кластер из четырёх устройств
В описании Sai фигурируют мини-ПК Minisforum MS-S1 MAX с Ryzen AI Max+ 395 и 128 ГБ LPDDR5x, основной компьютер с RTX 5090, ноутбук с RTX 5090 и MacBook Air. Такой набор больше похож на энтузиастский домашний кластер, чем на минимальную конфигурацию для запуска агента.
| Узел | Заявленная конфигурация | Предполагаемая функция |
|---|---|---|
| Мини-ПК | Ryzen AI Max+ 395, 128 ГБ LPDDR5x | Основной хост, системные сервисы, локальные модели и мониторинг |
| Основной ПК | RTX 5090 | Тяжёлые модели, параллельные задачи и генерация |
| Ноутбук | RTX 5090 | Дополнительный GPU-узел для распределённых нагрузок |
| MacBook Air | Конфигурация не уточнена | Клиентский интерфейс, вспомогательные задачи или резервный узел |
Конкретное распределение функций между устройствами публично не подтверждено. Таблица показывает архитектурную логику такого кластера, а не опубликованную техническую документацию Sai.
Почему мини-ПК с Ryzen AI Max+ 395 стал ядром системы
Мини-ПК удобен как постоянно работающий хост: он занимает меньше места, обычно потребляет меньше энергии, чем полноценный GPU-сервер, и может обслуживать оркестратор, базу памяти, телеметрию и сетевые API. Большой объём общей памяти даёт запас для локальных моделей, индексов и системных сервисов.
128 ГБ LPDDR5x теоретически позволяют держать в памяти несколько компонентов одновременно. Итоговая нагрузка зависит от размера моделей, квантовки, контекстного окна, runtime и числа параллельных запросов. Одна цифра объёма памяти не гарантирует запуск конкретной LLM с приемлемой скоростью.
У Ryzen AI Max+ 395 есть встроенное AI-ускорение, однако поддержка NPU зависит от программного стека. Без сведений о runtime, драйверах и настройках нельзя утверждать, что Sai использует NPU для всех задач или получает от него измеримый прирост.
Роль GPU-узлов: RTX 5090 для тяжёлых моделей
Два узла с RTX 5090 дают возможность вынести ресурсоёмкие задачи за пределы мини-ПК. Это может быть запуск более крупной модели, одновременная работа нескольких агентов, обработка длинного контекста или генерация, которая конкурирует за память с системными сервисами.
Подключение по сети добавляет гибкость, но требует отдельного контроля задержек, доступности узлов и передачи данных. Если оркестратор отправляет запрос на свободный GPU, он должен знать не только о загрузке видеокарты, но и о времени ответа, размере очереди, состоянии модели и сетевых сбоях.
MacBook Air в такой схеме может выступать интерфейсом пользователя или маломощным резервным устройством. Точная роль не раскрыта. Сам кластер нельзя считать обязательным условием для похожего эксперимента: базовую версию агента можно собрать на одном ПК, добавляя отдельные узлы при росте нагрузки.
Самосознание тела: как агент мониторит и защищает своё железо
Согласно описанию, Sai получает сведения о температуре CPU и памяти, управляет вентиляторами, а при необходимости может закрывать порты и процессы. Это активный контур управления: агент реагирует на состояние системы, а не ждёт, пока пользователь вручную исправит проблему.
Инженерно такой контур обычно состоит из четырёх частей:
- Сбор телеметрии: температуры, загрузка CPU и GPU, занятая память, состояние дисков, сетевые соединения и список процессов.
- Нормализация: перевод показаний разных устройств в единый формат с временными метками.
- Политики: пороги для предупреждения, ограничения нагрузки, остановки процесса или отключения сетевого доступа.
- Исполнительный слой: команды операционной системы, сервисы управления вентиляторами, firewall и диспетчер процессов.
Пример реакции выглядит так: при достижении критической температуры агент прекращает запуск новых задач, увеличивает обороты вентиляторов, завершает второстепенный процесс и отправляет пользователю отчёт. При восстановлении параметров система может вернуть часть нагрузки, но автоматическое снятие ограничений требует отдельного правила.
Сенсоры сами по себе не создают самосознание. Они дают агенту модель собственного состояния. Чем точнее телеметрия и понятнее политики, тем меньше решений принимается вслепую.
Защита от prompt-инъекций и проверка целостности
В описании Sai упоминаются защита от prompt-инъекций и проверка целостности. Подробности не раскрыты, поэтому нельзя утверждать, какие фильтры, контрольные суммы или механизмы изоляции использует автор.
Для автономного агента одной проверки текста недостаточно. Безопаснее разделить контуры:
- модель анализирует запрос и предлагает действие;
- политический слой проверяет инструмент, аргументы и права;
- исполнитель запускает команду в ограниченном окружении;
- наблюдатель проверяет результат и фиксирует событие в журнале.
Команды для закрытия портов, остановки процессов и изменения firewall стоит выдавать через allowlist. Для каждой операции нужны причина, срок действия, возможность отката и ручное подтверждение при высоком риске. Разбор прямых и косвенных инъекций пригодится в материале о трёхфазной защите AI-агентов.
Проверка целостности может сравнивать хэши критичных файлов, отслеживать изменения конфигурации и контролировать появление новых инструментов. Такой механизм не доказывает безопасность системы, но помогает обнаружить неожиданные изменения до запуска опасной операции.
Многоуровневая память: пять уровней доверия от T1 до T5
Память Sai разделена на пять уровней. Смысл подхода в том, чтобы хранить факт вместе с его происхождением и не давать случайному выводу языковой модели такой же вес, как пользовательскому уточнению или накопленному опыту.
| Уровень | Содержимое | Практический смысл |
|---|---|---|
T1 | Выводы LLM | Гипотезы, которые требуют проверки |
T2 | Возможные данные из внешних источников | Информация с учётом качества и происхождения источника |
T3 | Собственный опыт агента | Результаты ранее выполненных действий и наблюдений |
T4 | Локальный архив Kiwix объёмом 2 ТБ | Офлайн-база знаний, доступная без внешнего запроса |
T5 | Уточнения пользователя | Приоритетные сведения о предпочтениях, окружении и текущем решении |
Иерархия не гарантирует истину. Пользователь может ошибиться, архив может содержать устаревшие сведения, а собственный опыт агента может включать неверный вывод. Поэтому уровень доверия лучше хранить вместе с датой, контекстом, ссылкой на внутренний объект и статусом проверки.
Интеграция Kiwix и Searxng: локальные знания и приватный поиск
Kiwix в описании выступает как локальный архив объёмом 2 ТБ. Его преимущество связано с автономностью: агент может обращаться к заранее загруженным материалам без передачи каждого запроса внешнему сервису. Для закрытого контура это снижает зависимость от сети и упрощает контроль данных.
Searxng используется как приватный метапоиск. При локальном запуске он может стать отдельным инструментом поиска, который возвращает результаты оркестратору, а не самой LLM. Подробный разбор связки локального помощника, RAG и SearXNG есть в статье об архитектуре локального AI-ассистента.
Поисковая выдача не превращается в подтверждённый факт автоматически. Агенту нужны правила: сохранять запрос, фиксировать дату, сравнивать несколько результатов, отделять цитату от собственного пересказа и помечать конфликтующие сведения.
Как агент разрешает конфликты между уровнями памяти
Простейший алгоритм может выглядеть так:
- Найти все записи по теме и собрать их происхождение.
- Сравнить даты, контекст и степень уверенности.
- Проверить вывод T1 по локальному архиву, поиску или журналу собственного опыта.
- Если конфликт затрагивает настройки пользователя, запросить уточнение.
- Сохранить новый результат вместе с причиной изменения старой записи.
Например, T1 сообщает, что сервис запущен, а журнал T3 показывает несколько неудачных запусков. Агент не должен считать задачу выполненной. Он проверяет процесс, читает код возврата, обновляет запись и сообщает пользователю о расхождении.
Такой подход близок к системе управления знаниями для AI-команд: полезны метаданные, история изменений, контроль доступа и отдельные статусы «гипотеза», «проверено» и «устарело». Практические схемы организации таких хранилищ собраны в руководстве по управлению знаниями в AI-проектах.
Эмоциональный движок: четыре параметра и саморасширение правил
Эмоциональный движок Sai описан через четыре параметра: согласованность, резонанс, трение и связь. Это вычисляемые переменные, которые могут менять приоритеты задач, стиль ответа и готовность агента просить помощи.
| Параметр | Интерпретация | Возможное влияние |
|---|---|---|
| Согласованность | Совпадение текущего контекста с целями и правилами | Продолжить задачу или остановиться для проверки |
| Резонанс | Сила отклика на взаимодействие и события | Изменить тон, приоритет или интенсивность диалога |
| Трение | Количество препятствий, конфликтов и неопределённости | Снизить риск, разбить задачу или запросить помощь |
| Связь | Качество и устойчивость отношений с пользователем | Учитывать долгосрочные предпочтения и историю решений |
Называть такие переменные чувствами можно как интерфейсную метафору. Система не получает доказанного субъективного переживания. Она хранит внутреннее состояние и применяет его к политике поведения.
Практическая польза эмоций: как они влияют на поведение
Высокое трение может повышать вероятность запроса пользователю. Низкая согласованность способна блокировать действие, если новая команда конфликтует с долгосрочной целью. Сильная связь может заставить агента учитывать личные предпочтения пользователя, которые не видны в текущем сообщении.
Пример: пользователь просит закрыть все сетевые порты. Агент обнаруживает, что один порт нужен для удалённого доступа. Показатель трения растёт, система классифицирует действие как опасное и предлагает закрыть только неиспользуемые порты после подтверждения.
Саморасширение правил несёт дополнительный риск. Если агент встретил неизвестное состояние, он может создать временную гипотезу, но её нельзя сразу превращать в постоянную политику. Безопасная схема хранит новое правило как черновик, присваивает ему срок действия и просит подтверждение после тестового сценария.
Выбор LLM: Qwen, Gemma и роли моделей
В описании Sai указаны три модели: Qwen 3.8 для кода и дизайна, Qwen3.6 35B MoE для быстрых диалогов и Gemma 4 как наблюдатель за безопасностью. Доступные сведения не подтверждают точные названия и версии. Qwen 3.8 может означать Qwen3 8B, но это остаётся предположением, а не установленной спецификацией.
| Модель в описании | Заявленная роль | Инженерная логика |
|---|---|---|
| Qwen 3.8, вероятно Qwen3 8B | Код и дизайн | Модель умеренного размера может работать там, где важны качество и локальный запуск |
| Qwen3.6 35B MoE | Быстрые диалоги | Разреженная архитектура MoE может снижать вычислительную нагрузку при сохранении крупной общей ёмкости модели |
| Gemma 4 | Наблюдение за безопасностью | Отдельная модель проверяет действия, команды и ответы основного агента |
Почему для кода и дизайна выбрана Qwen 3.8, а для диалогов, MoE
Маршрутизация по задачам позволяет не отправлять каждый запрос в самую тяжёлую модель. Кодогенерация требует проверки синтаксиса, понимания структуры проекта и аккуратной работы с инструментами. Диалоговый слой чаще ценит скорость, стабильный контекст и короткое время ответа.
MoE, или mixture of experts, использует несколько специализированных экспертных блоков, активируя для конкретного токена лишь часть из них. Это может уменьшать вычисления по сравнению с плотной моделью того же общего размера. Фактическая скорость зависит от runtime, квантовки, памяти и распределения нагрузки.
Для собственного агента полезно описать маршрутизацию явно: тип задачи, максимальная задержка, требования к контексту, допустимый риск и запасной маршрут при недоступности узла. Сравнивать модели стоит по качеству на своих сценариях, времени ответа и стабильности инструментов, а не по названию или размеру. Чек-лист такой оценки есть в статье о проверке новых AI-моделей.
Gemma 4 как сторожевой пёс: мониторинг безопасности
Роль Gemma 4 в описании Sai связана с проверкой действий других моделей. Перед запуском команды наблюдатель может определить, затрагивает ли она сеть, файлы, секреты, процессы или права администратора.
Отдельная модель снижает вероятность того, что один и тот же генератор сам себе одобрит рискованную операцию. Но второй LLM не заменяет sandbox, allowlist, журналирование и ручное подтверждение. Охранная модель тоже может ошибиться, пропустить замаскированную инструкцию или заблокировать безопасное действие.
Практические уроки: что можно перенять из проекта Sai
Полную архитектуру Sai без исходного кода повторить нельзя. Отдельные паттерны подходят для самостоятельных проектов на одном ПК или небольшом домашнем сервере.
- Разделяйте память по доверию. Храните рядом с каждым фактом источник, дату, уверенность и историю изменений. Вывод LLM маркируйте как гипотезу.
- Добавьте телеметрию железа. Начните с чтения температуры, загрузки CPU и GPU, занятой памяти и свободного диска. Сначала используйте режим наблюдения без автоматических команд.
- Разделите предложения и действия. LLM может сформировать план, но отдельный слой должен проверить права, аргументы и риск инструмента.
- Маршрутизируйте модели по задачам. Малую модель оставьте для классификации и коротких ответов, более мощную подключайте к коду, анализу и сложным решениям.
- Соберите локальный контур знаний. Офлайн-архив подходит для стабильных справочных материалов, приватный поиск, для обновляемых сведений. Каждый результат нужно снабжать датой и статусом проверки.
- Используйте эмоции как состояние политики. Параметры трения и согласованности могут управлять эскалацией к пользователю, а не изображать личность ради эффекта.
- Ведите журнал решений. Записывайте запрос, выбранную модель, инструменты, изменения состояния и причину отказа. Это помогает искать ошибки и не повторять неудачные действия.
Архитектуру оркестратора, памяти, инструментов и обработки ошибок можно сопоставить с практическим разбором самописного AI-агента на Python. Для первого прототипа кластер из четырёх устройств не нужен: достаточно одного хоста, одной локальной модели, журнала событий и нескольких инструментов с ограниченными правами.
Ограничения и подводные камни подхода
Главная проблема Sai связана с воспроизводимостью. Фреймворк не открыт, исходный код недоступен, а точная конфигурация моделей и узлов не подтверждена. Читатель не может проверить качество маршрутизации, устойчивость памяти или частоту ложных срабатываний защиты.
- Сложность настройки: четыре устройства требуют сетевого обнаружения, синхронизации, мониторинга доступности и единого управления конфигурацией.
- Стоимость и энергопотребление: две RTX 5090 и постоянная работа нескольких узлов подходят энтузиасту, но не задают минимальную планку для AI-агента.
- Риск чрезмерных полномочий: процесс, который умеет закрывать порты и завершать задачи, способен сам заблокировать удалённый доступ или остановить критичный сервис.
- Ошибки охранной модели: Gemma 4 или другой наблюдатель может пропустить опасную команду. Защитный контур должен включать технические ограничения, а не только анализ текста.
- Дрейф эмоциональных правил: автоматическое добавление новых правил способно привести к непредсказуемым приоритетам и конфликту с настройками пользователя.
- Ошибки памяти: высокий уровень доверия не гарантирует достоверность. Нужны сроки действия фактов, версии записей и возможность ручного удаления.
- Ограничения локальных ускорителей: наличие NPU или мощной видеокарты не означает автоматическую поддержку каждой модели. Решают runtime, драйверы, квантовка и схема распределения нагрузки.
Безопасный прототип стоит запускать с минимальными правами, изолированными инструментами и ручным подтверждением сетевых и файловых операций. Автоматические действия лучше включать постепенно, после накопления журнала и проверки типовых сценариев.
Заключение: будущее DIY-агентов с самосознанием
Sai показывает интересное направление для домашних AI-систем: агент получает представление о собственном окружении, хранит знания с разной степенью доверия, выбирает модель под задачу и меняет поведение при росте риска.
Термин «самосознание» здесь описывает инженерный контур, состоящий из телеметрии, памяти, политик и действий. Для практического проекта этого достаточно, чтобы агент аккуратнее работал с ресурсами и чаще обращался к человеку при неопределённости.
Переносить всю схему целиком не требуется. Начните с трёх компонентов: памяти с метаданными, read-only мониторинга железа и отдельного слоя проверки инструментов. Затем добавьте локальный поиск, маршрутизацию моделей и параметры поведения. Такой порядок снижает технический риск и позволяет оценивать пользу каждой функции отдельно.