واجهات API لوكلاء الذكاء الاصطناعي: من MCP إلى نقاط النهاية

عندما تعلمت نماذج LLM استدعاء الدوال

في عصر GPT-3، كان التفاعل مع نموذج LLM يعني تزويده بموجه والحصول على نص في المقابل. كانت معرفة النموذج واسعة لكنها ثابتة، مجمدة عند ما احتوته بيانات التدريب. كان بإمكانك أن تطلب منه شرح الحوسبة الكمية أو صياغة رسالة بريد إلكتروني، وكان سينتج نصا مقبولا. لكنه لم يكن قادرا على التحقق من طقس اليوم، أو الاستعلام من قاعدة بيانات، أو تنفيذ أي إجراء في العالم الحقيقي.

الميزة التي غيرت ذلك لا تحصل على التقدير الكافي. لقد منحت النموذج خيارا بين توليد النص واستدعاء دالة. بدلا من إنتاج الرمز التالي دائما، أصبح النموذج قادرا على إخراج كائن JSON منظم يحدد اسم دالة ووسائطها. ينفذ وقت التشغيل تلك الدالة، ويعيد النتيجة إلى النموذج، ثم يواصل النموذج من هناك. صاغت ورقة ReAct (Yao et al., 2022) هذا بوصفه حلقة التفكير، الإجراء، الملاحظة. يفكر النموذج فيما يجب فعله، ويتخذ إجراء (يستدعي أداة)، ويلاحظ النتيجة، ثم يكرر ذلك. كل وكيل ذكاء اصطناعي جاد في 2026 يعمل على نسخة ما من هذا النمط.

الحلقة

تعمل Claude Code وOpenClaw وCodex وDevin وعشرات الأنظمة الوكيلة الأخرى بالطريقة نفسها. استدع أداة، لاحظ النتيجة، قرر ما يجب فعله بعد ذلك، وكرر. صاغها Simon Willison بوضوح: “يشغل وكيل LLM الأدوات في حلقة لتحقيق هدف.”

على سبيل المثال، يستخدم Claude Code حلقة رئيسية أحادية المسار من دون سرب متعدد الوكلاء أو مخطط تنسيق معقد: while(tool_call) -> execute -> feed results -> repeat.

تظهر أبحاث Anthropic حول استقلالية الوكلاء أن مدد الجولات في Claude Code تضاعفت تقريبا خلال ثلاثة أشهر، من 25 إلى أكثر من 45 دقيقة. يزداد اعتماد المستخدمين على الحلقة لتعمل وحدها. تظهر البيانات أن المستخدمين ذوي الخبرة يقاطعون أكثر (مع الانتقال من الموافقة على كل إجراء إلى المراقبة الاستراتيجية)، بينما يطلب الوكيل نفسه توضيحا بمعدل يزيد على ضعف معدل مقاطعة المستخدمين له.

يظهر نمط الحلقة هذا في كل مكان، في وكلاء البرمجة، وبوتات دعم العملاء، ومتحكمات الروبوتات على حد سواء.

ما الذي يعد أداة؟

تمنحنا نماذج LLM حرية كبيرة في تحديد مستوى التجريد الذي يجب أن تعمل عنده الأداة. في أحد الطرفين، لديك نقاط نهاية API شديدة التحديد: “أنشئ جهة اتصال HubSpot بهذه الحقول الـ 12.” وفي الطرف الآخر، لديك أدوات مثل “شغل أمر bash هذا” أو “نفذ كود Python هذا”، وهي في جوهرها “افعل ما تريد.”

يعمل Devin باستخدام ثلاث أدوات: shell، ومحرر كود، ومتصفح. الأداة الأساسية في Claude Code هي أيضا shell. يستخدم OpenClaw نظام إضافات مهارات ديناميكيا. كان الاتجاه في أدوات البرمجة الوكيلة نحو أدوات أقل وأكثر عمومية، بدلا من عدد كبير من الأدوات المحددة.

لاحظ Simon Willison أن MCP “انفجر في البداية لكنه بدا أقل مركزية لاحقا” لوكلاء البرمجة لأن bash هو الأداة الشاملة. الملفات والسكريبتات بدائية أقل كلفة تشغيلية من تنفيذات خوادم MCP الكاملة. إذا كان الوكيل قادرا على كتابة الكود وتنفيذه، فيمكنه فعل كل شيء تقريبا من دون الحاجة إلى تعريف أداة مخصصة.

لكن الأدوات العامة تصلح للوكلاء العامين. بالنسبة إلى وكلاء الذكاء الاصطناعي المتخصصين في مجال معين (دعم العملاء، المبيعات، العمليات الداخلية)، تحتاج إلى أدوات متخصصة في المجال. يجب ألا يكتب وكيل الدعم لديك Python للتحقق من حالة طلب. يجب أن يستدعي نقطة نهاية API محددة جيدا، بمعلمات واضحة واستجابات متوقعة. يصبح تصميم مجموعة أدواتك قرارا متعلقا بالمنتج.

ماذا تعني نقطة نهاية API الآن

بالنسبة إلى وكلاء الذكاء الاصطناعي، تعمل نقطة نهاية API كإعلان عن قدرة. نشر واحدة يعني أنك (أو وكيل الذكاء الاصطناعي لديك) أصبحت قادرا الآن على فعل شيء لم يكن ممكنا من قبل.

يعمل هذا في كلا الاتجاهين. ينشر مورّد برمجيات API حتى يتمكن الآخرون من التكامل مع منتجه. لكن يمكن لوكيل ذكاء اصطناعي أيضا اكتشاف نقاط النهاية بنفسه عبر البحث في الوثائق، أو قراءة مواصفات OpenAPI، أو حرفيا البحث في Google عن كيفية إنجاز مهمة.

خادم MCP هو حزمة منتقاة من نقاط نهاية API، مع تصور مسبق لكيفية استخدامها. اتخذ منشئ MCP بالفعل قرارات حول نقاط النهاية التي يجب كشفها، وكيفية تسميتها، وما المعلمات التي يجب إظهارها، وضمنيا ما سير العمل الذي يجب دعمه. هذا الانتقاء هو نقطة القوة (السهولة، التوحيد) ونقطة الضعف (الجمود، والنطاق المحدد برأي مسبق) في الوقت نفسه. خادم Notion مثال ملموس: ينشر 28 أداة، ويحتاج وكيل مركز مساعدة إلى أربع منها، مقسمة عبر اتصالين.

تستبدل MCPs التحكم بسهولة الاستخدام. في 2026، يكتب الذكاء الاصطناعي معظم كود التكامل. إذا كان الوكيل قادرا على قراءة وثائق API وكتابة التكامل بنفسه، تصبح حجة “سهولة الاستخدام” لصالح MCP أضعف. قد تكون طبقة MCP أكثر أهمية خلال فترة الانتقال، بينما لم تلحق الأدوات بعد بقدرة النموذج. يعد دليل Anthropic حول أنماط تصميم استخدام الأدوات مرجعا عمليا لهيكلة مخططات الأدوات سواء استخدمت MCP أو نقاط نهاية منفردة.

تطور ذو صلة: llms.txt معيار مقترح تنشر فيه المواقع ملف /llms.txt لتوجيه نماذج الذكاء الاصطناعي نحو الموارد عالية القيمة. اعتمدته Anthropic وCloudflare وDocker وStripe. يوحد MCP استدعاء الأدوات، ويوحد llms.txt اكتشاف الوثائق. يحاول كلاهما جعل الويب أكثر قابلية للقراءة آليا، من زاويتين مختلفتين.

ما هي نقطة نهاية API في سياق وكلاء الذكاء الاصطناعي؟

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

بخلاف المطورين البشر الذين يمكنهم قراءة الدروس التعليمية وتصحيح الأخطاء تكراريا، يعتمد الوكيل على مخطط نقطة النهاية ووصفها لإجراء استدعاء واحد صحيح. لهذا السبب أصبحت وثائق API المصممة لاستهلاك الذكاء الاصطناعي أكثر أهمية من أي وقت مضى. حاليا، 24% فقط من المطورين يصممون واجهات API مع أخذ وكلاء الذكاء الاصطناعي في الحسبان، رغم أن 89% يستخدمون الذكاء الاصطناعي في سير عملهم.

ما هو MCP (Model Context Protocol)؟

MCP هو بروتوكول مفتوح قدمته Anthropic يوحد كيفية اتصال وكلاء الذكاء الاصطناعي بالأدوات الخارجية ومصادر البيانات. فكر فيه كأنه USB-C للذكاء الاصطناعي. موصل واحد يمكن لأي مزود أدوات تنفيذه ويمكن لأي وكيل ذكاء اصطناعي استهلاكه. يكشف خادم MCP مجموعة من الأدوات (هي في جوهرها نقاط نهاية API) بمخططات موحدة، ويمكن لعميل MCP (الوكيل) اكتشافها واستدعاؤها من دون كود تكامل مخصص. لشرح تقني أعمق، راجع منشورنا شرح MCP. ولعرض عملي لاستخدام MCP في الإنتاج، راجع تحليلنا لـ التحديات الواقعية عند البناء على MCP الخاص بـ Shopify.

طيف التحكم في Quickchat AI

تمنحك Quickchat AI ثلاث طرق لتزويد AI Agent بأدوات خارجية. تقع هذه الطرق على طيف يبدأ من الأكثر أتمتة إلى الأكثر تحكما. يقدم كل نهج مفاضلة مختلفة بين سرعة الإعداد ودقة السلوك.

Remote MCP: وصّل وابدأ

Remote MCP هي أسرع طريقة لربط AI Agent بوظائف خارجية. توفر URL لخادم MCP، فتتصل Quickchat AI به، وتكتشف كل الأدوات المتاحة، وتتيح لك تحديد الأدوات التي يجب أن يستخدمها وكيلك.

كيفية إعداده:

1. انتقل إلى AI Actions في لوحة تحكم Quickchat AI
2. انقر على “Add Remote MCP”
3. الصق URL خادم MCP الخاص بك (مثلا، https://mcp.example.com/sse)
4. أضف اختياريا رمز مصادقة أو ترويسات مخصصة (الخياران متنافيان)
5. انقر على “Connect.” تكتشف Quickchat AI كل الأدوات المتاحة وتعرض أسماءها
6. فعّل الأدوات الفردية أو عطّلها للتحكم في الأدوات التي يمكن لوكيلك استخدامها
7. اضبط علم “default tool is active” للتحكم فيما إذا كانت الأدوات المكتشفة حديثا مفعلة أو معطلة تلقائيا

ما يحدث تحت الغطاء:

عند النقر على Connect، تكتشف Quickchat AI بروتوكول النقل تلقائيا من URL. إذا احتوى URL على sse، يستخدم نقل SSE، وإلا يكون streamable_http هو الخيار الافتراضي. عند توفير رمز مصادقة، يرسل كرمز Bearer في ترويسة Authorization.

يعمل ترشيح الأدوات من خلال نظام بثلاث طبقات. تتحقق كل أداة من خادم MCP مقابل مجموعتين: الأدوات المفعلة صراحة تُدرج دائما، والأدوات المعطلة صراحة تُستبعد دائما، وأي أداة غير موجودة في أي من المجموعتين تعود إلى إعداد “default tool is active” الذي اخترته. هذا يعني أنه عندما يضيف خادم MCP أدوات جديدة، يمكنك التحكم فيما إذا كانت متاحة تلقائيا لوكيلك أم تتطلب تفعيلا صريحا.

في وقت التشغيل، عندما تبدأ محادثة، يتم تحميل كل اتصالات Remote MCP النشطة للوكيل. يتم جلب الأدوات وترشيحها وفق تكوين كل اتصال، ويتم التحقق من تفرد أسماء الأدوات عبر كل المصادر (مع تحذير إذا وجدت تكرارات).

المفاضلة: تحصل على وصول فوري إلى كل ما يكشفه MCP، لكن تحكمك محدود في أوصاف الأدوات، أو تعريفات المعلمات، أو كيفية قرار الوكيل باستخدامها. كما وجدنا عند بناء AI Agent على MCP الخاص بـ Shopify، يتطلب الانتقال من العرض التجريبي إلى الإنتاج ضبطا دقيقا قد يجعل نهج الحزمة في MCP صعبا.

راجع أيضا: ربط وكيلك بخادم MCP بعيد، كيفية إطلاق Quickchat AI MCP الخاص بك، اعتبارات أمان MCP، وثائق Quickchat AI: قناة MCP.

AI Actions (HTTP Request): نقطة نهاية واحدة، تحكم كامل

AI Action في Quickchat AI هي نقطة نهاية HTTP API واحدة تهيئها بشكل منفرد لـ AI Agent الخاص بك. بينما يستورد MCP حزمة أدوات دفعة واحدة، تمنحك كل AI Action تحكما كاملا في قدرة محددة واحدة. للاطلاع على مثال كامل، أربع إجراءات تنشئ جهات اتصال وتثريها، وتسجل صفقات، وتفتح تذاكر في CRM، راجع دليل HubSpot AI Actions.

تهيئة AI Action:

1. Name (بحد أقصى 64 حرفا): يصبح هذا اسم الأداة الذي يراه LLM. يتم تطبيعه إلى معرف صالح (مثلا، يتحول “Check Order Status” إلى Check_Order_Status)
2. Description (بحد أقصى 1,000 حرف): هذا هو الحقل الأهم. يخبر الوصف LLM متى يستخدم هذه الأداة. تحدد الأوصاف الجيدة الظروف الحوارية التي تستدعي استخدامها، والمعلومات التي يجب جمعها من المستخدم أولا، وكيف يجب إبلاغ النتائج مرة أخرى
3. HTTP method: GET، POST، PATCH، DELETE، أو PUT
4. URL (بحد أقصى 10,000 حرف): يمكن أن يحتوي على مواضع {{parameter_name}} للقيم الديناميكية
5. Headers: أزواج مفتاح وقيمة للمصادقة ونوع المحتوى
6. Body items / Body JSON: جسم الطلب مع حقن المعلمات
7. Query parameters: قيم سلسلة استعلام URL
8. Parameters (بحد أقصى 10): لكل منها اسم، ووصف (بحد أقصى 500 حرف)، ونوع (str، int، float، bool، أو custom)، وعلم مطلوب، وقيمة افتراضية اختيارية

تعد مواضع {{parameter_name}} الآلية الأساسية. عندما يستدعي LLM الأداة، يوفر قيما لكل معلمة بناء على سياق المحادثة. ثم تحقن Quickchat AI تلك القيم في قوالب URL والترويسات والجسم وسلسلة الاستعلام قبل إجراء طلب HTTP. توجد أيضا أربعة متغيرات مدمجة يمكن حقنها بهذه الطريقة: scenario_id، وconversation_id، وconversation_channel، وconversation_url.

AI Action مهيأة للتحقق من حالة الطلب، تعرض قالب URL مع موضع معلمة، والترويسات، وتعريفات المعلمات.

تحت الغطاء: تبني Quickchat AI ديناميكيا مخططا ذا أنواع من تعريفات المعلمات لكل AI Action. يتم تعيين الأنواع الخمسة المدعومة (str، int، float، bool، custom) إلى مكافئاتها الأصلية، ويستخدم هذا المخطط للتحقق من مدخلات LLM قبل إجراء طلب HTTP.

مثال AI Action للتحقق من حالة الطلب:

{
  "name": "check_order_status",
  "description": "عندما يسأل المستخدم عن حالة طلبه ويكون قد قدم رقم طلب، استدع نقطة النهاية هذه لاسترداد الحالة الحالية. أبلغ المستخدم بالحالة، وتاريخ التسليم المتوقع، ورقم التتبع (إن كان متاحا).",
  "method": "GET",
  "url": "https://api.example.com/orders/{{order_id}}",
  "headers": [
    { "name": "Authorization", "value": "Bearer YOUR_API_KEY" },
    { "name": "Content-Type", "value": "application/json" }
  ],
  "parameters": [
    {
      "name": "order_id",
      "description": "معرف الطلب الذي قدمه المستخدم (مثلا، ORD-12345)",
      "type": "str",
      "is_required": true
    }
  ]
}

الاختبار: تحتوي لوحة التحكم على زر “Test” يتيح لك تقديم قيم معلمات عينة ورؤية طلب HTTP الفعلي (بما في ذلك أمر curl مولد) والاستجابة قبل النشر.

نصائح لكتابة أوصاف AI Action فعالة:

• كن محددا حول متى يجب على الوكيل استدعاؤها: “عندما يسأل المستخدم عن حالة طلبه ويقدم رقم طلب، استدع نقطة النهاية هذه”
• اذكر المعلومات التي يجب جمعها أولا: “قبل الاستدعاء، تأكد من أن لديك عنوان بريد المستخدم الإلكتروني ومعرف الطلب”
• صف كيفية التعامل مع الاستجابة: “إذا كانت الحالة ‘shipped’، فأخبر المستخدم برقم التتبع من الاستجابة”
• بالنسبة إلى سير العمل متعدد الخطوات، صف التسلسل في موجه النظام الرئيسي للوكيل بدلا من أوصاف الإجراءات الفردية، ومن أجل نقل قيمة بين الإجراءات وتقييد الكتابة بناء عليها، استخدم Save to memory مع run-condition

مثال عملي: للحصول على AI Action خطوة بخطوة تسجل العملاء المحتملين، والأسئلة غير المجابة، وطلبات العروض التجريبية مباشرة في جدول بيانات، راجع كيفية ربط وكيل ذكاء اصطناعي بـ Google Sheets.

Generate from Text: دع الذكاء الاصطناعي يحدد الحل

الخيار الثالث مخصص للمستخدمين الذين يعرفون ما يريدون من وكيلهم أن يفعله، لكنهم لا يعرفون أي نقطة نهاية API (أو حتى أي خدمة) يجب استخدامها.

كيف يعمل:

1. تكتب وصفا بلغة طبيعية لما تريده، مثلا، “أريد أن يتمكن AI Agent الخاص بي من تشغيل سيارة Tesla الخاصة بمستخدم عندما يطلب ذلك”
2. ترسل Quickchat AI هذا إلى LLM مع تفعيل أداة web_search
3. يبحث النموذج في الويب للعثور على API المناسبة، ويقرأ الوثائق الرسمية، وينشئ مواصفة AI Action كاملة تشمل URL، والطريقة، والترويسات، والمعلمات، ومتطلبات المصادقة
4. تعود النتيجة بتكوين الإجراء الكامل، واستشهادات بالوثائق التي استخدمها، ورسالة شرح تذكر الافتراضات والفجوات
5. تراجع النتيجة، وتملأ بيانات الاعتماد، وتفعّلها

إدخال وصف بلغة طبيعية للقدرة المطلوبة.

تكوين AI Action المولد مع استشهادات بوثائق API المستخدمة.

تتم هيكلة توليد AI Action الآلي حول ثلاث أولويات:

• الأولوية 1: فهم القصد. تحديد القدرة الدقيقة التي يريدها المطور ونقطة نهاية API المحددة التي توفرها
• الأولوية 2: الارتكاز إلى الوثائق. استخدام بحث الويب للعثور على وثائق المورد الرسمية، وليس التخمينات
• الأولوية 3: تصميم دلالات تضع المحادثة أولا. يجب أن يكون الاسم والوصف المولدان حول متى في المحادثة تُستخدم هذه الأداة، وليس فقط ما تفعله API تقنيا

يستخدم الموجه اصطلاحين للمواضع. يحدد {{param}} معلمات وقت التشغيل التي يملؤها LLM من سياق المحادثة. ويحدد [[secret_name]] (أقواس مربعة مزدوجة) ثوابت المطور مثل مفاتيح API ومعرفات الحساب التي يجب تهيئتها يدويا قبل التفعيل. يجب أن يظهر كل اسم معلمة كموضع {{that_exact_name}} في مكان ما داخل تعريف الطلب، ولا يسمح بوجود مواضع يتيمة.

يستخدم النظام سياسة فشل مغلقة. إذا لم يستطع النموذج تأكيد معلومة حرجة من الوثائق (طريقة HTTP، أو URL، أو مخطط المصادقة، أو بنية الحمولة المطلوبة)، فلا يتم إنشاء أي إجراء. بدلا من ذلك، يعيد النظام شرحا موجزا لما هو ناقص بدلا من التخمين.

هنا ترتبط الفكرة الفلسفية حول اكتشاف وكلاء الذكاء الاصطناعي لواجهات API بميزة منتج ملموسة. ميزة Generate from Text هي حرفيا وكيل ذكاء اصطناعي (LLM مع بحث ويب) يبني تعريف أداة لوكيل ذكاء اصطناعي آخر (وكيل Quickchat AI الذي سيستخدمها في المحادثات).

مثال عملي: للحصول على الدليل الكامل الذي يحول جملتين مكتوبتين إلى إجراءين مباشرين ومختبرين (استعلام طقس بلا مفتاح وآخر خاص بـ NASA مع مفتاح، بما في ذلك رفض الفشل المغلق)، راجع كيفية ربط وكيل الذكاء الاصطناعي الخاص بك بأي API بلغة إنجليزية بسيطة.

في وقت التشغيل، يتم تجميع كل أنواع الأدوات هذه معا. تجمع Quickchat AI أدوات AI Action لطلبات HTTP، وأدوات Shopify MCP، وأدوات قاعدة المعرفة، وأدوات Remote MCP، وأدوات Discord، وأدوات مخصصة أخرى في مجموعة تعرض على LLM. لا يرى النموذج أي فرق بينها. تبدو أداة Remote MCP وAI Action المهيأة يدويا متطابقتين بمجرد وجودهما في قائمة الأدوات.

واجهات API المفتوحة بصفتها SEO الجديد

إذا كان وكلاء الذكاء الاصطناعي سيكتشفون واجهات API ويستخدمونها ذاتيا، فإن امتلاك API موثقة جيدا وسهلة الاستخدام يصبح أصلا للتوزيع. تتوقع Gartner أن أكثر من 30% من زيادة الطلب على API ستأتي من وكلاء الذكاء الاصطناعي بحلول 2026.

قد تجد الشركات التي تملك واجهات API مفتوحة مع حواجز اعتماد محدودة أن واجهات API الخاصة بها أصبحت أفضل قناة اكتساب لديها. بدلا من مرات الظهور في بحث Google، تكون “مرات الظهور” هي اختيار وكلاء الذكاء الاصطناعي استخدام خدمتك بدلا من خدمة منافس.

ينطبق المنطق نفسه على مستوى أعلى. يمكن لوكيل ذكاء اصطناعي يجيب من وثائقك أن يتم كشفه هو نفسه كخادم MCP تستدعيه ChatGPT وClaude وCursor كأداة، ما يجعل معرفتك، وليس API الخاصة بك فقط، قابلة للاكتشاف بواسطة الويب الوكيلية.

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

قد تجد الشركات التي تكون واجهات API لديها غير موثقة أو محجوبة خلف متطلبات اعتماد ثقيلة نفسها غير مرئية للويب الوكيلية، بالطريقة نفسها التي أصبحت بها الشركات التي لا تملك مواقع ويب غير مرئية لـ Google في العقد الأول من الألفية.

استخدام الكمبيوتر مقابل واجهات API

هناك استثمار كبير في تعليم نماذج الذكاء الاصطناعي “استخدام الكمبيوتر” (النقر على الأزرار، ملء النماذج، التنقل في واجهات المستخدم). تقدم Anthropic وOpenAI (Operator) ومشاريع مفتوحة المصدر مثل Browser Use نسخا من ذلك.

لكن استخدام المتصفح حل التفافي لغياب API. يستغرق استدعاء POST /orders ميلي ثوان ويعيد بيانات منظمة. أما وكيل متصفح يتنقل في مسار دفع فيستغرق دقائق ويمكن أن يتعطل عندما يتحرك زر ثلاثة بكسلات إلى اليسار. واجهات API أسرع، وأكثر حتمية، وأرخص في التنفيذ.

الحجة المضادة حقيقية: لا توجد واجهات API لكل شيء. الأنظمة القديمة، وبرمجيات المؤسسات التي لا تحتوي على سطح API، والأجهزة الفيزيائية المتحكم بها عبر واجهات رسومية. يسد استخدام الكمبيوتر فجوة حقيقية في تلك الحالات.

ربما تكون الاستجابة الأفضل على المدى الطويل لعبارة “لا نملك API لهذا” هي بناء API بدلا من تعليم الذكاء الاصطناعي استخدام الواجهة الرسومية. مع كتابة مزيد من البرمجيات بواسطة وكلاء ذكاء اصطناعي من أجل وكلاء ذكاء اصطناعي، تنخفض تكلفة بناء واجهات API وصيانتها. يتغير الحساب الاقتصادي الذي جعل كشط واجهة المستخدم أرخص من بناء API.

هناك أيضا زاوية أمنية. تصف “الثلاثية القاتلة” لـ Simon Willison التركيبة الخطرة من الوصول إلى بيانات خاصة + التعرض لمحتوى غير موثوق + اتصال خارجي. ينطبق هذا على كلا النهجين، لكن الأدوات القائمة على API أسهل في التدقيق والتقييد. يمكنك تسجيل كل استدعاء API، والتحقق من كل معلمة، وتحديد معدل كل نقطة نهاية. تنفيذ ما يعادل ذلك لوكيل متصفح يمكنه النقر على أي شيء أصعب بكثير.

أدوات للعالم الفيزيائي

كل ما نوقش حتى الآن يتعلق بالبرمجيات. يظهر النمط نفسه في العالم الفيزيائي.

تستخدم RT-2 وGemini Robotics من Google DeepMind البنية نفسها، إلا أن الأدوات ترسل الأوامر إلى مشغلات بدلا من واجهات API. يضفي إطار SPCA (Sense-Plan-Code-Act) الطابع الرسمي على ذلك في الروبوتات: امسح البيئة، وخطط للنهج، وولّد كودا قابلا للتنفيذ، ونفذه، ولاحظ النتائج.

لا توجد API لـ “حرّك النبتة على مكتبي إلى اليمين.” لكن يمكن لروبوت مزود بكاميرا أن يعرّف move_object(object_id="plant_01", direction="right", distance_cm=15) كأداة بشكل فوري ثم يستدعيها. يعمل تعريف الأداة كواجهة بين طبقة التفكير وطبقة التنفيذ الفيزيائي، وهو الدور نفسه الذي تؤديه نقاط نهاية API في البرمجيات.

بنية LLM + أدوات + حلقة عامة الغرض. تصادف أنها الأسهل تنفيذا في البرمجيات اليوم، لكن الروبوتات تلحق بها.

واجهات API يكتبها الذكاء الاصطناعي، للذكاء الاصطناعي

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

تعد MCPs طبقة توحيد مفيدة، لكنها أيضا طبقة انتقاء تدخل تحيزا. يقرر منشئ MCP الأدوات التي يكشفها وكيف يؤطرها. بالنسبة إلى وكلاء الذكاء الاصطناعي في الإنتاج، قد لا يطابق ذلك الإطار ما تحتاجه فعليا. (كتبنا عن هذا بالتفصيل عند تحليل التحديات مع MCP الخاص بـ Shopify.)

يعكس الطيف الذي استعرضناه في Quickchat AI Agents نقطة أوسع. يعتمد مستوى التحكم الصحيح على حالة الاستخدام لديك. تعمل Remote MCP جيدا لبناء النماذج الأولية بسرعة. تمنحك AI Actions الفردية تحكما دقيقا للوكلاء الموجهين للعملاء في الإنتاج. تتيح Generate from Text للذكاء الاصطناعي البحث في API وبناء تعريف الأداة لك عندما لا تزال تستكشف.

وعلى كل مستوى، يظل النمط الأساسي هو نفسه. LLM، ومجموعة أدوات، وحلقة. سواء كانت الأدوات أوامر bash، أو نقاط نهاية API، أو خوادم MCP، أو مشغلات روبوتية، فالأمر أدوات في كل طبقة.