Як розгорнути Agentlas OS на Linux VPS

Що насправді являє собою Agentlas OS

Agentlas OS — це open source середовище виконання агентів. Воно зберігає спеціалізовані агенти на диску як пакети та створює тимчасовий оркестратор для кожного завдання. Ви розгортаєте його самостійно, встановлюючи у власний обліковий запис користувача на Linux VPS. Це не сервіс. Тут немає daemon, порту, на якому прослуховуються з’єднання, web-інтерфейсу або container image у repository.

Це речення визначає все інше на цій сторінці. Більшість multi-agent систем запускають supervisor process, який постійно працює та зберігає агентів. Agentlas працює навпаки: спеціалізовані агенти є файлами на диску, а оркестратор існує лише під час виконання завдання. Практичний результат полягає в тому, що неактивний hub використовує дисковий простір, а не пам’ять.

Проєкт називає своє open core Hephaestus. Саме цю назву ви побачите в командах, шляхах і змінних середовища. Repository має адресу agentlas-ai/Agentlas-OS, поширюється за ліцензією Apache-2.0 і написаний переважно мовою Python.

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

Репозиторій створено 4 червня 2026 року. Станом на 12 серпня 2026 року йому близько десяти тижнів, він має приблизно 1,150 зірок і 112 форків. Для інструмента, якому ви доручаєте реальну роботу, це дуже короткий термін.

Важливішою за вік є частота випусків. Версію v1.1.103 опубліковано 8 серпня 2026 року, а v1.2.0 — 12 серпня 2026 року. У серії 1.1 було понад сто позначених випусків, деякі дні мали по кілька випусків, опублікованих засобами автоматизації. Проєкт, який розвивається з такою швидкістю, може змінити поведінку між вівторком і четвергом.

Тому зафіксуйте версію випуску. Інсталятор читає для цього змінну середовища, і весь наведений нижче посібник використовує її. Інсталяція без зафіксованої версії проєкту, який випускає оновлення кілька разів на день, встановить саме те, що випадково було доступне на main тієї години.

Що потрібно на VPS

Вимоги мінімальні, оскільки у фоновому режимі нічого не працює.

• Linux VPS. Ubuntu 24.04 — надійний базовий варіант. Інсталятор визначає операційну систему за допомогою uname -s і для Linux використовує гілку, відмінну від macOS, тому підтримуються сервери без графічного інтерфейсу.
• curl, tar і git на сервері, а також робочий інтерпретатор Python.
• Вихідний HTTPS-доступ до raw.githubusercontent.com і github.com. Інсталятор завантажує архів релізу та перевіряє його SHA-256, тому сервер без вихідного доступу до мережі не зможе виконати інсталяцію.
• Host harness — програмний coding agent, який безпосередньо взаємодіє з моделлю. Підтримуються адаптери Claude Code, Codex, opencode, goose і Hermes.

Права root не потрібні. Інсталятор записує файли лише у ваш домашній каталог і в ~/.local/bin. Якщо шлях недоступний для запису, інсталятор виводить попередження, а не завершує роботу з помилкою. Якщо ви ще обираєте сам сервер, у матеріалі Запуск coding agent на 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 — це фіксована версія. Усередині скрипту цей рядок має вигляд version="${HEPHAESTUS_REF:-v1.2.0}", тому якщо не задати значення явно, сьогодні ви отримаєте v1.2.0, а наступного тижня — іншу версію. Задайте значення явно, і під час повторного складання в жовтні буде встановлено саме те, що ви тестували в серпні.

Є одне важливе обмеження: URL скрипту вище вказує на main, а HEPHAESTUS_REF фіксує корисне навантаження runtime, яке завантажує скрипт. Це різні компоненти. Щоб зафіксувати обидва, завантажте скрипт із tag, а не з main, замінивши main на v1.2.0 у цьому URL.

Після успішного виконання будуть виведені шляхи, за якими скрипт записав файли, зокрема такі два рядки:

Installed runner: /home/you/.agentlas/runtime/current/bin/hephaestus
Installed shell commands in /home/you/.local/bin (add ~/.local/bin to PATH to use them)

Другий рядок часто пропускають. У щойно встановленій системі Ubuntu ~/.local/bin часто відсутній у PATH, тому кожна команда hep-* завершується помилкою command not found, хоча встановлення виконано успішно. Виправте це й перевірте:

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

hep-global status показує, що встановив глобальний router і які harness він виявив. Якщо команда взагалі запускається, ваш PATH налаштовано правильно.

Де зберігається стан

Усе зберігається у файлах у вашому домашньому каталозі, тому резервне копіювання та міграція прості.

• ~/.agentlas/runtime/v1.2.0/ містить саме середовище виконання, а ~/.agentlas/runtime/current/ є символічним посиланням на активну версію. Дві зафіксовані версії можуть працювати паралельно.
• ~/.local/bin/ містить shell-обгортки: 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.

У документації щодо пам’яті прямо зазначено, що секрети, необроблені облікові дані та повні транскрипції не можна зберігати в жодній області пам’яті. Значення облікових даних зберігаються в локальних файлах, доданих до gitignore, а в пам’яті записуються лише імена та шляхи. Створіть резервну копію каталогів ~/.agentlas і каталогів проєктів .agentlas — і зможете відновити середовище на новому VPS.

На які бекенди моделей він може вказувати

Ось деталь, яка змінює розуміння всієї схеми: Agentlas не викликає 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 і процесів.

Налаштуйте підключення до self-hosted endpoint 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. Якщо результат не містить корисних даних, найчастіша причина — недостатня довжина контексту. Документація Agentlas рекомендує для сесій із великою кількістю маршрутизації модель щонайменше з контекстом 64k і наводить qwen3-coder, gemma3 та deepseek-r1 як приклади. У власних рекомендаціях Ollama для інструментів розробки також указано мінімальний контекст 64k. Рішення щодо маршрутизації містять перелік агентів у prompt, тому модель із контекстом 8k або 32k обрізає цей перелік і вибирає агент неправильно.

Є одна важлива особливість, про яку не йдеться в tagline. Ollama, Gemma та DeepSeek не мають власної системи plugin або command, тому slash-команди /agentlas там недоступні. У конфігурації з локальною моделлю системою керують через MCP server і команду hephaestus route. Це реальне обмеження функціональності, але саме така ціна зберігання ваг моделі на власному сервері.

Скільки RAM потребує хаб неактивних спеціалістів

Нічого. Це вся відповідь, і її можна довести, а не просто прийняти на віру.

Запозичені спеціалісти хаба надходять як артефакти пакетів, а не як процеси. Спеціаліст — це agent.md і каталог .agentlas/ із JSON: routing-card.json для тригерів і можливостей, memory-map.json для меж запису, mode-map.json для визначення, чи працює він самостійно, чи в команді. Hephaestus Network описано як планувальник у процесі, якому не потрібна фонова служба. Між завданнями перевірте це самостійно:

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

Перші дві команди нічого не виводять на неактивній системі, оскільки нічого не запущено в пам’яті. Третя команда показує єдину вартість неактивного хаба для вас — дисковий простір. Вона зростає разом із кількістю збережених спеціалістів і вбудованою моделлю embeddings, яку постачає runtime.

Отже, питання використання пам’яті повністю зводиться до пікового навантаження, а його визначають ваш harness і backend моделі. Якщо harness звертається до hosted API, постійне споживання пам’яті становить один процес обсягом кілька сотень мегабайтів. Якщо ви розміщуєте weights самостійно, основну частину ресурсів потребують саме 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 run. KV cache для контексту 64k додається до кожного наведеного значення, більшого за нуль. Модель, яку Agentlas docs називають першою, qwen3-coder:30b, потребує 19 GB weights ще до врахування контексту. Навіть варіант Gemma 27B потребує 17 GB. На тлі цих значень сам шар Agentlas у бюджеті ресурсів непомітний.

Як це порівняти із запуском одного harness

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

Змінюється не обсяг пам’яті, а context. Orchestrator, який завантажує кілька specialist cards і їхні routing metadata, використовує для кожного завдання більше токенів, ніж базовий harness. Для hosted API це означає вищу вартість, а не більше використання RAM. Для локальних weights це означає більший час виконання, оскільки довший prompt потребує довшого prefill на CPU або створює більше навантаження на GPU.

Тому рекомендації щодо вибору конфігурації для сервера такого типу залежать від вибору моделі, а не від agent framework. Вибір RAM і CPU для coding agent VPS докладно розглядає це питання. Висновок тут такий самий: виберіть план для backend, який плануєте запускати, а потім додайте кілька гігабайтів запасу для harness. Якщо для порівняння потрібна схема з постійно активним supervisor, multi-agent harness Omnigent залишає coordinator у пам’яті. Це протилежний компроміс, який безпосередньо відображається у використанні пам’яті в режимі простою.

Режими відмови та повідомлення, які ви побачите

hep-build: command not found одразу після чистого встановлення. Інсталятор записав значення в ~/.local/bin, якого немає в PATH в образі Ubuntu за замовчуванням. Це було зазначено в останньому рядку, але він уже прокрутився. Додайте export, наведений вище.

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

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

ollama launch не розпізнається. Ця підкоманда з’явилася в Ollama v0.15. Старі пакети з репозиторію дистрибутива були випущені раніше, тому встановіть актуальну версію Ollama.

Інсталяція записує дані в harness, яких ви не очікували. Скрипт виявляє та налаштовує кожен знайдений harness, записуючи дані в ~/.claude/, ~/.codex/, ~/.gemini/, ~/.cursor/ та інші каталоги. На спільному сервері збірки прочитайте скрипт перед запуском і визначте, які з цих каталогів вам потрібні.

Чи варто вже запускати цей проєкт

Проєкт, якому лише десять тижнів і який випускає оновлення кілька разів на день, не варто використовувати в робочому навантаженні production. Архітектура справді цікава, ліцензія — Apache-2.0, а файлова структура дає змогу видалити проєкт, просто видаливши два каталоги. Це робить його недорогим для тестування, але ризикованим для залежності від нього.

Наразі варто зафіксувати версію v1.2.0, запускати проєкт на сервері, який можна відновити з нуля, зберігати ~/.agentlas у резервних копіях і перечитувати changelog перед зміною зафіксованої версії. Щоб ширше ознайомитися з іншими рішеннями в цій сфері та рівнем зрілості кожного з них, почніть із огляду self-hosted AI-агентів. У матеріалі як розгорнути self-hosted Hermes-агента на VPS описано один із harness, до яких адаптується Agentlas.

FAQ

Чи працює Agentlas OS як сервер на моєму VPS?

Ні. У репозиторії немає ані daemon, ані порту, що прослуховується, ані container image. Інсталятор записує runtime у ~/.agentlas/runtime/, а обгортки команд — у ~/.local/bin. Hephaestus Network є scheduler у межах процесу, а не фоновою службою. Це можна перевірити на неактивній машині: pgrep -af hephaestus нічого не виводить, і немає systemd unit, який можна ввімкнути. Self-hosting у цьому випадку означає, що код і стан зберігаються на вашій машині, а не те, що певний сервіс прослуховує порт.

Скільки RAM використовує hub із неактивними specialist?

Нуль, оскільки неактивні specialist не є процесами. Specialist — це файл agent.md і каталог .agentlas/, що містить routing-card.json, memory-map.json та подібні метадані, тому припаркований hub займає місце на диску. Виміряти його можна за допомогою du -sh ~/.agentlas. Пам’ять споживається лише під час виконання завдання. Її використовують ваш harness process і ваш model backend, а не шар Agentlas.

Які моделі можна використовувати і чи можна підключити власний Ollama?

Agentlas самостійно не викликає model API. Облікові дані та підключення контролює host harness, тому підтримуються всі моделі, які підтримує ваш harness. Для локальних ваг виконайте ollama launch opencode, замінивши значення на claude, codex або droid. Це налаштує harness для роботи з вашим Ollama server без environment variables. Використовуйте модель щонайменше з контекстом 64k, наприклад qwen3-coder або gemma3, оскільки routing prompts містять inventory агентів і некоректно обрізаються за меншого розміру контекстного вікна.

Яку версію слід встановити і чому тут важливо фіксувати версію?

Встановіть v1.2.0 — tagged release, актуальний станом на 12 August 2026, — задавши HEPHAESTUS_REF=v1.2.0 перед запуском інсталятора. Власне значення за замовчуванням у скрипті — version="${HEPHAESTUS_REF:-v1.2.0}". Воно відповідає наступному тегу, який створять maintainers. Фіксувати версію тут важливіше, ніж зазвичай, оскільки проєкт опублікував понад сто релізів у серії 1.1, інколи по кілька за день. Тому повторна збірка без зафіксованої версії через кілька тижнів не дасть систему, яку ви тестували.