إذا بنيت أي شيء جدي باستخدام نماذج اللغة الكبيرة في Python خلال العامين الماضيين، فمن المحتمل أنك كتبت نفس الشيفرة المتكررة ثلاث مرات: تحليل رد النموذج، التحقق منه مقابل مخطط، إعادة المحاولة عند JSON غير صالح، تسجيل المكالمة، تبديل المزود حين يتعطل أحدهم، ثم محاولة الشرح لمراجع شيفرة لماذا «إطارك» تحول إلى اثني عشر ملفًا من شيفرة الترقيع. الجيل الأول من مكتبات الوكلاء — LangChain وHaystack وإصدارات CrewAI الأولى — حل مشكلة الاكتشاف لكنه لم يحل مشكلة المتانة. علّم جيلًا من المهندسين ما يستطيع الوكيل فعله، لكنه لم يمنحهم طريقة مريحة لوضعه في الإنتاج.
في عام 2026، المشروع الذي تتجه إليه معظم الفرق بدلًا من ذلك هو Pydantic AI. بُني على يد الفريق نفسه الذي يقف خلف Pydantic، مكتبة التحقق التي تعمل أصلًا داخل FastAPI وLangChain وحزمة OpenAI لـ Python وكل أداة تقريبًا تستخدمها. الفرضية بسيطة: إذا كانت Pydantic هي طبقة المخططات الفعلية في Python، فإن إطار وكلاء مبنيًا فوقها يجب أن يكون الخيار الافتراضي الممل وآمن الأنواع — لا برج تجريد جديد.
الإجابة في 30 ثانية
Pydantic AI هو إطار وكلاء بايثون يتعامل مع نداءات نماذج اللغة كأنها نداءات دوال مكتوبة الأنواع. تُعرّف المدخلات والمخرجات كنماذج Pydantic، وتُسجّل الأدوات كدوال Python بسيطة، ويتولى الإطار التحقق وإعادة المحاولة والبث وتبديل المزود. يعمل مع OpenAI وAnthropic وGoogle وMistral وGroq وCohere وBedrock وأي نقطة نهاية متوافقة مع OpenAI، ويتكامل أصلًا مع Logfire للرصد دون توصيلات إضافية.
اختر Pydantic AI حين تريد مخرجات منظمة بجودة الإنتاج، وسلوكًا قابلًا للتوقع عند إعادة المحاولة، ومساحة API يمكنك قراءتها من البداية إلى النهاية في فترة بعد الظهر.
لماذا تنتقل الفرق بعيدًا عن LangChain
نمط الترحيل في عام 2026 ثابت بشكل ملحوظ. تبدأ الفرق على LangChain لأن الدروس متاحة في كل مكان، تصطدم باثنين أو ثلاثة من الجدران التالية، ثم تقيّم البدائل:
- انجراف المخططات بين الطبقات. أي تغيير في نموذج خرج Pydantic لا ينساب تلقائيًا عبر السلاسل والوكلاء والاسترجاعات. تنتهي بترقيع الشكل نفسه في أربعة أماكن.
- حالة مخفية ومتغيرات عامة ضمنية. الذاكرة والاسترجاعات والتتبع تُضبط عبر آثار جانبية. ميزتان غير مرتبطتين تبدآن بالتفاعل في الإنتاج.
- تذبذب الإصدارات. الإصدارات الكبرى من LangChain تقسّم الحزم وتعيد تسمية الوحدات وتغيّر واجهات API بأسرع مما تستطيع معظم الفرق إعادة هيكلة شيفرتها.
- تصحيح بالأخطاء عبر تتبع المكدّس. حين تسوء سلسلة، يكون التتبع جدارًا من أسماء الفئات الداخلية. قراءة ما رآه النموذج فعلًا أصعب مما ينبغي.
- تشظي المزودين. كل مزود نموذج له خصوصياته في استدعاء الأدوات والمخرجات المنظمة والبث. تبديل المزود يتطلب أكثر من تغيير في الإعدادات.
صُمم Pydantic AI كردّ مباشر على هذه المشكلات. الإطار يحوي نحو عشرين مفهومًا عامًا، بلا حالة عالمية، ولا سجل استرجاعات، وبتجريد واحد موحد لاستدعاء الأدوات عبر المزودين. تقرأ الشيفرة المصدرية في فترة بعد الظهر وتستطيع التنبؤ بما يفعله كل سطر.
البنية الأساسية
برنامج Pydantic AI مبنيٌّ حول ثلاث بنى أولية: Agent، وoutput_type مكتوب الأنواع، وtools اختيارية. كل ما عدا ذلك — البث وإعادة المحاولة والحوار متعدد الأدوار والتسجيل المنظم — يضاف فوقها دون تغيير هذه البنى.
مثال بسيط:
from pydantic import BaseModel
from pydantic_ai import Agent
class Order(BaseModel):
product: str
quantity: int
customer: str
agent = Agent(
"anthropic:claude-opus-4-7",
output_type=Order,
system_prompt="استخرج تفاصيل الطلب من رسالة المستخدم.",
)
result = agent.run_sync("سارة من تونس طلبت ثلاثة حواسيب محمولة بحجم 14 بوصة.")
print(result.output)
# Order(product='حاسوب محمول 14 بوصة', quantity=3, customer='سارة')نقطتان تستحقان التوقف عندهما. أولًا، result.output هو نسخة حقيقية من Order — ليس قاموسًا ولا سلسلة JSON عليك تحليلها. محرر الشيفرة يعرف الشكل، الاختبارات تتحقق من حقول حقيقية، وأي دالة لاحقة تأخذ Order يتم فحص أنواعها مقابل هذا الاستدعاء. ثانيًا، معرّف النموذج مجرد سلسلة نصية. الانتقال إلى openai:gpt-5-3 أو google-gla:gemini-3-pro تغيير من سطر واحد؛ الإطار يطبّع استدعاء الأدوات والمخرجات المنظمة داخليًا.
الأدوات وحقن الاعتماديات
الوكلاء الحقيقيون يحتاجون إلى أكثر من تحويل النص. إنهم يقرأون قواعد البيانات، ويستدعون خدمات HTTP، ويكتبون إلى طوابير الرسائل. يعالج Pydantic AI ذلك بفكرتين مستعارتين من FastAPI: الأدوات كدوال مزخرفة، وdeps_type مكتوب الأنواع يتدفق إلى كل استدعاء أداة.
from dataclasses import dataclass
from pydantic_ai import Agent, RunContext
@dataclass
class Deps:
db: Database
http: AsyncClient
region: str
agent = Agent(
"anthropic:claude-opus-4-7",
deps_type=Deps,
system_prompt="أنت مساعد مبيعات لـ noqta.tn.",
)
@agent.tool
async def get_customer(ctx: RunContext[Deps], customer_id: int) -> dict:
return await ctx.deps.db.fetch_customer(customer_id, region=ctx.deps.region)
@agent.tool
async def lookup_pricing(ctx: RunContext[Deps], sku: str) -> dict:
response = await ctx.deps.http.get(f"/pricing/{sku}")
return response.json()ثلاث خصائص ملائمة للإنتاج تنبثق من هذا التصميم. الاختبارات تحقن Deps وهمية وتتحقق من السلوك دون لمس الشبكة. السياق لكل طلب — معرّف المستأجر، علم ميزة، مدى تتبع — يتدفق دون متغيرات عامة. ولأن الأدوات مكتوبة الأنواع، يستطيع الإطار وصفها للنموذج بدقة، والتحقق من استدعاءات الأدوات قبل تنفيذها.
البث مع التحقق
البث هو المكان الذي يتخلى فيه كثير من أطر الوكلاء بهدوء عن أمان الأنواع. يحافظ Pydantic AI على العقد: الحمولة المبثوثة يتم التحقق منها بشكل تدريجي، ومعالِجك يرى كائنًا مكتوب الأنواع بمجرد وصول قدر كافٍ منه.
async with agent.run_stream("لخّص طلبات الأسبوع الماضي.") as response:
async for partial in response.stream_structured():
render(partial) # partial كائن مكتوب الأنواع، وليس سلسلة نصيةهذا مهم حين يبث نموذج اللغة كائن JSON جزئيًّا قد يُسقط json.loads عادة. محلّل Pydantic AI يتسامح مع الحالة في الطيران، يكشف ما هو صالح حاليًا، ويؤكد القيمة عند إغلاق التدفق.
الرصد بدون شيفرة ترقيع
يأتي Pydantic AI مع تكامل من الدرجة الأولى مع Logfire. شغّله، وكل تشغيل وكيل، وكل استدعاء أداة، وكل إعادة محاولة، وكل تكلفة بالرموز تظهر في شجرة تتبع واحدة، مع المطالبات والإكمالات والمخرجات المتحقق منها مرفقة. لا يوجد معالج استرجاع منفصل لتسجيله، ولا مكتبة تسجيل موازية لإعدادها.
import logfire
logfire.configure()
logfire.instrument_pydantic_ai()للفرق التي تستخدم OpenTelemetry بالفعل، يصدر Pydantic AI spans قياسية، فتصل البيانات نفسها إلى Datadog أو Honeycomb أو Grafana Tempo دون تغيير في الشيفرة. هذا أكبر سبب يذكره مهندسو الإنتاج لتبرير الانتقال: تصحيح الأخطاء في الإنتاج يصبح نفس سير العمل الذي يستخدمونه أصلًا لخدمات HTTP.
متى تستخدم Pydantic AI مقابل البدائل
استقر مشهد وكلاء Python في 2026 على تقسيم واضح.
- Pydantic AI يفوز حين تحتاج مخرجات منظمة موثوقة، وبصمة اعتماديات صغيرة، ورصدًا يلائم الأدوات الموجودة. النقطة المثالية أنظمة وكيل واحد أو أنظمة متعددة الوكلاء متواضعة، بعقود واضحة بين الخطوات.
- LangGraph يفوز حين يكون سير العمل رسمًا حقيقيًا ذا حالة، فيه فروع وحلقات ونقاط تفتيش بشرية. إذا وجدت نفسك ترسم الوكيل على لوح أبيض بأسهم، فتلك إشارة.
- CrewAI يفوز لفرق الوكلاء القائمة على الأدوار التي تتعاون على مهمة طويلة، حيث لكل وكيل شخصية ومهمة. النموذج الذهني فريق صغير، لا دالة.
- OpenAI Agents SDK يفوز داخل حزمة عمل تعتمد على OpenAI حصرًا، حيث ميزات المنصة (التسليمات، التتبع، الجلسات) تتوافق مع طريقة عملك القائمة.
Pydantic AI لا يحاول فعل كل شيء. هذا الانضباط هو جوهر الأمر. أغلب وكلاء الإنتاج ليسوا رسوم خمسة عشر عقدة؛ بل خطوة أو خطوتان مكتوبتا الأنواع تلتفان حول استدعاء نموذج، وPydantic AI هو أقصر طريق إلى ذلك.
ما الذي يجب مراقبته في 2026
ثلاثة أمور تستحق المتابعة. أولًا، يصبح التكامل مع Pydantic Logfire المسار الافتراضي للرصد في أحمال الذكاء الاصطناعي في Python — توقّع أن تتوحد أطر أخرى على شكل تتبعه. ثانيًا، أنماط الوكلاء المتعددين تنزل كطبقة رقيقة فوق الوكلاء المنفردين بدلًا من تجريد منفصل، مما يحافظ على صغر مساحة API. ثالثًا، يُستخدم الإطار بشكل متزايد كتطبيق مرجعي لمعايير المخرجات المنظمة، ما يعني أن مزودي النماذج يضبطون أداء نماذجهم على مسارات التحقق التي يثيرها بالضبط.
إن كنت تبدأ مشروع ذكاء اصطناعي جديدًا في Python اليوم، فابدأ بـ Pydantic AI افتراضيًّا، والجأ إلى LangGraph أو CrewAI حين تستلزم بنية مشكلتك ذلك فعلًا، وقاوم إغراء إضافة إطار قبل أن تكتب الوكيل بدونه. الشيفرة المملة المكتوبة الأنواع القابلة للرصد عادت إلى الموضة — وللذكاء الاصطناعي في الإنتاج، هذه هي الموضة الصحيحة تمامًا.