دليل فهم وإنشاء وتحسين وكلاء_API

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

وكلاء_API هي مثال رئيسي على هذا التحول إلى وكلاء. وكلاء_API يستخدمون نماذج اللغة الكبيرة (LLM) للتفاعل مع أنظمة البرمجيات من خلال واجهات برمجة التطبيقات (APIs).

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

الشركات تستخدم حاليًا وكلاء_API في مجالات مختلفة، بما في ذلك:

• تطبيقات المستهلك: تم تصميم المساعدين مثل سيري من شركة آبل أو أليكسا من شركة أمازون لتسهيل المهام اليومية، مثل التحكم في أجهزة المنزل الذكية وعمليات الحجز.
• عمليات العمل التجاري: قامت الشركات بتشغيل وكلاء_API لتحسين المهام المتكررة مثل استرداد البيانات من أنظمة إدارة العلاقات مع العملاء، وتوليد التقارير، أو توحيد المعلومات من الأنظمة الداخلية.
• استرجاع البيانات وتحليلها: تستخدم الشركات وكلاء_API لتسهيل الوصول إلى مجموعات البيانات المملوكة، والموارد المُشترك فيها، والواجهات البرمجية العامة من أجل توليد رؤى.

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

سأوضح كيف تعمل وكلاء_API وكيفية بناء هؤلاء الوكلاء بنجاح من خلال الهندسة المعمارية والهندسة.

الجزء الأول: التعريفات الرئيسية

• واجهة برمجة التطبيقات (API): مجموعة من القواعد والبروتوكولات التي تمكن التطبيقات البرمجية المختلفة من التواصل وتبادل المعلومات.
• الوكيل: نظام ذكاء اصطناعي مصمم للاستشعار والتفاعل مع بيئته واتخاذ القرارات والقيام بالactions لتحقيق أهداف محددة.
• وكيل_API: وكيل ذكاء اصطناعي متخصص يترجم أوامر اللغة الطبيعية إلى أوامر_API دقيقة.
• وكيل إنشاء الشفرة: نظام ذكاء اصطناعي يساعد في تطوير البرمجيات من خلال كتابة وتنقيح الشفرة. في حين أن هذا متعلق، فإن التركيز هنا ي集中 على الوكلاء الذين يدعون واجهات_API، على الرغم من أن الذكاء الاصطناعي يمكن أن يساعد أيضًا في بناء هؤلاء الوكلاء.
• بروتوكول سياق النموذج (MCP): بروتوكول، تم تطويره بشكل ملحوظ بواسطة أنثروبيك، يحدد كيف يمكن للنماذج اللغوية الكبيرة (LLM) الاتصال بمصادر البيانات الخارجية والأدوات.

الجزء الثاني: المهمة الأساسية: ترجمة اللغة الطبيعية إلى إجراءات_API

الوظيفة الأساسية لوكيل_API هي تفسير طلب اللغة الطبيعية للمستخدم وترجمته إلى أوامر_API دقيقة. هذا العملية عادة ما تتضمن:

1. تعرف النية: فهم هدف المستخدم، حتى لو تم التعبير عنه بشكل غامض.
2. اختيار الأداة: تحديد نقطة نهاية_API المناسبة (أو “الأداة”) من مجموعة من الخيارات المتاحة التي يمكن أن ت满ي النية.
3. استخراج المعلمات: تحديد واستخراج المعلمات اللازمة للأداة التي تم اختيارها من استفسار المستخدم.
4. تنفيذ الاستجابة وتوليدها: إجراء أوامر_API، واستلام الاستجابات، ثم 合amation هذه المعلومات في إجابة متسقة أو أداء إجراء لاحق.

على سبيل المثال، عند طلب مثل “Hey Siri, ما هو الطقس اليوم؟”، يجب على الوكيل تحديد الحاجة إلى الاتصال بواجهة_API للطقس، وتحديد موقع المستخدم الحالي (أو السماح بتحديده)، ثم صياغة أوامر_API لاسترداد معلومات الطقس.

الجزء الثالث: هندسة الحل: المكونات الرئيسية والبروتوكولات

بناء وكلاء_API الفعالين يتطلب نهجًا هندسيًا منظمًا.

1. تعريف “الأدوات” للوكيل

للوصول إلى واجهة_API، يجب أن يتم وصف قدرات واجهة_API إلى نموذج اللغة الكبيرة (LLM) بطريقة يمكنه فهمها. يتم تمثيل كل نقطة نهاية_API أو وظيفة على أنها “أداة”. تعريف أداة قوي يتضمن:

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

2. دور بروتوكول سياق النموذج (MCP)

بروتوكول سياق النموذج (MCP) هو مكون حاسم لاستخدام الأدوات بشكل أكثر стандارديًا ومتينًا. يوفر تنسيقًا منظمًا لتحديد كيف يمكن للنماذج اللغوية الكبيرة (LLM) الاتصال بمصادر البيانات الخارجية والأدوات.

الاستفادة من بروتوكول سياق النموذج (MCP) مفيد لأنها تتيح دمج أدوات متنوعة بسهولة أكبر، وتعزز إعادة استخدام تعريفات الأدوات عبر وكلاء أو نماذج مختلفة. بالإضافة إلى ذلك، يُعتبر من أفضل الممارسات لفرق الهندسة، بدءًا من مواصفات_API المحددة جيدًا، مثل مواصف OpenAPI. تم تصميم أدوات مثل Stainless.ai لمساعدة في تحويل هذه المواصفات إلى تكوينات بروتوكول سياق النموذج (MCP)، مما يسهل عملية جعل واجهات_API “جاهزة للوكيل”.

3. إطارات الوكيل واختيارات التنفيذ

هناك العديد من الإطارات التي يمكن أن تساعد في بناء الوكيل نفسه. تشمل هذه:

• Pydantic: على الرغم من أنه ليس إطارًا حصريًا للوكيل، Pydantic مفيد لتعريف هياكل البيانات وضمان سلامة النوع للمدخلات والمخرجات للأدوات، وهو أمر مهم للاستقرار. العديد من التطبيقات المخصصة للوكيل يستخدمون Pydantic لهذه الصلابة الهيكلية.
• مكتب الوكيل ماب: هذا الإطار مصمم خصيصًا للعمل مع بروتوكول سياق النموذج (MCP)، ويوفر هيكلًا أكثر تحديدًا يتوافق مع ممارسات بناء وكلاء فعالين كما هو موضح في الأبحاث من أماكن مثل Anthropic.
• إطار داخلي: من الشائع أيضًا استخدام وكلاء إنشاء الشفرة (باستخدام أدوات مثل Cursor أو Cline) لمساعدة في كتابة الشفرة الإسكانية للوكيل وأدواته ومنطقه المحيط. تظهر تجربة مختبر جورجيان للذكاء الاصطناعي مع الشركات على تنفيذ الوكلاء أن هذا يمكن أن يكون رائعًا لإنشاء إطارات مخصصة دقيقة.

الجزء الرابع: الهندسة من أجل الموثوقية والأداء

ضمان أن الوكيل يجري أوامر_API بشكل موثوق ويعمل بشكل جيد يتطلب جهدًا هندسيًا متعمقًا. هناك طريقتان لتحقيق ذلك: (1) إنشاء مجموعة البيانات واعتمادها، و (2) هندسة الحث وتحسينه.

1. إنشاء مجموعة البيانات واعتمادها

تدريب (إذا كان ذلك مناسبًا)، اختبار، وتحسين الوكيل يتطلب مجموعة بيانات عالية الجودة. يجب أن تتكون هذه المجموعة من استفسارات اللغة الطبيعية الممثلة وأوامر_API المرغوبة أو النتائج.

• الإنشاء اليدوي: تجميع مجموعة بيانات يدويًا يضمن دقة وملاءمة عالية، ولكنه يمكن أن يكون مكلفًا من حيث العمالة.
• التوليد الاصطناعي: يمكن أن يؤدي توليد البيانات برمجيًا أو باستخدام نماذج اللغة الكبيرة (LLM) إلى توسيع إنشاء مجموعة البيانات، ولكن هذا النهج يطرح تحديات كبيرة. وجد بحث مختبر جورجيان للذكاء الاصطناعي أن ضمان صحة وcomplexity واقعية لأوامر_API والاستفسارات المولدة اصطناعيًا هو أمر صعب للغاية. في كثير من الأحيان، كانت الأسئلة المولدة إما слишком简单 أو معقدة بشكل لا يمكن تصوره، مما جعل من الصعب قياس أداء الوكيل الدقيق. التحقق الدقيق من البيانات المولدة اصطناعيًا هو أمر بالغ الأهمية.

للتقييم الحرج، غالبًا ما توفر مجموعة بيانات صغيرة، عالية الجودة، تم التحقق منها يدوياً رؤى أكثر موثوقية من مجموعة بيانات كبيرة ومضطربة.

2. هندسة الحث وتحسينه

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

• الحفاظ الفعال يتضمن تحديد مهمة الوكيل بوضوح، وتقديم وصف للأدوات المتاحة، وهيكلة الحفاظ لتشجيع استخراج المعلمات الدقيق.
• التحسين المنهجي باستخدام إطارات مثل DSPy يمكن أن يعزز الأداء بشكل كبير. يسمح DSPy بتعريف مكونات الوكيل (مثل الوحدات لتنمية الأفكار، واختيار الأداة، وتنسيق المعلمات) ثم يستخدم نهجًا شبيهًا بالمترجم مع أمثلة قليلة من مجموعة البيانات لfinding الحفاظ الأمثل أو التكوينات لهذه المكونات.

الجزء الخامس: مسار موصى به للوكلاء_API الفعالين

تطوير وكلاء_API القوي هو مجال هندسي تكراري. بناءً على نتائج بحث مختبر جورجيان للذكاء الاصطناعي، يمكن تحسين النتائج بشكل كبير باستخدام سير عمل منهجي مثل:

1. ابداً بواجهات_API الواضحة: ابدأ بواجهات_API موثقة جيدًا، مثل مواصفات OpenAPI، للواجهات التي سيتفاعل معها الوكيل.
2. توحيد وصول الأداة: قم بتحويل مواصفات OpenAPI إلى أدوات بروتوكول سياق النموذج (MCP). يمكن أن تساعد أدوات مثل Stainless.ai في ذلك، مما يخلق طريقة موحدة للوكيل لفهم واستخدام واجهات_API.
3. تنفيذ الوكيل: اختر إطارًا مناسبًا أو نهجًا. قد يتضمن هذا استخدام Pydantic لنمذجة البيانات داخل هيكل وكيل مخصص أو استخدام إطار مثل مكتب الوكيل ماب الذي يتمحور حول بروتوكول سياق النموذج (MCP).
4. تجميع مجموعة بيانات التقييم عالية الجودة: قم بإنشاء أو التحقق الدقيق من مجموعة بيانات من الاستفسارات وآثار_API المرغوبة. هذا أمر بالغ الأهمية للاختبار الموثوق والتحسين.
5. تحسين حفاظ الوكيل ومنطقه: استخدم إطارات مثل DSPy لتعديل حفاظ الوكيل ومنطقه باستخدام مجموعة البيانات لتوجيه التحسينات في الدقة والموثوقية.

الجزء السادس: مثال توضيحي على سير العمل

هنا مثال مبسط يُظهر سير العمل الموصى به لبناء وكيل_API:

الخطوة 1: ابدأ بواجهات_API الواضحة

افترض واجهة_API لادارة قائمة المهام البسيطة، محددة في OpenAPI:

openapi: 3.0.0

info:

title: واجهة_API قائمة المهام

version: 1.0.0

paths:

/tasks:

post:

summary: إضافة مهمة جديدة

requestBody:

required: true

content:

application/json:

schema:

type: object

properties:

description:

type: string

responses:

‘201’:

description: تم إنشاء المهمة بنجاح

get:

summary: الحصول على جميع المهام

responses:

‘200’:

description: قائمة المهام

الخطوة 2: توحيد وصول الأداة

قم بتحويل مواصف OpenAPI إلى تكوينات بروتوكول سياق النموذج (MCP). باستخدام أداة مثل Stainless.ai، قد ينتج عن ذلك:

الخطوة 3: تنفيذ الوكيل

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

الخطوة 4: تجميع مجموعة بيانات التقييم عالية الجودة

قم بإنشاء مجموعة بيانات:

الخطوة 5: تحسين حفاظ الوكيل ومنطقه

استخدم DSPy لتعديل الحفاظ، مع التركيز على التوجيه الواضح، واختيار الأداة، واستخراج المعلمات باستخدام مجموعة البيانات المجمعة للتقييم والتحسين.

من خلال دمج هذه الكتل البنائية – من تعريفات_API المهيكلة وبروتوكولات أدوات معيارية إلى ممارسات بيانات صارمة وتحسين منهجي – يمكن لفرق الهندسة بناء وكلاء_API أكثر قدرة وموثوقية وقابلية للصيانة.