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

لكي يعمل وكيل الذكاء الاصطناعي بصورة سليمة في بيئة الإنتاج، لا يكفيه الاحتفاظ بكل شيء في ذاكرة العملية: فبعد إعادة التشغيل يجب أن يتذكّر ما الذي طلبه المستخدم تحديدًا، وأي خطة بُنيت بالفعل، وأي الأدوات أنهت عملها، وأين توقّف التنفيذ. في الجزء الأول من تحليل عملي جديد على Habr AI، يقترح الكاتب بناء هذه الحالة الدائمة (durable state) حول ثلاثة كيانات أساسية: الدور والخطوة والحدث، ويوضّح لماذا تتحول سيناريوهات الوكلاء الطويلة بدونها بسرعة إلى خط معالجة (pipeline) غير شفاف وهش.

نقطة الانطلاق في النص بسيطة: إذا كان الوكيل يحتفظ بالحالة في الذاكرة فقط (in-memory)، فإن أي انهيار للخدمة يصفّر المهمة. هذا مقبول في العروض التجريبية، لكن وكيل الإنتاج قد يحلّل مستندات، وينتظر تأكيد المستخدم، وينفّذ سلسلة طويلة من الإجراءات، لذلك يحتاج بعد العطل إلى الاستعادة من قاعدة البيانات لا من بقايا الـ prompt. وبوصفها الحد الأدنى من الكيانات المحفوظة (persistent)، يذكر الكاتب AgentTurn وAgentPlanItem وAgentEvent، ويلفت إلى أن ApprovalGrant وSessionContext وBackgroundJob تظهر إلى جانبها بصورة شبه حتمية. والفكرة أن الحالة الدائمة لا تصف الجواب النهائي فقط، بل المسار كله: الطلب الأصلي، والأمر المُطبَّع (normalized)، وأعلام التأكيد، وحالات التنفيذ، والخطأ المحتمل.

يمثّل AgentTurn في هذا المخطط سجلًّا كاملًا لدور واحد من أدوار المستخدم. يحفظ معرّف الجلسة وturn_id ونص الرسالة والأمر المُطبَّع وحالة المعالجة، مثل created وplanned وawaiting_approval وrunning وcompleted وfailed. والمهم أن الدور يثبّت كلًّا من output_text النهائي وerror إذا تعثّر التنفيذ. وهذا يزيل الاعتماد الحرج على «ذاكرة» النموذج: إذ يستطيع الـ backend في أي لحظة أن يعرف ما جرى بالضبط مع الطلب، حتى لو أُعيد تشغيل العملية. وتزداد أهمية ذلك في المهام الطويلة، لأن الطلب الواحد نادرًا ما يقتصر على استدعاء واحد للنموذج، وغالبًا تقف خلفه سلسلة من قراءة الملفات واستدعاء الأدوات والتحقق وإعداد النتيجة.

الطبقة التالية هي AgentPlanItem، أي خطوة منفصلة داخل الدور. فإذا طلب المستخدم تحليل مشروع وإعداد تقرير، يمكن للوكيل أن يقسّم المهمة إلى عدة إجراءات: العثور على المستندات، وقراءة الملفات ذات الصلة، والتحقق من البيانات، وتجميع الجواب النهائي. ويُقترح أن تحتفظ كل خطوة بـ item_id خاص بها ورقمها التسلسلي واسم الأداة والوسائط (arguments) ونمط التأكيد والحالة. ويشدّد المقال على أن الأنماط safe_readonly وconfirm_once وmutating ليست للزينة: فهي تتيح فصل عمليات القراءة الآمنة مسبقًا عن الإجراءات التي تُؤكَّد مرة واحدة وعن عمليات التعديل (mutations) الخطرة المحتملة. وبذلك لا يعرف النظام أن «الوكيل يفعل شيئًا ما» فحسب، بل يعرف أي أداة يجب أن تبدأ بعد ذلك، وما الذي اكتمل، وما الذي يمكن إعادة محاولته، وفي أي موضع تعثّر التنفيذ.

الكيان الثالث الإلزامي هو AgentEvent، أي الخط الزمني لما يحدث. فالأحداث هي التي تحوّل الدور من صندوق أسود إلى نظام قابل للمراقبة. فبدلًا من حالة واحدة ضبابية، تستطيع الواجهة الأمامية قراءة turn_started وtool_started وtool_progress وtool_completed وapproval_requested وtool_failed وturn_completed، ثم عرض تقدّم واضح.

والمثال الوارد في النص واقعي، ولذلك فهو مفيد: يشغّل الوكيل collect_documents ويعثر على 12 مستندًا، ثم يبلّغ في خطوة analyze_documents عن تقدّم 40 من 100، وفي حال العطل يسجّل انتهاء المهلة (timeout) لخدمة خارجية ويضع على الخطأ علامة retryable. بالنسبة للمستخدم يعني هذا تجربة استخدام (UX) سليمة بدل عبارة «الوكيل يفكّر» التي لا تنتهي، وبالنسبة لفريق التطوير هو إمكانية تصحيح الأخطاء في خط المعالجة وإجراء التدقيق وتحليل الحوادث واستعادة المهام بعد إعادة التشغيل دون إعادة بناء التاريخ يدويًا.

الخلاصة الرئيسية من مادة Habr AI أن وكيل الإنتاج في 2026 ليس prompt ناجحًا مع طبقة ربط، بل نظام ذو حالة (stateful) يملك سجلًّا للتنفيذ. فإذا لم تكن للوكيل حالة دائمة على مستوى الدور والخطوة والحدث، فإنه يتحمّل الأعطال بصورة سيئة، ويبقى غير شفاف للواجهة، ويكاد لا يقبل الصيانة. ومن ثَمّ فإن المرحلة التالية من تطور تطبيقات الوكلاء لا تكمن في النماذج الجديدة بقدر ما تكمن في انضباط معمارية الـ backend: في كيفية تثبيت الحالة، وضبط التأكيدات، وتحويل عمل النموذج إلى عملية تشغيلية قابلة لإعادة الإنتاج.