Skip to main content
شغّل عدة وكلاء معزولين في عملية Gateway واحدة، لكل منهم مساحة عمل خاصة به، ودليل حالة (agentDir)، وسجل جلسات مدعوم بـ SQLite، بالإضافة إلى عدة حسابات قنوات (مثل رقمي WhatsApp). تُوجَّه الرسائل الواردة إلى الوكيل الصحيح عبر الارتباطات. الوكيل هو النطاق الكامل لكل شخصية: ملفات مساحة العمل، وملفات تعريف المصادقة، وسجل النماذج، ومخزن الجلسات. يربط الارتباط حساب قناة (مساحة عمل Slack أو رقم WhatsApp، وما إلى ذلك) بأحد هؤلاء الوكلاء.

ما الوكيل الواحد

لكل وكيل ما يلي:
  • مساحة العمل: الملفات، وAGENTS.md/SOUL.md/USER.md، والملاحظات المحلية، وقواعد الشخصية.
  • دليل الحالة (agentDir): ملفات تعريف المصادقة، وسجل النماذج، وإعدادات كل وكيل.
  • مخزن الجلسات: سجل المحادثات وحالة التوجيه في ~/.openclaw/agents/<agentId>/agent/openclaw-agent.sqlite.
تكون ملفات تعريف المصادقة خاصة بكل وكيل، وتُقرأ من:
يُعد sessions_history المسار الأكثر أمانًا للاسترجاع عبر الجلسات: فهو يعيد عرضًا محدودًا ومنقحًا، لا تفريغًا خامًا للنص المنسوخ. ويزيل تواقيع كتل التفكير، وتفاصيل حمولات نتائج الأدوات، وبنية <relevant-memories>، ووسوم XML لاستدعاءات الأدوات (<tool_call> و<function_call> وصيغهما الجمعية/المخفّضة)، وXML لاستدعاءات أدوات MiniMax، ثم يقتطع المخرجات ويحدّها حسب حجم البايتات.
لا تُعِد استخدام agentDir مطلقًا عبر الوكلاء — إذ يسبب ذلك تعارضات في حالة المصادقة/الجلسات. عندما تنتهي صلاحية بيانات اعتماد OAuth المحلية لوكيل ثانوي أو يفشل تحديثها، يقرأ OpenClaw بيانات اعتماد الوكيل الافتراضي/الرئيسي لمعرّف ملف التعريف نفسه ويعتمد الرمز الأحدث، من دون نسخ رمز التحديث إلى مخزن الوكيل الثانوي. إذا أردت حساب OAuth مستقلاً بالكامل، فسجّل الدخول من ذلك الوكيل. وإذا نسخت بيانات الاعتماد يدويًا، فلا تنسخ إلا ملفات تعريف api_key أو token الثابتة والقابلة للنقل — فبيانات تحديث OAuth غير قابلة للنقل افتراضيًا (يمكن لـ copyToAgents تمكين ذلك صراحةً لملف تعريف).
تُحمَّل Skills من مساحة عمل كل وكيل بالإضافة إلى الجذور المشتركة مثل ~/.openclaw/skills، ثم تُرشَّح وفق قائمة Skills المسموح بها فعليًا للوكيل. استخدم agents.defaults.skills لخط أساس مشترك وagents.list[].skills لاستبدال خاص بكل وكيل (تحل الإدخالات الصريحة محل الإعداد الافتراضي ولا تُدمج معه). راجع Skills: الخاصة بكل وكيل مقابل المشتركة وSkills: قوائم السماح للوكلاء. يتبع التخزين المملوك لـ Plugin إعدادات ذلك الـ Plugin؛ وإضافة وكيل ثانٍ لا تقسّم تلقائيًا كل مخزن عام للـ Plugin. على سبيل المثال، اضبط خزائن Memory Wiki الخاصة بكل وكيل عندما يجب ألا تشارك الشخصيات معرفة الويكي المجمّعة.
ملاحظة حول مساحة العمل: مساحة عمل كل وكيل هي دليل العمل الحالي الافتراضي، وليست بيئة معزولة صارمة. تُحل المسارات النسبية داخل مساحة العمل، لكن يمكن للمسارات المطلقة الوصول إلى مواقع أخرى على المضيف ما لم يكن العزل مفعّلًا. راجع العزل.

المسارات

وضع الوكيل الواحد (الافتراضي)

إذا لم تضبط شيئًا، يشغّل OpenClaw وكيلاً واحدًا:
  • تكون القيمة الافتراضية لـ agentId هي main.
  • تستخدم الجلسات المفتاح agent:main:<mainKey> (القيمة الافتراضية لـ mainKey هي main).
  • تكون مساحة العمل افتراضيًا ~/.openclaw/workspace (أو workspace-<profile> عندما تُضبط OPENCLAW_PROFILE على قيمة غير default).
  • تكون الحالة افتراضيًا ~/.openclaw/agents/main/agent.

أداة الوكيل المساعدة

أضف وكيلاً معزولاً جديدًا:
العلامات: --workspace <dir>، و--model <id>، و--agent-dir <dir>، و--bind <channel[:accountId]> (قابلة للتكرار)، و--non-interactive (تتطلب --workspace). أضف bindings لتوجيه الرسائل الواردة (يعرض المعالج تنفيذ ذلك نيابةً عنك)، ثم تحقّق:

بدء سريع

1

إنشاء مساحة عمل لكل وكيل

يحصل كل وكيل على مساحة عمل خاصة به تحتوي على SOUL.md وAGENTS.md وUSER.md اختياري، بالإضافة إلى agentDir مخصص ومخزن جلسات ضمن ~/.openclaw/agents/<agentId>.
2

إنشاء حسابات القنوات

أنشئ حسابًا واحدًا لكل وكيل على القنوات التي تفضّلها:
  • Discord: روبوت واحد لكل وكيل، فعّل Message Content Intent، وانسخ كل رمز.
  • Telegram: روبوت واحد لكل وكيل عبر BotFather، وانسخ كل رمز.
  • WhatsApp: اربط كل رقم هاتف بحساب.
راجع أدلة القنوات: Discord، وTelegram، وWhatsApp.
3

إضافة الوكلاء والحسابات والارتباطات

أضف الوكلاء ضمن agents.list، وحسابات القنوات ضمن channels.<channel>.accounts، واربط بينها باستخدام bindings (الأمثلة أدناه).
4

إعادة التشغيل والتحقق

عدة وكلاء، وعدة شخصيات

يمثل كل agentId مضبوط حدًا مستقلاً للشخصية بالنسبة إلى حالة الوكيل الأساسية:
  • حسابات مختلفة لكل قناة (لكل accountId).
  • شخصيات مختلفة (AGENTS.md/SOUL.md لكل وكيل).
  • مصادقة وجلسات منفصلة، مع تمكين الوصول عبر الوكلاء فقط من خلال ميزات صريحة أو إعدادات Plugin.
يتيح ذلك لعدة أشخاص مشاركة Gateway واحد مع إبقاء حالة كل وكيل الأساسية منفصلة.

خزائن Memory Wiki الخاصة بكل وكيل

يستخدم Memory Wiki خزينة عامة واحدة افتراضيًا. لإبقاء المعرفة المجمّعة لوكيل الدعم منفصلة عن معرفة وكيل التسويق، اضبط plugins.entries.memory-wiki.config.vault.scope على agent:
المسار المضبوط هو الدليل الأب. يضيف OpenClaw معرّف الوكيل بعد تطبيعه، منتجًا مسارات مثل ~/.openclaw/wiki/support و ~/.openclaw/wiki/marketing. تتطلب عمليات CLI وGateway ضمن نطاق الوكيل تحديد وكيل صراحةً عند ضبط عدة وكلاء. راجع خزائن Memory Wiki الخاصة بكل وكيل للحصول على تفاصيل تصفية الجسر والترحيل وحدود الثقة.

البحث في ذاكرة QMD عبر الوكلاء

للسماح لوكيل بالبحث في نصوص جلسات QMD الخاصة بوكيل آخر، أضف مجموعات إضافية ضمن agents.list[].memorySearch.qmd.extraCollections. استخدم agents.defaults.memorySearch.qmd.extraCollections عندما ينبغي لجميع الوكلاء مشاركة المجموعات نفسها.
يمكن مشاركة مسار مجموعة إضافية بين الوكلاء، لكن تبقى قيمة name الخاصة به صريحة عندما يكون المسار خارج مساحة عمل الوكيل. وتبقى المسارات داخل مساحة العمل ضمن نطاق الوكيل، بحيث يحتفظ كل وكيل بمجموعة البحث الخاصة به في النصوص المنسوخة.

رقم WhatsApp واحد، وعدة أشخاص (تقسيم الرسائل المباشرة)

وجّه رسائل WhatsApp المباشرة المختلفة إلى وكلاء مختلفين على حساب WhatsApp واحد عبر مطابقة المُرسِل بصيغة E.164 (+15551234567) باستخدام peer.kind: "direct". تظل الردود صادرة من رقم WhatsApp نفسه — فلا توجد هوية مُرسِل خاصة بكل وكيل.
تُدمج المحادثات المباشرة افتراضيًا في مفتاح الجلسة الرئيسية للوكيل، لذا يتطلب العزل الحقيقي وكيلاً واحدًا لكل شخص.
يكون التحكم في الوصول إلى الرسائل المباشرة (الاقتران/قائمة السماح) عامًا لكل حساب WhatsApp، وليس لكل وكيل. بالنسبة إلى المجموعات المشتركة، اربط المجموعة بوكيل واحد أو استخدم مجموعات البث.

قواعد التوجيه

الارتباطات حتمية، وتفوز المطابقة الأكثر تحديدًا. راجع توجيه القنوات لمعرفة ترتيب الطبقات الكامل (نظير مطابق تمامًا، ونظير أب، ونظير بدل، وخادم+أدوار، وخادم، وفريق، وحساب، وقناة، ووكيل افتراضي). وفيما يلي بعض القواعد الجديرة بالتنبيه:
  • إذا طابقت عدة ارتباطات ضمن الطبقة نفسها، يفوز أولها حسب ترتيب الإعدادات.
  • إذا حدّد ارتباط عدة حقول مطابقة (مثل peer + guildId)، فيجب أن تتطابق جميع الحقول المحددة (دلالات AND).
  • الارتباط الذي يحذف accountId يطابق الحساب الافتراضي فقط، وليس كل الحسابات. استخدم accountId: "*" كخيار احتياطي على مستوى القناة، أو accountId: "<name>" لحساب واحد. تؤدي إضافة الارتباط نفسه مرة أخرى مع معرّف حساب صريح إلى ترقية الارتباط الحالي الخاص بالقناة فقط بدلاً من تكراره.

حسابات / أرقام هواتف متعددة

تستخدم القنوات التي تدعم حسابات متعددة (مثل WhatsApp) accountId لتعريف كل تسجيل دخول. يوجّه كل accountId إلى وكيله الخاص، لذا يمكن لخادم واحد استضافة عدة أرقام هواتف من دون خلط الجلسات. عيّن channels.<channel>.defaultAccount لاختيار الحساب المستخدم عند حذف accountId. عند عدم تعيينه، يعود OpenClaw إلى default إذا كان موجودًا، وإلا فيستخدم معرّف أول حساب مُعدّ (بعد الفرز). القنوات التي تدعم حسابات متعددة: discord، feishu، googlechat، imessage، irc، line، mattermost، matrix، nextcloud-talk، nostr، signal، slack، telegram، whatsapp، zalo، zalouser.

المفاهيم

  • agentId: «عقل» واحد (مساحة عمل، ومصادقة لكل وكيل، ومخزن جلسات لكل وكيل).
  • accountId: مثيل واحد لحساب قناة (مثل حساب WhatsApp ‏personal مقارنةً بـ biz).
  • binding: يوجّه الرسائل الواردة إلى agentId حسب (channel, accountId, peer)، واختياريًا حسب معرّفات النقابة/الفريق.
  • تُدمج المحادثات المباشرة في agent:<agentId>:<mainKey> (الحساب «الرئيسي» لكل وكيل؛ راجع session.mainKey).

أمثلة المنصات

يُربط كل حساب روبوت Discord بقيمة accountId فريدة. اربط كل حساب بوكيل واحتفظ بقوائم السماح منفصلة لكل روبوت.
  • ادعُ كل روبوت إلى النقابة وفعّل Message Content Intent.
  • توجد الرموز المميزة في channels.discord.accounts.<id>.token (يمكن للحساب الافتراضي استخدام DISCORD_BOT_TOKEN).
  • أنشئ روبوتًا واحدًا لكل وكيل باستخدام BotFather وانسخ كل رمز مميز.
  • توجد الرموز المميزة في channels.telegram.accounts.<id>.botToken (يمكن للحساب الافتراضي استخدام TELEGRAM_BOT_TOKEN).
  • عند استخدام عدة روبوتات في مجموعة Telegram نفسها، ادعُ كل روبوت واذكر الروبوت الذي ينبغي أن يجيب.
  • عطّل BotFather Privacy Mode لكل روبوت مجموعة (/setprivacy -> Disable)، ثم أزل الروبوت وأعد إضافته لكي يطبّق Telegram الإعداد.
  • اسمح بالمجموعات باستخدام channels.telegram.groups، أو استخدم groupPolicy: "open" فقط لعمليات نشر المجموعات الموثوقة.
  • ضع معرّفات المستخدمين المرسلين في groupAllowFrom. تنتمي معرّفات المجموعات والمجموعات الفائقة إلى channels.telegram.groups، وليس إلى groupAllowFrom.
  • اربط حسب accountId لكي يوجّه كل روبوت الرسائل إلى وكيله الخاص.
اربط كل حساب قبل بدء Gateway:
~/.openclaw/openclaw.json ‏(JSON5):

الأنماط الشائعة

قسّم حسب القناة: وجّه WhatsApp إلى وكيل يومي سريع وTelegram إلى وكيل Opus.
تستخدم هذه الأمثلة accountId: "*" لكي تستمر الروابط في العمل إذا أضفت حسابات لاحقًا. لتوجيه محادثة مباشرة/مجموعة واحدة إلى Opus مع إبقاء البقية على وكيل المحادثة، أضف رابط match.peer لذلك النظير — تتغلب مطابقات النظير دائمًا على القواعد الشاملة للقناة.

إعداد صندوق الحماية والأدوات لكل وكيل

يمكن أن يكون لكل وكيل قيود صندوق حماية وأدوات خاصة به:
يوجد setupCommand ضمن sandbox.docker ويُشغّل مرة واحدة عند إنشاء الحاوية. تُتجاهل تجاوزات sandbox.docker.* الخاصة بكل وكيل عندما يكون النطاق المحسوم هو "shared".
يوفّر ذلك:
  • العزل الأمني: تقييد الأدوات للوكلاء غير الموثوقين.
  • التحكم في الموارد: تشغيل وكلاء محددين داخل صندوق حماية مع إبقاء الآخرين على المضيف.
  • سياسات مرنة: أذونات مختلفة لكل وكيل.
لدى tools.elevated بوابة عامة (tools.elevated.enabled/allowFrom) وبوابة لكل وكيل (agents.list[].tools.elevated.enabled/allowFrom). لا يمكن لبوابة كل وكيل إلا زيادة تقييد البوابة العامة — يجب أن تسمح كلتاهما للمرسل لكي تعمل الأوامر ذات الامتيازات المرتفعة. لاستهداف المجموعات، استخدم agents.list[].groupChat.mentionPatterns لكي تُربط إشارات @ بالوكيل المقصود بوضوح.
راجع صندوق الحماية والأدوات متعددة الوكلاء للاطلاع على أمثلة تفصيلية.

ذو صلة