استكشاف مشاكل Cursor Agent الشائعة وإصلاحها

وضع agent في Cursor قوي، ولكن عندما تسوء الأمور، يمكن أن تكون الأعراض مربكة. agent يتعلق إلى ما لا نهاية، أو أداء يتدهور دون تفسير، أو عدادات استخدام تصل إلى 100% بعد Tokens أقل بكثير من المتوقع، كل هذه مشاكل يبلغ عنها مستخدمو المنتدى بانتظام. يقدم هذا الدليل حلولاً ملموسة ومختبرة لأكثر مشاكل agent شيوعًا في Cursor.

تعليق Agent عند "Taking Longer Than Expected"

هذه أكثر مشكلة agent يتم الإبلاغ عنها. يبدأ agent مهمة، يبدأ في العمل، ثم يتوقف مع رسالة "Taking longer than expected." أحيانًا يكمل في النهاية، وأحيانًا لا يكمل أبدًا.

فهم الرسالة

"Taking longer than expected" ليست خطأ. إنها إشعار بأن عملية agent الحالية قد تجاوزت حدًا زمنيًا. من المحتمل أن agent ينتظر شيئًا ما:

سبب الانتظار	الاحتمالية	صعوبة الإصلاح
طلب شبكة إلى مزود الذكاء الاصطناعي	عالية	سهل
مهلة تنفيذ الأداة	متوسطة	متوسط
قراءة/فهرسة ملف كبير	متوسطة	سهل
تعليق أمر الطرفية	متوسطة	متوسط
عدم استجابة خادم MCP	منخفضة	متوسط
خطأ داخلي في Cursor	منخفضة	صعب

خطوة التشخيص 1: فحص اتصال الشبكة

يعتمد agent على سحابة Cursor لتشغيل نموذج الذكاء الاصطناعي. إذا كانت شبكتك غير مستقرة أو خلف وكيل، سيتعلق agent.

# اختبار الاتصال بـ API الخاص بـ Cursor
curl -w "Time: %{time_total}s\n" -o /dev/null -s https://api2.cursor.sh/health

# التحقق مما إذا كنت خلف وكيل
echo $HTTP_PROXY
echo $HTTPS_PROXY

تلميح

إذا كنت تستخدم VPN للشركة أو خلف وكيل، قد يتعلق agent بشكل متقطع. قم بتكوين إعدادات الوكيل في Cursor تحت Settings > General > HTTP Proxy. تأكد من أن الوكيل يسمح باتصالات WebSocket، التي يستخدمها Cursor لبث استجابات agent.

خطوة التشخيص 2: التحقق مما إذا كانت أداة عالقة

قد يكون agent في انتظار تنفيذ أداة (مثل أمر طرفية، أو بحث عن ملفات، أو استدعاء أداة MCP). انظر إلى مؤشر نشاط agent. إذا كان يقول شيئًا مثل "Running command..." أو "Searching files..."، فإن التعليق في تنفيذ الأداة، وليس في نموذج الذكاء الاصطناعي.

الإصلاح: ألغِ تشغيل agent الحالي (Cmd/Ctrl + .) وأعد المحاولة. إذا كان يتعلق باستمرار على نفس الأداة، فهذه الأداة لديها مشكلة. راجع قسمي تعليق الطرفية و MCP أدناه.

خطوة التشخيص 3: تقليل حجم السياق

نوافذ السياق الكبيرة تبطئ agent لأنه يجب معالجة المزيد من البيانات في كل خطوة. إذا كان مشروعك كبيرًا أو لديك العديد من الملفات المفتوحة:

1. أغلق الملفات التي لا تحتاجها للمهمة الحالية
2. استخدم إشارات @ للإشارة إلى الملفات ذات الصلة فقط
3. تجنب @codebase للمشاريع الكبيرة ما لم يكن ذلك ضروريًا
4. امسح سجل الدردشة إذا أصبح طويلًا جدًا

warning

إشارة @codebase توجه agent للبحث في قاعدة الكود المفهرسة بالكامل. لمشروع به أكثر من 10,000 ملف، يمكن أن يستغرق هذا وقتًا كبيرًا وقد يؤدي إلى رسالة "Taking longer than expected". استخدم إشارات @file أو @folder الموجهة بدلاً من ذلك للحصول على أداء أفضل.

خطوة التشخيص 4: إعادة تشغيل عملية Agent

إذا لم يساعد أي مما سبق، فإن عملية agent نفسها قد تكون في حالة سيئة:

1. افتح لوحة الأوامر (Cmd/Ctrl + Shift + P)
2. اكتب Developer: Reload Window
3. بعد إعادة التحميل، ابدأ جلسة agent جديدة

هذا يمسح الحالة في الذاكرة دون إغلاق مشروعك.

أداء Agent البطيء

عندما يكون agent بطيئًا ولكن غير معلق بالكامل، يمكن أن تكون التجربة بطيئة بشكل محبط. يصف مستخدمو المنتدى أداءً "فائق البطء" حيث تستغرق كل خطوة أكثر من 30 ثانية.

الأسباب الشائعة لضعف الأداء

1. فهرسة قاعدة كود كبيرة

إذا كان Cursor يقوم بفهرسة قاعدة الكود الخاصة بك أثناء استخدامك لـ agent، سيتدهور الأداء بشكل كبير. تحقق من شريط الحالة عن مؤشر الفهرسة.

الإصلاح:

• انتظر اكتمال الفهرسة قبل بدء مهام agent الثقيلة
• أضف الدلائل الكبيرة إلى files.exclude لتخطي الفهرسة غير الضرورية:

{
  "files.exclude": {
    "**/node_modules": true,
    "**/dist": true,
    "**/build": true,
    "**/.next": true,
    "**/coverage": true,
    "**/.git/objects": true
  }
}

2. عدد مفرط من التبويبات المفتوحة

كل ملف مفتوح يستهلك الذاكرة والسياق. يتتبع Cursor الملفات المفتوحة لوعي سياق agent.

الإصلاح: أغلق الملفات التي لا تعمل عليها بنشاط. استخدم Cmd/Ctrl + W لإغلاق التبويب الحالي. يمكنك دائمًا إعادة فتحها.

3. تعارضات Agent في الخلفية

إذا كان لديك agents تعمل في الخلفية أثناء استخدام agent في المقدمة، فإنها تتنافس على الموارد.

الإصلاح: تحقق من agents الخلفية قيد التشغيل في شريط الحالة. أوقفها أو ألغها أثناء العمل في المقدمة.

4. نسخة Cursor قديمة

تأتي تحسينات الأداء مع كل تحديث لـ Cursor. تشغيل نسخة قديمة يعني تفويت التحسينات.

الإصلاح:

# تحقق من نسخة Cursor الخاصة بك
# Help > About (أو Cursor > About على macOS)

إذا كنت متأخرًا بأكثر من نسختين، حدّث على الفور.

قائمة فحص تحسين الأداء

• اكتملت فهرسة قاعدة الكود
• تم استبعاد الدلائل الكبيرة من الفهرسة
• لا يزيد عدد الملفات المفتوحة عن 10-15
• تم إيقاف أو إكمال agents الخلفية
• تم تحديث Cursor إلى أحدث نسخة
• لا توجد مشاكل VPN/وكيل (اختبر بـ curl)
• ذاكرة وصول عشوائي (RAM) كافية للنظام (8 جيجابايت كحد أدنى، 16 جيجابايت موصى به)
• يحتوي القرص على 20% على الأقل من المساحة الحرة

تعارضات whois.exe على Windows

مشكلة شائعة بشكل مدهش ومحددة على Windows: يتعلق agent أو يتعطل عندما تتورط عملية whois.exe. لقد تعقب مستخدمو المنتدى عدم استقرار agent إلى أداة نظام Windows هذه.

ما هو whois.exe؟

whois.exe هو أداة Windows Sysinternals تقوم بإجراء عمليات بحث عن أسماء النطاقات. ليست جزءًا من Windows القياسي ولكنها مثبتة عادة من قبل المطورين. قد تستدعي بعض إضافات Cursor أو خوادم MCP أثناء عمليات الشبكة.

التعارض

تنشأ المشكلة عندما:

1. يقوم خادم MCP أو إضافة بتشغيل whois.exe كعملية فرعية
2. يقوم whois.exe بطلب شبكة يتعلق (مثل الاستعلام عن نطاق خلف جدار حماية)
3. العملية الفرعية لا تنتهي بالمهلة
4. ينتظر agent إلى ما لا نهاية اكتمال العملية الفرعية
5. يبدو agent معلقًا

الإصلاح 1: إزالة whois.exe من PATH

إذا لم تكن بحاجة إلى whois.exe للتطوير:

# تحقق مما إذا كان whois.exe في PATH الخاص بك
where.exe whois

# إذا وجد، أزله من PATH (اضبط المسار حسب الحاجة)
$path = [System.Environment]::GetEnvironmentVariable("PATH", "User")
$newPath = ($path -split ";" | Where-Object { $_ -notlike "*Sysinternals*" }) -join ";"
[System.Environment]::SetEnvironmentVariable("PATH", $newPath, "User")

أعد تشغيل Cursor بعد إجراء هذا التغيير.

الإصلاح 2: تحديد ما يستدعي whois.exe

استخدم Process Monitor لمعرفة العملية التي تشغل whois.exe:

1. نزل Process Monitor من Sysinternals
2. شغل Process Monitor
3. عيّن فلترًا: Process Name contains whois.exe
4. ابدأ مهمة agent في Cursor
5. راقب العملية التي تشغل whois.exe

بعد التحديد، قم بتكوين خادم MCP أو الإضافة لتعطيل البحث الشبكي الذي يشغل whois.exe.

تلميح

إذا كان خادم MCP يشغل whois.exe للتحقق من النطاقات، تحقق من تكوين الخادم عن إعداد verifyDomains أو dnsLookup. تعطيل التحقق من النطاق في خوادم MCP التي لا تحتاج إليه للأمان سيمنع التعليق.

الإصلاح 3: تعيين مهلة للعملية

لخوادم MCP التي تشغل عمليات فرعية، قم بتكوين مهلة:

{
  "mcpServers": {
    "problematic-server": {
      "command": "npx",
      "args": ["-y", "@org/server"],
      "env": {
        "CHILD_PROCESS_TIMEOUT_MS": "10000",
        "DISABLE_WHOIS": "true"
      }
    }
  }
}

تعليق اختيار الطرفية

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

السبب

يحدث هذا عادةً عندما:

1. تحتوي الطرفية على مخزن تمرير كبير
2. تطبيق الطرفية قيد التشغيل في وضع الشاشة البديلة (مثل vim، less، top)
3. يحاول agent تحديد نص يمتد عبر حدود الشاشة

الإصلاح 1: مسح مخزن تمرير الطرفية

قبل بدء مهمة agent تتضمن الطرفية:

1. أغلق الطرفية الحالية (Cmd/Ctrl + Shift + )
2. افتح طرفية جديدة
3. ابدأ مهمة agent

الإصلاح 2: تجنب برامج الشاشة البديلة

لا يمكن لـ agent التفاعل بشكل موثوق مع تطبيقات الطرفية بملء الشاشة. إذا كان سير عملك يتضمن قيام agent بتشغيل أوامر الطرفية:

• تجنب تشغيل vim، nano، less، top، أو htop في طرفية agent
• استخدم بدائل غير تفاعلية: cat بدلاً من less، head بدلاً من less

الإصلاح 3: تكوين إعدادات الطرفية

{
  "terminal.integrated.scrollback": 1000,
  "terminal.integrated.enablePersistentSessions": false
}

يقلل تقليل التمرير من كمية النص التي يحتاج agent إلى معالجتها عند التحديد، مما يمنع التعليق.

warning

إذا كان agent يتعلق باستمرار عند التفاعل مع الطرفية، فكر فيما إذا كانت المهمة تتطلب فعلاً تفاعلًا مع الطرفية. يمكن إجراء العديد من مهام الطرفية (تشغيل الاختبارات، فحص المخرجات) من خلال لوحات Cursor المدمجة، وهي أكثر موثوقية لتفاعل agent.

وصول الاستخدام إلى 100% بـ Tokens أقل

مشكلة محبطة يبلغ عنها العديد من مستخدمي المنتدى: يعرض لوحة الاستخدام 100% استخدام، ولكن المستخدم يعرف أنه لم يستخدم هذا القدر من Tokens. هذا يخلق انطباعًا بالخضوع للتحديد المسبق أو تقييد المعدل.

فهم حساب الاستخدام

يتبع مقياس استخدام Cursor عدة أشياء، وليس فقط عدد Tokens الخام:

المكون	ما يحسبه	الوزن التقريبي
Tokens الإدخال	Tokens المرسلة إلى النموذج	عالي
Tokens الإخراج	Tokens التي ينشئها النموذج	عالي
استرجاع السياق	فهرسة واسترجاع قاعدة الكود	متوسط
استدعاءات الأدوات	كل تنفيذ أداة	منخفض لكل استدعاء، يتراكم
قراءات الملفات	كل ملف يقرأه agent	منخفض لكل قراءة، يتراكم
عمليات MCP	كل تفاعل مع خادم MCP	متوسط

تلميح

مهمة agent واحدة تقرأ 50 ملفًا، وتجري 10 استدعاءات أدوات، وتنشئ 5000 Tokens إخراج قد تستهلك نفس "الاستخدام" كمهمة تنشئ 15000 Tokens إخراج. مقياس الاستخدام ليس عداد Tokens نقي. إنه مجموعة موزونة من جميع الموارد الحسابية التي استهلكها agent.

لماذا يصل الاستخدام إلى 100% قبل المتوقع

السبب 1: تضخم السياق

ترسل كل خطوة من مهمة agent سياق المحادثة بالكامل بالإضافة إلى الملفات المشار إليها إلى النموذج. إذا كانت محادثتك تحتوي على 20 دورة وتشير إلى 10 ملفات، فإن الخطوة 21 ترسل كل ذلك بالإضافة إلى المحتوى الجديد. ينمو عدد Tokens بشكل تربيعي، وليس خطيًا.

الإصلاح:

• ابدأ دردشة جديدة لكل مهمة متميزة
• استخدم /clear بين المهام غير المرتبطة
• تجنب الإشارة إلى قاعدة الكود بأكملها؛ استخدم ملفات محددة

السبب 2: قراءات ملفات متكررة

قد يقرأ agent نفس الملف عدة مرات عبر خطوات مختلفة. كل قراءة تحسب ضمن الاستخدام.

الإصلاح:

• إذا لاحظت أن agent يعيد قراءة الملفات، أخبره صراحة: "لديك بالفعل محتوى الملف X. لا تقرأه مرة أخرى."
• استخدم إشارات @file لتحميل الملفات مسبقًا في السياق مرة واحدة

السبب 3: عبء وضع Plan

عند استخدام وضع Plan، ينشئ agent خطة قبل التنفيذ. ينشئ الخطة يستهلك Tokens يتم حسابها ضمن الاستخدام حتى لو لم يتم تغيير أي كود.

الإصلاح: استخدم وضع Plan بشكل انتقائي، وليس لكل مهمة.

مراقبة الاستخدام الفعلي

لرؤية تفصيل Tokens الفعلي:

1. انقر على مؤشر الاستخدام في شريط الحالة
2. عرض التفصيل التفصيلي
3. تحقق من "Context tokens" مقابل "Generated tokens"

إذا كانت Tokens السياق تتجاوز بشكل كبير Tokens المنشأة، فإن استخدامك يُستهلك بواسطة تضخم السياق، وليس بواسطة توليد الكود الفعلي.

warning

إذا وصل استخدامك باستمرار إلى 100% بنشاط يبدو ضئيلًا، تحقق من وجود agents خلفية غير منظبطة. agent خلفية عالق في حلقة سيستهلك الاستخدام بسرعة. تحقق من لوحة Background Agents عن أي agents تظهر نشاطًا مستمرًا دون إنتاج نتائج، وألغها.

رؤية تكاليف لوحة التحكم

يبلغ مستخدمو المنتدى أن لوحة تحكم Cursor لا تظهر بوضوح تفصيل التكاليف، مما يجعل من الصعب فهم أين تذهب الأموال.

ما تعرضه لوحة التحكم

تعرض لوحة تحكم Cursor (قابلة للوصول عبر Settings > Usage):

1. الإجمالي - نسبة مئوية من حد خطتك
2. تفصيل النموذج - أي النماذج استهلكت أكثر
3. الجدول الزمني - الاستخدام خلال فترة الفوترة

ما لا تعرضه لوحة التحكم

• عدد Tokens لكل مهمة (يجب عليك التحقق من الدردشات الفردية)
• التكلفة بالدولارات (لخطط Pro/Business، يظهر الاستخدام كنسبة مئوية، وليس كمبلغ بالدولارات)
• تقسيم Tokens السياق مقابل التوليد (متاح فقط لكل دردشة، غير مجمع)
• استخدام خادم MCP (استخدام Tokens بواسطة استدعاءات MCP غير مفصول)

حلول بديلة لرؤية أفضل

تتبع الاستخدام لكل مهمة

بعد كل مهمة agent مهمة، سجل نسبة الاستخدام. هذا يبني نموذجًا ذهنيًا لأنواع المهام الأكثر تكلفة:

Task: Refactor auth module - 15% usage
Task: Write unit tests - 8% usage
Task: Debug API endpoint - 5% usage

استخدام API للحصول على مقاييس مفصلة

إذا كنت في خطة Business، يمكنك الاستعلام عن API للحصول على استخدام مفصل:

# الحصول على تفاصيل الاستخدام (API خطة Business)
curl -H "Authorization: Bearer $CURSOR_API_KEY" \
  https://api2.cursor.sh/usage/details?period=current

هذا يرجع تفصيل JSON لاستخدام Tokens حسب النموذج ونوع المهمة والتاريخ.

إصلاح رأسية الإدخال الثابتة

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

المشكلة

عندما تكون استجابة agent طويلة، يظل شريط إدخال الأوامر مثبتًا في الأعلى. على الشاشات الأصغر، يمكن أن يستهلك هذا 20-30% من المنطقة المرئية، تاركًا مساحة صغيرة للاستجابة الفعلية.

الإصلاح 1: تبديل الدردشة بملء الشاشة

اضغط على Cmd/Ctrl + Shift + L لتبديل لوحة الدردشة إلى وضع ملء الشاشة. هذا يعطي الاستجابة مساحة أكبر ويجعل الرأس الثابت أصغر نسبيًا.

الإصلاح 2: ضبط تخطيط الدردشة

{
  "cursor.chat.stickyHeader": false,
  "cursor.chat.compactMode": true
}

ضبط stickyHeader على false يسمح لرأس الأوامر بالتمرر بعيدًا مع باقي المحتوى.

تلميح

إذا كان إعداد stickyHeader غير متاح في نسختك من Cursor، فقد يسمى cursor.chat.inputBehavior. تحقق في Settings > Features > Chat عن خيار تكوين سلوك شريط الإدخال. تغير الاسم الدقيق للإعداد عبر النسخ.

الإصلاح 3: استخدام نافذة أعرض

إذا لم تكن الرأس الثابت هي المشكلة ولكن مساحة الشاشة محدودة، فزد عرض نافذة Cursor. لوحة الدردشة أكثر قابلية للاستخدام بعرض 800 بكسل+. على كمبيوتر محمول مقاس 13 بوصة، فكر في شاشة خارجية للعمل المكثف بـ agent.

سير عمل استكشاف الأخطاء العام

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

الخطوة 1: إعادة الإنتاج معزولًا

1. ابدأ دردشة جديدة
2. أعطِ مهمة بسيطة: "أنشئ ملفًا اسمه test.txt يحتوي على المحتوى 'hello'"
3. إذا فشل هذا، فالمشكلة بيئية (الشبكة، تثبيت Cursor، موارد النظام)
4. إذا نجح هذا، فالمشكلة محددة بالمهمة (سياق كبير، أدوات محددة، MCP)

الخطوة 2: فحص السجلات

1. افتح لوحة المخرجات (Cmd/Ctrl + Shift + U)
2. حدد Cursor Agent من القائمة المنسدلة
3. ابحث عن رسائل الخطأ، أو المهلات، أو الاستثناءات

الخطوة 3: الوضع الآمن

عطل جميع الإضافات وخوادم MCP:

1. Cmd/Ctrl + Shift + P > Extensions: Disable All Installed Extensions
2. أزل تكوين خادم MCP مؤقتًا
3. أعد تشغيل Cursor
4. اختبر agent

إذا عمل agent في الوضع الآمن، فالمشكلة سببها إضافة أو خادم MCP. أعد تمكينها واحدًا تلو الآخر لعزل المتسبب.

الخطوة 4: جمع معلومات تشخيصية

إذا كنت تحتاج إلى الإبلاغ عن المشكلة إلى دعم Cursor:

# نسخة Cursor
cursor --version

# معلومات النظام
# macOS: system_profiler SPHardwareDataType
# Windows: systeminfo | findstr /B /C:"OS Name" /C:"Total Physical Memory"
# Linux: uname -a && free -h

# موقع سجلات Cursor
# macOS: ~/Library/Application Support/Cursor/logs/
# Windows: %APPDATA%/Cursor/logs/
# Linux: ~/.config/Cursor/logs/

الخلاصة

تنقسم مشاكل agent في Cursor إلى عدة فئات: مشاكل الشبكة والاتصال المسببة للتعليق، وتنافس الموارد المسبب للبطء، والتعارضات الخاصة بـ Windows مثل whois.exe، وقيود تفاعل الطرفية، وغرابة حساب الاستخدام التي تجعلك تشعر بأنك تستنزف حصتك أسرع من المتوقع. باتباع خطوات التشخيص في هذا الدليل، يمكنك تحديد السبب الجذري لمعظم مشاكل agent وتطبيق إصلاح موجه بدلاً من إعادة التشغيل بشكل أعمى وتوقع الأفضل.