تسليم المهام متعدد الوكلاء: تمرير السياق بين الوكلاء الفرعيين

وجد وكيل البحث حساب العميل، وأكد الخطة، وسحب آخر أربع فواتير. ثم سلّمه إلى وكيل الفوترة بملخص من سطر واحد: «العميل يريد استردادًا». يبدأ وكيل الفوترة، الذي لا يعرف الآن شيئًا عن الحساب أو الخطة أو الفواتير، بطلب معرف الحساب.

جرّب Apidog اليوم

كل حقيقة جمعها الوكيل الأول ضاعت عند نقطة الانتقال. هذه مشكلة التسليم: تدفع ثمنها في استدعاءات API المكررة والأخطاء الناتجة عن عمل الوكيل الثاني بمعلومات أقل من الأول.

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

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

ما الذي يجب أن يعبر الحد؟

لا تمرر سجل المحادثة كله، ولا تمرر لا شيء. مرر فقط ما لا يمكن للوكيل المستلم استعادته بسهولة:

• المعرفات: مثل customer_id وinvoice_id وtask_id. صغيرة، مستقرة، وقابلة للتحقق.
• القرارات المتخذة: مثل «العميل مؤهل للاسترداد بموجب السياسة 3». لا تجعل الوكيل التالي يعيد الحكم.
• القيود: الميزانيات، الموافقات، والإجراءات المنفذة. فقدانها قد يؤدي إلى تحصيل أو إرسال مكرر. راجع التكرارية لوكلاء الذكاء الاصطناعي.
• الأسئلة المفتوحة: ما لم يتمكن الوكيل الأول من حسمه، حتى لا يفترض الوكيل التالي إجابة من تلقاء نفسه.

لا تحتاج عادةً إلى تمرير استجابات API الخام أو سجل الاستدلال أو أي بيانات يستطيع الوكيل التالي جلبها باستدعاء واحد.

ثلاث طرق لتمرير الحالة

1. تمرير المحادثة كاملة

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

2. تمرير ملخص

يكتب الوكيل الأول ملخصًا ويبدأ الثاني منه. المشكلة أن النماذج تميل إلى حفظ السرد وحذف المعرفات. قد تحصل على:

العميل مشترك منذ عامين ومحبط.

بدلًا من:

الحساب 8812، خطة احترافية، أربع فواتير، وتمت الموافقة على استرداد للفاتورة inv_44.

3. تمرير كائن تسليم منظم

هذا هو الخيار الأكثر متانة. يملأ الوكيل الأول مخططًا، ويقرأ الوكيل الثاني الحقول بدل الاعتماد على النثر.

{
  "task_id": "task_2026_08_26_0031",
  "from_agent": "research",
  "to_agent": "billing",
  "entities": {
    "customer_id": "cus_8812",
    "invoice_ids": ["inv_41", "inv_42", "inv_43", "inv_44"],
    "subscription_id": "sub_119"
  },
  "decisions": [
    { "decision": "refund_eligible", "value": true, "basis": "policy 3.2, charged twice in one cycle" }
  ],
  "constraints": {
    "max_refund_cents": 4900,
    "human_approval_granted": false,
    "actions_taken": ["read_invoices"]
  },
  "open_questions": ["Customer has not confirmed which invoice to refund"],
  "summary": "Customer cus_8812 was double-charged in August. Refund of one invoice is approved under policy 3.2, up to 4900 cents. Awaiting the customer's choice of invoice."
}

احتفظ بحقل summary للتفاصيل الدقيقة التي لا يغطيها المخطط، لكن لا تدعه يحل محل الحقول المنظمة.

تحقق من صحة الكائن قبل التسليم. إذا كان customer_id مطلوبًا ومفقودًا، أوقف العملية عند الحد بدل أن يكتشف الوكيل الثاني المشكلة بعد عدة استدعاءات.

مرر المراجع، لا الحمولات

أقوى تسليم يمرر أقل قدر من البيانات: المعرفات فقط، ثم يجلب الوكيل المستلم ما يحتاجه.

هذا يحقق ثلاث فوائد:

1. الحالة حديثة: يرى الوكيل الثاني القيمة الحالية بدل نسخة قديمة.
2. الحمولة صغيرة: مئات البايتات بدل آلاف الرموز.
3. التدقيق أوضح: تظهر كل قراءة كاستدعاء API بدل نص منسوخ بين المطالبات.

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

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

أين تتعطل عمليات التسليم؟

معرف مفقود

يقول الملخص «العميل» من دون معرف. يبحث الوكيل التالي بالاسم، يجد تطابقين، ويختار الخطأ.

الحل: اجعل معرفات الكيانات المطلوبة حقولًا إلزامية وتحقق منها قبل التسليم.

إجراء مكرر

أرسل الوكيل الأول البريد الإلكتروني، لكنه لم يسجل ذلك. يرسله الوكيل الثاني مرة أخرى.

الحل: سجل actions_taken وتحقق منه قبل أي كتابة، مع استخدام مفاتيح التكرارية.

موافقة مفقودة

وافق شخص على الاسترداد أثناء عمل الوكيل الأول. لا يعرف الوكيل الثاني ذلك ويطلب الموافقة ثانيةً.

الحل: مرر الموافقات كقيود صريحة مرتبطة بالمهمة، لا بالوكيل.

اختراع واثق

يحتاج الوكيل المستلم إلى قيمة غير موجودة في التسليم، فيخترعها بدل السؤال.

الحل: استخدم open_questions وأضف قاعدة صريحة: إذا غاب معرف مطلوب، توقف واسأل.

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

اختبر الحد، لا الوكلاء فقط

التسليم نقطة تكامل، لذا اختبره كنقطة تكامل.

اختبر كائن التسليم

شغّل الوكيل الأول على سيناريو ثابت، ثم تحقق من أن الكائن الناتج يحتوي على:

• المعرفات المطلوبة
• القرارات المسجلة وأسسها
• الإجراءات المنفذة
• القيود والأسئلة المفتوحة

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

اختبر المستلم منفصلًا

مرر لوكيل الفوترة كائن تسليم يدويًا وتحقق من الإجراء الناتج. ثم احذف customer_id عمدًا وتأكد من أنه يسأل بدل التخمين. هذا هو الاختبار الذي يكشف الاختراع.

استخدم نماذج وهمية

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

في Apidog، يمكن أن تأتي النماذج الوهمية من تعريف API نفسه الذي يستخدمه الوكلاء، فلا ينجرف الاختبار عن الواجهة الحقيقية.

سجل كل تسليم

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

ما تقدمه الأطر

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

• يعرّف OpenAI Agents SDK handoff التسليم كأداة يستدعيها الوكيل. هذا مريح، لكنه يضع قرار النقل في جزء غير حتمي من النظام؛ أضف تحققًا عند الخروج.
• تتعامل إرشادات LangGraph للوكلاء المتعددين مع الحالة ككائن رسم بياني صريح تقرأه وتكتبه كل عقدة. يتطابق ذلك مع كائن التسليم المنظم؛ ويبقى عليك تحديد الحقول المطلوبة.
• تستحق كتابة Anthropic حول بناء نظام بحث متعدد الوكلاء القراءة للتفاصيل التشغيلية، خصوصًا مقدار التعليمات الذي يحتاجه الوكيل الفرعي ليعمل باستقلالية مفيدة.

كل إطار سينقل شيئًا، لكن لا إطار يحدد لك الحقائق الأساسية التي يجب ألا تضيع. هذه مسؤوليتك، وهي أول قائمة يجب مراجعتها عند فشل التشغيل.

احتفظ بكائن المهمة خارج المحادثة

احفظ حالة المهمة في مخزن دائم مفهرس بـtask_id. يجب أن يقرأه كل وكيل ويحدّثه بدل تمرير الحالة في الرسائل.

المحادثة ليست مخزن حالة موثوقًا: تُضغط وتُلخص وتُعاد صياغتها، ولا تعرف هذه العمليات الحقول التي لا يمكنك خسارتها. صف في قاعدة بيانات لا يملك هذه المشكلة.

النمط بسيط:

1. عند بداية الدور، يحمّل الوكيل كائن المهمة.
2. عند تنفيذ إجراء، يضيفه إلى actions_taken ويحفظ الكائن.
3. عند التسليم، يمرر task_id.
4. يحمّل الوكيل المستلم الكائن نفسه.

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

حيث يمكن للمنصة الاحتفاظ بالحالة

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

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

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

قائمة مراجعة التسليم

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

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

الأسئلة المتكررة

هل يستحق التسليم المنظم العناء لوكيلين؟

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

هل يجب أن يكتب النموذج كائن التسليم أم ينشئه الكود؟

استخدم الكود حيثما أمكن. يجب أن يملأ المنسق المعرفات والإجراءات والموافقات من الأحداث الفعلية، لا من ذاكرة النموذج. اترك للنموذج summary والأسئلة المفتوحة فقط.

كيف أوقف اضمحلال السياق في حلقة؟

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

ماذا عن الأطر التي تدعم التسليم مدمجًا؟

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

هل يحتاج الوكلاء الفرعيون إلى بيانات اعتماد API منفصلة؟

نعم، ومحددة لنطاق كل وكيل. مشاركة مفتاح قوي واحد تلغي قدرتك على تقليل نطاق الضرر ومعرفة أي وكيل نفذ الاستدعاء. راجع مفاتيح API بأقل امتياز لوكلاء الذكاء الاصطناعي.

كم يجب أن يحتوي حقل الملخص؟

بضع جمل عن النية والتفاصيل الدقيقة التي لا تناسب الحقول المنظمة. إذا بدأ يسرد المعرفات والمبالغ، انقلها إلى حقول منظمة قابلة للتحقق.