تعليم وكلاء AI التعلّم من فريق العمل: قصة وكيل Buzz من Warp

ما هي مشكلة الـ 80%؟ الفجوة التي تقتل الوكلاء

تخيل أنك بنيت روبوتاً يساعدك في تنظيم بريدك الإلكتروني. بعد أيام من العمل، صار ينجز 80% من المهمة بشكل مقبول. لكن الـ 20% الباقية — الردود الدقيقة، التعامل مع المواقف المحرجة، فهم النكات والمشاعر — تبقى سيئة جداً. لدرجة أنك تقضي وقتاً أطول في تعديل أخطائه مما لو قمت بالعمل بنفسك!

هذه هي “فجوة الـ 80%” التي تحدث عنها Petra، مسؤولة تجربة المطورين في شركة Warp (منصة طرفية ذكية لتشغيل الوكلاء). في حديثها، طلبت من الحضور رفع أيديهم: من بنى وكيلاً (Agent)؟ كثيرون رفعوا أيديهم. من لديه وكيل يعمل يومياً؟ أيدٍ أقل. من لديه وكيل في مرحلة الإنتاج (Production) وهو سعيد به؟ أيدٍ قليلة جداً.

هذه الفجوة بين “يشتغل نوعاً ما” و”يعمل بشكل موثوق” هي المكان الذي تموت فيه معظم مشاريع الوكلاء. والخبر السار: هناك طريقة لسدّ هذه الفجوة، وهذا ما سنشرحه في هذا المقال.

قصة Buzz — وكيل الردود الذكي من Warp

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

الفريق صغير جداً — لا يمكنهم توظيف جيش من موظفي خدمة العملاء. لذا بنوا Buzz ليقوم بـ:

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

المدهش أن Buzz بُني في أيام معدودة، وهو مؤلف من حوالي 15 ملف “مهارة” (Skill)، مع صفر كود برمجي تقريباً. كل هذه الملفات تحتوي تعليمات مكتوبة باللغة العربية (أو الإنجليزية المبسّطة)، وليس أكواداً برمجية معقدة.

القواعد vs المبادئ: لماذا تفشل القواعد الجامدة؟

في البداية، حاول فريق Warp بناء Buzz بالطريقة التقليدية: قواعد صارمة (Rules). مثلاً: “إذا ذكر المستخدم كلمة ‘غلاء’، لا تذكر التسعير في أول جملة”، وهكذا.

المشكلة؟ انتهى بهم الأمر بقائمة قواعد طويلة تشبه دليل التعليمات. والنتيجة كانت ردوداً آلية (روبوتية) جافة، تنكسر بسهولة عندما يظهر موقف جديد لم يُكتب له مسبقاً. تخيل أنك تحاول تعليم صديقك قيادة السيارة بقائمة من 500 قاعدة — هذا غير عملي!

الحل كان: التحول من القواعد إلى المبادئ (Principles). بدلاً من “إذا قال X افعل Y”، أعطوا Buzz مبادئ عامة مثل:

• “كن متعاطفاً ولطيفاً، خاصة عندما يشتكي المستخدم.”
• “تصرّف كمطوّر منتج لا كموظف دعم فني.”
• “لا تتخذ موقفاً دفاعياً.”

النتيجة: أصبح ملف المهارات أقصر بخمس مرات من السابق! والأهم — أصبحت ردود Buzz أكثر مرونة وطبيعية، لأن المبادئ تسمح للوكيل بالتفكير والاستنتاج بنفسه، بدلاً من اتباع قواعد جامدة.

تعليم الوكيل كيف يتعلم — لا تعطه الإجابات، علّمه طريقة التفكير

بعد أن تحسّنت ردود Buzz بالمبادئ، بقي هناك عيب: لم يكن يتحسّن مع الوقت. كل خطأ كان يحتاج من الفريق أن يعدّل الملفات يدوياً — وهو أمر مرهق.

هنا أتت الفكرة العبقرية: تعليم Buzz كيف يتعلم من أخطائه. تخيل أن لديك موظفاً جديداً. عندما يخطئ، لا تعطيه قاعدة جديدة لكل خطأ. بل تشرح له: “انظر، هذا الخطأ حدث لأنك لم تنتبه لـ X. في المستقبل، عندما ترى Y، فكّر في Z.”

طبقوا هذا مع Buzz: بدلاً من إضافة قواعد جديدة عند كل خطأ، أعطوه تعليمات تعلّمه كيف يستنتج الدرس بنفسه. صار Buzz:

1. ينظر إلى الرد الذي كتبه.
2. ينظر إلى التصحيح الذي قدمه الفريق.
3. يقارن بين تعليماته الحالية والنتيجة المثالية.
4. يستنتج: “ما الذي يجب أن يتغير في تعليماتي لأحصل على هذه النتيجة الأفضل؟”

وهكذا صار Buzz قادراً على توسيع تعليماته وتحسينها بنفسه، دون أن ينتظر الفريق ليكتب له كل تعديل.

حلقة التغذية الراجعة (Feedback Loop): السر الحقيقي

الآن Buzz يفهم المبادئ، وهو يعرف كيف يتعلم من أخطائه. لكن يبقى سؤال مهم: مَن سيمنحه الوقت لتعليمه كل يوم؟ الفريق مشغول، لا أحد يريد اجتماعاً أسبوعياً إضافياً أو مهمة روتينية لتدريب الوكيل.

هنا وصلوا إلى الحل النهائي — ما يميز Buzz حقاً — وهو حلقة التغذية الراجعة التلقائية (Automated Feedback Loop).

الفكرة ببساطة:

1. Buzz يراقب الإشارات ويُرسل اقتراحاته في قناة Slack خاصة.
2. أعضاء الفريق يرونها أثناء تصفحهم للقناة — نفس القناة التي يتواصلون فيها يومياً.
3. يبقي الفريق يردّون على التغريدات يدوياً (لأن الأصالة مهمة)، لكن Buzz اقتراحاته تجعل العمل أسرع بكثير.
4. بعد الرد، يضيف الفريق رمزاً تعبيرياً (Emoji) على اقتراح Buzz: ✅ إذا طابق الرد الفعلي اقتراحه، ❌ إذا اختلف. وأيضاً يمكنهم كتابة ملاحظة سريعة في Slack.
5. يومياً، Buzz يراجع كل هذه الفجوات بين ما اقترحه وما فعله الفريق فعلاً، ويستنتج منها تحسينات لتعليماته.
6. Buzz يفتح طلب تعديل (Pull Request) في مستودع GitHub الخاص بالمهارات، ويُرسل رابط الطلب للفريق.
7. المراجعة تستغرق 60 ثانية — لأن التعديلات عادةً بضع جمل باللغة الإنجليزية!

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

كيف تبدو Buzz في العمل الفعلي؟

لنأخذ جولة سريعة في واجهة Buzz العملية:

• Skill Files: حوالي 15 ملف مهارة على GitHub، كلها نصوص مبادئ وليست أكواداً. يمكن لأي شخص قراءتها وتعديلها بسهولة.
• قناة Slack: Buzz يرسل كل إشارة مع اقتراحه “ارد بهذه الطريقة” أو “اكتفِ بالإعجاب” أو “تجاهل — ليس عنا“.
• شرح المنطق: كل اقتراح يأتي مع شرح لسبب اختيار Buzz لهذا الإجراء. هذا يساعد الفريق على فهم طريقة تفكير الوكيل وتصحيحها بسرعة.
• حالات التخطّي (Skipped): المفضلة لدى الفريق! عندما يقرر Buzz أن إشارة معينة لا تستحق الرد، هذا يعني توفير وقت كامل للفريق.
• التقارير اليومية: كل صباح، يرسل Buzz رسالة خاصة إلى Petra تحتوي رسوماً بيانية عن أدائه: كم إشارة عولجت، كم رد، كم تخطّى، وغيرها.

النتائج: ماذا حققت Buzz لـ Warp؟

الأرقام تتحدث عن نفسها:

• آلاف الإشارات شهرياً تتم معالجتها.
• 50% منها تُتخطى تلقائياً — أي نصف العمل لا يحتاج أي تدخل بشري!
• 15 مهارة (وتزيد باستمرار) تغطي كل شيء من التصنيف إلى الكتابة إلى التحليلات.
• آلاف جولات الوكلاء شهرياً — Buzz يعمل في السحابة تلقائياً، دون أن يطلب منه أحد.

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

الخاتمة: كيف تبني وكيلاً يتحسن ذاتياً؟

العبرة النهائية من قصة Buzz واضحة: لا تحاول أن تجعل وكيلك مثالياً من اليوم الأول. ركّز بدلاً من ذلك على تصميم حلقة تغذية راجعة تسمح له بالتحسّن مع الوقت.

الثلاثة مكونات الأساسية:

• المبادئ (Principles) — بدلاً من القواعد الجامدة. أعطِ وكيلك مبادئ يفكر بها، ليس تعليمات ينفذها.
• تعليم التعلّم (Teach to Learn) — علّم وكيلك كيف يستنتج الدروس من أخطائه بدلاً من إضافة قواعد جديدة لكل خطأ.
• حلقة التغذية الراجعة (Feedback Loop) — صمّم طريقة تسمح للفريق بتقديم ملاحظات دون عناء إضافي. استخدم الأدوات التي يستخدمونها أصلاً (مثل Slack، الإيموجي، Pull Requests).

إذا أردت التعمق أكثر، اقرأ مقالنا عن وكلاء الذكاء الاصطناعي 2026: من المساعدات إلى الأنظمة المستقلة، أو مقال Agentic AI 2026: دليل فهم وبناء الأنظمة المستقلة لمقارنة شاملة لأطر بناء الوكلاء.

📹 هذا المقال مستند إلى محاضرة: “Teaching agents to learn from your team” — Petra (Warp)
🔗 للمزيد: منصة Warp | وثائق Anthropic لبناء الوكلاء