Your AI Agent Is Hiding Its Mistakes From You - Ben Holmes, Warp

أنا بن هولمز، وأعمل قائدًا لهندسة تجربة المطورين في Warp، وسأتحدث اليوم عن بناء وكلاء ذاتيي التحسين، وهم وكلاء يراجعون أعمالهم السابقة ويكتشفون كيفية تحسين إعداداتهم الخاصة. لإعطائكم بعض السياق، أنا أعمل على Warp Factories، وهي بنية تحتية مرنة ومفتوحة تساعدكم جميعًا على بناء مصانع برمجيات خاصة بكم، والأهم من ذلك، مصانع قادرة على تحسين نفسها كجزء من النظام. لن أتحدث كثيرًا عن مصانع البرمجيات ككل اليوم، لكني سأركز على جزء جوهري منها، وهو جعل الوكلاء يفحصون كل الأعمال التي يقومون بها داخل تلك الأنظمة ويقترحون تحسينات ليؤدي الوكيل عمله بشكل أفضل بمرور الوقت. سأبدأ بطرح ما قد يتبادر إلى ذهنكم عند سماع مصطلح "مصنع البرمجيات" من أجل وضع تعريف أساسي له. إنها فكرة أتمتة دورة حياة تطوير البرمجيات. ربما رأيتم ذلك كخط تجميع لوكلاء مختلفين يقومون بمهام متنوعة ويسلمون العمل لبعضهم البعض. وقد ترونه أيضًا كعجلة، كما تشاهدون في هذه الحالة، حيث تبدأ من قائمة مهام، أو لوحة، أو رسائل Slack، أو أي مكان تتبعون فيه العمل ؛ ويكون لديكم خط تجميع من الوكلاء يمرون بعملية البحث أو التصنيف، وربما العمل مع بشري لكتابة مواصفات، وتنفيذ ذلك التغيير ، وإدخال استخدام الحاسوب في الصورة لالتقاط لقطات شاشة وتسجيلات لضمان الحصول على طلب سحب (Pull Request) جيد في النهاية. وربما أيضًا إجراء جولات من مراجعة الأكواد التنافسية لضمان أنها

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

تحسينات بشكل دوري. وبعد ذلك يمكنك الاستمرار في التقييم ومتابعة أداء الدرجات، وهكذا. لذا، سأقوم بتقسيم هذه الحلقة إلى أجزاء فردية حتى نتمكن من الحديث عن كل منها على حدة. الجزء الأول من الحلقة التي عرضتها هو تجميع كل محادثات وكلائك في مكان واحد حتى يتمكن الوكيل من فهم وتحليل كل الأعمال التي يقوم بها فريقك. إذا كنت تعمل مع وكلاء محليين مثل Claude code أو codex أو pie أو أي منهم، فستكون هذه الملفات موجودة على نظامك. فبالنسبة لـ Claude، سيكون لديك مجلد خاص بـ Claude حيث يتم تخزين البيانات. وبالنسبة لـ Codex، سيكون لديك مجلد خاص بـ Codex. وهذا يعمل بشكل جيد بما يكفي إذا كنت ترغب في تحسين إعداداتك الفردية. لقد تحدثت بالفعل مع فرق أنشأت حاوية S3 وأتمتة لأخذ مجلدات dot Claude الخاصة بالجميع وضغطها ووضعها في مساحة S3 مشتركة، وذلك فقط ليكون لدينا محادثات الجميع في مكان واحد. إنها إحدى طرق إنجاز الأمور. لكن هناك طرق أخرى يمكنك من خلالها مركزة هذه المعلومات. إذا كنت تستخدم نظام "مصنع البرمجيات"(software factory)، فالأمر يأتي بشكل تلقائي. تعتمد هذه الفكرة على تشغيل الوكلاء داخل جهاز كمبيوتر مشترك. أي ليس على أجهزة الكمبيوتر المحمولة الخاصة بكل فرد، بل على جهاز مشترك يرسل إليه الجميع المهام.

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

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

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

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

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

نعطيه نتيجة "رسوب" لأنه لم يتبع التعليمات التي توقعناها حقاً. وبالنسبة للإسهاب، ربما كان واضحاً جداً في الواقع . كان يستخدم نموذجاً جديداً لا يقوم بكتابة تعليقات برمجية. آه، نموذج GPT، هل هناك أحد في الغرفة؟ لا أعرف. لكن لنقل أنه لم يكتب الكثير من التعليقات. كان من السهل جداً فهم طلب السحب (PR)، لذا فقد اجتاز الاختبار. وبالانتقال إلى الكفاءة، لنقل أنه كان يحاول القيام بالكثير من الاستكشاف في بيئة الاختبار الخاصة به لمعرفة كيفية اختبار هذا التغيير في المقام الأول، في حين كان ينبغي عليه الحصول على بعض التعليمات المسبقة حول ذلك . ومن المحتمل أن يكون هذا تقييماً بالرسوب في هذا الجانب. ومرة أخرى، النجاح والرسوب يعتمدان فقط على ما إذا كان الأداء أقل من المعيار الذي وضعناه في نظام التقييم. ويمكنك بعد ذلك متابعة كل محادثات الوكيل الخاصة بك والاستمرار في تقييمها. لذا، وبشكل تلقائي، عادةً ما يكون المحفز هو دمج طلب السحب، حيث يتم تشغيل وكيل لمراجعة تلك المحادثة بناءً على معايير التقييم الخاصة بك. ومع مرور الوقت، ستبدأ في تجميع الكثير من البيانات حول كيفية سير المحادثات. وسيتضمن كل من هذه البيانات معدلات النجاح والرسوب. إذاً ، هل نجحت أم فشلت في كل تعريف؟ ثم يمكنك أيضاً جعل الوكيل يصف سبب حدوث أحد حالات الفشل أو النجاح تلك. ويصبح هذا سياقاً يمكن لوكيل آخر استخدامه لتحديد التحسينات التي يجب إجراؤها. لذا، الطريقة التي أعددناها بها، بالعودة إلى هذه الدورة، هي فكرة تقييم المحادثات بمجرد حدوثها. وربما من خلال وظيفة مجدولة (cron job)، كل 24 ساعة، يتم مراجعة عينة من محادثات الـ 24 ساعة الماضية. ربما كان هناك حوالي 200

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

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

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

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

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