الفصل 4 — أوّليات العميل: السلوكيات الوكيلية والتحكُّم

تم النشر في: 1447-10-14 آخر تحديث في: 1447-12-26 الإصدار: 1

الفصل 4 — أوّليات العميل: السلوكيات الوكيلية والتحكُّم

المقالة الرابعة من الجولة الفصلية لـ LLM Primer IV: تصميم الإدراك الاصطناعي بـ MCP. أوّليات الخادم تَعرض ما يَستطيع الخادم تقديمه؛ وأوّليات العميل تَعرض ما يُعيره المُضيف — وكل عاريةٍ قدرةٌ يَمنحها المستخدم ومُجازفةٌ يَقبلها المُضيف.


لماذا يوجد هذا الفصل

الخادم الذي يَعرض الموارد والموجِّهات والأدوات فقط لا يَعرف شيئاً عن مُضيفه: لا النموذج الذي يُشغِّله، ولا الملفات التي يَراها، ولا حتى ما إذا كان المستخدم عند لوحة المفاتيح. لكثير من التكاملات هذا الجدار متعمَّد. ولفئاتٍ كاملةٍ من السلوك المفيد هو أعلى مما ينبغي. خادمٌ يَحتاج تلخيص وثيقةٍ طويلة لا ينبغي أن يَشحن نموذجه اللغوي الخاص. خادمٌ يريد العمل على مشروعٍ ينبغي أن يَعرف أيُّ مشروع. خادمٌ يَحتاج إذن المستخدم لخطوةٍ هَدّامة ينبغي أن يَستطيع السؤال. أوّليات العميل هي كيف يَفتح MCP ثقوباً صغيرةً مضبوطةً عبر الجدار.

الأوّليات الثلاث — المعاينة، الجذور، الاستنطاق — كلٌّ تَمدّ ذراع الخادم إلى أرض المُضيف بطريقةٍ دقيقةٍ متفاوضٍ عليها. وكلٌّ سطحٌ أمني يَقبله المُضيف نيابةً عن مستخدمه، وتَتركَّب الواحدة مع الأخريات لإنتاج سلوكٍ أكثر وكيليةً من مجموع أجزائه.

في سطر واحد: المعاينة تُتيح للخادم استخدام نموذج المُضيف، الجذور تُخبر الخادم بالنطاق الذي يَعمل فيه، الاستنطاق يُتيح للخادم سؤال المستخدم — كلٌّ عاريةٌ متعمَّدة، وكلٌّ مُجازفةٌ متعمَّدة.

4.1 المعاينة: استعارة دماغ المُضيف

بتفعيل المعاينة، يَستطيع الخادم طلب أن يُجري المُضيف استدعاء استدلالٍ ويُعيد النتيجة. لا يَشحن نموذجاً، لا يَحمل مفتاح API، ولا يَعرف أبداً أيَّ نموذجٍ استخدمه المُضيف فعلاً — يُرسل رسائل وتفضيلاتٍ مرنة (كلفة، سرعة، ذكاء)، ويُجري المُضيف الاستدعاء. من منظور الخادم، صار المُضيف نقطة نموذجٍ لغوي عامة.

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

هاجسٌ أدقّ: تَستطيع المعاينة كَبس حلقةٍ وكيلية داخلية. تَبدو للمُضيف استدعاء معاينةٍ واحداً؛ داخل الخادم، عَمَل وكيلٌ فرعي كامل. النمط الجدير بالتسمية هو الوكيل الفرعي المُقَيَّد — يَمنح المستخدم ميزانية N استدعاء، T ثانية، X دولار؛ يُجري الخادم ما يَشاء داخل ذلك المظروف ويُعيد إما نتيجةً أو جزئياً لطيفاً. لا تُعطي المعاينة الخادم وصولاً إلى المحادثة أيضاً؛ يَرى فقط ما أرسله، ومُضيفٌ يَهرب سياق المحادثة في حمولات المعاينة قد أَضعف حدّ الثقة بصرف النظر عن النية.

4.2 الجذور: حدود نظام الملفات ونطاق المشروع

الجذر URI — عادةً file://، وإن كانت المواصفة عامة — أعلنه المُضيف داخل النطاق. يَستدعي الخادم roots/list ويَسأل «بماذا أعمل؟». يُعلن المُضيف عن قدرة roots عند التهيئة ويَبعث notifications/roots/list_changed حين يُبَدِّل المستخدم المشاريع. القائمة قائمةٌ فقط؛ لا لغة أذوناتٍ متداخلة، ولا أنماط نجمية، ولا قواعد تَضمين/استثناء.

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

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

4.3 الاستنطاق: إتاحة الخادم سؤالاً

الاستنطاق أحدث الثلاث وأكثرها انعكاساً لما تعلَّمه المصمِّمون من الموجة الأولى لنشر الوكلاء. يَبعث الخادم elicitation/create مع رسالة (السؤال) وrequestedSchema (شكل الإجابة المتوقَّعة). يَعرض المُضيف السؤال في واجهته، يَجمع الإجابة، يَتحقَّق منها، ويُعيدها. يَستأنف الخادم عمله والإجابة في يده.

المخطط هو ما يَجعل الاستنطاق أأمن من الموجِّهات الحرة. لا يُجاب على بولياني بنثرٍ؛ ولا على تعداد بخيارٍ رابع. يَستطيع المُضيف عرض المستخدم في واجهةٍ واضحةٍ أنه يُسأل نعم/لا، ورفض ما عداه. تُقَيِّد المواصفة المخططات عمداً بكائناتٍ مسطَّحةٍ من البدائيات — للنماذج الفعلية، استخدم أداةً مخطط وسائطها هو النموذج، حيث يَستطيع المستخدم مراجعة قيم النموذج المُعَبَّأة قبل الاستدعاء. الاستنطاق لحالات الحقل الواحد أو الاثنين.

صورة المُجازفة بشكل تَصَيُّد: خادمٌ يَعرض «يتطلَّب النظام مفتاح وصول AWS الخاص بك للاستمرار» يُحاول جعل المستخدم يكتب سرّاً في المكان الخطأ. تُخفِّف المُضيفات بنسبٍ واضح — كل موجِّه استنطاقٍ مُعلَّمٌ بالخادم المُصدر، منفصلاً عن صوت المساعد — وبرفض المخططات التي تَبدو على شكل اعتماد. الوجه الإيجابي هو نمط تأكيد الأداة الهَدّامة: أول وظيفة الأداة استنطاق «هل أنت متأكد؟» وفقط على التأكيد تَعمل. هذه من أفعَل ممارسات تصلُّب MCP في الإنتاج.

4.4 تركيب الثلاث

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

يجدر بنا تذكُّره: اقرأ أوّليات العميل الثلاث بوصفها سؤالاً واحداً — كم من نفسه يَوَدّ المُضيف إعارته للخادم؟ المعاينة تُعير النموذج. الجذور تُعير نطاقاً. الاستنطاق يُعير انتباه المستخدم. كل عاريةٍ مُتفاوَضٌ عليها منفصلةً ليكون القَبول متعمَّداً، ووظيفة البروتوكول ليست إزالة المُجازفة بل جعلها مقروءة.

ما يُمهِّد له الفصل 4

أوّليات الخادم وأوّليات العميل بينهما تَصفان كل ما يَستطيع المُضيف والخادم فعله الواحد للآخر. ما لم نَتطرَّق له بعد هو كيف يَنتقل أيٌّ من هذا عبر السلك. tools/list وsampling/createMessage ليست مجرد رسائل مُجرَّدة — تَركب نقلاً، واختيار النقل يُقرِّر بهدوءٍ تقريباً كل خاصية تشغيلية لتكامل MCP. الخوادم تَحتاج أيضاً أن تكون قابلةً للوجدان: مُضيفٌ يَوَدّ استخدام خادمٍ عليه أن يَعرف أنه موجود، أين يَسكن، وهل يَثق بالادِّعاء. يَتناول الفصل 5 كليهما.


التالي — الفصل 5: بروتوكولات النقل والاكتشاف. النقول الثلاثة التي يَدعمها MCP — stdio، SSE، HTTP القابل للبث — مقارنةً بصدق، وطبقة .well-known/mcp.json وبطاقات الخادم التي تُحَوِّل التكاملات الفردية إلى ما يُشبه نظاماً بيئياً.

هل تريد الصورة الكاملة؟ يَمشي الكتاب على دورة حياة كل أوّليةٍ ونموذج خطئها وسطح مُجازفتها، يُعالج نمط الوكيل الفرعي المُقَيَّد بعمق، ويَضع نموذج الموافقة المُتدَرِّج الذي ظهر للمُضيفات التي تُدير خوادم قراءةٍ ونطاقٍ ووكيلية. عرض LLM Primer IV على أمازون ←

SHO
SHO
مدير التكنولوجيا والمؤسس لشركة RECEIPTROLLER. يركز على البيانات، مدفوع بالابتكار، دائم الفضول.