ذكاء التجارة الاصطناعي الخاص بك لا يتذكر ما فعله قبل 5 ثوانٍ. بنية جديدة يمكنها إصلاح ذلك.

خلاصة: وكيلك مصاب بفقدان الذاكرة

• معظم وكلاء الذكاء الاصطناعي اليوم عديمو الحالة (stateless). ليس لديهم ذاكرة موثوقة للإجراءات السابقة، مما يجعلهم غير مناسبين لعمليات التجارة الحرجة مثل إدارة المخزون أو رحلات العملاء متعددة الخطوات. هذا ليس خطأ برمجيًا؛ إنه عيب جوهري في تصميمهم يؤدي إلى إخفاقات لا يمكن التنبؤ بها ولا يمكن تدقيقها.
• تقترح ورقة بحثية جديدة من arXiv هذا الأسبوع، "ESAA: حدث المصدر للوكلاء المستقلين في نماذج اللغة الكبيرة" (arXiv:2602.23193v1)، حلاً من خلال تكييف نمط مؤسسي تم اختباره – حدث المصدر (event sourcing) – للأنظمة القائمة على الوكلاء (agentic systems) [5]. وتفصل بين نوايا الوكيل (ما يريد فعله) وآثاره (ما يحدث بالفعل).
• يسمح هذا التحول المعماري بإنشاء سير عمل قائم على الوكلاء (agentic workflows) قابل للتدقيق، وإعادة التشغيل، ومرن. ويُمكِّن العلامات التجارية من استخدام نماذج لغة كبيرة غير متجانسة (مثل GPT-5 و Claude Sonnet 4.6)، وتجنب الاعتماد على بائع واحد، وبناء وكلاء طويل الأمد يمكن الوثوق بهم أخيرًا في المهام الحيوية دون تضليل حالتهم الخاصة [6].

إليك سيناريو أصبح واردًا أكثر من أي وقت مضى. كان المدير التقني (CTO) لعلامة تجارية سريعة النمو موجهة للمستهلكين - لنطلق عليها "Melrose Active" - في حالة ذعر كامل. لقد حاول وكيل المخزون المستقل الجديد الخاص بهم، وهو نظام تم بيعه لهم على أنه قمة "التجارة القائمة على الوكلاء" (agentic commerce)، للتو طلب 50,000 وحدة من منتج بطيء الحركة. ما السبب؟ خلل في الشبكة أثناء فحص روتيني للمخزون. الوكيل، بعد أن فقد سياقه في منتصف العملية، أعاد تشغيل منطقه الأولي، وأساء تفسير البيانات الجزئية من المحاولة الفاشلة الأولى، وخلص إلى أن المستودع كان فارغًا. كان خطأ يكلف مليون دولار، تم اكتشافه فقط من خلال تنبيه بشري في الحلقة، والذي، بصراحة، هزم الغرض الكامل من النظام المستقل.

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

بينما يفتن بقية العالم بعروض وكلاء الذكاء الاصطناعي الذين يحجزون الرحلات الجوية أو "يبحثون عن الأجواء" في خطط السفر [1]، نحن في خنادق بناء أنظمة تجارية فعلية نخوض معركة أكثر جوهرية بكثير: معركة من أجل الحالة (state). وقد تكون ورقة بحثية صدرت بهدوء على arXiv هذا الأسبوع واحدة من أهم التطورات حتى الآن في هذه المعركة.

إذن، ثلاثة وكلاء ذكاء اصطناعي يدخلون حانة... ويحرقونها؟

لم تكن مشكلة وكيل Melrose Active مجرد نقطة فشل واحدة. لقد كانت عرضًا لمشكلة أعمق وأكثر منهجية في الأنظمة متعددة الوكلاء (multi-agent systems). عندما تنشر وكلاء مستقلين متعددين يتشاركون الموارد - مثل قواعد بيانات المخزون، أو محركات التسعير، أو بوابات API - فإنهم لا يفشلون بشكل فردي فحسب. بل غالبًا ما يفشلون بطرق متزامنة ومترابطة تضخم الضرر.

توضح ورقة بحثية رائعة على arXiv نُشرت هذا الأسبوع، "Three AI-agents walk into a bar … ‘Lord of the Flies’ tribalism" (ثلاثة وكلاء ذكاء اصطناعي يدخلون حانة... "قبلية سيد الذباب")، هذا السيناريو الكابوسي تمامًا [2]. وضع الباحثون وكلاء نماذج لغة كبيرة مستقلة (LLM agents) في سيناريو تنافس على الموارد كلاسيكي (مشكلة El Farol Bar) وشاهدوا ما حدث. فبدلاً من التصرف كجهات فاعلة مستقلة وعقلانية، سرعان ما شكل الوكلاء "قبائل" بناءً على أنماط تفكيرهم الأساسية. أصبح البعض "عدوانيًا" (27.3% من السكان)، يحاول دائمًا الوصول إلى المورد. وكان آخرون "محافظين" (24.7%)، وأصبحت أغلبية كبيرة "انتهازية" (48.1%).

النتيجة المرعبة؟ أدت هذه القبلية الناشئة إلى سلوك متزامن، مما تسبب في زيادات حمل وإخفاقات منهجية أسوأ بكثير مما قد ينتج عن توزيع عشوائي بسيط. عندما يقرر وكيل واحد إغراق واجهة برمجة تطبيقات المخزون (inventory API) الخاصة بك، فمن المحتمل أن العشرات من الوكلاء الآخرين، المبنيين على نفس النموذج والمنطق الأساسي، على وشك فعل الشيء نفسه. هذا هو خطر نشر أنظمة تبدو مستقلة ولكنها تفتقر إلى الاستقلال الحقيقي في أوضاع فشلها. بدون عمود فقري معماري قوي، فإن قوة عملك المعتمدة على الوكلاء (agentic workforce) ليست فريقًا من الأفراد؛ إنها حشد، عرضة للانهيارات السريعة والغباء الجماعي.

لهذا السبب فإن الهوس بـ قدرات الوكيل - ما يمكنهم فعله - في غير محله. التحدي الحقيقي هو بناء بنية ذكاء اصطناعي تجارية (commerce AI architecture) يمكنها التعامل برشاقة ليس فقط مع فشل وكيل واحد، ولكن مع فشل العشرات منهم في وقت واحد. نحن بحاجة إلى أنظمة حتمية، وقابلة للتدقيق، ومرنة للفوضى المتأصلة في المنطق المدفوع بنماذج اللغة الكبيرة. نحن بحاجة إلى التخطيط للفشل، وليس مجرد الإعجاب بالنجاح.

آلة فقدان الذاكرة: لماذا يفشل وكيل الذكاء الاصطناعي الحالي الخاص بك في التجارة

السبب الجذري لهذه الهشاشة هو ما يسميه المهندسون "إدارة الحالة" (state management). أو، في هذه الحالة، عدم وجودها على الإطلاق. معظم الأطر القائمة على الوكلاء (agentic frameworks) اليوم، مثل حلقات ReAct (Reason+Act) الشائعة، تتعامل مع كل تفاعل كحدث مستقل إلى حد كبير. غالبًا ما تكون "ذاكرة" الوكيل مجرد سجل المحادثة المحشوة في نافذة سياق استدعاء نموذج اللغة الكبيرة (LLM call). هذه ليست ذاكرة؛ إنها مذكرة لاصقة، وصغيرة جدًا على ذلك.

أكدت ورقة بحثية من أوائل هذا الأسبوع حول تقييم الذاكرة طويلة الأفق لتطبيقات الوكلاء (agentic applications) ما رآه الكثير منا عمليًا: هذا النهج يتدهور بشكل كارثي بمرور الوقت [7]. فمع ازدياد تعقيد المهمة وازدياد عدد الأدوار، تمتلئ نافذة السياق، وتُفقد المعلومات الهامة، ويبدأ الوكيل في الانحراف. ينسى تعليماته الأولية، وأفعاله السابقة، وحالة العالم الذي من المفترض أن يتلاعب به.

هذا له عواقب عميقة وملموسة لأي حالة استخدام تجارية جادة:

1. عدم قابلية التدقيق (Lack of Auditability): إذا كانت تصرفات الوكيل مجرد استدعاءات عابرة لواجهة برمجة تطبيقات (API calls) مدفوعة بنموذج لغة كبيرة احتمالي، فما هو مصدر الحقيقة؟ عندما تسأل إدارتك المالية لماذا خفض وكيل التسعير الديناميكي (dynamic pricing agent) الخاص بك سعر منتج رئيسي بنسبة 90% في منتصف الليل، فإن إجابتك الوحيدة هي "قرر نموذج اللغة الكبير ذلك". لا يوجد سجل غير قابل للتغيير للقرارات، أو البيانات التي أثرت فيها، أو تسلسل الأحداث. هذا غير مقبول لأي عملية منظمة أو حرجة.

2. عدم وجود التماثل (No Idempotency): في الأنظمة الموزعة (distributed systems)، التماثل هو الملك. إنه الضمان أن إجراء نفس الطلب عدة مرات ينتج نفس النتيجة كما لو تم إجراؤه مرة واحدة. عندما أعاد وكيل Melrose Active محاولة فحص المخزون بعد خطأ في الشبكة، كان يجب أن يكون عملية غير ضارة، متماثلة. بدلاً من ذلك، ولأن حالته فقدت، أصبحت المحاولة الجديدة إجراءً جديدًا ومستقلاً بنتيجة كارثية. لا تفرض معظم أطر عمل الوكلاء التماثل أو حتى تأخذه في الاعتبار، مما يجعلها هشة في مواجهة فشل الشبكة الحتمي في العالم الحقيقي.

3. عدم القدرة على إعادة التشغيل وتصحيح الأخطاء (Inability to Replay and Debug): عندما يفشل النظام، كيف تقوم بتصحيح الأخطاء؟ مع وكيل عديم الحالة، لا يمكنك ذلك. لا يمكنك إعادة تشغيل التسلسل الدقيق للأحداث والحالات التي أدت إلى الخطأ. ينتهي بك الأمر إلى التحديق في سجلات مبهمة من موفر نموذج اللغة الكبيرة، محاولًا عكس هندسة صندوق أسود احتمالي. إنه مثل محاولة تصحيح أخطاء نموذج مالي معقد من خلال مشاهدة نقاش إخباري تلفزيوني.

هذه ليست حالات هامشية. هذا هو السلوك الافتراضي لغالبية أنظمة التجارة القائمة على الوكلاء (agentic commerce systems) التي يتم تسويقها اليوم. إنها غير موثوقة بشكل أساسي، وغير قابلة للتدقيق، وغير مناسبة لبيئات الإنتاج حيث تكون الأموال الحقيقية والمخزون الحقيقي على المحك. إنها مسؤولية معمارية تنتظر أن تحدث.

هل حدث المصدر (Event Sourcing) هو الحل غير الجذاب والمُتأخر للتجارة القائمة على الوكلاء (Agentic Commerce)؟

هذا يقودني إلى الورقة البحثية التي صدرت هذا الأسبوع والتي تحمل عنوانًا غير جذاب تمامًا: "ESAA: Event Sourcing for Autonomous Agents in LLM" (arXiv:2602.23193v1) [5]. إنها تقترح حلاً ليس مجرد توجيه ذكي أو نموذج أكبر. إنه نمط معماري مستعار من عالم أنظمة المؤسسات عالية المخاطر وواسعة النطاق: حدث المصدر (event sourcing).

حدث المصدر ليس جديدًا. إنه نمط أساسي في معماريات مثل CQRS (Command Query Responsibility Segregation) التي تم استخدامها لسنوات في التكنولوجيا المالية، والخدمات المصرفية، واللوجستيات - في أي مكان تكون فيه قابلية التدقيق والموثوقية غير قابلة للتفاوض. الفكرة الأساسية بسيطة: بدلاً من تخزين الحالة الحالية للنظام، تقوم بتخزين سجل إلحاقي (append-only log) لجميع الأحداث التي حدثت على الإطلاق. ثم يتم اشتقاق الحالة الحالية عن طريق إعادة تشغيل هذه الأحداث.

تقترح ورقة ESAA تطبيق هذا النمط بالضبط على وكلاء الذكاء الاصطناعي. فبدلاً من السماح لنموذج اللغة الكبيرة (LLM) باستدعاء الأدوات وتغيير حالة العالم مباشرة، فإن الوظيفة الوحيدة للوكيل هي إصدار كائن JSON يصف نيته. هذا كل شيء. يتم التعامل مع هذه النية كحدث. ثم يتولى نظام حتمي منفصل - المنسق (orchestrator) - مسؤولية التحقق من صحة هذا الحدث، وتثبيته في سجل غير قابل للتغيير، ومن ثم فقط تطبيق آثاره (مثل استدعاء واجهة برمجة تطبيقات Shopify أو تحديث قاعدة بيانات).

هذا الفصل هو المفتاح. الجزء الاحتمالي، غير المتوقع، الإبداعي من النظام (نموذج اللغة الكبيرة LLM) يتم عزله عن الجزء الحتمي، الموثوق، الذي يغير الحالة من النظام (المنسق).

كيف يعمل ESAA: نوايا، لا أفعال

يوفر تدفق البيانات في نظام قائم على ESAA الحواجز التي يحتاجها وكلاء اليوم بشدة. إنه يفرض مستوى من الانضباط يمنع أنواع الإخفاقات التي رأيناها مع Melrose Active.

تبدو العملية كالتالي:

هذا ليس مجرد مخطط نظري. توضح ورقة ESAA أن هذه البنية تعمل مع نماذج غير متجانسة مثل GPT-5 من OpenAI و Claude Sonnet 4.6 من Anthropic [6]. الجمال هو أن سجل الأحداث والمنسق مستقلان عن النموذج. يتم تقليل دور نموذج اللغة الكبيرة (LLM) ليصبح "محرك اقتراحات"، لكن المنسق يظل المصدر الوحيد للحقيقة لجميع تغييرات الحالة.

سرد تفصيلي لوكيل مخزون مستقل

دعنا نُعيد تمثيل سيناريو Melrose Active باستخدام هذه البنية. تحتاج العلامة التجارية، التي مقرها هنا في لوس أنجلوس، إلى إدارة المخزون لمتجرها الرئيسي في أبوت كيني.

1. المحفز: تبدأ مهمة مُجدولة وكيل المخزون بالهدف: "ضمان أن جميع المنتجات الأساسية في موقع أبوت كيني أعلى من مستويات المخزون الآمنة."
2. النية رقم 1 (الاستعلام): يطلق وكيل نموذج اللغة الكبير (LLM agent) أولاً نية: {"intent": "get_inventory_levels", "location": "abbot_kinney"}. يقوم المنسق بتسجيل ذلك، ويستعلم نظام المخزون، ويعيد البيانات إلى الوكيل.
3. فشل الشبكة: لنفترض أن الاتصال انقطع مباشرة بعد أن أرسل المنسق البيانات. لم يتلق الوكيل شيئًا. في نموذج عديم الحالة (stateless model)، لا يمكن التكهن بالإجراء التالي. في نموذج ESAA، لم يتغير شيء. لم يتم تغيير أي حالة. الشيء الوحيد الموجود هو نية مسجلة للاستعلام.
4. إعادة المحاولة: عندما يعيد الوكيل المحاولة، فإنه يطلق نفس النية تمامًا مرة أخرى: {"intent": "get_inventory_levels", "location": "abbot_kinney"}. يمكن للمنسق، عند رؤية هذا الطلب المتماثل، ببساطة إعادة تقديم النتيجة من الاستعلام الأول أو تنفيذه مرة أخرى. النتيجة هي نفسها.
5. النية رقم 2 (الطلب): عند رؤية أن أحد المنتجات منخفض المخزون، يطلق الوكيل الآن أمرًا: {"intent": "create_purchase_order", "sku": "MA-LG-BLK", "quantity": 500, "reason": "Stock at 42, below threshold of 50"}. لاحظ حقل reason - يمكننا الآن إجبار نموذج اللغة الكبير على تبرير نواياه، ويتم تخزين هذا التبرير إلى الأبد في سجل الأحداث.
6. التدقيق: بعد ستة أشهر، يمكن لمراجع الحسابات إعادة بناء الحالة الدقيقة لنظام المخزون لذلك اليوم عن طريق إعادة تشغيل سجل الأحداث غير القابل للتغيير. يمكنهم رؤية ليس فقط ماذا حدث، ولكن لماذا قرر الوكيل التصرف. هذا هو أساس بنية مهندس التجارة القائمة على الوكلاء (agentic commerce architect) الجديرة بالثقة.

هل هذا مجرد مبالغة معمارية؟ وجهة نظر المتشككين

بالطبع، لا توجد بنية سحرية. أول ما سيشير إليه المتشكك - أو المهندس الذي لديه موعد نهائي ضيق - هو التكاليف العامة. يُدخل حدث المصدر (event sourcing) تعقيدًا وتأخرًا. الكتابة إلى السجل، والتحقق من المخططات، ثم عرض الحالة أبطأ بطبيعتها من مجرد تعديل سجل قاعدة البيانات مباشرة.

يوجد أساس لهذا الجدل. ورقة بحثية مختلفة قُدمت إلى arXiv في نفس الأسبوع، "Tool-R0" (arXiv:2602.21320v1)، تعرض فلسفة مختلفة تمامًا. تستخدم التعلم المعزز من بيانات صفرية لتعليم الوكيل كيفية استخدام الأدوات بكفاءة لا تصدق، وتفخر بتحسين بنسبة 92.5% على المعايير [9]. ينصب تركيزها على الأداء والقدرة البحتة، وليس على موثوقية وقت التشغيل من خلال التسجيل. للمهام قصيرة الأمد وحيث يكون الفشل غير مكلف، فإن نهج Tool-R0 يتفوق على الأرجح.

علاوة على ذلك، فإن القلق بشأن تضخم "الدفاع في العمق" حقيقي. هل تحتاج هذه الآلية الثقيلة لروبوت دردشة خدمة عملاء بسيط يبحث عن حالات الطلبات؟ ربما لا. قد تكون حلقة ReAct أبسط أو بوابة النموذج المقترحة بواسطة بروتوكول OpenPort (OPP) [1] كافية. المفتاح هو فهم المقايضات.

إليك تفصيل للنهج المتنافسة التي ظهرت في الأسبوع الأخير من فبراير 2026:

نمط ESAA ليس لكل مشكلة. ولكن بالنسبة للعمليات عالية المخاطر وطويلة الأمد ومتعددة الخطوات التي تحدد التجارة الخلفية، فإن مقايضاته - التضحية ببضعة أجزاء من الثانية من التأخير لسنوات من قابلية التدقيق والموثوقية - ليست مجرد مجدية؛ إنها إلزامية.

ما يعنيه هذا لاستعداد واجهة متجرك الرقمية المدعومة بالوكلاء (Agentic Storefront Readiness) لعلامتك التجارية

بالنسبة لأي مدير تقني (CTO) أو رئيس هندسة في علامة تجارية موجهة للمستهلكين (DTC)، يجب أن يكون هذا بمثابة نداء للتنبيه. إن جاهزية واجهتك الرقمية المدعومة بالوكلاء (agentic storefront readiness) لا علاقة لها بمدى روعة روبوت الدردشة الخاص بك. إنها تتعلق بمتانة الواجهة الخلفية (backend) الخاصة بك. إنها تتعلق بما إذا كانت بنيتك التحتية جاهزة للوكلاء ذوي الحالة (stateful)، والقابلين للتدقيق، والموثوق بهم.

إليك ما تبدو عليه الجاهزية بالفعل:

1. واجهات برمجة تطبيقات (APIs) منظمة ومتساوية: يجب أن تكون واجهات برمجة التطبيقات الداخلية والخارجية الخاصة بك قوية للغاية. هل يمكن لنقطة نهاية create_order الخاصة بك التعامل مع الاستدعاء خمس مرات بنفس الحمولة دون إنشاء خمسة طلبات؟ إذا لم يكن كذلك، فأنت لست جاهزًا. سيفشل الوكلاء وسيحاولون مرة أخرى. يجب أن تكون أنظمتك مصممة لهذا الغرض.

2. طبقة بيانات غنية: الوكيل جيد بقدر البيانات التي يمكنه الوصول إليها. الاستثمار في البيانات المهيكلة للبحث بواسطة الذكاء الاصطناعي (structured data for AI search) - كتالوجات منتجات نظيفة، وقطاعات عملاء محددة جيدًا، وبيانات مخزون سهلة الوصول - هو أساس أي نظام ذكي. هذا هو جوهر ما تعمل عليه فرق مثل مختبر Princeton GEO (Generative Engine Optimization): تحسين البيئة للتوليد، وليس فقط النموذج.

3. استراتيجية إدارة الحالة (State Management Strategy): هذه هي النقطة الكبيرة. تحتاج إلى اتخاذ قرار واعٍ بشأن كيفية إدارة وكلاءك للحالة. هل ستقبل مخاطر حلقة ReAct عديمة الحالة (stateless ReAct loop) للتفاعلات منخفضة المخاطر؟ أم ستستثمر في نمط مثل حدث المصدر (event sourcing) لسير العمل الحرج؟ عدم وجود استراتيجية هو استراتيجية للفشل.

4. معمل تجارب الذكاء الاصطناعي (AI Experience Lab): لا يمكنك بناء هذا على الفور. تحتاج العلامات التجارية إلى إنشاء معامل تجارب الذكاء الاصطناعي الداخلية - بيئات معزولة حيث يمكنك اختبار هذه البُنى القائمة على الوكلاء بأمان. هذا هو المكان الذي يمكنك فيه اختبار أنظمتك بنفسك (red-team)، ومحاكاة أعطال الشبكة، ومعرفة كيف تتصرف وكلاءك تحت الضغط قبل أن يتمكنوا من لمس مخزون الإنتاج للمتجر الرئيسي في سانتا مونيكا.

في CTO.LA، نعمل مع العلامات التجارية التجارية لبناء هذه البنية التحتية الأساسية. نحن لا نبيع سحر الوكلاء؛ نحن ننفذ البنية الأساسية المرنة، والمملة ولكنها ضرورية، التي تجعل ذلك ممكنًا. نحن نعمل كـ مهندس التجارة القائمة على الوكلاء (agentic commerce architect) الذي يضمن عدم انهيار النظام في المرة الأولى التي يمر فيها الوكيل بيوم سيء.

لا تبني مسؤولية أخرى قائمة على الوكلاء

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

وجدت دراسة للوكلاء المنتشرين في المختبر 11 فئة مختلفة من الفشل، من تسرب البيانات وإنكار الخدمة إلى مجرد الكذب بشأن إكمال مهمة [1]. المشكلة ليست أن الوكلاء يفشلون؛ المشكلة هي أن أنظمتنا ليست مصممة لاحتواء هذا الفشل.

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

لا تدع مبادرة الذكاء الاصطناعي الكبيرة التالية لشركتك تصبح انقطاعها الكبير التالي. ركز على البنية. ابنِ للموثوقية. افصل النية عن التنفيذ. ومن أجل الله، امنح وكيلك ذاكرة.

مستقبل الذكاء الاصطناعي التجاري في لوس أنجلوس وما بعدها لن يحدده أذكى التوجيهات، بل الأنظمة الأكثر مرونة. CTO.LA تعمل مع العلامات التجارية التجارية التي تبني هذه البنية التحتية القائمة على الوكلاء. دعنا نتحدث.

المراجع

1. AnybodyCanPrompt - Anthropic ترفض العرض النهائي للبنتاغون...
2. arXiv:2602.23093v1 - ثلاثة وكلاء ذكاء اصطناعي يدخلون حانة... "قبلية سيد الذباب"
3. arXiv:2602.23073 - تقييم السياسة ذات المخاطر المعجلة عبر الإنترنت في POMDPs
4. arXiv:2602.22915 - تصميم معلومات قوي للأنظمة متعددة الوكلاء
5. arXiv:2602.23193 - ESAA: حدث المصدر للوكلاء المستقلين في نماذج اللغة الكبيرة
6. PDF: ESAA: حدث المصدر للوكلاء المستقلين في نماذج اللغة الكبيرة
7. arXiv:2602.22769 - تقييم الذاكرة طويلة الأفق لتطبيقات الوكلاء
8. arXiv:2602.23330 - نحو فرق استثمار خبيرة من نماذج اللغة الكبيرة
9. arXiv:2602.21320 - Tool-R0: تمكين نماذج اللغة الكبيرة بالأدوات من خلال التعلم المعزز من بيانات صفرية
10. arXiv:2602.22302 - عقود الوكلاء: لغة للاتفاقيات القابلة للتنفيذ بين البشر ووكلاء الذكاء الاصطناعي

• agentic commerce
• commerce ai architecture
• event sourcing
• llm
• ai