Omnigent: এক harness-এ বহু agent CLI চালানোর উপায়

Omnigent কী

Omnigent একটি open source meta-harness: এটি একটি orchestration layer, যা আপনার সিস্টেমে ইতিমধ্যে ইনস্টল করা agent command-line tool (CLI) পরিচালনা করে। এটি Claude Code, Codex, Cursor, OpenCode, Hermes বা Pi-কে প্রতিস্থাপন করে না। এটি এগুলো চালু করে, প্রতিটিকে একটি করে কাজ দেয় এবং একটি policy set ব্যবহার করে একই session-এর মধ্যে ফলাফল তদারক করে। Databricks 2026 সালের June মাসে Apache 2.0 licence-এর অধীনে repository প্রকাশ করে। এর front page-এ এখনও Status: alpha লেখা আছে।

এই দাবিটি সীমিত, এবং সরাসরি বলা দরকার। আপনি YAML-এ একটি agent একবার বর্ণনা করেন এবং সেটি চালানোর harness-এর নাম উল্লেখ করেন। ওই একটি line পরিবর্তন করলে একই agent অন্য vendor-এর CLI-তে চলে। আপনার setup-এর অন্য কিছু পরিবর্তন করতে হয় না, কারণ Omnigent agent-এর ভেতরের loop নয়, বরং agent-এর উপরের loop পরিচালনা করে।

একটি meta-harness কী এবং এটি framework থেকে কীভাবে আলাদা?

harness হলো এমন একটি প্রোগ্রাম, যা একটি model-কে loop-এর মধ্যে চালায়। এটি আপনার prompt পড়ে, tools ব্যবহার করে, files সম্পাদনা করে এবং ফলাফল জানায়। Claude Code একটি harness। Codex একটি harness। আপনি এটি install করেন, login করেন, এবং এটি নিজে কাজ করে।

framework হলো এমন একটি library, যার ওপর ভিত্তি করে আপনি code লেখেন। আপনি এটি import করেন, Python-এ ধাপগুলো নির্ধারণ করেন, এবং আপনার program-ই agent হয়ে যায়। সেখানে vendor পরিবর্তন করতে হলে code সম্পাদনা করতে হয়, কারণ vendor-এর client আপনার program-এর মধ্যেই সংযুক্ত থাকে।

meta-harness উভয়ের চেয়ে এক স্তর ওপরে কাজ করে। এটি এমন একটি supervisor, যা child process হিসেবে harness চালায়। Omnigent vendor CLI চালু করে, সেখানে কাজ পাঠায় এবং ফিরে আসা ফলাফল পড়ে। আপনি আগে install করা CLI-ই ব্যবহার করেন। সেটির জন্য ইতিমধ্যে যে subscription বা API (application programming interface) key ব্যবহার করছেন, সেটিও অপরিবর্তিত থাকে। এটাই মূল পার্থক্য। আর এই পার্থক্যই নির্ধারণ করে tool-টি কার জন্য: যাদের একাধিক agent CLI ইতিমধ্যে সচল আছে এবং যারা একবারে একটি terminal থেকে সেগুলো চালাতে ক্লান্ত।

একটি orchestration layer কোন সমস্যার সমাধান করে?

• Vendor পরিবর্তনের খরচ এক লাইনে সীমাবদ্ধ থাকে। Agent definition-এ harness এবং model data হিসেবে থাকে। তাই একটি role এক vendor থেকে অন্য vendor-এ সরাতে YAML file সম্পাদনা করলেই হয়, নতুন করে সবকিছু লিখতে হয় না।
• বিভিন্ন vendor-এর মধ্যে review করা যায়। একটি model-এর লেখা diff অন্য কোম্পানির model পড়ে। একই family-এর দুটি model সাধারণত একই blind spot ভাগ করে নেয়। তাই একই vendor-এর দ্বিতীয় মতামতের মূল্য কম।
• Policy-এর একটি কেন্দ্রীয় অবস্থান থাকে। Spend cap এবং approval prompt agent file-এ ঘোষণা করা হয়। এগুলো তার অধীন প্রতিটি sub-agent-এর ক্ষেত্রে প্রযোজ্য হয়।
• Session কোনো একটি tool-এর ওপর নির্ভর করে না। একটি transcript-এ একাধিক CLI-তে করা কাজের বিবরণ থাকে। তাই চারটি scrollback একসঙ্গে জোড়া না দিয়েও কী ঘটেছে তা পরে পড়া যায়।

এর বিনিময়ে layer-টি নিজেই একটি খরচ। Omnigent-এর প্রতিটি bug এখন আপনার এবং আগে স্বতন্ত্রভাবে কাজ করা agent-এর মাঝখানে থাকা একটি bug। Alpha পর্যায়ে এটি বাস্তব খরচ, তাত্ত্বিক বিষয় নয়।

একক agent tool-এর পাশে multi-agent harness কোথায় কাজে লাগে

আপনি যদি এখনো কোনো server-এ একটি agent না চালিয়ে থাকেন, তাহলে আগে সেটি দিয়ে শুরু করুন। VPS-এ coding agent চালানো নিয়ে আমাদের guide-এ single agent ব্যবহারের পুরো প্রক্রিয়া দেখানো হয়েছে। Omnigent ধরে নেয় যে এই setup আপনার আগে থেকেই আছে। self-hosted AI agent-এর বৃহত্তর ক্ষেত্রেই আপনি agent বেছে নেন। এই পরিভাষাগুলো নতুন হলে agent কীভাবে কাজ করে তা শেখা দিয়ে শুরু করাই ভালো।

Omnigent connector layer থেকে ভিন্ন একটি বিষয়। agent-কে আপনার নিজস্ব data source-এ access দেওয়া-এর মতো কাজ নির্ধারণ করে agent কোন data বা service-এ পৌঁছাতে পারবে। Omnigent নির্ধারণ করে কোন agent চলবে, কোন ক্রমে চলবে এবং কী সীমার মধ্যে চলবে। আপনার একই সময়ে দুটিই প্রয়োজন হতে পারে। এগুলো পরস্পরের বিকল্প নয়।

ইনস্টল করার আগে যা প্রয়োজন

• Python 3.12 বা পরবর্তী সংস্করণ। প্রকাশিত package-এ requires-python >= 3.12 ঘোষণা করা আছে।
• tmux, কারণ terminal harness-গুলো এর ভেতরে চলে।
• অন্তত একটি vendor CLI আগে থেকেই ইনস্টল করা এবং লগ ইন করা থাকতে হবে।
• git checkout থেকে build করলে শুধু Node.js 22 প্রয়োজন। PyPI-এর wheel-এ তৈরি web assets অন্তর্ভুক্ত থাকে, তাই সাধারণ install-এর জন্য Node একেবারেই প্রয়োজন হয় না।

নির্দিষ্ট 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-কে নিজের option হিসেবে পড়ে এবং installer কখনোই flag-টি দেখতে পায় না। ফলে সেদিনের সর্বশেষ version ইনস্টল হয়। কয়েক সপ্তাহ পরপর breaking change প্রকাশ করে এমন repository-তে এটাই reproducible system এবং অপ্রত্যাশিত ফলাফলের মধ্যে পার্থক্য তৈরি করে।

installer uv ব্যবহার করে। uv হলো Astral-এর Python package manager। uv না থাকলে installer প্রথমে 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-টি সেই directory-তে রাখে, যেটি uv tool dir --bin report করে। সাধারণত সেটি ~/.local/bin। installer আপনার shell profile-এ directory-টি যোগ করার প্রস্তাব দেয়। পরিষ্কারভাবে ইনস্টল করার পরপরই command পাওয়া না গেলে, এর কারণ সেটিই। শেষ পর্যন্ত কী ইনস্টল হয়েছে তা যাচাই করুন:

omni upgrade --check

এটি ইনস্টল করা version-এর সঙ্গে সর্বশেষ প্রকাশিত version তুলনা করে এবং upgrade available কি না জানায়, কিন্তু upgrade সম্পাদন করে না। omni এবং omnigent একই program-এর দুটি নাম।

একটি model provider নির্ধারণ করুন

omni setup

Wizard আপনার environment-এ আগে থেকেই থাকা credential খুঁজে বের করে এবং যেগুলো অনুপস্থিত, সেগুলোর জন্য prompt দেখায়। এটি API key, vendor subscription, OpenRouter বা Ollama-এর মতো gateway এবং Databricks workspace পরিচালনা করে। একই মেশিনে যদি আপনি ইতিমধ্যে Ollama দিয়ে একটি local model server চালান, তাহলে gateway-কে সেটির দিকে নির্দেশ করুন। এতে network traffic কখনও মেশিনের বাইরে যায় না।

একটি ন্যূনতম multi-agent run

উদাহরণ agent-গুলো repository-তে রয়েছে। তাই আপনি যে tag ইনস্টল করেছেন, একই 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-এর সঙ্গে সরবরাহ করা multi-agent coding orchestrator। এর configuration-এ claude_code, codex, opencode, cursor, hermes এবং pi নামে sub-agent নির্ধারিত আছে। এতে একটি নিয়ম রয়েছে, যা পুরো অনুশীলনটি চালানোর প্রধান কারণ: implementer এবং reviewer সবসময় ভিন্ন vendor-এর হতে হবে। Polly নিজে কোনো code লেখে না। এটি পরিকল্পনা তৈরি করে, লক্ষ্যকে work item-এ ভাগ করে, প্রতিটি item delegate করে এবং প্রতিটি diff অন্য vendor-এর reviewer-এর কাছে পাঠায়।

কোনো কাজ delegate করার আগে Polly preflight check চালিয়ে দেখে, মেশিনে কোন sub-agent CLI সত্যিই আছে। মাত্র একটি vendor CLI ইনস্টল থাকলে diff পাঠানোর মতো অন্য কেউ থাকে না। তাই output মূল্যায়নের আগে অন্তত দুটি CLI ইনস্টল করুন। সরবরাহ করা অন্য উদাহরণ Debby হলো দুইটি head-সহ একটি debate agent; একটির পেছনে Claude এবং অন্যটির পেছনে GPT রয়েছে:

omni debby

দুটি provider configured আছে কি না নিশ্চিত করার এটি একটি সংক্ষিপ্ত উপায়, কারণ কিছু বলার জন্য এর উভয় provider-ই প্রয়োজন।

সাব-এজেন্টকে টুল হিসেবে ঘোষণা করা হয়

এজেন্ট ফাইলটি YAML। executor-এ harness, model এবং authentication-এর নাম থাকে। tools-এ MCP (model context protocol) server, Python function এবং sub-agent থাকে। একটি sub-agent হলো type: agent-সহ একটি tool এবং এর নিজস্ব 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 id-গুলো প্রকল্পের নিজস্ব docs/AGENT_YAML_SPEC.md উদাহরণ থেকে নেওয়া এবং এগুলো Databricks-hosted নাম। আপনার সিস্টেমে কনফিগার করা omni setup অনুযায়ী harness এবং model প্রতিস্থাপন করুন। Generic protocol ব্যবহার করা যেকোনো কিছুর জন্য spec-এ অন্যান্য harness value হিসেবে antigravity, copilot, kimi, qwen এবং acp:<slug>-ও রয়েছে। Spec একটি sub-agent-এ pass_history: true সমর্থন করে। এটি parent conversation sub-agent-এর কাছে পাঠায়। প্রতিটি delegation-এ এতে token খরচ হয়। তাই যে sub-agent-এর শুধু নির্দিষ্ট task-টি প্রয়োজন, তার জন্য এটি বন্ধ রাখুন। কোনো coder-এর prompt যদি তাকে কাজ করার জন্য সবচেয়ে ছোট কার্যকর পরিবর্তনটি করতে নির্দেশ দেয়, তাহলে সে reviewer-এর কাছে পড়ার উপযোগী ছোট diff পাঠায়। এখানে উভয় role-এর জন্য কোন model বেছে নেবেন, তার চেয়ে এই বিষয়টি বেশি গুরুত্বপূর্ণ।

দীর্ঘ সময় চলা orchestration VPS-এ চালানো উচিত

একটি multi-agent run দুই মিনিটের কোনো command নয়। পরিকল্পনা করুন, কাজ ভাগ করুন, parallel git worktree-এর কাজ শেষ হওয়ার জন্য অপেক্ষা করুন, review করুন এবং সংশোধন করুন। ল্যাপটপের ঢাকনা বন্ধ করলে পুরো প্রক্রিয়া বন্ধ হয়ে যায়। একটি VPS (virtual private server) চালু থাকে এবং তার network সংযোগ বজায় রাখে। তাই আপনি নজর না রাখলেও 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। সেটি পরে সরিয়ে দেওয়া হয়েছে। তাই পুরোনো নির্দেশনা ও screenshot আপনার terminal-এ দেখা ফলাফলের সঙ্গে মিলবে না।

6767 কোনো public address-এ প্রকাশ করবেন না। নিরাপদভাবে করার দুটি পদ্ধতি আছে। firewall-এ port বন্ধ রাখুন এবং ssh -N -L 6767:localhost:6767 you@your-server দিয়ে SSH-এর মাধ্যমে এটি forward করুন। এরপর নিজের machine-এ http://localhost:6767 খুলে web interface ব্যবহার করুন। অথবা সামনে TLS (transport layer security) termination করুন এবং authentication চালু করুন:

OMNIGENT_AUTH_ENABLED=1 omnigent server --background

এর firewall অংশটি সাধারণ কাজ। এটি VPS-এর জন্য ufw firewall-এর প্রাথমিক বিষয়গুলো-তে ব্যাখ্যা করা হয়েছে। server-এ যদি ইতিমধ্যে বেশ কয়েকটি Docker Compose app-এর সামনে Traefik ব্যবহার করে container চালানো থাকে, তাহলে একই pattern-এ Omnigent আরও একটি service হবে।

container deploy-এর জন্য repository-এর deploy/ directory-তে একটি Compose setup আছে। ./bootstrap.sh secrets তৈরি করে .env-এ রাখে। এরপর docker compose up -d port 6767-এ Omnigent এবং Postgres চালু করে। DATABASE_URL Postgres অথবা SQLite নির্বাচন করে। OMNIGENT_AUTH_ENABLED-এর default মান container-এর ভিতরে 1। বাইরে থেকে reachable যেকোনো service-এর জন্য এটিই সঠিক default।

সার্ভারের working set আনুমানিক 512 MB থেকে 1 GB ধরা হয়েছে। Fly.io configuration-এ 1 GB নির্ধারিত আছে। এই হিসাবটি শুধু supervisor-এর জন্য। প্রতিটি sub-agent আলাদা process হিসেবে নিজের checkout এবং নিজের model client ধরে রাখে। তাই server-এর আকার agents-এর সংখ্যা ও ব্যবহারের ভিত্তিতে নির্ধারণ করুন। server চালু হওয়ার পর omnigent login https://your-host এবং তারপর omnigent host https://your-host চালালে আপনার laptop serverটির সঙ্গে নিবন্ধিত হয়। omnigent attach <session_id> ব্যবহার করে অন্য device থেকে চলমান session আবার চালু করা যায়।

প্রস্থান করার আগে প্রতিটি sub-agent-কে sandbox-এ সীমাবদ্ধ করুন

Omnigent একটি operating system level sandbox সরবরাহ করে, যার নাম Omnibox। Linux-এ এটি bubblewrap namespaces এবং seccomp ব্যবহার করে। তাই boundary agent-এর prompt নয়, kernel প্রয়োগ করে। Prompt injection-এর মাধ্যমে প্রভাবিত কোনো agent kernel rule এড়াতে পারবে না। প্রথমে dependency ইনস্টল করুন:

sudo apt install bubblewrap

agent file-এ configuration থাকে 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-এর কাছে কখনো প্রকৃত secret থাকে না; এটি শুধু একটি placeholder ধরে রাখে। Request বাইরে যাওয়ার সময় proxy প্রকৃত secret বসিয়ে দেয়। তাই transcript ফাঁস হলেও ব্যবহারযোগ্য কোনো secret ফাঁস হয় না। Multi-harness setup-এ প্রতিটি sub-agent নিজের config file-এ agents/-এর অধীনে নিজস্ব sandbox block বহন করে। ফলে reviewer-এর network access বন্ধ রাখা যায়, অথচ implementer তা চালু রাখতে পারে।

Documentation-এ এই সীমাবদ্ধতা স্পষ্টভাবে উল্লেখ আছে, এবং এটি গুরুত্বপূর্ণ। OS sandbox sys_os_* tool call এবং terminal-এর ক্ষেত্রে প্রযোজ্য। MCP server-এর ক্ষেত্রে এটি প্রযোজ্য নয়। Omnigent supervisor process-এর ক্ষেত্রেও এটি প্রযোজ্য নয়। আপনি চালু করা কোনো MCP server sandbox-এর বাইরে আপনার permissions নিয়ে চলে। এই সীমাবদ্ধতার কারণে আরও শক্তিশালী পদ্ধতি হলো প্রতিটি agent-এর জন্য একটি করে throwaway machine ব্যবহার করা। এই বিষয়টি disposable VM-এ coding agent চালানো অংশে আলোচনা করা হয়েছে। কাজটির অন্য অংশ হলো credentials পরিচালনা করা। ছয়টি sub-agent একই host ভাগ করলে agent-এর নাগালের বাইরে secret রাখা আরও কঠিন হয়।

Spend limit হলো policy, যা একই 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 করে, তবে একই সময়ে তিন জায়গায় খরচ হয়। তাই প্রথম invoice পাওয়ার পরে নয়, প্রথম unattended run শুরুর আগেই cap নির্ধারণ করুন। Built-in option-এর মধ্যে max_tool_calls_per_session এবং ask_on_os_tools-ও আছে। এগুলো file এবং shell operation-এর আগে approval চায়। VPS-এ AI agent-এর খরচ নিয়ন্ত্রণ করা বিষয়ে আমাদের নোট এখানে সরাসরি প্রযোজ্য। Parallel sub-agent থাকলে burn rate বহুগুণ বাড়ে, তাই এখানে এই নিয়ন্ত্রণ আরও গুরুত্বপূর্ণ।

এই 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
  }
]

এগুলো হলো 3 August 2026 তারিখে প্রকল্পের নিজস্ব releases page থেকে নেওয়া প্রকাশিত release-এর তারিখ। 2026-06-19 থেকে 2026-07-27-এর মধ্যে 7টি tagged release প্রকাশিত হয়েছে। পরপর যেকোনো দুটি release-এর মধ্যে সর্বাধিক বিরতি ছিল 11 দিন। v0.5.1 আগের release-এর একই দিনে প্রকাশিত হয়েছে। প্রথম release, 16 June 2026-এর 0.1.1, chart-এ রাখা হয়নি, কারণ সেটির আগের কোনো tag নেই যার ভিত্তিতে ব্যবধান মাপা যায়।

এই release-গুলোর মধ্যে দুটি এমন command পরিবর্তন করেছে, যা guide-গুলোতে আগে থেকেই নথিভুক্ত ছিল। v0.7.0-এ omni server start সরিয়ে তার পরিবর্তে omni server --background ব্যবহার করা হয়েছে। v0.6.0-এ omnigent[memory] extra-এর নাম পরিবর্তন করে omnigent[hindsight] করা হয়েছে। তাই June-এর কোনো write-up থেকে কপি করা install line July build-এ ব্যর্থ হয়। আপনার install command-এ --version ব্যবহার করা এবং git clone-এ একটি tag নির্দিষ্ট করার কারণ এটাই; এটি কোনো style preference নয়।

এখনও যেসব কাজে আমি এটি ব্যবহার করব না

August 2026 অনুযায়ী repository-টির প্রায় 8.1k stars, 1.2k forks এবং মোটামুটি 350টি open issue রয়েছে। প্রথম public release-এর বয়স সাত সপ্তাহ। Stars আগ্রহের মাত্রা দেখায়, পরিপক্বতা নয়। Project-টি নিজেই alpha বলেছে, এবং উপরের release history-ও দেখায় যে এটি সত্যিই alpha পর্যায়ে রয়েছে।

• production credentials থাকা কোনো host-এ আমি এটি চালাব না, কারণ sandbox MCP server বা supervisor-কে কভার করে না।
• cost_budget policy ছাড়া কোনো run unattended অবস্থায় রেখে যাব না, কারণ তিনটি vendor সমান্তরালে bill করতে পারে এবং সেগুলো থামানোর জন্য অন্য কোনো নিয়ন্ত্রণ নেই।
• OMNIGENT_AUTH_ENABLED সেট না করে এবং সামনে TLS না রেখে public IP address-এ server expose করব না।
• minor version পরিবর্তনের মধ্যে agent YAML-কে এখনও stable ধরে নেব না। তাই version pin করুন এবং upgrade করার আগে release notes পড়ুন।

এটি আপনাকে অপ্রস্তুত অবস্থায় চমকে দেওয়ার আগে আরও একটি বিষয় জানা দরকার: v0.6.0 anonymised usage telemetry যোগ করেছে, এবং project-টি dedicated telemetry page-এ এটি নথিবদ্ধ করেছে। সেই page পড়ুন এবং machine-এ client-এর কাজ থাকলে ভেবেচিন্তে সিদ্ধান্ত নিন।

বর্তমানে Omnigent যে কাজে সত্যিই ভালো, সেটিই এর জন্য তৈরি করা হয়েছে। আপনার কাছে তিন বা চারটি agent CLI আছে, আপনি সেগুলোর জন্য ইতিমধ্যে অর্থ দিচ্ছেন, এবং আপনি চান একটি agent লিখবে, আরেকটি review করবে। এটি এখন একটি machine-এ, Linux-এ বাস্তব sandboxing সহ কাজ করে। এর পরের সবকিছুকে সম্ভাবনাময় কিন্তু অসম্পূর্ণ হিসেবে বিবেচনা করুন।

FAQ

Omnigent কি agent, নাকি agent চালায় এমন কোনো জিনিস?

এটি agent চালায়। Omnigent একটি meta-harness: এটি আপনার আগে থেকে ইনস্টল করা vendor CLI, যেমন Claude Code, Codex বা OpenCode, চালু করে, প্রতিটিকে কাজ দেয় এবং একই session-এ ফলাফল তদারক করে। এটি নিজস্ব কোনো model নিয়ে আসে না। এই কারণেই এটি framework থেকে আলাদা। Framework-এ আপনি একটি library-এর বিরুদ্ধে Python লিখে নিজের program-কে agent বানান।

Omnigent কার্যকর হওয়ার আগে কি Claude Code এবং Codex ইনস্টল করতে হবে?

কমপক্ষে একটি vendor CLI ইনস্টল করে লগ ইন করা থাকতে হবে, কারণ Omnigent ওই program-গুলো চালায়; সেগুলোর বিকল্প হিসেবে কাজ করে না। সরবরাহ করা Polly উদাহরণের জন্য ভিন্ন vendor-এর দুই বা ততোধিক CLI থাকা দরকার। Polly-এর নিয়ম হলো, review সবসময় implementer-এর চেয়ে ভিন্ন vendor দিয়ে করতে হবে। তাই একটি মাত্র CLI থাকলে diff পাঠানোর জন্য দ্বিতীয় কোনো vendor থাকে না।

সর্বশেষ সংস্করণের বদলে নির্দিষ্ট Omnigent version কীভাবে ইনস্টল করব?

install script-এর মাধ্যমে --version পাস করতে sh -s -- ব্যবহার করুন, যেমন 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।

unattended অবস্থায় agent চালানোর জন্য Omnibox sandbox কি যথেষ্ট?

যে বিষয়গুলো এটি নিয়ন্ত্রণ করে, সেগুলোর জন্য এটি শক্তিশালী এবং যেগুলো নিয়ন্ত্রণ করে না, সেগুলোও স্পষ্টভাবে জানায়। Linux-এ এটি bubblewrap এবং seccomp ব্যবহার করে। ফলে kernel file ও network সীমা প্রয়োগ করে এবং agent সেগুলো এড়াতে পারে না। Documentation-এ বলা হয়েছে, এটি sys_os_* tool call এবং terminal-এর ক্ষেত্রে প্রযোজ্য। তবে MCP server বা Omnigent supervisor process-এর ক্ষেত্রে এটি প্রযোজ্য নয়। তাই MCP server আপনার স্বাভাবিক permission নিয়ে চলে। এই কারণে unattended কাজের জন্য প্রতি agent-এ একটি disposable virtual machine ব্যবহার করাই বেশি শক্তিশালী isolation দেয়।

VPS-এ Omnigent server-এর কত memory প্রয়োজন?

Project-এর deploy note অনুযায়ী server-এর working set প্রায় 512 MB থেকে 1 GB। এর Fly.io configuration 1 GB নির্ধারণ করে। এতে শুধু supervisor এবং port 6767-এ চলা web interface অন্তর্ভুক্ত। প্রতিটি sub-agent একটি পৃথক process, যার নিজস্ব working copy এবং model client থাকে। Polly-এর মতো run-এ parallel git worktree ব্যবহৃত হয়। তাই server-এর জন্য নয়, একসঙ্গে চালানোর পরিকল্পনা করা agent-এর সংখ্যার ভিত্তিতে RAM এবং disk নির্ধারণ করুন।