قابلية نقل وكلاء الذكاء الاصطناعي: بدّل بين النماذج دون إعادة بناء وكلائك

Built for Speed: ~10ms Latency, Even Under Load
Blazingly fast way to build, track and deploy your models!
- Handles 350+ RPS on just 1 vCPU — no tuning needed
- Production-ready with full enterprise support
ما المقصود بقابلية نقل وكلاء الذكاء الاصطناعي؟
قابلية نقل وكلاء الذكاء الاصطناعي هي خاصية تضمن بقاء منطق عمل الوكيل ثابتاً بينما يمكن تغيير النموذج الذي يعمل في خلفيته. يشير الوكيل إلى النموذج بالاسم ويستدعي واجهة مستقرة، بينما تظل هوية المزود الذي ينفذ الطلب وبيانات الاعتماد المستخدمة خارج نطاق الوكيل تماماً.
قارن ذلك بنقطة البداية الشائعة؛ حيث يُكتب الوكيل اعتماداً على حزمة تطوير برمجية (SDK) لمزود معين، ويتم وضع مفتاح واجهة برمجة التطبيقات (API Key) الخاص بالمزود داخل بيئة الوكيل، وتنتشر أسماء النماذج في جميع أجزاء الكود. كل عنصر من هذه العناصر يمثل قيداً يربط الوكيل بمزود واحد. أما قابلية النقل فهي ما يحدث عندما تتخلص من هذه القيود الثلاثة.
الفائدة عملية وملموسة: يمكنك اعتماد نموذج أحدث فور صدوره، أو الانتقال إلى مزود بديل عند تعطل المزود الأساسي، أو توجيه الطلبات البسيطة إلى نموذج أصغر، مع الحفاظ على النماذج المستضافة ذاتياً والتجارية خلف واجهة واحدة. لا ينبغي لأي من هذه الإجراءات أن يتطلب تعديل الوكيل نفسه.
لماذا تعد قابلية النقل أكثر صعوبة بالنسبة للوكلاء؟
بالنسبة لروبوتات الدردشة ذات التفاعل الواحد، يعد تبديل النماذج أمراً بسيطاً يكاد يقتصر على تغيير سطر واحد. لكن الوكلاء يزيدون من تعقيد الأمر لأسباب تستحق الذكر، لأنها تحدد ما يجب أن تتعامل معه طبقة قابلية النقل الفعالة.
- الوكلاء ينفذون العديد من الاستدعاءات، وليس استدعاءً واحداً. تتضمن دورة عمل الوكيل الواحد سلسلة من عمليات التخطيط، واستدعاء الأدوات، وإعادة المحاولة، والتعامل مع سياق طويل. يجب أن يظل تبديل النموذج فعالاً عبر كل هذه المراحل، وليس مجرد استجابة واحدة.
- يختلف السلوك باختلاف النموذج. تختلف موثوقية استدعاء الأدوات، ودقة المخرجات المهيكلة، والتعامل مع السياق الطويل بين النماذج، لذا ستحتاج إلى الاختبار والتبديل لكل وكيل على حدة، وأحياناً توجيه خطوات مختلفة إلى نماذج مختلفة.
- تتعدد بيانات الاعتماد. إذا قمت بتضمين المفاتيح في كل وكيل وكل مساحة عمل، فسيصبح تحديث مفتاح المزود عبئاً على مستوى النظام بالكامل. تعني قابلية النقل ألا يحتفظ الوكيل بأي مفاتيح على الإطلاق.
إن طبقة قابلية النقل التي تكتفي بتبديل اسم النموذج بينما تترك بيانات الاعتماد، وآليات التوجيه، وخطط الطوارئ داخل الوكيل، لم تجعل الوكيل قابلاً للنقل حقاً، بل قامت فقط بنقل المشكلة إلى مكان آخر.
كيف تجعل TrueFoundry الوكلاء قابلين للنقل؟
تعتمد TrueFoundry نهجاً يقوم على إدارة الوصول إلى النماذج مرة واحدة، من خلال بوابة الذكاء الاصطناعي (AI Gateway)، والسماح لكل وكيل بالإشارة إلى النماذج بالاسم. تحتفظ البوابة ببيانات اعتماد المزود، وتفرض سياسات الوصول، وتوجه حركة البيانات، بينما يرث الوكلاء كل هذه الإعدادات.
واجهة برمجة تطبيقات موحدة ومتوافقة مع OpenAI
تستقر جميع النماذج، سواء كانت من OpenAI أو Anthropic أو Azure OpenAI أو Google Vertex أو AWS Bedrock أو Databricks أو Together AI أو حتى النماذج التي تستضيفها بنفسك، خلف واجهة برمجة تطبيقات واحدة متوافقة مع OpenAI. ما عليك سوى توجيه الكود الخاص بك إلى البوابة مرة واحدة، ثم التبديل بين النماذج عن طريق تغيير اسم النموذج في الطلب. نفس الرابط، ونفس بيانات الاعتماد.
from openai import OpenAI
client = OpenAI(
api_key="your-truefoundry-api-key", # a gateway token, never a provider key
base_url="https://gateway.truefoundry.ai",
)
# Today:
resp = client.chat.completions.create(
model="openai-main/gpt-4o",
messages=[{"role": "user", "content": "Draft the release notes"}],
)
# Tomorrow, swap the model. Nothing else changes:
resp = client.chat.completions.create(
model="anthropic-main/claude-sonnet-4",
messages=[{"role": "user", "content": "Draft the release notes"}],
)لم يتغير كود الوكيل بأي شكل جوهري، كما لم تتغير بيانات الاعتماد. التعديل الوحيد هو اسم النموذج، وحتى هذا يمكن تجريده، وهو ما سنتناوله في الجزء التالي.
تبديل النماذج للوكلاء دون الحاجة للتعامل مع بيانات الاعتماد
في أداة Agent Harness من TrueFoundry، يُعد النموذج خياراً يتم تحديده في أداة الإنشاء وليس قيمة داخل الكود. يمكنك اختيار أي نموذج متاح لك في البوابة، ويتم التبديل بضغطة زر واحدة دون الحاجة لتعديل الكود أو إدخال بيانات اعتماد جديدة.

لقطة شاشة للمنتج، وثائق TrueFoundry: أداة اختيار النموذج في Agent Harness.
يكمن الاختلاف عن منتجات الوكلاء المُدارة الأخرى في مكان تخزين بيانات الاعتماد. ففي العديد منها، يتعين عليك تقديم مفاتيح واجهة برمجة التطبيقات الخاصة بالمزود عند إنشاء وكيل، أو تسجيلها لكل مساحة عمل. أما في TrueFoundry، فيتم إدارة الوصول إلى النموذج مرة واحدة على مستوى البوابة، ويكتفي الوكلاء بالإشارة إلى أسماء النماذج.
TrueFoundry AI Gateway delivers ~3–4 ms latency, handles 350+ RPS on 1 vCPU, scales horizontally with ease, and is production-ready, while LiteLLM suffers from high latency, struggles beyond moderate RPS, lacks built-in scaling, and is best for light or prototype workloads.














.webp)



.png)
.png)
.png)
.png)
.png)






.png)







