Omnigent: Isang Harness para sa Maraming Agent CLI

Ano ang Omnigent

Ang Omnigent ay isang open source meta-harness: isang orchestration layer na nagpapatakbo sa mga agent command-line tool (CLI) na naka-install na sa iyo. Hindi nito pinapalitan ang Claude Code, Codex, Cursor, OpenCode, Hermes, o Pi. Sinisimulan nito ang mga ito, binibigyan ang bawat isa ng gawain, at sinusubaybayan ang resulta sa iisang session gamit ang isang policy set. Inilathala ng Databricks ang repository noong June 2026 sa ilalim ng Apache 2.0 licence, at ang front page ay naglalaman pa rin ng Status: alpha.

Makitid ang praktikal na pahayag na ito at dapat itong sabihin nang malinaw. Inilalarawan mo ang isang agent nang isang beses sa YAML at tinutukoy mo ang harness na nagpapatakbo rito. Baguhin ang isang linyang iyon at tatakbo ang parehong agent gamit ang CLI ng ibang vendor. Walang ibang kailangang baguhin sa setup mo, dahil ang loop na pinamamahalaan ng Omnigent ay nasa itaas ng mga agent, hindi ang loop na nasa loob ng mga ito.

Ano ang meta-harness, at paano ito naiiba sa framework?

Ang harness ay program na nagbabalot sa isang model sa loob ng loop. Binabasa nito ang prompt mo, tumatawag ng tools, nag-e-edit ng files, at nagbabalik ng resulta. Ang Claude Code ay harness. Ang Codex ay harness. Ini-install mo ito, nagla-login ka, at gumagana ito nang mag-isa.

Ang framework ay isang library na sinusulatan mo ng code. Ini-import mo ito, tinutukoy mo ang mga hakbang sa Python, at nagiging agent ang program mo. Kapag nagpalit ka ng vendor, kailangan mong i-edit ang code dahil nakakabit sa program mo ang client ng vendor.

Ang meta-harness ay nasa isang antas na mas mataas kaysa sa dalawang ito. Isa itong supervisor na nagpapatakbo ng mga harness bilang child process. Sinisimulan ng Omnigent ang vendor CLI, ipinapasa rito ang gawain, at binabasa ang ibinabalik nito. Patuloy mong ginagamit ang CLI na na-install mo na, pati ang subscription o API (application programming interface) key na ginagamit mo na sa pagbabayad nito. Iyan ang buong pagkakaiba, at dito nakabatay kung para kanino ang tool: para sa mga taong may ilang agent CLI na gumagana na at pagod nang patakbuhin ang mga ito nang paisa-isa sa bawat terminal.

Anong problema ang nalulutas ng isang orchestration layer?

• Isang linya lang ang kailangan kapag nagpapalit ng vendor. Naka-store bilang data sa agent definition ang harness at model, kaya ang paglipat ng isang role mula sa isang vendor patungo sa iba ay pag-edit sa YAML file, hindi muling pagsulat ng configuration.
• Maaaring tumawid sa iba’t ibang vendor ang review. Binabasa ng model mula sa ibang kumpanya ang diff na ginawa ng isang model. Karaniwang pareho ang blind spots ng dalawang model mula sa iisang family, kaya mas mababa ang halaga ng second opinion mula sa parehong vendor.
• Iisa ang pinaglalagyan ng policy. Idinedeklara sa agent file ang spend caps at approval prompts, at nalalapat ang mga ito sa bawat sub-agent na nasa ilalim nito.
• Mas matagal mabuhay ang session kaysa sa alinmang tool. Sinasaklaw ng iisang transcript ang gawaing isinagawa ng ilang CLI, kaya mababasa mo kung ano ang nangyari nang hindi pinagdudugtong ang apat na scrollback.

Ang kapalit nito ay ang layer mismo. Ang bawat bug sa Omnigent ay nagiging bug na nasa pagitan mo at ng agent na dati namang gumagana nang mag-isa. Sa alpha, tunay na gastos ito, hindi teoretikal lamang.

Kung saan pumapagitna ang multi-agent harness sa mga single-agent tool

Kung hindi ka pa nagpapatakbo ng isang agent sa isang server, doon ka muna magsimula. Saklaw ng aming gabay sa pagpapatakbo ng coding agent sa isang VPS ang single-agent na setup mula simula hanggang wakas. Ipinapalagay ng Omnigent na mayroon ka na ng setup na ito. Sa mas malawak na larangan ng self-hosted AI agents, pinipili mo mismo ang mga agent. Mas mabuting unang basahin ang pag-alam kung paano talaga gumagana ang mga agent kung bago sa iyo ang mga terminong ginagamit dito.

Ibang axis din ang Omnigent kumpara sa connector layer. Ang gawaing gaya ng pagbibigay sa mga agent ng access sa sarili mong data source ay tungkol sa kung ano ang maaaring maabot ng isang agent. Ang Omnigent ay tungkol sa kung aling agent ang tatakbo, sa anong pagkakasunod-sunod, at sa ilalim ng anong mga limitasyon. Maaaring kailanganin mo ang dalawang ito nang sabay, at hindi sila nagsasapawan.

Mga kailangan bago mag-install

• Python 3.12 o mas bago. Idinedeklara ng published package ang requires-python >= 3.12.
• tmux, dahil tumatakbo rito ang mga terminal harness.
• Kahit isang vendor CLI na naka-install na at naka-login na.
• Node.js 22 lamang kung magbu-build mula sa git checkout. Kasama na sa wheel sa PyPI ang built web assets, kaya hindi nangangailangan ng Node ang karaniwang installation.

Mag-install ng naka-pin na release, hindi ng main

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

Hindi dekorasyon ang bahaging sh -s --. Kung wala ito, ituturing ng sh ang --version bilang sarili nitong option at hindi makikita ng installer ang flag, kaya mai-install ang pinakabagong bersyon sa araw na iyon. Sa repository na naglalabas ng breaking changes bawat ilang linggo, ito ang pagkakaiba ng reproducible na server at hindi inaasahang resulta.

Ginagamit ng installer ang uv, ang Python package manager ng Astral, at nag-aalok itong i-install muna ang uv kung wala pa ito. Kung mayroon na ang uv, laktawan ang script:

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

Pareho ang pattern para sa extras, at inuulit ang flag: --extra e2b --extra kubernetes sa script, o "omnigent[e2b,kubernetes]" gamit ang uv. Tandaan na v0.7.0 ang git tag, samantalang 0.7.0 ang package version sa PyPI.

Inilalagay ng uv ang binary sa directory na iniuulat ng uv tool dir --bin, karaniwang ~/.local/bin, at nag-aalok ang installer na idagdag ito sa shell profile mo. Kung hindi agad makita ang command pagkatapos ng malinis na installation, ito ang dahilan. Suriin kung ano ang aktuwal na na-install:

omni upgrade --check

Ikinukumpara nito ang naka-install na version sa pinakabagong published version at sinasabi kung may available na upgrade, nang hindi ito isinasagawa. Iisang program lang ang omni at omnigent na magkaiba ang pangalan.

Ituro ito sa isang model provider

omni setup

Hinahanap ng wizard ang mga credential na mayroon na sa iyong environment at hinihingi ang mga kulang. Sinusuportahan nito ang API keys, vendor subscriptions, mga gateway gaya ng OpenRouter o Ollama, at mga Databricks workspace. Kung nagpapatakbo ka na sa parehong machine ng local model server gamit ang Ollama, ituro ang isang gateway dito para hindi lumabas sa machine ang network traffic.

Isang minimal na multi-agent run

Nasa repository ang mga example agent, kaya i-clone ang parehong tag na na-install mo sa halip na main.

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

Ang Polly ang multi-agent coding orchestrator na kasama sa repo. Sa configuration nito, idinedeklara ang mga sub-agent na may pangalang claude_code, codex, opencode, cursor, hermes at pi, pati ang isang rule na siyang dahilan kung bakit sulit patakbuhin ang buong exercise: palaging ibang vendor ang gumagawa ng review kaysa sa implementer. Walang code na direktang sinusulat si Polly. Nagpa-plano ito, hinahati ang goal sa mga work item, dine-delegate ang bawat isa, at ipinapadala ang bawat diff sa reviewer mula sa ibang vendor.

Bago mag-delegate ng anuman, nagpapatakbo si Polly ng preflight check upang malaman kung aling sub-agent CLI ang aktuwal na available sa machine. Kung isang vendor CLI lamang ang naka-install, walang mapagpapasahan ng diff, kaya mag-install muna ng hindi bababa sa dalawa bago suriin ang output. Ang Debby, ang isa pang example na kasama sa repo, ay isang debate agent na may dalawang head: isang Claude at isang GPT:

omni debby

Maikling paraan ito upang makumpirmang naka-configure ang dalawang provider, dahil kailangan nito ang pareho bago ito makapaglabas ng anuman.

Idinedeklara bilang mga tool ang mga sub-agent

YAML ang format ng agent file. Tinutukoy ng executor ang harness, model, at authentication. Naglalaman ang tools ng mga MCP (model context protocol) server, Python function, at sub-agent. Ang sub-agent ay isang tool na may type: agent at sarili nitong executor. Ito ang mekanismong nasa likod ng lahat ng nabanggit.

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

Galing ang mga model ID na iyon sa sariling docs/AGENT_YAML_SPEC.md example ng project, at mga pangalang hosted ng Databricks ang mga ito. Palitan ang harness at model ng anumang omni setup na naka-configure sa iyong machine. Kabilang sa iba pang harness value sa spec ang antigravity, copilot, kimi, qwen, at acp:<slug> para sa anumang gumagamit ng generic protocol. Sinusuportahan din ng spec ang pass_history: true sa isang sub-agent. Ipinapasa nito sa sub-agent ang parent conversation. May token cost ito sa bawat delegation, kaya huwag itong i-enable para sa mga sub-agent na kailangan lamang ang task na nasa harap nila. Kapag ang prompt ng isang coder ay nagsasabi rito na gumawa ng pinakamaliit na pagbabagong gumagana, ipinapasa nito sa reviewer ang diff na sapat ang ikli para aktuwal na mabasa. Mas mahalaga ito rito kaysa sa model na pipiliin mo para sa alinmang role.

Bakit dapat sa VPS tumakbo ang matagal na orchestration

Ang multi-agent run ay hindi command na natatapos sa loob ng dalawang minuto. Kailangan nitong magplano, mag-delegate, maghintay sa parallel git worktrees, mag-review, at mag-revise. Kapag isinara ang takip ng laptop, matatapos ang lahat ng ito. Patuloy na tumatakbo ang VPS (virtual private server) at nananatiling nakakonekta sa network, kaya nagpapatuloy ang session kahit hindi mo ito mino-monitor.

omnigent server --background
omnigent server status

Nagho-host ang server ng web user interface sa port 6767. Iniuulat ng omnigent server status kung may tumatakbo, at pinapatigil ito ng omnigent stop. Sa mga release bago ang v0.7.0, omni server start ang ginagamit dito, ngunit inalis na ito. Kaya hindi tutugma sa aktuwal na resulta sa terminal mo ang mga lumang write-up at screenshot.

Huwag i-publish ang 6767 sa public address. May dalawang ligtas na setup. Panatilihing sarado ang port sa firewall at i-forward ito sa SSH gamit ang ssh -N -L 6767:localhost:6767 you@your-server, pagkatapos ay buksan ang web interface sa http://localhost:6767 sa sarili mong machine. O mag-terminate ng TLS (transport layer security) sa harap nito at i-enable ang authentication:

OMNIGENT_AUTH_ENABLED=1 omnigent server --background

Karaniwang firewall configuration ang bahaging iyon, at saklaw ito ng mga pangunahing kaalaman sa ufw firewall para sa VPS. Kung nagpapatakbo na ang server ng mga container sa likod ng Traefik sa harap ng ilang Docker Compose app, isa pang service ang Omnigent na sumusunod sa parehong pattern.

Para sa container deploy, nasa deploy/ directory ng repository ang Compose setup: ang ./bootstrap.sh ang nagge-generate ng secrets sa .env, at ang docker compose up -d ang nagsisimula sa Omnigent at Postgres sa port 6767. Pinipili ng DATABASE_URL ang Postgres o SQLite, at ang default ng OMNIGENT_AUTH_ENABLED sa loob ng mga container ay 1. Ito ang tamang default para sa anumang naaabot mula sa labas.

Tungkol sa sizing, tinatantiya ng deploy notes na nasa 512 MB hanggang 1 GB ang working set ng server, at itinatakda ng Fly.io config ang 1 GB. Para lamang iyon sa supervisor. Hiwalay na process ang bawat sub-agent, at may sarili itong checkout at model client. Kaya i-size ang server batay sa mga agent. Kapag gumagana na ang server, nirerehistro ng omnigent login https://your-host na sinusundan ng omnigent host https://your-host ang laptop mo rito, at ipinagpapatuloy ng omnigent attach <session_id> ang isang tumatakbong session mula sa ibang device.

I-sandbox ang bawat sub-agent bago ka umalis

Ang Omnigent ay naglalabas ng operating system level sandbox na tinatawag na Omnibox. Sa Linux, gumagamit ito ng bubblewrap namespaces at seccomp, kaya ang kernel ang nagpapatupad ng boundary sa halip na ang prompt ng agent. Hindi makakalusot ang prompt-injected agent sa kernel rule sa pamamagitan lamang ng mga pakiusap. I-install muna ang dependency:

sudo apt install bubblewrap

Nasa os_env ang configuration sa agent file:

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: []

Read-only ang working directory hanggang ilista mo ito sa write_paths, kaya hindi makakasulat sa labas ng workspace ang agent kapag nagkamali ito. Nananatiling nakatago ang dotfiles maliban kung pangalanan ang mga ito sa cwd_allow_hidden. Ibig sabihin, hindi basta-basta mailalantad ng malawak na read grant ang .ssh o .aws. Itakda ang egress_rules upang dumaan ang lahat ng HTTP at HTTPS traffic sa default-deny proxy, at isulat ang bawat rule bilang "METHODS host/path-glob". Mas mahigpit pa ang credential_proxy: placeholder lamang ang hawak ng agent, at pinapalitan ito ng proxy ng totoong secret habang lumalabas ang request. Kaya walang kapaki-pakinabang na secret na malalabas kapag na-leak ang transcript. Sa multi-harness setup, may sariling sandbox block ang bawat sub-agent sa sarili nitong config file sa ilalim ng agents/. Dahil dito, maaaring pagbawalan sa network ang reviewer habang nananatili itong available sa implementer.

Nasa documentation ang limitasyon, at mahalagang tandaan ito. Sinasaklaw ng OS sandbox ang sys_os_* tool calls at terminals. Hindi nito sinasaklaw ang MCP servers, at hindi rin nito sinasaklaw ang mismong Omnigent supervisor process. Ang MCP server na sinimulan mo ay tumatakbo sa labas ng sandbox gamit ang permissions mo. Dahil sa gap na ito, mas matibay pa rin ang pattern na gumamit ng isang throwaway machine para sa bawat agent. Iyan ang paksa ng pagpapatakbo ng coding agents sa disposable VM. Ang kabilang bahagi ng trabaho ay credentials. Mas nagiging mahirap, hindi mas madali, ang pag-iwas na maabot ng agent ang secrets kapag anim na sub-agent ang gumagamit ng iisang host.

Ang spend limits ay mga policy na idinedeklara sa parehong file:

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]

Ang isang run na nagpaplano gamit ang isang vendor, nag-iimplement gamit ang pangalawa, at nagre-review gamit ang pangatlo ay sabay-sabay na gumagastos sa tatlong lugar. Kaya itakda ang cap bago ang unang unattended run, hindi pagkatapos ng unang invoice. Kasama rin sa built-ins ang max_tool_calls_per_session at ask_on_os_tools, na humihingi ng approval bago ang file at shell operations. Direktang naaangkop dito ang aming mga tala tungkol sa pagkontrol sa gastos ng AI agents sa isang VPS, at mas mahalaga pa ito rito dahil pinaparami ng parallel sub-agents ang burn rate.

Gaano kabilis ang pag-usad ng repository na ito?

[
  {
    "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
  }
]

Iyan ang mga petsa ng release na inilathala sa sariling releases page ng proyekto, batay sa datos noong 3 August 2026. May 7 na tagged release sa pagitan ng 2026-06-19 at 2026-07-27, at ang pinakamahabang pagitan ng alinmang dalawang release ay 11 araw. Na-release ang v0.5.1 sa parehong araw ng release na nauna rito. Hindi isinama sa chart ang unang release na 0.1.1 noong 16 June 2026 dahil walang naunang tag na maaaring gawing batayan ng sukat.

Dalawa sa mga release na iyon ang nagbago sa mga command na naidokumento na sa mga guide. Inalis ng v0.7.0 ang omni server start at pinalitan ito ng omni server --background. Pinalitan ng v0.6.0 ang pangalan ng omnigent[memory] extra at ginawa itong omnigent[hindsight], kaya mabibigo ang install line na kinopya mula sa write-up noong June kapag ginamit sa build noong July. Ito ang dahilan kung bakit dapat gamitin ang --version sa install command at maglagay ng tag sa git clone mo; hindi ito usapin ng style preference.

Mga bagay na hindi ko pa ipagkakatiwala rito

Noong August 2026, mayroon ang repository ng humigit-kumulang 8.1k stars, 1.2k forks, at mga 350 open issue, habang pitong linggo pa lamang ang unang public release nito. Sinusukat ng stars ang interes, at hindi katumbas ng maturity ang interes. Nakasaad sa proyekto na alpha ito, at ipinapakita ng release history sa itaas na alpha nga ang ibig sabihin nito.

• Hindi ko ito patatakbuhin sa host na naglalaman ng production credentials, dahil hindi saklaw ng sandbox ang MCP servers o ang supervisor.
• Hindi ko iiwan ang isang run nang walang nagbabantay kung walang cost_budget policy, dahil maaaring sabay na maningil ang tatlong vendor at walang ibang pipigil sa kanila.
• Hindi ko ilalantad ang server sa public IP address nang hindi naka-set ang OMNIGENT_AUTH_ENABLED at walang TLS sa harap nito.
• Hindi ko pa ituturing na stable sa pagitan ng minor version ang agent YAML, kaya i-pin ang version at basahin ang release notes bago mag-upgrade.

May isa pang dapat malaman bago ka mabigla: nagdagdag ang v0.6.0 ng anonymised usage telemetry, at inilalarawan ito ng proyekto sa isang nakalaang telemetry page. Basahin ang page na iyon at gumawa ng sinadyang desisyon kung humahawak ang machine ng client work.

Ang tunay na mahusay na ginagawa ng Omnigent sa ngayon ay ang mismong layuning pinagdisenyo rito. Mayroon kang tatlo o apat na agent CLI, binabayaran mo na ang mga ito, at gusto mong may isang magsulat habang nagre-review ang isa pa. Gumagana na ito ngayon, sa isang machine, na may aktuwal na sandboxing sa Linux. Ituring na promising ngunit hindi pa tapos ang lahat ng higit pa rito.

FAQ

Agent ba ang Omnigent, o isang bagay na nagpapatakbo ng mga agent?

Nagpapatakbo ito ng mga agent. Ang Omnigent ay isang meta-harness: sinisimulan nito ang mga vendor CLI na na-install mo na, gaya ng Claude Code, Codex, o OpenCode, binibigyan ang bawat isa ng gawain, at sinusubaybayan ang mga resulta sa iisang session. Wala itong sariling model. Kaya naiiba ito sa isang framework, kung saan nagsusulat ka ng Python laban sa isang library at ang sarili mong program ang nagiging agent.

Kailangan ko bang ma-install ang Claude Code at Codex bago maging kapaki-pakinabang ang Omnigent?

Kailangan mong magkaroon ng kahit isang vendor CLI na naka-install at naka-login, dahil pinapatakbo ng Omnigent ang mga program na iyon sa halip na palitan ang mga ito. Para sa kasamang Polly example, kailangan mo ng dalawa o higit pa mula sa magkakaibang vendor. Ayon sa rule ng Polly, laging ibang vendor ang gumagawa ng review kaysa sa implementer. Kaya kung iisang CLI lamang ang mayroon, walang pangalawang vendor na maaaring padalhan ng diff.

Paano ako mag-i-install ng partikular na bersyon ng Omnigent sa halip na ang pinakabago?

Ipasa ang --version sa install script gamit ang sh -s --, gaya ng nasa sh -s -- --version 0.7.0. Kung wala ang -s --, ang flag ay gagamitin mismo ng sh at ii-install ng script ang pinakabagong release. Kung mayroon ka nang uv, pareho ang ginagawa ng uv tool install --force --python 3.12 "omnigent==0.7.0". Ang git tag ay v0.7.0, samantalang ang PyPI version string ay 0.7.0.

Sapat na ba ang Omnibox sandbox para magpatakbo ng mga agent nang walang supervision?

Malakas ito para sa mga sakop nito at malinaw kung ano ang hindi nito sakop. Sa Linux, gumagamit ito ng bubblewrap at seccomp, kaya kernel ang nagpapatupad ng mga limitasyon sa file at network at hindi maaaring i-bypass ng agent ang mga ito. Nakasaad sa documentation na nalalapat ito sa sys_os_* tool calls at terminal, ngunit hindi sa MCP servers o sa Omnigent supervisor process. Dahil dito, tumatakbo ang isang MCP server gamit ang normal mong permissions. Kaya nananatiling mas matibay na isolation para sa unattended work ang isang disposable virtual machine para sa bawat agent.

Gaano karaming memory ang kailangan ng Omnigent server sa isang VPS?

Ayon sa deploy notes ng project, kailangan ng server ng working set na humigit-kumulang 512 MB hanggang 1 GB, at naka-configure sa 1 GB ang Fly.io configuration nito. Sapat ito para sa supervisor at web interface sa port 6767 lamang. Hiwalay na process ang bawat sub-agent, na may sarili nitong working copy at model client. Gumagamit din ng parallel git worktrees ang mga Polly-style run. Kaya maglaan ng RAM at disk batay sa bilang ng mga agent na plano mong patakbuhin nang sabay, hindi batay sa server lamang.