Written with AI assistance from the source video. The video is the authority.
Log in to leave a comment
No posts yet
لقد فشل مفهوم "التقسيم المجهري" (Micro-sharding) الذي روجت له أدوات مثل LangChain أو AutoGPT. تقسيم الخطوات إلى عشرات الأجزاء قد يجعل سلسلة المنطق تبدو دقيقة، لكنه في الواقع يؤدي إلى بتر السياق مع كل استدعاء، مما يزيد من عدم اليقين. عند استخدام نماذج LLM ذات قدرات استدلال متطورة مثل Claude 3.5 أو نموذج 4 القادم، يجب تغيير الاستراتيجية. لا تصارع العقد المتناثرة؛ بدلاً من ذلك، يجب الدمج في هيكل مركزي لإدارة الحالة يتم التحكم فيه بواسطة الـ Planner.
من أجل انتقال ناجح للهندسة المعمارية، قم أولاً بتجميع المهام المجهرية الحالية كطرق (methods) داخل فئة واحدة وقم بتغليفها في "مخزن أدوات" (Tool Box). بعد ذلك، حدد كائن State موحد يشير إليه جميع الوكلاء. يجب أن يتضمن هذا الكائن حقولاً أساسية مثل plan (خطة خطوة بخطوة)، وhistory (سجل تنفيذ الأدوات)، وartifacts (البيانات المولدة).
استفد من ميزة الـ reducer في LangGraph لجعل كل وكيل يقوم بتحديث هذه الحالة المشتركة فور انتهاء مهمته. من خلال منع انقطاع السياق مادياً، سيختفي إرسال التوكنات المكررة. الفرق التي انتقلت إلى هذا الهيكل سجلت بالفعل توفيراً فورياً في تكاليف واجهة برمجة التطبيقات (API) بنسبة تزيد عن 30%.
إن الحكم الذاتي على مخرجات الوكيل بأنها "تبدو جيدة" لا يقل عن كونه قنبلة موقوتة في بيئة التشغيل الفعلية. يجب اعتماد نمط LLM-as-a-Judge، وفرضه برمجياً على مستوى الكود. يجب على وكيل الـ Evaluator تقسيم مخرجات الـ Generator إلى أربعة مؤشرات: الدقة، الاتساق، القابلية للقراءة، والكفاءة، وتحويلها إلى أرقام.
استخدم مكتبة Pydantic لإجبار نتائج التقييم على اتباع مخطط JSON محدد.
RubricScore واضبط كل مؤشر كحقل صحيح بين 1 و 5.Merge Block لإيقاف النشر تلقائياً في خط أنابيب CI/CD وإرسال إشارة لإعادة العمل.بناء نظام التحقق الآلي هذا يقلل من وقت التحقق الذي كان يستغرق 5 ساعات يدوياً إلى أقل من 10 دقائق. قد يكون التقييم الميكانيكي صارماً، لكنه يزيد من إمكانية التنبؤ بالنظام.
بمجرد أن تبدأ حلقة الوكيل في الدوران، تتراكم التوكنات بسرعة مخيفة. إرسال تعليمات النظام وتعريفات الأدوات في كل مرة هو بمثابة إلقاء المال في الشارع. تفرض ميزة تخزين المطالبات مؤقتاً (Prompt Caching) في Claude حوالي 10% فقط من الرسوم العادية للتوكنات المخزنة. للاستفادة من هذه الميزة، يجب استخدام استراتيجية مطابقة البادئة (Prefix matching) لترتيب هيكل المطالبة من الأجزاء الثابتة إلى الديناميكية (Tools ← System ← Messages).
cache_control.<system-reminder> داخل رسائل المستخدم لإدراج المعلومات المتغيرة. هذا يضمن عدم كسر التخزين المؤقت للبادئة العلوية.تصميم استراتيجية التخزين المؤقت بشكل صحيح يمكن أن يخفض تكاليف استدعاء API بنسبة تصل إلى 90%. كما ستصبح سرعة الاستجابة أسرع بشكل ملحوظ. إنها الطريقة الوحيدة لكسب المال والوقت معاً.
إذا تمسك كل من الـ Generator والـ Evaluator برأيهما ولم يصلا إلى اتفاق، فسيقع الوكيل في حالة جمود (Deadlock). هذه ليست مجرد خطأ بسيط، بل كارثة تؤدي إلى انفجار التكاليف. لمنع ذلك، نحتاج إلى قاطع دائرة متعدد الطبقات يراقب عدد العمليات وتشابه الاستجابات. خصيصاً، إذا كان تشابه الجيب تماماً (Cosine similarity) بين الاستجابة السابقة والحالية 0.95 أو أكثر، فهذه إشارة واضحة على أن الوكيل يكرر نفسه ويدور في حلقة غبية.
منح الوكيل سلطة كاملة ليس شجاعة، بل عدم مسؤولية. نظام وكيل بدون أجهزة أمان هو نظام يفضل عدم تشغيله.
عملية عمل الوكلاء الثلاثة معاً هي "صندوق أسود". إذا لم تكن تعرف أين يحدث الاختناق، فلن تتمكن من التحسين. قم بربط نظام تتبع يتبع معايير OpenTelemetry لتصور تدفق الرسائل بين الوكلاء. تنفيذ نقاط التفتيش (Checkpointing) القائمة على Redis يتيح لك الاستمرار من آخر نقطة نجاح بدلاً من البدء من الصفر في حال تعطل النظام.
استخرج قيمة cache_read_input_tokens من ترويسات استجابة API وارسمها على لوحة التحكم. إذا كان معدل نجاح التخزين المؤقت منخفضاً، فهذا دليل على خطأ في هيكل المطالبة. أيضاً، من خلال تحويل سرعة تقارب الحلقة إلى مؤشر، يمكنك إثبات نتائج هندسة المطالبات بالأرقام. يتيح تخزين معرفات الجلسات وإصدارات القطع الأثرية (Artifacts) في PostgreSQL مراجعة دقيقة للنقاط التي تعثر فيها فريق الوكلاء في الماضي. الوكيل الذي لا يتم تسجيل سجلاته لن يصبح ذكياً أبداً.