يوجّه System Prompt في Claude Fable 5 نحو عصر الـ Agent Harness

تستحق ملاحظات Claude الرسمية حول system prompts من Anthropic القراءة، ليس لأنها تكشف خدعة سحرية، بل لأنها تُظهر اتجاهًا منتجيًا واضحًا. تنشر الصفحة لقطات مؤرخة من الـ prompts الأساسية المستخدمة في واجهة Claude على الويب (claude.ai) وتطبيقات iOS/Android للجوال. وتوضح Anthropic الحدّ الفاصل صراحةً: هذه التحديثات لا تنطبق على Claude API. هذا التفريق مهم. لا ينبغي التعامل مع الصفحة باعتبارها prompt خاصًا بالـ API، ولا باعتبارها ترخيصًا لنسخ نصوص prompt خاصة أو تحويلها إلى تشغيل مباشر.

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

رسم تحريري لدليل تشغيل يتحول إلى مسارات workflow للوكلاء

الشكل 1: يتجه مسار system prompt من “الإجابة على المستخدم” إلى “التشغيل الآمن داخل منضدة عمل”.

ينبغي استخدام الاسم الرسمي Claude Fable 5. ومعرّف النموذج في API هو claude-fable-5. تتحدث Anthropic أيضًا عن Claude Mythos 5 (claude-mythos-5)، لكن لا ينبغي دمج الاثنين بسهولة. Claude Fable 5 هو النموذج المتاح عمومًا؛ أما Mythos 5 فتوافره مقيّد. في هذه المقالة، ليست النقطة المهمة هي تسويق النموذج. المهم أن أحدث prompt لواجهة دردشة Claude يبدو كإشارة إلى تحول أوسع في الصناعة: يُتوقع من النموذج أن يكون جزءًا من harness.

من مساعد محسّن إلى دليل تشغيل

طريقة مفيدة لقراءة التدرّج من Opus إلى Fable هي اعتباره تطورًا في بيئة التشغيل المتوقعة.

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

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

التحول بين الفعل وطلب التوضيح

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

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

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

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

يمكن لنافذة دردشة أن تعبّر عن هذه السياسة بالكلمات. أما الـ harness فيمكنه فرضها داخل workflow.

التحول نحو اكتشاف الأدوات

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

هذا يغير تعريف “الذكاء”. نموذج يقول “لا أستطيع الوصول إلى الملف” قد يكون محقًا في واجهة ما ومخطئًا في واجهة أخرى. القدرة العملية للنموذج أصبحت الآن مجموع:

1. قدرته على الاستدلال،
2. الأدوات المعروضة له،
3. الصلاحيات الممنوحة لتلك الأدوات،
4. الحالة المحفوظة عبر الخطوات،
5. وسطح Artifact الذي يمكن من خلاله فحص النتائج.

لهذا تهم عبارة agent harness. الـ harness ليس زينة. إنه النظام الذي يمنح النموذج عيونًا وأيديًا وذاكرة وحدودًا وقنوات إخراج. من دونه، حتى النموذج القوي قد يصبح راكبًا فصيحًا على نحو غير عادي داخل صندوق دردشة صغير.

خط زمني مرسوم يدويًا من سلوك مساعد الدردشة إلى دليل تشغيل كامل للوكيل

الشكل 2: يشير تطور الـ prompt من مساعدة أغنى إلى تشغيل منظم: الفعل، واكتشاف الأدوات، وحفظ الحالة، وإنتاج Artifacts.

لماذا لا يقتصر عصر الـ harness على “دردشة أفضل”

التحول الصناعي المهم ليس أن النماذج تستطيع كتابة إجابات أطول. المهم أنها باتت مطالَبة أكثر فأكثر بالمشاركة في حلقات عمل أطول. والحلقة الحقيقية لها حالة ومخاطر.

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

تعاني واجهة دردشة واحدة مع هذا النوع من العمل لأنها تفتقر إلى عدة أشياء يحتاجها العمل:

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

هذه ليست تفاصيل prompt engineering. إنها تفاصيل سطح التشغيل.

كيف يحمل MCPlato هذا الاتجاه

أفضل طريقة لفهم MCPlato هي اعتباره مساحة عمل للذكاء الاصطناعي وسطح تشغيل للوكلاء، لا مجرد صندوق إجابات آخر. مفرداته المنتَجية تتوافق بشكل طبيعي مع الاتجاه الذي تلمّح إليه system prompts الأحدث في Claude.

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

Wand هو workflow مغلف وذو حالة. بدل أن يُطلب من الذكاء الاصطناعي ارتجال العملية نفسها في كل مرة، يستطيع Wand تعريف المراحل والبوابات والموارد محددة النطاق والـ Artifacts المتوقعة. النتيجة أقرب إلى تطبيق عمل قابل للتكرار من كونها قالب prompt.

Artifact هو نقطة النهاية الدائمة. لا ينبغي أن تُحبس المخرجات في جدار من نص الدردشة. يجب أن تصبح تقريرًا أو patch أو عرضًا تقديميًا أو جدولًا أو مجلدًا أو مذكرة قرار أو سجل QA أو كائنًا آخر قابلًا للفحص.

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

ClawMode و Scheduled Tasks يمددان العمل عبر الزمن. بعض المهام القيّمة ليست فورية: موجز بحث أسبوعي، فحص ليلي لمستودع، pipeline محتوى متكرر، أو متابعة عند ظهور معلومات جديدة.

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

Channels و IM bridges تجعل التفاعل غير متزامن. يجب أن يتمكن المستخدم من تفويض مهمة من دردشة فريق، وتلقي تحديثات تقدم، ومراجعة Artifact النهائي دون مراقبة نافذة دردشة في الواجهة.

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

باختصار، يمنح MCPlato النماذج نوع البيئة الذي تفترضه تعليماتها التشغيلية الأحدث بشكل متزايد: أدوات، وملفات، وذاكرة، وصلاحيات، ومراحل، وArtifacts، ونقاط تفتيش بشرية.

رسم تحريري مسطح لـ workspace harness يحتوي على Artifacts وجداول وموافقات ومسارات جلسات

الشكل 3: يحوّل الـ harness قدرة النموذج إلى حلقات عمل قابلة للملاحظة، قائمة على الصلاحيات، ومتمحورة حول Artifacts.

أربعة أمثلة ملموسة

1. من issue برمجية إلى patch ثم QA Artifact

يضع مستخدم issue من GitHub داخل MCPlato ويطلب إصلاحًا. في تدفق قائم على الدردشة فقط، قد يقفز المساعد مباشرة إلى الاقتراحات. في تدفق قائم على harness، تصبح المهمة عملًا مرحليًا:

1. قراءة الـ issue وسياق المستودع،
2. صياغة خطة محدودة النطاق،
3. السؤال قبل التعديل إذا كان التغيير عالي المخاطر،
4. إنشاء الـ patch،
5. تشغيل الفحوصات المتفق عليها،
6. إنتاج QA Artifact يتضمن الملفات المتغيرة ومخرجات الاختبارات والمخاطر غير المحلولة وملاحظات المراجعة.

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

2. موجز بحث مجدول مع استشهادات

الموجز البحثي الأسبوعي ليس إجابة لمرة واحدة. إنه حلقة متكررة: جمع مصادر معتمدة، إزالة التكرار، المقارنة مع الأسبوع السابق، تلخيص التغييرات، الاستشهاد بكل ادعاء محدد، وتسليم التقرير. تجعل Scheduled Tasks وArtifacts في MCPlato المخرجات دائمة؛ وتجعل channels التسليم غير متزامن؛ وتجعل Skills التنسيق قابلًا لإعادة الاستخدام.

تصبح تعليمات الاستشهاد بالمصادر على مستوى الـ prompt أكثر قيمة عندما تستطيع مساحة العمل حفظ قائمة المصادر وArtifact الموجز معًا.

3. Workflow للمتصفح والمستندات

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

هذا هو الفرق بين “يمكن للذكاء الاصطناعي استخدام متصفح” و“يمكن للذكاء الاصطناعي العمل داخل حلقة متحكم بها من المتصفح والمستندات”.

4. الموافقة على إجراء عالي المخاطر

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

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

ماذا يعني ذلك للبناة

بالنسبة إلى بناة منتجات الذكاء الاصطناعي، تمثل ملاحظات Claude حول system prompts إشارة تصميم مفيدة. لا تسألوا فقط: “أي نموذج هو الأذكى؟” بل اسألوا أيضًا:

• في أي بيئة يعتقد النموذج أنه يعمل؟
• هل يستطيع المنتج كشف الأدوات دون طمس الصلاحيات؟
• هل يستطيع workflow الاستمرار عبر الزمن دون فقدان الحالة؟
• هل يستطيع المستخدم فحص ما حدث؟
• هل يمكن أن تعيش النتيجة النهائية كـ Artifact لا كنص محادثة؟
• هل يستطيع النظام التوقف في اللحظات الصحيحة بدل أن يسأل كثيرًا أو يتصرف بحرية مفرطة؟

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

هذا هو عصر الـ harness: تصبح النماذج أكثر قدرة، لكن القدرة لا تصبح مفيدة إلا عندما تُحاط بالحالة والأدوات والتعافي والموافقات وArtifacts.

الخلاصة

لقطة system prompt في Claude Fable 5 مثيرة للاهتمام لأنها تشير إلى ما بعد قدرة النموذج. إنها تُظهر شكل البيئة التي تُحضَّر النماذج الحديثة للعيش فيها. لم تعد الجبهة مجرد “دردشة أفضل”. إنها عمل وكلاء: ذو حالة، واعٍ بالأدوات، مضبوط بالصلاحيات، منتبه للاستشهادات، قابل للتعافي، ومتمحور حول Artifacts.

بُني MCPlato لهذا الاتجاه. تنسيق Sprite، وWands، وArtifacts، وSkills القابلة لإعادة الاستخدام، والعمل المجدول، وchannels، وحالة workspace المحلية أولًا، وبوابات الموافقة ليست زينة حول نموذج. إنها سطح التشغيل الذي يسمح لنموذج قوي بأن يصبح مشاركًا مفيدًا في العمل الحقيقي.

لا يزال النموذج هو المحرك. أما الـ harness فهو ما يحوّل المحرك إلى مركبة يستطيع الناس قيادتها وفحصها وإصلاحها والثقة بها.

المراجع

1. Anthropic docs, System Prompts release notes.
2. Anthropic docs, Introducing Claude Fable 5 and Claude Mythos 5.