Omnigent என்றால் என்ன? Agent CLI-களை நிர்வகிக்கும் முறை

Omnigent என்றால் என்ன

Omnigent என்பது ஒரு open source meta-harness ஆகும். இது நீங்கள் ஏற்கனவே நிறுவியுள்ள agent command line tools (CLIs)-ஐ இயக்கும் ஒரு orchestration layer ஆகும். இது Claude Code, Codex, Cursor, OpenCode, Hermes அல்லது Pi ஆகியவற்றை மாற்றாது. மாறாக, இது அவற்றை இயக்கி, ஒவ்வொன்றிற்கும் ஒரு பணியை வழங்கி, ஒரே policy தொகுப்பைக் கொண்டு ஒரே session-க்குள் அவற்றின் முடிவுகளைக் கண்காணிக்கும். Databricks இந்த repository-ஐ ஜூன் 2026-ல் Apache 2.0 உரிமத்தின் கீழ் வெளியிட்டது. அதன் முகப்புப் பக்கத்தில் இன்னும் Status: alpha என்று குறிப்பிடப்பட்டுள்ளது.

இதன் நடைமுறை நோக்கம் மிகத் தெளிவானது. நீங்கள் ஒரு agent-ஐ YAML கோப்பில் ஒருமுறை விவரிக்கிறீர்கள், அதை இயக்கும் harness-ன் பெயரை குறிப்பிடுகிறீர்கள். அந்த ஒரு வரியை மாற்றினால் போதும், அதே agent வேறொரு vendor-ன் CLI-ல் இயங்கும். உங்கள் setup-ல் வேறு எதுவும் மாறாது. ஏனெனில், Omnigent agent-களுக்குள் இருக்கும் loop-ஐக் கட்டுப்படுத்தாமல், அவற்றுக்கு மேலே உள்ள loop-ஐக் கட்டுப்படுத்துகிறது.

meta-harness என்றால் என்ன, அது framework-லிருந்து எவ்வாறு வேறுபடுகிறது?

Harness என்பது ஒரு model-ஐ loop-க்குள் இயக்கும் நிரலாகும். இது உங்கள் prompt-ஐப் படித்து, tools-ஐ அழைத்து, கோப்புகளைத் திருத்தி, முடிவுகளைத் தெரிவிக்கும். Claude Code ஒரு harness ஆகும். Codex ஒரு harness ஆகும். நீங்கள் அதை install செய்து, login செய்தவுடன், அது தானாகவே இயங்கும்.

Framework என்பது நீங்கள் code எழுதும் ஒரு library ஆகும். நீங்கள் அதை import செய்து, Python-ல் படிகளை வரையறுக்கிறீர்கள், உங்கள் நிரலே agent-ஆக மாறுகிறது. அங்கு vendor-ஐ மாற்ற வேண்டுமென்றால், உங்கள் code-ஐத் திருத்த வேண்டும், ஏனெனில் vendor-ன் client உங்கள் நிரலுடன் இணைக்கப்பட்டிருக்கும்.

Meta-harness இவை இரண்டிற்கும் ஒரு படி மேலே உள்ளது. இது harnesses-ஐ child processes-ஆக இயக்கும் ஒரு supervisor ஆகும். Omnigent என்பது vendor CLI-ஐத் தொடங்கி, அதற்குப் பணிகளை வழங்கி, வரும் முடிவுகளைப் படிக்கும். நீங்கள் ஏற்கனவே install செய்த CLI-ஐயும், அதற்கான subscription அல்லது API (application programming interface) key-ஐயும் நீங்கள் தொடர்ந்து பயன்படுத்தலாம். இதுவே முழுமையான வேறுபாடு, மேலும் இந்த tool யாருக்கானது என்பதை இதுவே தீர்மானிக்கிறது: ஏற்கனவே பல agent CLI-களைப் பயன்படுத்தும் நபர்கள், ஒவ்வொரு terminal-ஆகத் தனித்தனியாக இயக்குவதில் சோர்வடைந்தவர்களுக்கானது இது.

ஒரு orchestration layer என்ன சிக்கலைத் தீர்க்கிறது?

• Vendor-ஐ மாற்றும் செலவு குறைவு. Agent definition-ல் harness மற்றும் model தரவுகளாக இருப்பதால், ஒரு vendor-லிருந்து மற்றொரு vendor-க்கு role-ஐ மாற்றுவது என்பது YAML file-ல் ஒரு சிறிய திருத்தம் மட்டுமே, முழுமையாக மீண்டும் எழுதுவது அல்ல.
• Vendor-களைக் கடந்து ஆய்வு செய்யலாம். ஒரு model உருவாக்கிய diff-ஐ மற்றொரு நிறுவனத்தின் model மூலம் ஆய்வு செய்ய முடியும். ஒரே குடும்பத்தைச் சேர்ந்த இரண்டு model-கள் பெரும்பாலும் ஒரே மாதிரியான குறைபாடுகளைக் கொண்டிருக்கும், எனவே அதே vendor-ன் இரண்டாவது கருத்து அதிக மதிப்புடையது அல்ல.
• Policy-க்கு ஒரே இடம். செலவு வரம்புகள் (spend caps) மற்றும் ஒப்புதல் கோரிக்கைகள் (approval prompts) agent file-ல் வரையறுக்கப்படுகின்றன, இவை அதன் கீழ் உள்ள அனைத்து sub-agent-களுக்கும் பொருந்தும்.
• Session எந்த ஒரு கருவியையும் விட நீண்ட காலம் நீடிக்கும். ஒரு transcript பல CLI-கள் செய்த வேலைகளை உள்ளடக்கியது, எனவே நான்கு வெவ்வேறு scrollback-களை இணைக்க வேண்டிய அவசியமின்றி என்ன நடந்தது என்பதை உங்களால் படித்துப் பார்க்க முடியும்.

இதற்கான செலவு அந்த layer-ன் செயல்பாட்டிலேயே உள்ளது. Omnigent-ல் உள்ள ஒவ்வொரு bug-ம், முன்பு தனித்துச் செயல்பட்ட agent-க்கும் உங்களுக்கும் இடையே ஒரு தடையாக அமைகிறது. Alpha நிலையில் இது ஒரு கோட்பாட்டு ரீதியான சிக்கல் அல்ல, உண்மையான செலவாகும்.

Multi-agent harness, single agent கருவிகளுக்கு அடுத்ததாக எங்கு பொருந்துகிறது

நீங்கள் ஒரு server-ல் இதுவரை ஒரு agent-ஐயும் இயக்கவில்லை என்றால், அங்கிருந்து தொடங்கவும். VPS-ல் coding agent-ஐ இயக்குவது குறித்த எங்களது வழிகாட்டி, single agent சூழலை முழுமையாக விளக்குகிறது; Omnigent-ஐப் பயன்படுத்துவதற்கு இந்த அடிப்படை அமைப்பு ஏற்கனவே உங்களிடம் இருக்க வேண்டும் என்று எதிர்பார்க்கப்படுகிறது. Self-hosted AI agents குறித்த பரந்த களத்தில் நீங்கள் agent-களைத் தேர்வு செய்யலாம். இங்குள்ள கலைச்சொற்கள் உங்களுக்குப் புதியவை என்றால், agent-கள் எவ்வாறு செயல்படுகின்றன என்பதைக் கற்றுக்கொள்வது சிறந்த தொடக்கமாகும்.

Omnigent என்பது connector layer-லிருந்து மாறுபட்ட ஒரு பரிமாணம். Agent-களுக்கு உங்கள் சொந்த தரவு மூலங்களை அணுக அனுமதி அளிப்பது போன்ற பணிகள், ஒரு agent எதை அடைய முடியும் என்பது பற்றியது. Omnigent என்பது எந்த agent, எந்த வரிசையில், என்ன கட்டுப்பாடுகளுடன் இயங்க வேண்டும் என்பது பற்றியது. இவை இரண்டையும் நீங்கள் ஒரே நேரத்தில் பயன்படுத்த விரும்பலாம்; இவை ஒன்றுடன் ஒன்று குறுக்கிடுவதில்லை.

நிறுவுவதற்கு முன் உங்களுக்குத் தேவையானவை

• Python 3.12 அல்லது அதற்குப் புதிய பதிப்பு. வெளியிடப்பட்ட தொகுப்பு requires-python >= 3.12-ஐக் குறிப்பிடுகிறது.
• tmux, ஏனெனில் terminal harnesses இதற்குள் இயங்குகின்றன.
• ஏற்கனவே நிறுவப்பட்டு, login செய்யப்பட்ட குறைந்தது ஒரு vendor CLI.
• git checkout-லிருந்து build செய்தால் மட்டுமே Node.js 22 தேவை. PyPI-ல் உள்ள wheel ஏற்கனவே build செய்யப்பட்ட web assets-ஐக் கொண்டிருப்பதால், சாதாரண நிறுவலுக்கு Node தேவையில்லை.

main-க்கு பதிலாக pinned release-ஐ நிறுவுதல்

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

sh -s -- பகுதி அலங்காரத்திற்காக அல்ல. அது இல்லையென்றால், sh ஆனது --version-ஐ தனது சொந்த விருப்பமாக (option) எடுத்துக்கொள்ளும். இதனால் installer-க்கு அந்த flag கிடைக்காது, எனவே அன்றைய தேதியில் உள்ள புதிய பதிப்பு எதுவோ அதுவே நிறுவப்படும். சில வாரங்களுக்கு ஒருமுறை மாற்றங்களை வெளியிடும் repository-களில், இது ஒரு நிலையான சூழலுக்கும் (reproducible box) எதிர்பாராத சிக்கல்களுக்கும் இடையிலான வித்தியாசமாகும்.

இந்த installer, Astral-ன் Python package manager ஆன uv-ஐப் பயன்படுத்துகிறது. uv இல்லையென்றால், முதலில் அதை நிறுவ இது பரிந்துரைக்கும். uv ஏற்கனவே இருந்தால், script-ஐத் தவிர்க்கவும்:

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

Extras-ம் இதே முறையைப் பின்பற்றுகின்றன, flag மீண்டும் பயன்படுத்தப்படுகிறது: script-ல் --extra e2b --extra kubernetes அல்லது uv-உடன் "omnigent[e2b,kubernetes]". git tag v0.7.0 என்றும், PyPI-ல் உள்ள package version 0.7.0 என்றும் குறிப்பிடப்பட்டுள்ளது என்பதை கவனிக்கவும்.

uv ஆனது binary-ஐ uv tool dir --bin குறிப்பிடும் directory-ல் வைக்கும், இது பொதுவாக ~/.local/bin ஆகும். installer உங்கள் shell profile-ல் இதைச் சேர்க்கப் பரிந்துரைக்கும். புதிய நிறுவலிற்குப் பிறகு command கிடைக்கவில்லை என்றால், அதற்குக் காரணம் இதுதான். நீங்கள் எதை நிறுவியுள்ளீர்கள் என்பதைச் சரிபார்க்கவும்:

omni upgrade --check

இது நிறுவப்பட்ட பதிப்பை, வெளியிடப்பட்ட சமீபத்திய பதிப்போடு ஒப்பிட்டு, upgrade ஏதேனும் உள்ளதா என்று தெரிவிக்கும்; ஆனால் upgrade-ஐச் செய்யாது. omni மற்றும் omnigent ஆகிய இரண்டும் ஒரே program-ன் இரண்டு பெயர்கள் ஆகும்.

Model provider-ஐக் குறிப்பிடுதல்

omni setup

உங்கள் environment-ல் ஏற்கனவே உள்ள credentials-ஐ இந்த wizard கண்டறியும்; விடுபட்ட விவரங்களை உள்ளிடுமாறு கேட்கும். இது API keys, vendor subscriptions, OpenRouter அல்லது Ollama போன்ற gateways மற்றும் Databricks workspaces ஆகியவற்றை நிர்வகிக்கிறது. நீங்கள் ஏற்கனவே அதே machine-ல் Ollama மூலம் local model server-ஐ இயக்குகிறீர்கள் என்றால், அந்த gateway-ஐ அதற்குச் சுட்டிக்காட்டவும். இதன் மூலம் network traffic அந்த machine-ஐ விட்டு வெளியேறாது.

குறைந்தபட்ச multi-agent இயக்கம்

மாதிரி agents களஞ்சியத்தில் (repository) உள்ளன. எனவே, main-க்கு பதிலாக நீங்கள் நிறுவிய அதே tag-ஐ clone செய்யவும்.

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 ஆகும். இதன் கட்டமைப்பு (config), claude_code, codex, opencode, cursor, hermes மற்றும் pi எனப் பெயரிடப்பட்ட sub-agents-ஐயும், இந்தச் செயல்பாட்டை பயனுள்ளதாக்கும் ஒரு விதியையும் கொண்டுள்ளது: குறியீட்டைச் செயல்படுத்துபவரைத் தவிர வேறொரு vendor-ஆல் மட்டுமே ஆய்வு (review) செய்யப்பட வேண்டும். Polly தானாக எந்தக் குறியீட்டையும் எழுதுவதில்லை. இது திட்டமிடுகிறது, இலக்கை வேலைகளாகப் பிரிக்கிறது, ஒவ்வொன்றையும் ஒப்படைக்கிறது, மேலும் ஒவ்வொரு diff-ஐயும் வேறொரு vendor-ன் reviewer-க்கு அனுப்புகிறது.

எதையும் ஒப்படைக்கும் முன், கணினியில் எந்தெந்த sub-agent CLI-கள் உள்ளன என்பதைச் சரிபார்க்க Polly ஒரு preflight சோதனையை நடத்துகிறது. ஒரே ஒரு vendor CLI மட்டும் நிறுவப்பட்டிருந்தால், diff-ஐ ஒப்படைக்க யாரும் இருக்க மாட்டார்கள். எனவே, முடிவை மதிப்பிடுவதற்கு முன் குறைந்தது இரண்டையாவது நிறுவவும். Debby என்பது மற்றுமொரு மாதிரி agent; இது இரண்டு தலைகளைக் கொண்ட விவாத agent (debate agent), ஒன்று Claude மற்றும் மற்றொன்று GPT:

omni debby

இரண்டு providers-ம் சரியாக உள்ளமைக்கப்பட்டுள்ளனவா என்பதை உறுதிப்படுத்த இது ஒரு எளிய வழியாகும், ஏனெனில் எதையும் சொல்வதற்கு இரண்டுமே தேவைப்படும்.

Sub-agents கருவிகளாக அறிவிக்கப்படுகின்றன

Agent கோப்பு YAML வடிவில் இருக்கும். executor என்பது harness, model மற்றும் authentication ஆகியவற்றைக் குறிப்பிடுகிறது. tools என்பது MCP (model context protocol) servers, Python functions மற்றும் 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

அந்த model ids-கள் திட்டத்தின் சொந்த docs/AGENT_YAML_SPEC.md உதாரணத்திலிருந்து பெறப்படுகின்றன, மேலும் அவை Databricks-ல் ஹோஸ்ட் செய்யப்பட்ட பெயர்களாகும். harness மற்றும் model ஆகியவற்றை உங்கள் கணினியில் omni setup அமைத்துள்ள மதிப்புகளைக் கொண்டு மாற்றவும். பொதுவான protocol-ஐப் பயன்படுத்தும் எதற்கும், spec-ல் உள்ள பிற harness மதிப்புகளில் antigravity, copilot, kimi, qwen மற்றும் acp:<slug> ஆகியவை அடங்கும். இந்த spec, sub-agent-ல் pass_history: true வசதியையும் ஆதரிக்கிறது; இது parent உரையாடலை sub-agent-க்கு வழங்குகிறது. ஒவ்வொரு முறை பணி ஒப்படைக்கும்போதும் இது tokens-ஐச் செலவழிக்கும் என்பதால், தங்களுக்கு வழங்கப்பட்ட பணியை மட்டும் செய்யும் sub-agents-க்கு இதைத் தவிர்க்கவும். ஒரு coder-ன் prompt, செயல்படக்கூடிய மிகச்சிறிய மாற்றத்தைச் செய்ய அறிவுறுத்துமெனில், அது அதன் reviewer-க்கு எளிதாகப் படிக்கக்கூடிய ஒரு சிறிய diff-ஐ வழங்கும்; நீங்கள் எந்த model-ஐத் தேர்வு செய்கிறீர்கள் என்பதை விட, இதுவே இங்கு முக்கியமானது.

நீண்ட நேரம் இயங்கும் ஆர்கெஸ்ட்ரேஷன் ஏன் VPS-ல் இருக்க வேண்டும்

பல ஏஜெண்டுகள் (multi-agent) இயங்கும் பணி என்பது இரண்டு நிமிடங்களில் முடிந்துவிடும் கட்டளை அல்ல. திட்டமிடுதல், பணிகளைப் பிரித்துக் கொடுத்தல், இணையாக நடக்கும் git பணிகளுக்காகக் காத்திருத்தல், ஆய்வு செய்தல் மற்றும் திருத்துதல் எனப் பல நிலைகள் உள்ளன. மடிக்கணினியை மூடினால் இவை அனைத்தும் நின்றுவிடும். ஒரு VPS (virtual private server) எப்போதும் இயங்கிக்கொண்டிருக்கும், அதன் நெட்வொர்க் இணைப்பும் நீடிக்கும். எனவே, நீங்கள் கவனிக்காத நேரத்திலும் அந்த session தொடர்ந்து இயங்கும்.

omnigent server --background
omnigent server status

இந்த சர்வர் 6767 என்ற போர்ட்டில் ஒரு இணைய பயனர் இடைமுகத்தை (web user interface) வழங்குகிறது. omnigent server status ஏதேனும் ஒன்று இயங்குகிறதா என்பதைத் தெரிவிக்கும், omnigent stop அதை நிறுத்தும். v0.7.0-க்கு முந்தைய பதிப்புகளில் இது omni server start என்று இருந்தது, அது இப்போது நீக்கப்பட்டுவிட்டது. எனவே, பழைய கட்டுரைகள் மற்றும் ஸ்கிரீன்ஷாட்கள் உங்கள் டெர்மினலில் நடப்பவற்றுடன் ஒத்துப்போகாது.

6767 என்ற போர்ட்டை பொது முகவரியில் (public address) வெளியிட வேண்டாம். இரண்டு முறைகள் பாதுகாப்பானவை. ஃபயர்வால் மூலம் அந்த போர்ட்டை மூடி வைத்துவிட்டு, ssh -N -L 6767:localhost:6767 you@your-server மூலம் SSH வழியாக அதை ஃபார்வர்ட் (forward) செய்யவும். பிறகு உங்கள் கணினியில் http://localhost:6767 என்ற முகவரியில் இணைய இடைமுகத்தைத் திறக்கவும். அல்லது, அதற்கு முன்னால் TLS (transport layer security) மூலம் இணைப்பை முடித்துவிட்டு (terminate), அங்கீகாரத்தை (authentication) இயக்கவும்:

OMNIGENT_AUTH_ENABLED=1 omnigent server --background

அதற்கான ஃபயர்வால் அமைப்புகள் சாதாரணமானவை, அவை VPS-க்கான ufw ஃபயர்வால் அடிப்படைகள் என்ற பகுதியில் விளக்கப்பட்டுள்ளன. ஏற்கனவே பல Docker Compose செயலிகளுக்கு முன்னால் Traefik என்ற அமைப்பைப் பயன்படுத்தி கன்டெய்னர்களை இயக்கினால், Omnigent-ஐயும் அதே முறையில் ஒரு கூடுதல் சேவையாகச் சேர்க்கலாம்.

கன்டெய்னர் முறையில் நிறுவுவதற்கு, களஞ்சியத்தின் (repository) deploy/ கோப்பகத்தில் 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) தனித்தனி செயல்முறையாக (process) இயங்கி, அதன் சொந்த செக்-அவுட் மற்றும் மாடல் கிளையண்டைக் கொண்டிருக்கும். எனவே, ஏஜெண்டுகளின் எண்ணிக்கைக்கு ஏற்ப சர்வரின் அளவைத் தீர்மானிக்கவும். சர்வர் இயங்கிய பிறகு, omnigent login https://your-host மற்றும் அதைத் தொடர்ந்து omnigent host https://your-host ஆகியவற்றை இயக்கினால் உங்கள் மடிக்கணினி அதனுடன் பதிவு செய்யப்படும். omnigent attach <session_id> மூலம் மற்றொரு சாதனத்திலிருந்து இயங்கிக்கொண்டிருக்கும் session-ஐ மீண்டும் தொடரலாம்.

ஒவ்வொரு sub-agent-ஐயும் வெளியேறும் முன் sandbox செய்யவும்

Omnigent, Omnibox எனப்படும் operating system level sandbox-ஐ வழங்குகிறது. Linux-ல் இது bubblewrap namespaces மற்றும் seccomp-ஐப் பயன்படுத்துகிறது; எனவே, agent-ன் prompt-ஐ விட kernel-லே எல்லைகளைக் கடுமையாக அமல்படுத்துகிறது. Prompt-injection செய்யப்பட்ட ஒரு agent-ஆல் kernel விதியை மீறி வெளியேற முடியாது. முதலில் தேவையான dependency-ஐ நிறுவவும்:

sudo apt install bubblewrap

இதற்கான configuration, agent கோப்பில் os_env-ன் கீழ் உள்ளது:

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-ல் குறிப்பிடும் வரை working directory read-only நிலையில் இருக்கும். எனவே, தவறாகச் செயல்படும் ஒரு agent-ஆல் workspace-க்கு வெளியே எதையும் எழுத முடியாது. cwd_allow_hidden-ல் குறிப்பிடப்படாத வரை dotfiles மறைத்தே இருக்கும். இதன் பொருள், ஒரு பொதுவான read grant மூலம் .ssh அல்லது .aws போன்றவை வெளிப்படாது. egress_rules-ஐ அமைத்தால், அனைத்து HTTP மற்றும் HTTPS traffic-ம் default deny proxy வழியாகச் செல்லும்; ஒவ்வொரு விதியும் "METHODS host/path-glob" என எழுதப்படும். credential_proxy இன்னும் ஒரு படி மேலே செல்கிறது: agent ஒரு placeholder-ஐ மட்டுமே வைத்திருக்கும்; request வெளியேறும்போது proxy உண்மையான secret-ஐச் சேர்க்கும். இதனால், transcript கசிந்தாலும் பயனுள்ள தகவல்கள் எதுவும் கிடைக்காது. Multi-harness அமைப்பில், ஒவ்வொரு sub-agent-ம் agents/-ன் கீழ் உள்ள அதன் சொந்த config கோப்பில் தனி sandbox block-ஐக் கொண்டிருக்கும். இதனால், reviewer-க்கு network அணுகலை மறுத்துவிட்டு, implementer-க்கு அதை வழங்க முடியும்.

இதற்கான வரம்பு ஆவணத்தில் குறிப்பிடப்பட்டுள்ளது, அது முக்கியமானது. இந்த OS sandbox, sys_os_* tool calls மற்றும் terminals-க்கு மட்டுமே பொருந்தும். இது MCP servers-ஐயோ அல்லது Omnigent supervisor process-ஐயோ உள்ளடக்காது. நீங்கள் தொடங்கும் ஒரு MCP server, உங்கள் அனுமதியுடன் sandbox-க்கு வெளியே இயங்கும். இந்த இடைவெளி காரணமாகவே, ஒவ்வொரு agent-க்கும் ஒரு தனி throwaway machine-ஐப் பயன்படுத்துவது சிறந்த முறையாகக் கருதப்படுகிறது. இது disposable VM-ல் coding agents-ஐ இயக்குதல் என்ற பகுதியில் விவரிக்கப்பட்டுள்ளது. வேலையின் மற்றொரு பகுதி credentials சார்ந்தது. agent-ன் அணுகலுக்கு வெளியே secrets-ஐ வைத்திருத்தல் என்பது ஆறு sub-agents ஒரே host-ஐப் பகிரும்போது இன்னும் கடினமாகிறது.

Spend limits என்பது கொள்கைகள், அவை அதே கோப்பில் அறிவிக்கப்படுகின்றன:

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-உடன் திட்டமிட்டு, இரண்டாவது vendor-உடன் செயல்படுத்தி, மூன்றாவது vendor-உடன் சரிபார்க்கும் ஒரு run, ஒரே நேரத்தில் மூன்று இடங்களில் செலவை ஏற்படுத்தும். எனவே, முதல் invoice வருவதற்கு முன்பே, unattended run தொடங்குவதற்கு முன்னரே இதற்கான வரம்பை அமைக்கவும். இதில் max_tool_calls_per_session மற்றும் ask_on_os_tools ஆகிய built-in வசதிகளும் உள்ளன; இவை file மற்றும் shell செயல்பாடுகளுக்கு முன் அனுமதி கேட்கும். VPS-ல் AI agent செலவுகளைக் கட்டுப்படுத்துதல் குறித்த எங்கள் குறிப்புகள் இதற்கும் நேரடியாகப் பொருந்தும். பல sub-agents ஒரே நேரத்தில் இயங்கும்போது செலவு விகிதம் பலமடங்கு அதிகரிக்கும் என்பதால், இதில் கூடுதல் கவனம் தேவை.

இந்த 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 August 2026 அன்று பெறப்பட்ட வெளியீட்டுத் தேதிகள் ஆகும். 2026-06-19 மற்றும் 2026-07-27 ஆகியவற்றுக்கு இடையே 7 tagged releases வெளியிடப்பட்டுள்ளன, மேலும் ஏதேனும் இரண்டு வெளியீடுகளுக்கு இடையே இருந்த அதிகபட்ச இடைவெளி 11 நாட்கள் ஆகும். v0.5.1 அதற்கு முந்தைய வெளியீட்டின் அதே நாளில் வெளியிடப்பட்டது. முதல் வெளியீடான 0.1.1, 16 June 2026 அன்று வெளியிடப்பட்டது; இதைக் கணக்கிடுவதற்கு முந்தைய tag இல்லாததால், இது வரைபடத்திலிருந்து தவிர்க்கப்பட்டுள்ளது.

அவற்றில் இரண்டு வெளியீடுகள், ஏற்கனவே வழிகாட்டிகளில் ஆவணப்படுத்தப்பட்டிருந்த கட்டளைகளைச் செயலிழக்கச் செய்தன. v0.7.0 பதிப்பில் omni server start நீக்கப்பட்டு, அதற்குப் பதிலாக omni server --background சேர்க்கப்பட்டது. v0.6.0 பதிப்பில் omnigent[memory] extra என்பது omnigent[hindsight] எனப் பெயர் மாற்றப்பட்டது, எனவே June மாதக் கட்டுரையில் இருந்து நகலெடுக்கப்பட்ட install கட்டளை, July மாத build-ல் இயங்காது. இது உங்கள் install கட்டளையில் --version-ஐப் பயன்படுத்துவதற்கும், உங்கள் git clone-ல் ஒரு குறிப்பிட்ட tag-ஐக் குறிப்பிடுவதற்கும் உள்ள அவசியத்தை வலியுறுத்துகிறது; இது வெறும் பாணி சார்ந்த விருப்பம் அல்ல.

இதை எவற்றில் பயன்படுத்த நான் இன்னும் நம்பவில்லை

ஆகஸ்ட் 2026 நிலவரப்படி, இந்த repository சுமார் 8.1k stars, 1.2k forks மற்றும் ஏறத்தாழ 350 open issues-ஐக் கொண்டுள்ளது. இதன் முதல் public release ஏழு வாரங்களுக்கு முன்புதான் வெளியானது. Stars என்பது ஆர்வத்தை மட்டுமே குறிக்கும், முதிர்ச்சியை அல்ல. இந்தத் திட்டம் alpha நிலையில் இருப்பதாகக் குறிப்பிடுகிறது, மேலும் மேலே உள்ள release history அது alpha-வில்தான் இருப்பதையும் உறுதிப்படுத்துகிறது.

• production credentials-ஐக் கொண்ட ஒரு host-ல் இதை நான் இயக்கமாட்டேன், ஏனெனில் sandbox என்பது MCP servers அல்லது supervisor-ஐ உள்ளடக்கியது அல்ல.
• cost_budget policy இல்லாமல் இதை கவனிக்க ஆள் இல்லாமல் இயக்கமாட்டேன், ஏனெனில் மூன்று vendors ஒரே நேரத்தில் கட்டணம் வசூலிக்க முடியும், அதைத் தடுக்க வேறு வழியில்லை.
• OMNIGENT_AUTH_ENABLED அமைக்கப்படாமலும், முன்னால் TLS இல்லாமலும் இதை public IP address-ல் நான் வெளிப்படுத்தமாட்டேன்.
• agent YAML-ஐ minor versions-க்கு இடையில் நிலையானதாக நான் கருதமாட்டேன், எனவே version-ஐ pin செய்துவிட்டு, upgrade செய்வதற்கு முன் release notes-ஐப் படிக்கவும்.

உங்களுக்கு ஆச்சரியத்தைத் தரும் மற்றொரு விஷயம்: v0.6.0-ல் anonymised usage telemetry சேர்க்கப்பட்டுள்ளது, மேலும் இது குறித்த தகவல்களைத் திட்டத்தின் பிரத்யேக telemetry பக்கத்தில் காணலாம். அந்தப் பக்கத்தைப் படித்துவிட்டு, உங்கள் கணினி வாடிக்கையாளர் பணிகளைக் கையாள்கிறது என்றால், கவனமாக முடிவெடுங்கள்.

Omnigent தற்போது எதற்காக உருவாக்கப்பட்டதோ, அதைச் சிறப்பாகச் செய்கிறது. உங்களிடம் மூன்று அல்லது நான்கு agent CLI-கள் உள்ளன, நீங்கள் ஏற்கனவே அவற்றுக்குக் கட்டணம் செலுத்துகிறீர்கள், மேலும் ஒரு agent எழுதும்போது மற்றொன்று அதைச் சரிபார்க்க வேண்டும் என்று விரும்புகிறீர்கள். இது இப்போது Linux-ல் முறையான sandboxing-உடன், ஒரே கணினியில் சிறப்பாகச் செயல்படுகிறது. இதைத் தாண்டிய அனைத்தையும் நம்பிக்கைக்குரிய ஆனால் முழுமையடையாத அம்சங்களாகக் கருதுங்கள்.

FAQ

Omnigent என்பது ஒரு agent-ஆ அல்லது agent-களை இயக்கும் ஒரு கருவியா?

இது agent-களை இயக்குகிறது. Omnigent ஒரு meta-harness ஆகும்: இது நீங்கள் ஏற்கனவே நிறுவியுள்ள Claude Code, Codex அல்லது OpenCode போன்ற vendor CLI-களைத் தொடங்கி, ஒவ்வொன்றிற்கும் பணிகளை வழங்கி, ஒரே session-ல் அவற்றின் முடிவுகளைக் கண்காணிக்கிறது. இது தனக்கென எந்த model-ஐயும் கொண்டிருக்கவில்லை. இதனால்தான் இது ஒரு framework-லிருந்து வேறுபடுகிறது; framework-ல் நீங்கள் ஒரு library-ஐப் பயன்படுத்தி Python code எழுதுவீர்கள், உங்கள் program-மே agent-ஆக மாறும்.

Omnigent-ஐப் பயன்படுத்துவதற்கு முன்பு Claude Code மற்றும் Codex ஆகியவற்றை நான் நிறுவ வேண்டுமா?

குறைந்தது ஒரு vendor CLI-ஐ நிறுவி, அதில் login செய்திருக்க வேண்டும். ஏனெனில் Omnigent அந்த program-களை மாற்றீடு செய்யாமல், அவற்றை இயக்குகிறது. வழங்கப்பட்டுள்ள Polly உதாரணத்திற்கு, வெவ்வேறு vendor-களிடமிருந்து இரண்டு அல்லது அதற்கு மேற்பட்ட CLI-கள் தேவை. Polly-ன் விதிப்படி, ஒரு வேலையைச் செய்தவர் அல்லாத மற்றொரு vendor-தான் அதைச் சரிபார்க்க வேண்டும். எனவே, ஒரே ஒரு CLI மட்டும் இருந்தால், diff-ஐ அனுப்ப இரண்டாவது vendor இருக்க மாட்டார்.

சமீபத்திய பதிப்பிற்குப் பதிலாக, ஒரு குறிப்பிட்ட Omnigent பதிப்பை எவ்வாறு நிறுவுவது?

--version-ஐ sh -s -- மூலம் install script-க்கு அனுப்பவும், உதாரணமாக sh -s -- --version 0.7.0. -s -- இல்லையென்றால், அந்த flag sh-ஆலேயே எடுத்துக்கொள்ளப்பட்டு, script புதிய release-ஐ நிறுவிவிடும். ஏற்கனவே uv இருந்தால், uv tool install --force --python 3.12 "omnigent==0.7.0" அதே வேலையைச் செய்யும். git tag என்பது v0.7.0, அதே சமயம் PyPI version string என்பது 0.7.0 ஆகும்.

Omnibox sandbox, agent-களைக் கவனிக்காமல் (unattended) இயக்கப் போதுமானதா?

இது உள்ளடக்கும் விஷயங்களுக்கு இது வலுவானது, எதைச் செய்யாது என்பதில் தெளிவாக உள்ளது. Linux-ல் இது bubblewrap மற்றும் seccomp-ஐப் பயன்படுத்துகிறது, எனவே kernel கோப்பு மற்றும் network வரம்புகளை அமல்படுத்துகிறது; agent-ஆல் இதிலிருந்து விலக முடியாது. ஆவணங்களின்படி, இது sys_os_* tool calls மற்றும் terminals-க்கு மட்டுமே பொருந்தும், MCP servers அல்லது Omnigent supervisor process-க்கு இது பொருந்தாது. எனவே, ஒரு MCP server உங்கள் சாதாரண அனுமதிகளுடன் இயங்கும். இதனால்தான், கவனிக்கப்படாத பணிகளுக்கு ஒவ்வொரு agent-க்கும் ஒரு disposable virtual machine-ஐப் பயன்படுத்துவதே பாதுகாப்பானது.

VPS-ல் ஒரு Omnigent server-க்கு எவ்வளவு memory தேவை?

இந்தத் திட்டத்தின் deploy குறிப்புகள், server-க்கு சுமார் 512 MB முதல் 1 GB வரை working set தேவை என்று கூறுகின்றன, மேலும் அதன் Fly.io configuration 1 GB-ஐ ஒதுக்குகிறது. இது port 6767-ல் உள்ள supervisor மற்றும் web interface-க்கு மட்டுமே பொருந்தும். ஒவ்வொரு sub-agent-ம் தனித்தனி process-ஆக, அதன் சொந்த working copy மற்றும் model client-உடன் இயங்கும். Polly-முறை இயக்கங்கள் parallel git worktrees-ஐப் பயன்படுத்துவதால், server-ன் அளவை மட்டும் பார்க்காமல், ஒரே நேரத்தில் நீங்கள் இயக்கத் திட்டமிட்டுள்ள agent-களின் எண்ணிக்கைக்கு ஏற்ப RAM மற்றும் disk-ஐத் திட்டமிடுங்கள்.