البشر والوكلاء في مشروع واحد: لماذا يفشل نموذج تطبيقات الدردشة

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

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

التعاون البشري نشأ حول قيدين بشريين

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

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

ما الذي يتغير حين ينضم الوكلاء

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

ثلاث نقاط قوة

سعة عالية وقدرة تنفيذ قوية. ويصدق هذا خصوصًا على المهام ذات الأهداف الواضحة القابلة للقياس. كما أن المهام التي يستطيع الوكلاء إنجازها تزداد طولًا وصعوبةً وتعقيدًا بسرعة. ففي وصفها لوكيل البرمجة الخاص بها، تذكر Meta مهمة لتحسين نواة GPU عمل فيها الوكيل لمدة تصل إلى 24 ساعة، وأجرى أكثر من 1,000 استدعاء للأدوات (Meta). وفي أكتوبر 2026، نشر Linus Torvalds سلسلة تصحيحات لنواة Linux كتب Claude Code شيفرتها وبرامج اختبارها والمسودة الأولى لرسالة الإيداع الخاصة بها؛ أما القياسات فأجراها بنفسه على جهازه (LWN).

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

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

ثلاث نقاط ضعف

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

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

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

لماذا لا تناسب تطبيقات الدردشة

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

أما بالنسبة إلى الوكلاء، فهذا الشكل لا يناسبهم:

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

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

ما يفعله Orkas: نُبقي ما لم يتغير، ونعيد تصميم ما تغيّر

نهجنا أن نُبقي على أجزاء التعاون التي لم تتغير، وأن نعيد تصميم الأجزاء التي تغيرت. في الصورة أدناه مشروع مشترك في Orkas؛ والأفكار الأربع تقابل المناطق الأربع المميَّزة فيه.

1. إسناد العمل وتسليمه ومراجعته: «المهام المطلوبة»

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

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

2. مشاركة الأهداف والخلفية والسياق: «الأهداف والقواعد» و«الذاكرة»

هنا يتشارك البشر والوكلاء السياق نفسه، فتبقى الحقائق الأساسية موحّدة لدى الجميع.

«الأهداف والقواعد» و«الذاكرة» في المشروع مشتركة بين كل محادثة في هذا المشروع، ويلتزم بها الوكلاء في كل مرة. على سبيل المثال، ضع في «الأهداف والقواعد» تعريف مؤشر مثل «الاحتفاظ الشهري = المستخدمون الجدد الذين يعودون في الشهر التالي»، وسجّل القرارات الأساسية في ذاكرة المشروع. وحين ينضم عضو جديد مع وكلائه، يقرؤون الشيء نفسه تمامًا منذ اليوم الأول.

3. التسليم عبر الملفات، مع إبقاء العملية منفصلة

تتزامن «المكتبة» الخاصة بالمشروع بين الأعضاء، ويمكن أن تحمل المهمة المطلوبة أي ملف كمرفق. يُسلَّم العمل في صورة ملفات، لا في صورة سجل محادثات.

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

4. مشاركة الوكلاء الخاصين مع الفريق

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

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

مشكلة مبكرة ومفتوحة

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

بعض النماذج تستطيع ذلك بالفعل من تلقاء نفسها: تشغيل عدة وكلاء فرعيين بالتوازي لاستكشاف مشكلة من زوايا مختلفة، أو التخطيط أولًا ثم إرسال وكلاء فرعيين لتنفيذ الخطة. ويوصف Muse Spark Open، الذي أصدرته Meta بأوزان مفتوحة في أكتوبر 2026، بأنه مدرَّب على تقسيم العمل وتسليمه إلى وكلاء فرعيين والتنسيق بينهم (مدونة PyTorch).

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

في الختام

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

ما زلنا نستكشف هذا الطريق، ويسعدنا أن نتبادل التجارب. إن كنت تدير فريقًا يعمل فيه البشر والوكلاء معًا، فجرّبه أولًا على مشروع واحد. يمكنك تنزيل Orkas مجانًا على macOS وWindows.