1 / 17
🤝
الموديول 07 — أنظمة متعددة الوكلاء

أنظمة متعددة الوكلاء

من وكيل واحد لفريق — الأنماط، التوجيه، الـ sub-agents، ولوحة الـ Kanban، وسقف التوازي اللي بيكدب عليك
17 شريحة ثنائي اللغة مشروع تطبيقي
شريحة 2 — ليه نعمل وكلاء أصلاً
ليه نعمل وكلاء أصلاً
أربع مشاكل حقيقية — والتوازي مش معناها تعدد وكلاء
🧪
تلويث السياق
نتايج ويب وأخطاء و diffات جربها ورجّعها — كل لفة بعدها بتدفع الثمن
🔧
تخصّص الأدوات
لوحة الدعم لازم ما يكونش فيها terminal أصلاً — ده مش تصميم، ده تسريب
🚦
توزّع الحمل
مهمة بحث طويلة بتحجز الـ session وباقي المستخدمين بيقعدوا في الطابور
♻️
إعادة الاستخدام
وكيل الـ Reviewer أصل ثابت، و SOUL.md بتاعه هو المواصفة
Parallel Tools Multi-Agent
وحدة التنفيذ استدعاء أداة واحدة وكيل كامل (حلقة تفكير كاملة)
عزل لا يوجد session / context منفصل
النتيجة تُدمج في نفس اللفة ترجع كـ turn مستقل
التكلفة زائد شوية مضاعفة (كل وكيل له context)
متى تستخدمه 5 عمليات بحث 5 مقالات بنفس الشكل
💡
القاعدة العملية
لو النتيجة المتوقعة نص ⇒ استخدم أداة. لو النتيجة المتوقعة قرار ⇒ استخدم وكيل.
شريحة 3 — الأنماط الأربعة
الأنماط الأربعة للمعمارية
كل نمط بيحل مشكلة مختلفة — واللي بيشتغل في الإنتاج توليفة منهم
The four shapes
ROUTER [User] ──► [Router] ──► [Sales] [Support] [Eng] WORKER POOL [Queue] ──► [Dispatcher] ──┬─► [Worker 1] ├─► [Worker 2] └─► [Worker 3] SUPERVISOR [Task] ──► [Worker] ──► [Verifier] ──✓ done ▲ │ └── retry ┘ (on failure) HIERARCHICAL [Main] ──┬─► [Orch-A] ──┬─► [w] [w] ├─► [Orch-B] ──► [Orch-D] ──► [w] └─► [Orch-C]
🚦
Router — الموجِّه
عدد الوكلاء ثابت وكل واحد متخصص في سياق واضح — بس نقطة فشل واحدة.
🏭
Worker Pool — تجمع العمال
نفس النوع من الشغل بيتكرر — وده بالظبط Hermes Kanban.
🔍
Supervisor — المشرف
الجودة مضمونة هندسياً — بيزيد التكلفة 30–50%.
🌳
Hierarchical — التسلسلي
المسألة محتاجة تقسيم متكرر — وأعلى تكلفة تنسيق.
⚠️
تحذير تكلفة الهرمية
مع max_spawn_depth: 3 و max_concurrent_children: 3، الشجرة ممكن توصل 27 agent متوازي.
شريحة 4 — مقارنة الأنماط وشجرة القرار
مقارنة الأنماط وشجرة القرار
إزاي تختار في دقيقة بدل ما تجرّب بالغلط
Router Worker Pool Supervisor Hierarchical
حتمي ✔ عالي ✔ عالي متوسط ✘ منخفض
وكلاء فعلياً ✘ ✘ ✔ ✔
تكلفة إضافية منخفضة منخفضة متوسطة عالية
يبقى سيئاً عند نقطة فشل واحدة مهم غير متجانسة نجاح غير معرّف مهمة مسطّحة
في Hermes profiles Kanban board swarm max_spawn_depth > 1
في OpenClaw bindings command queue Swarm collectors maxSpawnDepth
🌳
شجرة القرار
هل عدد الوكلاء ثابت ومحدود؟ نعم ⇒ Router.
شريحة 5 — التوجيه في OpenClaw
توجيه الوكلاء في OpenClaw
الـ binding بتختار الـ agent بس — وهي مش control ولا access
ℹ️
الـ agent في OpenClaw مش prompt — ده نطاق كامل per-persona.
json5
{
  agents: {
    ownership: "explicit",
    entries: {
      main:    { workspace: "~/.openclaw/workspace" },
      support: { workspace: "~/.openclaw/workspace-support" },
    },
  },
  bindings: [
    {
      agentId: "support",
      comment: "Route the support bot account to the support agent",
      match: { channel: "discord", accountId: "support" },
    },
    {
      agentId: "main",
      match: { channel: "discord", accountId: "*" },
    },
  ],
}
حقل المطابقة الوظيفة
accountId حساب واحد مُعدّ — فاضية = الحساب الافتراضي بس
peer محادثة concrete أو wildcard
guildId / teamId قيود group-space خاصة بالقناة
roles Discord role IDs، بيتقيّم مع شرط الـ guild
session.dmScope / groupScope تجاوز لنطاق session
⚠️
ترتيب الأولوية + نقطة حرجة
الترتيب بالـ specificity والأضيق بيكسب: peer محدّد ← peer wildcard ← guild+roles ← guild ← team ← account ← channel ← default agent.
شريحة 6 — توليد sub-agents في OpenClaw
توليد sub-agents في OpenClaw
التسليم push-based — وانتهاء الـ run مش انتهاء الشغل
⛔
ما تعملش polling — الـ completion push-based.
json5
{
  agents: {
    defaults: {
      maxConcurrent: 4,          // سقف الـ main lane المشترك
      subagents: {
        maxSpawnDepth: 2,        // الافتراضي 5، المدى 1-5
        maxChildrenPerAgent: 5,  // أقصى أطفال نشطين لكل session
        maxConcurrent: 8,        // أقصى runs متوازية لكل spawning session
        runTimeoutSeconds: 900,  // 0 = بلا مهلة
        announceTimeoutMs: 120000,
        delegationMode: "prefer",
      },
    },
  },
  messages: { queue: { mode: "collect", cap: 20, drop: "summarize" } },
}
Announce chain
depth 2 child ──announce──► depth 1 parent | (parent synthesises its own children first) └──announce──► main agent ──► user each level only sees announcements of its DIRECT children — no sibling talk
العمق session key الدور الافتراضي يقدر يـspawn؟
0 agent:<id>:main Main agent دائماً
1 agent:<id>:subagent:<uuid> Orchestrator نعم، إلا لو maxSpawnDepth: 1
2–4 مفاتيح مسطّحة محفوظة مع lineage Orchestrator نعم، افتراضياً
5 مفتاح مسطّح مع lineage Leaf ✘ لأ
🧩
حدود السياق والأدوات
sub-agent context بيحقن AGENTS.md بس — والـ children مش بياخدوا message tool.
شريحة 7 — الـ profiles في Hermes
الـ profiles في Hermes
«محادثة منفصلة» ≠ «profile منفصل» — وده أشهر غلط في الموديل
🚫
القاعدة الذهبية: عمرك ما تشغّل عمليتين على نفس الـ profile
كل الـ profiles بيكتبوا الذاكرة تلقائياً، وكل واحد بيحمّل كتابات التاني في الـ system prompt بتاعه بداية الجلسة.
bash
# إنشاء + وصف (الوصف مهم لو الـ profile هيشتغل kanban worker)
hermes profile create researcher \
  --description "Reads source code and external docs, writes findings."

# نسخ: config فقط / كل حاجة / من profile محدد
hermes profile create work --clone
hermes profile create backup --clone-all
hermes profile create work --clone-from coder

# الاستخدام
hermes -p work chat
hermes profile use work        # sticky default
hermes profile list
hermes profile describe --all --auto
hermes -p <name> auth add <provider>
المصطلح المعنى
Profile بيت Hermes منفصل بالكامل
Agent الـ Hermes assistant الشغّال
Subagent طفل اتولد بـ delegate_task — مش profile
Bot Mode bot profile بيظهر في الـ roster
Messaging bot حساب على منصة مراسلة
💡
النسخ ما بيجيبش القنوات ولا الـ OAuth
كل clone بينسخ من غير bot tokens والـ allowlists — البوت ينتمي لـ profile واحد بس.
شريحة 8 — Bot Mode
Bot Mode — فريق من شخصيات
مفيش primitive جديد — الـ Bot هو Hermes profile
💬
Bot Chat
ضغط على البوت بيفتح محادثة دائمة — و/new بيعمل fork، متعملهوش.
🕐
Active now
صاحب اللفة الحية المركّزة، واللي كتبوا خلال آخر 90 ثانية.
🫥
Hide Bot
عرضي بس — وroutines لسه بتشتغل.
bash
# الـ Bot == profile: كل حاجة بتعملها في الواجهة بتفضل من الـ CLI
hermes -p <name> chat      # بيفتح نفس الـ agent بالظبط
hermes profile list        # الـ roster

# الـ routines هي cron jobs حقيقية — نفس أدوات cron
hermes cron list
🤖
Bot ≠ Messaging bot
الـ Bot شخصية جوّه الواجهة — والـ Messaging bot حساب على منصة حقيقية.
⚠️
ليه Bot Mode مهم للـ multi-agent — وحدّه
البوتات **بتتكلم مع بعض** — وده مش متاح في delegate_task.
شريحة 9 — sub-agents في Hermes
sub-agents في Hermes عبر delegate_task
أربع نمانج — والـ subagent بيفتح محادثة جديدة كلياً
python
# 1. Single
delegate_task(goal, context)

# 2. Batch — كل الـ children متوازية في handle واحد
delegate_task(tasks=[
    {"goal": "...", "context": "..."},
    {"goal": "...", "context": "..."},
    {"goal": "...", "context": "..."},
])

# 3. Background — بيرجع handle على طول، النتيجة turn جديد
delegate_task(goal=..., context=..., background=True)

# 4. Orchestrator — طفل يقدر يspawn أولاده
delegate_task(goal=..., role="orchestrator")

# النتيجة JSON متحقّقة — ده اللي يخليك تدمج بدل parsing نص حر
delegate_task(goal=..., output_schema={...})
OpenClaw sessions_spawn Hermes delegate_task
التسليم announce chain (درجة بدرجة) النتيجة ترجع كـ turn جديد
Batch spawn متكرر ✔ tasks array في نداء واحد
Depth maxSpawnDepth (1–5) max_spawn_depth — flat
Concurrency maxConcurrent: 8 max_concurrent_children (3)
Tool surface الأطفال محرومين من session/message tools full tools حسب الـ toolset
📌
أهم قاعدة: الـ subagent مش بيشوف سياق الـ parent
هو بيفتح محادثة جديدة كلياً؛ اللي بيمرّه هو context و goal بس.
شريحة 10 — لوحة Kanban متعددة الوكلاء
لوحة Kanban متعددة الوكلاء
لوحة SQLite دائمة — الـ board هو الحد الصلب للعزل
Task lifecycle
triage ──► todo ──► ready ──► running ──► review ──► done │ └──► blocked links: parent ──► child ; dispatcher promotes todo → ready when ALL parents are done every state change writes a row in task_events
bash
# إنشاء مهمة بمعاملاتها المهمة
hermes kanban create "Research: agent frameworks 2026" \
  --body "Gather facts ... output a brief with a sources table." \
  --assignee researcher --workspace scratch --priority 10 --max-runtime 30m

# dependencies: ده اللي بيخلّي الـ pipeline يعمل لوحده
hermes kanban link <research_id> <write_id>

# lifecycle
hermes kanban request-review <id>   # مستني مراجعة — مش block
hermes kanban block <id> --note "needs an API key"
hermes kanban promote <id>         # recovery: todo/blocked → ready

# تشخيص
hermes kanban dispatch --dry-run
hermes kanban diagnostics
hermes kanban stats
hermes kanban watch
المفهوم المعنى
Board طابور مستقل بـ SQLite خاص
Comment بروتوكول التواصل بين الوكلاء
Tenant namespace ناعم — مش حد أمان
Circuit breaker auto-block بعد محاولتين فاشلتين
المتغيرات السحرية HERMES_KANBAN_BOARD، HERMES_KANBAN_TASK، HERMES_KANBAN_WORKSPACE
🛑
الـ dispatcher بيشتغل جوه الـ gateway
hermes kanban daemon Deprecated — استخدم hermes gateway start.
شريحة 11 — Swarm وتفكيك المهام
Swarm v1 وتفكيك المهام
Map + Verify + Reduce — والـ graph كله في أمر واحد
📐
لو ما تقدرش تكتب الـ acceptance criteria بتاع المهمة، ما تفكّكهاش.
bash
# Swarm: workers متوازيين → verifier → synthesizer، بتبعيات مولّدة تلقائياً
hermes kanban swarm "قارن بين Postgres و SQLite لتطبيقنا" \
  --worker "researcher:ابحث عن مزايا Postgres" \
  --worker "researcher:ابحث عن مزايا SQLite" \
  --worker "analyst:اقرأ الكود الحالي" \
  --verifier auditor \
  --synthesizer writer

# مهمة open-ended: worker في goal loop، judge بيقيس كل رد ضد الكارت
hermes kanban create "Improve the article's opening" \
  --assignee writer --goal --goal-max-turns 5
الاستراتيجية إمتى الشرط
Output Partitioning 10 مصادر مستقلة كل مهمة قابلة للتحقق لوحدها
Sequential Pipeline spec ← implement ← test كل خطوة عندها مخرج مكتوب
Role Partitioning تخصصات مختلفة فعلاً دور الـ reviewer مش نفس دور الـ coder
Goal Loop النهاية مش واضحة مهمة مفتوحة مش عدديّة
Map-Reduce بيانات كتير + دمج حقيقي الـ Reduce deterministic قدر الإمكان
💸
حذار تكلفة + خطأ كلاسيكي
البحث Map بسيطة — الـ swarm = Map + Verify + Reduce.
شريحة 12 — التوازي وتجميع النتائج
مسارات العمل المتوازية وتجميع النتائج
التوازي مش «وكلاء أكتر» — هو مشكلة تصميم على مورد نادر
أسلوب التجميع المزايا العيوب
انتظار الكل tasks=[...] بسيط، والنموذج بيقرّر الأهمية بنفسه أبطأ child بيحدّد الكل
بث background=True سريع، والـ parent بياخد نتيجة مبكرة محتاج صبر، وعرضة للتفكير المكرر
Swarm v1 Map + Verify + Reduce تكلفة عالية
البوتلنك العلامة الحل
Session locks مهام بتنتظر في نفس الـ session lane contracts + background work
Model capacity rate limits من الـ provider قلّل maxConcurrent
Tool capacity workers واقفين على terminal execute_code بدل agent
Ownership ambiguity وكلاء مكرر بيعملوا نفس الحاجة describe واضح + routing صريح
🧹
قبل ما توسّع، نضّف
لو عندك 5 workers بيعملوا نفس الشغل، عندك 1 worker و 4 مهدرين.
شريحة 13 — التسلسل والإشراف
التسلسل والإشراف
اختبار الـ 3 أسئلة: لو 3/3 نعم، عندك hierarchy
Do you actually need a hierarchy?
1. is the task really COMPOSABLE (not just 10 independent files)? 2. is the final result ASSEMBLED from intermediate results (real synthesis)? 3. are the sub-problems UNKNOWN until the first one resolves? if you can settle every sub-problem without seeing any result -> NO hierarchy, that is just a plain parallel fan-out.
مستوى الإشراف الأداة إمتى
Sampling role="orchestrator" ورشة عمل 2–3 وكلاء
Goal loop --goal مهمة واحدة مفتوحة
Verifier swarm النجاح معرّف موضوعياً
Board root orchestrator_profile تلقائي
bash
# جودة الـ auto-routing مرهونة بجودة الأوصاف — من غيرها بيرمي child tasks عشوائي
hermes profile describe researcher --text "Reads source code and external docs, writes findings."
hermes profile describe auditor   --text "Verifies every claim against sources; rejects unsupported assertions."
hermes profile describe --all --auto

# الفرق المهم: review مش block
hermes kanban request-review <id>    # التنفيذ خلص، مستني مراجعة
hermes kanban block <id>            # محتاج تدخل بشري
hermes kanban request-changes <id>  # حكم الـ reviewer: رجّع للأنفّذ
💡
خلطهم بيوقف الـ pipeline في نصه
request-review = «خلص، حد يحدّق» — وblock = «محتاج حد».
شريحة 14 — حل التعارضات
حل التعارضات بين الوكلاء
80% من التعارضات ثغرة في الـ boundary — مش مشكلة prompt
التعارض الحل
Routing Routing — الأولوية بالـ specificity
Write Write — git worktrees
Criteria Criteria — ده نقص مواصفة
Memory Memory — profile منفصل لكل writer
Priority الـ queue + فصل الشغل التقيل لـ background
Conflict protocol
1. Stop — لا تفرّق نتيجة لحد 2. Classify — Routing / Write / Criteria / Memory / Priority 3. Locate — فين الـ boundary المفروض؟ 4. Fix the boundary — config، مش agent 5. Document — الـ rule اللي اتغير 6. Verify — جرّب نفس السيناريو تاني
🎯
صلّح الـ boundary مش الـ prompt
العزل بثلاث طبقات: Profile = هوية، Workspace = شغل، Sandbox = تنفيذ.
شريحة 15 — سقف التوازي
سقف التوازي — والـ cap الرابع اللي مش في Hermes
تلات caps حقيقية في الكود، والرابع بييجي من الـ model نفسه
الـ cap أين العلامة في اللوج
Per-call reject delegate_tool.py Too many tasks: N provided...
Per-turn truncator _cap_delegate_task_calls Truncated N excess delegate_task...
Cost warning — مش capping نفس الدالة High values multiply cost linearly
✘ الـ model نفسه نماذج الاستدلال بتقصّ batch لـ «رقم أجمل» مفيش لوج خالص
bash
# الـ recipe التشخيصي — 3 خطوات
hermes config get delegation.max_concurrent_children

grep -E "Truncated.*delegate_task|Too many tasks" ~/.hermes/logs/agent.log | tail

python -c "from tools.delegate_tool import _get_max_concurrent_children; print(_get_max_concurrent_children())"
🧠
الـ cap هو الـ model مش Hermes
لو الـ config والـ logs متوافقين ومفيش اللوجين، الـ cap جاي من الـ model.
شريحة 16 — OpenClaw مقابل Hermes
OpenClaw مقابل Hermes في الـ multi-agent
المصفوفات المختارة — النظامين مختلفين في الأساس
البُعد OpenClaw Hermes
Primitive الـ multi-agent agents.entries profiles
التوجيه ✔ bindings profile selection + multiplexing
Sub-agents sessions_spawn delegate_task
عدد التوازي 8 3
Batch ✘ نداء لكل طفل ✔ tasks array
Structured output ✘ مفيش output_schema ✔ output_schema
الطابور / الـ Board command queue (زائلة) ✔ Kanban
الـ tenancy ✘ ✔ soft namespace
Goal loop ✘ ✔ --goal
Auto decomposition ✘ ✔ decomposer
Model لكل مهمة ✔ model ✔ --model
Bot-to-bot مباشر ✘ ✔ Bot Mode
الحد الأخطر sub-agents بيشتركوا في عملية الـ Gateway delegate_task مش durable
🧭
الحل العملي للديوم
delegate_task مش durable — للشغل اللي لازم يعيش استخدم cronjob أو Kanban.
شريحة 17 — المشروع والاختبار
المشروع التطبيقي والاختبار
ابنِ فريق 3 متخصصين — ثم 5 أسئلة سريعة
bash
# 1) تلات profiles بأوصاف — الأوصاف هي اللي بيوجّه الـ decomposer
hermes profile create researcher --description "Reads source code and external docs, writes findings with citations."
hermes profile create writer     --description "Turns a researched brief into a structured article. Does not invent facts."
hermes profile create auditor    --description "Verifies every claim against its cited source. Rejects unsupported assertions."
hermes -p researcher setup && hermes -p writer setup && hermes -p auditor setup

# 2) اكتب هوية كل واحد في SOUL.md — بيتحقن في كل جلسة
cat > ~/.hermes/profiles/auditor/SOUL.md <<'EOF'
# Auditor
## Owns
- Verifying every claim in a draft against its cited source
## Does not own
- Writing or rewriting the draft (→ writer)
## Output contract
| Claim | Verdict | Evidence |
Verdict is exactly one of: SUPPORTED / UNSUPPORTED / MISLEADING
End with PASS or FAIL. FAIL if any UNSUPPORTED claim remains.
EOF

# 3) لوحة + pipeline بالـ links — الـ promotion بيحصل لوحده
hermes kanban boards create content-pipeline --name "Content Pipeline" --switch
hermes kanban create "Research: agent frameworks" --assignee researcher --max-runtime 30m
hermes kanban create "Write: comparison"        --assignee writer     --max-runtime 20m
hermes kanban create "Audit: article"          --assignee auditor    --max-runtime 15m
hermes kanban link <research_id> <write_id> && hermes kanban link <write_id> <audit_id>

# 4) شغّل واعرف النجاح: pipeline end-to-end + auto-promotion + goal loop
hermes kanban dispatch --dry-run
hermes gateway start
hermes kanban list --status running

اختبار الموديول 7

Score: 0/5
Q1: OpenClaw عندك 3 حسابات Discord والـ binding بتاعك حطّيت accountId فاضي. إيه اللي بيحصل؟
بيطابق الحساب الافتراضي بس
بيرفض الـ config لأنه ناقص
بيوزّع عشوائي على التلاتة
Q2: عندك pipeline: research → write → audit. الـ research خلص والـ write لسه todo من 10 دقايق.
bucket الـ dependency — الـ link أو المسندة
الـ dispatcher بطيء، استنى
الـ writer profile باظ
Q3: حطّيت max_concurrent_children: 15، والـ log فاضي من لوجي الـ capping. إيه السبب الحقيقي؟
الـ model نفسه بيقصّ الـ batch
لوج الـ cost-warning هو اللي بيقصّ
في سقف صلب تاني مش موثّق
Q4: لقيت تلات agents بيكتبوا في نفس الـ profile وبيتخانقوا. إيه الحل الجذري؟
قسّم لـ profiles منفصلة
فعّل sandbox لكل واحد
قلّل max_concurrent_children لـ 1
Q5: مهمة «ابحث في 5 مصادر وقارن» على 5 agents ونتايجهم نص حر. أنهي الأداة الصح؟
hermes kanban swarm مع verifier
delegate_task بـ 5 children
execute_code