Omnigent: تشغيل عدة وكلاء CLI في بيئة واحدة

ما هو Omnigent

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

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

ما هو meta-harness، وما الفرق بينه وبين framework؟

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

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

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

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

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

التكلفة هي الطبقة نفسها. كل خطأ في 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

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

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

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

لماذا يجب تشغيل مهام orchestration الطويلة على VPS

لا تُنفَّذ مهمة متعددة الوكلاء خلال دقيقتين. فهي تتطلب التخطيط والتفويض والانتظار حتى تنتهي عمليات git worktree المتوازية، ثم المراجعة والتنقيح. يؤدي إغلاق غطاء الحاسوب المحمول إلى إيقاف كل ذلك. يبقى 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. هذا الرقم يخص supervisor وحده. كل وكيل فرعي عملية مستقلة تحتفظ بنسخة checkout خاصة بها وعميل model خاص بها، لذلك حدّد حجم الخادم وفقاً لعدد الوكلاء. بعد تشغيل الخادم، يسجّل omnigent login https://your-host ثم omnigent host https://your-host حاسوبك المحمول لدى الخادم، ويتيح omnigent attach <session_id> استئناف جلسة قيد التشغيل من جهاز آخر.

عزّل كل وكيل فرعي قبل أن تتركه

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

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

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

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

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 fork وحوالي 350 issue مفتوحة، بينما مضى على أول إصدار عام سبعة أسابيع. تقيس النجوم مستوى الاهتمام، والاهتمام لا يعني النضج. يصف المشروع نفسه بأنه alpha، ويُظهر سجل الإصدارات أعلاه أن المقصود هو alpha فعلاً.

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

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

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

FAQ

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

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

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

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

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

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

هل تكفي بيئة Omnibox المعزولة لتشغيل الوكلاء دون إشراف؟

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

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

تذكر ملاحظات نشر المشروع أن مجموعة العمل للخادم تبلغ تقريباً من 512 MB إلى 1 GB، ويحدد إعداد Fly.io مقدار 1 GB. يغطي ذلك العملية المشرفة وواجهة الويب على المنفذ 6767 فقط. كل وكيل فرعي هو عملية مستقلة لها نسخة عمل وعميل نموذج خاصان بها، وتستخدم عمليات التشغيل بأسلوب Polly أشجار git للعمل المتوازية، لذلك خصّص RAM ومساحة القرص وفق عدد الوكلاء الذين تخطط لتشغيلهم في الوقت نفسه، لا وفق احتياجات الخادم.