آموزش کار با Omnigent برای مدیریت چندین Agent CLI

Omnigent چیست

Omnigent یک meta-harness متن‌باز است: یک لایه ارکستراسیون که ابزارهای خط فرمان (CLI) عامل‌هایی را که از قبل نصب کرده‌اید، مدیریت می‌کند. این ابزار جایگزین Claude Code، Codex، Cursor، OpenCode، Hermes یا Pi نمی‌شود. Omnigent آن‌ها را اجرا می‌کند، به هر کدام وظیفه‌ای محول می‌کند و نتیجه را در یک نشست واحد و تحت یک مجموعه سیاست مشخص نظارت می‌کند. Databricks این مخزن را در ژوئن 2026 تحت مجوز Apache 2.0 منتشر کرد و صفحه اصلی آن همچنان عبارت Status: alpha را نمایش می‌دهد.

ادعای کاربردی این ابزار محدود است و ارزش دارد که به‌صراحت بیان شود. شما یک عامل را یک‌بار در قالب YAML توصیف می‌کنید و نام harness اجراکننده آن را مشخص می‌کنید. با تغییر همان یک خط، همان عامل روی CLI فروشنده دیگری اجرا می‌شود. هیچ بخش دیگری از تنظیمات شما تغییر نمی‌کند، زیرا Omnigent حلقه کنترلی بالای عامل‌ها را در اختیار دارد، نه حلقه درون آن‌ها را.

متا-هارنس (meta-harness) چیست و چه تفاوتی با فریم‌ورک دارد؟

هارنس برنامه‌ای است که مدل را در یک حلقه محصور می‌کند. این برنامه پرامپت شما را می‌خواند، ابزارها را فراخوانی می‌کند، فایل‌ها را ویرایش کرده و گزارش می‌دهد. Claude Code یک هارنس است. Codex نیز یک هارنس است. شما آن را نصب می‌کنید، وارد حساب خود می‌شوید و برنامه به‌طور خودکار کار می‌کند.

فریم‌ورک کتابخانه‌ای است که شما کد خود را بر اساس آن می‌نویسید. شما آن را import می‌کنید، مراحل را در Python تعریف می‌کنید و برنامهٔ شما تبدیل به ایجنت می‌شود. تغییر فروشنده (vendor) در این حالت مستلزم ویرایش کد شماست، زیرا کلاینتِ فروشنده در برنامهٔ شما ادغام شده است.

متا-هارنس یک سطح بالاتر از هر دوی این‌ها قرار دارد. این یک ناظر است که هارنس‌ها را به عنوان پردازش‌های فرزند (child processes) اجرا می‌کند. Omnigent رابط خط فرمان (CLI) فروشنده را اجرا می‌کند، کار را به آن می‌سپارد و خروجی را می‌خواند. شما همان CLI که قبلاً نصب کرده‌اید را حفظ می‌کنید و اشتراک یا کلید API (رابط برنامه‌نویسی اپلیکیشن) خود را که برای آن پرداخت کرده‌اید، همچنان در اختیار دارید. تفاوت اصلی همین است و همین موضوع تعیین می‌کند که ابزار برای چه کسی مناسب است: افرادی که چندین CLI ایجنت دارند که از قبل کار می‌کنند و از مدیریت تک‌تک آن‌ها در ترمینال‌های جداگانه خسته شده‌اند.

یک لایه ارکستراسیون چه مشکلی را حل می‌کند؟

• هزینه تغییر فروشنده تنها یک خط است. تعریف agent شامل harness و model به عنوان داده است، بنابراین انتقال یک نقش از یک فروشنده به فروشنده دیگر، تنها یک ویرایش در فایل YAML است و نه بازنویسی کامل.
• بررسی می‌تواند بین فروشندگان مختلف انجام شود. یک diff که توسط یک مدل نوشته شده است، توسط مدلی از یک شرکت متفاوت خوانده می‌شود. دو مدل از یک خانواده معمولاً نقاط کور مشابهی دارند، بنابراین نظر دوم از همان فروشنده ارزش کمتری دارد.
• سیاست‌ها یک جایگاه واحد دارند. سقف هزینه‌ها و درخواست‌های تأیید در فایل agent تعریف می‌شوند و برای تمام زیر-agentهای تحت آن اعمال می‌گردند.
• نشست (session) از هر ابزار تکی طولانی‌تر عمر می‌کند. یک رونوشت (transcript) کل کاری را که توسط چندین CLI انجام شده پوشش می‌دهد، بنابراین می‌توانید بدون نیاز به کنار هم قرار دادن چهار خروجی مختلف، آنچه رخ داده است را بازخوانی کنید.

هزینه این کار، خودِ این لایه است. هر باگ در Omnigent اکنون باگی است که بین شما و agent قرار گرفته که قبلاً به‌تنهایی کار می‌کرد. در مرحله آلفا، این یک هزینه واقعی است، نه یک هزینه نظری.

جایگاه ابزارهای چندعاملی (multi-agent) در کنار ابزارهای تک‌عاملی

اگر هنوز یک عامل (agent) را روی سرور اجرا نکرده‌اید، از آنجا شروع کنید. راهنمای ما برای اجرای یک عامل کدنویسی روی VPS، سناریوی تک‌عاملی را به‌طور کامل پوشش می‌دهد و این همان پیش‌فرضی است که Omnigent برای راه‌اندازی در نظر می‌گیرد. حوزه گسترده‌تر عوامل هوش مصنوعی خودمیزبان (self-hosted) جایی است که می‌توانید خودِ عامل‌ها را انتخاب کنید، و اگر اصطلاحات این حوزه برای شما جدید است، یادگیری نحوه عملکرد واقعی عامل‌ها نقطه شروع بهتری خواهد بود.

Omnigent همچنین در محور متفاوتی نسبت به لایه‌های اتصال‌دهنده (connector layer) قرار دارد. کارهایی مانند دادن دسترسی به عامل‌ها به منابع داده شخصی درباره این است که یک عامل به چه چیزی می‌تواند دسترسی داشته باشد. Omnigent درباره این است که کدام عامل، با چه ترتیبی و تحت چه محدودیت‌هایی اجرا شود. شما می‌توانید هر دو را همزمان بخواهید و این دو با هم تداخلی ندارند.

پیش‌نیازهای پیش از نصب

• نسخه Python 3.12 یا جدیدتر. بسته منتشرشده، requires-python >= 3.12 را به عنوان پیش‌نیاز اعلام می‌کند.
• tmux، زیرا محیط‌های اجرای ترمینال درون آن اجرا می‌شوند.
• حداقل یک CLI فروشنده که از قبل نصب شده و در آن لاگین کرده باشید.
• Node.js 22، تنها در صورتی که قصد دارید برنامه را از روی git checkout کامپایل کنید. فایل wheel موجود در PyPI شامل دارایی‌های وبِ از پیش ساخته‌شده است، بنابراین نصب معمولی به هیچ‌وجه به Node نیاز ندارد.

نصب یک نسخه ثابت (Pinned 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 را به عنوان گزینه اختصاصی خود می‌خواند و نصب‌کننده هرگز آن پرچم (flag) را نمی‌بیند؛ در نتیجه، شما همیشه جدیدترین نسخه موجود در آن روز را دریافت می‌کنید. در مخزنی که هر چند هفته یک‌بار تغییرات ساختارشکن (breaking changes) منتشر می‌کند، این موضوع تفاوت بین یک سرور با قابلیت بازتولید (reproducible) و یک غافلگیری ناخوشایند است.

این نصب‌کننده از uv، مدیر بسته پایتون شرکت Astral، استفاده می‌کند و در صورت نبود آن، پیشنهاد می‌دهد ابتدا uv را نصب کنید. اگر uv از قبل نصب شده است، از اسکریپت صرف‌نظر کنید:

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

بخش‌های اضافی (Extras) نیز از همین الگو پیروی می‌کنند و پرچم مربوطه تکرار می‌شود: --extra e2b --extra kubernetes در اسکریپت، یا "omnigent[e2b,kubernetes]" با استفاده از uv. توجه داشته باشید که تگ git برابر با v0.7.0 است، در حالی که نسخه بسته در PyPI برابر با 0.7.0 می‌باشد.

ابزار uv فایل باینری را در دایرکتوری که uv tool dir --bin گزارش می‌دهد قرار می‌دهد، که معمولاً ~/.local/bin است، و نصب‌کننده پیشنهاد می‌دهد آن را به پروفایل شل شما اضافه کند. اگر بلافاصله پس از یک نصب تمیز، دستور پیدا نشد، دلیل آن همین است. بررسی کنید چه چیزی در نهایت نصب شده است:

omni upgrade --check

این دستور نسخه نصب‌شده را با آخرین نسخه منتشرشده مقایسه می‌کند و بدون انجام ارتقا، به شما اطلاع می‌دهد که آیا نسخه جدیدتری وجود دارد یا خیر. omni و omnigent هر دو یک برنامه با دو نام متفاوت هستند.

تنظیم ارائه‌دهنده مدل

omni setup

ویزارد به‌طور خودکار اعتبارنامه‌های موجود در محیط شما را جستجو کرده و برای موارد مفقود از شما درخواست ورودی می‌کند. این ابزار کلیدهای API، اشتراک‌های فروشندگان، درگاه‌هایی مانند OpenRouter یا Ollama و محیط‌های کاری Databricks را مدیریت می‌کند. اگر در حال حاضر یک سرور مدل محلی با Ollama روی همان دستگاه اجرا می‌کنید، یک درگاه (gateway) را به آن متصل کنید تا ترافیک هرگز از دستگاه خارج نشود.

اجرای حداقلی چند عاملی (multi-agent)

عامل‌های نمونه در مخزن قرار دارند، بنابراین به‌جای main، همان تگی را کلون کنید که نصب کرده‌اید.

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

Polly یک ارکستراتور کدنویسی چندعاملی است که همراه با مخزن عرضه می‌شود. پیکربندی آن، عامل‌های فرعی با نام‌های claude_code، codex، opencode، cursor، hermes و pi را تعریف می‌کند و شامل یک قانون است که اجرای این تمرین را ارزشمند می‌سازد: بازبینی همیشه باید توسط فروشنده‌ای متفاوت از پیاده‌ساز انجام شود. Polly خود هیچ کدی نمی‌نویسد. این ابزار برنامه‌ریزی می‌کند، هدف را به واحدهای کاری تقسیم کرده، هر کدام را محول می‌کند و هر diff را برای بازبینی به فروشنده‌ای دیگر ارجاع می‌دهد.

پیش از محول کردن هر کاری، Polly یک بررسی اولیه (preflight check) انجام می‌دهد تا ببیند کدام CLIهای عامل‌های فرعی واقعاً روی سیستم موجود هستند. اگر تنها یک CLI فروشنده نصب شده باشد، کسی برای تحویل گرفتن diff وجود نخواهد داشت؛ بنابراین پیش از قضاوت درباره خروجی، حداقل دو مورد را نصب کنید. Debby، دیگر نمونه عرضه شده، یک عامل مناظره با دو سر است که یکی از آن‌ها Claude و دیگری GPT است:

omni debby

این روشی کوتاه برای اطمینان از پیکربندی دو ارائه‌دهنده است، زیرا برای گفتن هر چیزی به هر دو نیاز دارد.

زیر-عامل‌ها (Sub-agents) به عنوان ابزار تعریف می‌شوند

فایل عامل با فرمت YAML است. executor نام harness، مدل و احراز هویت را مشخص می‌کند. tools شامل سرورهای MCP (پروتکل زمینه مدل)، توابع Python و زیر-عامل‌ها است. یک زیر-عامل، ابزاری با 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

آن شناسه‌های مدل از نمونه docs/AGENT_YAML_SPEC.md خود پروژه گرفته شده‌اند و نام‌های میزبانی‌شده توسط Databricks هستند. مقادیر harness و model را با هر آنچه در سیستم خود برای omni setup پیکربندی کرده‌اید، جایگزین کنید. سایر مقادیر harness در مشخصات شامل antigravity، copilot، kimi، qwen و acp:<slug> برای هر چیزی است که از پروتکل عمومی پشتیبانی می‌کند. این مشخصات همچنین از pass_history: true در یک زیر-عامل پشتیبانی می‌کند که گفتگوی والد را به آن منتقل می‌کند. این کار در هر تفویض وظیفه هزینه توکن دارد، بنابراین برای زیر-عامل‌هایی که فقط به وظیفه محول‌شده نیاز دارند، آن را غیرفعال بگذارید. برنامه‌نویسی که prompt آن، دستور انجام کوچک‌ترین تغییر کارآمد را می‌دهد، یک diff به بازبین خود تحویل می‌دهد که به اندازه کافی کوتاه است تا واقعاً خوانده شود؛ این موضوع در اینجا اهمیت بیشتری نسبت به مدلی دارد که برای هر یک از نقش‌ها انتخاب می‌کنید.

چرا ارکستراسیون‌های طولانی‌مدت باید روی یک VPS اجرا شوند

اجرای یک multi-agent بیش از دو دقیقه زمان می‌برد. برنامه‌ریزی، تفویض وظایف، انتظار برای کارهای موازی در git worktree، بازبینی و اصلاح، همگی زمان‌بر هستند. بستن درب لپ‌تاپ باعث پایان یافتن تمام این فرآیندها می‌شود. یک VPS (سرور مجازی خصوصی) همیشه روشن است و اتصال شبکه خود را حفظ می‌کند، بنابراین نشست (session) شما در زمانی که نظارتی بر آن ندارید، فعال باقی می‌ماند.

omnigent server --background
omnigent server status

این سرور یک رابط کاربری وب را روی پورت 6767 میزبانی می‌کند. omnigent server status وضعیت اجرای آن را گزارش می‌دهد و omnigent stop آن را متوقف می‌کند. در نسخه‌های پیش از v0.7.0 این کار با omni server start انجام می‌شد که اکنون حذف شده است؛ بنابراین مستندات و اسکرین‌شات‌های قدیمی با عملکرد ترمینال شما مطابقت نخواهند داشت.

پورت 6767 را روی یک آدرس عمومی منتشر نکنید. دو روش برای ایمن‌سازی آن وجود دارد. پورت را در فایروال بسته نگه دارید و آن را از طریق SSH با ssh -N -L 6767:localhost:6767 you@your-server فوروارد کنید، سپس رابط کاربری وب را در http://localhost:6767 روی دستگاه خود باز کنید. یا اینکه TLS (امنیت لایه انتقال) را در مقابل آن قرار داده و احراز هویت را فعال کنید:

OMNIGENT_AUTH_ENABLED=1 omnigent server --background

بخش فایروال این کار یک روال عادی است که در اصول اولیه فایروال ufw برای یک VPS پوشش داده شده است. اگر سرور شما در حال حاضر کانتینرهایی را پشت Traefik در مقابل چندین برنامه Docker Compose اجرا می‌کند، Omnigent نیز یک سرویس دیگر در همان الگو خواهد بود.

برای استقرار کانتینری، دایرکتوری 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 یک پردازش مجزا است که checkout و کلاینت مدل مخصوص به خود را دارد، بنابراین سرور را بر اساس تعداد agentها انتخاب کنید. پس از بالا آمدن سرور، omnigent login https://your-host به همراه omnigent host https://your-host لپ‌تاپ شما را در سرور ثبت می‌کند و omnigent attach <session_id> یک نشست در حال اجرا را از دستگاهی دیگر بازیابی می‌کند.

پیش از ترک سیستم، هر زیر-عامل (sub-agent) را در Sandbox قرار دهید

Omnigent یک sandbox در سطح سیستم‌عامل به نام Omnibox ارائه می‌دهد. این ابزار در لینوکس از namespaceهای bubblewrap به همراه seccomp استفاده می‌کند، بنابراین هسته سیستم‌عامل (kernel) مرزها را اعمال می‌کند، نه دستورات خودِ عامل. عاملی که دچار prompt injection شده باشد، نمی‌تواند با متقاعدسازی از قوانین هسته عبور کند. ابتدا وابستگی‌های لازم را نصب کنید:

sudo apt install bubblewrap

پیکربندی این ابزار در فایل عامل و تحت بخش 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 لیست نشود، فقط‌خواندنی (read-only) باقی می‌ماند؛ بنابراین عاملی که دچار خطا شود، نمی‌تواند خارج از فضای کاری بنویسد. فایل‌های نقطه (dotfiles) مخفی می‌مانند مگر اینکه در cwd_allow_hidden نام برده شوند؛ این یعنی اعطای دسترسی خواندن گسترده، به‌طور پنهانی باعث افشای .ssh یا .aws نمی‌شود. با تنظیم egress_rules، تمام ترافیک HTTP و HTTPS از یک پروکسی با سیاست پیش‌فرض deny عبور می‌کند و هر قانون به صورت "METHODS host/path-glob" نوشته می‌شود. credential_proxy یک گام فراتر می‌رود: عامل تنها یک جای‌نگهدار (placeholder) در اختیار دارد و پروکسی هنگام خروج درخواست، مقدار واقعی secret را جایگزین می‌کند؛ بنابراین در صورت نشت متن گفتگو، هیچ داده قابل‌استفاده‌ای لو نمی‌رود. در یک تنظیمات چند-ابزاری (multi-harness)، هر زیر-عامل بلوک sandbox مخصوص به خود را در فایل پیکربندی‌اش تحت agents/ دارد؛ بنابراین می‌توان دسترسی شبکه را از یک بازبین (reviewer) سلب کرد در حالی که مجری (implementer) همچنان به آن دسترسی دارد.

محدودیت‌ها در مستندات ذکر شده‌اند و اهمیت دارند. این sandbox سیستم‌عامل برای فراخوانی ابزارهای sys_os_* و ترمینال‌ها اعمال می‌شود. این ابزار شامل سرورهای MCP یا خودِ پردازش ناظر Omnigent نمی‌شود. سرور MCP که راه‌اندازی می‌کنید، خارج از این sandbox و با مجوزهای کاربری شما اجرا می‌شود. به همین دلیل است که الگوی قوی‌تر، استفاده از یک ماشین یک‌بارمصرف (throwaway machine) برای هر عامل است که موضوع اجرای عوامل برنامه‌نویسی در یک VM یک‌بارمصرف است. نیمه دیگر این کار مربوط به اعتبارنامه‌ها است و دور نگه داشتن secretها از دسترس عامل زمانی که شش زیر-عامل از یک میزبان مشترک استفاده می‌کنند، دشوارتر می‌شود.

محدودیت‌های هزینه (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]

اجرایی که برنامه‌ریزی را با یک سرویس‌دهنده، پیاده‌سازی را با دومی و بازبینی را با سومی انجام می‌دهد، همزمان در سه جا هزینه ایجاد می‌کند؛ بنابراین سقف بودجه را پیش از اولین اجرای بدون نظارت تعیین کنید، نه پس از دریافت اولین صورت‌حساب. قابلیت‌های داخلی شامل max_tool_calls_per_session و ask_on_os_tools نیز هستند که پیش از عملیات فایل و شل، درخواست تأیید می‌کنند. یادداشت‌های ما در مورد کنترل هزینه‌های عوامل هوش مصنوعی روی VPS مستقیماً در اینجا کاربرد دارند و حتی با شدت بیشتری صادق هستند، زیرا زیر-عامل‌های موازی نرخ مصرف منابع را چند برابر می‌کنند.

سرعت توسعه این مخزن چقدر است؟

[
  {
    "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 خوانده شده‌اند. تعداد 7 نسخه تگ‌شده بین 2026-06-19 و 2026-07-27 منتشر شده‌اند و طولانی‌ترین فاصله بین هر دو نسخه 11 روز بوده است. نسخه v0.5.1 در همان روزی منتشر شد که نسخه پیش از آن عرضه شده بود. اولین نسخه، یعنی 0.1.1 در تاریخ 16 June 2026، از نمودار حذف شده است زیرا تگ قبلی برای محاسبه فاصله وجود ندارد.

دو مورد از این نسخه‌ها دستوراتی را که در راهنماها مستند شده بودند، از کار انداختند. نسخه v0.7.0 دستور omni server start را حذف و omni server --background را جایگزین آن کرد. نسخه v0.6.0 نام extra مربوط به omnigent[memory] را به omnigent[hindsight] تغییر داد، بنابراین دستور نصبی که از یک نوشته در ماه June کپی شده باشد، در بیلد ماه July با خطا مواجه می‌شود. این موضوع دلیلی بر استفاده از --version در دستور نصب و تعیین تگ در git clone است و صرفاً یک ترجیح در سبک نگارش نیست.

مواردی که هنوز به آن اعتماد نمی‌کنم

تا اوت 2026، این مخزن حدود 8.1 هزار ستاره، 1.2 هزار فورک و تقریباً 350 ایشو باز دارد و از اولین نسخه عمومی آن هفت هفته می‌گذرد. ستاره‌ها نشان‌دهنده میزان علاقه هستند و علاقه به معنای بلوغ نرم‌افزار نیست. پروژه وضعیت خود را آلفا اعلام کرده است و تاریخچه انتشار ذکر شده در بالا نشان می‌دهد که این وضعیت واقعاً آلفا است.

• من آن را روی میزبانی که حاوی اعتبارنامه‌های عملیاتی (production credentials) است اجرا نمی‌کنم، زیرا محیط sandbox شامل سرورهای MCP یا supervisor نمی‌شود.
• من یک اجرا را بدون سیاست cost_budget بدون نظارت رها نمی‌کنم، زیرا سه فروشنده می‌توانند به‌طور هم‌زمان هزینه دریافت کنند و هیچ مکانیزم دیگری برای جلوگیری از آن وجود ندارد.
• من سرور را بدون تنظیم OMNIGENT_AUTH_ENABLED و قرار دادن TLS در مقابل آن، روی یک IP عمومی در معرض دید قرار نمی‌دهم.
• من فایل YAML عامل را هنوز به عنوان پایدار در نسخه‌های فرعی در نظر نمی‌گیرم، بنابراین نسخه را ثابت (pin) کنید و پیش از ارتقا، یادداشت‌های انتشار را مطالعه کنید.

یک نکته دیگر که باید پیش از غافلگیر شدن بدانید: نسخه v0.6.0 تله‌متری استفاده ناشناس را اضافه کرده است و پروژه آن را در یک صفحه اختصاصی تله‌متری مستند کرده است. آن صفحه را بخوانید و اگر دستگاه کارهای مشتری را پردازش می‌کند، آگاهانه تصمیم بگیرید.

آنچه Omnigent در حال حاضر واقعاً در آن خوب عمل می‌کند، همان هدفی است که برای آن ساخته شده است. شما سه یا چهار CLI عامل دارید، از قبل هزینه آن‌ها را پرداخت می‌کنید و می‌خواهید یکی از آن‌ها بنویسد در حالی که دیگری بازبینی می‌کند. این کار اکنون روی یک دستگاه و با sandbox واقعی در لینوکس انجام می‌شود. هر چیزی فراتر از این را به عنوان یک قابلیت امیدوارکننده اما ناتمام در نظر بگیرید.

FAQ

آیا Omnigent یک عامل (agent) است یا ابزاری برای اجرای عامل‌ها؟

این ابزار عامل‌ها را اجرا می‌کند. Omnigent یک meta-harness است: رابط‌های خط فرمان (CLI) فروشندگانی که قبلاً نصب کرده‌اید (مانند Claude Code، Codex یا OpenCode) را فراخوانی می‌کند، به هر کدام وظیفه‌ای محول کرده و نتایج را در یک نشست واحد نظارت می‌کند. این ابزار مدل اختصاصی خود را ندارد. به همین دلیل با یک فریم‌ورک متفاوت است؛ در فریم‌ورک شما با استفاده از یک کتابخانه کد پایتون می‌نویسید و برنامهٔ خودتان به عامل تبدیل می‌شود.

آیا پیش از استفاده از Omnigent باید Claude Code و Codex را نصب کرده باشم؟

شما باید حداقل یک CLI فروشنده را نصب کرده و در آن لاگین کرده باشید، زیرا Omnigent به‌جای جایگزینی این برنامه‌ها، آن‌ها را هدایت می‌کند. برای مثال Polly که همراه محصول ارائه شده، به دو یا چند CLI از فروشندگان مختلف نیاز دارید. قانون Polly این است که بازبینی (review) همیشه باید توسط فروشنده‌ای متفاوت از پیاده‌ساز (implementer) انجام شود؛ بنابراین اگر تنها یک CLI در دسترس باشد، فروشنده دومی برای ارسال diff وجود نخواهد داشت.

چگونه می‌توانم به‌جای آخرین نسخه، نسخهٔ خاصی از Omnigent را نصب کنم؟

مقدار --version را با استفاده از sh -s -- به اسکریپت نصب ارسال کنید، همان‌طور که در sh -s -- --version 0.7.0 آمده است. بدون -s --، این فلگ توسط خود sh مصرف می‌شود و اسکریپت جدیدترین نسخهٔ منتشرشده را نصب می‌کند. اگر uv از قبل نصب شده باشد، uv tool install --force --python 3.12 "omnigent==0.7.0" همین کار را انجام می‌دهد. تگ گیت v0.7.0 است، در حالی که رشتهٔ نسخه در PyPI به صورت 0.7.0 می‌باشد.

آیا محیط sandbox در Omnibox برای اجرای بدون نظارت عامل‌ها کافی است؟

این محیط برای آنچه پوشش می‌دهد قدرتمند است و در مورد محدودیت‌هایش شفاف عمل می‌کند. در لینوکس از bubblewrap به همراه seccomp استفاده می‌کند، بنابراین هستهٔ سیستم‌عامل محدودیت‌های فایل و شبکه را اعمال می‌کند و عامل نمی‌تواند از آن‌ها سرپیچی کند. مستندات بیان می‌کنند که این محدودیت‌ها برای فراخوانی ابزارهای sys_os_* و ترمینال‌ها اعمال می‌شود و سرورهای MCP یا فرایند ناظر Omnigent را پوشش نمی‌دهد. بنابراین یک سرور MCP با مجوزهای عادی شما اجرا می‌شود؛ به همین دلیل است که برای کارهای بدون نظارت، استفاده از یک ماشین مجازی یک‌بارمصرف برای هر عامل، همچنان روش ایزوله‌سازی قوی‌تری محسوب می‌شود.

یک سرور Omnigent روی VPS به چه مقدار حافظه نیاز دارد؟

یادداشت‌های استقرار پروژه، فضای کاری حدود 512 MB تا 1 GB را برای سرور پیشنهاد می‌دهند و پیکربندی Fly.io آن نیز 1 GB را اختصاص داده است. این مقدار فقط ناظر و رابط وب روی پورت 6767 را پوشش می‌دهد. هر زیر-عامل (sub-agent) یک فرایند مجزا با کپی کاری و کلاینت مدل مخصوص به خود است و اجراهای به سبک Polly از git worktreeهای موازی استفاده می‌کنند؛ بنابراین رم و دیسک را بر اساس تعداد عامل‌هایی که قصد دارید هم‌زمان اجرا کنید تنظیم کنید، نه فقط برای خود سرور.