داخل SHARP Agent Protocol v2: برومبت من 22 كيلوبايت يدير الوكلاء كفريق هندسي
SHARP Agent Protocol v2 مجموعة تعليمات من 488 سطرًا تحوّل نموذجًا لغويًا واحدًا إلى فريق هندسي مُدار: مهمة واحدة بالضبط لكل وكيل فرعي جديد، واختبارات خصومة قبل أي كود، وتحقق مستقل، وملفات ذاكرة دائمة تنجو من فقدان السياق. ماذا يفعل، وكيف تستخدمه، وأين تتجاوز ادعاءاته الدليل.
انضم اليوم إلى قسم البرومبتات في هذا الموقع إدخال جديد: برومبت LLM Sharp Reasoning، وعنوانه الرسمي SHARP Agent Protocol v2 - Multi-Agent Execution, Adversarial Verification and Memory Context Boost. عند 488 سطرًا ونحو 22 كيلوبايت، ليس هذا برومبتًا تلصقه للحصول على بريد إلكتروني أفضل. إنه دليل تشغيل يحاول تحويل نموذج لغوي واحد إلى فريق هندسي مُدار: مدير يخطط، ووكلاء فرعيون جدد ينفذ كل منهم مهمة واحدة بالضبط، ومختبِر خصم يكتب حالات الفشل قبل وجود أي كود، ومجموعة من ملفات الذاكرة الدائمة التي تنجو من انتهاء المحادثة. قرأت النص كاملًا بعناية. هذه التدوينة هي خريطتي لما يفعله، والأفكار التي تستحق الاستعارة، والأماكن التي تتجاوز فيها وعوده ما يمكن لبرومبت أن يضمنه فعلًا.
النسخة المختصرة
SHARP بروتوكول بأسلوب البرومبت النظامي من ثلاثة أجزاء. يعرّف الجزء الأول حلقة تنفيذ تكيفية - triage وplan وideate وtest-spec وwork وverify وmanage - يفوّض فيها وكيل مدير مهمة واحدة بالضبط لكل وكيل فرعي جديد ثم يتحقق من النتيجة بشكل مستقل مقابل معايير قبول صريحة. الجزء الثاني انضباط ذاكرة: ملفات دائمة بأسماء افتراضية مثل AGENTS.md وTASKS.md وDECISIONS.md وHANDOFF.md وVERIFICATION.md، وتسلسل هرمي للاسترجاع، ونقاط تفتيش، وإجراء استرداد إلزامي بعد فقدان السياق. الجزء الثالث يربط كل شيء في حلقة واحدة بصيغة تقرير نهائي صارمة (Done وVerified وNot verified وRisks وResume state). ادعاءاته الجوهرية - الخطط ليست تنفيذًا، والتنفيذ ليس برهانًا، وتاريخ المحادثة ليس ذاكرة - ثقافة هندسية رصينة مضغوطة في تعليمات. التكاليف حقيقية: إنفاق كبير للرموز على المراسم، وافتراضات عن ميزات منصة تفتقر إليها كثير من الإعدادات، ولا يوجد تقييم منشور، فالفوائد مُبرَّرة لا مقاسة. النص الكامل منشور حرفيًا في قسم البرومبتات، والرابط أدناه.
ما هذا البرومبت فعلًا
يصل SHARP ككتلة تعليمات واحدة معدّة للتثبيت كبرومبت نظامي أو مجموعة تعليمات دائمة لوكيل برمجة أو هندسة. يفتتح ببيان مهمة - اعمل كوكيل هندسي منضبط يصحح نفسه - وقائمة من سبعة مبادئ جوهرية تقرأ كوثيقة ثقافة مراجعة كود: الخطط ليست تنفيذًا؛ التنفيذ ليس برهان صحة؛ تاريخ المحادثة ليس ذاكرة دائمة؛ الملخصات ليست الحقيقة المرجعية؛ الوكلاء الفرعيون مساهمون لا سلطات؛ المهمة غير مكتملة حتى تُتحقق معايير قبولها الإلزامية؛ ولا تدّعِ أبدًا قدرات أو أفعالًا أو نتائج اختبارات أو نجاحًا لا يمكنك إثباته. المتن تسعة عشر قسمًا مرقمًا في ثلاثة أجزاء، تنتهي بقاعدة تنفيذ نهائية: لا تختلق التقدم أبدًا. النص لا يسمي مؤلفًا ولا يحمل أي أصل سوى v2 في عنوانه، مما يوحي على الأقل بوجود تكرار وتطوير. لا أدّعي شيئًا عن مصدره؛ ما يلي تحليل للنص نفسه المنشور حرفيًا على هذا الموقع.
الجزء الأول: حلقة هندسية لا دردشة
يعرّف الجزء الأول سبع مراحل. TRIAGE يقدّر المهمة ويختار واحدًا من ثلاثة مستويات صرامة - تافه أو قياسي أو معقد - مع تحذير صريح بأن الفرز يحدد مقدار العمل لا إذنًا بتخطي الفحوصات الإلزامية. PLAN يجعل المدير يكتب استراتيجية قصيرة، وثلاث إلى ست مهام ملموسة موسومة بالصعوبة، ومعايير قبول لكل منها، والأدلة التي ستثبت النجاح. IDEATE يرسل المشكلة إلى وكيل فرعي جديد لم يرَ العمل الحالي، ويشترط ثلاثة مقاربات مختلفة فعلًا مع أنماط فشلها، ويحظر كود التنفيذ في هذه المرحلة. TEST-SPEC هي المرحلة غير المعتادة: قبل بدء التنفيذ، يكتب وكيل فرعي خصم جديد اختبارات مصممة لاكتشاف كيف يمكن للحل المقترح أن يفشل - مدخلات حدية، وتسابقات، ومخاطر حقن، وتراجعات - وتُحفظ تلك الاختبارات لمرحلة التحقق. WORK يسلّم مهمة واحدة بالضبط لكل وكيل فرعي منفّذ جديد مع إحاطة منضبطة، ويحظر تضخم النطاق، ويشترط مرور هجوم ذاتي يسمي ثلاثة أنماط فشل محتملة على الأقل. VERIFY يعيد المسؤولية إلى المدير: عليه فعلًا تشغيل التنفيذ والاختبارات الخصومة، وقواعد الدليل صريحة - لا تدّعِ أبدًا أن اختبارًا نجح ما لم يعمل وينجح فعلًا، لا تخفِ أبدًا فحوصات متخطاة، ومعيار إلزامي فاشل يلغي كل ادعاء سابق بالاكتمال. MANAGE تغلق الحلقة بتصنيف إشارة مرور (أخضر، أصفر، أحمر) وإجراء استرداد يتراجع، أو يسابق البدائل بالتوازي، أو يبدّل المقاربة بدل الترقيع اللانهائي.
الجزء الثاني: الذاكرة كمكوّن من الدرجة الأولى
يتعامل الجزء الثاني مع إنهاك نافذة السياق وإعادة تشغيل الجلسات والضغط كظروف تشغيل متوقعة لا حالات حدية. قاعدته المركزية: المعرفة الحرجة يجب أن تكون قابلة للاسترداد من حالة دائمة، لا من تاريخ المحادثة. يصف خمسة ملفات افتراضية - AGENTS.md لتعليمات المشروع الدائمة، وTASKS.md لحالة التنفيذ، وDECISIONS.md لتاريخ القرارات مع البدائل المرفوضة، وHANDOFF.md كنقطة استئناف، وVERIFICATION.md كسجل أدلة للفحوصات المنفذة فعلًا - مع التشديد على أن الأسماء افتراضية ويجب إعادة استخدام سجلات المشروع القائمة. حول هذه الملفات يبني تسلسلًا هرميًا للاسترجاع (التعليمات الحالية ووثائق المستودع فوق الذاكرة، والذاكرة فوق ملخصات المحادثات)، وقواعد لتحديث السجلات عند المعالم ذات الدلالة، وإدارة ميزانية السياق بحفظ نقاط تفتيش الاسترداد قبل ضغط محتمل، وافتراضًا صارمًا بأن كل وكيل فرعي جديد يبدأ بلا ذاكرة ضمنية، فيجب أن تكون إحاطات التسليم كاملة. قسمان يبرزان. CONTEXT RECOVERY إجراء إلزامي من تسع خطوات بعد أي انقطاع: أعد قراءة السجلات، افحص الحالة الفعلية للمستودع، تحقق من أن التغييرات المدّعاة سابقًا موجودة فعلًا، واستأنف من أقدم تبعية غير محلولة - دون الثقة أبدًا بملخص يناقض الحالة الملاحظة. أما RESUMABILITY TEST فيسأل عن أي عمل جوهري غير منتهٍ: هل يمكن لوكيل جديد أن يواصل من السجلات الدائمة وحدها؛ إن لم تستطع السجلات الإجابة عما يريده المستخدم وما تم التحقق منه وما الخطوة التالية، فيجب تحسينها قبل انتهاء الجلسة.
الجزء الثالث: حلقة واحدة وصيغة تقرير واحدة
يضغط الجزء الأخير كل شيء في خط واحد - من triage إلى plan إلى ideate إلى test-spec إلى work إلى verify إلى manage إلى تحديث الذاكرة إلى المهمة التالية - مع استرجاع الذاكرة طوال الطريق. القسم الختامي يعرّف صيغة رد نهائي يسعدني أن أراها معتمدة في كل مكان: أبلغ عما أُنجز، وما تم التحقق منه مع النتائج الملاحظة، وما لم يتم التحقق منه، والمخاطر، وحالة الاستئناف للعمل غير المنتهي. ويحظر أيضًا ادعاء حفظ الذاكرة ما لم تنجح الكتابة فعلًا، وادعاء أن مهمة قابلة للاستئناف ما لم توجد السجلات. السطر الأخير هو الفلسفة كلها في جملة واحدة: التنفيذ الفعلي والتحقق المنفذ هما ما يثبت الحقيقة.
ما يصيب فيه
يقرأ البروتوكول كقائمة بأنماط فشل الوكلاء الملاحظة ومع كل واحد تدبير مضاد. النجاح المتوهَّم يحصل على قواعد الدليل. تضخم النطاق يحصل على قاعدة المهمة الواحدة بالضبط. فقدان السياق يحصل على ملفات الذاكرة وإجراء الاسترداد. الوكلاء الفرعيون المتملقون يحصلون على سطر مفاده أن كود الوكيل الفرعي وادعاءاته غير موثوقة حتى تُفحص. تصميم السياق الجديد لكل مهمة يعكس كيف تتصرف أطر التنسيق الجادة فعلًا، وكتابة اختبارات خصومة قبل التنفيذ هي تفكير الفريق الأحمر مطبقًا في أرخص لحظة ممكنة. يعجبني أيضًا قيود الصدق التي تتخطاها معظم البرومبتات: أفصح عندما تكون قدرة مطلوبة غير متاحة، ولا تحاكي الامتثال أبدًا، ولا تخفض مستوى مهمة للتهرب من فحوصات إلزامية. وسواء تبنيت البروتوكول كله أم لا، فإن عادة VERIFICATION.md - سجل جارٍ للأوامر المنفذة والنتائج الملاحظة - تستحق السرقة وحدها.
كيف تستخدمه
الصق النص الكامل كبرومبت نظامي أو تعليمات دائمة لمنصة وكلاء تدعم فعلًا الوكلاء الفرعيين والملفات الدائمة؛ هذه هي الفئة التي يفترضها البروتوكول. على إعداد أخف، يمنحك قسم الفرز إذنًا بتشغيل نسخة مخففة: المهام التافهة تحصل على تنفيذ مباشر بفحوصات متناسبة، ولا تنطلق المراسم الكاملة متعددة الوكلاء إلا على العمل المعقد. كيّف أسماء ملفات الذاكرة مع ما يستخدمه مشروعك أصلًا بدل إنشاء وثائق موازية - النص يسمح بذلك صراحة. توقع ارتفاعًا حادًا في استهلاك الرموز على المهام الصعبة، لأن توليد الأفكار وكتابة الاختبارات الخصومة والتحقق المستقل كلها استدعاءات نموذج إضافية بالتصميم. واحتفظ بصيغة التقرير النهائي حتى لو لم تحتفظ بشيء آخر؛ فهي تُخرج الفرق بين منجز ومُتحقق منه ومفترض إلى العلن.
حدود صادقة
عدة حدود، وربما أصرّ البرومبت نفسه على أن أعددها. أولًا، لا يوجد تقييم منشور: لا شيء في النص أو في أي مكان آخر يثبت أن الوكلاء المتبعين لـSHARP ينتجون عيوبًا أقل قياسًا من مجموعات تعليمات أبسط، فكل فائدة هنا مُبرَّرة من البنية لا من الدليل. ثانيًا، يفترض البروتوكول ميزات منصة - وكلاء فرعيون جدد قابلون للإنشاء، وملفات دائمة، واسترجاع، وقياس استهلاك السياق - تفتقر إليها كثير من عمليات النشر ببساطة، وقد يحاكي النموذج على منصة أدنى المراسم بدل تخطيها بصدق. ثالثًا، 22 كيلوبايت من التعليمات هي نفسها ضريبة سياق تنافس الميزانية ذاتها التي تحاول أقسام الذاكرة حمايتها. رابعًا، البرومبت يقيّد السلوك؛ لا يمكنه ضمانه. قد يكتب النموذج "كل الاختبارات نجحت" عن اختبارات لم تعمل قط - يستطيع البروتوكول أن يحرّم الكذبة لكنه لا يستطيع منعها، ولهذا تهم عادة التحقق لدى المدير أكثر من أي قاعدة مفردة. أخيرًا، للمراسم ثمن على المهام الصغيرة حتى مع الفرز، والفرق التي تشغّل CI ومراجعة كود منضبطين أصلًا ستجد أجزاء منه زائدة بجانب أدوات تفرض القواعد ذاتها آليًا لا بالطلب المهذب.
أين تقرأ النص الكامل
البروتوكول الكامل منشور حرفيًا - كل الـ488 سطرًا - في قسم البرومبتات في هذا الموقع باسم LLM Sharp Reasoning Prompt، مع الصفحة المحيطة بست لغات. إن كنت تدير سير عمل برمجة متعدد الوكلاء، فهو يستحق عشرين دقيقة من القراءة حتى لو احتفظت بثلاث أفكار فقط: مهمة واحدة لكل وكيل فرعي جديد، واختبارات خصومة قبل الكود، وسجل تحقق يدوّن ما عمل فعلًا.