Omnigent คืออะไร วิธีใช้งาน meta-harness จัดการ Agent CLI

Omnigent คืออะไร

Omnigent เป็น meta-harness แบบโอเพนซอร์ส ซึ่งเป็นเลเยอร์การจัดการ (orchestration layer) ที่ทำหน้าที่ควบคุมเครื่องมือบรรทัดคำสั่ง (CLI) ของเอเจนต์ที่คุณติดตั้งไว้ใช้งานอยู่แล้ว โดยไม่ได้เข้ามาแทนที่ Claude Code, Codex, Cursor, OpenCode, Hermes หรือ Pi แต่ทำหน้าที่เริ่มการทำงาน สั่งงาน และกำกับดูแลผลลัพธ์ของเอเจนต์เหล่านั้นภายในเซสชันเดียวภายใต้นโยบายชุดเดียวกัน Databricks ได้เผยแพร่ repository นี้ในเดือนมิถุนายน 2026 ภายใต้สัญญาอนุญาต Apache 2.0 และหน้าแรกของเว็บไซต์ยังคงระบุข้อความว่า Status: alpha

เป้าหมายการใช้งานจริงนั้นมีความเฉพาะเจาะจงและสามารถอธิบายได้โดยตรง คุณเพียงแค่กำหนดรายละเอียดของเอเจนต์ไว้ในไฟล์ YAML และระบุชื่อ harness ที่จะใช้รันเอเจนต์นั้น หากคุณเปลี่ยนบรรทัดดังกล่าวเพียงบรรทัดเดียว เอเจนต์ตัวเดิมก็จะสามารถทำงานบน CLI ของผู้ให้บริการรายอื่นได้ทันที โดยไม่ต้องปรับเปลี่ยนการตั้งค่าส่วนอื่นในระบบของคุณ เนื่องจาก Omnigent ทำหน้าที่ควบคุมลูปการทำงานที่อยู่ เหนือ ตัวเอเจนต์ แทนที่จะควบคุมลูปที่อยู่ ภายใน ตัวเอเจนต์เอง

Meta-harness คืออะไร และแตกต่างจาก framework อย่างไร

Harness คือโปรแกรมที่ทำหน้าที่ครอบโมเดลไว้ในลูปการทำงาน โดยจะอ่าน prompt ของคุณ เรียกใช้เครื่องมือ แก้ไขไฟล์ และรายงานผลลัพธ์กลับมา ตัวอย่างเช่น Claude Code เป็น harness และ Codex ก็เป็น harness เช่นกัน คุณเพียงแค่ติดตั้ง ล็อกอิน แล้วโปรแกรมจะทำงานด้วยตัวเอง

Framework คือไลบรารีที่คุณต้องเขียนโค้ดเพื่อใช้งาน คุณต้อง import ไลบรารี กำหนดขั้นตอนการทำงานด้วย Python แล้วโปรแกรมของคุณจึงจะกลายเป็น agent การเปลี่ยนผู้ให้บริการในกรณีนี้หมายถึงการแก้ไขโค้ดของคุณ เพราะ client ของผู้ให้บริการถูกเชื่อมต่อไว้ภายในโปรแกรมของคุณโดยตรง

Meta-harness อยู่เหนือกว่าทั้งสองอย่างนั้นหนึ่งระดับ โดยทำหน้าที่เป็นตัวควบคุม (supervisor) ที่รัน harness ต่างๆ ในฐานะ child process ตัวอย่างเช่น Omnigent จะเริ่มการทำงานของ CLI ของผู้ให้บริการ ส่งงานให้ และอ่านผลลัพธ์ที่ส่งกลับมา คุณยังคงใช้ CLI ที่ติดตั้งไว้เดิม รวมถึงการสมัครสมาชิกหรือ API (application programming interface) key ที่คุณจ่ายเงินไว้อยู่แล้วได้ตามปกติ นี่คือความแตกต่างทั้งหมด และเป็นตัวกำหนดว่าเครื่องมือนี้เหมาะกับใคร ซึ่งก็คือผู้ที่มี agent CLI หลายตัวที่ใช้งานอยู่แล้ว และต้องการเลิกใช้งานผ่าน terminal ทีละหน้าต่างครับ

ชั้นการจัดการ orchestration ช่วยแก้ปัญหาอะไรบ้าง

• การเปลี่ยนผู้ให้บริการทำได้เพียงแก้ไขบรรทัดเดียว นิยามของ agent เก็บ harness และ model ไว้ในรูปแบบข้อมูล ดังนั้นการย้ายบทบาทจากผู้ให้บริการรายหนึ่งไปยังอีกรายหนึ่งจึงเป็นการแก้ไขไฟล์ YAML ไม่ใช่การเขียนใหม่ทั้งหมด
• การตรวจสอบข้ามผู้ให้บริการทำได้ ผลต่าง (diff) ที่เขียนโดยโมเดลหนึ่งสามารถอ่านได้โดยโมเดลจากบริษัทอื่น โมเดลสองตัวจากตระกูลเดียวกันมักมีจุดบอดที่เหมือนกัน ดังนั้นความเห็นที่สองจากผู้ให้บริการรายเดียวกันจึงมีค่าน้อยกว่า
• นโยบายมีศูนย์กลางเดียว การกำหนดเพดานค่าใช้จ่ายและคำขออนุมัติจะถูกประกาศไว้ในไฟล์ agent และจะมีผลกับ sub-agent ทุกตัวที่อยู่ภายใต้
• เซสชันมีอายุยาวนานกว่าเครื่องมือใดเครื่องมือหนึ่ง บันทึกการสนทนาเดียวครอบคลุมงานที่ทำโดย CLI หลายตัว คุณจึงสามารถอ่านย้อนหลังได้ว่าเกิดอะไรขึ้นโดยไม่ต้องนำข้อความจากหน้าจอ 4 ส่วนมาต่อกันเอง

ต้นทุนที่ต้องจ่ายคือตัวชั้นการจัดการเอง บั๊กทุกตัวใน Omnigent กลายเป็นบั๊กที่คั่นกลางระหว่างคุณกับ agent ที่เคยทำงานได้ด้วยตัวเอง ในช่วงสถานะ alpha นี่คือต้นทุนที่เกิดขึ้นจริง ไม่ใช่แค่ทฤษฎี

ตำแหน่งของ multi-agent harness เมื่อเทียบกับเครื่องมือแบบ single agent

หากคุณยังไม่เคยรัน agent บนเซิร์ฟเวอร์ ให้เริ่มต้นจากจุดนั้นก่อน คู่มือของเราเรื่อง การรัน coding agent บน VPS ครอบคลุมกรณีการใช้งาน single agent ตั้งแต่ต้นจนจบ ซึ่งเป็นสภาพแวดล้อมที่ Omnigent สมมติว่าคุณมีอยู่แล้ว ในส่วนของ self-hosted AI agents ในวงกว้างนั้นเป็นที่ที่คุณจะเลือกตัว agent เอง และการ เรียนรู้วิธีการทำงานจริงของ agent เป็นจุดเริ่มต้นที่ดีกว่าหากคำศัพท์ในที่นี้ยังเป็นเรื่องใหม่สำหรับคุณ

Omnigent ยังเป็นคนละส่วนกับชั้น connector งานประเภท การให้สิทธิ์ agent เข้าถึงแหล่งข้อมูลของคุณ เป็นเรื่องเกี่ยวกับสิ่งที่ agent สามารถเข้าถึงได้ ส่วน Omnigent เป็นเรื่องเกี่ยวกับว่า agent ตัวใดจะทำงาน ในลำดับใด และภายใต้ข้อจำกัดใด คุณสามารถต้องการทั้งสองอย่างพร้อมกันได้โดยที่การทำงานไม่ซ้ำซ้อนกัน

สิ่งที่ต้องเตรียมก่อนการติดตั้ง

• Python 3.12 หรือใหม่กว่า โดยแพ็กเกจที่เผยแพร่ได้ระบุ requires-python >= 3.12 ไว้
• tmux เนื่องจาก terminal harness จะทำงานอยู่ภายในนั้น
• Vendor CLI อย่างน้อยหนึ่งรายการที่ติดตั้งและล็อกอินเรียบร้อยแล้ว
• Node.js 22 เฉพาะในกรณีที่คุณ build จาก git checkout เท่านั้น เนื่องจากไฟล์ wheel บน PyPI ได้รวม web assets ที่ build ไว้แล้ว การติดตั้งตามปกติจึงไม่จำเป็นต้องใช้ Node เลย

การติดตั้งรุ่นที่ระบุเวอร์ชัน (Pinned release) ไม่ใช่รุ่น main

curl -fsSL https://raw.githubusercontent.com/omnigent-ai/omnigent/main/scripts/install_oss.sh | sh -s -- --version 0.7.0

ส่วน sh -s -- ไม่ใช่สิ่งที่ใส่ไว้เพื่อความสวยงาม หากไม่มีส่วนนี้ sh จะอ่าน --version เป็นออปชันของตัวมันเอง ทำให้ตัวติดตั้งไม่ได้รับ flag ดังกล่าว ส่งผลให้คุณได้รับเวอร์ชันล่าสุดของวันนั้นเสมอ ในกรณีของ repository ที่มีการเปลี่ยนแปลงแบบ breaking changes ทุกสองสามสัปดาห์ นี่คือความแตกต่างระหว่างการได้เซิร์ฟเวอร์ที่ทำซ้ำได้ (reproducible) กับการเจอเรื่องเซอร์ไพรส์ที่ไม่คาดคิด

ตัวติดตั้งใช้ uv ซึ่งเป็น Python package manager ของ Astral และจะเสนอให้ติดตั้ง uv ก่อนหากยังไม่มี หากมี uv อยู่แล้ว ให้ข้ามสคริปต์ไปได้เลย:

uv tool install --force --python 3.12 "omnigent==0.7.0"

ส่วนเสริม (Extras) ใช้รูปแบบเดียวกันและต้องระบุ flag ซ้ำ: --extra e2b --extra kubernetes บนสคริปต์ หรือ "omnigent[e2b,kubernetes]" เมื่อใช้ uv โปรดสังเกตว่า git tag คือ v0.7.0 ในขณะที่เวอร์ชันของแพ็กเกจบน PyPI คือ 0.7.0

uv จะวางไฟล์ binary ไว้ในไดเรกทอรีที่ uv tool dir --bin รายงาน ซึ่งโดยปกติคือ ~/.local/bin และตัวติดตั้งจะเสนอให้เพิ่มพาธดังกล่าวลงใน shell profile ของคุณ หากคำสั่งไม่พบหลังจากติดตั้งเสร็จสิ้น นั่นคือสาเหตุ ให้ตรวจสอบสิ่งที่คุณติดตั้งไป:

omni upgrade --check

คำสั่งนี้จะเปรียบเทียบเวอร์ชันที่ติดตั้งไว้กับเวอร์ชันล่าสุดที่เผยแพร่ และแจ้งให้คุณทราบว่ามีการอัปเกรดหรือไม่ โดยที่ยังไม่ได้ดำเนินการอัปเกรดจริง omni และ omnigent คือโปรแกรมเดียวกันภายใต้ชื่อเรียกสองชื่อ

กำหนดผู้ให้บริการโมเดล

omni setup

วิซาร์ดจะตรวจสอบข้อมูลรับรอง (credentials) ที่มีอยู่ในสภาพแวดล้อมของคุณ และจะแจ้งเตือนให้คุณระบุข้อมูลที่ยังขาดอยู่ ระบบจะจัดการทั้ง API keys, การสมัครสมาชิกของผู้ให้บริการ, เกตเวย์อย่าง OpenRouter หรือ Ollama และ Databricks workspaces หากคุณใช้งาน เซิร์ฟเวอร์โมเดลภายในเครื่องด้วย Ollama อยู่บนเครื่องเดียวกันอยู่แล้ว ให้กำหนดเกตเวย์ไปยังเซิร์ฟเวอร์นั้น เพื่อให้ทราฟฟิกข้อมูลทำงานอยู่ภายในเครื่องโดยไม่ต้องส่งออกไปยังภายนอก

การรัน multi-agent แบบขั้นต่ำ

ตัวอย่าง agent อยู่ใน repository ดังนั้นให้ clone tag เดียวกับที่คุณติดตั้งไว้แทนการใช้ main

git clone --depth 1 --branch v0.7.0 https://github.com/omnigent-ai/omnigent.git
cd omnigent
omnigent run examples/polly/

Polly คือ multi-agent coding orchestrator ที่มาพร้อมกับ repo นี้ ไฟล์ config ของมันประกาศชื่อ sub-agent ไว้คือ claude_code, codex, opencode, cursor, hermes และ pi พร้อมด้วยกฎหนึ่งข้อที่ทำให้การทดสอบนี้คุ้มค่าที่จะรัน: การตรวจสอบจะต้องทำโดย vendor คนละรายกับผู้เขียนโค้ดเสมอ Polly ไม่ได้เขียนโค้ดด้วยตัวเอง แต่จะทำหน้าที่วางแผน แบ่งเป้าหมายออกเป็นงานย่อย มอบหมายงาน และส่ง diff แต่ละรายการไปยังผู้ตรวจสอบจาก vendor อื่น

ก่อนจะมอบหมายงานใดๆ Polly จะรันการตรวจสอบเบื้องต้น (preflight check) เพื่อดูว่า CLI ของ sub-agent ตัวใดบ้างที่มีอยู่จริงบนเครื่อง หากติดตั้ง vendor CLI ไว้เพียงตัวเดียว ก็จะไม่มีใครให้ส่ง diff ต่อได้ ดังนั้นควรติดตั้งอย่างน้อยสองตัวก่อนที่คุณจะประเมินผลลัพธ์ Debby ซึ่งเป็นตัวอย่างอีกตัวที่มาพร้อมกัน คือ debate agent ที่มีสองหัว ประกอบด้วย Claude และ GPT:

omni debby

นี่เป็นวิธีสั้นๆ ในการยืนยันว่ามีการตั้งค่า provider ไว้สองรายแล้ว เพราะมันจำเป็นต้องใช้ทั้งสองรายในการแสดงผลลัพธ์ใดๆ ออกมา

Sub-agents ถูกประกาศเป็นเครื่องมือ

ไฟล์ agent อยู่ในรูปแบบ YAML โดย executor จะระบุชื่อ harness, โมเดล และการยืนยันตัวตน ส่วน tools จะเก็บเซิร์ฟเวอร์ MCP (model context protocol), ฟังก์ชัน Python และ sub-agents เอาไว้ sub-agent คือเครื่องมือที่มี type: agent และตัวประมวลผล (executor) ของตัวเอง ซึ่งเป็นกลไกเบื้องหลังทุกสิ่งที่กล่าวมาข้างต้น

name: orchestrator
prompt: |
  You coordinate coding and review tasks.

executor:
  harness: claude-sdk
  model: databricks-claude-sonnet-4-6

tools:
  coder:
    type: agent
    prompt: Write and test code.
    executor:
      harness: claude-sdk
      model: databricks-claude-opus-4-7
  reviewer:
    type: agent
    prompt: Review proposed changes.
    executor:
      harness: claude-sdk
      model: databricks-claude-sonnet-4-6

omnigent run path/to/my_agent.yaml

รหัสโมเดลเหล่านั้นมาจากตัวอย่าง docs/AGENT_YAML_SPEC.md ของโปรเจกต์เอง และเป็นชื่อที่โฮสต์โดย Databricks ให้แทนที่ harness และ model ด้วยค่าใดก็ตามที่ omni setup กำหนดไว้บนเครื่องของคุณ ค่า harness อื่นๆ ใน spec รวมถึง antigravity, copilot, kimi, qwen และ acp:<slug> สำหรับบริการใดก็ตามที่สื่อสารด้วยโปรโตคอลทั่วไป นอกจากนี้ spec ยังรองรับ pass_history: true บน sub-agent ซึ่งจะส่งบทสนทนาของ parent ไปให้ด้วย การทำเช่นนี้จะสิ้นเปลือง token ในทุกครั้งที่มีการมอบหมายงาน ดังนั้นควรปิดไว้สำหรับ sub-agent ที่ต้องการเพียงแค่ภารกิจที่อยู่ตรงหน้าเท่านั้น โปรแกรมเมอร์ที่มี prompt สั่งให้ทำ การเปลี่ยนแปลงที่เล็กที่สุดที่ใช้งานได้ จะส่ง diff ที่สั้นพอให้อ่านได้จริงแก่ผู้ตรวจสอบ ซึ่งในบริบทนี้มีความสำคัญมากกว่าโมเดลที่คุณเลือกใช้สำหรับบทบาทใดบทบาทหนึ่งเสียอีก

เหตุผลที่การทำ orchestration ระยะยาวควรอยู่บน VPS

การรัน multi-agent ไม่ใช่คำสั่งที่ใช้เวลาเพียงสองนาที แต่ประกอบด้วยการวางแผน การมอบหมายงาน การรอการทำงานบน git worktrees แบบขนาน การตรวจสอบ และการแก้ไข การปิดฝาแล็ปท็อปจะทำให้กระบวนการทั้งหมดสิ้นสุดลง VPS (virtual private server) จะทำงานอยู่ตลอดเวลาและคงสถานะเครือข่ายไว้ ทำให้เซสชันยังคงอยู่แม้ในขณะที่คุณไม่ได้เฝ้าดู

omnigent server --background
omnigent server status

เซิร์ฟเวอร์จะโฮสต์เว็บอินเทอร์เฟซไว้ที่พอร์ต 6767 โดย omnigent server status จะรายงานว่ามีบริการทำงานอยู่หรือไม่ และ omnigent stop จะใช้สำหรับปิดการทำงาน ในรุ่นก่อน v0.7.0 จะใช้คำสั่ง omni server start ซึ่งถูกถอดออกไปแล้ว ดังนั้นบทความหรือภาพหน้าจอเก่าๆ จะไม่ตรงกับการทำงานของเทอร์มินัลของคุณในปัจจุบัน

ห้ามเปิดพอร์ต 6767 สู่สาธารณะ รูปแบบที่ปลอดภัยมีสองวิธี คือปิดพอร์ตที่ไฟร์วอลล์แล้วทำ port forwarding ผ่าน SSH ด้วย ssh -N -L 6767:localhost:6767 you@your-server จากนั้นจึงเปิดเว็บอินเทอร์เฟซที่ http://localhost:6767 บนเครื่องของคุณเอง หรืออีกวิธีคือทำ TLS (transport layer security) termination ไว้ด้านหน้าและเปิดใช้งานการยืนยันตัวตน:

OMNIGENT_AUTH_ENABLED=1 omnigent server --background

ส่วนของการตั้งค่าไฟร์วอลล์เป็นงานพื้นฐาน ซึ่งครอบคลุมอยู่ใน พื้นฐานการใช้ ufw firewall สำหรับ VPS และหากเซิร์ฟเวอร์ของคุณรันคอนเทนเนอร์อยู่แล้วโดยใช้ Traefik หน้าแอป Docker Compose หลายตัว Omnigent ก็จะเป็นอีกหนึ่งบริการที่ใช้รูปแบบเดียวกัน

สำหรับการปรับใช้แบบคอนเทนเนอร์ ไดเรกทอรี deploy/ ใน repository จะมีการตั้งค่า Compose ไว้: ./bootstrap.sh จะสร้าง secrets ลงใน .env จากนั้น docker compose up -d จะเริ่มการทำงานของ Omnigent และ Postgres ที่พอร์ต 6767 โดย DATABASE_URL จะใช้เลือกฐานข้อมูลระหว่าง Postgres หรือ SQLite และ OMNIGENT_AUTH_ENABLED จะตั้งค่าเริ่มต้นเป็น 1 ภายในคอนเทนเนอร์ ซึ่งเป็นค่าเริ่มต้นที่เหมาะสมสำหรับบริการที่เข้าถึงได้จากภายนอก

ในด้านการจัดสรรทรัพยากร บันทึกการติดตั้งระบุว่าเซิร์ฟเวอร์ต้องการหน่วยความจำประมาณ 512 MB ถึง 1 GB และการตั้งค่า Fly.io ได้กำหนดไว้ที่ 1 GB ตัวเลขนี้เป็นเพียงส่วนของ supervisor เท่านั้น เนื่องจาก sub-agent แต่ละตัวเป็นกระบวนการแยกต่างหากที่ต้องเก็บ checkout และ model client ของตัวเอง ดังนั้นควรเลือกขนาดเซิร์ฟเวอร์ให้เหมาะสมกับจำนวน agent เมื่อเซิร์ฟเวอร์พร้อมใช้งานแล้ว ให้ใช้ omnigent login https://your-host ตามด้วย omnigent host https://your-host เพื่อลงทะเบียนแล็ปท็อปของคุณเข้ากับเซิร์ฟเวอร์ และใช้ omnigent attach <session_id> เพื่อดึงเซสชันที่กำลังทำงานอยู่กลับมาใช้งานต่อจากอุปกรณ์อื่น

ทำ Sandbox ให้กับ sub-agent ทุกตัวก่อนที่คุณจะปล่อยให้มันทำงาน

Omnigent มาพร้อมกับ sandbox ระดับระบบปฏิบัติการที่เรียกว่า Omnibox บน Linux มันใช้ bubblewrap namespaces ร่วมกับ seccomp เพื่อให้ kernel เป็นผู้บังคับใช้ขอบเขตแทนที่จะพึ่งพา prompt ของ agent ดังนั้น agent ที่ถูก prompt injection จะไม่สามารถหลบเลี่ยงกฎของ kernel ได้ ให้ติดตั้ง dependency ก่อน:

sudo apt install bubblewrap

การตั้งค่าจะอยู่ที่ os_env ในไฟล์ของ agent:

os_env:
  type: caller_process
  cwd: .
  sandbox:
    type: linux_bwrap
    write_paths: [.]
    write_files: []
    read_paths: []
    allow_network: true
    cwd_allow_hidden: [.venv]
    env_passthrough: []
    egress_rules: []
    credential_proxy: []

ไดเรกทอรีทำงานจะเป็นแบบอ่านได้อย่างเดียวจนกว่าคุณจะระบุไว้ใน write_paths ดังนั้น agent ที่ทำงานผิดพลาดจะไม่สามารถเขียนข้อมูลออกนอก workspace ได้ ไฟล์ dotfiles จะถูกซ่อนไว้เว้นแต่จะระบุชื่อไว้ใน cwd_allow_hidden ซึ่งหมายความว่าการอนุญาตให้อ่านข้อมูลในวงกว้างจะไม่เป็นการเปิดเผย .ssh หรือ .aws โดยไม่ตั้งใจ หากตั้งค่า egress_rules ทราฟฟิก HTTP และ HTTPS ทั้งหมดจะผ่าน proxy ที่ปฏิเสธการเชื่อมต่อไว้ก่อนเป็นค่าเริ่มต้น โดยแต่ละกฎจะเขียนในรูปแบบ "METHODS host/path-glob" ส่วน credential_proxy จะเพิ่มความปลอดภัยอีกขั้น: agent จะถือเพียง placeholder เท่านั้น และ proxy จะสลับเป็น secret จริงในขณะที่คำขอถูกส่งออกไป ดังนั้นหาก transcript รั่วไหล ข้อมูลที่ได้ก็จะไม่สามารถนำไปใช้งานได้ ในการตั้งค่าแบบ multi-harness sub-agent แต่ละตัวจะมีบล็อก sandbox ของตัวเองในไฟล์ config ภายใต้ agents/ ทำให้สามารถปฏิเสธการเข้าถึงเครือข่ายของ reviewer ในขณะที่ยังอนุญาตให้ implementer เข้าถึงได้

ข้อจำกัดนี้ระบุไว้ในเอกสารประกอบและมีความสำคัญมาก Sandbox ของ OS จะครอบคลุมถึงการเรียกใช้เครื่องมือ sys_os_* และ terminal แต่ไม่ครอบคลุมถึง MCP server และไม่ครอบคลุมถึงกระบวนการ Omnigent supervisor เอง MCP server ที่คุณเริ่มทำงานจะรันอยู่นอก sandbox ด้วยสิทธิ์ของคุณ ช่องว่างนี้คือเหตุผลที่รูปแบบที่แข็งแกร่งกว่ายังคงเป็นการใช้เครื่องเสมือนแบบใช้แล้วทิ้งหนึ่งเครื่องต่อหนึ่ง agent ซึ่งเป็นหัวข้อของ การรัน coding agent ใน VM แบบใช้แล้วทิ้ง อีกส่วนหนึ่งของงานคือเรื่อง credentials ซึ่ง การเก็บ secret ให้พ้นมือ agent จะทำได้ยากขึ้นเมื่อ sub-agent หกตัวใช้โฮสต์เดียวกัน

การจำกัดค่าใช้จ่ายเป็นนโยบายที่ต้องประกาศไว้ในไฟล์เดียวกัน:

policies:
  budget:
    type: function
    handler: omnigent.policies.builtins.cost.cost_budget
    factory_params:
      max_cost_usd: 5.00
      ask_thresholds_usd: [1.00, 3.00]

การรันงานที่วางแผนกับ vendor หนึ่งราย ดำเนินการกับรายที่สอง และตรวจสอบกับรายที่สาม จะทำให้เกิดค่าใช้จ่ายในสามที่พร้อมกัน ดังนั้นควรตั้งค่าเพดานงบประมาณก่อนการรันงานแบบอัตโนมัติครั้งแรก แทนที่จะตั้งหลังจากได้รับใบแจ้งหนี้ใบแรก ฟีเจอร์ที่มีมาให้ในตัวยังรวมถึง max_tool_calls_per_session และ ask_on_os_tools ซึ่งจะขอการอนุมัติก่อนการดำเนินการเกี่ยวกับไฟล์และ shell บันทึกของเราเกี่ยวกับ การควบคุมค่าใช้จ่าย AI agent บน VPS สามารถนำมาปรับใช้ได้โดยตรงที่นี่ และมีความสำคัญยิ่งกว่าเดิมเนื่องจาก sub-agent ที่ทำงานขนานกันจะเพิ่มอัตราการใช้จ่ายให้สูงขึ้นทวีคูณ

ที่เก็บข้อมูลนี้มีการอัปเดตเร็วเพียงใด

[
  {
    "version": "v0.2.0",
    "released": "2026-06-19",
    "interval": 3
  },
  {
    "version": "v0.3.0",
    "released": "2026-06-27",
    "interval": 8
  },
  {
    "version": "v0.4.0",
    "released": "2026-07-03",
    "interval": 6
  },
  {
    "version": "v0.5.0",
    "released": "2026-07-10",
    "interval": 7
  },
  {
    "version": "v0.5.1",
    "released": "2026-07-10",
    "interval": 0
  },
  {
    "version": "v0.6.0",
    "released": "2026-07-21",
    "interval": 11
  },
  {
    "version": "v0.7.0",
    "released": "2026-07-27",
    "interval": 6
  }
]

ข้อมูลดังกล่าวคือวันที่เผยแพร่ซอฟต์แวร์จากหน้า releases ของโครงการโดยตรง ซึ่งอ่านเมื่อวันที่ 3 สิงหาคม 2026 มีการปล่อยเวอร์ชันที่ติดแท็กจำนวน 7 รายการ ระหว่างวันที่ 2026-06-19 ถึง 2026-07-27 โดยช่วงเวลาที่ยาวนานที่สุดระหว่างการปล่อยสองเวอร์ชันคือ 11 วัน เวอร์ชัน v0.5.1 ถูกปล่อยออกมาในวันเดียวกับเวอร์ชันก่อนหน้า เวอร์ชันแรกคือ 0.1.1 เมื่อวันที่ 16 มิถุนายน 2026 ไม่ได้ถูกนำมาแสดงในแผนภูมิเนื่องจากไม่มีแท็กก่อนหน้าให้คำนวณระยะห่าง

การปล่อยเวอร์ชันสองครั้งทำให้คำสั่งที่ระบุไว้ในคู่มือใช้งานไม่ได้ผล เวอร์ชัน v0.7.0 ได้นำ omni server start ออกและแทนที่ด้วย omni server --background ส่วน v0.6.0 ได้เปลี่ยนชื่อ extra จาก omnigent[memory] เป็น omnigent[hindsight] ส่งผลให้คำสั่งติดตั้งที่คัดลอกมาจากบทความในเดือนมิถุนายนไม่สามารถใช้งานได้กับบิลด์ของเดือนกรกฎาคม นี่คือเหตุผลว่าทำไมการระบุ --version ในคำสั่งติดตั้งและการระบุแท็กใน git clone ของคุณจึงเป็นเรื่องจำเป็น ไม่ใช่เพียงแค่ความชอบส่วนบุคคลในการเขียนโค้ด

สิ่งที่ผมยังไม่ไว้วางใจให้ทำในขณะนี้

ณ เดือนสิงหาคม 2026 repository นี้มีดาวประมาณ 8.1k ดวง มีการ fork 1.2k ครั้ง และมี issue ที่ยังเปิดอยู่ประมาณ 350 รายการ โดยมีการเผยแพร่สู่สาธารณะครั้งแรกเมื่อ 7 สัปดาห์ก่อน จำนวนดาวเป็นตัววัดความสนใจ แต่ความสนใจไม่ได้หมายถึงความพร้อมใช้งาน โครงการระบุว่าเป็นสถานะ alpha และประวัติการ release ข้างต้นก็แสดงให้เห็นว่ามันคือ alpha จริงๆ

• ผมจะไม่รันบนโฮสต์ที่เก็บข้อมูลรับรอง (credentials) สำหรับใช้งานจริง (production) เพราะ sandbox ยังไม่ครอบคลุมถึง MCP servers หรือตัว supervisor
• ผมจะไม่ปล่อยให้การทำงานดำเนินไปโดยไม่มีนโยบาย cost_budget กำกับดูแล เพราะผู้ให้บริการ 3 รายสามารถเรียกเก็บเงินพร้อมกันได้โดยไม่มีกลไกอื่นมาหยุดยั้ง
• ผมจะไม่เปิดเผยเซิร์ฟเวอร์บน IP address สาธารณะโดยไม่มีการตั้งค่า OMNIGENT_AUTH_ENABLED และไม่มี TLS อยู่เบื้องหน้า
• ผมจะไม่ถือว่าไฟล์ YAML ของ agent มีความเสถียรข้ามเวอร์ชันย่อยในขณะนี้ ดังนั้นควรล็อกเวอร์ชันไว้และอ่านบันทึกการ release ก่อนทำการอัปเกรด

อีกหนึ่งสิ่งที่ควรทราบก่อนที่จะพบกับเรื่องเซอร์ไพรส์: v0.6.0 ได้เพิ่มระบบ telemetry การใช้งานแบบไม่ระบุตัวตนเข้ามา ซึ่งโครงการได้จัดทำเอกสารไว้ในหน้า telemetry โดยเฉพาะ โปรดอ่านหน้านั้นและตัดสินใจอย่างรอบคอบหากเครื่องดังกล่าวต้องจัดการงานของลูกค้า

สิ่งที่ Omnigent ทำได้ดีจริงๆ ในปัจจุบันคือสิ่งที่มันถูกสร้างมาเพื่อทำ นั่นคือการที่คุณมี CLI ของ agent อยู่ 3 หรือ 4 ตัว ซึ่งคุณจ่ายเงินใช้งานอยู่แล้ว และคุณต้องการให้ตัวหนึ่งเขียนงานในขณะที่อีกตัวหนึ่งทำหน้าที่ตรวจสอบ สิ่งนี้สามารถทำได้แล้วในขณะนี้ บนเครื่องเดียว พร้อมระบบ sandboxing บน Linux ที่ใช้งานได้จริง ส่วนฟังก์ชันการทำงานอื่นๆ นอกเหนือจากนี้ ให้ถือว่าเป็นสิ่งที่น่าสนใจแต่ยังไม่เสร็จสมบูรณ์

FAQ

Omnigent เป็น agent หรือเป็นสิ่งที่ใช้รัน agent?

มันเป็นสิ่งที่ใช้รัน agent โดย Omnigent ทำหน้าที่เป็น meta-harness ซึ่งจะเริ่มการทำงานของ vendor CLI ที่คุณติดตั้งไว้แล้ว เช่น Claude Code, Codex หรือ OpenCode จากนั้นจะมอบหมายงานให้แต่ละตัวและกำกับดูแลผลลัพธ์ในเซสชันเดียว มันไม่มีโมเดลเป็นของตัวเอง นี่คือจุดที่ทำให้มันแตกต่างจากเฟรมเวิร์กที่คุณต้องเขียน Python เพื่อเรียกใช้ไลบรารีและให้โปรแกรมของคุณกลายเป็น agent ด้วยตัวเอง

ฉันจำเป็นต้องติดตั้ง Claude Code และ Codex ก่อนถึงจะใช้งาน Omnigent ได้หรือไม่?

คุณจำเป็นต้องติดตั้งและล็อกอิน vendor CLI อย่างน้อยหนึ่งตัว เพราะ Omnigent ทำหน้าที่ควบคุมโปรแกรมเหล่านั้นแทนที่จะเข้าไปแทนที่ สำหรับตัวอย่าง Polly ที่มาพร้อมกับโปรแกรม คุณต้องมี CLI จากผู้ให้บริการตั้งแต่สองรายขึ้นไป กฎของ Polly คือการตรวจสอบงานจะต้องทำโดยผู้ให้บริการรายอื่นที่ไม่ใช่ผู้ที่เขียนโค้ด ดังนั้นหากมี CLI เพียงตัวเดียว ก็จะไม่มีผู้ให้บริการรายที่สองสำหรับส่ง diff ไปให้ตรวจสอบ

ฉันจะติดตั้ง Omnigent เวอร์ชันเฉพาะเจาะจงแทนเวอร์ชันล่าสุดได้อย่างไร?

ให้ส่งค่าผ่าน --version ไปยังสคริปต์ติดตั้งด้วย sh -s -- ดังตัวอย่างใน sh -s -- --version 0.7.0 หากไม่มี -s -- แฟล็กดังกล่าวจะถูกใช้โดย sh เองและสคริปต์จะติดตั้ง release ล่าสุดให้ หากคุณมี uv อยู่แล้ว uv tool install --force --python 3.12 "omnigent==0.7.0" ก็สามารถทำงานเดียวกันได้ โดย git tag คือ v0.7.0 ในขณะที่สตริงเวอร์ชันบน PyPI คือ 0.7.0

Omnibox sandbox เพียงพอสำหรับการรัน agent แบบไม่ต้องเฝ้าดูหรือไม่?

มันมีความแข็งแกร่งในส่วนที่ครอบคลุมและระบุไว้อย่างชัดเจนในส่วนที่ไม่ครอบคลุม บน Linux มันใช้ bubblewrap ร่วมกับ seccomp ดังนั้น kernel จะบังคับใช้ข้อจำกัดด้านไฟล์และเครือข่ายโดยที่ agent ไม่สามารถเลือกที่จะไม่ปฏิบัติตามได้ เอกสารระบุว่ามันใช้กับ sys_os_* tool calls และเทอร์มินัล แต่ไม่ครอบคลุมถึง MCP servers หรือกระบวนการ Omnigent supervisor ดังนั้น MCP server จึงรันด้วยสิทธิ์ปกติของคุณ ซึ่งเป็นเหตุผลว่าทำไมการใช้ virtual machine แบบใช้แล้วทิ้งสำหรับแต่ละ agent จึงยังคงเป็นการแยกส่วนที่ปลอดภัยกว่าสำหรับการทำงานแบบไม่ต้องเฝ้าดู

Omnigent server ต้องการหน่วยความจำเท่าใดบน VPS?

บันทึกการปรับใช้ของโปรเจกต์ระบุว่าเซิร์ฟเวอร์ต้องการหน่วยความจำใช้งานประมาณ 512 MB ถึง 1 GB และการตั้งค่า Fly.io ได้กำหนดไว้ที่ 1 GB ซึ่งครอบคลุมเฉพาะตัว supervisor และเว็บอินเทอร์เฟซบนพอร์ต 6767 เท่านั้น โดย sub-agent แต่ละตัวจะเป็นกระบวนการแยกต่างหากที่มี working copy และ model client ของตัวเอง และการรันแบบ Polly จะใช้ git worktrees แบบขนาน ดังนั้นควรจัดสรร RAM และดิสก์ตามจำนวน agent ที่คุณวางแผนจะรันพร้อมกัน แทนที่จะจัดสรรตามขนาดของเซิร์ฟเวอร์เพียงอย่างเดียว