วิธีติดตั้ง Agentlas OS บน Linux VPS ด้วยตัวเอง

Agentlas OS คืออะไร

Agentlas OS เป็น agent runtime แบบโอเพนซอร์สที่จัดเก็บ agent เฉพาะทางไว้บนดิสก์ในรูปแบบแพ็กเกจ และจะประกอบร่าง orchestrator ชั่วคราวขึ้นมาสำหรับแต่ละงาน คุณสามารถ self-host ระบบนี้ได้โดยการติดตั้งลงในบัญชีผู้ใช้ของคุณบน Linux VPS โดยระบบนี้ไม่ใช่ service ไม่มี daemon ไม่มีพอร์ตที่เปิดรอรับการเชื่อมต่อ ไม่มีเว็บอินเทอร์เฟซ และไม่มี container image อยู่ใน repository

ประโยคสุดท้ายนั้นเป็นตัวกำหนดทุกอย่างที่เหลือในหน้านี้ ระบบ multi-agent ส่วนใหญ่จะรัน supervisor process ที่ทำงานค้างไว้เพื่อดูแล agent ต่างๆ แต่ Agentlas ใช้วิธีการที่ตรงกันข้าม คือตัว specialist จะเป็นเพียงไฟล์ที่ถูกจัดเก็บไว้ และ orchestrator จะมีตัวตนอยู่เฉพาะในขณะที่งานกำลังรันเท่านั้น ผลลัพธ์ในทางปฏิบัติคือเมื่อ hub ไม่ได้ใช้งาน มันจะใช้เพียงพื้นที่ดิสก์ ไม่ใช่หน่วยความจำ

โครงการนี้เรียก open core ของตนว่า Hephaestus ซึ่งชื่อนี้คือสิ่งที่คุณจะพบในคำสั่ง, path และ environment variable ต่างๆ repository ของโครงการคือ agentlas-ai/Agentlas-OS ซึ่งได้รับอนุญาตภายใต้สัญญาอนุญาต Apache-2.0 และเขียนด้วยภาษา Python เป็นหลัก

ความจริงแล้วโปรเจกต์นี้อยู่ในขั้นเริ่มต้นเพียงใด

repository นี้ถูกสร้างขึ้นเมื่อวันที่ 4 June 2026 ณ วันที่ 12 August 2026 โปรเจกต์มีอายุประมาณ 10 สัปดาห์ โดยมีจำนวนดาวประมาณ 1,150 ดวง และมีการ fork ไปแล้ว 112 ครั้ง ซึ่งถือว่ายังใหม่เกินกว่าจะนำไปใช้กับงานจริง

ความถี่ในการออก release มีความสำคัญมากกว่าอายุของโปรเจกต์ โดย version v1.1.103 ถูกเผยแพร่เมื่อวันที่ 8 August 2026 และ v1.2.0 ถูกปล่อยออกมาเมื่อวันที่ 12 August 2026 ซึ่งมีการออก tagged release ในซีรีส์ 1.1 ไปแล้วกว่าหนึ่งร้อยรายการ โดยบางวันมีการออก release หลายครั้งผ่านระบบอัตโนมัติ โปรเจกต์ที่เคลื่อนไหวด้วยความเร็วระดับนี้อาจมีการเปลี่ยนแปลงพฤติกรรมระหว่างวันอังคารถึงวันพฤหัสบดีได้

ดังนั้น คุณควรระบุเวอร์ชัน (pin) ให้ชัดเจน ตัว installer รองรับการอ่านค่านี้ผ่าน environment variable และคู่มือทั้งหมดด้านล่างนี้จะใช้การระบุเวอร์ชันดังกล่าว การติดตั้งโดยไม่ระบุเวอร์ชันสำหรับโปรเจกต์ที่มีการปล่อยอัปเดตหลายครั้งต่อวัน จะทำให้คุณได้รับสิ่งที่ถูกอัปโหลดขึ้นไปยัง main ในชั่วโมงนั้นๆ

สิ่งที่จำเป็นต้องมีบน VPS

ความต้องการของระบบมีเพียงเล็กน้อยเนื่องจากไม่มีกระบวนการใดทำงานอยู่เบื้องหลัง

• VPS ที่ใช้ Linux โดย Ubuntu 24.04 เป็นพื้นฐานที่เหมาะสม ตัวติดตั้งจะตรวจหา operating system ด้วย uname -s และเลือก branch ที่ไม่ใช่ macOS สำหรับ Linux ดังนั้นจึงรองรับการใช้งานบนเครื่องแบบ headless
• curl, tar และ git บนเครื่อง รวมถึง Python interpreter ที่ใช้งานได้ปกติ
• การเชื่อมต่อ HTTPS ขาออกไปยัง raw.githubusercontent.com และ github.com เนื่องจากตัวติดตั้งจะดาวน์โหลด release archive และตรวจสอบค่า SHA-256 ดังนั้นเครื่องที่ไม่มีการเชื่อมต่อขาออกจะไม่สามารถติดตั้งซอฟต์แวร์นี้ได้
• Host harness ซึ่งเป็น coding agent ที่ทำหน้าที่สื่อสารกับโมเดล โดยรองรับ adapter ได้แก่ Claude Code, Codex, opencode, goose และ Hermes

คุณไม่จำเป็นต้องมีสิทธิ์ root ตัวติดตั้งจะเขียนข้อมูลลงใน home directory และ ~/.local/bin ของคุณเท่านั้น และจะแจ้งเตือนแทนการหยุดทำงานหาก path ใดไม่สามารถเขียนข้อมูลได้ หากคุณยังอยู่ในขั้นตอนการเลือกเครื่อง การรัน coding agent บน VPS มีเนื้อหาครอบคลุมถึง base image และการตั้งค่าการเข้าถึงที่จำเป็นสำหรับการใช้งานนี้

ติดตั้งรุ่นที่ระบุเวอร์ชัน (pinned release)

README ของต้นทางระบุคำสั่งบรรทัดเดียวที่ส่งสคริปต์จาก main ไปยัง bash โดยตรง ให้ดาวน์โหลดและอ่านสคริปต์ดังกล่าวก่อน สคริปต์นี้จะเขียนข้อมูลลงในไฟล์ตั้งค่า shell ของคุณและในทุก agent 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 payload ที่สคริปต์ดาวน์โหลด ทั้งสองส่วนนี้เป็นคนละส่วนกัน หากต้องการระบุเวอร์ชันทั้งคู่ ให้ดึงสคริปต์จาก tag แทนที่จะเป็น main โดยการแทนที่ main ด้วย v1.2.0 ใน URL นั้น

การทำงานที่สำเร็จจะแสดง path ที่ถูกเขียนลงไป รวมถึงสองบรรทัดนี้:

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 จะรายงานสิ่งที่ global router ติดตั้งและ harness ที่ตรวจพบ หากคำสั่งนี้ทำงานได้ แสดงว่า PATH ของคุณถูกต้องแล้ว

ตำแหน่งที่จัดเก็บสถานะ

ทุกอย่างเป็นไฟล์ภายใต้ home directory ของคุณ ซึ่งทำให้การสำรองข้อมูลและการย้ายระบบทำได้ง่าย

• ~/.agentlas/runtime/v1.2.0/ จัดเก็บตัว runtime โดยมี ~/.agentlas/runtime/current/ เป็น symlink เชื่อมไปยังเวอร์ชันที่ใช้งานอยู่ คุณสามารถเก็บเวอร์ชันที่ระบุไว้ (pinned versions) สองเวอร์ชันไว้คู่กันได้
• ~/.local/bin/ จัดเก็บ shell wrappers ได้แก่ hephaestus, hep-build, hep-network, hep-search, hep-storm, hep-cloud และ hep-upload
• ~/.agentlas/networking/memory/ จัดเก็บหน่วยความจำถาวร (durable memory) ได้แก่ playbook-registry.json, playbook-candidates.jsonl และ memory-events.jsonl
• ~/.agentlas/networking/hub-agents/<slug>/memory/experience.sqlite จัดเก็บประสบการณ์การใช้งานแยกตาม agent โดยจำกัดขอบเขตตามเจ้าของ
• <project>/.agentlas/ontology-runtime.sqlite จัดเก็บสถานะแยกตามโปรเจกต์ ดังนั้นข้อมูลจะติดไปกับ repository แทนที่จะอยู่กับเครื่องเซิร์ฟเวอร์
• ~/.cache/agentlas/python จัดเก็บ Python cache บน Linux สำหรับ macOS จะใช้ path อื่น ซึ่งเป็น branch ที่ตัวติดตั้งเลือกโดยใช้ uname

เอกสารประกอบเกี่ยวกับหน่วยความจำระบุไว้อย่างชัดเจนว่า ห้ามนำความลับ (secrets), ข้อมูลรับรองดิบ (raw credentials) และบันทึกการสนทนาฉบับเต็ม (full transcripts) เข้าไปในขอบเขตของหน่วยความจำใดๆ ทั้งสิ้น ค่าของข้อมูลรับรองควรเก็บไว้ในไฟล์ภายในเครื่องที่ถูก gitignore ไว้ และบันทึกหน่วยความจำจะเก็บเพียงแค่ชื่อและ path เท่านั้น หากคุณสำรองข้อมูล ~/.agentlas และไดเรกทอรี .agentlas ของโปรเจกต์ไว้ คุณจะสามารถสร้างระบบขึ้นมาใหม่บน VPS เครื่องใหม่ได้อย่างสมบูรณ์

โมเดลแบ็กเอนด์ที่สามารถเชื่อมต่อได้

นี่คือรายละเอียดที่ปรับเปลี่ยนความเข้าใจเกี่ยวกับโครงสร้างทั้งหมด: Agentlas ไม่ได้เรียกใช้ Model API โดยตรง แต่เป็นหน้าที่ของ Host Harness

เอกสารสถาปัตยกรรมอธิบายถึง Runtime Adapter ที่ทำหน้าที่แปลง Core หนึ่งตัวให้เข้ากับ Harness แต่ละตัว และระบุว่า Host Runtime เป็นผู้ถือครองข้อมูลรับรอง (Credential) ของโมเดล Agentlas จะส่งมอบส่วนประกอบสองส่วนที่ Harness จะนำไปใช้งาน ได้แก่ ไฟล์ AgentSkills และเซิร์ฟเวอร์ MCP (Model Context Protocol) ที่สื่อสารผ่าน 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 และรูปแบบกระบวนการทำงานเชิงลึกมากขึ้น

ชี้เป้าไปยัง endpoint ของ Ollama ที่โฮสต์ด้วยตนเอง

เนื่องจาก harness เป็นผู้ควบคุมการเชื่อมต่อกับโมเดล การชี้ Agentlas ไปยังโมเดลในเครื่องจึงหมายถึงการชี้ harness ของคุณไปที่ Ollama โดย Ollama ได้เพิ่มคำสั่งย่อย launch เข้ามาใน v0.15 เพื่อการนี้โดยเฉพาะ และยังคงมีให้ใช้งานใน v0.32.9 ณ วันที่ 11 สิงหาคม 2026 ซึ่งช่วยกำหนดค่า harness ที่มีอยู่ให้ทำงานร่วมกับโมเดลในเครื่องได้โดยไม่ต้องตั้งค่า environment variable ใดๆ:

ollama pull qwen3-coder:30b
ollama launch opencode

ให้แทนที่ claude, codex หรือ droid ด้วย opencode ขึ้นอยู่กับ harness ที่คุณติดตั้ง จากนั้นจึงส่งคำขอผ่าน runtime ในเครื่อง:

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

หากการกำหนดเส้นทางสำเร็จ ระบบจะส่งคืน JSON ที่ระบุชื่อ agent หรือทีมที่เลือก พร้อมด้วย receipt_id หากระบบไม่ส่งคืนข้อมูลที่เป็นประโยชน์ สาเหตุที่พบบ่อยที่สุดคือความยาวของ context โดยเอกสารของ Agentlas แนะนำให้ใช้โมเดลที่มี context อย่างน้อย 64k สำหรับเซสชันที่มีการกำหนดเส้นทางจำนวนมาก และระบุตัวอย่างเช่น qwen3-coder, gemma3 และ deepseek-r1 ซึ่งคำแนะนำของ Ollama สำหรับเครื่องมือเขียนโค้ดก็กำหนดขั้นต่ำไว้ที่ 64k เช่นกัน เนื่องจากการตัดสินใจกำหนดเส้นทางจะรวมรายการ agent ไว้ใน prompt ดังนั้นโมเดลที่มี context เพียง 8k หรือ 32k จะทำให้รายการดังกล่าวถูกตัดทอนและส่งผลให้การเลือกผิดพลาด

ข้อควรระวังประการหนึ่งที่คำโฆษณาไม่ได้บอกคุณคือ Ollama, Gemma และ DeepSeek ไม่มีระบบปลั๊กอินหรือระบบคำสั่งของตนเอง ดังนั้นคำสั่ง slash /agentlas จึงไม่มีอยู่จริงในการตั้งค่าโมเดลในเครื่อง คุณจะต้องควบคุมระบบผ่าน MCP server และคำสั่ง hephaestus route แทน ซึ่งถือเป็นการลดขอบเขตการทำงานลงอย่างแท้จริง และเป็นข้อแลกเปลี่ยนที่ตรงไปตรงมาสำหรับการเก็บ weight ไว้บนเครื่องของคุณเอง

ต้นทุน RAM ของกลุ่มผู้เชี่ยวชาญที่ไม่ได้ใช้งาน

ไม่มีเลย นี่คือคำตอบทั้งหมด และคุณสามารถพิสูจน์ได้ด้วยตัวเองแทนที่จะเชื่อเพียงอย่างเดียว

ผู้เชี่ยวชาญที่ถูกดึงมาใช้งานจะเข้ามาในรูปแบบของ package artifacts ไม่ใช่กระบวนการ (process) ผู้เชี่ยวชาญหนึ่งรายประกอบด้วย agent.md และไดเรกทอรี .agentlas/ ที่เก็บไฟล์ JSON: routing-card.json สำหรับตัวกระตุ้น (triggers) และความสามารถ, memory-map.json สำหรับขอบเขตการเขียน (write boundaries), และ mode-map.json สำหรับกำหนดว่าต้องรันแบบเดี่ยวหรือแบบทีม Hephaestus Network ถูกอธิบายว่าเป็นตัวจัดตารางเวลาแบบ in-process ที่ไม่มีบริการเบื้องหลัง (background service) ในระหว่างที่ไม่มีงาน คุณสามารถตรวจสอบได้ด้วยตัวเอง:

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

คำสั่งสองคำสั่งแรกจะไม่แสดงผลลัพธ์ใดๆ บนเครื่องที่ไม่ได้ใช้งาน เพราะไม่มีกระบวนการใดค้างอยู่ ส่วนคำสั่งที่สามจะแสดงต้นทุนเพียงอย่างเดียวที่ hub ทิ้งไว้บนเครื่องของคุณ นั่นคือพื้นที่ดิสก์ ซึ่งจะเพิ่มขึ้นตามจำนวนผู้เชี่ยวชาญที่คุณเก็บไว้รวมกับ embedding model ที่มาพร้อมกับ runtime

ดังนั้น คำถามเรื่องหน่วยความจำจึงเป็นเรื่องของช่วงที่มีการประมวลผลหนัก (burst) เท่านั้น ซึ่งต้นทุนในช่วงนี้คือตัว harness ของคุณบวกกับ model backend หาก harness เชื่อมต่อกับ 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 และ KV cache สำหรับ context ขนาด 64k จะถูกบวกเพิ่มเข้าไปในทุกตัวเลขที่มากกว่าศูนย์ โมเดลที่เอกสารของ Agentlas กล่าวถึงเป็นอันดับแรกคือ qwen3-coder:30b ซึ่งต้องการพื้นที่ 19 GB สำหรับ weights ก่อนจะนับรวม context และแม้แต่ Gemma รุ่น 27B ก็ยังต้องการพื้นที่ 17 GB เมื่อเทียบกับตัวเลขเหล่านี้ เลเยอร์ของ Agentlas เองแทบไม่มีผลต่อการใช้ทรัพยากรเลย

การเปรียบเทียบกับการรัน harness เพียงตัวเดียว

การรัน harness หนึ่งตัวกับ API ที่โฮสต์ไว้จะทำให้ VPS ของคุณมีเพียงหนึ่ง process เท่านั้น การเพิ่ม Agentlas เข้าไปก็ยังคงมีเพียง process เดียวเช่นเดิมบวกกับไฟล์ต่างๆ ตัว orchestrator ไม่ใช่โปรแกรมที่ทำงานค้างไว้นาน แต่เป็น prompt ขนาดใหญ่ที่ถูกประกอบขึ้นจากแพ็กเกจบนดิสก์แล้วถูกลบทิ้งไป

ต้นทุนที่เปลี่ยนแปลงคือบริบท (context) ไม่ใช่หน่วยความจำ (RAM) Orchestrator ที่ดึงการ์ดเฉพาะทางหลายใบและ metadata การกำหนดเส้นทางเข้ามา จะใช้โทเค็นต่อหนึ่งงานมากกว่า harness เปล่าๆ ซึ่งหากเป็น API ที่โฮสต์ไว้ ต้นทุนนี้จะอยู่ในรูปของเงินมากกว่า RAM แต่ถ้าเป็น local weights ต้นทุนนี้จะอยู่ในรูปของเวลา เนื่องจาก prompt ที่ยาวขึ้นหมายถึงการ prefill บน CPU ที่นานขึ้นหรือการใช้งาน GPU ที่หนักขึ้น

นี่คือเหตุผลที่คำแนะนำในการเลือกขนาดเครื่องสำหรับงานลักษณะนี้ขึ้นอยู่กับการตัดสินใจเลือกโมเดล ไม่ใช่เฟรมเวิร์กของเอเจนต์ การเลือกขนาด RAM และ CPU สำหรับ VPS ที่ใช้รัน coding agent ได้อธิบายเรื่องนี้ไว้อย่างละเอียด และข้อสรุปยังคงใช้ได้ในกรณีนี้คือ ให้เลือกแผนการใช้งานตาม backend ที่คุณตั้งใจจะรัน จากนั้นเพิ่ม RAM เผื่อไว้สัก 2-3 GB สำหรับตัว harness หากคุณต้องการเปรียบเทียบกับดีไซน์แบบ supervisor ที่ทำงานตลอดเวลา Omnigent multi-agent harness จะเก็บตัว coordinator ไว้ในหน่วยความจำตลอดเวลา ซึ่งเป็นการแลกเปลี่ยนทรัพยากรในทางตรงกันข้ามและส่งผลโดยตรงต่อการใช้หน่วยความจำขณะไม่ได้ใช้งาน (idle memory)

รูปแบบความล้มเหลวและข้อความที่คุณจะพบ

hep-build: command not found ทันทีหลังการติดตั้งใหม่ ตัวติดตั้งได้เขียนข้อมูลลงใน ~/.local/bin ซึ่งไม่มีอยู่บน PATH ในอิมเมจ Ubuntu ค่าเริ่มต้น โดยระบบได้แจ้งเตือนไว้ในบรรทัดสุดท้ายแต่ข้อความได้เลื่อนผ่านไป ให้เพิ่มคำสั่ง export ตามที่แสดงไว้ด้านบน

พฤติกรรมเปลี่ยนไปหลังจากที่คุณสร้างเครื่องใหม่ คุณไม่ได้ตั้งค่า HEPHAESTUS_REF ไว้ ตัวติดตั้งจึงใช้ค่า tag ที่เป็นปัจจุบันในวันนั้นโดยอัตโนมัติ ให้ทำการ pin เวอร์ชันไว้และบันทึกค่า pin นั้นไว้คู่กับหมายเลขเวอร์ชันอื่นๆ ของคุณ

การกำหนดเส้นทางเลือกผู้เชี่ยวชาญผิดพลาดในโมเดลท้องถิ่น หน้าต่างบริบท (context window) ของโมเดลมีขนาดเล็กเกินไปสำหรับรายการตัวแทน (agent inventory) ให้เปลี่ยนไปใช้โมเดลที่มีขนาด 64k ขึ้นไป และตั้งค่าความยาวบริบทของ Ollama ให้ตรงกัน เนื่องจากค่าเริ่มต้นนั้นต่ำกว่าที่เครื่องมือเขียนโปรแกรมต้องการ

ollama launch ไม่ได้รับการยอมรับ คำสั่งย่อยนี้ถูกเพิ่มเข้ามาใน Ollama v0.15 แพ็กเกจรุ่นเก่าจาก repository ของ distribution อาจเป็นเวอร์ชันที่เก่ากว่านั้น ให้ติดตั้ง Ollama เวอร์ชันปัจจุบันแทน

การติดตั้งเขียนข้อมูลลงใน harness ที่คุณไม่ได้คาดคิด สคริปต์จะตรวจหาและกำหนดค่าทุก harness ที่พบ โดยเขียนลงใน ~/.claude/, ~/.codex/, ~/.gemini/, ~/.cursor/ และอื่นๆ บนเครื่อง build ที่ใช้งานร่วมกัน ให้ตรวจสอบสคริปต์ก่อนเรียกใช้งานและทำความเข้าใจว่าไดเรกทอรีใดบ้างที่คุณต้องให้ความสำคัญ

ควรเริ่มใช้งานตอนนี้เลยหรือไม่

โครงการที่มีอายุเพียง 10 สัปดาห์และมีการออก release อัตโนมัติวันละหลายครั้ง ไม่ใช่สิ่งที่ควรนำมาใช้กับภาระงานระดับ production สถาปัตยกรรมของโครงการนี้น่าสนใจจริง มีการใช้สัญญาอนุญาตแบบ Apache-2.0 และการออกแบบที่อิงตามไฟล์ทำให้การถอนการติดตั้งทำได้เพียงแค่ลบสองไดเรกทอรีเท่านั้น ข้อเท็จจริงเหล่านี้ทำให้การทดลองใช้งานมีต้นทุนต่ำ แต่การพึ่งพาในระยะยาวนั้นมีความเสี่ยงสูง

แนวทางที่เหมาะสมในขณะนี้คือ: ให้ตรึงเวอร์ชันไว้ที่ v1.2.0, รันบนเครื่องที่คุณสามารถสร้างใหม่ได้ตลอดเวลา, เก็บ ~/.agentlas ไว้ในการสำรองข้อมูลของคุณ และอ่าน changelog อีกครั้งก่อนที่จะเปลี่ยนเวอร์ชันที่ตรึงไว้ สำหรับการสำรวจภาพรวมของเครื่องมืออื่นๆ ในกลุ่มนี้และความพร้อมใช้งานของแต่ละตัวเลือก บทสรุปของ AI agent แบบ self-hosted เป็นจุดเริ่มต้นที่ดีกว่า และ การทำ self-host ตัวแทน Hermes บน VPS จะครอบคลุมหนึ่งในเครื่องมือที่ Agentlas รองรับ

FAQ

Agentlas OS ทำงานเป็นเซิร์ฟเวอร์บน VPS ของฉันหรือไม่?

ไม่ ระบบนี้ไม่มี daemon ไม่มีพอร์ตที่เปิดรอรับการเชื่อมต่อ และไม่มี container image ใน repository ตัวติดตั้งจะเขียน runtime ไว้ที่ ~/.agentlas/runtime/ และเขียน command wrapper ไว้ที่ ~/.local/bin ส่วน Hephaestus Network เป็นเพียงตัวจัดตารางเวลาที่ทำงานภายในกระบวนการ (in-process scheduler) ไม่ใช่บริการเบื้องหลัง คุณสามารถตรวจสอบได้บนเครื่องที่ไม่ได้ใช้งาน: pgrep -af hephaestus จะไม่แสดงผลลัพธ์ใดๆ และไม่มี systemd unit ให้เปิดใช้งาน การทำ self-host ในที่นี้หมายถึงโค้ดและสถานะของระบบจัดเก็บอยู่บนเครื่องของคุณ ไม่ได้หมายความว่ามีบริการเปิดรอรับการเชื่อมต่ออยู่

กลุ่มผู้เชี่ยวชาญ (specialist) ที่ไม่ได้ใช้งานใช้ RAM เท่าใด?

ไม่ใช้เลย เพราะผู้เชี่ยวชาญที่ไม่ได้ใช้งานไม่ใช่กระบวนการ (process) ผู้เชี่ยวชาญหนึ่งรายประกอบด้วยไฟล์ agent.md และไดเรกทอรี .agentlas/ ที่เก็บ routing-card.json, memory-map.json และ metadata อื่นๆ ดังนั้น hub ที่จอดทิ้งไว้จะใช้เพียงพื้นที่ดิสก์เท่านั้น คุณสามารถวัดขนาดได้ด้วย du -sh ~/.agentlas หน่วยความจำจะถูกใช้ก็ต่อเมื่อมีการรันงานเท่านั้น และสิ่งที่ใช้หน่วยความจำคือกระบวนการ harness และ model backend ของคุณ ไม่ใช่เลเยอร์ของ Agentlas

ฉันสามารถใช้โมเดลใดได้บ้าง และชี้ไปยัง Ollama ของฉันเองได้หรือไม่?

Agentlas ไม่ได้เรียกใช้ model API ด้วยตัวเอง ตัว host harness จะเป็นผู้ถือครอง credential และการเชื่อมต่อ ดังนั้นโมเดลที่รองรับจึงขึ้นอยู่กับสิ่งที่ harness ของคุณรองรับ สำหรับ local weights ให้รัน ollama launch opencode (โดยแทนที่ด้วย claude, codex หรือ droid) ซึ่งจะเป็นการกำหนดค่า harness ให้เชื่อมต่อกับเซิร์ฟเวอร์ Ollama ของคุณโดยไม่ต้องใช้ environment variable ควรใช้โมเดลที่มี context อย่างน้อย 64k เช่น qwen3-coder หรือ gemma3 เนื่องจาก prompt สำหรับการจัดเส้นทาง (routing) จะมีรายการ agent อยู่ด้วย ซึ่งจะถูกตัดทอนอย่างรุนแรงหากใช้หน้าต่าง context ที่เล็กกว่านี้

ฉันควรติดตั้งเวอร์ชันใด และเหตุใดการระบุเวอร์ชัน (pinning) จึงสำคัญในกรณีนี้?

ให้ติดตั้ง v1.2.0 ซึ่งเป็นเวอร์ชันที่ติดป้ายกำกับ (tagged release) ล่าสุด ณ วันที่ 12 สิงหาคม 2026 โดยการตั้งค่า HEPHAESTUS_REF=v1.2.0 ก่อนรันตัวติดตั้ง ค่าเริ่มต้นของสคริปต์คือ version="${HEPHAESTUS_REF:-v1.2.0}" ซึ่งจะติดตามเวอร์ชันถัดไปที่ผู้ดูแลระบบติดป้ายกำกับไว้ การระบุเวอร์ชันมีความสำคัญมากกว่าปกติเนื่องจากโปรเจกต์นี้มีการออก release มากกว่าหนึ่งร้อยรายการในซีรีส์ 1.1 โดยบางวันมีการออกหลายครั้ง ดังนั้นการสร้างระบบใหม่โดยไม่ระบุเวอร์ชันในอีกหลายสัปดาห์ถัดมา จะทำให้คุณไม่ได้ระบบเดิมที่คุณเคยทดสอบไว้