- تختلف وكلاء الذكاء الاصطناعي عن تطبيقات إدارة التعلم العادية من خلال امتلاكها لتدفق التحكم، ودمج النماذج والأدوات والذاكرة والأهداف الواضحة.
- تعمل بروتوكولات مثل MCP و A2A و NLWeb على توحيد كيفية وصول الوكلاء إلى الأدوات والتعاون والتفاعل مع الويب.
- تعتمد العوامل القوية على اختيار النموذج الجيد، والأدوات المحددة جيدًا، والتعليمات الدقيقة، وأنماط التنسيق، والضوابط.
- تتيح الأطر الحديثة والحوسبة السحابية، بالإضافة إلى هذه البروتوكولات، إنشاء أنظمة بيئية متعددة العوامل قابلة للتوسع في المنتجات الحقيقية.
تعمل وكلاء الذكاء الاصطناعي على تحويل البرامج من مساعدين سلبيين إلى المتعاونون المستقلون بإمكانها إدراك بيئتها، والتفكير في الأهداف المعقدة، واتخاذ الإجراءات نيابةً عنا. بالنسبة للمطورين، يُغيّر هذا التحوّل كل شيء: فبدلاً من ربط مسارات العمل الثابتة بنموذج التعلم المحدود، يتم تصميم أنظمة يكون فيها النموذج نفسه هو الذي يُوجّه مسار التحكم، ويُنسّق الأدوات، ويتعاون مع العناصر والخدمات الأخرى.
إذا كنت ترغب في بناء شيء جاد، أنظمة وكلاء من الدرجة الإنتاجيةلم يعد فهم البروتوكولات الناشئة أمراً اختيارياً.أصبحت الطرق الموحدة التي تُمكّن الوكلاء من الوصول إلى الأدوات (MCP)، والتواصل فيما بينهم (A2A)، والتفاعل مع الويب عبر اللغة الطبيعية (NLWeb) تُشكّل بسرعة العمود الفقري لـ"نظام الوكلاء البيئي". في الوقت نفسه، لا يزال من الضروري إتقان العناصر الأساسية للوكلاء أنفسهم: النماذج، والأدوات، والتعليمات، وأنماط التنسيق، والضوابط.
ما هو بالضبط وكيل الذكاء الاصطناعي، وكيف يختلف عن نموذج التعلم المحدود العادي؟
يُفهم وكيل الذكاء الاصطناعي على أفضل وجه باعتباره نظامًا كاملاً مبنيًا حول نموذج التعلم الموجه بالتعلم، وليس مجرد النموذج نفسه.. التعريف المقبول أكاديمياً (على سبيل المثال في ستانفورد CS221) يصف العامل بأنه كيان حسابي موجود في بيئة، قادر على إدراكها من خلال أجهزة الاستشعار والتصرف عليها من خلال المشغلات لزيادة فرص النجاح فيما يتعلق بهدف معين.
من الناحية العملية للبرمجيات، تجمع وكلاء الذكاء الاصطناعي الحديثة أربعة مكونات.: و نموذج لغة كبير لأغراض التفكير المنطقي، والوصول إلى الأدوات الخارجية وواجهات برمجة التطبيقات، ونوع من الذاكرة لتتبع السياق بمرور الوقت، وهدف أو دور محدد بوضوح. على عكس روبوت الدردشة البسيط الذي يجيب على الأسئلة فقط، يمكن للوكيل التخطيط، واستدعاء الأدوات، والتفاعل مع مخرجاتها، وتوجيه سير العمل بشكل متكرر حتى يتم تحقيق الهدف.
من مصادر الالتباس الشائعة الخلط بين "العارضة" و"الوكيل".يُعدّ نموذج مثل GPT-4 أو Llama 3 بمثابة "دماغ" قويّ ولكنه سلبي: فهو لا يفعل شيئًا حتى تُرسل إليه إشارة، ولا يستطيع بمفرده إرسال رسائل بريد إلكتروني، أو الوصول إلى واجهات برمجة التطبيقات، أو تحديث قواعد البيانات. أما الوكيل، فيُغلّف النموذج في حلقة من الإدراك والاستدلال والتنفيذ. ويستخدم تنبؤات النموذج لاختيار الأداة المناسبة، وتحديد وقت طلب التوضيح من المستخدم، ومتى يتوقف.
الفرق الرئيسي هو من يتحكم في سير العملفي البرامج التقليدية، يحدد الكود التسلسل: إذا حدث أ، ثم ب، ثم ج. أما في الوكيل، فيقرر نظام إدارة التعلم الخطوة التالية بناءً على الحالة الراهنة. وقد يختار البحث عن طلب، أو فتح تذكرة دعم، أو إحالة الحالة إلى وكيل آخر، كل ذلك من خلال نفس الطلب عالي المستوى.
تتفاوت الوكلاء أيضًا في درجة تعقيدها، بدءًا من الأنظمة التفاعلية البسيطة وصولًا إلى البنى القائمة على التعلم والأهداف.. لا يزال التصنيف الكلاسيكي من راسل ونورفيج مفيدًا لفهم المشهد: ستحصل على عوامل تفاعلية بسيطة (قواعد إذا-ثم بحتة)، وعوامل تفاعلية قائمة على النموذج (مع حالة داخلية دنيا)، وعوامل قائمة على الهدف (تخطط لتحقيق نتيجة مرغوبة)، وعوامل قائمة على المنفعة (تعمل على تحسين درجة عددية على العديد من النتائج المحتملة) وعوامل التعلم (التي تكيف سياستها بناءً على التغذية الراجعة).
لماذا تُعدّ البروتوكولات مهمة في عصر وكلاء الذكاء الاصطناعي
مع ازدياد قدرات وانتشار البرامج الآلية، تظهر ثلاث مشكلات بسرعة: تكلفة التكامل، وقابلية التشغيل البيني، والأمن.إنّ استخدام أكواد ربط مخصصة لكل واجهة برمجة تطبيقات أو نظام شريك لا يُجدي نفعاً على نطاق واسع. كما أنّ استخدام تنسيقات خاصة ومخصصة يعيق التعاون بين الأدوات والبرامج من مختلف الموردين. وكل عملية تكامل جديدة تزيد من نقاط الضعف الأمنية.
تهدف البروتوكولات التي تركز على العامل إلى حل هذه المشكلات تحديدًا. من خلال تحديد معايير مفتوحة لـ: كيفية قيام المضيفين بعرض الأدوات والسياق لـ LLMs (بروتوكول سياق النموذج، أو MCP)، وكيفية تواصل الوكلاء مع وكلاء آخرين عبر الحدود التنظيمية والتقنية (من وكيل إلى وكيل، أو A2A)، وكيفية عرض مواقع الويب لمحتواها وإجراءاتها بطريقة تعتمد على اللغة الطبيعية أولاً لكل من البشر والوكلاء (شبكة اللغة الطبيعية، أو NLWeb).
بالنسبة للمطورين، تعمل هذه البروتوكولات كـ "محولات عالمية" و"بطاقات تعريف" للوكلاء والخدماتبدلاً من برمجة عشرات عمليات التكامل يدويًا، يمكنك التكامل مرة واحدة مع خوادم MCP أو النظراء المتوافقين مع A2A أو مواقع NLWeb، ودع البروتوكول يتولى عملية الاكتشاف والقدرات والمصادقة. هذا يقلل بشكل كبير من منطق التكامل المخصص، ويتيح لك تغيير النماذج أو الأدوات دون الحاجة إلى إعادة كتابة جميع التعليمات البرمجية.
وفي الوقت نفسه، يصبح الأمن على مستوى البروتوكول أمراً ضرورياًإن التحكم في الوصول، والمصادقة الموحدة، ووصف القدرات الواضح على مستوى البروتوكول يجعل من السهل جدًا التفكير في من يمكنه فعل ماذا، ومن أين، وتحت أي قيود - وهو أمر بالغ الأهمية في بيئات المؤسسات حيث قد يُسمح للوكلاء بالتعامل مع المخزون أو المدفوعات أو بيانات العملاء الحساسة.
بروتوكول سياق النموذج (MCP): محول عالمي للأدوات والبيانات
بروتوكول سياق النموذج هو معيار مفتوح يحدد كيفية قيام التطبيقات بتوفير الأدوات والبيانات السياقية للوكلاء القائمين على نموذج اللغة واللغة.من الناحية المفاهيمية، يقع MCP بين وكلائك وأنظمتك الحالية - قواعد البيانات، وواجهات برمجة تطبيقات SaaS، والخدمات الداخلية - ويحولها إلى مجموعة موحدة وقابلة للاكتشاف من القدرات.
تتبع MCP بنية العميل والخادم بثلاثة أدوار رئيسية: المضيف (تطبيق إدارة التعلم مثل بيئة التطوير المتكاملة أو عميل الدردشة أو وقت تشغيل الوكيل) الذي يبدأ الاتصالات، ومكونات العميل داخل هذا المضيف التي تحافظ على اتصالات فردية مع خوادم MCP، والخوادم نفسها، وهي برامج خفيفة الوزن تعرض قدرات محددة.
داخل بروتوكول MCP، تُعلن الخوادم عن ثلاث وظائف أساسية. يمكن للوكلاء استخدامها بطريقة متسقة: الأدوات والموارد والتوجيهات. الأدوات عبارة عن إجراءات منفصلة - مثل "الحصول على حالة الطقس" و"شراء منتج" و"البحث عن رحلات طيران" - مع أسماء وأوصاف ومخططات إدخال/إخراج. الموارد عبارة عن عناصر بيانات للقراءة فقط مثل الملفات أو صفوف قواعد البيانات أو السجلات، والتي يمكن أن تكون نصية أو ثنائية. التوجيهات عبارة عن قوالب مُعدة مسبقًا تُغلف أنماط هندسة التوجيهات أو التدفقات متعددة الخطوات.
يُعد اكتشاف الأدوات الديناميكي أحد أكبر إنجازات MCPبدلاً من تضمين وظيفة "بحث الرحلات" في برنامج مساعد السفر بتوقيع محدد، يتصل البرنامج بخادم MCP الخاص بشركة الطيران ويطلب قائمة إمكانياته. يُعيد الخادم وصفًا قابلاً للقراءة آليًا للأدوات، ومعاملاتها، والاستجابات المتوقعة. عندما تُضيف شركة الطيران أداة "ترقية الحجز"، يكتشفها برنامجك تلقائيًا دون الحاجة إلى تعديلات برمجية، طالما أنك تلتزم بشروط عقد MCP.
كما أن MCP مستقل عن النموذج بشكل متعمدبما أن البروتوكول يركز على الإمكانيات والسياق، وليس على واجهة برمجة تطبيقات أي مورد محدد، فإنه يمكن استخدام خادم MCP نفسه من أنظمة إدارة التعلم المختلفة أو أطر عمل الوكلاء. يتيح لك هذا تجربة تبديل النماذج أو استراتيجيات النماذج المتعددة (مثل استخدام نموذج صغير وبسيط للتدفقات البسيطة ونموذج قوي للاستدلال المعقد) دون الحاجة إلى إعادة عمليات التكامل.
ومن الفوائد الأخرى الأمن الموحديمكن لمنصة إدارة نقاط البيع (MCP) أن تتضمن آليات مصادقة متسقة، مما يجعلها أسهل بكثير في الصيانة من التعامل مع مجموعة كبيرة من عمليات المصادقة المخصصة لكل واجهة برمجة تطبيقات خارجية. بالنسبة للمؤسسات، يعني هذا توسعًا أكثر سلاسة من "تكامل واحد في بيئة الاختبار" إلى "مئات من خوادم MCP في بيئة الإنتاج" دون فقدان السيطرة على المفاتيح والصلاحيات.
يوضح المثال الملموس دور MCP بشكل أفضلتخيل مستخدمًا يطلب من مساعد سفر يعمل بالذكاء الاصطناعي "إيجاد رحلة طيران من بورتلاند إلى هونولولو وحجزها". يتصل المساعد، بصفته عميل MCP، بخادم MCP الخاص بشركة الطيران، ويستعرض أدوات مثل "search_flights" و"book_flight"، ثم يستدعي "search_flights" بالمعلمات الصحيحة، ويتلقى نتائج JSON، ويعرضها للمستخدم، ثم يستدعي "book_flight" بناءً على الخيار المُختار. لا يتصل المساعد أبدًا بواجهات برمجة التطبيقات الداخلية لشركة الطيران مباشرةً؛ بل يستخدم لغة MCP فقط.
بروتوكول التعاون بين عدة وكلاء (A2A):
بينما يركز بروتوكول MCP على ربط الوكلاء بالأدوات والبيانات، فإن بروتوكول Agent-to-Agent يتعلق بربط الوكلاء ببعضهم البعضبمجرد أن تتجاوز مفهوم "العامل الخارق" المتجانس إلى نظام بيئي من الوكلاء المتخصصين (السفر، والفواتير، والخدمات اللوجستية، والدعم...)، أنت بحاجة إلى طريقة واضحة لهم لاكتشاف بعضهم البعض، وتبادل السياق والتعاون في المهام المشتركة.
تم تصميم A2A لدعم هذا النوع من التنسيق الموزع بين المؤسساتيُمكّن هذا النظام وكلاء من شركات وأنظمة وبيئات استضافة مختلفة من التعاون لتلبية طلبات المستخدمين دون الحاجة إلى تحديد مسارات التفاعل مسبقًا. فعلى سبيل المثال، يستطيع وكيل سفر متوافق مع بروتوكول A2A الاتصال بوكيل طيران أو وكيل فندق أو وكيل تأجير سيارات، جميعها من تطوير فرق مختلفة تمامًا.
يعرض كل وكيل A2A بطاقة وكيل قابلة للقراءة آلياً يؤدي هذا دورًا مشابهًا لقائمة إمكانيات MCP، ولكن على مستوى الوكيل وليس على مستوى الأداة. تحتوي بطاقة الوكيل على اسم الوكيل، ووصف بلغة طبيعية لما يقوم به، وقائمة بالمهارات مع شرح لمتى يجب استدعاؤه، وعنوان URL لنقطة النهاية الحالية، ومعلومات الإصدار، وعلامات مثل ما إذا كان يدعم الاستجابات المتدفقة أو الإشعارات الفورية.
أما من جانب المتصل، فإن وكيل التنفيذ مسؤول عن تسليم السياق وإدارة التفاعلعندما يقرر وكيل محلي تفويض مهمة فرعية، يقوم منفذه بتجميع المحادثة الحالية والحالة ذات الصلة وأي قيود، ويرسلها إلى الوكيل البعيد عبر بروتوكول A2A. يقوم الوكيل البعيد بتشغيل أدواته الداخلية وحلقة LLM الخاصة به، ثم يعيد النتيجة دون أن يحتاج المتصل إلى معرفة تفاصيلها الداخلية.
يتم إرجاع نتيجة المهمة البعيدة المكتملة كعنصر.تتضمن الحزمة عادةً مخرجات المهمة، ووصفًا موجزًا لما تم إنجازه، والسياق النصي الذي تم تبادله خلال البروتوكول. بمجرد تسليم الحزمة، يمكن إغلاق اتصال A2A، مما يحافظ على نطاق كل تفاعل وكفاءته مع إتاحة تعاون مثمر.
بالنسبة للمهام طويلة الأمد أو غير المتزامنة، غالبًا ما تعتمد A2A على قائمة انتظار الأحداثبدلاً من إبقاء الاتصالات مفتوحة لعدة دقائق بينما يقوم وكيل بعيد بمعالجة البيانات أو ينتظر أنظمة خارجية، تتولى قائمة انتظار الأحداث مهمة تمرير الرسائل وتحديثها. وهذا أمر بالغ الأهمية في أنظمة الوكلاء المتعددين المستخدمة في بيئات الإنتاج، حيث تُعدّ مرونة الشبكة وإعادة المحاولات والتحكم في تدفق البيانات عوامل حاسمة.
تتشابه فوائد A2A مع فوائد MCP ولكن على مستوى النظام البيئيستحصل على تعاون مُحسّن بين العملاء ذوي الخلفيات المتنوعة، ومرونة في اختيار أفضل استراتيجية لإدارة دورة حياة العميل أو ضبطها لكل عميل، بالإضافة إلى نظام مصادقة مُدمج يضمن أمان المكالمات بين العملاء وقابليتها للتدقيق. وبذلك، يصبح من الممكن إنشاء "فرق من العملاء" من موردين متعددين بدلاً من محاولة حشر جميع الإمكانيات في نظام واحد متكامل.
شبكة اللغة الطبيعية (NLWeb): جعل الويب سهل الاستخدام للوكلاء
تم بناء شبكة الإنترنت حول المستندات ولغة HTML، وليس حول المحادثات والوكلاءلطالما اعتمد المستخدمون على القوائم ومربعات البحث لاستخراج المعلومات من مواقع الويب، بينما كان الوصول الآلي يعتمد عادةً على تقنيات استخراج البيانات غير الموثوقة أو واجهات برمجة التطبيقات المخصصة. يقترح NLWeb نموذجًا مختلفًا: مواقع ويب تتحدث اللغة الطبيعية بشكل أصيل، لكل من البشر وأنظمة الذكاء الاصطناعي.
تتمحور عملية نشر NLWeb حول تطبيق NLWeb مركزي— هو الكود البرمجي الأساسي الذي يستقبل الأسئلة باللغة الطبيعية، ويتصل بوحدات التخزين والنماذج، ويعيد إجابات منظمة. يمكنك اعتباره "محرك اللغة" لموقعك، حيث يُنسق عمليات التضمين والبحث المتجهي والاستدلال المنطقي اللغوي.
يحدد بروتوكول NLWeb نفسه القواعد الأساسية لهذا التفاعل باللغة الطبيعيةيُوحّد هذا النظام طريقة إرسال الأسئلة وكيفية استلام الإجابات، عادةً بتنسيق JSON باستخدام مصطلحات مثل Schema.org. وكما وحّد HTML مشاركة المستندات، يهدف NLWeb إلى توحيد الوصول إلى محتوى الموقع وإجراءاته باستخدام اللغة، مما يمهد الطريق لـ "شبكة ذكاء اصطناعي".
كل مثيل من NLWeb يعمل أيضًا كخادم MCPهذا يعني أنه يمكنه إتاحة الأدوات (مثل طريقة "السؤال") وموارد البيانات لأنظمة الذكاء الاصطناعي الخارجية عبر منصة MCP. من وجهة نظر الوكيل، يصبح موقعك مجرد نقطة نهاية أخرى لمنصة MCP: حيث يمكنه استدعاء "السؤال" لطرح سؤال، وتلقي رد منظم مرتبط ببيانات حقيقية في كتالوجك، وتجنب عرض منتجات أو صفحات غير موجودة.
يعتمد NLWeb بشكل كبير على نماذج التضمين وقواعد بيانات المتجهات.عند استيراد محتوى موقعك الإلكتروني - قوائم المنتجات، أوصاف الفنادق، أو منشورات المدونة - يقوم NLWeb بتحويلها إلى تمثيلات متجهة وتخزينها في مخزن متجهات متوافق مثل Qdrant أو Milvus أو Azure AI Search أو Snowflake أو Elasticsearch. عند الاستعلام، يسترجع NLWeb العناصر الأكثر تشابهًا ويمررها، مع سؤال المستخدم، إلى نموذج لغة منطقية (LLM) لصياغة إجابة تستند إلى المحتوى الفعلي.
يُعد موقع حجز السفر مثالاً رائعاً على تطبيق تقنية NLWeb عملياً.تقوم باستيعاب بيانات منظمة للرحلات الجوية والفنادق والباقات السياحية (ويُفضل استخدام Schema.org أو خلاصات RSS)، وإنشاء تضمينات وتخزينها. عندما يكتب المستخدم عبارة "ابحث لي عن فندق مناسب للعائلات في هونولولو مع مسبح الأسبوع المقبل" في مربع الدردشة، يستعلم NLWeb من مخزن البيانات المتجهة عن الفنادق ذات الصلة، ويترك لـ LLM تفسير عبارة "مناسب للعائلات" وغيرها من القيود المرنة، ثم يُعيد إجابة بلغة طبيعية مدعومة ببيانات حقيقية عن الفنادق المتاحة. ويتيح نفس نظام NLWeb، عبر واجهة MCP الخاصة به، لوكيل سفر خارجي الاستفسار، على سبيل المثال، عن المطاعم النباتية القريبة من تلك الفنادق، والحصول على بيانات JSON متسقة وقابلة للاستخدام الآلي.
متى يكون من المنطقي بناء وكيل ذكاء اصطناعي على الإطلاق
لا تحتاج كل مشكلة إلى وكيل؛ ففي بعض الأحيان تكون الخدمة الحتمية البسيطة أفضل.تتألق الوكلاء عندما لا يمكن بسهولة التقاط سير العمل كمجموعة جامدة من القواعد، أو عندما يكون هناك اعتماد كبير على البيانات غير المهيكلة، أو عندما يجعل عدد الاستثناءات والحالات الشاذة صيانة القواعد أمرًا شاقًا.
ثلاث مجموعات من حالات الاستخدام مناسبة بشكل خاص للوكلاء: اتخاذ القرارات المعقدة (على سبيل المثال، تحديد ما إذا كان سيتم الموافقة على رد أموال العميل بموجب سياسات دقيقة)، ومجموعات القواعد التي يصعب الحفاظ عليها (مثل مراجعات أمان البائعين المعقدة أو عمليات التحقق من الامتثال)، والتدفقات التي تهيمن عليها اللغة الطبيعية (معالجة المطالبات، وطلبات العملاء الحرة، ومهام البحث).
من الأساليب المفيدة النظر إلى الأنظمة التي نمت عبر ترقيعات لا نهاية لها وقواعد خاصة بالحالات الخاصة.إذا واجه حتى كبار المهندسين صعوبة في التنبؤ بالسلوك أو في ترميز تغييرات السياسات الجديدة دون إحداث خلل في شيء آخر، فمن المرجح أن تكون المشكلة الأساسية دلالية وليست منطقية بحتة. وهذا هو المجال الأمثل لوكيل مدعوم بنموذج التعلم القائم على اللغة (LLM) قادر على تحليل النصوص والسياسات والأمثلة.
في المقابل، بالنسبة للمهام الحتمية للغاية ذات المدخلات والمخرجات الواضحة، يكون الكود التقليدي عادةً أرخص وأسرع وأكثر موثوقية.إذا كانت وظيفتك هي "تحويل هذا الرقم إلى تنسيق آخر" أو "تشغيل استعلام SQL هذا وإرجاع الصفوف"، فإن إضافة حلقة وكيل في الأعلى ربما يكون تعقيدًا غير ضروري.
المكونات الأساسية لوكيل الذكاء الاصطناعي
على الرغم من الضجة المثارة حولها، فإن البنية الداخلية لعامل مصمم جيدًا بسيطة للغاية. تتلخص جميع الأنماط تقريبًا في ثلاثة أركان: النموذج الذي يقوم بالاستدلال، والأدوات التي تتصل بالعالم الخارجي، والتعليمات التي تقيد وتوجه السلوك.
النموذج هو محرك اتخاذ القرارتتفاوت نماذج التعلم الموجه (LLMs) المختلفة في جودة الاستدلال وسرعة الاستجابة والتكلفة. وتتمثل إحدى الاستراتيجيات الشائعة والعملية في البدء بنموذج عالي الكفاءة لتحديد مستوى الجودة الأساسي وفهم معايير الجودة في مجال العمل، ثم اختبار نماذج أصغر أو أقل تكلفة تدريجيًا لمهام فرعية مثل التصنيف أو الاسترجاع حيث لا يتطلب الأمر استدلالًا فائقًا.
تُوسّع الأدوات نطاق عمل الوكيل ليتجاوز مجرد النص.هي عبارة عن وظائف أو واجهات برمجة تطبيقات أو خدمات يمكن للوكيل استدعاؤها: كالاستعلام عن قاعدة بيانات، أو إرسال بريد إلكتروني، أو البحث في الإنترنت، أو التفاعل مع واجهة مستخدم قديمة من خلال نموذج استخدام حاسوبي، وما إلى ذلك. الأدوات المصممة جيدًا موثقة وقابلة لإعادة الاستخدام بين الوكلاء، ومن الأفضل أن تكون متاحة عبر بروتوكولات قياسية مثل MCP.
تُعتبر التعليمات الجزء الأكثر استهانةً في العميلأنت بحاجة إلى أكثر من مجرد "تقديم المساعدة". فالإرشادات عالية الجودة تُوضح كيفية تقسيم المهام، وكيفية التصرف عند نقص المعلومات، والأدوات المُفضلة في كل موقف، وما يُعتبر نجاحًا، وما يجب تجنبه. تُعيد العديد من الفرق استخدام إجراءات التشغيل القياسية الحالية، أو وثائق مركز المساعدة، أو أدلة العمل الداخلية بنجاح، وذلك بتحويلها إلى إرشادات مُرقمة مُلائمة لنموذج إدارة التعلم، يُمكن اتباعها.
أصبح من الشائع بشكل متزايد إنشاء التعليمات أو تحسينها تلقائيًا باستخدام نماذج التعلم الآلي نفسهاعلى سبيل المثال، يمكنك إدخال مقالة من مركز المساعدة في موجه تلقائي يطلب من النموذج إعادة كتابتها كمجموعة واضحة ومرقمة من تعليمات الوكيل، بما في ذلك معالجة الحالات الشاذة بشكل صريح. هذا يحافظ على توافق السلوك مع وثائقك مع تطورها.
أنماط التنسيق: أنظمة الوكيل الواحد مقابل أنظمة الوكلاء المتعددين
في الخفاء، يتم تنفيذ العمليات بشكل متكرر.مراقبة الوضع الحالي، وتحديد الإجراء المطلوب، والتنفيذ (غالباً عبر أداة)، وتحديث السياق، وتكرار العملية حتى يتم استيفاء شرط التوقف (تحقيق الهدف، أو حدوث خطأ، أو تدخل المستخدم، أو تجاوز حدود النظام). هذه "الحلقة التفاعلية" هي ما يحوّل استدعاء LLM لمرة واحدة إلى محرك سير عمل مستمر.
أبسط بنية هي عبارة عن وكيل واحد مزود بأدواتيستقبل هذا النظام رسائل المستخدمين، ويحللها، ويحدد الأدوات التي يجب استدعاؤها، ثم يُعيد الإجابات. غالبًا ما تُوفر الأطر البرمجية مكونًا تشغيليًا يستمر في استدعاء النموذج حتى يتم استيفاء معيار إنهاء معين، مثل "عدم وجود استدعاءات أدوات مفيدة أخرى" أو "إنتاج مخرجات مُهيكلة". يُعد هذا النمط مثاليًا للإصدارات المبكرة وللمشاكل ذات النطاق المحدد جيدًا.
مع ازدياد التعقيد، غالباً ما تنتقل الفرق إلى هياكل متعددة العوامل.هناك نمطان رئيسيان. في نمط المدير، يقوم وكيل "منسق" مركزي بتفويض المهام الفرعية إلى وكلاء متخصصين مُستخدمين كأدوات - على سبيل المثال، مترجمون إلى لغات مختلفة، ووكيل بحث، وناقد. يحتفظ المدير بالسيطرة الشاملة ويربط كل شيء معًا.
النمط الثاني أكثر لا مركزيةهنا، يُحيل الموظفون المهام إلى زملائهم عندما يكتشفون أن الطلب يقع خارج نطاق اختصاصهم. يمكن لموظف الفرز توجيه رسائل العملاء إلى موظفي الدعم الفني أو المبيعات أو إدارة الطلبات، ولكل منهم تعليماته وأدواته الخاصة. وتنتقل عملية التحكم بين الموظفين دون وجود مُخطط مركزي واحد.
يمكن دمج كلا النمطين بشكل طبيعي مع A2A على نطاق أوسع. داخل حدود المنتج أو الخدمة المصغرة، قد تستخدم نموذج المنسق بالإضافة إلى المتخصصين، بينما عبر الشركات أو الأقسام، تعتمد على A2A للتحدث إلى وكلاء مملوكين خارجيًا يعلنون عن قدراتهم من خلال بطاقات الوكلاء.
ضوابط الحماية: الحفاظ على سلامة وموثوقية الأنظمة المستقلة
إن منح الوكلاء الاستقلالية يعني أيضاً قبول مخاطر جديدةقد تتسبب هذه الأنظمة في تسريب بيانات حساسة، أو إجراء تغييرات غير مصرح بها، أو اتخاذ إجراءات ذات تأثير مالي أو على السمعة. وتُعدّ الضوابط بمثابة طبقة حماية تُدير هذه المخاطر دون المساس بفعالية النظام.
يتضمن التصميم الدفاعي عادةً طبقات متعددة من الحواجز الواقية. بعضها يعمل على المدخلات (حظر أو تنظيف الطلبات الضارة أو الخارجة عن النطاق)، وبعضها على قرارات النموذج الوسيطة (التحقق مما إذا كان الإجراء مسموحًا به قبل تنفيذه)، وبعضها على المخرجات (التصفية من أجل السلامة أو الامتثال أو تسريب البيانات قبل مغادرة الاستجابات للنظام).
في العديد من التطبيقات، تعمل الضوابط "بالتوازي" مع التقدم المتفائل للوكيلتستمر حلقة الوكيل في التقدم، لكن خطوات محددة - مثل استدعاء أداة قد تُعدّل البيانات - تُغلّف بفحوصات وقائية. إذا اكتشف الفحص الوقائي انتهاكًا، فإنه يستطيع إيقاف الإجراء، أو إصدار استثناء، أو تصعيد الأمر إلى مُشغّل بشري.
بعض الضوابط نفسها مدفوعة ببرامج الماجستير في القانون التي تركز على الحدود والمخاطر أو حتى وكلاءعلى سبيل المثال، يمكنك الاحتفاظ ببرنامج مخصص لكشف حالات التخلي عن الخدمة، يقوم بتقييم رسائل العملاء الواردة وتحديد الرسائل التي تشير إلى احتمالية عالية للإلغاء. ثم يستخدم نظام حماية متقدم هذه الإشارة لتفعيل إجراءات الاحتفاظ بالعملاء أو اشتراط مراجعة بشرية إلزامية قبل إنهاء التفاعل.
تشمل الضوابط التشغيلية أيضاً حدوداً صارمة وفتحات هروب.تساهم عوامل مثل الحد الأقصى لعدد الخطوات لتجنب الحلقات اللانهائية، والعتبات القائمة على المخاطر التي تجبر على موافقة الإنسان على الإجراءات الحساسة، والخيارات البديلة الواضحة عندما تكون ثقة النموذج منخفضة، في النشر الآمن في بيئات العالم الحقيقي.
من النظرية إلى التطبيق: تصميم تدريجي لوكيل دعم الطلبات
لتوضيح هذه الأفكار، لننظر في تطور نظام دعم الطلبات لمتجر إلكترونيعادةً ما تكون النسخة الأولية مجرد نقطة نهاية تفاعلية: عند إعطاء رقم الطلب، يتم جلب حالته من قاعدة البيانات وإعادتها. لا يوجد منطق، ولا ذاكرة، ولا سير عمل - فهذا ليس وكيلاً بعد.
تتمثل الخطوة الأولى في تمكين النموذج من التحكم في سير العملبدلاً من افتراض وجود رقم الطلب، يتم إدخال المحادثة كاملةً إلى النموذج، ويُترك له تحديد الإجراء المناسب. فإذا سأل المستخدم "أين طردي؟" دون تقديم رقم الطلب، يمكن للنموذج اختيار إجراء "طلب رقم الطلب" ومطالبة المستخدم بتقديم المزيد من المعلومات.
بعد ذلك، تقوم بتغليف هذا المنطق في حلقة وتُدخل حالةبعد كل رسالة من المستخدم أو استدعاء للأداة، يُعيد النظام تقييم الوضع. قد يسترجع طلبًا، أو يُحدّث السياق، أو يتحقق من كفاية المعلومات لديه للرد، أو يطرح سؤالًا للمتابعة. لا تتوقف هذه العملية إلا بعد إرسال رد واضح أو عند استيفاء شرط الإنهاء.
مع اتساع نطاق العمل ليشمل ما هو أبعد من مجرد التحقق من الحالة، يبدأ الوكيل في اختيار الأدوات بشكل ديناميكي بناءً على النية.قد تُوجَّه مشكلة في الشحن إلى "فتح بلاغ"، وطلب استرداد إلى "بدء استرداد"، واستعلام بسيط عن حالة الطلب إلى "الحصول على حالة الطلب". لا تقوم بترميز شجرة ثابتة من فروع if-else؛ بل يختار النموذج الإجراءات من قائمة أدوات تُحدِّدها أنت أو يتم اكتشافها عبر MCP.
في هذه المرحلة، يتم وضع ضوابط وتقييم المخاطر حول الأدوات الحساسة.قد تُنفَّذ عمليات القراءة فقط مباشرةً، ولكن أي تغيير في الحالة (مثل إصدار المبالغ المستردة، أو إلغاء الطلبات، أو تعديل العناوين) يمر عبر نظام حماية مُراعي للمخاطر. تتطلب الإجراءات عالية المخاطر موافقة بشرية؛ وقد تستدعي الإجراءات متوسطة المخاطر تأكيدات إضافية؛ أما الإجراءات منخفضة المخاطر فيمكن تنفيذها تلقائيًا.
وأخيرًا، تقوم بتحديد الحدود التشغيلية وقواعد تسليم المهام بين الأفراد.إذا وصل النظام إلى الحد الأقصى لعدد المحاولات الفاشلة، أو واجه معلومات متضاربة، أو اضطر إلى اتخاذ قرار عالي المخاطر خارج نطاق صلاحياته، فإنه يُحيل المهمة إلى موظف دعم بشري مُزوّد بكافة المعلومات المُتراكمة. يُمكّنك هذا النهج الهجين من نشر الاستقلالية بأمان مع الحفاظ على السيطرة على الحالات الاستثنائية.
أطر الاستدلال المتقدمة وأدوات الوكلاء الحديثة
إضافة إلى هذه الأساسيات المعمارية، تساعد أطر الاستدلال المتقدمة نماذج التعلم المنطقي على التصرف كعوامل واعية أكثر من كونها مجرد أدوات غامضة.. من الأنماط الشائعة نمط سلسلة الأفكار (CoT) ونمط رد الفعل (العقل + الفعل).
ببساطة، يطلب نموذج "سلسلة الأفكار" من النموذج التفكير خطوة بخطوة.يتم تقسيم الأسئلة المعقدة إلى خطوات استدلالية وسيطة قبل التوصل إلى إجابة نهائية. تُظهر الأبحاث أن هذا الأسلوب يُحسّن بشكل ملحوظ الأداء في المهام التي تتطلب استدلالًا مكثفًا في النماذج الأكبر حجمًا، ويتوافق بشكل طبيعي مع حلقة الوكيل: حيث يندرج كل استدعاء للأداة ضمن سلسلة استدلالية أوسع.
يربط برنامج ReAct بشكل وثيق بين التفكير واستخدام الأدواتيتناوب النظام بشكل واضح بين الأفكار والأفعال والملاحظات: فهو يشرح ما ينوي فعله، ويستدعي أداةً ما، ويفحص المخرجات، ويُحدّث خطته. هذا النمط هو أساس العديد من أنظمة الوكلاء المستقلين المبكرة مثل AutoGPT وBabyAGI، التي تُنشئ قوائم المهام وتُعيد ترتيب أولوياتها ديناميكيًا بما يتماشى مع هدف المستخدم.
تُغلف الأطر الحديثة ومجموعات تطوير البرامج هذه الأفكار في تجريدات سهلة الاستخدام للمطورينتوفر مكتبات مثل LangChain وLangGraph وCrewAI أو مجموعات الأدوات الأصغر حجمًا من نوع "smolagents" لبنات بناء لاستدعاء الأدوات، وسير العمل القائم على الرسوم البيانية، وتنسيق الوكلاء المتعددين، والذاكرة الدائمة. كما تتضمن العديد من سلاسل الأدوات هذه إرشادات لـ وكلاء مخصصون في VS Code. تضيف المنصات الخاصة من موردي الخدمات السحابية والجهات الفاعلة مثل OpenAI هياكل ذات مستوى أعلى للوكلاء والضوابط والتقييمات.
والأهم من ذلك، أن هذه الأطر تتكامل بشكل متزايد مع بروتوكولات مثل MCP و A2A و NLWebبدلاً من دمج موصلات منفصلة، يمكن للوكلاء الاتصال بطبقات قدرات موحدة، والتواصل مع وكلاء خارجيين عبر بطاقات الوكلاء، والتعامل مع المواقع المُفعّلة بتقنية NLWeb كواجهات برمجة تطبيقات من الدرجة الأولى تدعم اللغة الطبيعية. هذا التقارب بين البروتوكولات والأدوات هو ما يُتيح إنشاء أنظمة بيئية واسعة النطاق وقابلة للتشغيل البيني للوكلاء.
كل هذا يقع على سلسلة متصلة تتراوح من الحلول التي لا تتطلب كتابة أكواد إلى الحلول التي تتطلب كتابة أكواد عالية.تتيح المنصات المرئية في مجال البرمجة بدون كتابة أكواد للمستخدمين غير المتخصصين إنشاء سير عمل وأدوات للوكلاء باستخدام واجهات السحب والإفلات وإعدادات اللغة الطبيعية. في المقابل، توفر بيئات البرمجة عالية المستوى للمهندسين تحكمًا دقيقًا في التنسيق والتقييم والنشر، وغالبًا ما تجمع بين أطر العمل والبنية التحتية المخصصة على منصات مثل AWS أو Azure أو ما شابهها من الخدمات السحابية.
على امتداد هذا الطيف، فإن المنظمات التي تفوز هي تلك التي تتعلم تصميم الوكلاء، وليس مجرد استهلاكهم.إن فهم البروتوكولات والأنماط والضوابط يمكّنك من تجاوز تجارب "تجربة روبوت الدردشة" والوصول إلى أتمتة قوية وقابلة للتطوير: بدءًا من وكلاء التحليلات الداخلية ومساعدي المطورين، وصولًا إلى أنظمة متعددة الوكلاء تُنسق المخزون والمدفوعات وتجربة العملاء في الوقت الفعلي. ومع استمرار تطور هذه الوكلاء، تُصبح مهارات التصميم هذه ميزة تنافسية حقيقية.
