تصميم وتحسين وصيانة مهارات الوكيل في Perplexity

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

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

على سبيل المثال، إذا أخذت بعض الحكم من PEP20 – The Zen of Python, يصبح من الواضح سريعاً أن كتابة كود Python جيد تختلف عن كتابة مهارات جيدة. من بين 20 سطراً من الحكمة، فإن نصفها على الأقل خاطئ تماماً أو مضلل نشطاً عند كتابة المهارات. إليك خمسة منها:

خمسة أوجه تباين بين Zen of Python والإرشادات الواردة في المقالة لكتابة المهارات.

هذا الدليل هو المستند الذي يستخدمه المهندسون في جميع أنحاء Perplexity عند تطوير ومراجعة المهارات. كما أننا ننشر هذا الدليل للجمهور لكي تستفيد المجتمع الأوسع من اكتشافاتنا وتعلمنا. سواء كنت مهندساً تصمم مهارات إنتاجية في عملك اليومي، أو مستخدماً لـ Computer تتطلع إلى تطوير مهارتك الخاصة في مجال تعرفه جيداً، أو كليهما، فهذا الدليل مناسب لك.

ما هي المهارة؟

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

المهارة هي أربعة أشياء على الأقل، خاصة في سياق كيفية بنائها في Perplexity.

المهارة هي دليل (مجلد)

المهارة ليست مجرد ملف SKILL.md واحد. في كثير من الحالات، تتضمن المهارة عدة ملفات. تحت الدليل المسماة باسم مهارتك، قد يكون لديك:

SKILL.md: البيانات الوصفية (frontmatter) والتعليمات

scripts/: الكود الذي يشغله الوكيل، وليس يعيد اختراعه

references/: مستندات ثقيلة، يتم تحميلها مشروطاً

assets/: قوالب، مخططات، وبيانات

config.json: إعداد المستخدم للاستخدام الأول

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

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

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

تكبير

المهارة هي تنسيق

المهارة هي تنسيق. يجب أن يحتوي ملف الجذور الأساسي SKILL.md على اسم ووصف. علاوة على ذلك، تحتاج المهارة إلى المطابقة التامة لاسم الدليل الذي توجد فيه المهارة. يجب أن يكون الاسم مكوناً من حروف صغيرة بالكامل، وألا يحتوي على مسافات، ويمكنه استخدام الشرطات. الوصف هو مشغل التوجيه. هذه نقطة فشل شائعة: الوصف ليس وثائق داخلية لما تفعله المهارة. إنه يعادل تعليمات للنموذج حول متى يتم تحميل المهارة. لذلك، سترى بشكل متكرر "Load when" (تحميل عندما)، وليست "This Skill does" (تقوم هذه المهارة بـ). هذا مهم بسبب الطريقة التي تُدخل بها معظم التنفيذات الوصف في سياق النموذج.

داخل البيانات الوصفية (frontmatter)، توجد أيضاً "depends:"، والتي تتيح لك إنشاء تبعيات مهارات هرمية، و"metadata:"، والتي تُستخدم للمراجعات والتقييمات. يمكن لأجسام الوكلاء المختلفة حتى تحديد حقول البيانات الوصفية الخاصة بها، ليتم استخدامها بطريقة خاصة لتلك الأنظمة. كبديل، يمكن حزم البيانات الوصفية الخاصة بالمهارة في ملف تكوين JSON أو YAML إضافي. هذا مرغوب عند بناء أنظمة وكلاء تحتاج إلى تسهيل أنواع مختلفة من سلوك وقت التشغيل لكل مهارة دون تلويث سياق النموذج بالتفاصيل الدقيقة. أخيراً، يمكن الحصول على سلوك مماثل من خلال تجريد بيانات وصفية المهارة عند القراءة. يستخدم Computer هذه المنهجية، مما يسمح بالحفاظ على التكوين في ملف SKILL.md الأساسي. يتطلب الأمر اهتماماً دقيقاً بالتفاصيل في منطق التحليل، وقد يرغب المرء في تنفيذ التجريد المشروط إذا كانت هناك حقول معينة مفيدة لتواجدها داخل سياق النموذج.

المهارة قابلة للاستدعاء

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

هناك ثلاثة مستويات على الأقل من تكاليف السياق بالطريقة التي نفذنا بها المهارات في Computer. إليك العملية:

Computer يستدعي load_skill(name="...")

Computer ينسخ دليل المهارة إلى بيئة التنفيذ المعزولة (Sandbox)

Computer يقوم تلقائياً بتحميل التبعيات بشكل متكرر في العلامة "depends:"

Computer بعد ذلك يجرد البيانات الوصفية وبالتالي يرى الوكيل النص الأساسي والملفات الإضافية فقط

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

المهارة تدريجية

المهارات تدريجية. في Computer، هناك ثلاثة مستويات مختلفة لتكاليف السياق، ونحن نتكبد الثلاثة جميعاً في مراحل مختلفة:

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

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

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

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

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

متى تحتاج إلى مهارة؟

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

عندما تحتاج إلى مهارة

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

قد يكون أن معرفتك دائمة ولكنها ليست في بيانات التدريب. قد تكون هناك تواريخ قطع أو سير عمل خاص بالمؤسسة، أو قد تكون مسألة ذوق. على سبيل المثال، لدينا العديد من المهارات المتعلقة بالتصميم في Computer كتبها هنري موديسيت (رئيس التصميم لدينا). السبب في وجود كل رمز في تلك المهارات هو أن هنري لديه ذوق جيد جداً عندما يتعلق الأمر بتصميم مواقع الويب وملفات PDF. يحدد هنري الخطوط التي يجب استخدامها والخطوط التي لا يجب استخدامها، وكيف تشعر تلك الخطوط، وغيرها من مسائل الحكم التي لا يمكن للنموذج تعلمها من بيانات التدريب وحدها.

عندما لا تحتاج إلى مهارة

نرى العديد من المهارات التي كتب فيها المهندسون سلسلة من أوامر git التي يجب تنفيذها بالترتيب. هذا غير ضروري لأن النموذج يعرف بالفعل كيف يفعل ذلك، مما يعني أنه يصنع وثائق رائعة ولكنه مهارة ضعيفة.

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

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

كل مهارة هي ضريبة

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

الاقتباس الشهير التالي، والذي يبدو أفضل بكثير بالفرنسية، يُترجم تقريباً إلى “لم أقم بجعل هذا الرسالة أطول إلا لعدم توفر الوقت لدي لجعلها أقصر.”

« Je n’ai fait celle-ci plus longue que parce que je n’ai pas eu le loisir de la faire plus courte. » — Blaise Pascal, Lettres Provinciales, 1657

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

إذا وجدت نفسك تحاول إجراء توليد مهارة من محاولة واحدة (one-shot) وتقديم طلبات سحب (PRs) في خمس دقائق، فس تكون النتائج دون المستوى بالتأكيد. في الواقع، أظهرت الأبحاث المبكرة أنك إذا كنت تستخدم نماذج اللغات الكبيرة (LLMs) لكتابة المهارات، فلن تستفيد نموذج اللغة الكبيرة على الأرجح من ذلك: “لا توفر المهارات ذاتية التوليد أي فائدة في المتوسط، مما يظهر أن النماذج لا يمكنها تأليف المعرفة الإجرائية التي تستفيد من استهلاكها بشكل موثوق.”

كيفية بناء مهارة

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

الخطوة 0: كتابة التقييمات (Evals)

اكتب بعض التقييمات أولاً. يمكنك استمداد حالات التقييم من:

استعلامات المستخدمين الحقيقيين: عينة من الإنتاج أو شبكة ثقتك (brain trust)

الإخفاقات المعروفة: فشل الوكيل لعدم وجود المهارة

ارتباك الجيران: قريب من حدود مجالك ولكن يتم توجيهه إلى مهارة أخرى

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

ابدأ بأمثلة سلبية وإيجابية مشابهة. الأمثلة السلبية قوية للغاية ويمكن أن تكون أهم من الأمثلة الإيجابية.

الخطوة 1: الوصف

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

مرة أخرى، الوصف السيئ يصف ما تفعله المهارة أو سبب فائدتها. الوصف الجيد يقول متى يجب على الوكيل تحميل المهارة. على سبيل المثال، قل أن لديك شيئاً لمراقبة طلبات السحب. لا تكتب ما تفعله المهارة. اكتب ما يقوله المهندسون عندما يكونون محبطين ويريدون منك التأكد من أن طلب السحب الخاص بهم يعمل، مثل “babysit” (رعاية) أو “watch CI” (مراقبة التكامل المستمر) أو “make sure this lands” (تأكد من نجاح هذا).

إليك قائمة تحقق سريعة:

تبدأ بـ "Load when..." (تحميل عندما...)

استهداف 50 كلمة أو أقل

يصف نية المستخدم، من الناحية المثالية من الاستعلامات الحقيقية

لا تلخص سير العمل

الاستعلامات الحقيقية هي ما يمكنك تغطيته في قاعدة 80-20. عادة، تعمل مثالان أو ثلاثة بشكل جيد. ليس من السهل إضافة القدر الذي تحتاجه بدقة وفقط.

الخطوة 2: كتابة النص الأساسي

بعد ذلك، اكتب محتوى المهارة نفسها. لاحظ أن هذه ليست الخطوة 0 أو الخطوة 1.

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

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

على سبيل المثال، لا تحتاج إلى كتابة، “git log # العثور على الالتزام؛ git checkout main; git checkout -b <clean-branch>; git cherry-pick <commit>;”

بدلاً من ذلك، اكتب، “انقل الالتزام (cherry-pick) إلى فرع نظيف. قم بحل التعارضات مع الحفاظ على النية. إذا تعذر دمجها بسلاسة، فاشرح السبب.”

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

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

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

الخطوة 3: استخدم التسلسل الهرمي

استفد من تسلسل المهارة الهرمي عندما يكون لديك برنامج نصي، أو مراجع، أو تستخدم أداة معينة:

الاستخدامات المقترحة للبرامج النصية والمراجع والأصول والتكوين داخل المهارة.

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

الخطوة 4: التكرار

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

من المحتمل أن تقوم بالعديد من تغييرات الكلمات الصغيرة. يمكن أن يكون لتغييرات الكلمات الصغيرة في الأوصاف تأثير هائل على التوجيه (بما في ذلك الآثار الجانبية غير المباشرة على المهارات الأخرى)، لذا قم بكل هذا العمل قبل الخطوة 5.

الخطوة 5: الشحن والإطلاق

قم بشحنه.

كيفية صيانة مهارة

الآن بعد أن كتبت مهارة، يجب عليك صيانتها.

عجلة دفع الفخاخ (Gotchas Flywheel)

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

المهارات قابلة للإلحاق في الغالب. يكتسب قسم الفخاخ أكبر قيمة بمرور الوقت:

يفشل الوكيل في شيء ما ← أضف فخاً

يحمل الوكيل المهارة خارج الهدف ← اضبط الوصف وأضف تقييمات سلبية

لا يحمل الوكيل المهارة عندما يجب عليه ذلك ← أضف كلمات رئيسية وتقييمات إيجابية

تغيرات موجه النظام ← تحقق من التنافس أو التكرار

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

بينما تنتقل من 80-20 إلى الوصول إلى معدل نجاح 99.9% أو 99.99%， من السهل تنمية قائمة الفخاخ هذه. بينما ترى هذه الأمثلة السلبية، يجب عليك الإلحاق في الغالب بقسم الفخاخ. يجب ألا تضيف تعليمات أطول أو تغير الوصف.

أجنحة التقييم (Eval Suites)

في Perplexity، نقوم بتشغيل العديد من أجنحة التقييم للتحقق من أشياء مختلفة. هناك تحميل المهارات وقراءات ملفات المهارات، والتي تتحقق من الدقة (precision)، والاسترجاع (recall)، وعمليات التحقق المحظورة لتحميل المهارة نفسها. هل سيقوم الوكيل بتوجيه مهارتك عندما من المفترض أن يفعل ذلك؟ هذه تضمن أن المهارات الجديدة لا تكسر الحدود الحالية.

هناك أيضاً تقييمات يمكنها التحقق من التحميل التدريجي السليم. قد يقوم الوكيل بتحميل المهارة، ولكن هل يقرأ الملف أو الملفات الملحقة؟ على سبيل المثال، إذا كان لديك مهارة مالية للاستعلامات المالية، فهل يقرأ ملف FORMATTING.md الخاص؟

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

أخيراً، من المهم تشغيل هذه التقييمات مقابل نماذج مختلفة. يدعم Computer ثلاثة عائلات نماذج تنسيق مختلفة على الأقل: GPT، وClaude Opus، وClaude Sonnet. تريد تشغيل تحميل مهارتك ومهارات المجال مقابل هؤلاء المنسقين للوكلاء المختلفين لضمان عدم حصولك على سلوك مختلف. يتصرف Sonnet وGPT بشكل مختلف تماماً عندما يتعلق الأمر بالمهارات.

الأفكار النهائية والدروس المستفادة

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

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

هل يمكنك أتمتة مراجعات ما بعد الوفاة (postmortems)؟ هل يمكنك مراجعة طلبات السحب؟ أي مهمة يمكنك القيام بها، يمكنك على الأقل جعل التمرير الأول عبارة عن مهارة وكيل. سيوفر لك ذلك وقتاً كبيراً.

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

اكتب التقييمات قبل المهارة. تضمين الأمثلة السلبية والأحمال المحظورة للمهارات المجاورة ولكن المميزة.

الوصف هو الجزء الصعب. "Load when..." (تحميل عندما...) (كل كلمة تكلف انتباه).

الفخاخ هي محتوى عالي القيمة للغاية. ابدأ نحيفاً، واقضِ في النمو كلما فشل الوكيل.

تذكر أنه من السهل كسر المهارات الأخرى الموجودة مسبقاً عن طريق إضافة مهارة جديدة، حتى لو لم تلمسها (احذر من الفعل عن بعد).

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

اقتباس

@online{perplexity2026DesigningRefiningAndMaintainingAgentSkillsAtPerplexity,
  author = {{Perplexity} and Marshall Kiely and Daisy Lee and Jerry Ma and Lauren Kolm},
  title = {{Designing, refining, and maintaining agent skills at Perplexity}},
  date = {2026-05-01},
  url = {https://perplexity.coolkeypoint.com/hub/blog/designing-refining-and-maintaining-agent-skills-at-perplexity}
}