AWS Infinity: كيف تعلّق الوكلاء أثناء انتظار الأدوات بدل أن تدفع ثمن خمولهم؟

معظم الوقت الذي يقضيه وكيل البرمجة في العمل ليس تفكيراً، بل انتظاراً. يطلق بناءً يستغرق عشرين دقيقة، أو ينتظر مراجعة بشرية حتى صباح الغد، أو يترقب Pull Request جديداً طوال ساعات. وفي أغلب الأنظمة الحالية يظل الوكيل طوال هذا الانتظار عملية حيّة تحجز ذاكرة ومعالجاً. في 23 أكتوبر 2026 أعلنت AWS فتح مصدر Infinity، وهو مشغّل (runtime) مكتوب بلغة Rust يعالج هذه المشكلة تحديداً: يعلّق الوكيل أثناء الانتظار ثم يوقظه عند وصول النتيجة.

ما هو Infinity؟

وفق مدونة AWS للمصادر المفتوحة، فإن Infinity مشروع بترخيص Apache 2.0 ضمن مشروع Hydro، وهو تعاون بين AWS وجامعة كاليفورنيا في بيركلي. تصفه AWS بأنه نموذج بحثي أولي وليس خدمة مُدارة، وتطلب ملاحظات المطوّرين. أي أنه مناسب للتجربة والتعلّم أكثر من الاعتماد عليه في الإنتاج اليوم.

كيف يعمل التعليق والاستئناف؟

الفكرة مستعارة من طريقة تعامل لغات البرمجة مع الدوال غير المتزامنة (async): حين تنتظر الدالة نتيجة، تُحفظ حالتها ويُحرَّر الخيط لشيء آخر. يطبّق Infinity المبدأ نفسه على الوكلاء:

1. يستدعي الوكيل أداة (تشغيل اختبارات مثلاً).
2. يرسل Infinity الاستدعاء ويحفظ المحادثة.
3. يُعلَّق الوكيل ولا يستهلك شيئاً تقريباً.
4. عند انتهاء الأداة تصل النتيجة إلى طابور إدخال فيُستأنف الوكيل من حالته المحفوظة.

وبحسب Stackademic وpbxscience فإن الإصدار يضيف بروتوكول Reactive Agent Protocol وتوافقاً مع MCP وتصميماً لا خادمياً (serverless) على Lambda وSQS FIFO، بحيث يمكن للدالة أن تنتهي بدل أن تنتظر خاملة.

الأرقام وما تعنيه فعلاً

هنا يجب الحذر. رقم 75,000 هو عدد الوكلاء المعلّقين الذين يمكن حفظهم في الذاكرة، وليس عدد استدلالات النموذج الكبير التي تعمل في اللحظة نفسها. والاختبار الذي استشهدت به AWS استخدم مخازن في الذاكرة ونموذجاً محاكى، لا نموذجاً لغوياً حقيقياً. فالرقم لا يقول شيئاً عن سرعة النموذج أو تكلفته.

الإنجاز الحقيقي ليس «ملايين الوكلاء يفكرون معاً»، بل «آلاف الوكلاء ينتظرون بلا كلفة تُذكر».

لماذا هذا مهم لمن يبني وكلاء؟

1. الانتظار هو القاعدة

وكيل مراجعة الكود ينتظر طلبات الدمج، ووكيل الدعم ينتظر رد العميل، ووكيل الموافقات ينتظر مديراً. إذا كان كل منها عملية حيّة، فإن الكلفة تتضاعف مع عدد المهام لا مع حجم العمل الفعلي.

2. الوكيل يتفاعل مع أحداث وصلت أثناء غيابه

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

3. ينسجم مع الدوال اللاخادمية

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

ما الذي ينبغي أن تسأله قبل التجربة؟

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

تجربة صغيرة تبدأ بها

أبسط طريقة لفهم الفكرة بناء وكيل صغير يستدعي أداة بطيئة (مثل سكربت ينام عشر ثوانٍ) ثم يتابع. قارن بين نسختين: واحدة تنتظر داخل العملية، وأخرى تعلّق الوكيل وتستأنفه من الطابور. راقب الذاكرة عند تشغيل مئات النسخ معاً، وسترى الفرق بين كلفة «الانتظار الحيّ» وكلفة «الانتظار المعلّق». يوجد مثال مبسط بلغة TypeScript في DEV Community، والكود في مستودع hydro-project/infinity على GitHub.

أسئلة شائعة

هل Infinity خدمة جاهزة للإنتاج؟

لا. تصفه AWS بأنه نموذج بحثي أولي مفتوح المصدر، وليس خدمة مُدارة.

هل يجعل الوكلاء أسرع أو أرخص في استدعاء النموذج؟

لا. هو يقلل كلفة الانتظار والذاكرة فقط. سرعة النموذج ورسومه لا تتأثر.

هل يعمل مع أدواتي الحالية؟

يعلن المشروع توافقاً مع MCP، فيمكن نظرياً ربط الأدوات المبنية عليه، لكن عليك اختبار حالتك بنفسك.

الخلاصة

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

المصادر: AWS Open Source Blog، pbxscience، Stackademic