صُمّمت معظم خدمات الاستضافة حول إنسان يجلس أمام لوحة مفاتيح: نموذج تسجيل، وبطاقة، ولوحة تحكم، ورسالة بريد حين يسوء شيء. ووكيل الذكاء الاصطناعي الذي يحتاج إلى قدرة حوسبة لا يتلاءم مع أي من هذه الخطوات. لا يستطيع حل اختبار captcha، ولا يميّز صفحة صيانة من صفحة معطلة، ولن ينتبه إلى أنه أنشأ الخادم نفسه أربعين مرة.
من المغري أن نقول „أعطه واجهة API فحسب“. لكن هذا هو المتطلب الأول لا الأخير. فيما يلي سبعة نرى أنها مهمة، استناداً إلى بنائنا خادم MCP وواجهة REST API الخاصين بنا للوكلاء. ولكل منها: ما الذي يسوء في غيابه.
1. كل ما يحتاجه الوكيل قابل للبرمجة
يجب أن يعمل إنشاء الموارد وفحصها وتغيير حجمها وحذفها دون متصفح. ويشمل ذلك الأجزاء المملة: معرفة السعر قبل الشراء، والتحقق من توفر السعة في موقع ما، وقراءة كلمة مرور آلة جديدة، والإلغاء.
في غيابه: يقطع الوكيل 80% من الطريق ثم يتوقف عند الخطوة الوحيدة التي تتطلب نقرة، ويضطر إنسان إلى إنهاء العمل على أي حال. والواجهة الجزئية غالباً أسوأ من عدم وجودها، لأنها تغري بأتمتة لا يمكن أن تكتمل.
2. أخطاء يستطيع البرنامج التصرف بناءً عليها
يقرأ الوكيل الرد ويقرر ما يفعله بعد ذلك. ومتن JSON برمز ثابت (402 insufficient_balance، و409 sandbox_paused، و429 budget_exceeded مع وقت إعادة الضبط) شيء يستطيع أن يبني عليه قراره. أما صفحة خطأ HTML، أو رمز 500 برسالة مبهمة، فتتركه يخمّن: وغالباً ما يكرر شيئاً لن ينجح أبداً.
في غيابها: حلقات إعادة المحاولة. فأغلى إخفاقات الوكلاء ليست في الغالب قرارات خاطئة، بل هي الاستدعاء الفاشل نفسه مكرراً آلاف المرات.
3. دفع دون إنسان في المنتصف
مدفوعات البطاقات مليئة بخطوات صُمّمت للتأكد من وجود إنسان: رموز 3-D Secure، وتأكيدات تطبيق المصرف، والتحقق من الهوية. وهي جيدة لمنع الاحتيال ومستحيلة على البرنامج. والرصيد المسبق الدفع، المشحون مقدماً (في حالتنا غالباً بالعملات المستقرة)، يتيح للوكيل أن يدفع مقابل ما يستخدمه دون أن يوافق إنسان على كل خصم.
في غيابه: إما أن يوافق إنسان على كل عملية شراء، وهو ما يُفرغ الفكرة من معناها، أو يعطي أحدهم الوكيل بطاقة، وهي مخاطرة لا ينبغي لأحد أن يقدم عليها.
4. سقوف صارمة للإنفاق
الرصيد المسبق يحصر أسوأ الاحتمالات في ما يحتويه. وقد يكون ذلك كثيراً مع ذلك. والسقف اليومي والشهري بالدولار، الذي تفرضه المنصة لا النوايا الحسنة للوكيل نفسه، يحوّل الوكيل العالق في حلقة إلى خسارة صغيرة. وينبغي أن يفشل السقف بوضوح، بخطأ يتعرف عليه الوكيل، وأن يوقف ما يعمل أو يعلّقه مؤقتاً.
في غيابها: تكتشف الحلقة من الرصيد. ولهذا السبب تتضمن فوترة صناديق الرمل لدينا سقوفاً، وتقترح صفحة ضوابط MCP أي الإجراءات ينبغي أصلاً أن تتطلب موافقة إنسان.
5. حوسبة بالدقة المناسبة
ينتج الوكلاء ثلاثة أنواع مختلفة جداً من العمل:
- ثوانٍ: تشغيل مقطع شيفرة مولّد، أو التحقق من إجابة، أو تجربة إصلاح.
- ساعات: تقييم، أو جمع بيانات من الويب، أو بناء طويل.
- تشغيل دائم: روبوت، أو واجهة API، أو عامل مجدول.
المنصة التي لا تقدم إلا خوادم شهرية تجعل النوع الأول باهظاً على نحو سخيف، والتي لا تقدم إلا صناديق رمل قصيرة العمر تجعل النوع الثالث هشاً. ومهمة مدتها 20 ثانية على آلة تُحتسب بالساعة تدفع ثمن 59 دقيقة من لا شيء. ويبيّن مقال كيف تعمل الفوترة بالثانية أين يتوقف كل نموذج عن أن يكون منطقياً.
في غيابها: إما أن يدفع الوكلاء أكثر من اللازم مقابل العمل القصير، أو يشغّلوا خدمات طويلة على بنية تحتية لم تُصمَّم لتبقى قائمة.
6. العزل افتراضياً
الشيفرة التي يكتبها الوكيل شيفرة لم يراجعها أحد. وينبغي أن تعمل في مكان لا يحوي شيئاً ذا قيمة: لا على مضيف الوكيل نفسه، ولا على خادم يحمل مفاتيحك، ولا على الجهاز الذي يرسل بريدك. وعملياً يعني ذلك آلة افتراضية أو microVM منفصلة لكل مهمة، تُحذف بعدها. ويقارن مقال مستويات العزل للشيفرة غير الموثوقة بين الخيارات، ويشرح مقال آلات Firecracker microVM بلغة بسيطة لماذا تهم النواة الخاصة.
في غيابه: أول حقن للتعليمات (prompt injection) يتسلل إلى الشيفرة المولّدة يصل إلى كل ما يستطيع مضيف الوكيل الوصول إليه.
7. الرؤية ومفتاح الإيقاف
يحتاج الإنسان المسؤول عن الوكيل إلى رؤية ما فعله وإيقافه بسرعة. وهذا يعني الاستخدام والتكلفة لكل مورد، وقائمة بكل ما أنشأه الوكيل، وطريقة لحذفه كله. وينبغي أن تكون بيانات الاعتماد قابلة للإبطال وقصيرة العمر بما يكفي كي لا يبقى المسرَّب منها صالحاً إلى الأبد، مع طريقة لتجديدها لا تحتاج إلى إنسان.
في غيابهما: يصبح التنظيف علم آثار. فالموارد المنسية تواصل احتساب التكاليف، والرمز المسرَّب يواصل العمل.
ما لا يحتاجه الوكلاء
ولا يقل دلالة ما لا يفيد: لوحات تحكم مصممة للبيع الإضافي، ورسائل الترحيب، وباقات حدودها الحقيقية في حاشية، وأسعار لا تظهر إلا بعد التسجيل. لا شيء من ذلك يقرؤه البرنامج، وبعضه مضلل فعلياً لنموذج يأخذ النص حرفياً.
ما لا يزال بلا حل
ليس كل ما هنا مشكلة هندسية محلولة.
- المساءلة. هناك من يتحمل مسؤولية ما يفعله الوكيل بالحساب. وتحتاج المنصات إلى طريقة لربط النشاط المؤتمت بشخص مسؤول دون إجباره على المرور بكل خطوة.
- إساءة الاستخدام. التسجيل المفتوح والمؤتمت بالكامل هو بالضبط ما يريده المسيئون أيضاً. وكل منصة تخدم الوكلاء توازن بين الوصول السلس وبين إنشاء الحسابات بالجملة والتعدين، ولا تملك أي منها جواباً مثالياً.
- المسارات الطويلة. لا يزال الوكلاء يفشلون في العمليات ذات الخطوات العشر أكثر من الاستدعاءات المفردة. ويمكن للبنية التحتية أن تساعد بجعل كل خطوة متساوية الأثر عند التكرار (idempotent) وحالتها سهلة الاستعلام، كي تستأنف إعادة المحاولة العمل بدلاً من تكراره.
أين وصلنا
حاولنا أن نبني لهذه المتطلبات لا أن نلتف حولها: خادم MCP وواجهة REST API يغطيان دورة الحياة كاملة، وأخطاء قابلة للقراءة آلياً، ورصيد مسبق الدفع، وسقوف إنفاق، وصناديق رمل الشيفرة بالثانية للعمل القصير، وخوادم شهرية مثل باقة AI agent للعمل الطويل. وتجد جولة في جانب صناديق الرمل في صندوق رمل لوكلاء الذكاء الاصطناعي. ونفضّل أن تحكم على القائمة بمزاياها هي، فهي قائمة تحقق مفيدة لأي منصة تطلق فيها وكيلاً.
التعليقات
لا تعليقات بعد. كن الأول.