الدروس المستفادة من الترقية إلى LangChain 1.0 في الإنتاج

أول إصدار مستقر لإصدار v1.0 في أواخر أكتوبر 2025. بعد قضاء الشهرين الماضيين في العمل مع واجهات برمجة التطبيقات الجديدة الخاصة بهم، أشعر حقًا أن هذا هو الإصدار الأكثر تماسكًا وتصميمًا مدروسًا من LangChain حتى الآن.

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

هذا ليس كذلك بالمناسبة، منشور دعائي — أود أن أسمع أفكارك، فلا تتردد في مراسلتي مباشرة هنا!

هذه المقالة ليست هنا لتجديد المستندات. أفترض أنك قد انخرطت بالفعل في LangChain (أو أنك مستخدم كثيف). بدلاً من التخلص من قائمة النقاط، سأقوم باختيار أربع نقاط رئيسية فقط.

خلاصة سريعة: LangChain، وLangGraph، وLangSmith

على مستوى عالٍ، يعد LangChain إطارًا لبناء تطبيقات ووكلاء LLM، مما يسمح للمطورين بشحن ميزات الذكاء الاصطناعي بسرعة مع التجريدات الشائعة.

LangGraph هو محرك تنفيذ قائم على الرسم البياني لسير عمل الوكيل المتين والفعال بطريقة يمكن التحكم فيها. وأخيرًا، تعد LangSmith عبارة عن منصة مراقبة للتتبع والمراقبة.

ببساطة: يساعدك LangChain على بناء الوكلاء بسرعة، ويقوم LangGraph بتشغيلهم بشكل موثوق، ويتيح لك LangSmith مراقبتهم وتحسينهم في الإنتاج.

كومة بلدي

بالنسبة للسياق، تركز معظم أعمالي الأخيرة على بناء ميزات متعددة الوكلاء لمنصة الذكاء الاصطناعي التي تواجه العملاء في العمل. مكدس الواجهة الخلفية الخاص بي هو FastAPI، مع التحقق من صحة مخطط Pydantic وعقود البيانات.

الدرس الأول: إسقاط الدعم لنماذج Pydantic

كان التحول الرئيسي في الهجرة إلى الإصدار 1.0 هو تقديم الإصدار الجديد create_agent طريقة. إنه يبسط كيفية تعريف الوكلاء واستدعاءهم، ولكنه أيضًا يسقط الدعم لنماذج Pydantic وفئات البيانات في حالة الوكيل. يجب الآن التعبير عن كل شيء بامتداد TypedDicts AgentState.

إذا كنت تستخدم FastAPI، فغالبًا ما يكون Pydantic هو مدقق المخطط الافتراضي والموصى به. لقد أقدر اتساق المخطط عبر قاعدة التعليمات البرمجية وشعرت أن المزج بين نماذج TypedDicts وPydantic سيؤدي حتمًا إلى حدوث ارتباك – خاصة بالنسبة للمهندسين الجدد الذين قد لا يعرفون تنسيق المخطط الذي يجب اتباعه.

لحل هذه المشكلة، قدمت مساعدًا صغيرًا يحول نموذج Pydantic إلى TypedDict الذي يمتد AgentState مباشرة قبل أن يتم تمريره إلى create_agent . من المهم ملاحظة أن LangChain يقوم بإرفاق بيانات تعريف مخصصة لكتابة التعليقات التوضيحية التي يجب عليك الاحتفاظ بها. المرافق بايثون مثل get_type_hints() قم بإزالة هذه التعليقات التوضيحية، مما يعني أن التحويل البسيط لن ينجح.

الدرس الثاني: الوكلاء العميقون لديهم رأي حسب التصميم

إلى جانب الجديد create_agent جاءت واجهة برمجة التطبيقات (API) في LangChain 1.0 شيئًا لفت انتباهي: deepagents مكتبة. مستوحاة من أدوات مثل Claude Code وManus، يستطيع الوكلاء العميقون التخطيط وتقسيم المهام إلى خطوات وحتى إنشاء وكلاء فرعيين.

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

ال deepagents المكتبة برأيها إلى حد ما، وإلى حد كبير حسب التصميم. يأتي كل وكيل عميق مزودًا ببعض البرامج الوسيطة المضمنة – أشياء مثل ToDoListMiddleware, FilesystemMiddleware, SummarizationMiddlewareوما إلى ذلك. وهي تشكل كيفية تفكير الوكيل وتخطيطه وإدارته للسياق. المصيد هو أنك لا يمكن السيطرة عليها بالضبط عند تشغيل هذه البرامج الوسيطة الافتراضية، ولا يمكنك أيضًا تعطيل البرامج التي لا تحتاج إليها.

بعد الحفر في deepagents رمز المصدر هنا، يمكنك أن ترى أن معلمة البرنامج الوسيط هي إضافي الوسيطة لتطبيق بعد الوسيطة القياسية. أي برامج وسيطة تم تمريرها middleware=[...] يتم إلحاقه بعد الإعدادات الافتراضية.

كل هذا التنسيق الإضافي قدم أيضًا زمن وصول ملحوظًا، وقد لا يوفر فائدة ذات معنى. لذلك، إذا كنت تريد مزيدًا من التحكم الدقيق، فالتزم بالبساطة create_agent طريقة.

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

الميزة المفضلة لدي: الإخراج المنظم

بعد نشر الوكلاء في الإنتاج، خاصة تلك التي تتكامل مع أنظمة المؤسسة الحتمية، كان جعل الوكلاء ينتجون باستمرار مخرجات مخطط معين أمرًا بالغ الأهمية.

يجعل LangChain 1.0 هذا الأمر سهلاً للغاية. يمكنك تحديد مخطط (على سبيل المثال، نموذج Pydantic) وتمريره إليه create_agent عبر response_format المعلمة. يقوم الوكيل بعد ذلك بإنتاج مخرجات تتوافق مع هذا المخطط ضمن حلقة وكيل واحد دون أي خطوات إضافية.

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

ما أريد استكشاف المزيد منه: البرامج الوسيطة

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

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

في الآونة الأخيرة، في أحدث إصدار ثانوي v1.1، أضافت LangChain أيضًا نموذجًا وسيطًا لإعادة المحاولة مع تراجع أسي قابل للتكوين، مما يسمح بالاسترداد السلس لأخطاء نقطة النهاية العابرة.

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

قائمة البرامج الوسيطة هذه آخذة في النمو ومن المفيد حقًا أن تظل محايدة للمزود. إذا قمت بتجربة البرامج الوسيطة في عملك، فأنا أرغب في سماع ما وجدته أكثر فائدة!

لينتهي

هذا كل ما لدينا الآن – أربعة أفكار رئيسية مما تعلمته حتى الآن عن LangChain. وإذا قرأ هذا أي شخص من فريق LangChain، يسعدني دائمًا مشاركة تعليقات المستخدمين في أي وقت أو ببساطة الدردشة 🙂

استمتع بالبناء!