أنظمة أدوات الذكاء الاصطناعي: كيف يتصل الوكلاء بالبرمجيات

باختصار: طبقة الأدوات هي حيث يتوقف وكلاء الذكاء الاصطناعي عن الكلام ويبدأون بالعمل. يوفر MCP بروتوكولاً عالمياً لتكامل الوكيل بالأداة، ويمكّن A2A التعاون بين الوكلاء، ويتعامل استخدام الحاسوب مع الأنظمة القديمة التي تفتقر لواجهات برمجة التطبيقات. معاً، تبني هذه البروتوكولات البنية التحتية لوكلاء يمكنهم اكتشاف الأدوات التي يحتاجونها وتجميعها ديناميكياً.

وكيل ذكاء اصطناعي بلا أدوات هو سجين بليغ جداً. يمكنه التفكير والاستنتاج وتوليد نص رائع — لكنه لا يستطيع التحقق من تقويمك، أو الاستعلام من قاعدة بيانات، أو إرسال بريد إلكتروني، أو تنفيذ سطر واحد من الشيفرة. في اللحظة التي يحصل فيها الوكيل على أدوات، يتحول من شريك محادثة إلى فاعل في العالم الحقيقي.

طبقة الأدوات في مكدس الذكاء الاصطناعي الوكيلي هي حيث يلتقي الذكاء الاصطناعي بالبنية التحتية. هي حيث تتوقف النماذج اللغوية عن توليد نصوص حول ما يمكن فعله وتبدأ فعلاً بتنفيذه. وفي 2026، تمر هذه الطبقة بأهم تحول لها منذ إدخال استدعاء الدوال.

من استدعاء الدوال إلى أنظمة الأدوات

كان الجيل الأول من استخدام أدوات الذكاء الاصطناعي بدائياً: كان المطورون يُبرمجون تعريفات الدوال مباشرة في الموجّهات، ويكتبون منطق تحليل مخصص لمخرجات النموذج، ويتعاملون يدوياً مع كل حالة خطأ. كل أداة جديدة تتطلب شيفرة تكامل جديدة. التوسع إلى عشرات الأدوات يعني توسع التعقيد خطياً.

استدعاء الدوال — الذي قدمته OpenAI في يونيو 2023 وتبنّاه سريعاً المزودون الرئيسيون — حسّن هذا بشكل كبير. أصبحت النماذج قادرة على إخراج JSON منظم يحدد أي دالة يجب استدعاؤها وبأي معاملات. لكن كل تكامل ظل مخصصاً. ربط وكيل بـ Salesforce يتطلب شيفرة مختلفة عن ربطه بـ Slack، والذي يتطلب شيفرة مختلفة عن ربطه بقاعدة بيانات.

المشكلة لم تكن في النماذج. بل في البنية التحتية.

MCP: منفذ USB-C للذكاء الاصطناعي

غيّر بروتوكول سياق النموذج (MCP) قواعد اللعبة. قدمته Anthropic في نوفمبر 2024 وتبرعت به لمؤسسة الذكاء الاصطناعي الوكيلي (AAIF) التابعة لمؤسسة Linux في ديسمبر 2025، ويُعرّف MCP واجهة عالمية بين وكلاء الذكاء الاصطناعي والأدوات.

فكّر في تكامل الأدوات قبل MCP كحقبة ما قبل USB في الحوسبة: كل جهاز طرفي يحتاج موصله وبرنامج تشغيله وكابله الخاص. MCP هو USB-C — معيار واحد يمكن لأي مزود أدوات تطبيقه ولأي وكيل استخدامه.

يُوحّد البروتوكول ثلاثة أشياء:

1. اكتشاف الأدوات — يمكن للوكيل الاستعلام من خادم MCP لمعرفة الأدوات المتاحة ووظائفها والمعاملات التي تقبلها
2. استدعاء الأدوات — تنسيق منظم لاستدعاء الأدوات واستلام النتائج، مع معالجة أخطاء متسقة
3. توفير السياق — يمكن للأدوات توفير سياق (مستندات، بيانات، حالة) للوكيل، وليس فقط نتائج الإجراءات

بحلول مارس 2026، انفجر نظام MCP. تم فهرسة آلاف تطبيقات الخوادم — تغطي قواعد البيانات والخدمات السحابية وأدوات التطوير وتطبيقات الأعمال ومنصات الاتصال. تبنّت بيئات التطوير الرئيسية بما فيها Cursor وClaude Code وReplit وSourcegraph وVisual Studio Code (عبر GitHub Copilot) وWindsurf وZed بروتوكول MCP كواجهتها الأساسية بين الوكيل والأداة.

تأثير الشبكة قوي: كلما زادت الأدوات التي تدعم MCP، ازدادت قيمة الوكلاء المتوافقين مع MCP، مما يدفع المزيد من الأدوات لدعم MCP.

A2A: عندما يتحدث الوكلاء مع بعضهم

يحل MCP مشكلة الوكيل-الأداة. لكن ماذا عن الاتصال بين الوكلاء؟

يعالج بروتوكول Agent-to-Agent (A2A) من Google، الذي أُطلق في أبريل 2025 وساهم به في مؤسسة Linux في يونيو 2025، تحدياً مكملاً: كيف يكتشف الوكلاء المبنيون بشكل مستقل بعضهم البعض، ويتفاوضون على القدرات، ويتعاونون في المهام؟

يوفر A2A اكتشاف وكلاء معياري (عبر بطاقات الوكلاء التي تصف القدرات)، وتفويض المهام (الرجاء التعامل مع هذه المهمة الفرعية)، وتبادل النتائج (إليك ما وجدته). أضاف الإصدار 0.3، الصادر في يوليو 2025، دعم نقل gRPC وتحديثات متدفقة ومحادثات وكلاء متعددة الأدوار — مما يوفر واجهة أكثر استقراراً للتبني المؤسسي.

MCP وA2A ليسا متنافسين — بل طبقتان متكاملتان. MCP يربط الوكلاء بالأدوات. A2A يربط الوكلاء بوكلاء آخرين. معاً، يبنيان البنية التحتية لعالم حيث يمكن لأنظمة الوكلاء المنسّقة تجميع الأدوات والمتعاونين الذين تحتاجهم ديناميكياً لأي مهمة.

استخدام الحاسوب: الحل البديل عبر الواجهة الرسومية

ليس كل شيء يملك واجهة برمجة تطبيقات. البرمجيات المؤسسية القديمة والأدوات الداخلية والبوابات الحكومية والعديد من تطبيقات الويب تفتقر إلى واجهات برمجية. لهذه الأنظمة، يوفر استخدام الحاسوب — الوكلاء الذين يتفاعلون مع الواجهات الرسومية بالتقاط لقطات شاشة وتحديد العناصر ومحاكاة نقرات الفأرة وإدخال لوحة المفاتيح — حلاً بديلاً حاسماً.

تمثل ميزة استخدام الحاسوب من Claude لـ Anthropic، ووكيل ChatGPT من OpenAI (الذي يجمع بين Operator والبحث العميق ووكيل استخدام الحاسوب في وضع وكيل موحد)، وProject Mariner من Google مقاربات مختلفة لأتمتة الواجهة الرسومية. حقق Project Mariner دقة 83.5% على معيار WebVoyager ويمكنه تشغيل 10 مهام متوازية.

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

أنظمة الأدوات في الممارسة العملية

تتعامل عمليات نشر الوكلاء الأكثر فعالية مع الأدوات كنظام منسّق وليس بوفيهاً مفتوحاً. ثلاثة مبادئ توجه إدارة الأدوات الإنتاجية:

المبدأ الأول: الحد الأدنى من الصلاحيات

يجب أن يكون للوكيل حق الوصول فقط إلى الأدوات التي يحتاجها لدوره المحدد. وكيل خدمة العملاء يحتاج الوصول إلى أدوات البحث عن الطلبات والاسترداد — وليس إلى قواعد بيانات الإنتاج أو أنظمة النشر. هذا يعكس ممارسات الأمان القياسية ويدعم مباشرة موازنة الذكاء الاصطناعي من خلال الحد من التأثير المحتمل لأخطاء الوكيل.

المبدأ الثاني: أدوات قابلة للتركيب

الأدوات الصغيرة والمركّزة تتكامل أفضل من الأدوات الكبيرة والمعقدة. أداة “إرسال_بريد” وأداة “تنسيق_قالب” وأداة “بحث_جهة_اتصال” أكثر مرونة من أداة “إدارة_الاتصالات” المتجانسة. الأدوات القابلة للتركيب تمنح الوكيل مساحة أكبر للتفكير في كيفية الجمع بين القدرات بشكل إبداعي.

المبدأ الثالث: التنفيذ القابل للمراقبة

يجب تسجيل كل استدعاء أداة مع معاملاته ونتائجه ووقت استجابته وحالة الخطأ. عندما يرتكب وكيل خطأً، يكون سجل استدعاءات الأدوات هو أداة التشخيص الأساسية. بدون قابلية المراقبة، يكاد يكون تشخيص الأعطال في سير العمل متعدد الأدوات مستحيلاً.

مشكلة اكتشاف الأدوات

مع نمو أنظمة الأدوات، يبرز تحدٍ جديد: كيف يختار الوكيل الأداة الصحيحة من بين مئات الخيارات المتاحة؟

تعتمد معظم التطبيقات الحالية على أوصاف الأدوات — شروحات باللغة الطبيعية لما تفعله كل أداة — يقرأها النموذج ويستدل عليها. هذا يعمل جيداً لـ 10-20 أداة لكنه يتدهور مع زيادة العدد. تبدأ النماذج بالخلط بين أدوات متشابهة، واختيار خيارات دون المثالية، أو هلوسة أسماء أدوات غير موجودة.

تشمل الحلول الناشئة سجلات أدوات دلالية (قواعد بيانات قابلة للبحث من أدوات مع بيانات وصفية منظمة)، وأنظمة توصية أدوات (تقترح أدوات ذات صلة بناءً على وصف المهمة)، وتنظيم هرمي للأدوات (تجميع الأدوات ذات الصلة في فئات يتنقل فيها الوكيل تدريجياً).

هذه في جوهرها نفس مشكلة الاكتشاف التي أظهرها صعود وكلاء الذكاء الاصطناعي على كل مستوى من المكدس: مع تضاعف القدرات، يصبح إيجاد واختيار القدرة الصحيحة تحدياً هندسياً من الدرجة الأولى.

ما التالي

تتحرك طبقة الأدوات نحو عالم يمكن فيه للوكلاء اكتشاف وتقييم وتركيب أدوات لم يروها من قبل ديناميكياً — تماماً كما يمكن لمطور اكتشاف واستخدام مكتبة جديدة بقراءة توثيقها.

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

الوكلاء يحصلون على أيدٍ. السؤال الآن هو مدى براعة تلك الأيدي.

المصادر والقراءات الإضافية

• The Model Context Protocol Specification — Anthropic / Linux Foundation
• Agent2Agent Protocol (A2A) Specification — Linux Foundation
• Tool Use with Claude — Anthropic Documentation
• Function Calling Guide — OpenAI Documentation
• Building Effective Agents — Anthropic Research
• Tool Learning with Large Language Models: A Survey — Qu et al.