ما هو Omnigent؟ تشغيل عدة CLIs للوكلاء معًا

ما هو Omnigent

Omnigent هو meta-harness مفتوح المصدر: طبقة orchestration واحدة تشغّل أدوات سطر أوامر الوكلاء (CLIs) المثبّتة لديك. لا يستبدل Claude Code أو Codex أو Cursor أو OpenCode أو Hermes أو Pi. بل يشغّلها، ويمنح كل واحدة منها مهمة، ويراقب النتيجة داخل جلسة واحدة باستخدام مجموعة سياسات موحّدة. نشرت Databricks المستودع في June 2026 بموجب ترخيص Apache 2.0، وما زالت الصفحة الرئيسية تعرض Status: alpha.

الادعاء العملي محدود، ومن المفيد توضيحه مباشرة. تصف الوكيل مرة واحدة في YAML، وتحدّد الـharness الذي يشغّله. غيّر هذا السطر وحده، وسيعمل الوكيل نفسه باستخدام CLI من مورّد آخر. لا يتغير أي شيء آخر في إعدادك، لأن Omnigent يدير الحلقة فوق الوكلاء، وليس الحلقة داخلهم.

ما هو الـmeta-harness، وكيف يختلف عن framework؟

الـharness هو البرنامج الذي يغلّف النموذج داخل حلقة تشغيل. يقرأ prompt، ويستدعي الأدوات، ويعدّل الملفات، ثم يعرض النتيجة. Claude Code هو harness. وCodex هو harness. تثبّته، وتسجّل الدخول، ثم يعمل من تلقاء نفسه.

أما framework فهو مكتبة تكتب التعليمات البرمجية بالاعتماد عليها. تستوردها، وتعرّف الخطوات في Python، ويصبح برنامجك هو الـagent. عند تغيير المورّد، يجب تعديل التعليمات البرمجية، لأن عميل المورّد مضمَّن في برنامجك.

يقع الـmeta-harness في مستوى أعلى من كليهما. وهو مشرف يشغّل الـharnesses كعمليات فرعية. يبدأ Omnigent واجهة سطر أوامر المورّد، ويمرّر إليها العمل، ثم يقرأ ما تعيده. تحتفظ بواجهة سطر الأوامر التي ثبّتَّها مسبقاً، وتحتفظ أيضاً بالاشتراك أو بمفتاح API (واجهة برمجة التطبيقات) الذي تستخدمه للدفع مقابله. هذا هو الفرق بأكمله، وهو يحدّد الفئة التي تستفيد من الأداة: الأشخاص الذين لديهم عدة واجهات سطر أوامر للـagents تعمل بالفعل، وقد سئموا من تشغيلها واحدة تلو الأخرى في كل terminal.

ما المشكلة التي تحلها طبقة تنسيق واحدة؟

• تبديل المورّد يتطلب تعديل سطر واحد. يحتفظ تعريف الوكيل بـ harness وmodel كبيانات، لذا فإن نقل دور من مورّد إلى آخر يتطلب تعديل ملف YAML، لا إعادة كتابة التعريف.
• يمكن أن تمتد المراجعة عبر مورّدين مختلفين. يقرأ نموذج من شركة مختلفة الفروقات التي أنشأها نموذج آخر. تميل النماذج من العائلة نفسها إلى مشاركة النقاط العمياء نفسها، لذلك تكون قيمة الرأي الثاني من المورّد نفسه أقل.
• للسياسة مكان واحد. تُعرَّف حدود الإنفاق ومطالبات الموافقة في ملف الوكيل، وتُطبَّق على كل وكيل فرعي تحته.
• تتجاوز الجلسة عمر أي أداة واحدة. يغطي سجل محادثة واحد العمل المنفَّذ عبر عدة واجهات سطر أوامر، لذلك يمكنك مراجعة ما حدث من دون جمع أربع سجلات تمرير معاً.

التكلفة هي الطبقة نفسها. كل خطأ في Omnigent يصبح الآن خطأً يقع بينك وبين وكيل كان يعمل بمفرده. في الإصدار alpha، هذه تكلفة فعلية وليست نظرية.

أين يندرج إطار تشغيل عدة وكلاء إلى جانب أدوات الوكيل الواحد

إذا لم تكن قد شغّلت وكيلاً واحداً على خادم بعد، فابدأ بذلك بدلاً من هذا. يشرح دليلنا تشغيل وكيل برمجي على VPS حالة الوكيل الواحد من البداية إلى النهاية، ويفترض Omnigent أن هذا الإعداد موجود لديك مسبقاً. أما المجال الأوسع الخاص بـوكلاء الذكاء الاصطناعي المستضافين ذاتياً فهو المكان الذي تختار فيه الوكلاء أنفسهم، بينما يُعدّ تعلّم كيفية عمل الوكلاء فعلياً نقطة البداية الأفضل إذا كانت المصطلحات الواردة هنا جديدة عليك.

يختلف Omnigent أيضاً عن طبقة الموصلات من حيث الوظيفة. يتناول عمل مثل منح الوكلاء إمكانية الوصول إلى مصادر بياناتك الخاصة ما يمكن للوكيل الوصول إليه. أما Omnigent فيتعلق بالوكيل الذي يعمل، وترتيب تشغيله، والحدود التي يخضع لها. يمكنك استخدام الأمرين معاً، ولا يتداخل أحدهما مع الآخر.

ما تحتاج إليه قبل التثبيت

• Python 3.12 أو إصدار أحدث. تعلن الحزمة المنشورة عن requires-python >= 3.12.
• tmux، لأن أدوات تشغيل الطرفية تعمل داخله.
• واجهة أوامر واحدة على الأقل من أحد المورّدين، مثبّتة ومسجّل الدخول إليها مسبقاً.
• Node.js 22 فقط إذا بنيت الحزمة من نسخة مستنسخة من مستودع git. تتضمن wheel المنشورة على PyPI أصول الويب المبنية، لذلك لا يحتاج التثبيت العادي إلى Node مطلقاً.

تثبيت إصدار محدد، وليس إصدار 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 باعتبارها خياراً مستقلاً، ولا يرى المثبّت الراية، فتحصل على أحدث إصدار متاح في ذلك اليوم. في مستودع ينشر تغييرات كاسرة للتوافق كل بضعة أسابيع، يمثّل ذلك الفرق بين خادم يمكن إعادة إنتاجه ونتيجة غير متوقعة.

يستخدم المثبّت uv، وهو مدير حزم Python من Astral، ويعرض تثبيت uv أولاً إذا لم يكن موجوداً. إذا كان uv مثبتاً بالفعل، فتجاوز البرنامج النصي:

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

تتبع الإضافات النمط نفسه، وتتكرر الراية: --extra e2b --extra kubernetes مع البرنامج النصي، أو "omnigent[e2b,kubernetes]" مع uv. لاحظ أن وسم git هو v0.7.0، بينما إصدار الحزمة على PyPI هو 0.7.0.

يضع uv الملف التنفيذي في الدليل الذي يعرضه uv tool dir --bin، وعادةً يكون ~/.local/bin، ويعرض المثبّت إضافة هذا الدليل إلى ملف تعريف shell. إذا لم يُعثر على الأمر مباشرة بعد تثبيت نظيف، فهذا هو السبب. تحقّق مما تم تثبيته:

omni upgrade --check

يقارن ذلك الإصدار المثبّت بأحدث إصدار منشور، ويخبرك بوجود ترقية من عدمه، من دون تنفيذها. إن omni وomnigent اسمان للبرنامج نفسه.

وجّهه إلى مزوّد نماذج

omni setup

يبحث المعالج عن بيانات الاعتماد الموجودة مسبقاً في بيئتك، ويطلب منك إدخال البيانات الناقصة. وهو يتعامل مع مفاتيح API، واشتراكات المورّدين، والبوابات مثل OpenRouter أو Ollama، ومساحات عمل Databricks. إذا كنت تشغّل خادم نماذج محلياً باستخدام Ollama على الجهاز نفسه، فوجّه إحدى البوابات إليه، ولن تغادر حركة الشبكة الجهاز.

تشغيل مبسّط متعدد الوكلاء

توجد الوكلاء المثالّية في المستودع، لذلك استنسخ الوسم نفسه الذي ثبّتَّه بدلاً من 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 فحصاً تمهيدياً للتحقق من وجود واجهات CLI للوكلاء الفرعيين فعلياً على الجهاز. إذا كانت واجهة CLI لمورّد واحد فقط مثبّتة، فلن يتوفر مراجع يمكنه تسليمه diff، لذلك ثبّت واجهتي CLI لمورّدين مختلفين على الأقل قبل تقييم الناتج. أما Debby، المثال الآخر المرفق، فهو وكيل مناظرة برأسين: أحدهما Claude والآخر GPT:

omni debby

هذه طريقة مختصرة للتأكد من إعداد مورّدين، لأنها تحتاج إلى كليهما حتى تنتج أي مخرجات.

تُعرَّف الوكلاء الفرعيون كأدوات

ملف الوكيل بصيغة YAML. يحدّد executor بيئة التشغيل والنموذج وبيانات المصادقة. ويحتوي tools على خوادم MCP (بروتوكول سياق النموذج)، ودوال Python، والوكلاء الفرعيين. والوكيل الفرعي أداة لها type: agent ومنفّذ خاص بها، وهذه هي الآلية التي تقف وراء كل ما سبق.

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 على جهازك. تتضمن قيم بيئة التشغيل الأخرى في المواصفة antigravity وcopilot وkimi وqwen وacp:<slug> لأي مكوّن يستخدم البروتوكول العام. وتدعم المواصفة أيضاً pass_history: true على الوكيل الفرعي، ما يمرّر إليه المحادثة الأصلية. يستهلك ذلك رموزاً في كل عملية تفويض، لذا اتركه معطلاً للوكلاء الفرعيين الذين يحتاجون فقط إلى المهمة الحالية.

لماذا يُناسب تشغيل عمليات التنسيق الطويلة خادماً افتراضياً خاصاً

لا تُعدّ عملية التشغيل متعددة الوكلاء أمراً يستغرق دقيقتين. فهي تتضمن التخطيط، والتفويض، وانتظار عمليات git المتوازية في worktrees، والمراجعة، والتنقيح. يؤدي إغلاق غطاء الحاسوب المحمول إلى إنهاء العملية بالكامل. يظل الخادم الافتراضي الخاص (VPS) قيد التشغيل ويحافظ على اتصاله بالشبكة، لذلك تستمر الجلسة أثناء عدم مراقبتك لها.

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 الأسرار داخل .env، ثم يشغّل docker compose up -d كلاً من Omnigent وPostgres على المنفذ 6767. يختار DATABASE_URL بين Postgres وSQLite. ويكون OMNIGENT_AUTH_ENABLED مضبوطاً افتراضياً على 1 داخل الحاويات، وهو الإعداد الصحيح لأي خدمة يمكن الوصول إليها من خارج الخادم.

من ناحية تحديد الموارد، تذكر ملاحظات النشر أن مجموعة العمل على الخادم تحتاج تقريباً إلى 512 MB إلى 1 GB، ويحدد إعداد Fly.io الذاكرة عند 1 GB. هذا الرقم خاص بالمشرف وحده. كل وكيل فرعي عملية مستقلة تحتفظ بنسخة checkout خاصة بها وبعميل النموذج الخاص بها، لذلك حدّد حجم الخادم وفقاً لعدد الوكلاء. بعد تشغيل الخادم، يسجّل omnigent login https://your-host ثم omnigent host https://your-host جهازك المحمول لدى الخادم، ويستأنف omnigent attach <session_id> جلسة قيد التشغيل من جهاز آخر.

ضع كل وكيل فرعي داخل Sandbox قبل إنهاء العمل

يصدر Omnigent بيئة Sandbox على مستوى نظام التشغيل باسم Omnibox. في Linux، تستخدم هذه البيئة مساحات أسماء bubblewrap مع seccomp، لذلك تفرض النواة الحدود بدلاً من الاعتماد على prompt الوكيل. لا يستطيع وكيل حُقنت في prompt تعليمات ضارة التحايل على قاعدة تفرضها النواة. ثبّت التبعية أولاً:

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، لذلك لا يستطيع الوكيل الذي يتصرف على نحو خاطئ الكتابة خارج مساحة العمل. وتبقى ملفات dotfiles مخفية ما لم تسمِّها في cwd_allow_hidden، ما يعني أن منح صلاحية قراءة واسعة لا يكشف بصمت .ssh أو .aws. اضبط egress_rules، وسيمر كل traffic الخاص بـHTTP وHTTPS عبر proxy بمنع افتراضي، مع كتابة كل قاعدة على الصورة "METHODS host/path-glob". ويذهب credential_proxy خطوة أبعد: لا يحتفظ الوكيل إلا بقيمة بديلة، ويستبدل الـproxy بها السر الحقيقي عند خروج الطلب، لذلك لا يكشف transcript مسرّب أي قيمة صالحة للاستخدام. في إعداد يضم عدة أطر تشغيل، يحتوي كل وكيل فرعي على كتلة Sandbox خاصة به في ملف الإعداد الخاص به ضمن agents/، لذلك يمكن منع المراجع من الوصول إلى الشبكة، مع إبقاء الوصول متاحاً للمنفّذ.

يذكر التوثيق هذا القيد، وهو مهم. تنطبق بيئة Sandbox الخاصة بنظام التشغيل على استدعاءات الأدوات sys_os_* وعلى terminal. لكنها لا تشمل خوادم MCP، ولا تشمل عملية المشرف الخاصة بـOmnigent نفسها. يعمل خادم MCP الذي شغّلته خارج البيئة وبصلاحياتك. ولهذا السبب يظل النمط الأقوى هو تخصيص جهاز مؤقت واحد لكل وكيل، وهو موضوع تشغيل وكلاء البرمجة في VM مؤقت. والجزء الآخر من المهمة هو بيانات الاعتماد، كما أن إبعاد الأسرار عن متناول الوكيل يصبح أصعب، لا أسهل، عندما يشترك ستة وكلاء فرعيين في خادم واحد.

حدود الإنفاق هي سياسات تُعرَّف في الملف نفسه:

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، وهما يطلبان الموافقة قبل عمليات الملفات وshell. تنطبق ملاحظاتنا حول التحكم في تكاليف وكلاء الذكاء الاصطناعي على 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
  }
]

هذه هي تواريخ الإصدارات المنشورة في صفحة إصدارات المشروع نفسه، وقد جرى الاطلاع عليها في 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 تسمية الإضافة omnigent[memory] إلى omnigent[hindsight]، لذلك يفشل سطر التثبيت المنسوخ من مقال نُشر في June عند استخدامه مع إصدار مبني في July. لهذا السبب يجب تضمين --version في أمر التثبيت، وتثبيت علامة في git clone، وليس لأن ذلك مجرد تفضيل أسلوبي.

ما الذي لن أثق به فيه بعد

اعتباراً من August 2026، يضم المستودع نحو 8.1k نجمة و1.2k تفرعاً ونحو 350 issue مفتوحة، بينما لا يتجاوز عمر أول إصدار عام له سبعة أسابيع. تقيس النجوم مستوى الاهتمام، والاهتمام لا يعني النضج. يصف المشروع نفسه بأنه alpha، ويبيّن سجل الإصدارات أعلاه أن المقصود هو alpha فعلاً.

• لن أشغّله على مضيف يحتوي على بيانات اعتماد الإنتاج، لأن sandbox لا يغطي خوادم MCP أو supervisor.
• لن أترك عملية قيد التشغيل دون مراقبة من دون سياسة cost_budget، لأن ثلاثة مورّدين قد يفرضون رسوماً بالتوازي ولا يوقفهم شيء آخر.
• لن أعرّض الخادم على عنوان IP عام من دون ضبط OMNIGENT_AUTH_ENABLED ووضع TLS أمامه.
• لن أتعامل مع agent YAML على أنه مستقر بين الإصدارات الفرعية بعد، لذلك ثبّت الإصدار واقرأ ملاحظات الإصدار قبل الترقية.

هناك أمر آخر يجب معرفته قبل أن يفاجئك: أضاف v0.6.0 قياساً مجهول الهوية للاستخدام، ويوثّق المشروع ذلك في صفحة مخصصة للقياس عن بُعد. اقرأ تلك الصفحة واتخذ قرارك عن قصد إذا كان الجهاز يتعامل مع أعمال العملاء.

ما يتقنه Omnigent فعلاً اليوم هو الغرض الذي بُني من أجله. لديك 3 أو 4 من واجهات agent CLI، وتدفع مقابلها بالفعل، وتريد أن يكتب أحدها بينما يراجع آخر. هذا يعمل الآن، على جهاز واحد، مع sandbox حقيقي على Linux. تعامل مع كل ما يتجاوز ذلك على أنه واعد وغير مكتمل.

FAQ

هل Omnigent وكيل، أم برنامج يشغّل الوكلاء؟

يشغّل الوكلاء. Omnigent هو meta-harness؛ إذ يبدأ أدوات CLI الخاصة بالمورّدين التي ثبّتها مسبقاً، مثل Claude Code وCodex أو OpenCode، ويمنح كل أداة مهمة، ثم يشرف على النتائج ضمن جلسة واحدة. لا يتضمن أي نموذج خاص به. لذلك يختلف عن framework تكتب فيه Python باستخدام مكتبة، ويصبح برنامجك الخاص هو الوكيل.

هل أحتاج إلى تثبيت Claude Code وCodex قبل أن يصبح Omnigent مفيداً؟

تحتاج إلى تثبيت أداة CLI واحدة على الأقل من أحد المورّدين وتسجيل الدخول إليها، لأن Omnigent يشغّل هذه البرامج ولا يستبدلها. بالنسبة إلى مثال Polly المضمّن، تحتاج إلى أداتين أو أكثر من مورّدين مختلفين. تفرض قاعدة Polly أن ينفّذ مورّد مختلف عن مورّد التنفيذ عملية المراجعة دائماً. لذلك، عند توفر أداة CLI واحدة فقط، لا يوجد مورّد ثانٍ لإرسال diff إليه.

كيف أثبّت إصداراً محدداً من Omnigent بدلاً من أحدث إصدار؟

مرّر --version إلى install script باستخدام sh -s --، كما في sh -s -- --version 0.7.0. من دون -s --، تستهلك sh نفسها هذا الخيار، ويثبّت script أحدث release. إذا كان uv مثبتاً مسبقاً، ينفّذ uv tool install --force --python 3.12 "omnigent==0.7.0" المهمة نفسها. يكون git tag هو v0.7.0، بينما تكون قيمة الإصدار في PyPI هي 0.7.0.

هل تكفي Omnibox sandbox لتشغيل الوكلاء دون مراقبة؟

توفر عزلاً قوياً ضمن نطاقها، وتوضح ما لا تغطيه. في Linux، تستخدم bubblewrap مع seccomp، لذلك تفرض kernel حدود الملفات والشبكة، ولا يستطيع الوكيل تجاوزها. توضح الوثائق أنها تنطبق على استدعاءات الأدوات والطرفيات sys_os_*، ولا تشمل MCP servers أو عملية Omnigent supervisor. لذلك يعمل MCP server باستخدام صلاحياتك العادية، ولهذا تظل الآلة الافتراضية المؤقتة لكل وكيل الخيار الأقوى للعزل عند التشغيل دون مراقبة.

ما مقدار الذاكرة التي يحتاج إليها Omnigent server على VPS؟

تحدد ملاحظات النشر الخاصة بالمشروع working set للخادم بنحو 512 MB إلى 1 GB، ويحدد إعداد Fly.io مقدار 1 GB. يغطي ذلك supervisor وواجهة الويب على المنفذ 6767 فقط. يعمل كل sub-agent كعملية منفصلة لها working copy وmodel client خاصان بها. كما تستخدم عمليات Polly المشابهة git worktrees متوازية. لذلك، حدّد مقدار RAM ومساحة القرص وفق عدد الوكلاء الذين تخطط لتشغيلهم في الوقت نفسه، وليس وفق احتياجات الخادم وحده.