أصبح بإمكان ChatGPT الآن متابعة لوحة مشروعك: ما تحتاجه الوكلاء الموجهة بالأحداث في الخطوة القادمة

لخصت شركة OpenAI الأمر بعبارة واضحة في تقرير DevDay الموجز بتاريخ 29 سبتمبر: "يمكنك مطالبة ChatGPT بمراقبة المهام الجديدة على لوحة المشروع. وعندما تصل مهمة جديدة، يستطيع ChatGPT قراءة المستندات المرتبطة وصياغة مسودة خطة، حتى أثناء غيابك". يكمن وراء ذلك دعم ChatGPT للمواصفة المقترحة MCP Events على جميع الخطط، والتي طُرحت إلى جانب ميزتين للفرق: مهام الفريق التي تعمل وفق جدول زمني أو استجابة للأحداث، وميزة ChatGPT@ في Slack وTeams.

بالنسبة لفريق يستخدم بالفعل وكلاء برمجة، فإن وجود لوحة يراقبها الوكلاء يغير مفهوم المهمة الجديدة جذرياً؛ إذ كانت تنتظر في السابق تدخلاً بشرياً، بينما يمكنها الآن تنشيط وكيل واحد أو عدة وكلاء. وإذا طلب شخصان من ChatGPT مراقبة اللوحة نفسها، وكانت اللوحة نفسها تحتوي على وكيل (Agent) مخصص للأعمال الجديدة، فقد تؤدي مهمة جديدة واحدة إلى إنشاء ثلاث مسودات خطط في ثلاثة أماكن مختلفة، دون أن يحدد أحد أيها المعتمدة.

ملخص سريع

توفر MCP Events لـ ChatGPT وسيلة نظيفة وموقّعة رقمياً لتلقي إشعارات بالتغييرات في أي تطبيق متصل، في حين تتيح مهام فريق ChatGPT إمكانية تنفيذ الأعمال المجدولة والموجهة بالأحداث في خطتي Business وEnterprise. إن استخدام حدث لإطلاق وكيل هو النصف السهل من المعادلة، وقد أنجزته OpenAI بعناية فائقة. أما النصف الصعب فهو ما ينتجه هذا الحدث على اللوحة: من يملك العمل الناتج، وأين تستقر مسودة الخطة، وكيف تتم مراجعتها، وكيف نضمن ألا يستجيب وكيلان للحدث نفسه. يمكن صياغة ذلك في صورة قاعدة توجيه: نوع حدث واحد، مسؤول واحد، خطط تعود إلى المهمة نفسها، وتأكيد بشري بالقبول قبل اعتماد أي شيء كمكتمل.

ما تم إطلاقه في مؤتمر DevDay

تُعد MCP Events امتداداً مقترحاً لبروتوكول Model Context Protocol يتيح لخادم MCP إشعار ChatGPT بوقوع حدث ما في تطبيق متصل، بحيث يمكن لأي ملحق (Plugin) بدء أتمتة استجابةً لذلك. يوضح دليل MCP Events من OpenAI جانب الخادم؛ حيث يعلن الخادم عن دعمه للأحداث ويطبق ثلاث طرق برمجية: events/list وevents/subscribe وevents/unsubscribe. ويدعم ChatGPT تسليم الأحداث عبر webhook فقط، مع التوقيع بواسطة Standard Webhooks HMAC بعد اجتياز تحقق عبر HTTPS، بمعدل حدث واحد لكل طلب وبحجم أقصاه 256 KiB. وبحسب تعبير الدليل: "عندما يصل الحدث، يتلقاه ChatGPT في المحادثة المشتركة وينفذ تعليمات المستخدم حول كيفية الاستجابة له".

وقد روعيت الدقة التامة في التفاصيل الجوهرية؛ إذ يجب على الخادم تعيين معرّف فريد (unique ID) لكل حدث يظل ثابتاً حتى مع تكرار المحاولات (retries). كما يجب أن تكون الاشتراكات حيادية الأثر (idempotent)، بحيث يُشتق معرّف الاشتراك من الجهة الطالبة، ورابط الرد (callback URL)، واسم الحدث، والوسائط؛ مما يعني أن إعادة الاشتراك تُحدّث الاشتراك الحالي بدلاً من إنشاء اشتراك مكرر. وفضلاً عن ذلك، يتعين على الخادم حظر عناوين الاستدعاء الخاصة والمحلية وعدم تتبع عمليات إعادة التوجيه.

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

المُشغّل هو النصف السهل

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

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

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

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

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

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

ضع قواعد التوجيه على اللوحة مباشرة

على أي لوحة يُعيّن فيها الوكلاء كمكلفين بالمهام (Assignees)، يتحول مفهوم "مراقبة المهام الجديدة" عملياً إلى "إسناد المهمة". ففي منصة Sharkly، تبدأ المهمة المسندة إلى وكيل (Agent) في التنفيذ بمجرد خروجها من قائمة المهام المؤجلة (Backlog) وجاهزية بيئة التشغيل والحاسوب المخصصين لها. ولا يتسع حقل التنفيذ إلا لوكيل واحد (Agent) أو فريق واحد (Crew)، كما تدمج Sharkly الأعمال المعلقة لمنع التعليقات المتتالية من إنشاء عمليات تشغيل معلقة ومكررة لنفس الوكيل والمهمة. وبذلك تصبح المسؤولية حقلاً محدداً وليست مجرد عرف متفق عليه.

أما بالنسبة للأحداث التي يُفترض أن تطلق عملاً دون إسناد مسبق، فإن أتمتات Sharkly تمثل المكافئ المباشر لها على اللوحة. تتكون الأتمتة من قاعدة واحدة تشمل: التعليمات، والوكيل أو الفريق المنفذ، ومُشغّلاً واحداً أو أكثر، وسجل التشغيل، مع حالة نشطة (Active) أو متوقفة مؤقتاً (Paused). وتتنوع مشغّلاتها بين الجدول الزمني (cron بنطاق زمني محدد)، أو انتقال المهمة إلى حالة معينة، أو ورود تعليق يحتوي على عبارة محددة، أو webhook من خدمة خارجية، بالإضافة إلى خيار "التشغيل الآن" لأغراض الاختبار. تبدأ كل عملية تشغيل مباشرة وتُحفظ سجلاتها في الأتمتة نفسها، لذا ينبغي أن توضح التعليمات بدقة أين تُسجل النتائج. ونظراً لأن مطابقة الحالات والتعليقات تعمل على مستوى المؤسسة بالكامل حالياً، فإن توثيق الأتمتة يوصي بتضمين تعليمات تتحقق من المهمة المشغّلة قبل اتخاذ أي إجراء.

يوضح الجدول التالي آلية ربط الأحداث بالمهام في إحدى المساحات (Spaces):

وهذه هي القاعدة الأساسية الضابطة لهذه الآلية، مكتوبة بوضوح ليتسنى للفريق مراجعتها ومناقشتها:

Routing rule: new work in the ENG Space

1. One event type, one owner. Each event maps to exactly one
   Automation or one Agent Assignee. Personal watchers (a chat
   subscription, a dot) may read the board; they do not plan on it.
2. New requests enter Triage. A person accepts before any Agent runs.
3. Accepted work that needs a plan moves to "Needs plan", a status in
   the Backlog category. The "Draft plan" Automation runs the Planner
   Agent, which first checks the Task's Space and type and stops if
   the Task is not ours.
4. The plan returns to the Task as a comment. The Planner does not
   change status and does not assign anyone.
5. The Task's human assignee reads the plan, assigns the executing
   Agent, and moves the Task to Todo. That move starts the run.
6. Done means a person accepted the result. No Agent moves a Task
   into a Completed status.

إن إدراج حالة "Needs plan" ضمن فئة المهام المؤجلة (Backlog) هو التفصيل الدقيق الذي يضمن سلامة الخطوة الخامسة؛ فالمهمة المسندة في مرحلة Backlog تظل في وضع الانتظار، مما يتيح قراءة الخطة قبل بدء التنفيذ الفعلي. احرص على أن توضح في تعليمات وكيل التخطيط المكان المحدد لتسليم الخطة، واختبرها عبر خيار "التشغيل الآن" قبل الاعتماد الكامل على المُشغّل التلقائي. وعندما يحتاج الوكيل إلى قرار أثناء سير العمل، تُظهر المهمة أنها بانتظار رد بشري وتصل إلى صندوق الوارد الخاص بالشخص المسؤول؛ وهنا تماماً تعود عبارة "حتى أثناء غيابك" لتتطلب متابعة بشرية. فالمهمة هي المكان الذي يتحول فيه طلب المحادثة الجماعية إلى عمل برمجي قابل للتتبع، وينطبق الأمر ذاته على إسناد مسألة GitHub إلى وكيل ذكاء اصطناعي.

الموضع المناسب لمراقب ChatGPT

استخدم اشتراك MCP Events عندما يرغب شخص واحد في تلقي تنبيهات ومسودة أولية في محادثته الخاصة: مثل متابعة لوحة لا تديرها، أو متتبع مهام خاص بجهة شريكة، أو ملخص أسبوعي ليوم الجمعة لنفسك. واستخدم مهام الفريق (Team tasks) عندما يكون العمل المتكرر عبارة عن تقرير تحديث دوري للفريق يعتمد على ChatGPT ويكون فريقك مسجلاً في خطة Business أو Enterprise؛ حيث يتعاون الزملاء معاً في تحسين مجموعة واحدة من التعليمات بدلاً من أن يكتب كل شخص تعليماته بشكل منفصل. واستعن بالقواعد المحددة على اللوحة عندما ينتج عن الحدث عمل يتعين على الفريق بالكامل تبنيه وإدارته: كخطة سيتولى أحد تنفيذها، أو تعديل سيقوم شخص بمراجعته، أو مهمة لا بد أن تُدرج ضمن تقرير إنجازات يوم الإثنين.

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

وإذا كنت تدير بالفعل عدة وكلاء، فإن Sharkly تمنحك مكاناً موحداً لإدارة مهامهم ومتابعة نتائج أعمالهم.

مصادر إضافية

• أتمتات Sharkly: أنواع المشغلات الأربعة، وسجل التشغيل، وحدود الأتمتة
• من المحادثة الجماعية إلى مهام برمجية قابلة للتتبع: تحويل الرسائل إلى مهام محددة المسؤولية
• إدارة قائمة المهام المتراكمة وفرزها بواسطة الذكاء الاصطناعي: تحديد ما سيعمل عليه الوكلاء في الخطوة التالية
• إسناد مسألة GitHub إلى وكيل ذكاء اصطناعي: من المسألة البرمجية إلى طلب سحب قابل للمراجعة
• وكلاء البرمجة أثناء غيابك: التشغيل المستقل دون إشراف وقائمة المراجعة
• شرح OpenAI Dots: وكلاء شخصيون يعملون باستمرار، وما يحتاجه الفريق لدعمهم