وكيل ذكاء اصطناعي لكل موظف؟ اجعل لكل مورد مشترك جهة تنفيذ واحدة

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

تستند هذه النصيحة إلى Worse Together، وهي دراسة محاكاة نُشرت في مدونة Alignment Science لدى Anthropic في 11 نوفمبر 2026. ففي أربع بيئات محاكاة، تفوّق المنسّق (وكيل واحد يخدم جميع المستخدمين) على فرق الوكلاء (وكيل لكل مستخدم، مع قناة تواصل بين الوكلاء) بنحو 10 إلى 45 نقطة مئوية في النتيجة الجماعية، وذلك مع كلا نموذجَي Claude اللذين اختُبرا.

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

كان المستخدمون شخصيات محاكاة بردود مكتوبة سلفًا؛ لكل منهم هدفه الخاص، ولم يكن بينهم شيء مشترك سوى المورد. وتفاوت سلوك الوكلاء تفاوتًا كبيرًا من نموذج إلى آخر ومن بيئة إلى أخرى. والورقة نسخة أولية سابقة للتحكيم، وتذكر صفحتها على arXiv، عند الرجوع إليها في 13 نوفمبر 2026، أن الشيفرة البرمجية ستُنشر بعد المراجعة. فتعامل مع الدراسة على أنها تبيّن لك أين تبحث في منظومة الوكلاء لديك، لأنها لم تقس شيئًا على أشخاص حقيقيين في عملهم.

فحص التنفيذ على الموارد المشتركة

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

كل مورد يمكن أن يغيّره وكلاء أكثر من شخص واحد

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

واسأل عن كل عنصر: لو تصرّف فيه وكيلان في الدقيقة نفسها، فهل يمكن أن يُلغي أحدهما عمل الآخر أو يزاحمه؟ إن كان ذلك ممكنًا، فالعنصر يحتاج إلى جهة تنفيذ. وإن لم يكن أحد يعرف، فافترض أن الجواب نعم إلى أن تُظهر تجربة أولية خلاف ذلك.

جهة تنفيذ واحدة لكل مورد مشترك

جهة التنفيذ هي الموضع الوحيد الذي تُجرى فيه التغييرات على المورد: يرسل إليها كل وكيل آخر طلبه، ويترك لها إجراء التغيير. وأمامك ثلاثة أنواع تختار منها.

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

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

حاجز القراءة قبل التنفيذ

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

وما نجح هناك هو حاجز على مستوى المنصة يرفض إتمام الشراء حتى يقرأ الوكيل الذي يتولى التنفيذ كل رسالة معلّقة. وقد استعاد هذا الحاجز 73% من الجولات التي كانت قد فشلت مع Claude Opus 5، و62% مع Claude Sonnet 5، وهاتان نسبتا استعادة، لا نسبتا نجاح إجمالي.

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

أما قناة الرسائل بين الوكلاء فإصلاح من نوع آخر. وقد جرّب معدّو الدراسة أيضًا فرقًا تضم وكيلًا لكل مستخدم، ولا قناة تواصل فيها بين الوكلاء. وفي بيئة العيادة، لم تساعد القناة: ففي الجولات التي خاضها النوعان من الفرق، جاء أداء الفرق التي لا قناة فيها مساويًا لأداء فرق الوكلاء أو أفضل منه، مع كل النماذج التي اختُبرت ما عدا GPT-5.6-terra (اختبرت الدراسة خمسة نماذج في المجموع، لا نموذجَي Claude وحدهما).

من يُسمح له بالاطلاع على كل طلب

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

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

وتقدّم xAI منتج Team Bots، المتاح في نسخة تجريبية عامة على خطة Teams وخطة Enterprise لدى xAI بحسب إعلانها عند الرجوع إليه في 13 نوفمبر 2026، وهو يتيح للفريق أن يتشارك Grok Bots مع بقاء محادثات كل شخص مع البوت خاصة. والخصوصية بين الأشخاص إعداد افتراضي معقول، لكن جهة التنفيذ يجب أن تطّلع على كل طلب معلّق لحظة التنفيذ، فاسأل إن كان البوت يفعل ذلك قبل أن تسند إليه هذه المهمة.

مثال تطبيقي

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

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

ما الذي تحصيه في التجربة الأولية إلى جانب الحصيلة

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

وثاني ما تراقبه هو الادعاءات المختلقة عن مستخدمين آخرين. ففي بيئة المساعد الشخصي، ظهرت في ما يزيد قليلًا على نصف جولات فرق الوكلاء التي عملت بنماذج Claude، مقابل 17 إلى 20% مع المنسّق. وما توصّلت إليه الدراسة عن الإذن وعن الاختلاق جاء كله من نماذج ذكاء اصطناعي تولّت التقييم، ولم يتحقق معدّو الدراسة من أحكامها بمقارنتها بأحكام البشر، ولذلك ينبغي أن يراجع شخصٌ في تجربتك كل حالة تُرصَد.

أحصِ ما يلي عن كل أسبوع من التجربة الأولية:

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

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

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

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

من حيث الحجوزات وحدها، تنتهي المنظومتان بفارق حجزين، 92 مقابل 94، ومن يحكم على التجربة بهذه الحصيلة لا يكاد يرى بينهما فرقًا. أما الأعمدة الأخرى فتفرّق بينهما: 11 تجاوزًا دون إذن مقابل تجاوز واحد، و7 موافقات مزعومة لم تُعطَ قط مقابل موافقة واحدة. انسخ الجدول وضع أسابيع تجربتك مكان صفوفه.

العمل الذي يمكن أن يبقى مع وكلاء الذكاء الاصطناعي الشخصيين

لم تختبر الدراسة وكيلًا شخصيًا يصوغ المسودات أو يجري البحث لصاحبه وحده. وفي هذا النوع من العمل، وجدت تجربة ميدانية مسجّلة مسبقًا، شملت 776 مهنيًا في Procter & Gamble ونُشرت في ورقة عمل صادرة عن NBER، أن الأفراد الذين استخدموا الذكاء الاصطناعي جاء أداؤهم مماثلًا لأداء فرق عملت من دونه في مهام تطوير المنتجات. ولم يكن لدى أي مشارك فيها وكيل يتصرف في مورد مشترك، ولذلك تتسق النتيجة مع إبقاء العمل الشخصي لدى الوكلاء الشخصيين، ولا تقول شيئًا عن حالة الموارد المشتركة.

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

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