وكلاؤك يخلّفون عمليات وراءهم.
وAgentsRoom يعثر عليها.
يُطلق وكيل البرمجة بالذكاء الاصطناعي عملية نظام حقيقية عند كل أداة يستدعيها. معظمها ينتهي خلال ثوانٍ. بعضها لا ينتهي أبدًا، وتلك تحتجز غيغابايتات من الذاكرة دون أن تستهلك من CPU شيئًا على الإطلاق.
يمسح حارس العمليات العمليات الفرعية لوكلائك، ويشير إلى التي لم تعد تتقدّم، ويسمّي الوكيل المسؤول، ويتيح لك إنهاءها بنقرة واحدة. لا شيء يُنهى من وراء ظهرك.
ما ينظر إليه الحارس فعلًا: العمليات التي ولّدها وكيل واحد، وأيّها توقّف عن العمل.
وكيل البرمجة بالذكاء الاصطناعي ليس عملية واحدة. كل استدعاء أداة يقوم به يبدأ عملية حقيقية على آلتك: بحث، أو بناء، أو فحص أنواع، أو تشغيل اختبارات، أو سكربت. اضرب ذلك في بضعة وكلاء يعملون بالتوازي، على مدى يوم كامل، فتحصل على مئات العمليات تولد وتُدفن دون أن ترى واحدة منها.
معظمها ينتهي. المشكلة في التي لا تنتهي. عملية بحث يجعل نمطها محرك التعابير النمطية ينفجر لا تنهار ولا تتباطأ: تحجز الذاكرة، ثم تُدفع إلى الذاكرة المضغوطة، ثم تقضي بقية عمرها في أخطاء الصفحات عند 4% CPU. لن تنتهي أبدًا، ولن يقتلها شيء أبدًا. وإذا أُغلق الوكيل الذي أطلقها، تُعاد نسبتها إلى عملية init فتصير يتيمة لم يعد أحد على الآلة مسؤولًا عنها.
لهذا يتسلّل التباطؤ ببطء. ليست لحظة واحدة درامية، بل تراكم بطيء على مدى يوم عمل، وهذا بالضبط الشكل الذي يجعل الناس يتّهمون الطرف الخطأ: ارتفاع الحرارة، أو كثرة الوكلاء، أو تسرّب ذاكرة في التطبيق. في الجلسة التي قِسناها، كان التطبيق نفسه يستهلك 2.8 GB موزّعة على 91 عملية، وواجهات CLI الثمانية للوكلاء 1.6 GB مجتمعة. لا هذا ولا ذاك كان المشكلة.
حارس العمليات هو شبكة الأمان. يراقب ما يخلّفه الوكلاء، ويخبرك أيّها عالق ومن أطلقه، ويتيح لك إنهاءه. الأسباب الجذرية ستظل تتغيّر: أداة أخرى، نمط آخر، مزوِّد آخر. أما الشبكة فليست مضطرة للتغيّر.
لماذا تتباطأ آلة تشغّل وكلاء ذكاء اصطناعي
الأرقام أدناه مأخوذة من جلسة واحدة مقيسة على حاسوب محمول بذاكرة 16 GB مع ثمانية وكلاء يعملون. لا شيء هنا تقدير.
كانت الآلة تعمل منذ خمس ساعات ونصف. لا مشكلة حرارية على الإطلاق: لا خفض تردد مسجّل، والبطارية عند 30.6 درجة مئوية. كان متوسط الحِمل بين 17 و21 على 8 أنوية، وكان CPU يقضي 56% من وقته داخل النواة مقابل 1.5% خمول. هذه النسبة هي ما يفضح كل شيء. الآلة التي تنجز عملًا حقيقيًا تقضي وقتها في شيفرة المستخدم؛ أما آلة عند 56% من وقت النظام فهي نواة لا تفعل شيئًا سوى ضغط الذاكرة وفكّ ضغطها وتبديلها.
كانت سبع عمليات بحث عالقة تحتجز بين 3.9 و8.0 GB لكل واحدة، أي 41.8 GB مطلوبة إجمالًا على آلة فيها 16 GB من RAM. وكان التبديل عند 22.3 GB من أصل 23.5، وقد كُتب نحو 993 GB إلى التبديل منذ الإقلاع. إنهاء تلك العمليات السبع أعاد 15.5 GB فورًا، دون إعادة تشغيل وكيل واحد ودون إعادة تشغيل التطبيق.
السبب في أن لا أحد يلتقط هذا يدويًا هو أن الأدوات المعتادة تكذب بشأنه. على macOS قد تعرض عملية عالقة 20 MB من الذاكرة المقيمة بينما هي تحتجز فعليًا 8 GB، لأن كل ما لمسته مرّ عبر ضاغط الذاكرة. قِسنا واحدة على الهواء عند 4.7 GB من الذاكرة المقيمة مقابل بصمة حقيقية قدرها 14 GB. والحجم الافتراضي لا يفيد أيضًا: على تلك المنصة حتى launchd يبلّغ عن نحو 440 GB من الحجم الافتراضي، فالتصفية عليه تعني الإشارة إلى الآلة بأكملها.
الجلسة نفسها، ساعة بساعة: كتل الذاكرة التي لم يعد أحد يستخدمها، وما يحدث حين تُحرَّر.
ولهذه العمليات أربع خصائص تضمن أنها ستكون هنا غدًا أيضًا.
لا تنتهي أبدًا
ذاكرتها هي نفسها في التبديل، فتقضي وقتها في أخطاء الصفحات بدل الحساب. عملية بحث سليمة تشبع نواة كاملة؛ أما هذه فتقف عند 4%. لا مخرج من هذه الحلقة، ولا ينفع معها أي انتظار.
لا تموت أبدًا
لا مهلة زمنية على استدعاء أداة. لا شيء على الآلة لديه رأي في عملية خاملة منذ خمسين دقيقة. ستبقى جالسة هناك حتى يقتلها أحد أو تُعاد الآلة للإقلاع.
تعيش بعد وكيلها
أغلق تبويب الوكيل وقد تنجو العملية، فتُعاد نسبتها إلى عملية init. عند تلك اللحظة لا شيء يربطها بأي شيء: صارت يتيمة، ولن يستردّها أحد أبدًا. اثنتان من السبع التي قِسناها كانتا في هذه الحالة أصلًا.
تتراكم
واحدة عند كل جولة تحقّق، وواحدة عند كل بحث سيّئ الحظ. لهذا يتزايد التباطؤ باطّراد على مدى اليوم، ولهذا تبدو إعادة الإقلاع وكأنها تصلحه. هي لا تصلح شيئًا، بل تعيد العدّاد إلى الصفر فقط.
ماذا يفعل حارس العمليات
يراقب العمليات التي يولّدها وكلاؤك، وهو ضيّق عمدًا في تحديد ما يسمح لنفسه بلمسه.
يقيس الذاكرة الحقيقية
لا الحجم المقيم الذي يقلّل تقدير عملية عالقة بغيغابايتات. يقرأ الحارس البصمة الحقيقية مع الصفحات المضغوطة والصفحات المنقولة إلى التبديل، فتظهر عملية تعرض 20 MB وتحتجز 8 GB على حقيقتها.
يراقب CPU، لا RAM وحدها
الذاكرة وحدها كانت ستشير إلى كل عملية بناء على آلتك. يقيس الحارس استهلاك المعالج كمعدّل بين مسحين، فتُلتقط العملية التي اشتغلت بجدّ ثم تعطّلت، وتُترك عملية البناء التي تعمل فعلًا وشأنها.
يلتقط العمليات اليتيمة
العملية التي عاشت بعد الوكيل الذي أطلقها يُبلَّغ عنها بحدّ ذاتها، لأن لا أحد آخر سيستردّها يومًا. تُحفظ نسبتها إلى صاحبها بينما تكون ما تزال مرتبطة به، وهي اللحظة الوحيدة التي يمكن فيها تحديدها.
نقرة واحدة لإنهائها
شارة في شريط الحالة تسرد كل عملية عالقة مع الوكيل الذي ولّدها، وذاكرتها، وعمرها، واستهلاكها لـCPU. إنهاء واحدة ينهيها مع كل ما تفرّع عنها. تعود الذاكرة على الفور ويستمر وكلاؤك في العمل.
macOS وWindows وLinux
كل نظام يحتاج قياسًا مختلفًا كي يقول الحقيقة عن الذاكرة: الصفحات المضغوطة على macOS، والمقيم زائد المنقول إلى التبديل على Linux، والالتزام الخاص على Windows. الثلاثة منفَّذة فعلًا، لا مخطَّطة.
لا يكلّف شيئًا تقريبًا
لقطة واحدة للعمليات كل دقيقة، قيست عند نحو 40 ms على آلة تشغّل 824 عملية. أما فحص الذاكرة المكلف فلا يُشغَّل إلا حين يبدو شيء عالقًا أصلًا، ولا يجري أي مسح ما دام لا وكيل نشطًا.
القاعدة التي تمنعه من إطلاق إنذار كاذب
الحارس الذي يشير إلى عمليات البناء لديك هو حارس ستطفئه خلال أسبوع. لذلك لا يُبلَّغ عن عملية بسبب ذاكرتها وحدها أبدًا. عليها أن تكون كبيرة، وأن تكون قد عاشت مدة، وأن تكون قد توقّفت عن استخدام المعالج. الثلاثة دفعة واحدة.
الشرط الثالث هو الذي ينجز العمل. فحص الأنواع أو أداة التحزيم يحتجزان غيغابايتات لدقائق أيضًا، لكنهما يشبعان نواة كاملة أثناء ذلك. أما العملية المحبوسة في التبديل فتقف عند 4% تقريبًا، لأنها تقضي عمرها في انتظار أخطاء الصفحات بدل الحساب. هذه الفجوة هي ما يفصل آلة تعمل عن آلة تغرق، وهي الإشارة الوحيدة التي تفصل بينهما بشكل موثوق.
واستهلاك المعالج مقيس لا مقروء. الرقم المعتاد الذي تعرضه أدوات النظام هو متوسط على عمر العملية كاملًا، وهو يبدو مشغولًا لشيء اشتغل بجدّ عشرين دقيقة ثم تعطّل. يقارن الحارس بدل ذلك وقت المعالج المستهلك بين مسحين، فما يراه هو الدقيقة الأخيرة لا الساعة الأخيرة.
كيف يعمل
أربع خطوات، مرة كل دقيقة، والخطوة المكلفة لا تُشغَّل تقريبًا.
لقطة رخيصة واحدة للآلة
كل دقيقة يأخذ الحارس لقطة واحدة لكل العمليات الجارية ويمشي في الشجرة أسفل كل طرفية وكيل. الكلفة المقيسة على آلة تشغّل 824 عملية: نحو 40 ms. وما دام لا وكيل يعمل، لا يحدث هذا إطلاقًا.
اختصار قائمة المشتبه بها
من تلك اللقطة لا يبقي إلا العمليات الفرعية للوكلاء التي عاشت أطول من عتبتك ولم تعد تستخدم المعالج. في الاستخدام العادي تكون هذه القائمة فارغة، وينتهي كل شيء هنا.
قياس ما يبدو عالقًا
لهذه القائمة القصيرة وحدها يدفع الحارس ثمن قياس الذاكرة الحقيقي، مع الصفحات المضغوطة والمنقولة إلى التبديل. والعملية التي يعجز عن قياسها لا يُبلَّغ عنها أبدًا: المجهول ليس حكمًا.
يبلّغ، ويترك القرار لك
تظهر شارة في شريط الحالة وإشعار واحد يخبرك بالأمر مرة واحدة. تفتح القائمة، فترى ما هي العملية، وكم تحتجز، ومنذ متى هي عالقة، وأي وكيل أطلقها، وتنهيها إن أردت.
ما لن يمسّه أبدًا
الأداة القادرة على إنهاء عمليات يجب أن تكون ضيّقة في تحديد ما يعنيها. هذه الحدود بنيوية، لا خيارات عليك أن تتذكّر تفعيلها.
- واجهة CLI الخاصة بالوكيل نفسه. أيًّا كان المزوِّد الذي تشغّله، يحمي الحارس الملف التنفيذي الذي استخدمه التطبيق لإطلاق تلك الطرفية. يقرأ ذلك الاسم من الإطلاق نفسه لا من قائمة مكتوبة في الشيفرة، فتكون العملية الفرعية لواجهة CLI نفسها محميّة أيضًا، على أي عمق.
- طرفيات أوامر التطوير لديك. خادم تطوير خامل يستوفي كل معايير العملية الجامحة: ضخم، وقديم، ولا يستهلك من المعالج شيئًا. وهو أيضًا العملية الوحيدة التي تريدها فعلًا أن تعمل. لا يُراقَب سوى طرفيات الوكلاء، فلا يدخل خادم التطوير في الصورة أبدًا.
- الصدفة والبنية الداخلية للتطبيق. مساعد الطرفية والصدفة التي يعمل فيها الوكيل مستثنيان بحكم البناء. لا يكون مرشّحًا سوى عمليات الأدوات الواقعة أسفل واجهة CLI الخاصة بالوكيل.
- أي شيء لم يتبنّه. المسار الوحيد القادر على إنهاء عملية يرفض أي عملية لم يلتقطها الحارس من شجرة وكيل بعينه. لا يمكن أن يتحوّل إلى وسيلة لإنهاء شيء آخر على آلتك.
ولا شيء يُنهى تلقائيًا ما لم تطلب ذلك. افتراضيًا يبلّغ الحارس بما وجده وأنت تقرّر، لأنك أنت من يعرف إن كانت عملية كبيرة وصامتة أمرًا متوقعًا.
متى يستحق مكانه
كل واحدة من هذه حالة حقيقية، لا افتراضية.
الآلة أبطأ في السادسة مساءً منها في التاسعة صباحًا
لا لحظة واحدة انكسر فيها شيء، بل انزلاق مطّرد على مدى اليوم. هذا الشكل يكون دائمًا تقريبًا عمليات عالقة متراكمة، وهو الأصعب تشخيصًا باليد لأن لا شيء يبدو خاطئًا في أي لحظة بعينها.
عدة وكلاء يعملون بالتوازي
كلما شغّلت وكلاء أكثر، كثرت استدعاءات الأدوات، وزادت فرص أن يتعطّل أحدها. معدّل الفشل لكل استدعاء ضئيل جدًا؛ ومضروبًا في يوم من العمل المتوازي يكفّ عن كونه ضئيلًا.
بحث لا يعود أبدًا
نمط يجعل محرك التعابير النمطية ينفجر يحجز غيغابايتات على ملف حجمه بضع مئات من الكيلوبايتات. الوكيل ينتظره، وأنت تنتظر الوكيل، والآلة تدفع الثمن عن الاثنين.
أغلقت الوكيل، وبقيت العملية
إغلاق تبويب لا يحرّر شيئًا دائمًا. العملية التي كانت قد انفصلت أصلًا تحتفظ بذاكرتها وتفقد آخر رابط لها بأي شيء تراه في التطبيق.
حاسوب محمول بذاكرة 16 GB
على آلة بذاكرة RAM وفيرة، تختبئ بضع عمليات عالقة وقتًا طويلًا. أما على محمول بذاكرة 16 GB فتصل إلى التبديل بسرعة، وما إن يبدأ النظام بضغط الذاكرة حتى يتباطأ كل وكيل لديك في الوقت نفسه.
قبل أن تتّهم التطبيق
حين تزحف الآلة وAgentsRoom مفتوح، يكون التطبيق هو المشتبه به البديهي. امتلاك الأرقام الحقيقية، لكل عملية على حدة، مع الوكيل الذي أطلق كلًا منها، يحوّل الشك إلى شيء يمكنك التحقق منه فعلًا.
أنت من يضع الحدود
القيم الافتراضية حذرة عمدًا. كل ما يلي موجود في الإعدادات، ضمن تبويب الطرفية، وكل واحد منها يمكن أيضًا لوكيل أن يقرأه ويغيّره عبر أدوات MCP الخاصة بـAgentsRoom.
- مراقبة العمليات الفرعية للوكلاء
- مفعّلة افتراضيًا. أطفئها فلا يجري أي مسح على الإطلاق، أبدًا.
- التبليغ فوق عتبة ذاكرة
- غيغابايتان افتراضيًا. تحتها لا تستحق عملية عالقة أن تقاطعك. ارفع العتبة على محطة عمل بذاكرة RAM وفيرة، وأنزلها على محمول ذاكرته مقتّرة.
- وبعد حد أدنى من العمر
- خمس دقائق افتراضيًا. هذا ما يمنع مهمة بطيئة لكنها مشروعة من أن يُبلَّغ عنها يومًا، إذ لا يكاد شيء تريده فعلًا يستغرق خمس دقائق دون أن يستهلك من المعالج شيئًا.
- إنهاء العمليات العالقة تلقائيًا
- مطفأ افتراضيًا، وهذا قرار منتج مقصود لا مجرّد حذر. الحارس يصدر حكمًا تقديريًا، وأنت وحدك تعرف إن كانت عملية كبيرة وصامتة أمرًا متوقعًا. فعّله فيتصرّف من تلقاء نفسه، مع إشعار بعد وقوع الأمر.
عتبة المعالج غير معروضة، وذلك عن قصد. هي القياس الذي يفصل عملية بناء تعمل عن عملية عالقة، وليست مسألة ذوق.
الأسئلة الشائعة
هل يعني هذا أن AgentsRoom يبطّئ حاسوبي؟
لا، ولهذا السبب بالذات وُجدت هذه الميزة. في الجلسة التي قِسناها، كان التطبيق يستهلك 2.8 GB موزّعة على 91 عملية، وواجهات CLI الثمانية للوكلاء 1.6 GB مجتمعة. أما الـ41.8 GB فكانت محتجزة لدى عمليات أدوات تعطّلت. يصادف أن AgentsRoom هو المكان الوحيد الذي يرى كل وكيل وكل عملية ولّدها، فهو المكان الوحيد القادر على الفصل.
هل سينهي عملية البناء أو تشغيل الاختبارات لديّ؟
لا. لا يُبلَّغ عن عملية إلا إذا كانت كبيرة وقديمة وتوقّفت عن استخدام المعالج. عملية البناء التي تعمل فعلًا تشبع نواة كاملة، فتسقط عند الشرط الثالث ولا تصبح مرشّحة أبدًا. هذا الشرط موجود تحديدًا ليصنع هذا التمييز.
هل يراقب خادم التطوير لديّ؟
لا، ولن يفعل أبدًا. خادم تطوير خامل يستوفي كل معايير العملية الجامحة: يحتجز ذاكرة كثيرة، ويعمل منذ ساعات، ولا يستخدم المعالج بين طلب وآخر. لا يُراقَب سوى العمليات الفرعية لطرفيات الوكلاء، فأوامر التطوير لديك خارج النطاق بحكم البناء.
هل يمكنه إنهاء الوكيل نفسه؟
لا. واجهة CLI الخاصة بالوكيل محميّة أيًّا كان المزوِّد الذي تستخدمه، والحماية مبنية على الملف التنفيذي الذي استخدمه التطبيق لإطلاق تلك الطرفية لا على قائمة أسماء معروفة. والصدفة ومساعد الطرفية الخاص بالتطبيق مستثنيان كذلك.
ما العملية اليتيمة ولماذا تحظى بمعاملة خاصة؟
العملية التي انتهى أبوها تُعاد نسبتها إلى عملية init في النظام. من تلك اللحظة لا شيء يربطها بالوكيل الذي أطلقها، فلا أحد سينظّفها أبدًا. يحفظ AgentsRoom نسبتها إلى صاحبها بينما تكون ما تزال مرتبطة به، وهي اللحظة الوحيدة التي يمكن فيها تحديدها، فيظل قادرًا على التبليغ عنها بعد ذلك.
كم تكلّف المراقبة نفسها؟
لقطة واحدة للعمليات كل دقيقة، قيست عند نحو 40 ms على آلة تشغّل 824 عملية. أما قياس الذاكرة الأكثر كلفة فلا يجري إلا على عمليات تبدو عالقة أصلًا، وهو ما يعني في الاستخدام العادي أنه لا يجري. والمسح غير موجود أصلًا ما دام لا وكيل نشطًا.
لماذا لا أكتفي بالنظر إلى عمود الذاكرة في مراقب النشاط؟
لأنه على macOS يقلّل من حجم المشكلة برتبة كاملة. العملية التي دُفعت إلى الذاكرة المضغوطة قد تعرض 20 MB مقيمة بينما تحتجز 8 GB. قِسنا واحدة على الهواء عند 4.7 GB مقيمة مقابل بصمة حقيقية قدرها 14 GB. والحجم الافتراضي ليس أفضل: حتى عمليات النظام تبلّغ عن مئات الغيغابايتات منه.
هل يعمل مع Claude Code وCodex وغيرهما؟
نعم. لا يعرف الحارس شيئًا عن أي أداة أو مزوِّد بعينه. يراقب العمليات الفرعية لأي طرفية وكيل شغّلتها، وواجهة CLI التي يحميها تُقرأ من الإطلاق نفسه. إضافة مزوِّد جديد لا تغيّر شيئًا هنا.
هل يعمل على Windows وLinux؟
نعم. كل منصة تحتاج قياسًا مختلفًا كي تكون الذاكرة صادقة: الصفحات المضغوطة على macOS، والمقيم زائد المنقول إلى التبديل على Linux، والالتزام الخاص على Windows. الثلاثة منفَّذة.
هل سينهي عمليات دون أن يسألني؟
ليس ما لم تفعّل ذلك بنفسك. افتراضيًا يبلّغ بما وجده، مع الوكيل والذاكرة والعمر واستهلاك المعالج، وأنت تقرّر. الإنهاء التلقائي إعداد، مطفأ منذ اللحظة الأولى.
ماذا يحدث للوكيل حين أنهي إحدى عملياته؟
يواصل الوكيل عمله. يتلقّى استدعاء الأداة خطأً بدل أن يبقى معلّقًا إلى الأبد، وهذه هي النتيجة التي تريدها: تلك العملية لم تكن ستنتهي على أي حال. لا شيء يُعاد تشغيله ولا يضيع أي سياق.
هل يعالج السبب الجذري؟
لا، وهو لا يحاول. الأسباب تتغيّر: أداة اليوم، ونمط الغد، ومزوِّد الشهر المقبل. هذه شبكة أمان، مصمَّمة لتظل تعمل حين يكون السبب سببًا لم يره أحد بعد.
قد يعجبك أيضًا
كناري السياق
الإنذار المبكر الآخر: يراقب سياق الوكيل نفسه لا الآلة، ويخبرك حين ينجرف وكيل قبل أن يبدأ باختلاق ملفات وواجهات برمجية.
طرفيات المطورين
شغّل خوادم التطوير والأوامر الطويلة داخل AgentsRoom، مع إشعار حين ينتهي أمر طويل. هذه الطرفيات هي بالضبط ما بُني حارس العمليات كي لا يمسّه أبدًا.
تتبّع حالة الوكلاء
اعرف بلمحة أي الوكلاء يعمل، وأيهم ينتظرك، وأيهم خامل، دون قراءة طرفية واحدة.
استخدام الرموز
المورد الآخر الجدير بالمراقبة. استهلاك الرموز وحصّتها لكل وكيل، لتعرف إلى أين يذهب استخدامك.
العرض المقسّم
عدة وكلاء جنبًا إلى جنب في نافذة واحدة، لكل منهم لوحه ولونه وحالته الحية.
CLI Doctor
حين يعجز وكيل عن الإقلاع، يخبرك بالسبب وبما ينبغي فعله، بدل أن يتركك أمام طرفية فارغة.
توقّف عن الدفع مقابل عمليات لا يستخدمها أحد
تنزيل AgentsRoom مجاني، وحارس العمليات مفعّل منذ أول تشغيل.
التطبيق المرافق: تابع وكلاءك أينما كنت
استخدم Claude أو Codex أو Antigravity CLI أو أي مزود AI آخر.
أرسل الأخطاء والطلبات مباشرة إلى قائمة المهام العامة.
لمحة عن AgentsRoom أثناء العمل.