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

Omnigent কী

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

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

মেটা-hারনেস কী, এবং এটি framework থেকে কীভাবে আলাদা?

Harness হলো এমন একটি program, যা একটি 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-এ ঘোষণা করা হয়। এগুলো ওই agent-এর অধীন প্রতিটি sub-agent-এর ক্ষেত্রে প্রযোজ্য হয়।
• Session কোনো একটি tool-এর ওপর নির্ভর করে থাকে না। একটি transcript-এ একাধিক CLI-তে করা কাজের বিবরণ থাকে। তাই চারটি scrollback একসঙ্গে মিলিয়ে না দেখেও কী ঘটেছে তা পরে পড়ে দেখা যায়।

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

একটি single-agent tool-এর পাশে multi-agent harness কোথায় উপযোগী

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

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

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

• Python 3.12 বা পরবর্তী সংস্করণ। প্রকাশিত package-এ requires-python >= 3.12 নির্ধারিত আছে।
• tmux, কারণ terminal harness-গুলো এর ভেতরে চলে।
• অন্তত একটি vendor CLI, যা আগে থেকেই ইনস্টল করা এবং লগ ইন করা আছে।
• git checkout থেকে build করলে শুধু Node.js 22 প্রয়োজন। PyPI-এর wheel-এ তৈরি web asset অন্তর্ভুক্ত থাকে, তাই সাধারণ ইনস্টলের জন্য 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 আগে থেকেই থাকলে 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 দেখায়। সাধারণত এটি ~/.local/bin হয়। installer আপনার shell profile-এ directory-টি যোগ করার প্রস্তাব দেয়। পরিষ্কারভাবে ইনস্টল করার পরপরই command না পাওয়া গেলে, কারণটি সাধারণত এটাই। শেষ পর্যন্ত কী ইনস্টল হয়েছে তা পরীক্ষা করুন:

omni upgrade --check

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

একটি model provider-এর দিকে নির্দেশ করুন

omni setup

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

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

উদাহরণ agent-গুলো repository-তে আছে। তাই main-এর পরিবর্তে আপনি যে একই tag install করেছেন, সেটি clone করুন।

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। এর config-এ 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 install থাকলে diff পাঠানোর মতো অন্য কেউ থাকে না। তাই output মূল্যায়নের আগে অন্তত দুটি vendor CLI install করুন। অন্য shipped example Debby হলো দুইটি head-সহ একটি debate agent; একটি Claude এবং অন্যটি GPT:

omni debby

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

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

এজেন্ট ফাইলটি YAML। executor-এ harness, model এবং authentication-এর নাম থাকে। tools-এ MCP (model context protocol) server, Python function এবং 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 প্রয়োজন, তার জন্য এটি সক্রিয় রাখবেন না।

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

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

6767 কোনো public address-এ প্রকাশ করবেন না। নিরাপদ ব্যবহারের দুটি পদ্ধতি আছে। firewall-এ port বন্ধ রাখুন এবং ssh -N -L 6767:localhost:6767 you@your-server দিয়ে SSH-এর মাধ্যমে port 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 চালানো থাকে, তাহলে Omnigent একই pattern-এর আরও একটি service।

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

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

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

Omnigent একটি operating system স্তরের sandbox সরবরাহ করে, যার নাম Omnibox। Linux-এ এটি bubblewrap namespace এবং seccomp ব্যবহার করে। তাই সীমানা agent-এর prompt নয়, kernel enforce করে। Prompt injection করা agent kernel-এর নিয়ম এড়াতে কথার মাধ্যমে কোনো উপায় তৈরি করতে পারে না। প্রথমে 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-এ নাম উল্লেখ না করা পর্যন্ত dotfile গোপন থাকে। এর ফলে broad 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 ফাঁস হলেও ব্যবহারযোগ্য কোনো secret ফাঁস হয় না। Multi-harness setup-এ প্রতিটি sub-agent নিজের config file-এ, agents/-এর অধীনে, নিজের sandbox block বহন করে। ফলে reviewer-এর network access বন্ধ রাখা যায়, কিন্তু implementer-এর access চালু রাখা যায়।

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

Spend limit হলো policy, এবং একই file-এ তা declare করা হয়:

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-in policy-গুলোর মধ্যে 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 date। 7টি tagged release 2026-06-19 থেকে 2026-07-27-এর মধ্যে প্রকাশিত হয়েছে। যেকোনো দুটি 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 আগ্রহের মাত্রা দেখায়, পরিপক্বতা নয়। প্রকল্পটি নিজেই এটিকে alpha বলেছে, এবং উপরের release history-ও দেখায় যে এটি সত্যিই alpha পর্যায়ে রয়েছে।

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

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

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

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 ইনস্টল করে login করা থাকতে হবে, কারণ Omnigent ওই program-গুলোকে চালায়; এগুলোর বিকল্প নয়। সরবরাহ করা Polly example-এর জন্য আপনি ভিন্ন 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।

Agent-কে unattended অবস্থায় চালানোর জন্য 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 নির্ধারণ করুন।