شرح Habr AI كيفية بناء وكيل إنتاج مع حالة دائمة وخطوات وأحداث

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

لعرض توضيحي هذا مقبول، لكن وكيل الإنتاج يمكنه تحليل المستندات والانتظار لتأكيد المستخدم وتنفيذ سلسلة طويلة من الإجراءات، لذلك بعد الفشل يحتاج إلى التعافي من قاعدة بيانات وليس من أجزاء الفور. كحد أدنى من الكيانات الدائمة، يسرد المؤلف AgentTurn وAgentPlanItem وAgentEvent، وكذلك يلاحظ أن ApprovalGrant وSessionContext وBackgroundJob تظهر بشكل لا مفر منه قريباً. الفكرة هي أن الحالة الدائمة تصف ليس فقط الإجابة النهائية بل المسار بأكمله إليها: الطلب الأصلي والأمر المعياري والأعلام الوقائية وحالات التنفيذ والأخطاء المحتملة.

AgentTurn في هذا المخطط هو سجل كامل لدور المستخدم الواحد. يخزن معرّف الجلسة وturn_id ونص الرسالة والأمر المعياري وحالة المعالجة مثل created وplanned وawaiting_approval وrunning وcompleted أوfailed. من المهم أن يلتقط الدور كل من output_text النهائي والخطأ في حالة فشل التنفيذ.

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

إذا طلب المستخدم تحليل مشروع وإعداد تقرير، يمكن للوكيل تقسيم المهمة إلى عدة إجراءات: البحث عن مستندات وقراءة الملفات ذات الصلة والتحقق من البيانات وتجميع الإجابة النهائية. لكل خطوة يُقترح تخزين معرّفه الخاص item_id والرقم الترتيبي واسم الأداة والمعاملات وطريقة التأكيد والحالة. يؤكد المقال بشكل خاص أن الأنماط safe_readonly وconfirm_once ومutating ضرورية ليس من أجل الزينة: فهي تسمح بتقسيم مسبق للعمليات الآمنة للقراءة والإجراءات ذات التأكيد الفردي والتحويرات المحتملة الخطرة.

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

بدلاً من حالة واحدة غامضة، يمكن للواجهة الأمامية قراءة turn_started وtool_started وtool_progress وtool_completed وapproval_requested وtool_failed وturn_completed، ثم عرض تقدم واضح. المثال من النص عملي وبالتالي مفيد: يقوم الوكيل بتشغيل collect_documents ويجد 12 مستند، ثم في خطوة analyze_documents يبلغ عن التقدم 40 من 100، وفي حالة الفشل يكتب انقطاع الخدمة الخارجية ويوسّم الخطأ على أنه قابل لإعادة المحاولة. بالنسبة للمستخدم هذا يعني واجهة مستخدم عادية بدلاً من «الوكيل يفكر» لا نهاية له، وللفريق الهندسي — القدرة على تصحيح خط الأنابيب وإجراء التدقيقات وتحليل الحوادث واستعادة المهام بعد إعادة التشغيل دون إعادة بناء يدوية للسجل.

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