المؤلف: sysls
مُترجم: Deep潮 TechFlow
مقدمة من Shenchao: كتب مطور ومدون يمتلك 2.6 مليون متابع، sysls، مقالًا طويلًا عمليًا حظي بـ 827 مشاركة و7000 إعجاب، وجوهره جملة واحدة فقط: من المرجح أن إضافاتك وأنظمة التذكير وجميع أدوات التثبيت التي تستخدمها تُعيقك أكثر مما تساعدك. لا يتناول هذا المقال نظريات عامة، بل يقدم مبادئ عملية مستخلصة من مشاريع إنتاجية حقيقية — من كيفية التحكم في السياق ومعالجة ميل الذكاء الاصطناعي للاسترضاء، إلى كيفية تحديد شروط إنهاء المهمة، وهو أوضح مقال رأيته حتى الآن في شرح الممارسات الهندسية لـ Claude/Codex.
النص الكامل كالتالي:
مقدمة
أنت مطور، تستخدم Claude و Codex CLI يوميًا، وتسأل نفسك كل يوم إن كنت قد استنزفت قدراتهما بالكامل. أحيانًا ترى منه أشياء سخيفة جدًا، ولا تفهم لماذا يبدو أن بعض الناس يستخدمون الذكاء الاصطناعي لبناء صواريخ، بينما أنت لا تستطيع حتى ترتيب حجرين بثبات.
تشعر أن المشكلة في harness الخاص بك، أو الإضافة، أو المحطة، أو غير ذلك. لقد استخدمت beads و opencode و zep، وكتبت ملف CLAUDE.md بطول 26000 سطر. لكن مهما بذلت من جهد، لا تفهم لماذا تبتعد أكثر عن الجنة، بينما الآخرون يلعبون مع الملائكة.
هذا هو المقال الذي كنت تنتظره.
بالإضافة إلى ذلك، ليس لدي أي مصلحة مالية. أشير إلى CLAUDE.md بما في ذلك AGENT.md، وأشير إلى Claude بما في ذلك Codex، وأستخدم كليهما بكثافة.
على مدار الأشهر القليلة الماضية، لاحظت شيئًا مثيرًا للاهتمام: تقريبًا لا أحد يعرف حقًا كيفية الاستفادة القصوى من قدرات الوكيل.
يبدو وكأن مجموعة صغيرة من الأشخاص قادرة على جعل الوكلاء يبنون العالم بأكمله، بينما يدور الآخرون في بحر هائل من الأدوات، ويعانون من متلازمة الاختيار—معتقدين أنهم إذا وجدوا التوليفة الصحيحة من الحزم أو المهارات أو harness، فسيتمكنون من فتح AGI.
اليوم، أريد أن أكسر كل هذا وأترككم بكلمة بسيطة وصادقة، ثم نبدأ من هناك. أنت لا تحتاج إلى أحدث مُستَغْلِّل وكيل، ولا تحتاج إلى تثبيت مليون حزمة، ولا تحتاج على الإطلاق إلى قراءة مليون مقال للحفاظ على تنافسيتك. في الواقع، من المحتمل أن شغفك يسبب لك ضررًا أكثر من فائدة.
أنا لست هنا للسياحة — لقد بدأت استخدامه منذ أن كان المُمثل قادرًا على كتابة الكود بصعوبة. جربت كل الحزم، وكل إطار عمل، وكل نموذج. كتبت إشارات وبنية تحتية وقنوات بيانات باستخدام مصنع المُمثلين، وليس مشاريع "للعب"، بل حالات استخدام حقيقية تعمل في بيئة الإنتاج. بعد القيام بكل هذا...
اليوم، استخدمت تكوينًا كان شبه أبسط ما يمكن، فقط باستخدام CLI الأساسي (Claude Code و Codex)، بالإضافة إلى فهم مبادئ أساسية قليلة من هندسة الوكلاء، وقمت بإنتاج أفضل عمل لي على الإطلاق.
افهم أن العالم يتحرك بسرعة هائلة
أولاً، أود أن أقول إن شركات النماذج الأساسية تمر بمرحلة سباق تاريخية، ومن الواضح أنها لن تتباطأ قريبًا. كل تحسين في "الذكاء الوكيلي" سيغير طريقة تعاونك معها، لأن الوكلاء مصممون ليصبحوا أكثر استعدادًا للامتثال للتعليمات.
قبل بضع أجيال فقط، إذا كتبت في CLAUDE.md "اقرأ READTHISBEFOREDOINGANYTHING.md قبل القيام بأي شيء"، فكان هناك احتمال 50% أن يرد عليك بـ "اذهب إلى الجحيم"، ثم يفعل ما يريده بنفسه. اليوم، يتبع معظم الأوامر، حتى الأوامر المعقدة المتداخلة — مثل أن تقول "اقرأ A، ثم اقرأ B، وإذا كان C فاقرأ D" — وغالبًا ما يرحب بالقيام بذلك.
ماذا يعني هذا؟ المبدأ الأهم هو الإدراك أن كل جيل جديد من الوكلاء يجبرك على إعادة التفكير في ما هو الحل الأمثل، وهذا بالضبط هو السبب في أن الأقل هو الأكثر.
عندما تستخدم العديد من المكتبات والهارنيسات المختلفة، فإنك تُحبَس في "حل" واحد، لكن هذه المشكلة قد لا توجد أصلاً أمام الوكلاء من الجيل التالي. هل تعرف من هم أكثر المستخدمين حماسة واستخداماً للوكلاء؟ نعم—هم موظفو الشركات الرائدة، الذين لديهم ميزانيات غير محدودة من الرموز، ويستخدمون النماذج الأحدث فعلاً. هل تفهم ما يعنيه ذلك؟
هذا يعني أنه إذا كان هناك مشكلة حقيقية وحل جيد، فستكون الشركات الرائدة أكبر مستخدمين لذلك الحل. وماذا سيفعلون بعد ذلك؟ سيقومون بدمج ذلك الحل في منتجاتهم الخاصة. فكّر: لماذا تسمح أي شركة بمنتج آخر يحل مشكلات حقيقية ويخلق اعتمادًا خارجيًا؟ كيف أعرف أن هذا صحيح؟ انظر إلى المهارات، وHarness الذاكرة، والوكالات الفرعية... جميعها بدأت كـ"حلول" لمشكلات حقيقية، وأثبتت فعاليتها من خلال التجربة العملية.
لذلك، إذا كان هناك شيء حقيقيًا ثوريًا ويمكنه توسيع حالات استخدام الوكلاء بطرق ذات مغزى، فسيتم دمجه حتمًا في المنتج الأساسي للشركة الأساسية. ثق بي، فالشركة الأساسية تتحرك بسرعة هائلة. لذا استرخِ، فأنت لا تحتاج إلى تثبيت أي شيء أو الاعتماد على أي تبعيات خارجية لأداء أفضل عمل ممكن.
أتنبأ بأن قسم التعليقات سيملأ بسرعة بـ "SysLS، استخدمت مُعدّلًا معينًا، رائع! أعدت بناء Google في يوم واحد!" — وأقول لكم: مبروك! لكنكم لستم الجمهور المستهدف، فأنتتم تمثلون مجموعة ضئيلة جدًا جدًا داخل المجتمع فهمت حقًا هندسة الوكلاء.
السياق هو كل شيء
بصراحة، السياق هو كل شيء. استخدام ألف إضافة واعتماد خارجي آخر يعني أنك تعاني من "تضخم السياق" — أي أن وكيلك يغمره الكثير من المعلومات.
دعني أقوم بعمل لعبة تخمين الحروف باستخدام Python؟ بسيط. انتظر، ما هذا الملاحظة عن "إدارة الذاكرة" التي كُتبت قبل 26 جلسة؟ آه، المستخدم كان لديه شاشة متجمدة قبل 71 جلسة بسبب إنشائنا لعدد كبير جدًا من العمليات الفرعية. هل يجب دائمًا كتابة الملاحظات؟ حسنًا، لا مشكلة... ما علاقة هذا بلعبة تخمين الحروف؟
أنت تفهم. أنت تريد فقط تقديم المعلومات الدقيقة التي يحتاجها الوكيل لإكمال المهمة، لا أكثر ولا أقل! كلما سيطرت أفضل على هذا، كان أداء الوكيل أفضل. بمجرد أن تبدأ في إدخال أنظمة ذاكرة غريبة، أو ملحقات، أو مهارات كثيرة بأساليب تسمية واستدعاء مربكة، فأنت تقدم للوكيل تعليمات لصنع قنبلة ووصفة لخبز كعكة، بينما تريد فقط أن يكتب قصيدة عن غابة الأشجار العملاقة.
لذلك، أعيد التبشير مرة أخرى — قم بإزالة جميع الاعتمادات، ثم...
افعل شيئًا مفيدًا حقًا
وصف دقيق للتفاصيل التنفيذية
Remember that context is everything?
Do you remember that you want to inject the exact information an agent needs to complete a task—no more, no less?
أول طريقة للقيام بذلك هي فصل البحث عن التنفيذ. يجب أن تكون دقيقًا جدًا في تحديد ما تطلبه من الوكيل.
ما هي عواقب عدم الدقة؟ "قم بإنشاء نظام مصادقة." يجب على الوكيل أن يبحث: ما هو نظام المصادقة؟ ما هي الخيارات المتاحة؟ وما هي مزايا وعيوب كل منها؟ الآن، يجب عليه البحث عبر الإنترنت عن كمية كبيرة من المعلومات التي لا يحتاجها فعليًا، مما يملأ السياق بتفاصيل تنفيذ محتملة متنوعة. عندما يحين وقت التنفيذ الفعلي، يكون من الأسهل عليه أن يختلط عليه الأمر، أو أن يولد هلوسات غير ضرورية أو غير ذات صلة بالخيار المنفذ المختار.
على العكس، إذا قلت "استخدام تجزئة كلمة المرور bcrypt-12 للاعتماد JWT، وتبديل رموز التحديث، وانتهاء الصلاحية بعد 7 أيام..."، فلن تحتاج إلى دراسة أي حلول بديلة أخرى، فستعرف بالضبط ما تريده، وبالتالي يمكن ملء السياق بتفاصيل التنفيذ.
بالطبع، لن تعرف دائمًا تفاصيل التنفيذ. في كثير من الأحيان لا تعرف ما هو الصحيح، وأحيانًا ترغب حتى في تفويض مهمة تحديد تفاصيل التنفيذ إلى الوكيل. ماذا تفعل في هذه الحالة؟ ببساطة — قم بإنشاء مهمة بحث لاستكشاف مختلف إمكانيات التنفيذ، إما لاتخاذ قرارك الخاص أو لترك الوكيل يقرر أي تنفيذ يستخدم، ثم اجعل وكيلًا آخر ينفذها بسياق جديد تمامًا.
بمجرد أن تبدأ في التفكير بهذه الطريقة، ستشعر بوجود تلوث غير ضروري في سياق الوكلاء داخل سير العمل، ويمكنك بعد ذلك إنشاء جدران عزل داخل سير عمل الوكلاء لتجريد المعلومات غير الضرورية منهم، والاحتفاظ فقط بالسياق المحدد الذي يساعدهم على الأداء المتميز في المهمة. تذكر أنك تمتلك فريقًا موهوبًا وذكيًا جدًا، يعرف كل أنواع الكرات في الكون — لكن ما لم تخبره أنك تريد تصميم مساحة تجعل الناس يرقصون ويستمتعون، فسيستمر في إخبارك بفوائد الأجسام الكروية المختلفة.
القيود التصميمية للانحياز نحو إرضاء الآخرين
لا أحد يريد استخدام منتج ينتقدك باستمرار، أو يخبرك أنك مخطئ، أو يتجاهل أوامرك تمامًا. لذا، ستسعى هذه الوكلاء جاهدة للاتفاق معك، وفعل ما تريد منها.
إذا طلبت منه إضافة كلمة "سعيد" بعد كل ثلاث كلمات، فسيبذل قصارى جهده للامتثال — ويفهم معظم الناس هذا الأمر. إن طاعته هي ما يجعله منتجًا مفيدًا جدًا. لكنه يمتلك خاصية مثيرة للاهتمام للغاية: فهذا يعني أنه إذا قلت له "ساعدني في العثور على خطأ في مستودع الكود"، فسيجد خطأً — حتى لو اضطر إلى "خلق" واحد. لماذا؟ لأنه يريد بشدة الامتثال لأوامرك!
يُشكو الكثيرون بسرعة من أن نماذج اللغة الكبيرة تخلق أوهام وتُخترع أشياء غير موجودة، لكنهم لا يدركون أن المشكلة تكمن في أنفسهم. تطلب منها شيئًا، فتُقدّمه لك—حتى لو احتاج الأمر إلى تضخيم الحقائق قليلاً!
ماذا أفعل؟ وجدت أن "الإشارات المحايدة" فعالة جدًا، أي عدم ميل الوكيل نحو نتيجة معينة. على سبيل المثال، لا أقول "ساعدني في العثور على خطأ في قاعدة البيانات"، بل أقول "قم بمسح قاعدة البيانات بالكامل، وحاول تتبع منطق كل مكون، وأعد تقريرًا بجميع الاكتشافات."
أحيانًا تكشف هذه التنبيهات المحايدة عن أخطاء، وأحيانًا تصف فقط كيف يعمل الكود بشكل موضوعي. لكنها لا تميل الوكيل نحو الافتراض المسبق بأن هناك أخطاء.
طريقة أخرى للتعامل مع الميل إلى إرضاء الآخرين هي تحويله إلى ميزة. أعلم أن الوكيل يبذل قصارى جهده لإرضائي واتباع تعليماتي، ويمكنني التحول في هذا الاتجاه أو ذاك.
لذلك طلبت من وكيل يبحث عن أخطاء أن يحدد جميع الأخطاء في قاعدة البيانات، وأخبرته أن الأخطاء ذات التأثير المنخفض تحصل على +1 نقطة، والأخطاء ذات التأثير المعتدل على +5 نقاط، والأخطاء الخطيرة على +10 نقاط. أعلم أن هذا الوكيل سيكون متحمسًا جدًا لتحديد جميع أنواع الأخطاء (بما في ذلك تلك التي لا تُعد أخطاءً)، ثم يبلغني بنتيجة مثل 104 نقطة. أعتبر هذا مجموعة فائقة من جميع الأخطاء الممكنة.
ثم أطلقت وكيلًا معارضًا للاعتراض، وأخبرته أنه يحصل على درجة الخطأ لكل اعتراض ناجح، ولكن إذا اعترض بشكل خاطئ، يحصل على -2 ضعف درجة الخطأ. سيحاول هذا الوكيل الاعتراض على أكبر عدد ممكن من الأخطاء، لكن بسبب آلية العقوبة، سيظل حذرًا. لا يزال سيُظهر نشاطًا في "الاعتراض" على الأخطاء (بما في ذلك الأخطاء الحقيقية). أعتبر هذا مجموعة فرعية من جميع الأخطاء الحقيقية.
في النهاية، طلبت من وكيل حكم تجميع مدخلات الطرفين وتقديم التقييم. أخبرت وكيل الحكم أن لدي الإجابة الصحيحة الحقيقية، فحصل على +1 نقطة إذا أجاب بشكل صحيح و-1 نقطة إذا أجاب بشكل خاطئ. ثم قام وكيل الحكم بتقييم وكلاء اكتشاف الأخطاء والوكيل المضاد على كل "خطأ" على حدة. ما قاله وكيل الحكم بأنه الحقيقة، كنت أتحقق منه. في معظم الأحيان، كانت هذه الطريقة ذات دقة مذهلة، لكنها أحيانًا تخطئ، ومع ذلك فقد أصبحت عملية شبه خالية من الأخطاء.
ربما تجد أن البحث عن وكيل فردي للخطأ كافٍ، لكن هذه الطريقة فعّالة جدًا بالنسبة لي لأنها تستفيد من الخاصية المتأصلة في كل وكيل — الرغبة في إرضاءك.
كيف تحدد ما هو مفيد وما يستحق الاستخدام؟
يبدو هذا السؤال صعبًا، وكأنه يتطلب منك التعلم المتعمق ومتابعة مستمرة لأحدث تطورات الذكاء الاصطناعي، لكنه في الواقع بسيط... إذا نجح OpenAI وClaude في تنفيذه أو استحوذا على الشركة التي نفذته، فمن المحتمل جدًا أنه مفيد.
هل لاحظتم أن "المهارات (skills)" أصبحت شائعة جدًا وجزءًا من الوثائق الرسمية لـ Claude و Codex؟ هل لاحظتم أن OpenAI استحوذت على OpenClaw؟ هل لاحظتم أن Claude أضافت على الفور وظائف الذاكرة والصوت والعمل عن بُعد؟
كيف هو التخطيط (planning)؟ هل تتذكر عندما اكتشف كثيرون أن التخطيط أولاً ثم التنفيذ مفيد جداً، ثم أصبح ميزة أساسية؟
نعم، تلك مفيدة!
هل تتذكر أن خطافات التوقف اللانهائية كانت مفيدة جدًا، لأن الوكلاء كانوا يتجنبون بشدة القيام بمهام طويلة الأمد... ثم فجأة، مع إصدار Codex 5.2، اختفى هذا الطلب بين عشية وضحاها؟
هذا كل ما تحتاج معرفته... إذا كان شيء ما مهمًا وفعالًا حقًا، فسيقوم Claude و Codex بتنفيذه تلقائيًا! لذا لا داعي للقلق كثيرًا بشأن استخدام "الأشياء الجديدة" أو التعود عليها، بل لا تحتاج حتى إلى "البقاء محدثًا".
ساعدني، قم بتحديث أداة CLI التي اخترتها بين الحين والآخر، واقرأ ما تم إضافته من ميزات. هذا كافٍ.
الضغط، السياق، والافتراضات
يجد بعض الأشخاص حفرة كبيرة عند استخدام وكلاء: أحيانًا يبدو وكأنهم أذكى كائنات على وجه الأرض، وأحيانًا أخرى لا تصدق أنك خُدعت منهم.
Is this smart? This is fucking stupid!
الفرق الأكبر هو ما إذا كان الوكيل اضطر إلى إجراء افتراضات أو "ملء الفراغات". اليوم، لا يزالون سيئين جدًا في "ربط النقاط" أو "ملء الفراغات" أو إجراء الافتراضات. كلما قاموا بذلك، يصبح الأمر واضحًا على الفور، ويتدهور الوضع بوضوح.
أحد أهم القواعد في CLAUDE.md هي القاعدة المتعلقة بكيفية الحصول على السياق، وتُوجّه الوكيل ليقرأ تلك القاعدة أول شيء كلما قرأ CLAUDE.md (أي بعد كل ضغط). كجزء من قاعدة الحصول على السياق، يمكن لعدة تعليمات بسيطة أن تُحدث فرقًا كبيرًا: إعادة قراءة خطة المهمة، وإعادة قراءة الملفات المرتبطة بالمهمة قبل المتابعة.
أخبر الوكيل كيفية إنهاء المهمة
لدينا نحن البشر شعور واضح تمامًا بـ "إكمال" مهمة ما. أكبر مشكلة في الذكاء الحالي للوكلاء هي أنهم يعرفون كيف يبدأون مهمة، لكنهم لا يعرفون كيف ينهونها.
هذا يؤدي غالبًا إلى نتائج محبطة جدًا: حيث ينتهي الممثل بتنفيذ مجموعة من الجسور ثم ينهي العمل.
الاختبار هو علامة فارقة جيدة للوكيل، لأن الاختبارات حتمية، ويمكنك تحديد توقعات واضحة جدًا. ما لم تمر هذه X اختبارات، لم تكتمل مهامك؛ ولا يُسمح لك بتعديل الاختبارات.
ثم عليك فقط مراجعة الاختبارات، وبمجرد اجتياز جميع الاختبارات، يمكنك أن تشعر بالاطمئنان. يمكنك أيضًا أتمتة هذا العملية، لكن النقطة الأساسية هي — تذكّر أن "انتهاء المهمة" أمر طبيعي للبشر، لكنه ليس كذلك للوكيل.
هل تعرف ما إذا كان هناك أي شيء آخر أصبح وجهة مهمة حديثًا؟ قم بالتقاط صورة شاشة + التحقق. يمكنك أن تطلب من الوكيل تنفيذ شيء ما حتى تمر جميع الاختبارات، ثم يلتقط صورة شاشة ويوافق على "التصميم أو السلوك" المُظهر في الصورة.
هذا يسمح لك بجعل الوكيل يُكرر المحاولات ويتقدم نحو التصميم الذي تريده، دون القلق من أنه سيتوقف بعد المحاولة الأولى!
الامتداد الطبيعي لهذا هو إنشاء "عقد" مع الوكيل ودمجه في القواعد. على سبيل المثال، يحدد هذا `{TASK}CONTRACT.md` ما يجب عليك فعله قبل السماح لك بإنهاء الجلسة. في `{TASK}CONTRACT.md`، ستُحدد الاختبارات وصور الشاشة وغيرها من التحقق المطلوب إكماله قبل التأكيد على انتهاء المهمة!
وكيل يعمل دائمًا
أحد الأسئلة التي تُطرح عليّ بشكل متكرر هو كيف يمكن للناس ضمان تشغيل الوكيل على مدار 24 ساعة مع التأكد من أنه لا ينحرف؟
هناك طريقة بسيطة جدًا. قم بإنشاء stop-hook يمنع إنهاء الجلسة ما لم تُكمل جميع أجزاء `{TASK}_CONTRACT.md`.
إذا كان لديك 100 عقدًا بمواصفات محددة بوضوح تحتوي على المحتوى الذي ترغب في بنائه، فسيمنع stop-hook إنهاء الوكيل حتى يكتمل جميع العقود الـ 100، بما في ذلك جميع الاختبارات والتحقق المطلوب تشغيلها!
نصيحة احترافية: وجدت أن الجلسات الطويلة التي تستمر 24 ساعة ليست مثالية لـ "القيام بالمهام". أحد الأسباب هو أن هذا الأسلوب يفرض بشكل هيكلية توسع السياق، لأن سياقات العقود غير ذات الصلة تدخل جميعها في نفس الجلسة!
لذلك، لا أنصح بفعل ذلك.
هناك طريقة أفضل لأتمتة الوكيل — افتح جلسة جديدة لكل عقد. قم بإنشاء العقد كلما احتجت إلى القيام بشيء ما.
قم بإنشاء طبقة ترتيب لإنشاء عقد جديد عند الحاجة إلى تنفيذ "شيء ما"، وإنشاء جلسة جديدة للتعامل مع ذلك العقد.
هذا سيغير تجربتك الوسيطة تمامًا.
تكرار، تكرار، تكرار
هل تتوقع أن يعلم مساعدك الإداري بجدولك من اليوم الأول؟ أو كيف تشرب قهوتك؟ هل تتناول العشاء في السادسة مساءً وليس الثامنة؟ بالطبع لا. ستُطور تفضيلاتك مع مرور الوقت.
نفس الشيء ينطبق على الوكيل. ابدأ بأبسط تكوين، وتجاهل الهياكل المعقدة أو harness، واعطِ CLI الأساسي فرصة.
ثم أضف تفضيلاتك تدريجيًا. كيف؟
القواعد
إذا كنت لا تريد أن يقوم الوكيل بفعل ما، فاكتب ذلك كقاعدة. ثم أخبر الوكيل بهذه القاعدة في ملف CLAUDE.md. على سبيل المثال: "اقرأ ملف coding-rules.md قبل كتابة الكود." يمكن أن تكون القواعد متداخلة، ويمكن أن تكون شرطية! إذا كنت تكتب كودًا، اقرأ ملف coding-rules.md؛ إذا كنت تكتب اختبارات، اقرأ ملف coding-test-rules.md؛ إذا كانت اختباراتك تفشل، اقرأ ملف coding-test-failing-rules.md. يمكنك إنشاء قواعد بفروع منطقية غير محدودة يلتزم بها الوكيل، وسيكون Claude (و Codex) سعيدًا بالالتزام بها، بشرط أن يكون هناك شرح واضح في ملف CLAUDE.md.
في الواقع، هذه أول نصيحة عملية أقدمها: اعتبر ملف CLAUDE.md كدليل منطقي متداخل يوضح أين تبحث عن السياق في سيناريوهات ونتائج محددة. يجب أن يكون موجزًا قدر الإمكان، ويتضمن فقط منطق IF-ELSE المتعلق بـ "أين تبحث عن السياق في أي حالة".
إذا رأيت الوكيل يقوم بشيء لا توافق عليه، أضفه كقاعدة وأخبر الوكيل أن يقرأ القاعدة قبل القيام بذلك مرة أخرى، فلن يقوم به مرة أخرى بالتأكيد.
المهارات
المهارات (Skills) مشابهة للقواعد، إلا أنها أكثر ملاءمة لوصف "خطوات التنفيذ" بدلاً من تفضيلات الترميز. إذا كان لديك طريقة محددة ترغب في تنفيذ شيء ما بها، فيمكنك تضمينها في المهارات.
في الواقع، يشكو الناس غالبًا من عدم معرفة كيفية حل الوكيل لمشكلة ما، مما يسبب قلقًا. إذا كنت ترغب في جعل هذا أمرًا مؤكدًا، فاجعل الوكيل يدرس أولًا كيفية حل المشكلة، ثم يُسجّل الحل في ملف مهارة. بهذه الطريقة، يمكنك رؤية كيفية تعامل الوكيل مع المشكلة مسبقًا، وتصحيحها أو تحسينها قبل أن يواجهها فعليًا.
كيف تجعل الوكيل يعلم بوجود هذه المهارة؟ نعم! اكتب ذلك في ملف CLAUDE.md، وعندما تواجه هذا السيناريو وتحتاج إلى معالجة هذا الأمر، اقرأ ملف `SKILL.md`.
القواعد والمهارات
أنت بالتأكيد ترغب في إضافة قواعد ومهارات مستمرة للوكيل. هذه هي الطريقة التي تمنحه بها شخصية وتتذكر بها تفضيلاتك. تقريبًا كل شيء آخر زائد عن الحاجة.
بمجرد أن تبدأ في القيام بذلك، سيشعر وكيلك وكأنه سحر. سيقوم بالأشياء "بالطريقة التي تريدها". ثم ستبدأ أخيرًا في الشعور بأنك "فهمت" هندسة الوكلاء.
ثم...
سترى الأداء يبدأ في التراجع مرة أخرى.
ما الأمر؟!
ببساطة. مع إضافة المزيد من القواعد والمهارات، تبدأ في التناقض مع بعضها البعض، أو يبدأ الوكيل في معاناة تضخم سياقي كبير. إذا كنت بحاجة إلى أن يقرأ الوكيل 14 ملفًا بتنسيق markdown قبل بدء البرمجة، فسيواجه نفس المشكلة مع كمية هائلة من المعلومات غير المفيدة.
ماذا يجب أن أفعل؟
تنظيف. اطلب من وكيلك أن "يأخذ جلسة سبا"، ودمج القواعد والمهارات، من خلال توضيح تفضيلاتك المحدثة لحل التناقضات.
Then it will feel like magic again.
هذا كل شيء. هذا حقًا هو السر. ابق بسيطًا، واستخدم القواعد والمهارات، واعتبر CLAUDE.md دليلًا، وانتبه بعناية لسياقاتها وقيود تصميمها.
المسؤولية عن النتائج
لا توجد وكيل مثالي اليوم. يمكنك تفويض العديد من مهام التصميم والتنفيذ إلى الوكيل، لكنك مسؤول عن النتائج.
لذلك كن حذرًا... ثم استمتع جيدًا!
إن لعب ألعاب المستقبل (مع استخدامها بوضوح لأغراض جادة) ممتع حقًا!