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 เนื่องจากตัวรัน harness ของเทอร์มินัลทำงานอยู่ภายในนั้น
• Vendor CLI อย่างน้อยหนึ่งรายการที่ติดตั้งและล็อกอินเรียบร้อยแล้ว
• Node.js 22 หรือใหม่กว่า พร้อมด้วย npm เนื่องจาก harness ของ Claude, Codex และ Pi จำเป็นต้องใช้งาน ตัวติดตั้งจะตรวจสอบ Node 22.10 หรือใหม่กว่า และจะแจ้งเตือนหากไม่พบ ตัว Omnigent เองไม่จำเป็นต้องใช้ Node เนื่องจาก wheel บน PyPI ได้รวมไฟล์เว็บที่ build ไว้แล้ว และ Node จะกลายเป็นข้อกำหนดบังคับก็ต่อเมื่อทำการ build จาก git checkout เท่านั้น

ติดตั้งรุ่นที่ระบุเวอร์ชัน (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 เป็นออปชันของตัวมันเอง ทำให้ตัวติดตั้งไม่ทำงานเลย ในกรณีที่ sh เป็น Bash มันจะแสดงเวอร์ชันของ Bash เองแล้วจบการทำงานโดยไม่มีข้อผิดพลาด ส่งผลให้ไม่มีการติดตั้งและไม่มีการแจ้งเตือนใดๆ แต่เมื่อใช้ -s -- ตัว sh จะอ่านสคริปต์จาก pipe และส่ง --version 0.7.0 ต่อไปยังตัวติดตั้ง ในคลังซอฟต์แวร์ที่มีการเปลี่ยนแปลงแบบ breaking changes ทุกสองสามสัปดาห์ นี่คือความแตกต่างระหว่างเซิร์ฟเวอร์ที่ทำซ้ำผลลัพธ์ได้ (reproducible) กับเซิร์ฟเวอร์ที่เกิดปัญหาไม่คาดคิด

รุ่น 0.7.0 ยังคงเผยแพร่อยู่บน PyPI ณ วันที่ 12 ตุลาคม 2026 แต่รุ่นล่าสุดในปัจจุบันคือ 0.17.0 ซึ่งเผยแพร่เมื่อวันที่ 6 ตุลาคม 2026 สิ่งสำคัญคือการระบุเวอร์ชัน (pin) ไม่ใช่ตัวเลขเวอร์ชัน ให้ระบุเวอร์ชันที่คุณผ่านการทดสอบแล้ว และอ่านรายละเอียดการเปลี่ยนแปลงใน release notes ก่อนที่จะขยับเวอร์ชัน

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

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

ส่วนเสริม (extras) ใช้รูปแบบเดียวกันและต้องระบุแฟล็กซ้ำ: --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-agent ถูกประกาศเป็นเครื่องมือ (tools)

ไฟล์ agent อยู่ในรูปแบบ YAML โดย executor จะระบุชื่อ harness, โมเดล และการยืนยันตัวตน ส่วน tools จะเก็บเซิร์ฟเวอร์ MCP (model context protocol), ฟังก์ชัน Python และ sub-agent ต่างๆ โดย 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 ทั้งนี้ spec ปัจจุบันบน main ยังระบุถึง acp:<slug> สำหรับเซิร์ฟเวอร์ Agent Client Protocol ใดๆ แต่ spec เวอร์ชัน v0.7.0 ไม่ได้ระบุไว้ ดังนั้นควรตรวจสอบให้แน่ใจว่าใช้งานได้กับเวอร์ชันที่คุณล็อกไว้ก่อนที่จะนำไปใช้งานจริง นอกจากนี้ spec ยังรองรับ pass_history: true บน sub-agent ซึ่งจะส่งบทสนทนาของ parent ให้กับ sub-agent นั้น การทำเช่นนี้จะสิ้นเปลือง token ในทุกครั้งที่มีการมอบหมายงาน (delegation) ดังนั้นควรปิดไว้สำหรับ sub-agent ที่ต้องการเพียงแค่ภารกิจที่อยู่ตรงหน้าเท่านั้น โปรแกรมเมอร์ที่มี prompt สั่งให้สร้าง การเปลี่ยนแปลงที่เล็กที่สุดที่ใช้งานได้ จะส่ง diff ที่สั้นพอให้อ่านได้จริงแก่ผู้ตรวจสอบ ซึ่งในบริบทนี้มีความสำคัญมากกว่าโมเดลที่คุณเลือกใช้สำหรับบทบาทใดบทบาทหนึ่งเสียอีก

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

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

omnigent server --background
omnigent server status

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

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

OMNIGENT_AUTH_ENABLED=1 omnigent server --background

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

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

ในด้านการจัดสรรทรัพยากร บันทึกการ deploy ระบุว่า working set ของเซิร์ฟเวอร์อยู่ที่ประมาณ 512 MB ถึง 1 GB และ config ของ Fly.io กำหนดไว้ที่ 1 GB ตัวเลขนี้เป็นเพียงส่วนของ supervisor เท่านั้น sub-agent แต่ละตัวเป็น process แยกต่างหากที่เก็บ 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 ที่ทำงานขนานกันจะเพิ่มอัตราการใช้จ่ายให้สูงขึ้นทวีคูณ

repository นี้มีการพัฒนาเร็วเพียงใด

[
  {
    "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 ไม่ถูกนำมาแสดงในแผนภูมิเนื่องจากไม่มีแท็กก่อนหน้าให้วัดผล

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

ความเร็วในการพัฒนาไม่ได้ลดลงนับตั้งแต่การอ่านค่าครั้งนั้น จนถึงวันที่ 12 ตุลาคม 2026 PyPI แสดงรายการรุ่น 0.17.0 ซึ่งปล่อยออกมาเมื่อวันที่ 6 ตุลาคม นับเป็น 10 รุ่นย่อยหลังจาก 0.7.0 และบันทึกการปล่อยรุ่นบน GitHub ได้ระบุถึงการเปลี่ยนแปลงที่ส่งผลกระทบต่อการทำงานเดิม (breaking changes) ไว้ในอย่างน้อย 6 รุ่น โดยมี 2 รุ่นที่ส่งผลต่อคำสั่งใดก็ตามที่คัดลอกมาจากหน้านี้: v0.12.0 ทำให้การใช้ omni เปล่าๆ เป็นการเริ่ม background host แทนที่จะเป็น Polly agent (ปัจจุบันต้องใช้ omni run เพื่อเรียกใช้ agent เริ่มต้น) และ v0.13.0 กำหนดให้ต้องใช้ tmux 3.3 หรือใหม่กว่าสำหรับ managed terminals

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

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

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

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

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

FAQ

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

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

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