התקנת Agentlas OS על שרת VPS: מדריך מעשי

מהו למעשה Agentlas OS

Agentlas OS הוא סביבת הרצה (runtime) של סוכנים בקוד פתוח, השומרת סוכנים מומחים על הדיסק כחבילות ומרכיבה מתזמר (orchestrator) זמני עבור כל משימה. אתם מארחים אותו בעצמכם על ידי התקנתו בחשבון המשתמש שלכם ב-VPS מבוסס Linux. זהו אינו שירות. אין לו daemon, אין פורט מאזין, אין ממשק אינטרנט ואין image של container במאגר.

המשפט האחרון קובע את כל שאר ההיבטים בדף זה. רוב המערכות מרובות-הסוכנים מריצות תהליך מפקח שנשאר פעיל ומחזיק את הסוכנים. Agentlas הופך את המודל הזה: המומחים הם קבצים במצב מנוחה, והמתזמר קיים רק בזמן שהמשימה רצה. התוצאה המעשית היא שמרכז (hub) במצב המתנה צורך שטח דיסק, לא זיכרון.

הפרויקט מכנה את הליבה הפתוחה שלו Hephaestus, וזהו השם שתראו בפקודות, בנתיבים ובמשתני הסביבה. המאגר הוא agentlas-ai/Agentlas-OS, הוא מופץ תחת רישיון Apache-2.0, וכתוב ברובו ב-Python.

עד כמה הפרויקט הזה מוקדם, בכנות

המאגר נוצר ב-4 ביוני 2026. נכון ל-12 באוגוסט 2026, הוא בן עשרה שבועות לערך, עם כ-1,150 כוכבים ו-112 מזלגות (forks). זהו גיל צעיר עבור פרויקט שמיועד לעבודה אמיתית.

קצב שחרור הגרסאות חשוב יותר מהגיל. גרסה v1.1.103 פורסמה ב-8 באוגוסט 2026, וגרסה v1.2.0 הגיעה ב-12 באוגוסט 2026. מדובר ביותר ממאה גרסאות מתויגות בסדרת 1.1, לעיתים כמה ביום אחד, אשר פורסמו באמצעות אוטומציה. פרויקט שמתקדם בקצב כזה ישנה את התנהגותו אצלך בין יום שלישי ליום חמישי.

לכן, קבעו את גרסת השחרור (pin). המתקין קורא משתנה סביבה עבור מטרה זו, וכל המדריך להלן משתמש בו. התקנה ללא קיבוע של פרויקט שמשחרר גרסאות כמה פעמים ביום תספק לכם את מה שהיה במקרה ב-main באותה שעה.

מה נדרש בשרת ה-VPS

הדרישות מצומצמות כיוון ששום דבר לא רץ ברקע.

• שרת Linux VPS. הפצה מסוג Ubuntu 24.04 מהווה בסיס מצוין. תוכנית ההתקנה מזהה את מערכת ההפעלה באמצעות uname -s ובוחרת בענף שאינו macOS עבור Linux, כך ששרת ללא ממשק גרפי (headless) נתמך.
• curl, tar ו-git מותקנים בשרת, בנוסף למפרש Python תקין.
• גישת HTTPS יוצאת ל-raw.githubusercontent.com ו-github.com. תוכנית ההתקנה מורידה ארכיון של ה-release ומאמתת את ה-SHA-256 שלו, לכן שרת ללא גישה יוצאת לא יוכל להשלים את ההתקנה.
• רכיב host harness, שהוא סוכן הקידוד שמתקשר בפועל עם המודל. המתאמים (adapters) הנתמכים הם Claude Code, Codex, opencode, goose ו-Hermes.

אין צורך בהרשאות root. תוכנית ההתקנה כותבת רק לספריית הבית שלך ול-~/.local/bin, והיא מציגה אזהרה במקום להיעצר כאשר נתיב אינו ניתן לכתיבה. אם טרם בחרת את השרת עצמו, המדריך הרצת סוכן קידוד על גבי VPS מכסה את הגדרת תמונת הבסיס והגישה שעליהם מתבסס תהליך זה.

התקנת גרסה נעולה (pinned release)

ה-README של המקור מתעד שורה אחת המזרימה סקריפט מ-main ישירות לתוך bash. הורידו אותו וקראו אותו תחילה. הוא כותב לתוך הגדרות ה-shell שלכם ולתוך כל רכיב agent שהוא מוצא, לכן כדאי להקדיש לו עשר שניות של תשומת לב.

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 הוא ה-pin. בתוך הסקריפט השורה היא version="${HEPHAESTUS_REF:-v1.2.0}", כך שהשארתו ללא הגדרה תיתן לכם היום את v1.2.0, אך משהו אחר בשבוע הבא. הגדירו אותו במפורש, וכך הבנייה מחדש שלכם באוקטובר תתקין את מה שבדקתם באוגוסט.

מגבלה אחת כנה: כתובת ה-URL של הסקריפט לעיל עוקבת אחרי main, בעוד ש-HEPHAESTUS_REF נועל את ה-payload של ה-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 הגלובלי התקין ואילו רכיבים הוא זיהה. אם הוא רץ בכלל, ה-PATH שלכם תקין.

היכן נשמר המצב

הכול מיוצג כקובץ תחת ספריית הבית שלך, מה שהופך גיבוי והעברה לפעולות פשוטות.

• ~/.agentlas/runtime/v1.2.0/ מכיל את סביבת הריצה עצמה, כאשר ~/.agentlas/runtime/current/ משמש כקישור סימבולי (symlink) לגרסה הפעילה. ניתן להחזיק שתי גרסאות מקובעות זו לצד זו.
• ~/.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 מכיל את מצב הפרויקט, כך שהוא עובר יחד עם ה-repository ולא נשאר מקובע לשרת.
• ~/.cache/agentlas/python מכיל את ה-cache של Python ב-Linux. ב-macOS נעשה שימוש בנתיב אחר, הנבחר על ידי המתקין בהתאם לענף (branch) בעזרת uname.

תיעוד הזיכרון מבהיר במפורש כי סודות, אישורי גישה גולמיים ותמלילים מלאים אסורים באחסון באף היקף זיכרון. ערכי אישורי הגישה נשמרים בקבצים מקומיים שאינם נכללים ב-git, והזיכרון מתעד רק שמות ונתיבים. גבה את ~/.agentlas ואת ספריות ה-.agentlas של הפרויקט שלך, ותוכל לשחזר את המערכת על גבי VPS חדש.

אילו מודלים (backends) ניתן להגדיר

להלן הפרט שמשנה את התמונה כולה: Agentlas אינו קורא ל-API של מודל. ה-harness המארח הוא זה שעושה זאת.

מסמך הארכיטקטורה מתאר מתאמי זמן ריצה (runtime adapters) שמתרגמים ליבה אחת לכל harness, ומציין כי זמן הריצה המארח מחזיק בפרטי ההתחברות למודל. Agentlas מספק שני ממשקים ש-harness יכול לצרוך: קובץ AgentSkills ושרת MCP (פרוטוקול הקשר מודל) המתקשר באמצעות stdio. לכן, השאלה "באילו מודלים Agentlas תומך" היא למעשה "באילו מודלים ה-harness שלך תומך", והתשובה היא כל מודל ש-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 ובשאר קובצי התצורה של ה-harness במהלך ההתקנה. אם אתם מחברים כמה מהם לשרת אחד, המדריך הרצת שרתי MCP על גבי VPS מכסה לעומק את נושא ה-stdio ומודל התהליכים.

הפניית ה-harness לנקודת קצה של Ollama באירוח עצמי

מכיוון שה-harness מנהל את החיבור למודל, הפניית Agentlas למודלים מקומיים משמעותה הפניית ה-harness ל-Ollama. החל מגרסה v0.15 הוסיפה Ollama פקודת משנה launch בדיוק למטרה זו, והיא עדיין קיימת בגרסה v0.32.9 נכון ל-11 באוגוסט 2026. פקודה זו מגדירה harness קיים לעבודה מול מודלים מקומיים ללא צורך בהגדרת משתני סביבה:

ollama pull qwen3-coder:30b
ollama launch opencode

החליפו את opencode ב-claude, codex או droid, בהתאם ל-harness שהתקנתם. לאחר מכן, נתבו בקשה דרך ה-runtime המקומי:

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

ניתוב מוצלח יחזיר אובייקט JSON עם החלטה המציינת את ה-agent או הצוות שנבחר, בצירוף receipt_id. אם לא מתקבלת תשובה מועילה, הסיבה הנפוצה לכך היא אורך ה-context. התיעוד של Agentlas דורש מודל עם לפחות 64k של context עבור סשנים עתירי ניתוב, ומציין את qwen3-coder, gemma3 ו-deepseek-r1 כדוגמאות. ההנחיות של Ollama עצמה עבור כלי פיתוח מציינות את אותו רף של 64k. החלטות ניתוב כוללות את מלאי ה-agents בתוך ה-prompt, לכן מודל עם 8k או 32k של context יקצץ את המלאי ויבצע בחירות שגויות.

סייג אחד שהכותרת לא תציין בפניכם: ל-Ollama, ל-Gemma ול-DeepSeek אין מערכת פלאגינים או פקודות משלהן, ולכן פקודות ה-slash מסוג /agentlas אינן קיימות שם. בהגדרה של מודל מקומי, אתם מנהלים את המערכת דרך שרת ה-MCP ופקודת ה-hephaestus route. מדובר בצמצום ממשי של שטח התקיפה, וזהו המחיר ההוגן עבור שמירת המשקולות (weights) על השרת שלכם.

מה העלות ב-RAM של אוסף מומחים במצב המתנה

כלום. זו התשובה המלאה, ואפשר להוכיח זאת במקום להסתמך על הנחות.

מומחי ה-hub המושאלים מגיעים כארטיפקטים של חבילות, לא כתהליכים. מומחה מורכב מ-agent.md ומספריית .agentlas/ של קובצי JSON: routing-card.json עבור טריגרים ויכולות, memory-map.json עבור גבולות כתיבה, ו-mode-map.json עבור הגדרה אם הוא רץ לבדו או כחלק מצוות. רשת Hephaestus מתוארת כמתזמן בתוך התהליך (in-process) ללא שירות רקע. בין משימות, בדקו זאת בעצמכם:

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

שתי הפקודות הראשונות לא מדפיסות דבר במכונה במצב המתנה, כיוון ששום דבר אינו תושב בזיכרון. השלישית מדפיסה את העלות היחידה ש-hub במצב המתנה מטיל עליכם, והיא שטח דיסק; עלות זו גדלה בהתאם למספר המומחים שאתם שומרים בתוספת מודל ה-embedding המצורף שמגיע עם סביבת הריצה.

לכן, שאלת הזיכרון היא למעשה שאלה על פרץ הפעילות (burst), והפרץ מורכב מה-harness שלכם וממנוע המודל. אם ה-harness מתקשר עם 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 עבור context של 64k מתווסף מעל כל נתון הגדול מאפס. המודל שמוזכר ראשון בתיעוד של Agentlas, ה-qwen3-coder:30b, דורש 19 GB של משקולות לפני ה-context, ואפילו גרסת ה-27B של Gemma דורשת 17 GB. מול מספרים אלו, שכבת ה-Agentlas עצמה אינה מופיעה בתקציב.

כיצד זה בהשוואה להרצת harness יחיד

הרצת harness יחיד מול API מאוחסן גורמת ל-VPS שלכם לשאת תהליך אחד בלבד. הוספת Agentlas גורמת לו לשאת את אותו תהליך, בתוספת קבצים. ה-orchestrator אינו תוכנית נוספת שרצה לאורך זמן; זהו prompt גדול יותר שמורכב מהחבילות שעל הדיסק ולאחר מכן מושלך.

העלות שמשתנה היא ה-context, לא הזיכרון. orchestrator שמושך כמה כרטיסי מומחה ומטא-נתוני הניתוב שלהם צורך יותר tokens לכל משימה מאשר harness בסיסי. ב-API מאוחסן, מדובר בכסף ולא ב-RAM. במודלים מקומיים, מדובר בזמן, כיוון ש-prompt ארוך יותר משמעו prefill ארוך יותר ב-CPU או עומס רב יותר על ה-GPU.

זו הסיבה שההמלצות לגבי גודל השרת עבור מערכת כזו נגזרות מהחלטת המודל ולא מ-framework הסוכנים. קביעת גודל RAM ו-CPU עבור VPS של סוכן קידוד מפרט זאת לעומק, והמסקנה נותרת בעינה: בחרו את התוכנית עבור ה-backend שאתם מתכוונים להריץ, ואז הוסיפו כמה גיגה-בייטים של מרווח ביטחון עבור ה-harness. אם אתם מעדיפים להשוות זאת לתכנון של supervisor שפועל תמיד, ה-harness מרובה-סוכנים Omnigent שומר את ה-coordinator שלו בזיכרון, מה שמהווה את הפשרה ההפוכה ומתבטא ישירות בזיכרון במצב המתנה.

מצבי כשל והודעות שתיתקל בהן

hep-build: command not found מיד לאחר התקנה נקייה. המתקין כתב ל-~/.local/bin, שאינו נמצא ב-PATH בתמונת Ubuntu סטנדרטית. הדבר צוין בשורה האחרונה של תהליך ההתקנה, אך השורה נעלמה מהמסך. הוסף את ה-export המוצג לעיל.

שינויי התנהגות לאחר בנייה מחדש של השרת. לא הגדרת את HEPHAESTUS_REF, לכן המתקין השתמש בתג (tag) שהיה עדכני באותו יום. קבע גרסה ספציפית (pin) ותעד אותה לצד מספרי הגרסאות האחרים שלך.

ניתוב בוחר במומחה הלא נכון במודל מקומי. חלון ההקשר (context window) של המודל קטן מדי עבור מלאי הסוכנים. עברו למודל עם 64k או יותר והגדירו את אורך ההקשר של Ollama בהתאם, שכן ערך ברירת המחדל נמוך ממה שכלי הפיתוח דורשים.

ollama launch אינו מזוהה. פקודת המשנה נוספה ב-Ollama v0.15. חבילות ישנות ממאגרי ההפצה אינן כוללות אותה, לכן התקן גרסה עדכנית של Ollama.

ההתקנה כותבת לתוך רכיבים שלא ציפית להם. הסקריפט מזהה ומגדיר כל רכיב שהוא מוצא, וכותב ל-~/.claude/, ~/.codex/, ~/.gemini/, ~/.cursor/ ועוד. בשרת בנייה משותף, קרא את הסקריפט לפני הרצתו ודע אילו מהתיקיות הללו רלוונטיות עבורך.

האם כדאי להריץ את זה כבר עכשיו

פרויקט בן עשרה שבועות שמשחרר גרסאות באופן אוטומטי כמה פעמים ביום אינו מתאים לעומסי עבודה בסביבת production. הארכיטקטורה מעניינת באמת, הרישיון הוא Apache-2.0, והתכנון מבוסס הקבצים אומר שהסרת ההתקנה מסתכמת במחיקת שתי תיקיות. עובדות אלו הופכות את הניסוי לזול, אך את ההסתמכות עליו ליקרה.

עמדה הגיונית לעת עתה: קבעו גרסה ל-v1.2.0, הריצו את המערכת על שרת שניתן להקים מחדש, שמרו את ~/.agentlas בגיבויים שלכם, וקראו שוב את ה-changelog לפני שתשנו את גרסת ה-pin. לסקירה רחבה יותר של אפשרויות אחרות בתחום זה ושל רמת הבשלות של כל אחת מהן, הסקירה של סוכני AI באירוח עצמי היא נקודת התחלה טובה יותר, והמדריך אירוח עצמי של סוכן Hermes ב-VPS מכסה את אחת התשתיות ש-Agentlas מתאים אליהן.

FAQ

האם Agentlas OS רץ כשרת על ה-VPS שלי?

לא. אין daemon, אין פורט בהאזנה ואין image של container במאגר. המתקין כותב סביבת הרצה תחת ~/.agentlas/runtime/ ומעטפות פקודה לתוך ~/.local/bin, ורשת Hephaestus היא מתזמן בתוך התהליך (in-process) ולא שירות רקע. ניתן לאמת זאת במכונה במצב המתנה: pgrep -af hephaestus לא מדפיס דבר, ואין יחידת systemd להפעלה. אירוח עצמי בהקשר זה אומר שהקוד והמצב נמצאים על המכונה שלך, לא ששירות כלשהו מאזין ברקע.

כמה RAM צורך hub של מומחים במצב המתנה?

כלום, כיוון שמומחים במצב המתנה אינם תהליכים. מומחה הוא קובץ agent.md בצירוף ספריית .agentlas/ המכילה routing-card.json, memory-map.json ומטא-דאטה דומה, לכן hub מושהה תופס רק שטח דיסק. ניתן למדוד זאת באמצעות du -sh ~/.agentlas. זיכרון נצרך רק בזמן הרצת משימה, ומי שצורך אותו הוא תהליך ה-harness שלך ומנוע ה-model שלך, לא שכבת ה-Agentlas.

באילו מודלים ניתן להשתמש, והאם ניתן להפנות את המערכת ל-Ollama הפרטי שלי?

Agentlas אינו קורא ל-APIs של מודלים בעצמו. ה-harness המארח מחזיק בפרטי הגישה ובחיבור, לכן המודלים הנתמכים הם כל מה שה-harness שלך תומך בו. עבור משקולות מקומיות, הריצו את ollama launch opencode (תוך החלפת claude, codex או droid), פעולה המגדירה את ה-harness מול שרת ה-Ollama שלכם ללא משתני סביבה. השתמשו במודל עם context של לפחות 64k, כגון qwen3-coder או gemma3, כיוון שהנחיות הניתוב (routing prompts) נושאות את מלאי הסוכנים ונקטעות בצורה משמעותית בחלונות קטנים יותר.

איזו גרסה עלי להתקין, ומדוע קיבוע גרסה (pinning) חשוב כאן?

התקינו את v1.2.0, ה-release המתויג העדכני ל-12 באוגוסט 2026, על ידי הגדרת HEPHAESTUS_REF=v1.2.0 לפני הרצת המתקין. ברירת המחדל של הסקריפט היא version="${HEPHAESTUS_REF:-v1.2.0}", העוקבת אחר כל מה שהמתחזקים יתייגו בהמשך. קיבוע גרסה חשוב כאן יותר מהרגיל כיוון שהפרויקט פרסם מעל מאה גרסאות בסדרת 1.1 שלו, לעיתים כמה ביום אחד, כך שבנייה מחדש ללא קיבוע לאחר שבועות לא תספק לכם את המערכת שבדקתם.