الوكلاء الفرعيون

الوكلاء الفرعيون هم عمليات تشغيل لوكلاء في الخلفية، تُنشأ من عملية تشغيل وكيل موجودة. يعمل كل واحد منهم في جلسته الخاصة (agent:<agentId>:subagent:<uuid>)، وعند انتهائه، يعلن نتيجته مرة أخرى في قناة دردشة مقدّم الطلب. يُتتبَّع كل تشغيل لوكيل فرعي بوصفه مهمة في الخلفية.

الأهداف:

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

أمر الشرطة المائلة

يفحص /subagents عمليات تشغيل الوكلاء الفرعيين في الجلسة الحالية:

/subagents list/subagents log <id|#> [limit] [tools]/subagents info <id|#>

يعرض /subagents info بيانات التشغيل الوصفية (الحالة، والطوابع الزمنية، ومعرّف الجلسة، ومسار نص المحادثة، والتنظيف). يطبع /subagents log أحدث أدوار الدردشة لعملية تشغيل؛ أضف الرمز tools لتضمين رسائل استدعاء الأدوات/نتائجها (تُحذف افتراضيًا). استخدم sessions_history لاسترجاع محدود وخاضع لتصفية السلامة من داخل دور الوكيل، أو افحص مسار نص المحادثة على القرص للاطلاع على النص الكامل الخام.

عناصر التحكم في ربط السلاسل

تعمل هذه الأوامر على القنوات ذات روابط السلاسل الدائمة. راجع القنوات الداعمة للسلاسل أدناه.

/focus <subagent-label|session-key|session-id|session-label>/unfocus/agents/session idle <duration|off>/session max-age <duration|off>

سلوك الإنشاء

يبدأ الوكلاء وكلاء فرعيين في الخلفية باستخدام أداة sessions_spawn. تعود حالات الاكتمال بوصفها أحداثًا داخلية في جلسة الوكيل الأب؛ ويقرر الوكيل الأب/وكيل مقدّم الطلب ما إذا كان يلزم إرسال تحديث مرئي للمستخدم.

أوضاع السياق

يبدأ الوكلاء الفرعيون الأصليون معزولين ما لم يطلب المستدعي صراحةً تفرّع النص الحالي للمحادثة.

استخدم fork باعتدال. فهو مخصص للتفويض الحساس للسياق، وليس بديلًا عن كتابة مطالبة مهمة واضحة.

الأداة: sessions_spawn

تبدأ تشغيل وكيل فرعي باستخدام deliver: false على مسار subagent العام، ثم تنفّذ خطوة إعلان وتنشر رد الإعلان في قناة دردشة مقدّم الطلب.

يعتمد التوفر على سياسة الأدوات الفعلية للمستدعي. يتضمن ملف التعريف المضمّن coding الأداة sessions_spawn؛ بينما لا يتضمنها messaging ولا minimal. يسمح full بكل الأدوات. أضف tools.alsoAllow: ["sessions_spawn", "sessions_yield", "subagents"]، أو استخدم tools.profile: "coding"، للوكلاء ذوي ملف تعريف أضيق والذين ينبغي أن يتمكنوا مع ذلك من تفويض العمل. يمكن لسياسات السماح/المنع الخاصة بالقناة/المجموعة، والموفّر، والعزل، وكل وكيل أن تزيل الأداة بعد مرحلة ملف التعريف. استخدم /tools من الجلسة نفسها لتأكيد قائمة الأدوات الفعلية.

القيم الافتراضية:

• النموذج: يرث الوكلاء الفرعيون الأصليون نموذج المستدعي ما لم تضبط agents.defaults.subagents.model (أو agents.list[].subagents.model لكل وكيل). تستخدم عمليات إنشاء بيئة تشغيل ACP نموذج الوكيل الفرعي المضبوط نفسه عند وجوده؛ وإلا تحتفظ حاضنة ACP بقيمتها الافتراضية الخاصة. يظل sessions_spawn.model الصريح صاحب الأولوية.
• التفكير: يرث الوكلاء الفرعيون الأصليون إعداد التفكير من المستدعي ما لم تضبط agents.defaults.subagents.thinking (أو agents.list[].subagents.thinking لكل وكيل). تطبّق عمليات إنشاء بيئة تشغيل ACP أيضًا agents.defaults.models["provider/model"].params.thinking للنموذج المحدد. يظل sessions_spawn.thinking الصريح صاحب الأولوية.
• مهلة التشغيل: يستخدم OpenClaw ‏agents.defaults.subagents.runTimeoutSeconds عند ضبطه؛ وإلا يعود إلى 0 (من دون مهلة). لا تقبل sessions_spawn تجاوزات للمهلة لكل استدعاء.
• تسليم المهمة: يتلقى الوكلاء الفرعيون الأصليون المهمة المفوّضة في أول رسالة [Subagent Task] مرئية لهم. تحمل مطالبة نظام الوكيل الفرعي قواعد وقت التشغيل وسياق التوجيه، لا نسخة مكررة مخفية من المهمة.

تتضمن عمليات إنشاء الوكلاء الفرعيين الأصليين المقبولة البيانات الوصفية لنموذج الوكيل الفرعي المحسوم في نتيجة الأداة: يحتوي resolvedModel على مرجع النموذج المطبق، ويحتوي resolvedProvider على بادئة الموفّر عندما يتضمن المرجع واحدة.

وضع مطالبة التفويض

يتحكم agents.defaults.subagents.delegationMode في إرشادات المطالبة فقط؛ ولا يغيّر سياسة الأدوات ولا يفرض التفويض.

• suggest (الافتراضي): يحتفظ بالتلميح القياسي في المطالبة لاستخدام الوكلاء الفرعيين للأعمال الأكبر أو الأبطأ.
• prefer: يطلب من الوكيل الرئيسي الحفاظ على سرعة الاستجابة وتفويض أي عمل أكثر تعقيدًا من رد مباشر عبر sessions_spawn.

التجاوز لكل وكيل: agents.list[].subagents.delegationMode.

{  agents: {    defaults: {      subagents: {        delegationMode: "prefer",        maxConcurrent: 4,      },    },    list: [      {        id: "coordinator",        subagents: { delegationMode: "prefer" },      },    ],  },}

معلمات الأداة

أسماء المهام والاستهداف

taskName معرّف موجّه للنموذج لأغراض التنسيق، وليس مفتاح جلسة. استخدمه لأسماء الوكلاء الفرعية الثابتة مثل review_subagents أو linux_validation أو docs_update عندما قد يحتاج المنسّق إلى فحص ذلك الوكيل الفرعي لاحقًا.

يقبل تحليل الهدف التطابقات التامة لـ taskName والبادئات غير الملتبسة. يقتصر التطابق على نافذة الأهداف النشطة/الحديثة نفسها المستخدمة مع أهداف /subagents المرقّمة، لذلك لا يجعل وكيل فرعي مكتمل قديم المعرّف المعاد استخدامه ملتبسًا. إذا اشترك وكيلان فرعيان نشطان أو حديثان في taskName نفسه، يكون الهدف ملتبسًا؛ استخدم بدلًا منه فهرس القائمة أو مفتاح الجلسة أو معرّف التشغيل.

لا تصلح الأهداف المحجوزة last وall كقيم لـ taskName لأن لها معاني تحكمية بالفعل.

الأداة: sessions_yield

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

sessions_yield هي آلية الانتظار الأساسية. لا تستبدلها بحلقات استقصاء عبر subagents أو sessions_list أو sessions_history أو أمر sleep في الصدفة أو استقصاء العمليات لمجرد اكتشاف اكتمال الوكيل الفرعي.

لا تستخدم sessions_yield إلا عندما تتضمنها قائمة الأدوات الفعلية للجلسة. قد تعرض بعض ملفات تعريف الأدوات الدنيا أو المخصصة sessions_spawn و subagents من دون عرض sessions_yield؛ وفي هذه الحالة، لا تنشئ حلقة استقصاء لمجرد انتظار الاكتمال.

عند وجود وكلاء فرعية نشطة، يحقن OpenClaw كتلة مطالبة مختصرة منشأة في وقت التشغيل باسم Active Subagents ضمن الأدوار العادية، كي يتمكن مقدّم الطلب من رؤية جلسات الوكلاء الفرعية الحالية ومعرّفات التشغيل والحالات والتسميات والمهام وأسماء taskName البديلة من دون استقصاء. تُقتبس حقول المهمة والتسمية في تلك الكتلة بوصفها بيانات لا تعليمات، لأنها قد تنشأ من وسائط إنشاء قدّمها المستخدم/النموذج.

الأداة: subagents

تسرد عمليات تشغيل الوكلاء الفرعية التي أنشأتها جلسة مقدّم الطلب. يقتصر نطاقها على مقدّم الطلب الحالي؛ ولا يمكن للوكيل الفرعي رؤية سوى الوكلاء الفرعية الخاضعة لسيطرته.

استخدم subagents للحصول على الحالة عند الطلب وتصحيح الأخطاء. استخدم sessions_yield لانتظار أحداث الاكتمال.

الجلسات المرتبطة بسلاسل المحادثات

عند تمكين روابط سلاسل المحادثات لقناة، يمكن أن يظل الوكيل الفرعي مرتبطًا بسلسلة محادثة، بحيث يستمر توجيه رسائل المستخدم اللاحقة في تلك السلسلة إلى جلسة الوكيل الفرعي نفسها.

القنوات الداعمة لسلاسل المحادثات

تدعم القناة جلسات الوكلاء الفرعية الدائمة المرتبطة بسلاسل المحادثات (sessions_spawn مع thread: true) عندما تسجّل مهايئًا لربط المحادثات. القنوات المضمّنة التي تدعم ذلك: Discord و iMessage وMatrix وTelegram. ينشئ Discord وMatrix سلسلة محادثة فرعية افتراضيًا؛ بينما يربط Telegram وiMessage المحادثة الحالية افتراضيًا. استخدم مفاتيح إعداد threadBindings الخاصة بكل قناة للتمكين والمهل وspawnSessions.

التدفق السريع

عناصر التحكم اليدوية

مفاتيح الإعداد

• الإعداد الافتراضي العام: session.threadBindings.enabled وsession.threadBindings.idleHours وsession.threadBindings.maxAgeHours.
• مفاتيح تجاوز القناة والربط التلقائي عند الإنشاء خاصة بكل مهايئ. راجع القنوات الداعمة لسلاسل المحادثات أعلاه.

راجع مرجع الإعداد و أوامر الشرطة المائلة للاطلاع على تفاصيل المهايئات الحالية.

قائمة السماح

إذا كانت جلسة مقدّم الطلب معزولة، ترفض sessions_spawn الأهداف التي ستعمل من دون عزل.

الاكتشاف

استخدم agents_list لمعرفة معرّفات الوكلاء المسموح بها حاليًا لـ sessions_spawn. تتضمن الاستجابة النموذج الفعلي لكل وكيل مدرج وبيانات وصفية مضمّنة لوقت التشغيل، كي يستطيع المستدعون التمييز بين OpenClaw وCodex app-server وأوقات التشغيل الأصلية المهيأة الأخرى.

يجب أن تشير إدخالات allowAgents إلى معرّفات وكلاء مهيئين في agents.list[]. تعني ["*"] أي وكيل مستهدف مهيأ بالإضافة إلى مقدّم الطلب. إذا حُذف إعداد وكيل لكن بقي معرّفه في allowAgents، فسترفض sessions_spawn ذلك المعرّف وتحذفه agents_list من النتائج. شغّل openclaw doctor --fix لتنظيف إدخالات قائمة السماح القديمة، أو أضف إدخالًا أدنى في agents.list[] عندما يجب أن يظل الهدف قابلًا للإنشاء مع وراثة الإعدادات الافتراضية.

الأرشفة التلقائية

• تُؤرشف جلسات الوكلاء الفرعية تلقائيًا بعد agents.defaults.subagents.archiveAfterMinutes (الافتراضي 60).
• تستخدم الأرشفة sessions.delete وتعيد تسمية النص المنسوخ إلى *.deleted.<timestamp> (في المجلد نفسه).
• تؤرشف cleanup: "delete" الجلسة فورًا بعد الإعلان (مع استمرار الاحتفاظ بالنص المنسوخ عبر إعادة التسمية).
• الأرشفة التلقائية بأفضل جهد؛ وتُفقد المؤقتات المعلّقة إذا أُعيد تشغيل Gateway.
• لا تؤدي مهل التشغيل المهيأة إلى الأرشفة التلقائية؛ فهي توقف التشغيل فقط. وتبقى الجلسة حتى الأرشفة التلقائية.
• تنطبق الأرشفة التلقائية بالتساوي على جلسات العمق 1 والعمق 2.
• تنظيف المتصفح منفصل عن تنظيف الأرشيف: تُغلق علامات تبويب/عمليات المتصفح المتتبعة بأفضل جهد عند انتهاء التشغيل، حتى عند الاحتفاظ بالنص المنسوخ/سجل الجلسة.

الوكلاء الفرعية المتداخلة

افتراضيًا، لا يمكن للوكلاء الفرعية إنشاء وكلاء فرعية خاصة بها (maxSpawnDepth: 1). عيّن maxSpawnDepth: 2 لتمكين مستوى واحد من التداخل — نمط المنسّق: الرئيسي ← الوكيل الفرعي المنسّق ← الوكلاء الفرعية العاملة.

{  agents: {    defaults: {      subagents: {        maxSpawnDepth: 2, // السماح للوكلاء الفرعية بإنشاء وكلاء فرعية (الافتراضي: 1، النطاق 1-5)        maxChildrenPerAgent: 5, // الحد الأقصى للوكلاء الفرعية النشطة لكل جلسة وكيل (الافتراضي: 5، النطاق 1-20)        maxConcurrent: 8, // الحد الأقصى لمسار التزامن العام (الافتراضي: 8)        runTimeoutSeconds: 900, // المهلة الافتراضية لـ sessions_spawn‏ (0 = بلا مهلة)        announceTimeoutMs: 120000, // مهلة إعلان Gateway لكل استدعاء      },    },  },}

مستويات العمق

سلسلة الإعلان

تتدفق النتائج صعودًا عبر السلسلة:

1. ينتهي العامل في العمق 2 ← يعلن لوالده (المنسّق في العمق 1).
2. يتلقى المنسّق في العمق 1 الإعلان، ويولّف النتائج، وينتهي ← يعلن للرئيسي.
3. يتلقى الوكيل الرئيسي الإعلان ويسلّمه إلى المستخدم.

لا يرى كل مستوى إلا الإعلانات الواردة من أبنائه المباشرين.

سياسة الأدوات حسب العمق

• يُكتبان الدور ونطاق التحكم في البيانات الوصفية للجلسة وقت الإنشاء. يمنع ذلك مفاتيح الجلسات المسطّحة أو المستعادة من استعادة امتيازات المنسّق عن طريق الخطأ.
• العمق 1 (منسّق، عندما يكون maxSpawnDepth >= 2): يحصل على sessions_spawn وsubagents وsessions_list وsessions_history ليتمكن من إنشاء الأبناء وفحص حالتهم. تظل أدوات الجلسة/النظام الأخرى محظورة.
• العمق 1 (طرفي، عندما يكون maxSpawnDepth == 1): لا توجد أدوات جلسة (السلوك الافتراضي الحالي).
• العمق 2 (عامل طرفي): لا توجد أدوات جلسة — تكون sessions_spawn محظورة دائمًا في العمق 2. لا يمكنه إنشاء أبناء إضافيين.

حد الإنشاء لكل وكيل

يمكن لكل جلسة وكيل (في أي عمق) أن تضم في الوقت نفسه ما لا يزيد على maxChildrenPerAgent من الأبناء النشطين (القيمة الافتراضية 5). يمنع هذا التفرع الجامح من منسّق واحد.

الإيقاف المتسلسل

يؤدي إيقاف منسّق في العمق 1 تلقائيًا إلى إيقاف جميع أبنائه في العمق 2:

• يؤدي /stop في المحادثة الرئيسية إلى إيقاف جميع وكلاء العمق 1، ويتسلسل الإيقاف إلى أبنائهم في العمق 2.

المصادقة

تُحل مصادقة الوكيل الفرعي حسب معرّف الوكيل، لا حسب نوع الجلسة:

• مفتاح جلسة الوكيل الفرعي هو agent:<agentId>:subagent:<uuid>.
• يُحمّل مخزن المصادقة من agentDir الخاص بذلك الوكيل.
• تُدمج ملفات تعريف مصادقة الوكيل الرئيسي بوصفها خيارًا احتياطيًا؛ وتتغلب ملفات تعريف الوكيل على ملفات تعريف الرئيسي عند التعارض.

الدمج إضافي، لذا تكون ملفات تعريف الرئيسي متاحة دائمًا بوصفها خيارات احتياطية. عزل المصادقة بالكامل لكل وكيل غير مدعوم حتى الآن.

الإعلان

ترفع الوكلاء الفرعية تقاريرها عبر خطوة إعلان:

• تعمل خطوة الإعلان داخل جلسة الوكيل الفرعي (وليس جلسة الطالب).
• إذا رد الوكيل الفرعي بـ ANNOUNCE_SKIP تمامًا، فلن يُنشر شيء.
• إذا كان أحدث نص للمساعد هو رمز الصمت المطابق تمامًا NO_REPLY / no_reply، فيُمنع إخراج الإعلان حتى لو وُجد تقدم مرئي سابق.

يعتمد التسليم على عمق الطالب:

• تستخدم جلسات الطالب في المستوى الأعلى استدعاء agent للمتابعة مع التسليم الخارجي (deliver=true).
• تتلقى جلسات الوكيل الفرعي الطالب المتداخلة حقن متابعة داخليًا (deliver=false) كي يتمكن المنسّق من توليف نتائج الأبناء داخل الجلسة.
• إذا اختفت جلسة وكيل فرعي طالب متداخلة، يعود OpenClaw إلى طالب تلك الجلسة عند توفره.

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

يقتصر تجميع اكتمالات الأبناء على تشغيل الطالب الحالي عند إنشاء نتائج الاكتمال المتداخلة، ما يمنع تسرب مخرجات الأبناء القديمة من تشغيل سابق إلى الإعلان الحالي. تحافظ ردود الإعلان على توجيه سلسلة الرسائل/الموضوع عند توفره في محولات القنوات.

سياق الإعلان

يُطبّع سياق الإعلان إلى كتلة أحداث داخلية مستقرة:

تُبلغ عمليات التشغيل الطرفية الفاشلة عن حالة الفشل دون إعادة تشغيل نص الرد الملتقط. لا يُرفع إخراج الأداة/toolResult إلى نص نتيجة الابن.

سطر الإحصاءات

تتضمن حمولات الإعلان سطر إحصاءات في النهاية (حتى عند التفافها):

• وقت التشغيل (مثل runtime 5m12s).
• استخدام الرموز (الإدخال/الإخراج/الإجمالي).
• التكلفة المقدّرة عند ضبط تسعير النموذج (models.providers.*.models[].cost).
• sessionKey وsessionId ومسار النص المنسوخ كي يتمكن الوكيل الرئيسي من جلب السجل عبر sessions_history أو فحص الملف على القرص.

البيانات الوصفية الداخلية مخصصة للتنسيق فقط؛ وينبغي إعادة صياغة الردود الموجهة للمستخدم بصوت مساعد طبيعي.

لماذا يُفضّل sessions_history

تُعد sessions_history مسار التنسيق الأكثر أمانًا لقراءة النص المنسوخ للابن من داخل دورة وكيل:

• تحجب النصوص المشابهة لبيانات الاعتماد/الرموز حتى عند تعطيل حجب السجلات العام.
• تقتطع كتل النص الطويلة (4000 محرف لكل كتلة)، وتحذف توقيعات التفكير وحمولات إعادة تشغيل الاستدلال وبيانات الصور المضمنة.
• تفرض حدًا أقصى للاستجابة قدره 80 كيلوبايت؛ وتُستبدل الصفوف المتضخمة بـ [sessions_history omitted: message too large].
• استخدم nextOffset عند وجوده للتنقل إلى الخلف عبر نوافذ النصوص المنسوخة الأقدم.
• لا تزيل sessions_history وسوم الاستدلال أو بنية <relevant-memories> أو XML الخاص باستدعاءات الأدوات من نص الرسالة — بل تعيد كتل محتوى منظّمة قريبة من بنية النص المنسوخ الخام، مع الحجب وتقييد الحجم فقط. يطبق /subagents log منقّي نثر أشد (يزيل وسوم الاستدلال وبنية الذاكرة وXML الخاص باستدعاءات الأدوات) لأنه يعرض أسطر محادثة عادية بدلًا من الكتل المنظّمة.
• يُعد فحص النص المنسوخ الخام على القرص الخيار الاحتياطي عندما تحتاج إلى النص الكامل المطابق بايتًا ببايت.

سياسة الأدوات

تستخدم الوكلاء الفرعية أولًا ملف التعريف ومسار سياسة الأدوات نفسيهما اللذين يستخدمهما الوكيل الأب أو المستهدف. بعد ذلك، يطبق OpenClaw طبقة قيود الوكيل الفرعي.

تفقد الوكلاء الفرعية دائمًا gateway وagents_list وsession_status وcron بغض النظر عن العمق أو الدور (وهي أدوات على مستوى النظام/تفاعلية، أو أدوات ينبغي أن ينسقها الوكيل الرئيسي). وتفقد الوكلاء الفرعية الطرفية (السلوك الافتراضي في العمق 1، ودائمًا في العمق 2) أيضًا subagents وsessions_list وsessions_history وsessions_spawn. لا تحصل الوكلاء الفرعية مطلقًا على أداة message — إذ تُعطّل وقت الإنشاء، ولا تُرشّح عبر قائمة الحظر هذه — وتظل sessions_send محظورة كي لا تتواصل الوكلاء الفرعية إلا عبر سلسلة الإعلان.

تظل sessions_history هنا أيضًا طريقة استرجاع محدودة ومنقّاة — وليست تفريغًا خامًا للنص المنسوخ.

عندما يكون maxSpawnDepth >= 2، تتلقى الوكلاء الفرعية المنسّقة في العمق 1 أيضًا sessions_spawn وsubagents وsessions_list وsessions_history كي تتمكن من إدارة أبنائها.

التجاوز عبر الإعداد

{  agents: {    defaults: {      subagents: {        maxConcurrent: 1,      },    },  },  tools: {    subagents: {      tools: {        // deny wins        deny: ["gateway", "cron"],        // if allow is set, it becomes allow-only (deny still wins)        // allow: ["read", "exec", "process"]      },    },  },}

تُعد tools.subagents.tools.allow مرشحًا نهائيًا للسماح فقط. يمكنها تضييق مجموعة الأدوات المحلولة بالفعل، لكنها لا تستطيع إعادة إضافة أداة أزالها tools.profile. على سبيل المثال، يتضمن tools.profile: "coding" الأداتين web_search/web_fetch ولكن ليس أداة browser. للسماح للوكلاء الفرعية ذات ملف تعريف البرمجة باستخدام أتمتة المتصفح، أضف المتصفح في مرحلة ملف التعريف:

{  tools: {    profile: "coding",    alsoAllow: ["browser"],  },}

استخدم agents.list[].tools.alsoAllow: ["browser"] الخاص بكل وكيل عندما ينبغي لوكيل واحد فقط الحصول على أتمتة المتصفح.

التزامن

تستخدم الوكلاء الفرعية مسار طابور مخصصًا داخل العملية:

• اسم المسار: subagent
• التزامن: agents.defaults.subagents.maxConcurrent (القيمة الافتراضية 8)

الحيوية والاسترداد

لا يعامل OpenClaw غياب endedAt على أنه دليل دائم على أن الوكيل الفرعي لا يزال نشطًا. تتوقف عمليات التشغيل غير المنتهية الأقدم من نافذة التشغيل القديمة (ساعتان، أو مهلة التشغيل المضبوطة مضافًا إليها فترة سماح قصيرة، أيهما أطول) عن الاحتساب كنشطة/معلّقة في /subagents list وملخصات الحالة وبوابات اكتمال التوابع وفحوص التزامن لكل جلسة.

بعد إعادة تشغيل Gateway، تُزال عمليات التشغيل القديمة غير المنتهية والمستعادة ما لم تكن جلسة الابن موسومة بـ abortedLastRun: true. تظل عمليات التشغيل التي أُجهضت بسبب إعادة التشغيل مسجلة لتدفق استرداد الوكيل الفرعي اليتيم: تُنهى عمليات التشغيل القديمة دون استئناف، بينما تتلقى جلسات الأبناء الحديثة رسالة استئناف اصطناعية قبل مسح علامة الإجهاض.

الاسترداد التلقائي بعد إعادة التشغيل محدود لكل جلسة ابن. إذا قُبل الابن نفسه من الوكلاء الفرعية مرارًا لاسترداد اليتيم داخل نافذة التعطل السريع المتكرر، يحفظ OpenClaw علامة منع استرداد على تلك الجلسة ويتوقف عن استئنافها تلقائيًا في عمليات إعادة التشغيل اللاحقة. شغّل openclaw tasks maintenance --apply لتسوية سجل المهمة، أو openclaw doctor --fix لمسح علامات استرداد الإجهاض القديمة من الجلسات الموسومة بعلامة المنع.

الإيقاف

• يؤدي إرسال /stop في محادثة الطالب إلى إجهاض جلسة الطالب وإيقاف أي عمليات تشغيل نشطة للوكلاء الفرعية أُنشئت منها، مع تسلسل الإيقاف إلى الأبناء المتداخلين.

القيود

• يكون إعلان الوكيل الفرعي وفق أفضل جهد ممكن. إذا أُعيد تشغيل Gateway، فستُفقد أعمال «الإعلان إلى الخلف» المعلّقة.
• تظل الوكلاء الفرعية تتشارك موارد عملية Gateway نفسها؛ تعامل مع maxConcurrent بوصفه صمام أمان.
• تكون sessions_spawn دائمًا غير حاجبة: إذ تُعيد { status: "accepted", runId, childSessionKey } فورًا.
• لا يحقن سياق الوكيل الفرعي سوى AGENTS.md وTOOLS.md (ولا يحقن SOUL.md أو IDENTITY.md أو USER.md أو MEMORY.md أو HEARTBEAT.md أو BOOTSTRAP.md). تتبع الوكلاء الفرعية الأصلية في Codex الحد نفسه: يظل TOOLS.md ضمن تعليمات سلسلة Codex الموروثة، بينما تُحقن ملفات الشخصية والهوية والمستخدم الخاصة بالوالد فقط بوصفها تعليمات تعاون مقتصرة على الدور، كي لا تنسخها الوكلاء الأبناء.
• الحد الأقصى لعمق التداخل هو 5 (نطاق maxSpawnDepth: من 1 إلى 5). يُوصى بالعمق 2 لمعظم حالات الاستخدام.
• يحدّد maxChildrenPerAgent سقف عدد الوكلاء الأبناء النشطين لكل جلسة (القيمة الافتراضية 5، والنطاق من 1 إلى 20).

ذو صلة

• أدوات الجلسة وتغييرات الحالة
• وكلاء ACP
• إرسال الوكيل
• المهام الخلفية
• أدوات وضع الحماية متعدد الوكلاء