Omnigent म्हणजे काय? अनेक agent CLIs साठी harness

Omnigent म्हणजे काय

Omnigent हे open source meta-harness आहे. तुमच्या सिस्टमवर आधीपासून स्थापित असलेल्या agent command line tools (CLIs) चालवण्यासाठी हा एक orchestration layer आहे. हे Claude Code, Codex, Cursor, OpenCode, Hermes किंवा Pi यांची जागा घेत नाही. हे प्रत्येक साधन सुरू करते, त्याला एक काम देते आणि एकाच session मध्ये, एका policy set अंतर्गत, त्याच्या परिणामाचे पर्यवेक्षण करते. Databricks ने हा repository June 2026 मध्ये Apache 2.0 licence अंतर्गत प्रकाशित केला आणि मुख्य पानावर अजूनही Status: alpha असेच दिसते.

याचा व्यावहारिक दावा मर्यादित आहे आणि तो स्पष्टपणे सांगणे योग्य आहे. तुम्ही YAML मध्ये एखाद्या agent चे वर्णन एकदाच करता आणि तो चालवणारा harness नमूद करता. ती एक ओळ बदलल्यावर तोच agent वेगळ्या vendor च्या CLI वर चालतो. तुमच्या setup मध्ये इतर कोणताही बदल करावा लागत नाही, कारण Omnigent agents च्या आतील loop ऐवजी agents च्या वरचा loop नियंत्रित करते.

मेटा-hार्नेस म्हणजे काय आणि ते फ्रेमवर्कपेक्षा कसे वेगळे आहे?

हॅर्नेस हा असा प्रोग्राम असतो, जो मॉडेलला एका लूपमध्ये चालवतो. तो तुमचा prompt वाचतो, tools कॉल करतो, files संपादित करतो आणि प्रतिसाद देतो. Claude Code हा एक हॅर्नेस आहे. Codex हा एक हॅर्नेस आहे. तुम्ही तो install करता, login करता आणि तो स्वतः काम करतो.

फ्रेमवर्क ही अशी library असते, जिच्यासाठी तुम्ही code लिहिता. तुम्ही ती import करता, Python मध्ये steps परिभाषित करता आणि तुमचा program agent बनतो. येथे vendor बदलण्यासाठी तुमच्या code मध्ये बदल करावे लागतात, कारण vendor चा client तुमच्या program द्वारे जोडलेला असतो.

मेटा-हॅर्नेस हे दोन्हींपेक्षा एक स्तर वर असते. हा असा supervisor असतो, जो harnesses ना child processes म्हणून चालवतो. Omnigent vendor CLI सुरू करते, त्याला काम देते आणि परत आलेले output वाचते. तुम्ही आधीच install केलेला CLI वापरू शकता. तसेच त्यासाठी आधीपासून वापरत असलेले subscription किंवा API (application programming interface) key कायम ठेवू शकता. एवढाच मुख्य फरक आहे. आणि यावरून हे tool कोणासाठी आहे ते ठरते: अनेक agent CLIs आधीपासून कार्यरत असलेले, पण प्रत्येक CLI स्वतंत्र terminal मधून चालवण्याचा कंटाळा आलेले लोक.

एक orchestration layer कोणती समस्या सोडवते?

• Vendor बदलण्याचा खर्च एका ओळीत मर्यादित राहतो. Agent definition मध्ये harness आणि model हे data म्हणून ठेवलेले असतात. त्यामुळे एखादी भूमिका एका vendor कडून दुसऱ्याकडे हलवण्यासाठी संपूर्ण पुनर्लेखन करण्याऐवजी YAML file मध्ये edit करणे पुरेसे असते.
• Review अनेक vendors मध्ये करता येतो. एका model ने तयार केलेला diff वेगळ्या कंपनीच्या model कडून वाचला जातो. एकाच family मधील दोन models मध्ये समान blind spots असण्याची शक्यता असते. त्यामुळे त्याच vendor कडून घेतलेले second opinion कमी उपयुक्त ठरते.
• Policy साठी एकच ठिकाण असते. Spend caps आणि approval prompts agent file मध्ये घोषित केले जातात. ते त्या agent अंतर्गत असलेल्या प्रत्येक sub-agent ला लागू होतात.
• Session कोणत्याही एका tool पेक्षा अधिक काळ टिकतो. अनेक CLIs द्वारे केलेले काम एका transcript मध्ये नोंदले जाते. त्यामुळे चार वेगवेगळे scrollbacks एकत्र जोडण्याची गरज न पडता काय झाले ते पुन्हा वाचता येते.

याची किंमत मात्र हा layer स्वतः आहे. Omnigent मधील प्रत्येक bug आता तुमच्या आणि पूर्वी स्वतंत्रपणे कार्य करणाऱ्या agent मधील अडथळा ठरतो. Alpha टप्प्यात ही वास्तविक किंमत आहे; ती केवळ सैद्धांतिक नाही.

एकल agent साधनांच्या शेजारी multi-agent harness कुठे बसतो

तुम्ही अद्याप सर्व्हरवर एक agent चालवला नसेल, तर आधी तेच करा. VPS वर coding agent चालवण्याचे आमचे मार्गदर्शन single agent ची संपूर्ण प्रक्रिया समजावते आणि Omnigent हे setup आधीपासून उपलब्ध आहे असे गृहीत धरते. self-hosted AI agents या व्यापक क्षेत्रात तुम्ही स्वतः agents निवडता. या विषयातील संज्ञा नवीन असल्यास agents प्रत्यक्षात कसे कार्य करतात हे शिकणे हा अधिक योग्य प्रारंभबिंदू आहे.

Omnigent हे connector layer पेक्षा वेगळ्या अक्षावर कार्य करते. agentsना तुमच्या स्वतःच्या data sourcesमध्ये प्रवेश देणे यासारखे काम agent कोणत्या स्रोतांपर्यंत पोहोचू शकतो यासंबंधी आहे. Omnigentमध्ये कोणता agent चालेल, तो कोणत्या क्रमाने चालेल आणि कोणत्या मर्यादांखाली चालेल हे ठरवले जाते. तुम्हाला दोन्ही एकाच वेळी आवश्यक असू शकतात; त्यांची कार्यक्षेत्रे एकमेकांवर येत नाहीत.

तुम्ही इंस्टॉल करण्यापूर्वी आवश्यक गोष्टी

• Python 3.12 किंवा त्यानंतरची आवृत्ती. प्रकाशित पॅकेजमध्ये requires-python >= 3.12 घोषित केले आहे.
• tmux, कारण terminal harnesses त्यामध्ये चालतात.
• किमान एक vendor CLI आधीच इंस्टॉल केलेला आणि त्यामध्ये login केलेले असणे आवश्यक आहे.
• git checkout मधून build करत असाल, तरच Node.js 22 आवश्यक आहे. PyPI वरील wheel मध्ये तयार केलेले web assets समाविष्ट आहेत. त्यामुळे सामान्य इंस्टॉलसाठी Node ची अजिबात आवश्यकता नाही.

पिन केलेले release install करा, 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 ला स्वतःचा option समजते आणि installer ला flag दिसत नाही. त्यामुळे त्या दिवशी उपलब्ध असलेले सर्वात नवीन version install होते. दर काही आठवड्यांनी breaking changes release करणाऱ्या repository मध्ये, यामुळे reproducible box आणि अनपेक्षित बदल यांमध्ये फरक पडतो.

Installer uv वापरतो. uv हे Astral चे Python package manager आहे. uv उपलब्ध नसल्यास installer ते आधी install करण्याची सूचना देतो. uv आधीपासून install केलेले असल्यास 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 त्या directory मध्ये ठेवतो जी uv tool dir --bin दाखवते. ही directory सहसा ~/.local/bin असते. Installer ती directory तुमच्या shell profile मध्ये जोडण्याची सूचना देतो. नवीन install केल्यानंतर लगेच command सापडत नसेल, तर त्याचे हेच कारण आहे. प्रत्यक्षात काय install झाले ते तपासा:

omni upgrade --check

यामुळे install केलेल्या version ची तुलना प्रकाशित झालेल्या नवीनतम version सोबत होते आणि upgrade उपलब्ध आहे का ते कळते. Upgrade प्रत्यक्षात केले जात नाही. omni आणि omnigent ही एकाच program ची दोन नावे आहेत.

मॉडेल प्रदात्याकडे निर्देशित करा

omni setup

विझार्ड तुमच्या environment मध्ये आधीपासून उपलब्ध असलेली credentials शोधतो आणि नसलेल्या credentials साठी prompt दाखवतो. हे API keys, vendor subscriptions, OpenRouter किंवा Ollama सारखे gateways आणि Databricks workspaces हाताळते. त्याच मशीनवर तुम्ही आधीपासून Ollama सह स्थानिक मॉडेल सर्व्हर चालवत असल्यास, gateway त्याकडे निर्देशित करा. त्यामुळे network traffic मशीनबाहेर जात नाही.

किमान multi-agent रन

उदाहरणातील agents repository मध्ये आहेत. त्यामुळे तुम्ही install केलेला तोच tag clone करा; main करू नका.

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

Polly हा repository सोबत release होणारा multi-agent coding orchestrator आहे. त्याच्या config मध्ये claude_code, codex, opencode, cursor, hermes आणि pi या नावांचे sub-agents घोषित केले आहेत. तसेच एक नियम आहे, ज्यामुळे हा संपूर्ण सराव उपयुक्त ठरतो: review नेहमी implementer पेक्षा वेगळ्या vendor कडून केला जातो. Polly स्वतः code लिहित नाही. ते नियोजन करते, उद्दिष्टाचे work items मध्ये विभाजन करते, प्रत्येक item योग्य agent कडे सोपवते आणि प्रत्येक diff दुसऱ्या vendor कडील reviewer कडे पाठवते.

कुठलेही काम delegate करण्यापूर्वी Polly preflight check चालवते आणि मशीनवर प्रत्यक्षात कोणते sub-agent CLIs उपलब्ध आहेत ते तपासते. फक्त एका vendor चे CLI install केले असल्यास diff सोपवण्यासाठी दुसरा कोणी उपलब्ध नसतो. त्यामुळे output चे मूल्यमापन करण्यापूर्वी किमान दोन CLI install करा. Debby हा दुसरा release केलेला example आहे. तो दोन heads असलेला debate agent आहे: एक Claude आणि एक GPT:

omni debby

दोन्ही providers configure झाले आहेत याची पुष्टी करण्याचा हा संक्षिप्त मार्ग आहे, कारण काहीही सांगण्यासाठी त्याला दोन्ही providers आवश्यक असतात.

उप-एजंट साधने म्हणून घोषित केले जातात

एजंट फाइल YAML मध्ये असते. executor मध्ये harness, model आणि authentication यांची नावे असतात. tools मध्ये MCP (model context protocol) servers, Python functions आणि sub-agents असतात. Sub-agent हे type: agent आणि स्वतःचा executor असलेले tool असते. वरील सर्व गोष्टींची यंत्रणा यामागेच असते.

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-hosted नावे आहेत. harness आणि model यांच्या जागी तुमच्या मशीनवर omni setup मध्ये configured असलेली मूल्ये द्या. Generic protocol वापरणाऱ्या घटकांसाठी spec मध्ये antigravity, copilot, kimi, qwen आणि acp:<slug> ही इतर harness values देखील आहेत. Spec मध्ये sub-agent साठी pass_history: true चे समर्थनही आहे. यामुळे parent conversation त्या sub-agent कडे पाठवली जाते. प्रत्येक delegation वेळी यासाठी tokens खर्च होतात. त्यामुळे केवळ समोरील task आवश्यक असलेल्या sub-agents साठी हे पर्याय बंद ठेवा. ज्या coder च्या prompt मध्ये काम करणारा सर्वात लहान बदल करण्यास सांगितले आहे, तो आपल्या reviewer ला प्रत्यक्ष वाचता येईल इतका लहान diff देतो. या भूमिकांसाठी कोणते model निवडता यापेक्षा येथे हे अधिक महत्त्वाचे आहे.

दीर्घकाळ चालणारे orchestration VPS वर का ठेवावे

Multi-agent run ही दोन मिनिटांची command नाही. नियोजन करा, कामे सोपवा, समांतर git worktrees पूर्ण होण्याची वाट पाहा, review करा आणि सुधारणा करा. Laptop चे झाकण बंद केल्यावर हे सर्व थांबते. VPS (virtual private server) सुरू राहतो आणि त्याचे network connection कायम ठेवतो. त्यामुळे तुम्ही निरीक्षण करत नसतानाही session सुरू राहते.

omnigent server --background
omnigent server status

Server port 6767 वर web user interface उपलब्ध करून देतो. omnigent server status एखादा session सुरू आहे का ते दाखवते आणि omnigent stop तो बंद करते. v0.7.0 पूर्वीच्या releases मध्ये यासाठी omni server start वापरले जात होते. ते आता काढून टाकले आहे. त्यामुळे जुन्या write-ups आणि screenshots तुमच्या terminal मधील परिणामांशी जुळणार नाहीत.

6767 सार्वजनिक address वर उघडू नका. सुरक्षित रचना दोन प्रकारे करता येते. Firewall मध्ये port बंद ठेवा आणि ssh -N -L 6767:localhost:6767 you@your-server वापरून तो SSH द्वारे forward करा. त्यानंतर तुमच्या स्वतःच्या machine वर http://localhost:6767 उघडा. किंवा त्याच्या समोर TLS (transport layer security) termination करा आणि authentication सुरू करा:

OMNIGENT_AUTH_ENABLED=1 omnigent server --background

यातील firewall संबंधित भाग सामान्य प्रशासकीय काम आहे. त्याचे वर्णन VPS साठी ufw firewall ची मूलभूत माहिती येथे केले आहे. जर त्या server वर अनेक Docker Compose apps च्या समोर Traefik आधीच चालत असेल, तर Omnigent ही त्याच pattern मधील आणखी एक service ठरते.

Container deploy साठी repository मधील deploy/ directory मध्ये Compose setup आहे. ./bootstrap.sh secrets .env मध्ये तयार करते. त्यानंतर docker compose up -d Omnigent आणि Postgres port 6767 वर सुरू करते. DATABASE_URL Postgres किंवा SQLite निवडते. Container च्या आत OMNIGENT_AUTH_ENABLED चे default मूल्य 1 असते. बाहेरून पोहोचता येणाऱ्या कोणत्याही सेवेकरिता हे योग्य default आहे.

Sizing बाबत deploy notes नुसार server चा working set साधारण 512 MB ते 1 GB असतो. Fly.io configuration मध्ये 1 GB निश्चित केले आहे. हा आकडा केवळ supervisor साठी आहे. प्रत्येक sub-agent हा स्वतंत्र process असतो. त्याच्याकडे स्वतःचा checkout आणि स्वतःचा model client असतो. त्यामुळे server चे sizing agents ची संख्या लक्षात घेऊन करा. Server सुरू झाल्यानंतर omnigent login https://your-host आणि त्यानंतर omnigent host https://your-host चालवल्यास तुमचा laptop त्या server शी register होतो. omnigent attach <session_id> वापरून दुसऱ्या device वरून सुरू असलेला session पुन्हा सुरू करता येतो.

प्रत्येक sub-agent कडून दूर जाण्यापूर्वी त्याला sandbox मध्ये मर्यादित करा

Omnigent ऑपरेटिंग सिस्टम स्तरावरील Omnibox नावाचा sandbox उपलब्ध करून देते. Linux वर ते bubblewrap namespaces आणि seccomp वापरते. त्यामुळे सीमा agent च्या prompt ऐवजी kernel लागू करतो. Prompt injection झालेला agent kernel rule मधून बाहेर पडण्यासाठी केवळ मजकूराद्वारे युक्तिवाद करू शकत नाही. प्रथम dependency install करा:

sudo apt install bubblewrap

Configuration agent file मधील 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 मधून जाते. प्रत्येक rule "METHODS host/path-glob" म्हणून लिहिला जातो. credential_proxy आणखी कडक संरक्षण देते: agent कडे कधीही फक्त placeholder असतो. Request बाहेर जाताना proxy त्यात खरे secret बसवतो. त्यामुळे transcript गळती झाली तरी वापरता येणारी माहिती गळत नाही. Multi-harness setup मध्ये प्रत्येक sub-agent कडे स्वतःच्या config file मध्ये, agents/ अंतर्गत, स्वतंत्र sandbox block असतो. त्यामुळे reviewer साठी network नाकारता येते, तर implementer साठी ते सुरू ठेवता येते.

या मर्यादेचा documentation मध्ये स्पष्ट उल्लेख आहे आणि ती महत्त्वाची आहे. OS sandbox sys_os_* tool calls आणि terminals वर लागू होतो. तो MCP servers वर लागू होत नाही. Omnigent supervisor process वरही तो लागू होत नाही. तुम्ही सुरू केलेला MCP server तुमच्या permissions सह sandbox च्या बाहेर चालतो. म्हणून अधिक मजबूत पद्धत अजूनही प्रत्येक agent साठी स्वतंत्र throwaway machine वापरणे हीच आहे. याच विषयावर disposable VM मध्ये coding agents चालवणे आहे. कामाचा दुसरा भाग credentials चा आहे. सहा sub-agents एकाच host वर share करत असतील, तर agent च्या आवाक्याबाहेर secrets ठेवणे अधिक सोपे नव्हे, तर अधिक कठीण होते.

Spend limits ही policies आहेत. त्या त्याच 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]

एक run पहिल्या vendor कडून planning, दुसऱ्या vendor कडून implementation आणि तिसऱ्या vendor कडून review करत असेल, तर एकाच वेळी तीन ठिकाणी खर्च होतो. त्यामुळे पहिला unattended run सुरू करण्यापूर्वी cap सेट करा; पहिला invoice आल्यानंतर करू नका. Built-ins मध्ये max_tool_calls_per_session आणि ask_on_os_tools यांचाही समावेश आहे. ते file आणि shell operations करण्यापूर्वी approval मागतात. VPS वर AI agent चा खर्च नियंत्रणात ठेवणे यावरील आमच्या नोंदी येथे थेट लागू होतात. Parallel 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 page वर 3 August 2026 रोजी पाहिलेल्या प्रकाशित release dates आहेत. 2026-06-19 आणि 2026-07-27 या कालावधीत 7 tagged releases प्रकाशित झाले. कोणत्याही दोन releases मधील सर्वात मोठे अंतर 11 दिवसांचे होते. v0.5.1 हे त्याच्या आधीच्या release च्याच दिवशी प्रकाशित झाले. पहिला release, 16 June 2026 रोजीचा 0.1.1, chart मध्ये समाविष्ट केलेला नाही, कारण त्यापूर्वी मोजण्यासाठी कोणताही tag उपलब्ध नाही.

या releases पैकी दोन releases मुळे guides मध्ये आधीच documented केलेले commands बदलले. v0.7.0 ने omni server start काढून त्याऐवजी omni server --background वापरले. v0.6.0 ने omnigent[memory] extra चे नाव बदलून omnigent[hindsight] केले. त्यामुळे June मधील write-up मधून copy केलेली install line July build वर fail होते. म्हणून तुमच्या install command मध्ये --version आणि तुमच्या git clone मध्ये tag वापरणे आवश्यक आहे; हा केवळ style preference चा विषय नाही.

यावर मी अद्याप विश्वास ठेवणार नाही

August 2026 पर्यंत या repository ला सुमारे 8.1k stars, 1.2k forks आणि अंदाजे 350 open issues आहेत. पहिल्या सार्वजनिक release ला सात आठवडे झाले आहेत. Stars हे केवळ स्वारस्य दर्शवतात; परिपक्वता नाही. प्रकल्प स्वतःला alpha म्हणतो आणि वरील release history वरून त्याचा अर्थ खरोखर alpha असाच दिसतो.

• production credentials असलेल्या host वर मी हे चालवणार नाही, कारण sandbox मध्ये MCP servers किंवा supervisor समाविष्ट नाहीत.
• cost_budget policy शिवाय run unattended ठेवणार नाही, कारण तीन vendors समांतरपणे शुल्क आकारू शकतात आणि त्यांना थांबवणारी दुसरी कोणतीही यंत्रणा नाही.
• OMNIGENT_AUTH_ENABLED सेट करून त्याच्या पुढे TLS न ठेवता server public IP address वर expose करणार नाही.
• minor versions मध्ये agent YAML स्थिर राहील असे मी अद्याप गृहीत धरणार नाही. त्यामुळे version pin करा आणि upgrade करण्यापूर्वी release notes वाचा.

हे अनपेक्षितपणे समोर येण्यापूर्वी आणखी एक गोष्ट जाणून घ्या: v0.6.0 मध्ये anonymised usage telemetry जोडले गेले आहे आणि प्रकल्पाने त्याचे दस्तऐवजीकरण स्वतंत्र telemetry page वर केले आहे. तो page वाचा आणि machine वर client work हाताळले जात असल्यास विचारपूर्वक निर्णय घ्या.

आज Omnigent ज्या कामासाठी खरोखर उपयुक्त आहे, तेच त्याच्या निर्मितीमागील उद्दिष्ट आहे. तुमच्याकडे तीन किंवा चार agent CLIs आहेत, तुम्ही त्यांच्यासाठी आधीच पैसे देता आणि त्यापैकी एकाने लिहावे, तर दुसऱ्याने review करावे अशी तुमची इच्छा आहे. हे आता एका machine वर, Linux मध्ये प्रत्यक्ष sandboxing सह कार्य करते. त्यापुढील सर्व गोष्टी आशादायक पण अद्याप अपूर्ण आहेत.

FAQ

Omnigent agent आहे की agents चालवणारी गोष्ट आहे?

ते agents चालवते. Omnigent हा meta-harness आहे. तुम्ही आधीच install केलेले Claude Code, Codex किंवा OpenCode यांसारखे vendor CLIs ते सुरू करते, प्रत्येकाला काम देते आणि एकाच session मध्ये परिणामांचे पर्यवेक्षण करते. Omnigent स्वतःचे model आणत नाही. म्हणून ते framework पेक्षा वेगळे आहे. Framework मध्ये तुम्ही library वापरून Python लिहिता आणि तुमचा स्वतःचा program agent बनतो.

Omnigent उपयुक्त ठरण्यापूर्वी Claude Code आणि Codex install केलेले असणे आवश्यक आहे का?

किमान एक vendor CLI install करून त्यात login केलेले असणे आवश्यक आहे. Omnigent त्या programs ना चालवते; त्यांची जागा घेत नाही. वितरित Polly उदाहरणासाठी वेगवेगळ्या vendors कडील दोन किंवा अधिक CLIs आवश्यक आहेत. Polly च्या नियमानुसार review नेहमी implementer पेक्षा वेगळ्या vendor कडून केला जातो. त्यामुळे एकच CLI उपलब्ध असल्यास diff पाठवण्यासाठी दुसरा vendor उपलब्ध राहत नाही.

नवीनतम version ऐवजी Omnigent ची विशिष्ट version कशी install करू?

Install script ला --version, sh -s -- सह pass करा, जसे sh -s -- --version 0.7.0 मध्ये दाखवले आहे. -s -- नसल्यास हा flag sh स्वतः वापरते आणि script नवीनतम release install करते. uv आधीच उपलब्ध असल्यास uv tool install --force --python 3.12 "omnigent==0.7.0" हेच काम करते. Git tag v0.7.0 आहे, तर PyPI version string 0.7.0 आहे.

Agents unattended पद्धतीने चालवण्यासाठी Omnibox sandbox पुरेसा आहे का?

तो ज्या गोष्टी नियंत्रित करतो त्यासाठी मजबूत आहे आणि ज्या गोष्टी नियंत्रित करत नाही त्याबाबत स्पष्ट आहे. Linux वर तो bubblewrap आणि seccomp वापरतो. त्यामुळे kernel file आणि network limits लागू करतो आणि agent ते limits bypass करू शकत नाही. Documentation नुसार हे sys_os_* tool calls आणि terminals वर लागू होते. MCP servers किंवा Omnigent supervisor process वर ते लागू होत नाही. त्यामुळे MCP server तुमच्या नेहमीच्या permissions सह चालतो. म्हणून unattended कामासाठी प्रत्येक agent ला स्वतंत्र disposable virtual machine देणे अजूनही अधिक मजबूत isolation आहे.

VPS वर Omnigent server साठी किती memory आवश्यक आहे?

Project च्या deploy notes नुसार server साठी साधारण 512 MB ते 1 GB working set आवश्यक आहे. Fly.io configuration मध्ये 1 GB निश्चित केलेले आहे. यात फक्त supervisor आणि port 6767 वरील web interface समाविष्ट आहेत. प्रत्येक sub-agent स्वतंत्र process असतो. त्याची स्वतःची working copy आणि model client असतो. Polly-शैलीच्या runs मध्ये parallel git worktrees वापरले जातात. त्यामुळे server साठी नव्हे, तर एकाच वेळी चालवण्याच्या agent संख्येनुसार RAM आणि disk चे sizing करा.