كتالوج نماذج MCP لوكلاء البرمجة: اجعل اختيار النموذج قابلاً للقراءة آلياً (Machine-Readable)

إن وكيل البرمجة الذي يضع أسماء النماذج بشكل ثابت (hardcoded) في الكود سيؤدي في النهاية إلى إيقاظ شخص ما في الساعة الثانية صباحاً. كتالوج نماذج MCP لوكلاء البرمجة يغير نمط الفشل هذا. فبدلاً من وجود سلسلة نصية مدفونة في الكود المصدري، يقرأ الوكيل قائمة منظمة من النماذج الحالية، والتكاليف، والأنماط (modalities)، وحقول الحالة في وقت الطلب. نحن نحتفظ بكتالوج مماثل في TokenLab، ونتعامل مع الكتالوج كمصدر للحقيقة من أجل التوجيه. في خط أنابيبنا (pipeline)، يعد اختيار النموذج عملية بحث (lookup)، وليس ثابتاً.

لماذا تحتاج وكلاء البرمجة إلى بيانات نماذج قابلة للقراءة آلياً

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

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

هذا أيضاً شرط أساسي لتوجيه النماذج (model routing) بشكل جدي. قد ترغب في عمليات إكمال رخيصة وعالية الحجم على DeepSeek V4 Flash أو Gemini 3.5 Flash. وقد تحتفظ بـ Claude Sonnet 5 لعمليات إعادة الهيكلة متعددة الملفات. لا تزال منطق التوجيه بحاجة إلى مصدر للحقيقة. يجب أن يحدد هذا المصدر النماذج الحالية، وتكلفتها، وما تدعمه. بدون ذلك، ستتعفن قواعد التوجيه بنفس الطريقة التي تتعفن بها أسماء النماذج المكتوبة بشكل ثابت.

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

النقاط الرئيسية

• يحول كتالوج النماذج اختيار النموذج من سلسلة نصية ثابتة إلى عملية بحث في وقت التشغيل، مما يقلل من عبء الصيانة عندما يصدر المزودون نماذج جديدة.
• تستفيد وكلاء البرمجة من توجيه أنواع المهام المختلفة (الإكمال التلقائي، إعادة الهيكلة، إنشاء الاختبارات، المراجعة) إلى نماذج مختلفة بدلاً من استخدام نموذج واحد لكل شيء.
• تتبع طلبات MCP لبيانات كتالوج النماذج عادةً شكل قائمة الموارد (resource-list) أو استدعاء الأداة (tool-call)؛ تحقق من المخطط الدقيق مقابل وثائق المزود نفسه قبل البناء بناءً عليه.
• تنشر TokenLab مركز بيانات النماذج (Model Data Center) على /models/data ودليل النماذج على /models؛ تعامل مع هذه الأماكن للتحقق من أسماء النماذج الحالية، وليس هذا المقال، لأن تشكيلات النماذج تتغير بشكل متكرر.

ما الذي يجب أن يتضمنه إدخال كتالوج نماذج MCP

يحتاج إدخال الكتالوج المفيد لوكيل البرمجة إلى أكثر من مجرد اسم نموذج. كحد أدنى، يجب أن يتوقع المطورون والمستهلكون رؤية:

• معرف النموذج (Model identifier): السلسلة النصية الدقيقة التي يتوقعها الـ API، حيث يقوم المزودون غالباً بإصدار أسماء دقيقة (عدم التطابق هنا هو أحد أكثر أخطاء التكامل شيوعاً).
• المزود (Provider): الشركة أو المنصة التي تخدم النموذج، وهو أمر ذو صلة عندما يجمع الكتالوج عدة مزودين.
• دعم الأنماط (Modality support): نص، كود، صورة، أو فيديو. الكتالوج الذي يمزج بين نماذج البرمجة مثل Kimi K2.7 Code ونماذج الصور مثل Nano Banana Pro يحتاج إلى حقل يسمح للوكيل بالتصفية بناءً على ما يحتاجه فعلياً.
• نافذة السياق (Context window): حدود الـ token مهمة للغاية لوكلاء البرمجة الذين يعملون عبر مستودعات كبيرة.
• حقول التكلفة (Cost fields): تسعير الـ token للإدخال والإخراج، ويفضل أن يكون منفصلاً، حيث غالباً ما يكون لدى وكلاء البرمجة أعباء عمل غير متماثلة تعتمد على الإدخال (سياق ملف كبير، مخرجات diff صغيرة).
• الحالة (Status): حالي، موقوف، أو مجدول للإيقاف. هذا هو الحقل الذي يمنع التوقف الصامت.
• وسوم ملاءمة المهام (Task suitability tags): بيانات وصفية اختيارية ولكنها مفيدة مثل 'coding'، أو 'low-cost routing'، أو 'open-weight'، حتى يتمكن الوكيل من التصفية دون معرفة خصائص كل نموذج مسبقاً.

لا يوجد ضمان بوجود أي من هذه الحقول في تنسيق كتالوج كل مزود. قبل بناء تكامل، تحقق من المخطط الفعلي الموثق لدى المزود الذي تستخدمه. بالنسبة للنماذج التي تقدمها TokenLab تحديداً، تحقق من مجموعة الحقول الحالية وتيرة التحديث على /models/data بدلاً من افتراض أنها تتطابق مع هذا المقال. تتغير مخططات الكتالوج مع إضافة نماذج وأنماط جديدة.

مثال: طلب كتالوج نماذج عبر MCP

يتواصل MCP عادةً عبر JSON-RPC 2.0. قد يرسل العميل الذي يطلب من الخادم سرد موارد النماذج المتاحة طلباً بهذا الشكل. يتبع هذا المثال نمط قائمة موارد MCP العام. إنه ليس ادعاءً حول المخطط المباشر لأي مزود معين. تأكد من أسماء الطرق الدقيقة وحقول الاستجابة مقابل https://docs.tokenlab.sh أو وثائق خادم MCP الخاص بك قبل كتابة كود الإنتاج بناءً عليه.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "resources/list",
  "params": {
    "filter": {
      "modality": "text",
      "tag": "coding"
    }
  }
}

شكل استجابة معقول، توضيحي مرة أخرى وليس مخططاً تم التحقق منه:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "resources": [
      {
        "id": "claude-sonnet-5",
        "provider": "Anthropic",
        "modality": ["text", "code"],
        "context_window": "verify at provider docs",
        "status": "current",
        "tags": ["coding", "review"]
      },
      {
        "id": "deepseek-v4-flash",
        "provider": "DeepSeek",
        "modality": ["text", "code"],
        "context_window": "verify at provider docs",
        "status": "current",
        "tags": ["low-cost", "coding"]
      }
    ]
  }
}

لا تتعامل مع قيم نافذة السياق، أو أسماء الحقول الدقيقة، أو النماذج المحددة المذكورة أعلاه كحقائق مؤكدة حول أي API مباشر. إنها تظهر شكل الطلب والاستجابة، وليس أرقام التسعير أو القدرات. اسحب تلك الأرقام من وثائق المزود الحالية أو من /models/data عند البناء.

اختيار النماذج حسب المهمة: قائمة مرجعية للقرار

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

مهمة وكيل البرمجة	ما يهم أكثر	نماذج أمثلة للتقييم
الإكمال التلقائي / الاقتراحات المضمنة	زمن انتقال منخفض، تكلفة منخفضة لكل استدعاء	DeepSeek V4 Flash, Gemini 3.5 Flash, Laguna XS 2.1
إعادة الهيكلة متعددة الملفات	نافذة سياق أكبر، استدلال قوي للكود	Claude Sonnet 5, DeepSeek V4 Pro
إنشاء الاختبارات	تنسيق متسق، استدلال معتدل	Kimi K2.7 Code, Claude Sonnet 5
مراجعة الكود / تلخيص PR	استدلال قوي، القدرة على الإشارة إلى diffs بدقة	Claude Sonnet 5, Gemini 3.5 Flash
مهام الدفعات عالية الحجم (linting، تعليقات التوثيق)	التكلفة لكل token فوق القدرة الخام	GLM-5.2, Qwen3.7 Plus, MiniMax M3
متطلبات الأوزان المفتوحة (استضافة ذاتية أو قيود ترخيص)	أوزان مفتوحة، قابلة للنشر خارج API مدار	GLM-5.2, DeepSeek V4 Pro, DeepSeek V4 Flash, Qwen3.7 Plus, Kimi K2.7 Code

قائمة مرجعية عملية لبناء منطق التوجيه نفسه:

1. هل يتضمن إدخال الكتالوج حقل حالة، حتى تتمكن من اكتشاف الإيقاف قبل فشل الاستدعاء؟
2. هل يفصل الكتالوج النماذج القادرة على البرمجة عن النماذج النصية أو الصورية العامة، بحيث لا تتطلب التصفية قوائم ثابتة؟
3. هل يمكنك تحديد سقف تكلفة لكل نوع مهمة وجعل الوكيل يختار أرخص نموذج يلبي ذلك، بدلاً من الافتراض دائماً بالخيار الأكثر قدرة (والأغلى)؟
4. هل يوجد نموذج احتياطي محدد لكل فئة مهمة، في حال كان الخيار الأساسي غير متاح أو محدود المعدل؟
5. هل تعيد التحقق من الكتالوج وفق جدول زمني، وليس فقط عند التكامل الأول، حيث تتغير تشكيلات النماذج بمرور الوقت؟

أين تتناسب TokenLab في سير العمل هذا

تحتفظ TokenLab بمركز بيانات النماذج على /models/data ودليل النماذج على /models، وكلاهما تمت ملاحظته اعتباراً من 2026-07-14. تحقق من هذه الأسطح للحصول على قوائم النماذج الحالية بدلاً من الاعتماد على أي مقال ثابت. كتالوجات النماذج حساسة للوقت بطبيعتها. وثائق API الخاصة بـ TokenLab على https://docs.tokenlab.sh هي المكان المناسب للتحقق من مخططات الطلب والاستجابة الدقيقة قبل التكامل.

قد تبني وكيل برمجة يوجه بين عدة نماذج. استخدم Claude Sonnet 5 لمهام المراجعة، و DeepSeek V4 Flash لعمليات الإكمال الرخيصة عالية الحجم، و Kimi K2.7 Code لإنشاء الاختبارات. تعامل مع معرف النموذج كمتغير. قم بحله في وقت الطلب مقابل كتالوج، وليس كمتغير ثابت مجمع في كود مصدر الوكيل الخاص بك. الخطوة العملية هي التحقق من /models/data وتأكيد شكل الطلب الذي يحتاجه عميل MCP الخاص بك مقابل وثائق API الخاصة بـ TokenLab. قم بتوصيل منطق التوجيه في الإنتاج فقط بعد تلك الفحوصات.

القيود

يصف هذا المقال نمطاً عاماً لكتالوجات نماذج MCP وتوجيه وكلاء البرمجة. إنه لا يؤكد أن أي مزود معين، بما في ذلك TokenLab، يكشف عن كل حقل موصوف أعلاه (نافذة السياق، حقول التكلفة، الحالة، وسوم المهام) بهذا الشكل بالضبط. تتغير المخططات، وأسماء الحقول، والنماذج المتاحة بشكل متكرر. تعامل مع أمثلة JSON في هذا المقال كتوضيح لنمط طلب واستجابة MCP العام، وليس كمخطط تم التحقق منه لأي نقطة نهاية مباشرة. قبل الشحن، تأكد من معرفات النماذج الدقيقة، والتسعير، ونوافذ السياق مقابل وثائق المزود الحالية ومقابل /models/data.

الأسئلة الشائعة

هل يحدد MCP نفسه مخطط كتالوج نماذج قياسي؟

يحدد MCP أنماطاً عامة للموارد والأدوات عبر JSON-RPC، ولكن الحقول الدقيقة في كتالوج النماذج (التسعير، نافذة السياق، الحالة) تعتمد على كيفية اختيار الخادم الذي ينفذ MCP لكشف تلك البيانات. تحقق من المخطط المحدد مع الخادم أو المزود الذي تتكامل معه.

هل يجب أن يستخدم وكيل البرمجة دائماً النموذج الأكثر قدرة المتاح؟

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

كم مرة يجب أن أعيد التحقق من كتالوج النماذج الذي يعتمد عليه وكيل البرمجة الخاص بي؟

تتغير تشكيلات النماذج بشكل متكرر بما يكفي لدرجة أن التكامل لمرة واحدة ليس كافياً. ابنِ منطق التوجيه الخاص بك للاستعلام عن الكتالوج بدلاً من تخزين معرفات النماذج مؤقتاً بشكل دائم، وتحقق من /models/data أو وثائق المزود الخاص بك وفق جدول زمني منتظم.

ابدأ بمراجعة القوائم الحالية على /models/data وتأكيد شكل الطلب الذي يحتاجه عميل MCP الخاص بك مقابل وثائق API الخاصة بـ TokenLab قبل توصيل منطق التوجيه في الإنتاج.