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

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

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

أهم النقاط

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

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

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

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

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

كتبت TokenLab عن هذه المشكلة مباشرة في سياق جعل معلومات النموذج شيئاً يمكن للوكيل الوثوق به بدلاً من شيء يجب على الإنسان إعادة التحقق منه يدوياً. راجع agent-readable model truth للحصول على الحجة الأوسع حول حقيقة النموذج القابلة للقراءة آلياً، و agent-first API حول كيفية تغير تصميم API عندما يكون المتصل الأساسي وكيلاً وليس مطوراً بشرياً.

ما الذي يجب أن يحتويه إدخال كتالوج نماذج 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 الخاص بك مقابل وثائق TokenLab API قبل توصيل منطق التوجيه في الإنتاج.

القيود

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

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

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

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

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