قادة الفكر

الوكلاء دائمًا موظفون من اليوم الأول. حان الوقت لنصمم من أجل ذلك.

mm
أضف Unite.AI إلى مصادرك المفضلة على Google

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

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

السياق: لماذا جاء الترميز أولاً

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

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

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

التوجيه: لماذا لا تعمل عملية Osmosis

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

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

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

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

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

النية: لماذا ينحرف الوكلاء إلى الوسط

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

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

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

أين تنكسر الاستعارة

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

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

مسؤولية الوكيل تعتمد على التصميم

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

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

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

Lauren Hanford هي نائبة رئيس عمليات المنتج في Sonar, رائدة عالمية في التحقق من شفرة AI والحكم عليها. قبل Sonar، كانت نائبة رئيس المنتج في Tidelift. خلفيتها في المنتج وتجربة المستخدم والتطوير. تستخدم هذا المزيج الفريد من المهارات لتقريب بناء التكنولوجيا والمنظمات من منظور يركز على المستخدم.