الادعاء المطروح حول الأنظمة القديمة
الإطار الأكثر فائدة هو أن الأنظمة القديمة تجسّد عقودًا من افتراضات الثقة المعايرة للتفاعل بمعدل بشري. هذه الافتراضات ليست مكتوبة كسياسة؛ بل هي ضمنية في المهلات الزمنية، وفي غياب حدود المعدل، وفي نقاط النهاية غير الموثقة التي "لا يستخدمها أحد"، وفي حسابات الخدمة ذات الأفعال الواسعة، وفي واجهات الدفعات التي تفترض أن مشغّلًا سيلاحظ نتيجة خاطئة. الوكيل لا ينشئ أذونات جديدة. بل يمارس الأذونات القائمة دون الاحتكاك الذي جعلها محتملة.
هذا التمييز مهم لأنه يغيّر المعالجة. إذا كانت المشكلة هدفًا، فالجواب هو تحصين المحيط: مزيد من الفحص، مزيد من التوقيعات، مزيد من التقسيم. وإذا كانت المشكلة عدم تطابق في القدرات، فالجواب هو تحديد نطاق ما يُسمح للوكيل بفعله عند حدود البروتوكول، بغض النظر عما تدعمه نقطة النهاية تقنيًا.
ما الذي يتغير عندما يكون المستدعي وكيلًا
المشغلون البشريون يحدّون من أنفسهم. يشعرون بالملل أو الشك أو التعب. يتوقفون بعد بضع محاولات فاشلة لأن تكلفة الاستمرار ترتفع والعائد المتوقع ينخفض. لا يعدّدون كل تركيبة معاملات في نموذج لأن النموذج ممل. يتخطون نقاط النهاية غير الموثقة لأنهم لا يعرفون بوجودها. هذه ليست ضوابط أمنية؛ بل آثار جانبية سلوكية للإدراك البشري، وقد اعتمدت الأنظمة القديمة عليها بهدوء لسنوات.
الوكلاء لا يمتلكون هذه الآثار الجانبية. يعدّدون بشكل شامل ويعيدون المحاولة بشكل حتمي. نقطة النهاية المتساهلة التي كان الإنسان يأخذ منها عينة تصبح، بالنسبة للوكيل، مسألة بحث: كرّر على فضاء المعاملات، لاحظ الاستجابة، ضيّق المجموعة. صُممت الواجهة لجمهور مشغلين معروف بمعدل تفاعل معروف. ليس لديها مفهوم لمستدعٍ يستكشف بشكل منهجي، لأنه لم يكن هناك مستدعٍ كهذا عند تحديد الواجهة.
هناك آلية ملموسة تجعل هذا مرئيًا. تخيل خدمة SOAP قديمة أو خدمة قائمة على النماذج تعرض فعل بحث. تقبل الخدمة معرّفًا، وتعيد سجلًا، وتسجل الاستدعاء. بالنسبة لمشغل بشري، يُكتب المعرّف من تذكرة. وبالنسبة لوكيل، يكون المعرّف متغيرًا في حلقة. لا يوجد حد للمعدل في الخدمة لأن التصميم الأصلي افترض إنسانًا على لوحة مفاتيح؛ يُكتب السجل لكن لا يُجمّع؛ تُخزّن الاستجابة مؤقتًا لكل معرّف، مما يعني أن الوكيل يمكنه التمييز بين "غير موجود" و"موجود لكن فارغ" واستخدام هذا الفرق كأوراكل. لم يتطلب أي من هذا من الوكيل كسر أي شيء. تطلب من الوكيل استخدام الواجهة كما هي محددة، بمعدل لم تتوقعه الواجهة قط.
يظهر النمط نفسه في الأنظمة الصناعية والحكومية: نقاط نهاية إرسال الدفعات التي تقبل معرّف مهمة وتعيد حالة، وأفعال إدارية كانت مخصصة لمهمة مجدولة لكنها قابلة للوصول من حساب خدمة، ونقاط نهاية "داخلية" تُحل على نفس قطاع الشبكة وليس لديها مصادقة لأن القطاع كان مفترضًا موثوقًا. لا يحتاج الوكيل إلى الذكاء. يحتاج إلى المثابرة، والمثابرة رخيصة بالنسبة له.
قاعدة التصميم: تحديد نطاق القدرات عند حدود البروتوكول
الضابط الذي يعالج هذا ليس محيطًا أفضل. بل هو حد قدرات أمام الطبقة القديمة، معبّر عنه بالبروتوكول الذي يتحدثه الوكيل فعليًا. ثلاث قواعد تجعله ملموسًا.
عدّد الأفعال التي يحتاجها الوكيل بشكل مشروع، لا الأفعال التي تدعمها نقطة النهاية. قد تدعم نقطة نهاية قديمة القراءة والكتابة والحذف ومجموعة من العمليات الإدارية. الوكيل الذي يلخّص السجلات يحتاج إلى القراءة على مجموعة فرعية محددة. تُشتق قائمة السماح من المهمة، لا من سطح نقطة النهاية. أي شيء ليس في القائمة غير قابل للوصول، حتى لو كانت الخدمة الأساسية ستقبله.
اربط كل فعل بمعدل ونطاق تأثير، لا بهوية فقط. يجيب التحكم في الوصول القائم على الهوية عن سؤال "من يستدعي". ولا يجيب عن "كم مرة" أو "على أي نطاق". فعل القراءة المحدد بسجل واحد قدرة مختلفة عن فعل القراءة المحدد بمسح جدول، رغم أن كليهما قراءة. يجب أن يحمل الحد كليهما: حد أقصى لمعدل الاستدعاء لكل فعل، وحد أقصى لمجموعة النتائج أو عدد السجلات المتأثرة لكل استدعاء. عندما يتجاوز الوكيل أيًا منهما، يُرفض الاستدعاء بدلًا من تقييده بصمت، لأن التقييد الصامت يحوّل انتهاك القدرة إلى مهلة زمنية سيعيد الوكيل المحاولة فيها.
تعامل مع نقاط النهاية غير الموثقة كغير موجودة بالنسبة للوكلاء حتى عندما تُحل. تحتوي الأنظمة القديمة على نقاط نهاية قابلة للوصول لكن غير مدرجة. بالنسبة لمشغل بشري، نقطة النهاية غير الموثقة غير مرئية فعليًا. وبالنسبة لوكيل يعدّد، فهي مرشح. يجب أن يرفض الحد التوجيه إلى نقاط نهاية ليست في بيان قدرات الوكيل، بغض النظر عما إذا كانت الشبكة ستوصل الطلب. هذا هو الفرق بين "الوكيل لا يستطيع الوصول إليها" و"الوكيل غير مسموح له بالوصول إليها"؛ الأخير يصمد أمام تغيرات الشبكة.
بيان أدنى يوضح الشكل:
agent_capabilities:
- verb: read_record
endpoint: /legacy/lookup
max_rate: 5/s
max_scope: 1 record
- verb: submit_job
endpoint: /legacy/batch
m
البيان ليس قاعدة جدار حماية. إنه وصف للغرض الذي وُجد الوكيل من أجله، وهو الأثر الذي تفتقر إليه برامج الترحيل حاليًا.
## ماذا يعني هذا لبرامج الترحيل
تفترض خرائط طريق التحديث أن نموذج التهديد بشري. ترتّب العمل حسب القيمة التجارية والدين التقني وترتيب التبعيات. جاهزية الوكلاء مسار عمل منفصل بقائمته الخاصة: أي نقاط نهاية تُحل، وأي أفعال تقبل، وأي حسابات خدمة تصل إليها، وأي من تلك الأفعال سيحتاجها الوكيل لمهمة مشروعة. هذه القائمة ليست نفس خريطة سطح الهجوم، لأنها محددة بالاستخدام المقصود لا بإمكانية الوصول.
المقايضة الصادقة هي أن تحديد نطاق القدرات يضيف حدًا يجب صيانته. كل مهمة وكيل جديدة تتطلب تغييرًا في البيان؛ وكل تغيير في البيان هو مراجعة. هذا احتكاك، وهو المقصود. البديل هو ترك الوكيل يرث افتراضات الثقة الضمنية للنظام القديم، مما يعني أن تسامحات النظام تصبح أذونات الوكيل. الاحتكاك هو الضابط.
المقايضة الثانية هي التغطية. حد القدرات أمام الطبقة القديمة يحمي الطبقة القديمة. لا يحمي أدوات الوكيل نفسه، ولا بيانات اعتماده، ولا الأنظمة التي يكتب إليها الوكيل في المصب. تحديد النطاق عند الحد ضروري وغير كافٍ؛ إنه أرخص ضابط يعالج عدم التطابق المحدد الموصوف هنا.
أرخص ضابط قريب المدى هو قائمة سماح للخروج والأفعال أمام الطبقة القديمة. لا يتطلب إعادة كتابة النظام القديم، ولا يتطلب اكتمال الترحيل أولًا. يتطلب جردًا للغرض الذي وُجد الوكيل من أجله، وحدًا يفرضه. هذا عمل أصغر من الترحيل، وهو الجزء الذي يحدد ما إذا كانت افتراضات الترحيل حول التفاعل بمعدل بشري ستصمد عند التلامس مع وكيل.
## الإطار الذي يجب التمسك به
الأنظمة القديمة ليست حديثة التعرض للخطر لأن الوكلاء موجودون. بل تُمارَس حديثًا لأن الوكلاء موجودون، والممارسة تكشف افتراضات كانت موجودة دائمًا. الحل ليس تحصين المحيط حول هدف ثابت. بل تحديد نطاق ما يمكن للوكيل فعله عند الحد، بالبروتوكول الذي يتحدثه، مع معدلات ونطاقات تأثير مرتبطة بالأفعال لا بالهويات وحدها. هذه مشكلة قدرات، وهي قابلة للحل دون انتظار الترحيل.