Как установить Agentlas OS на Linux VPS

Что на самом деле представляет собой Agentlas OS

Agentlas OS — это среда выполнения агентов с открытым исходным кодом. Она хранит специализированных агентов на диске в виде пакетов и создаёт временный оркестратор для каждой задачи. Вы самостоятельно размещаете её, устанавливая в собственную учётную запись пользователя на Linux VPS. Это не сервис. Здесь нет демона, порта, принимающего соединения, веб-интерфейса и образа контейнера в репозитории.

Последнее утверждение определяет всё остальное на этой странице. Большинство мультиагентных систем запускают процесс супервизора, который постоянно работает и хранит агентов. Agentlas использует обратный подход: специализированные агенты хранятся в виде файлов, а оркестратор существует только во время выполнения задачи. На практике это означает, что бездействующий узел использует место на диске, но не память.

Проект называет своё открытое ядро Hephaestus. Именно это имя вы увидите в командах, путях и переменных окружения. Репозиторий находится в agentlas-ai/Agentlas-OS, распространяется по лицензии Apache-2.0 и написан преимущественно на Python.

Насколько проект действительно молодой

Репозиторий создан 4 June 2026. По состоянию на 13 October 2026 ему около четырёх месяцев. При этом у него примерно 1,580 звёзд и 110 форков. Для инструмента, которому вы поручаете реальные задачи, это очень ранняя стадия.

Частота выпусков важнее возраста проекта. Версия v1.1.103 опубликована 8 August 2026, а v1.2.0 выпущена 12 August 2026. В ветке 1.1 было опубликовано более ста помеченных выпусков. В некоторые дни выходило по несколько выпусков, опубликованных средствами автоматизации. Ветка 1.2 сохранила такой темп: к 10 October 2026 она достигла версии v1.2.62. Проект, который развивается с такой скоростью, может изменить поведение между вторником и четвергом.

Поэтому зафиксируйте версию выпуска. Установщик поддерживает для этого переменную окружения, и во всём руководстве ниже используется именно она. Если не зафиксировать версию проекта, выпуски которого выходят так часто, установщик может выбрать последний выпуск, помеченный на момент последнего редактирования скрипта.

Что потребуется на VPS

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

• Linux VPS. Ubuntu 24.04 подходит в качестве базового варианта. Установщик определяет операционную систему с помощью uname -s и для Linux выбирает ветку, отличную от macOS, поэтому поддерживается сервер без графического интерфейса.
• curl, tar и git на сервере, а также Python 3.9 или новее. Текущий установщик использует его для проверки архива релиза.
• Исходящие HTTPS-соединения к raw.githubusercontent.com и github.com для обычной установки. Установщик скачивает архив релиза и проверяет его SHA-256. Сервер без исходящего доступа всё равно можно установить из дерева исходного кода, которое вы скопировали самостоятельно: укажите его в HEPHAESTUS_SOURCE_DIR, и скрипт пропустит скачивание, поскольку требование curl применяется только к установке из удалённого релиза.
• Хост-обвязка — агент программирования, который непосредственно взаимодействует с моделью. Поддерживаются адаптеры Claude Code, Codex, opencode, goose и Hermes.

Права root не требуются. Установщик записывает файлы только в вашем домашнем каталоге, включая ~/.local/bin. Если какой-либо шаг завершается ошибкой, например путь недоступен для записи, установщик выводит предупреждение и продолжает остальные шаги, а в конце завершается с ненулевым кодом, если произошла хотя бы одна ошибка. Если вы ещё выбираете сам сервер, в разделе запуск агента программирования на VPS описаны базовый образ и настройка доступа, на которые опирается эта установка.

Установите зафиксированный релиз

В README upstream-проекта приведена одна команда, которая передаёт скрипт из main напрямую в bash. Сначала скачайте этот скрипт и прочитайте его. Он записывает данные в конфигурацию оболочки и во все найденные harness-файлы агентов, поэтому стоит потратить на проверку десять секунд.

curl -fsSL -o install-all-runtimes.sh \
  https://raw.githubusercontent.com/agentlas-ai/Agentlas-OS/main/scripts/install-all-runtimes.sh
less install-all-runtimes.sh
HEPHAESTUS_REF=v1.2.0 bash install-all-runtimes.sh

HEPHAESTUS_REF — это переменная, задающая версию. В скрипте на main теперь указано version="${HEPHAESTUS_REF:-v1.2.62}", а v1.2.62 опубликован 10 October 2026. Если переменную не задать, больше не будет устанавливаться v1.2.0: версия по умолчанию будет меняться с каждым тегом. Задайте её явно. Тогда повторная сборка через несколько месяцев установит именно протестированную версию.

Есть важное ограничение: URL скрипта выше отслеживает main, а HEPHAESTUS_REF фиксирует версию runtime payload, который скачивает скрипт. Это разные компоненты. Чтобы зафиксировать оба, скачайте скрипт из тега, а не из main. Для этого замените main на v1.2.0 в URL.

Фиксация версии распространяется на установку, но не на последующее поведение. В v1.2.0 и начиная с main команды hephaestus запускают фоновую проверку обновлений. Если доступен новый релиз, он устанавливается, а ~/.agentlas/runtime/current переназначается без запроса подтверждения. Во время собственного запуска установщик отключает это поведение с помощью HEPHAESTUS_AUTO_UPDATE=0. Эта же переменная позволяет сохранить зафиксированную версию. На следующем шаге она добавляется в профиль оболочки.

При успешном выполнении выводятся пути записанных файлов, включая следующие строки:

Installed runner: /home/you/.agentlas/runtime/current/bin/hephaestus
Installed shell commands in /home/you/.local/bin
  /home/you/.local/bin is not on your PATH yet. To use them by name:

Предупреждение о PATH — это строка, которую часто пропускают. В новой системе Ubuntu ~/.local/bin часто отсутствует в PATH, поэтому каждая команда hep-* завершается ошибкой command not found, хотя установка выполнена успешно. Установщик добавляет путь в ~/.zshrc, но в Ubuntu оболочкой по умолчанию является bash. Исправьте это в bash, одновременно отключите фоновое обновление и проверьте результат:

echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc
echo 'export HEPHAESTUS_AUTO_UPDATE=0' >> ~/.bashrc
source ~/.bashrc
hep-global status

hep-global — это исходное написание hephaestus global, а status показывает, содержит ли каждый файл инструкций harness управляемый блок маршрутизатора. По умолчанию этот маршрутизатор отключён, поэтому ожидайте вывода none. Если команда вообще выполняется, значит, ваш PATH настроен правильно.

Где хранится состояние

Все данные находятся в домашнем каталоге. Поэтому резервное копирование и миграция выполняются просто.

• ~/.agentlas/runtime/1.2.0/ содержит сам runtime (инсталлятор удаляет начальный v из тега), а ~/.agentlas/runtime/current/ указывает на активную версию через символическую ссылку. Две зафиксированные версии могут находиться рядом.
• ~/.local/bin/ содержит оболочечные обёртки, включая hephaestus, hep-build, hep-network, hep-search, hep-storm, hep-cloud и hep-upload.
• ~/.agentlas/networking/memory/ содержит постоянные данные памяти: playbook-registry.json, playbook-candidates.jsonl и memory-events.jsonl.
• ~/.agentlas/networking/hub-agents/<slug>/memory/experience.sqlite содержит данные опыта отдельных агентов с учётом владельца.
• <project>/.agentlas/ontology-runtime.sqlite содержит состояние отдельных проектов. Поэтому оно перемещается вместе с репозиторием, а не с сервером.
• ~/.cache/agentlas/python содержит кэш Python в Linux. В macOS используется другой путь. Инсталлятор выбирает его в соответствующей ветви с помощью uname.

В документации по памяти v1.2.0 прямо указано, что секреты, исходные учётные данные и полные стенограммы нельзя сохранять в области памяти. Значения учётных данных хранятся в локальных файлах, исключённых из git, а в записях памяти сохраняются только имена и пути. Создайте резервные копии ~/.agentlas и каталогов проектов .agentlas, чтобы восстановить систему на новом VPS.

Одни данные покидают сервер: согласно текущему README, hep-build по умолчанию отправляет анонимную статистику сборок без запросов пользователю, путей или содержимого агента. Установите AGENTLAS_TELEMETRY=0 или DO_NOT_TRACK=1 либо добавьте "telemetry": false в ~/.agentlas/networking/config.json, чтобы отключить это поведение.

Какие модели поддерживаются через backend

Вот ключевая деталь, которая меняет понимание всей схемы: Agentlas не обращается к API модели напрямую. Это делает хостовая оболочка.

В документе по архитектуре описаны адаптеры среды выполнения, которые преобразуют одно ядро для каждой оболочки. В README указано, что адаптер отвечает за аутентификацию у провайдера, а вызывающая сторона передаёт собственную модель и доступ к API. Agentlas предоставляет две точки интеграции, которые использует оболочка: файл AgentSkills и сервер MCP (model context protocol), работающий через stdio. Поэтому вопрос «какие модели поддерживает Agentlas» на самом деле означает «какие модели поддерживает ваша оболочка». Ответ: любые модели, к которым могут обращаться Claude Code, Codex, opencode, goose или Hermes.

Регистрация сервера MCP в конфигурации TOML в стиле Codex выглядит так:

[mcp_servers.hephaestus-network]
command = "~/.agentlas/runtime/current/bin/hephaestus"
args = ["mcp", "serve"]

Во время установки этот же сервер автоматически регистрируется в ~/.cursor/mcp.json, ~/.config/goose/config.yaml и других конфигурациях оболочек. Если вы подключаете несколько таких серверов на одном хосте, в материале запуск серверов MCP на VPS подробнее описаны модель stdio и управление процессами.

Укажите локальную конечную точку Ollama

Поскольку подключением к модели управляет harness, для использования локальных моделей в Agentlas нужно настроить harness на работу с Ollama. В Ollama в v0.15 появилась субкоманда launch именно для этого. По состоянию на 11 August 2026 она по-прежнему входит в v0.32.9. Субкоманда настраивает существующий harness для работы с локальными моделями. Переменные окружения задавать не нужно:

ollama pull qwen3-coder:30b
ollama launch opencode

Замените opencode на claude, codex или droid в зависимости от установленного harness. Затем направьте запрос через локальную среду выполнения:

~/.agentlas/runtime/current/bin/hephaestus route "summarise the failing tests" --runtime ollama

При успешной маршрутизации возвращается JSON с решением, в котором указаны выбранные агент или команда и значение receipt_id. Если результат не содержит полезных данных, обычно причина связана с размером контекста. В документации по локальным моделям v1.2.0 рекомендуется использовать для сеансов с интенсивной маршрутизацией модель как минимум с контекстом 64k. В качестве примеров там указаны qwen3-coder, gemma3 и deepseek-r1. В собственных рекомендациях Ollama для инструментов разработки указан тот же минимум 64k. Решения о маршрутизации передают в промпте список доступных агентов, поэтому модель с контекстом 8k или 32k обрезает этот список и выбирает неправильно.

Есть один нюанс, о котором не сообщает tagline. У Ollama, Gemma и DeepSeek нет собственной системы плагинов или команд, поэтому slash-команды /agentlas там недоступны. В конфигурации с локальной моделью системой управляют через MCP server и команду hephaestus route. Это действительно уменьшает набор доступных возможностей. Такова честная плата за хранение весов на собственном сервере.

Сколько RAM занимает хаб бездействующих специалистов

Нисколько. Таков полный ответ, и его можно проверить, а не принимать на веру.

Подключаемые специалисты поставляются как пакетные артефакты, а не как процессы. Специалист — это agent.md и каталог .agentlas/ с JSON-файлами: routing-card.json содержит триггеры и возможности, memory-map.json — границы записи, mode-map.json — сведения о том, запускается ли он отдельно или в составе команды. В документации Hephaestus Network описан runner, который запускает worker для задачи. При этом он не открывает listening port и не требует включать сервис. Между задачами проверьте это самостоятельно:

pgrep -af hephaestus
systemctl --user list-units --type=service | grep -i agentlas
du -sh ~/.agentlas

Первые две команды ничего не выводят на простаивающей машине, потому что резидентных процессов нет. Единственное исключение — фоновый updater: если не задана HEPHAESTUS_AUTO_UPDATE=0, команда может оставить после завершения короткоживущий detached worker, работающий в фоне. Третья команда выводит единственную стоимость простаивающего хаба — место на диске. Оно увеличивается с числом сохранённых специалистов и встроенной embedding model, которая поставляется вместе с runtime.

Поэтому вопрос о потреблении памяти сводится к вопросу о пиковом запуске. А пиковое потребление определяется вашим harness и backend модели. Если harness обращается к hosted API, резидентное потребление составляет один процесс размером в несколько сотен мегабайт. Если вы размещаете weights самостоятельно, именно они определяют затраты:

[
  {
    "label": "Hosted API model",
    "weights_gb": 0
  },
  {
    "label": "gemma3:4b",
    "weights_gb": 3.3
  },
  {
    "label": "gemma3:12b",
    "weights_gb": 8.1
  },
  {
    "label": "gemma3:27b",
    "weights_gb": 17
  },
  {
    "label": "qwen3-coder:30b",
    "weights_gb": 19
  }
]

Это опубликованные размеры загрузки из библиотеки моделей Ollama, а не результаты benchmark. Кроме того, KV cache для контекста 64k добавляется к каждому значению выше нуля. Модель, которую Agentlas docs называют первой, qwen3-coder:30b, требует 19 GB weights до учёта контекста. Даже вариант Gemma 27B требует 17 GB. На фоне этих значений сам слой Agentlas в расчёте практически не заметен.

Сравнение с запуском одного harness

Запустите один harness для hosted API — и на VPS будет работать один процесс. Добавьте Agentlas — и процесс останется тем же, но появятся файлы. Orchestrator не является отдельной постоянно работающей программой. Это более крупный prompt, собранный из пакетов на диске и затем удалённый.

Меняется не объём памяти, а объём контекста. Orchestrator, который подключает несколько карточек специалистов и метаданные маршрутизации, использует для каждой задачи больше токенов, чем обычный harness. При работе с hosted API это означает дополнительные расходы, а не увеличение использования RAM. На локальных весах это увеличивает время выполнения: более длинный prompt требует более длительного prefill на CPU или создаёт большую нагрузку на GPU.

Поэтому рекомендации по выбору конфигурации для такого сервера зависят от выбора модели, а не от agent framework. Подбор RAM и CPU для VPS с coding agent подробно рассматривает этот вопрос. Вывод остаётся тем же: выбирайте план под backend, который собираетесь запускать, а затем добавьте пару гигабайт запаса для harness. Если вместо этого вы хотите сравнить архитектуру с постоянно работающим supervisor, multi-agent harness Omnigent оставляет coordinator запущенным. Это противоположный компромисс, который напрямую отражается на использовании памяти в простое.

Типовые ошибки и сообщения, которые вы увидите

hep-build: command not found сразу после чистой установки. Установщик записал данные в ~/.local/bin, которого нет в PATH в стандартном образе Ubuntu. В конце вывода об этом было сообщение, но предупреждение быстро прокрутилось, а предложенное исправление относится к ~/.zshrc, а не к bash. Добавьте показанный выше export в ~/.bashrc.

Поведение изменилось после пересборки сервера. Вы не задали HEPHAESTUS_REF, поэтому установщик выбрал тег по умолчанию, указанный в его скрипте на тот момент. Зафиксируйте нужный тег и запишите его рядом с другими номерами версий.

Поведение изменилось без пересборки. Фоновый обновлятор установил более новый релиз и переместил ~/.agentlas/runtime/current на него. Проверьте, на что указывает current, и задайте HEPHAESTUS_AUTO_UPDATE=0 в окружении, в котором запускается ваш harness, а не только в интерактивной оболочке.

Маршрутизация выбирает неподходящего специалиста в локальной модели. Контекстное окно модели слишком мало для списка агентов. Перейдите на модель с размером контекста не менее 64k и установите такую же длину контекста в Ollama, поскольку значение по умолчанию меньше, чем требуется инструментам для работы с кодом.

ollama launch не распознаётся. Эта подкоманда появилась в Ollama v0.15. Более старые пакеты из репозитория дистрибутива были выпущены до неё, поэтому установите текущую версию Ollama.

Установка записывает данные в harness, которые вы не ожидали. Скрипт обнаруживает и настраивает каждый найденный harness. Он записывает данные в ~/.claude/, ~/.codex/, ~/.gemini/, ~/.cursor/ и другие каталоги, а также изменяет уже существующие файлы конфигурации, например ~/.codex/config.toml, сохраняя резервную копию рядом с исходным файлом. На общем сервере сборки прочитайте скрипт перед запуском и определите, какие из этих каталогов вам нужны.

Стоит ли уже запускать это

Проекту всего четыре месяца, а релизы выходят автоматически, иногда по несколько раз в день. Это недостаточно зрелое решение для производственной нагрузки. Архитектура действительно интересна, лицензия — Apache-2.0, а всё состояние хранится в файлах, которые можно резервировать. Но удаление не такое простое, как можно предположить: в README не описана процедура удаления, установщик записывает файлы примерно в десять мест в домашнем каталоге и изменяет существующие конфигурации harness, а единственная команда удаления, указанная в документации, hephaestus global remove, удаляет только необязательный блок маршрутизатора. Поэтому попробовать проект на сервере, который можно без последствий пересоздать, недорого, а полагаться на него рискованно.

На данный момент разумный вариант такой: зафиксируйте версию v1.2.0, задайте HEPHAESTUS_AUTO_UPDATE=0, чтобы эта версия сохранялась, запускайте проект на сервере, который можно пересобрать, включите ~/.agentlas в резервные копии и перечитайте журнал изменений перед обновлением зафиксированной версии. Чтобы получить более широкий обзор решений в этой области и понять, насколько зрелым является каждый вариант, начните с обзора автономно размещаемых AI-агентов. В материале автономное размещение агента Hermes на VPS описан один из harness, с которыми работает Agentlas.

FAQ

Запускается ли Agentlas OS как сервер на моём VPS?

Нет. В репозитории нет ни демона, ни порта, который прослушивается, ни образа контейнера. Установщик записывает среду выполнения в ~/.agentlas/runtime/, а оболочки команд — в ~/.local/bin. Hephaestus Network запускается при выполнении задачи, а не работает как фоновая служба. Это можно проверить на простаивающем сервере: pgrep -af hephaestus ничего не выводит, а юнит systemd, который можно включить, отсутствует. Единственная фоновая активность — краткоживущий рабочий процесс обновления, который могут запускать команды; HEPHAESTUS_AUTO_UPDATE=0 отключает его. Самостоятельное размещение в данном случае означает, что код и состояние находятся на вашей машине, а не то, что служба прослушивает порт.

Сколько RAM использует хаб простаивающих специалистов?

Нисколько, потому что простаивающие специалисты не являются процессами. Специалист — это файл agent.md и каталог .agentlas/, содержащий routing-card.json, memory-map.json и аналогичные метаданные. Поэтому простаивающий хаб занимает место на диске. Измерить его можно с помощью du -sh ~/.agentlas. Память используется только во время выполнения задачи. Её потребляют процесс вашего harness и ваш backend модели, а не слой Agentlas.

Какие модели можно использовать и можно ли подключить собственный Ollama?

Agentlas не обращается к API моделей напрямую. Учётные данные и подключение контролирует host harness, поэтому поддерживаются все модели, которые поддерживает ваш harness. Для локальных весов выполните ollama launch opencode, заменив значения на claude, codex или droid. Эта команда настраивает harness для работы с вашим сервером Ollama без переменных окружения. Используйте модель с контекстом не менее 64k, например qwen3-coder или gemma3, поскольку routing prompts содержат список агентов и на окне меньшего размера сильно обрезаются.

Какую версию следует установить и почему здесь важно зафиксировать версию?

Установите v1.2.0 — это помеченный релиз, актуальный на 12 August 2026, — задав HEPHAESTUS_REF=v1.2.0 перед запуском установщика. Текущее значение по умолчанию самого скрипта в main — version="${HEPHAESTUS_REF:-v1.2.62}". Это v1.2.62, последний релиз, опубликованный 10 October 2026. Значение по умолчанию меняется с каждым новым тегом. Фиксация версии здесь особенно важна, поскольку проект выпустил более ста релизов в серии 1.1, иногда по нескольку за день. Поэтому повторная сборка без зафиксированной версии через несколько недель не даст систему, которую вы тестировали. Также задайте HEPHAESTUS_AUTO_UPDATE=0. Иначе runtime будет устанавливать более новые релизы в фоновом режиме, и зафиксированная версия перестанет соблюдаться.