وكيل واحد أم عدة وكلاء؟ متى يستحق نظام الوكلاء المتعددين تكلفته (2026)

فكرة "الوكلاء المتعددين" (Multi-Agent) هي أكثر فكرة يُبالَغ في استخدامها في هندسة الذكاء الاصطناعي اليوم. فرق كثيرة تقسّم مهمة بسيطة بين مخطِّط وباحث وكاتب ومراجع، ثم تقضي أسابيع في تتبع أخطاء الحوار بينهم. أحياناً تكون هذه البنية هي الصحيحة تماماً، لكن في أغلب الأحيان كان وكيل واحد، أو حتى سير عمل ثابت، سيكون أسرع وأرخص وأسهل في الإصلاح.

هذا الدليل يعطيك طريقة واضحة لاتخاذ القرار، مبنية على أوضح الأدلة المنشورة: ما كتبته Anthropic عن بناء الوكلاء، وعن نظام البحث متعدد الوكلاء الذي تعمل عليه ميزة Research في Claude. وفي النهاية نبني منسِّقاً صغيراً بلغة Python، مُختبَراً، يوضح ما تكسبه فعلاً وما تخسره.

ابدأ بأبسط حل يعمل

دليل Anthropic "Building effective agents" (ديسمبر 2024) يفرّق بين نوعين من الأنظمة. سير العمل (Workflows): أنظمة تُنسَّق فيها النماذج والأدوات عبر مسارات مكتوبة مسبقاً في الكود. الوكلاء (Agents): أنظمة يقرر فيها النموذج بنفسه خطواته والأدوات التي يستخدمها. ونصيحته الأساسية مباشرة: ابحث عن أبسط حل ممكن، ولا تزد التعقيد إلا عند الحاجة.

وهذا يعطيك سلّماً، اصعده درجة درجة:

• استدعاء واحد للنموذج مع تعليمات وأمثلة جيدة. أغلب أفكار "الوكلاء" تنتهي هنا.
• سير عمل عندما تكون الخطوات معروفة مسبقاً. ويصف الدليل نفسه الأنماط الشائعة: تسلسل التعليمات (خطوات ثابتة كل منها يستخدم ناتج السابقة)، والتوجيه (تصنيف المدخل وإرساله إلى مسار متخصص)، والتوازي (تقسيم أجزاء مستقلة، أو تشغيل عدة محاولات والتصويت بينها)، والمُقيِّم والمُحسِّن (نموذج يكتب وآخر ينتقد، ويتكرر ذلك).
• وكيل واحد عندما لا يمكن تحديد المسار مسبقاً، ويجب أن يقرر النموذج أي أداة يستدعي.
• عدة وكلاء، وغالباً بنمط المنسِّق والعمّال (Orchestrator-Workers): وكيل رئيسي يقسّم العمل ويوزعه على وكلاء عمّال. ويوصي به الدليل للمهام المعقدة التي لا تستطيع توقّع مهامها الفرعية مسبقاً.

ماذا تقول الأدلة عن أنظمة الوكلاء المتعددين؟

في يونيو 2025 نشرت Anthropic كيف بنت نظام البحث متعدد الوكلاء في Claude. أرقامه هي أفيد بيانات منشورة عن هذا السؤال، فتستحق القراءة بعناية:

• قد يكون أفضل بكثير. نظام فيه Claude Opus 4 كوكيل رئيسي ووكلاء فرعيون من Claude Sonnet 4 تفوّق على Claude Opus 4 وحده بنسبة 90.2% في تقييم البحث الداخلي لدى Anthropic.
• وهو أغلى بكثير. الوكلاء يستهلكون عادة حوالي 4 أضعاف التوكنات مقارنة بالمحادثة العادية، وأنظمة الوكلاء المتعددين حوالي 15 ضعفاً.
• والحقيقتان مرتبطتان. في تحليلهم لمعيار BrowseComp، استهلاك التوكنات وحده فسّر 80% من الفروق في الأداء. أنظمة الوكلاء المتعددين تتفوق أساساً لأنها تسمح لك بصرف توكنات أكثر بشكل مفيد، وبالتوازي، عبر نوافذ سياق منفصلة.

والمقال نفسه واضح في تحديد متى يناسب هذا النهج: يعمل أفضل في المهام القيّمة التي تحتاج توازياً كبيراً، ومعلومات أكبر من نافذة سياق واحدة، وتعاملاً مع أدوات كثيرة ومعقدة. ولا يناسب المجالات التي يحتاج فيها كل الوكلاء إلى السياق نفسه، أو التي فيها اعتماد كبير بين الوكلاء. ويشير الكاتبون إلى أن أغلب مهام البرمجة فيها أجزاء قابلة للتوازي أقل بكثير من البحث.

رأينا: اختبار من أربعة أسئلة

لا تتجه إلى الوكلاء المتعددين إلا إذا كانت إجابتك "نعم" على الأسئلة الأربعة كلها. وإذا كانت أي إجابة "لا"، فوكيل واحد أو سير عمل سيخدمك أفضل.

• هل العمل عرضي (breadth-first)؟ هل ينقسم إلى أجزاء لا يحتاج أحدها نتيجة الآخر، مثل البحث عن خمسة موردين، أو قراءة عشرة مستندات، أو فحص ستة أسواق؟ إذا كانت الخطوة 3 تحتاج ناتج الخطوة 2، فالعمّال المتوازيون سينتظرون بعضهم فقط.
• هل المادة أكبر مما تستوعبه نافذة سياق واحدة جيداً؟ إذا كان وكيل واحد يستطيع قراءة كل شيء براحة، فالتقسيم يضيف عمليات تسليم فقط.
• هل المهمة قيّمة بما يكفي لتدفع أضعاف التكلفة؟ عند حوالي 15 ضعف توكنات المحادثة، يجب أن يستحق التشغيل ذلك. تقرير عناية واجبة قبل صفقة؟ نعم. رد على استفسار عميل؟ تقريباً أبداً.
• هل تستطيع تقييمه؟ أخطاء الأنظمة متعددة الوكلاء تختبئ في عمليات التسليم بينهم. وبدون مجموعة اختبارات لن تعرف هل ساعدت الوكلاء الإضافية أم لا. (دليلنا عن اختبار الوكلاء بمقياس pass^k يشرح الطريقة.)

شاهد المقايضة في الكود

السكربت التالي ينفّذ مهمة البحث نفسها، المكونة من خمس مهام فرعية مستقلة، ببنيتين مختلفتين. العمّال هنا بدائل بزمن ثابت، فيكون التشغيل قابلاً للتكرار دون مفتاح API؛ وفي نظام حقيقي تستبدل call_model باستدعاء نموذج وتُبقي الباقي كما هو. أنشئ orchestrator.py:

"""Single agent vs orchestrator-workers: the same research job, two architectures.

Workers are stand-ins with a fixed delay so the run is reproducible. Swap
`call_model` for a real model call; the orchestration code stays the same.
"""
import asyncio
import time

SYSTEM_PROMPT_TOKENS = 1_500  # instructions + tool definitions every agent reads
RESULT_TOKENS = 2_000         # raw search results for one subtask
SUMMARY_TOKENS = 200          # what a worker hands back to the lead
STEP_SECONDS = 0.3            # stand-in latency of one subtask (scaled down)


async def call_model(subtask: str, fail: bool = False) -> str:
    """Stand-in for one agent researching one subtask."""
    await asyncio.sleep(STEP_SECONDS)
    if fail:
        raise TimeoutError(f"search tool timed out on {subtask!r}")
    return f"key findings on {subtask}"


async def single_agent(subtasks: list[str]) -> dict:
    """One agent, one context window: raw results pile up as it goes."""
    start, context, peak = time.perf_counter(), SYSTEM_PROMPT_TOKENS, 0
    for s in subtasks:
        await call_model(s)
        context += RESULT_TOKENS
        peak = max(peak, context)
    return {"seconds": time.perf_counter() - start, "peak_context": peak}


async def orchestrator(subtasks: list[str], failing: frozenset = frozenset()) -> dict:
    """A lead agent fans out to workers in parallel; each worker has a clean context."""
    start = time.perf_counter()
    jobs = [call_model(s, fail=s in failing) for s in subtasks]
    results = await asyncio.gather(*jobs, return_exceptions=True)  # one failure must not sink the rest

    found = [r for r in results if not isinstance(r, Exception)]
    gaps = [f"{s}: {r}" for s, r in zip(subtasks, results) if isinstance(r, Exception)]
    worker_peak = SYSTEM_PROMPT_TOKENS + RESULT_TOKENS
    lead_peak = SYSTEM_PROMPT_TOKENS + SUMMARY_TOKENS * len(found)  # lead reads summaries only
    return {"seconds": time.perf_counter() - start,
            "peak_context": max(worker_peak, lead_peak), "gaps": gaps}


async def main():
    subtasks = ["pricing", "API limits", "data residency", "Arabic support", "SLA terms"]
    single = await single_agent(subtasks)
    multi = await orchestrator(subtasks)

    print(f"{'architecture':<22}{'seconds':>9}{'largest context':>17}")
    print(f"{'single agent':<22}{single['seconds']:>9.1f}{single['peak_context']:>17,}")
    print(f"{'orchestrator-workers':<22}{multi['seconds']:>9.1f}{multi['peak_context']:>17,}")

    partial = await orchestrator(subtasks, failing=frozenset({"SLA terms"}))
    print("\nWith one worker failing, the lead still answers and reports the gap:")
    for g in partial["gaps"]:
        print("  missing ->", g)


if __name__ == "__main__":
    asyncio.run(main())

ثلاث تفاصيل تجعل هذا منسِّقاً حقيقياً لا مجرد حلقة تكرار:

• asyncio.gather يشغّل العمّال في الوقت نفسه. الوكيل الرئيسي لا ينتظر انتهاء مهمة فرعية قبل أن يبدأ التالية.
• كل عامل يبدأ بسياق نظيف. يرى فقط التعليمات ومهمته الفرعية، لا النتائج الخام للعمّال الأربعة الآخرين. وهذه هي ميزة "نوافذ السياق المنفصلة" التي يشرحها مقال Anthropic.
• return_exceptions=True يعزل الأعطال. إذا تعطلت أداة عند عامل واحد، يرجع الباقون نتائجهم، ويذكر الوكيل الرئيسي النقص بدل أن ينهار. ومقال Anthropic يؤكد أن الأعطال الصغيرة في أنظمة الوكلاء قد تكون كارثية، فهذه النقطة أهم مما تبدو.

ماذا يُظهر التشغيل، وماذا لا يُظهر

تشغيل python orchestrator.py أعطى:

architecture            seconds  largest context
single agent                1.5           11,500
orchestrator-workers        0.3            3,500

With one worker failing, the lead still answers and reports the gap:
  missing -> SLA terms: search tool timed out on 'SLA terms'

اقرأه بعناية، لأنه يُظهر طرفي المقايضة:

• السرعة: أسرع بخمس مرات هنا. المهام الفرعية الخمس المستقلة عملت معاً، فاستغرقت المهمة زمن خطوة واحدة بدل خمس. وهذا يحدث فقط لأن المهام كانت مستقلة؛ لو كانت سلسلة خطوات يعتمد بعضها على بعض لتساوى الرقمان.
• السياق: لم يحمل أي وكيل أكثر من 3,500 توكن. الوكيل الواحد انتهى بـ 11,500 توكن في نافذة واحدة (1,500 للتعليمات و5 × 2,000 للنتائج الخام)، وهذا الرقم يكبر مع كل مهمة فرعية. أما الوكيل الرئيسي في المنسِّق فيقرأ ملخصات قصيرة فقط. ولهذا تتعامل أنظمة الوكلاء المتعددين مع معلومات أكبر من نافذة سياق واحدة.
• العطل: المهمة انتهت رغم ذلك. فشل عامل واحد، والمخرجات تسمّي بالضبط ما الذي نقص. وهذا هو السلوك الذي تريده من الوكيل الرئيسي: إجابة جزئية صادقة بدل لا شيء.

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

إذا قررت بناءه: دروس من بيئة الإنتاج

• علّم الوكيل الرئيسي أن يقدّر حجم الجهد حسب السؤال. وضعت Anthropic في تعليمات وكيلها الرئيسي قواعد صريحة: البحث عن حقيقة بسيطة يحتاج وكيلاً واحداً بين 3 و10 استدعاءات للأدوات، والمقارنة المباشرة قد تحتاج 2 إلى 4 وكلاء فرعيين بين 10 و15 استدعاءً لكل منهم، والبحث المعقد قد يستخدم أكثر من 10 وكلاء فرعيين. وبدون هذه القواعد يميل الوكيل الرئيسي إلى إطلاق عمّال كثيرين لأسئلة سهلة.
• اكتب تكليف كل عامل كأنه تذكرة مهمة. كل عامل يحتاج هدفاً واضحاً، وشكل المخرجات، والأدوات التي يستخدمها، وحدوداً واضحة، حتى لا يبحث عاملان في الشيء نفسه.
• أرجِع ملخصات لا نتائج خاماً. سياق الوكيل الرئيسي هو عنق الزجاجة. يجب أن يسلّم العمّال نتائج مختصرة مع مصادرها، كما في المثال.
• خطط للأعطال في التشغيل الطويل. تشغيل الوكلاء له حالة: انهيار في المنتصف لا يمكن ببساطة أن يبدأ من الصفر. احفظ التقدم، وأعد محاولة الأدوات، واسمح للوكيل بالتكيف عندما تفشل أداة.
• انشر التحديثات بحذر. تستخدم Anthropic ما تسميه "rainbow deployments"، أي نقل الطلبات تدريجياً من النسخة القديمة إلى الجديدة، حتى لا تكسر التغييرات وكلاء يعملون في منتصف مهامهم.

الخلاصة

نظام الوكلاء المتعددين أداة لشكل واحد محدد من المشاكل: عمل واسع ومتوازٍ وعالي القيمة يتجاوز نافذة سياق واحدة. في هذا الشكل المكاسب كبيرة وموثقة جيداً. وفي كل ما عداه، الوكلاء الإضافيون يضيفون تكلفة، وتأخيراً في عمليات التسليم، وأماكن جديدة للأعطال. اصعد السلّم درجة درجة، وقِس كل خطوة بالاختبارات، ولا تضف وكلاء إلا عندما تثبت الأدلة أن الدرجة التالية تستحق تكلفتها.

والأساسيات التي شرحناها في أدلتنا السابقة تنطبق داخل كل عامل: أدوات عبر MCP وذاكرة تصمد في التشغيل الطويل.

المصادر: مدونة Anthropic الهندسية، "Building effective agents" (19 ديسمبر 2024) و"How we built our multi-agent research system" (13 يونيو 2025). جرى اختبار الكود بتاريخ 2026-10-05 على Python 3.13؛ والعمّال بدائل بأزمنة وأحجام توكنات ثابتة، فأرقام السرعة والسياق توضيح للبنية وليست قياساً لأي نموذج حقيقي.