---
title: "75 ألف وكيل ذكاء اصطناعي بذاكرة Raspberry Pi: شو هو Infinity من AWS؟"
description: "AWS فتحت مصدر Infinity برخصة Apache 2.0 ضمن مشروع Hydro مع جامعة بيركلي: رانتايم بيعلّق الوكيل وقت استدعاء الأداة متل async/await، فحوالي 75 ألف وكيل خامل بيتسعوا بذاكرة 8 غيغا."
url: https://ihsanalapsi.dev/articles/aws-infinity-agent-runtime
lang: ar
date: 2026-10-24
updated: 2026-10-24
tags: ["AI", "أدوات المطورين"]
author: Ihsan Alapsi (إحسان العبسي)
---
# 75 ألف وكيل ذكاء اصطناعي بذاكرة Raspberry Pi: شو هو Infinity من AWS؟

إذا عندك وكلاء ذكاء اصطناعي بيقضوا أغلب وقتن ناطرين أداة، فبأغلب الأطر كل وكيل منهن ماسك عملية وذاكرة طول الانتظار. يوم 23 تشرين الأول 2026 نشرت AWS [بوست رسمي](https://aws.amazon.com/blogs/opensource/introducing-infinity-a-runtime-for-extreme-agent-concurrency/) بيقول إنو 75 ألف وكيل بيتسعوا بالـ 8 غيغا تبع Raspberry Pi 5، والرقم محسوب من قياس عملوه على سيرفر. يلي بيعمل هالشي هو Infinity: رانتايم بيعلّق الوكيل متل دالة async وقت استدعاء الأداة، وبيصحّيه لما توصل النتيجة.

بآخر المقال بتعرف كيف بيشتغل، وإذا بيناسب وكلاءك، وكيف تجربه هلق.

## شو هو Infinity بالضبط؟

Infinity هو رانتايم بحثي لتشغيل وكلاء الذكاء الاصطناعي، جزء من مشروع Hydro يلي بتشتغل عليه AWS مع جامعة بيركلي، ومتاح على GitHub برخصة Apache 2.0. فكرته مأخوذة من الطريقة يلي بتعلّق فيها لغات البرمجة الدوال غير المتزامنة وبتكمّلها بعدين.

المشكلة يلي بيحلها إنو الوكلاء بيقضوا أغلب وقتن ناطرين الأدوات. وكيل برمجة ممكن يبلّش build بياخد عشرين دقيقة، ووكيل triage ممكن يستنى ساعات ليجي pull request جديد، ومساعد ممكن يستنى لتاني يوم لتوصل موافقة. أغلب الأطر بتشغّل حلقة الوكيل كخطوات ورا بعض، وكل خطوة بتوقف لحد ما ترجع الأداة، فالوكيل الناطر ماسك عملية وذاكرتها وما بيقدر يرد على أحداث جديدة.

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

Meta كمان نزّلت هالشهر أوزان Muse Spark Open [برخصة إلها شروط](/articles/meta-muse-spark-open-licence)، بس هداك موديل. Infinity بنية تحتية بتشغّل أساطيل الوكلاء نفسها.

## طيب ليش استدعاء الأداة بيشبه await؟

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

أغلب المطورين بيعرفوا async وawait من Rust أو JavaScript أو Python. لما دالة تستنى عملية غير متزامنة متل طلب شبكة، بتتعلّق، والـ thread بيروح يشتغل شغلات تانية. ولما العملية تخلص، الرانتايم بيكمّل تشغيل الدالة من النقطة يلي وقفت فيها. ولحتى يقدر، لازم يحفظ الـ continuation تبعها، يعني الحالة يلي بتلزمها لتكمّل.

لغات البرمجة بتحفظ هالحالة بطريقتين. الـ OS threads والـ stackful coroutines بيضلوا ماسكين الـ call stack كله بالذاكرة وهني ناطرين. أما الـ stackless coroutines، يلي Rust بيستعملها لـ `async fn`، فالكمبايلر بيحوّل فيها الدالة لـ state machine بتحتفظ بس بالقيم يلي بتلزم عند كل await. هيك الذاكرة أصغر، والـ executor بيقدر يشغّل عدد كبير منهن.

نقطة AWS إنو وكيل الـ LLM بينعلّق بنفس الطريقة: بلحظة استدعاء الأداة، سجل المحادثة فيه كل شي لازم ليكمّل لما توصل النتيجة. فإذا الرانتايم حفظ هالسجل، بيقدر يرمي كل شي بالذاكرة، وأي عملية عندها وصول للمخزن بتقدر تصحّي الوكيل بعدين.

لهيك Infinity بيشغّل كل وكيل كسلسلة شرائح (slices) محدودة. بكل شريحة، الرانتايم بيحمّل السجل من مخزن بتقدر تبدّله، وبيشغّل completion وحدة، وبيحفظ المخرجات، وبيبعت استدعاء أداة واحد بالكتير. بعدين الشريحة بتخلص. استدعاءات الأدوات هي نقاط الـ await: الشريحة ما بتستنى أداة ولا مؤقت ولا أي عملية من برّا.

كل شي بيقدر يصحّي الوكيل، من نص المستخدم لنتائج الأدوات، بيوصل كرسالة على طابور إدخال مشترك. ولأنو الطابور بيمسك الأحداث لحد ما ينعالجوا، الرانتايم ما بيحتاج يخلّي الوكيل عايش وهو ناطر: لما يسحب رسالة، بيفتح شريحة بتحمّل حالة الوكيل وبتعالج الرسالة.

## من وين طلع رقم الـ 75 ألف؟

رقم الـ 75 ألف محسوب من قياس عملته AWS: كل وكيل خامل أخد حوالي 100 كيلوبايت ذاكرة، و8 غيغا، وهي ذاكرة الـ Raspberry Pi 5، بتساع حوالي 75 ألف وكيل بهالمعدل. القياس نفسه انعمل على معالج سيرفر، مش على Raspberry Pi.

الوكيل المعلّق ما بيحمل غير سجله، فالذاكرة يلي بيلزمها قريبة من حجم السجل. لحتى يقيسوا هالشي، كتبوا benchmark بيطلق موجات وكلاء بنظام واحد مع موديل محاكى. كل وكيل بيشتغل عشرين دورة، وكل دورة بتمرق مرة كاملة عبر الرانتايم: completion حجمها حوالي 1.2 كيلوبايت بتستدعي أداة، والنتيجة بترجع عبر الطابور، وcompletion تانية بتسكّر الدورة.

شغّلوا الاختبار على 80 ألف وكيل، يعني 3.2 مليون completion بالمجموع، على thread واحد من معالج AMD EPYC 9R14 مع مخازن in-memory. الذاكرة كبرت خطياً، حوالي 100 كيلوبايت لكل وكيل خامل، وأغلبها رايح لسجلات المحادثات، لأنو الوكيل الخامل ما إلو task ولا stack ولا connection.

## شو يعني صفر تكلفة حوسبة والوكيل ناطر؟

صفر تكلفة حوسبة يعني إنو الوكيل الناطر على منصة serverless ما إلو ولا استدعاء شغال. الشريحة ما بتستنى عمليات من برّا وبتحمّل حالتها من التخزين، فالدالة بتنستدعى لكل وحدة شغل وبتطلع أول ما تخلص.

Infinity بيدعم هاد بـ step mode: المنصة بتنادي `step` مرة لكل دفعة رسائل، وما بينحفظ شي بالذاكرة بين النداءات.

النشر المرجعي يلي عملته AWS بيستعمل طابور SQS FIFO كطابور إدخال، مع `MessageGroupId` واحد لكل thread. كل توصيلة بتستدعي دالة Lambda بتشغّل خطوة وحدة وبتطلع. السجلات بـ Aurora DSQL، وحالة منع التكرار بـ DynamoDB، وأدوات الـ `sleep` بتستعمل تأخير التوصيل بـ SQS وEventBridge Scheduler للمؤقتات. والمستودع فيه CDK constructs بتجهّز هالموارد.

والتشغيل على هيك منصة بيفرض على الرانتايم خمس شروط:

- وقت تنفيذ محدود: الشريحة completion وحدة وكم نداء تخزين وإرسال، وما بتستنى أي عملية مدتها مفتوحة.
- بلا ارتباط بعملية معيّنة: كل الحالة مخزّنة حسب الـ thread ID، فأي استدعاء بيقدر يعالج الرسالة الجاية لأي thread.
- توصيل مرة وحدة على الأقل (at-least-once): الطابور ممكن يعيد رسالة، فكل رسالة إلها ID ثابت، والرانتايم بيتجاهل الرسالة يلي عالجها قبل، فمعالجة الشريحة بتصير idempotent.
- دورات محفوظة: مخرجات الموديل المتدفقة ما بتنحفظ إلا لما تخلص الدورة، ولما استدعاء أداة بيسكّر الدورة، الرانتايم بيحفظ الدورة قبل ما يبعت الاستدعاء، فما بتوصل نتيجة لاستدعاء مش متسجّل.
- ترتيب بلا أقفال: مجموعات رسائل FIFO بترتّب شرائح كل thread وحدة ورا التانية، فما في حاجة لأقفال موزّعة.

الرانتايمات التقليدية يلي بتوقف عند استدعاء الأداة فيها كمان تنحط على serverless، بس كل استدعاء لازم يضل مفتوح وأدواته شغالة. بـ Infinity الوكيل الناطر ما إلو ولا استدعاء شغال، فوكيل ناطر CI pipeline بياخد تلات أيام ما بيصرف حوسبة لحد ما الـ pipeline يرجّع نتيجته.

## كيف بتوصل الأحداث للوكيل وهو ناطر؟

الأحداث بتوصل للوكيل الناطر كاستدعاءات أدوات اصطناعية (synthetic tool calls): الرانتايم بيضيف للسجل استدعاء أداة ما عمله الموديل، ونتيجته هي الحدث. هيك الحدث بيدخل بترتيب المحادثة بشكل الموديل بيعرف يقراه.

الوكيل الناطر على أداة بيحتاج يعرف عن أحداث بتصير وهو ناطر: أمر طويل بيطلّع مخرجات مع الوقت، أو اشتراك بمستودع بيطلّع حدث مع كل pull request جديد. بالحالتين استدعاء واحد بيطلّع سلسلة نتائج، والرانتايم لازم يقدّم كل وحدة للموديل بشكل بيفهمه.

الـ APIs تبع الموديلات ما فيها طريقة لتمثيل حدث غير متزامن: كل استدعاء أداة لازم ترد عليه نتيجة وحدة بالضبط. نتيجة تانية بتكسر القاعدة، والموديلات عادةً بترفض المحادثة. وإذا حطيت الحدث كرسالة مستخدم، الـ API بيقبله بس بينسبه للمستخدم غلط. وإذا حطيته بالـ system prompt، بيطلع من ترتيب السجل يلي الموديل بيعتمد عليه ليعرف شو صار قبل شو.

لهيك لما يوصل حدث، الرانتايم بيضيف استدعاء أداة من طرف المساعد، الموديل ما عمله، وبعده نتيجة أداة فيها الحدث:

```
▶ Synthetic:  receive_event__injected({
                original_tool_name: "subscribe_github_events",
                original_tool_call_id: "call_abc123",
                original_args: { owner: "acme", repo: "api" }
              })
■ Result:     {"event_type": "pull_request", "action": "opened", "number": 42}
```

لأنو الحدث بيوصل كاستدعاء أداة، الموديل بيستعمل نفس يلي تعلّمه بالتدريب ليفهم نتائج الأدوات ويقرر شو يعمل فيها. الوسائط بتحدد استدعاء الأداة السابق يلي طلّع الحدث، فالموديل بيعرف لأي طلب من طلباته بيرجع. الاسم المخصص `receive_event__injected` بيخلّي الموديل يفرّق بين حدث واستدعاء جديد لنفس الأداة، واللاحقة `__injected` بتقول إنو الرانتايم هو يلي عمله. الرانتايم ما بيعرض هالاسم للموديل كأداة، وبيرفض الاستدعاء إذا الموديل حاول يناديه.

الأداة بتطلّع الأحداث بنفس طريقة أول نتيجة: بتبعت رسائل لطابور إدخال الوكيل. أول نتيجة بتعلّمها كبداية اشتراك، فالرانتايم بيعرف إنو ممكن يجي بعدها نتائج أكتر لنفس الاستدعاء. الوكيل بيضل خامل بين الأحداث، وكل حدث بيصحّيه لما يوصل، بعملية محلية أو باستدعاء Lambda جديد، فالاشتراك ما بيخلّي شي شغال وهو ناطر.

ووين ينعالج الحدث، هاد قرار تاني. إذا اشتراك بعت مية حدث لوكيل واحد، بياكلوا جزء كبير من نافذة السياق تبعه، لهيك الأداة بتختار لكل حدث وحدة من طريقتين. الافتراضية: كل حدث بيتعالج بـ child thread مؤقتة بتورث سياق الأب. الـ thread الفرعية بتتصرف وبتبلّغ الأب، أو بتسكّر بلا بلاغ إذا الحدث مش مهم، وبهالحالة سجل الأب ما بيتغيّر، والأحداث يلي بتوصل ورا بعض بتتعالج بالتوازي. والتانية: الحدث المعلّم associative بينضاف مباشرة لسجل الـ thread يلي اشتركت، وهي للأحداث يلي بتحدّث عملية الوكيل عم يتابعها، متل مخرجات test run شغّله بالخلفية.

## والوكلاء كيف بيحكوا مع بعض؟

الوكلاء بيحكوا مع بعض بنفس استدعاءات الأدوات والأحداث: كل وكيل عنده أداة `spawn_thread` مدمجة، بتعمل thread فرعية إلها طابور إدخال خاص فيها.

عند الأب، `spawn_thread` بتتصرف متل اشتراك: الاستدعاء بيرجع أول ما تنعمل الـ thread الفرعية، والأب بيكمّل شغله، وتقارير الفرعية بتوصله بعدين كأحداث على نفس الاستدعاء.

لما الـ thread الفرعية تنادي `report_to_parent`، الأب بيشوف التقرير كاستدعاء أداة اصطناعي مربوط باستدعاء الـ `spawn_thread` الأصلي، فبيعرف مين من ولاده بعته حتى لو كتير منهن شغالين بنفس الوقت. الفرعية بتقدر تبعت كذا تقرير وهي شغالة، والأخير بيوصل لما تنادي `close_thread`.

فالرانتايم ما بيحتاج نظام مراسلة منفصل للوكلاء. الـ thread الفرعية بتنعمل باستدعاء أداة عادي، والتقرير للأب كمان، ونتائجهن وأحداثهن بتمرق بطوابير الإدخال، ونفس ضمانة الترتيب (رسائل كل thread بتتعالج بالدور، شريحة شريحة) بتنطبق عليها. والأب وولاده بيشتغلوا بالتوازي كـ threads منفصلة بنفس نظام الوكلاء.

مثال: وكيل بيراجع pull request بيقدر يعمل thread فرعية لكل ملف، كل وحدة بتفحص ملفها وبتبعت تقريرها، والأب بيجمع التقارير وبيكتب المراجعة. كذا وكيل على نفس التغيير هو نفس النمط يلي بتشتغل فيه أدوات متل Claude Code Review ([مراجعة الكود بالذكاء الاصطناعي على GitHub](/articles/ai-code-review-github-claude-ga))، وInfinity بيخلّي الوكلاء الناطرين بهيك نمط ما يصرفوا حوسبة.

## طيب بقدر جرّبه هلق؟ وهل هو جاهز للإنتاج؟

Infinity بتقدر تجربه هلق، بس لسا ما تعتمد عليه بالإنتاج: AWS بتسمّيه إصدار بحثي مبكر، وشاركته لتاخد ملاحظات بدري. وفي أسئلة لسا مفتوحة حسب AWS: كيف الموديلات بتفكر بأحداث متداخلة، وسياسات الجدولة، والـ compaction بشجرة وكلاء كبيرة، وكيف الرانتايم بيثبت مصدر الأحداث.

للتجربة، افتح [دليل البداية السريعة (quickstart)](https://infinity.hydro.run/docs/infinity-runtime/quickstart/launching-your-first-agent): حسب AWS بتبني فيه وكيل بسيط على Infinity بكم دقيقة. المكتبة مكتوبة بـ Rust. بلّش بالوضع المحلي (in-memory) قبل ما تفكر بالنشر على serverless، لأنو الأدوات ومزوّدي الموديلات والاختبارات يلي بتكتبها على المكتبة الأساسية بتشتغل بالوضعين بلا تغيير.

وإذا بتشغّل أساطيل وكلاء، متل CI triage أو PR bots أو وكلاء برمجة، هاي البنية بتستاهل تدرسها. ولو بيهمك كيف وكلاء البحث بالذكاء الاصطناعي بيقروا موقعك، شوف [شو علّمتنا تجربة Cloudflare وOpenAI عن بحث ChatGPT](/articles/chatgpt-search-cloudflare-discovery-pilot).

لو عندك 75 ألف وكيل بيناموا وبيصحوا عالطلب، وما بيصرفوا حوسبة وهني نايمين، شو أول شي بتبني فيهن؟

## FAQ

**كيف بيعلّق Infinity الوكيل وقت استدعاء الأداة؟**

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

**شو بيكلّف الوكيل وهو ناطر؟**

على منصة serverless، صفر حوسبة: دالة Lambda بتطلع أول ما تخلص الشريحة، فوكيل ناطر CI pipeline بياخد أيام ما بيصرف حوسبة. يلي بيضل هو سجل المحادثة المحفوظ بالتخزين. وبالوضع المحلي، الوكيل الخامل بياخد حوالي 100 كيلوبايت ذاكرة حسب قياس AWS.

**كيف بجرّب Infinity؟**

افتح الـ quickstart على infinity.hydro.run: حسب AWS بتبني فيه وكيل بسيط بكم دقيقة، والمكتبة مكتوبة بـ Rust. بلّش بالوضع المحلي in-memory قبل ما تفكر بالنشر على serverless، لأنو الأدوات والاختبارات نفسها بتشتغل بالوضعين بلا تغيير.

**هل Infinity جاهز للإنتاج؟**

لأ. AWS بتسمّيه إصدار بحثي مبكر، وشاركته لتاخد ملاحظات بدري. وفي أسئلة لسا مفتوحة: كيف الموديلات بتفكر بأحداث متداخلة، وسياسات الجدولة، والـ compaction بشجرة وكلاء كبيرة، وكيف الرانتايم بيثبت مصدر الأحداث.