البنية التحتية الوكيلة والواجهة الخلفية الجديدة
· 9 min read · Filippo Spinella · AI, Agents, Infrastructure, Developer Tools
لقد تحدثنا كثيرًا عن الأطر الفاعلية. LangGraph، CrewAI، AutoGen، مجموعات SDK المتنوعة، الحلقة، استدعاء الأدوات، الذاكرة، المخطط، الناقد، المشرف. كل الكلام المفيد جزاكم الله خيرا. لكن كلما نظرت إلى العوامل المستخدمة فعليًا، بدا لي أن الجزء المثير للاهتمام قد انتقل إلى ما دون مستوى إطار العمل.
لم يعد السؤال مجرد: ما هي المكتبة التي أستخدمها لجعل النموذج المرحلي يفكر؟
السؤال الحقيقي هو: أين يعيش هذا العميل عندما يتوقف عن كونه تجريبيًا؟
لأن الوكيل الجاد ليس وظيفة تستدعي النموذج وترجع النص. إنه نظام موزع صغير. يجب عليه قراءة السياق، واستخدام الأدوات، وتنفيذ التعليمات البرمجية، ولمس الملفات، وتذكر القرارات، وطلب الإذن، والفشل بشكل جيد، وإعادة التشغيل، وترك السجلات، وعدم حرق الميزانية وعدم التحول إلى جرافة داخل مستودع الإنتاج.
الإطار هو عجلة القيادة. البنية التحتية هي الطريق والفرامل والجراج والتأمين والشخص الذي يعرف مكان المفاتيح.
##لأن هناك الكثير من الحديث عنه الآن
في عامي 2023 و2024، كانت المحادثة تتمحور حول النماذج بشكل كبير. أي ماجستير؟ كم السياق؟ كم يكلف؟ ما مدى براعته في البرمجة؟
وفي عامي 2025 و2026، تغير الحديث. النماذج جيدة بما فيه الكفاية للقيام بعمل حقيقي، ولكن هذا هو السبب في أن الأجزاء المملة تصبح مرئية: وقت التشغيل، والأمن، والموصلات، والهوية، وقابلية المراقبة، وتنفيذ التعليمات البرمجية، والنشر، والتراجع.
إنه الانتقال الطبيعي من السحر إلى الهندسة.
عندما يحتاج الوكيل فقط إلى إنشاء استجابة، تكون الدردشة كافية. عندما تحتاج إلى فتح طلب سحب، والاستعلام عن قاعدة بيانات، واستدعاء CRM، وبدء مهمة، والتنقل في موقع، وقراءة Slack، وتجميع التعليمات البرمجية وتحديث مستند، فأنت بحاجة إلى نظام تشغيل من حوله.
ليس بالمعنى الحرفي. بالمعنى التنظيمي.
القطعة الأولى: وقت تشغيل حيث يمكن للوكيل أن يستمر
غالبًا ما يعمل الوكيل في خطوات. انظر إلى الحالة، اختر إجراءً، استخدم أداة، راقب النتيجة، قم بتحديث الخطة، كرر.
إذا كانت هذه الحلقة موجودة داخل طلب HTTP واحد، فستواجه مشكلة على الفور. بعض الإجراءات بطيئة. البعض ينتظر المدخلات البشرية. البعض يفشل ويجب المحاولة مرة أخرى. يجب أن ينجو البعض من النشر أو المهلة.
هذا هو المكان الذي تلعب فيه مسارات العمل الدائمة وقوائم الانتظار وخلفيات الوظائف وأجهزة الحالة دورها. إنها ليست ساحرة، لكنها تمثل الفارق بين الوكيل الذي يبدو ذكيًا في العرض التجريبي والوكيل الذي يمكنك ترك العمل أثناء ذهابك لتناول القهوة.
بالنسبة لي، يجب أن يجيب وقت التشغيل الوكيل على أسئلة محددة للغاية:
- أين أحفظ الحالة بين خطوة وأخرى؟
- ماذا يحدث إذا ماتت العملية في منتصف الطريق؟
- هل يمكنني التوقف وطلب الموافقة؟
- هل يمكنني إعادة تشغيل الجولة لأفهم سبب قيامه بهذا الاختيار؟
- هل يمكنني تحديد المدة والذاكرة والأدوات والتكلفة؟
تعمل شركة Vercel بقوة على هذه الجبهة من خلال مجموعات SDK للذكاء الاصطناعي والوظائف وسير العمل والأدوات اللازمة لبناء الوكلاء داخل تطبيقات الويب. ولكن النقطة ليست مجرد Vercel. النقطة المهمة هي أن الوكيل يحتاج إلى منزل تشغيلي، وليس نقطة نهاية واحدة.
##القطعة الثانية: صندوق الرمل، لأن الوكيل يجب أن يكون قادراً على الاتساخ دون أن ينكسر
بمجرد قيام الوكيل بكتابة التعليمات البرمجية أو تنفيذ الأوامر، تكون هناك حاجة إلى وضع الحماية.
قد تبدو كلمة فنية، لكن الفكرة محلية: أعطه طاولة عمل. يمكنه فتح الملفات وتثبيت التبعيات وإجراء الاختبارات وإجراء التجارب وإنشاء المخرجات. إذا أخطأ في الأمر، فقد احتوت الضرر. إذا كان يعمل، تعزيز النتيجة.
يجب أن يتمتع صندوق الحماية الوكيل ببعض الخصائص:
- نظام الملفات المعزولة؛
- حدود وحدة المعالجة المركزية والذاكرة والوقت؛
- شبكة تسيطر عليها؛
- الأسرار محمولة فقط عند الحاجة إليها؛
- سجلات كاملة.
- إمكانية تصدير التحف.
- إعادة ضبط نظيفة بين عمليات التشغيل، عند الضرورة.
يسير Vercel Sandbox في هذا الاتجاه تمامًا: بيئات معزولة لتشغيل التعليمات البرمجية وتثبيت التبعيات والعمل مع الملفات وإنتاج العناصر دون تشغيل كل شيء في وقت تشغيل التطبيق الرئيسي.
هذا الشيء أكثر أهمية مما يبدو. تقفز العديد من النماذج الأولية مباشرة من النموذج إلى النظام الحقيقي. يمكن للنموذج استدعاء الأداة. الأدوات يمكن أن تفعل الأشياء. يبدو كل شيء أنيقًا حتى أول أمر خاطئ، وأول تبعية مثبتة في المكان الخطأ، وأول رمز مميز ينتهي به الأمر في السجل.
صندوق الرمل هو طريقة البالغين للقول: تفضل، ولكن هنا.
##القطعة الثالثة: MCP ومشكلة الموصل
أصبح بروتوكول السياق النموذجي أحد الأجزاء الأكثر إثارة للاهتمام في النظام البيئي لأنه يحاول توحيد شيء يصبح بسرعة غير قابل للإدارة: كيف يكتشف النموذج الأدوات الخارجية ويستخدمها.
وبدون معيار، يصبح كل تكامل بمثابة جزيرة صغيرة. تم إجراء موصل لـ GitHub بطريقة واحدة، وواحد لـ Slack بطريقة أخرى، وواحد لقواعد البيانات ذات دلالات مختلفة، وواحد لأتمتة المتصفح الذي لا يبدو وكأنه شيء.
يقترح MCP لغة مشتركة بين العميل والخادم: الأدوات والموارد والمطالبات والتراخيص والنقل والاكتشاف. إنه لا يحل مشكلة الحكم والأمن بطريقة سحرية، ولكنه يقدم قواعد نحوية.
والمسائل النحوية. عندما يتمكن الوكيل من الاتصال بالعديد من الأدوات، فإن السؤال ليس فقط "هل يمكنه القيام بذلك؟". المشكلة هي «هل يفهم ماذا يستطيع أن يفعل، وبأي حدود، ونيابة عن من، وأي أثر يترك؟».
بالنسبة لي، فإن MCP ليس ضجيجًا لأنه "يقوم باستدعاء الأداة". لقد فعلنا ذلك بالفعل. إنه ضجيج لأنه يحول مركز الثقل من التكامل الفردي إلى كتالوج الأدوات التشغيلية.
في بنية وكيلة جيدة، يصبح MCP نوعًا من لوحة التصحيح:
- GitHub للتعليمات البرمجية والمشكلات؛
- الركود لسياق المحادثة.
- الخطي أو جيرا للعمل المخطط؛
- قاعدة بيانات للقراءة فقط للتحليلات؛
- متصفح أو مكشطة يتم التحكم فيها للمواقع الخارجية؛
- تخزين المستندات؛
- بيئات التنفيذ المعزولة؛
- الأنظمة الداخلية مكشوفة بأذونات صارمة.
الجزء الصعب هو أن كتالوج الأدوات الخالية من السياسات هو مجرد وسيلة أكثر أناقة لخلق الفوضى.
القطعة الرابعة: الهوية والأذونات
هذا هو المجال الذي تغض فيه العديد من العروض التوضيحية أعينها.
وكيل يعمل نيابة عن شخص ما. لذلك يجب أن يكون واضحا من هو موضوع الإجراء.
هل يستخدم أذونات المستخدم؟ من حساب الخدمة؟ من مساحة العمل؟ هل لديك وصول مؤقت أو دائم؟ هل يمكنك قراءة كل شيء أم بعض الموارد فقط؟ هل يمكنك الكتابة؟ هل يمكنك الإلغاء؟ هل يمكنه إرسال رسائل نصية إلى أشخاص حقيقيين؟
إذا لم تجب على هذه الأسئلة بشكل جيد، فسوف تقوم عاجلاً أم آجلاً ببناء مساعد بمفاتيح المنزل ولن يتذكر من أعطاها له.
القاعدة الأساسية التي أحبها هي: يجب أن يكون الوكيل قادرًا على القيام بعمل أقل من الإنسان، وليس أكثر من الإنسان. وعندما يتعين عليه القيام بشيء أكثر خطورة، عليه أن يتوقف ويسأل.
وهذا يعني OAuth، والرمز المميز، والإدارة السرية، وسجل التدقيق، وسياسة الأداة، والقائمة المسموح بها، وخطوة الموافقة. ليست أشياء رومانسية للغاية. الاشياء الضرورية.
القطعة الخامسة: الذاكرة والسياق ولكن دون مراكمة القمامة
يحتاج العملاء إلى الذاكرة، لكن الذاكرة تكون خطيرة عندما تصبح علية.
هناك على الأقل ثلاثة أنواع من الذاكرة:
- تشغيل الذاكرة: ما حدث في هذا التنفيذ؛
- ذاكرة المشروع: الاتفاقيات والقرارات والقيود؛
- الذاكرة الشخصية أو الجماعية: التفضيلات والنبرة والطقوس والعمليات.
وضع كل شيء في الموجه هو الاختصار. إنه يعمل حتى لا يعمل بعد الآن. يجب الاهتمام بالذاكرة المفيدة: فهرستها، وتحديثها، وانتهت صلاحيتها، والتحقق منها، وجعلها قابلة للاستشهاد بها.
الوكيل الذي يتذكر بشكل سيء هو أسوأ من العميل الذي لا يتذكر. لأنه يتحدث بثقة.
لذلك يجب أن تتضمن البنية التحتية عمليات الاسترجاع وملفات التعليمات وقاعدة المعرفة والتضمين عند الحاجة، وكذلك التنظيف. نحن بحاجة إلى ثقافة الذاكرة: ما الذي يدخلها، ومن يوافق عليها، ومتى تضمحل، وكيف أصححها.
القطعة السادسة: الملاحظة والتقييم والإعادة
إذا ارتكب الوكيل خطأً، فإن سجل "النموذج المُسمى" لن يكون كافيًا.
تريد أن ترى الطريق. ما السياق الذي تلقاه؟ ما هي الأدوات التي كانت متاحة؟ ما هي الأداة التي اخترتها؟ بأية حجج؟ ما الرد الذي حصلت عليه؟ كم تكلف؟ أين علقت؟ هل وافق الإنسان على شيء؟ هل نموذج الخطأ أو الأداة أو المطالبة أو البيانات أو الخطأ في الإذن؟
هنا يشبه الوكلاء الأنظمة الموزعة أكثر من روبوتات الدردشة.
أنت بحاجة إلى آثار قابلة للقراءة، وليس فقط سجلات نصية. يجب أن تكون قادرًا على إعادة تشغيل الجولة. من الضروري مقارنة نسختين من نفس الوكيل في المهام المعروفة. نحن بحاجة إلى قياس التراجعات: فهي لا "تستجيب بشكل أفضل" فحسب، بل إنها "تغلق التذكرة الصحيحة دون لمس الملفات غير المرغوب فيها".
تعد عمليات تقييم الوكيل أكثر صعوبة من عمليات تقييم النص لأنها تتضمن إجراءات. لا يكفي مقارنة سلسلة متوقعة. عليك أن تنظر إلى التسلسل والآثار الجانبية وجودة المنتج والوقت والتكلفة وعدد التدخلات البشرية.
الشيء المضحك هو أننا نعود دائمًا إلى هناك: هندسة البرمجيات. الاختبارات والبيئات والتتبعات والتراجعات. باستثناء أن الكود الآن يقرر أيضًا ما يجب فعله بعد ذلك.
القطعة السابعة: الواجهات البشرية
لا يتعين على الوكيل أن يعيش في الدردشة فقط.
بعض الوكلاء يحتاجون إلى لوحة. الآخرين صفحة مع الحالة والسجل. أخرى من زر "الموافقة". المزيد من التعليقات المضمنة. لا يزال البعض الآخر من CLI.
واجهة المستخدم تغير السلوك. إذا كانت الطريقة الوحيدة للتحكم في الوكيل هي كتابة رسالة طويلة، فسيقوم المستخدم بإعطاء الوكيل تعليمات غامضة. ومع ذلك، إذا رأى الخطة والاختلافات والمصادر والمخاطر والإجراء التالي، فيمكنه التدخل بدقة.
تشتمل البنية التحتية اللائقة للوكيل على أسطح التحكم:
- الوضع الحالي.
- خطة قابلة للتحرير.
- المصنوعات اليدوية المنتجة؛
- فرق؛
- طلبات الموافقة؛
- التسلسل الزمني.
- زر التوقف؛
- زر إعادة المحاولة؛
- أذونات مرئية.
يبدو الأمر تافها، لكنه ليس كذلك. غالبًا ما يكون الفرق بين "الذكاء الاصطناعي المخيف" و"المساعد الموثوق" هو أن الأخير يوضح لك مكان وجوده.
المكدس العقلي
إذا كنت سأرسمه اليوم، فسيكون الحد الأدنى لمجموعة الوكيل هو:
- النموذج: الاستدلال، والتوليد، واستدعاء الأدوات، والوسائط المتعددة إذا لزم الأمر.
- التنسيق: الحلقة، الخطوة، المخطط، السياسة، الإنسان في الحلقة.
- وقت تشغيل متين: سير العمل، وقائمة الانتظار، وإعادة المحاولة، والإيقاف المؤقت، والاستئناف.
- Sandbox: تنفيذ التعليمات البرمجية، ونظام الملفات المعزول، والقيود، والتحف.
- طبقة الأدوات: MCP، واجهة برمجة التطبيقات الداخلية، المتصفح، قاعدة البيانات، المستودع.
- طبقة الهوية: OAuth، النطاق، السر، التدقيق، السياسة.
- طبقة الذاكرة: سياق المشروع، الاسترجاع، التعليمات، انتهاء الصلاحية.
- إمكانية الملاحظة: مقاييس التتبع وإعادة التشغيل والتقييم والتكلفة والجودة.
- سطح المنتج: قم بالدردشة عند الحاجة، ولوحة القيادة عند الحاجة، والمراجعة عندما يكون الأمر مهمًا.
يغطي الإطار الوكيل بشكل أساسي النقاط 2 وجزءًا من النقطة 1. والباقي هو العمل الحقيقي.
ما سأفعله عمليًا
إذا قال لي الفريق "نريد وكلاء في الإنتاج"، فلن أبدأ بعشرة وكلاء.
سأبدأ بسير عمل صغير ومتكرر ويمكن ملاحظته. على سبيل المثال: فتح تقارير العلاقات العامة الخاصة بالصيانة، وتحديث الوثائق من الإصدارات المغلقة، وإعداد مراجعة أسبوعية، وفرز الأخطاء المكررة، وإنشاء اختبارات للملفات المتأثرة.
ثم سأضع حدودًا واضحة جدًا:
- لا كتابة بدون فروع أو رمل؛
- لا أسرار في الموجه؛
- الأدوات في القائمة المسموح بها؛
- موافقة الإنسان على الإجراءات الخارجية؛
- سجل وتتبع إلزامي؛
- الميزانية لكل تشغيل؛
- الإخراج قابل للفحص دائمًا.
عندها فقط سأتوسع.
الوكلاء لا يفشلون لمجرد أن النماذج أخطأت في فهمهم. إنهم يفشلون لأننا نضعهم في بيئات غامضة، بأذونات مربكة وتوقعات مسرحية.
##قراءتي
البنية التحتية للوكالة مملة بأفضل طريقة.
إنه ليس الجزء الذي يجعلك تصفق في العرض التوضيحي. إنه الجزء الذي يتيح لك استخدام العرض التوضيحي صباح يوم الاثنين، مع أشخاص حقيقيين، وبيانات حقيقية، وعواقب حقيقية.
لن يتم تحديد مستقبل الوكلاء فقط من خلال من لديه أفضل قدوة. سيقرره من يبني أفضل مكان ليعمل فيه: منعزل عندما يقوم بالتجارب، متصل عند الحاجة، يمكن ملاحظته دائمًا، مخول بمعايير ومتواضع بما يكفي للتوقف عندما لا يعرف.
هذا هو المكان الذي يتوقف فيه العملاء عن كونهم لعبة ويصبحون بنية تحتية.