ملخص: أُطلق Cursor 3 في 2 أبريل 2026، ليحل محل واجهة IDE-first بمساحة عمل قائمة على الوكيل أولاً (agent-first). بالنسبة لمطوري واجهات برمجة التطبيقات (API)، تتمثل أكبر التغييرات في التنفيذ المتوازي للوكلاء، ومخرجات أدوات MCP الأكثر ثراءً، وميزة الانتقال من السحابة إلى الجهاز المحلي التي تحافظ على سير عملك دون انقطاع. إذا قمت بإقران Cursor 3 مع خادم MCP من Apidog، يمكن لوكلاء الذكاء الاصطناعي قراءة مواصفات واجهة برمجة التطبيقات الحية الخاصة بك وإنشاء رمز دقيق وواعٍ بالمخططات دون أي نسخ ولصق.
التحول الذي ربما شعرت به قادمًا
أصبحت محررات أكواد الذكاء الاصطناعي أكثر ذكاءً منذ عامين. لكن Cursor 3 ليس تحديثًا تدريجيًا. إنه إعادة تصميم لما تبدو عليه بيئة تطوير الذكاء الاصطناعي في جوهرها.
قبل Cursor 3، كنت لا تزال تعمل في الغالب كمستخدم تقليدي لبيئة التطوير المتكاملة (IDE). كنت تفتح ملفًا، وتطلب المساعدة من وكيل، وتراجع الاختلافات، ثم تنتقل. كان الوكلاء مجرد مساعدين تستدعيهم عند الحاجة.
يقلب Cursor 3 هذا المفهوم. أصبح الوكلاء الآن الوحدة الأساسية للعمل. يمكنك إدارتهم مثل علامات التبويب في المتصفح: تشغيل العديد منهم، وتركهم يعملون بالتوازي، والتحقق من مخرجاتهم، وترقية الأفضل.
بالنسبة لمطوري واجهات برمجة التطبيقات، هذا الأمر أكثر أهمية مما هو عليه بالنسبة لمعظم الآخرين. يتطلب عمل واجهات برمجة التطبيقات تنسيقًا مكثفًا. أنت تكتب نقاط نهاية، وتختبر العقود، وتحدث الوثائق، وتتعقب عدم تطابق المخططات. تعمل هذه المهام بالتوازي في أي مشروع حقيقي. الآن يمكن لأدواتك أن تتوافق مع هذا الواقع.
تتناول هذه المقالة ما تغير في Cursor 3، وما يعنيه ذلك لعمل واجهة برمجة التطبيقات يوميًا، وسير عمل محدد يربط Cursor 3 بخادم MCP من Apidog.
ما الجديد في Cursor 3
تم إصدار Cursor 3 في 2 أبريل 2026. الميزة الرئيسية هي واجهة جديدة تسمى نافذة الوكلاء (Agents Window). لكن العديد من التغييرات الأخرى تهم بشكل خاص المطورين الذين يعملون مع واجهات برمجة التطبيقات.
نافذة الوكلاء (Agents Window)
تستبدل نافذة الوكلاء التخطيط المرتكز على المحرر بتخطيط يركز على الوكيل. يمكنك تشغيل وكلاء عبر مستودعات متعددة في وقت واحد، سواء كانوا يعملون محليًا، في مساحات عمل Git (git worktrees)، في بيئة Cursor السحابية، أو على جهاز SSH بعيد.
يمكنك الوصول إليها باستخدام Cmd+Shift+P -> Agents Window. يمكنك إبقاء بيئة التطوير المتكاملة (IDE) مفتوحة بجانبها، أو التبديل بينهما. لا شيء مما كان لديك سابقًا يختفي؛ إنها إضافة.

التأثير العملي: يمكنك بدء تشغيل وكيل لإنشاء نقطة نهاية API جديدة في مستودع واحد بينما يقوم وكيل آخر بإصلاح خطأ في مكتبة مشتركة. تشاهد كلاهما. تتدخل عند الحاجة. توافق على الاختلافات عندما تكون جاهزة.
وضع التصميم (Design Mode)
داخل نافذة الوكلاء، يتيح لك وضع التصميم (Design Mode) إضافة تعليقات توضيحية لواجهة المستخدم في المتصفح مباشرةً. يمكنك تحديد العناصر، وإبراز المناطق، وإضافتها إلى سياق الوكيل دون كتابة وصف. بالنسبة لمطوري واجهة برمجة التطبيقات الذين يقومون ببناء أو اختبار واجهات أمامية للويب مقابل واجهات برمجة التطبيقات الخاصة بهم، فإن هذا يقلل من الحاجة إلى تعليمات "الزر في الزاوية العلوية اليمنى".
الاختصارات: Cmd+Shift+D للتبديل، Shift+drag لتحديد منطقة، Cmd+L لإضافة عنصر إلى الدردشة.

تطبيقات MCP: مخرجات المحتوى المهيكل
هذه الميزة هادئة ولكنها مهمة. في Cursor 3، تدعم تطبيقات MCP الآن المحتوى المهيكل في مخرجات الأدوات. في السابق، كانت مخرجات الأدوات من خوادم MCP تعود كنص عادي. الآن يمكنها إرجاع بيانات غنية ومهيكلة.

بالنسبة لخادم MCP من Apidog، هذا يعني أن الاستجابات من مشروع واجهة برمجة التطبيقات الخاص بك (تعريفات نقاط النهاية، بيانات المخطط، نتائج الاختبار) يمكن أن تعود بتنسيق يحلله وكلاء Cursor بشكل صحيح. يحصل الوكيل على بيانات نظيفة، وليس كتلة نصية يجب عليه تفسيرها.
مساحات العمل (Worktrees)، والأفضل من N (best-of-n)، والعزل
يقدم Cursor 3 أمرين جديدين: /worktree و /best-of-n.
/worktree ينشئ مساحة عمل Git معزولة. لا تؤثر التغييرات في هذا الفرع على دليل عملك. يمكنك اختبار التغييرات المدمرة، أو إنشاء وحدات جديدة، أو استكشاف تطبيقات بديلة دون مخاطرة.
/best-of-n يشغل نفس المهمة بالتوازي عبر نماذج متعددة، كل منها في مساحة عمل خاصة به، ثم يتيح لك مقارنة النتائج. بالنسبة لمطوري واجهة برمجة التطبيقات، هذا مفيد عندما تريد رؤية كيف يتعامل كل من Claude وGPT-4o وGemini مع تطبيق نقطة نهاية معقد. تختار الأفضل.
الانتقال من السحابة إلى الجهاز المحلي
يمكن للوكلاء الآن التنقل بين البيئات السحابية والمحلية. ابدأ مهمة طويلة الأمد في سحابة Cursor، ثم اسحبها إلى جهازك المحلي لاختبارها مقابل خدماتك الفعلية. أو ادفع جلسة إلى السحابة قبل إغلاق جهاز الكمبيوتر المحمول الخاص بك، بحيث تستمر في العمل طوال الليل.
ما يعنيه ذلك لتطوير واجهات برمجة التطبيقات
لطالما تضمن تطوير واجهة برمجة التطبيقات تبديل سياق أكثر من معظم أعمال البرمجة الأخرى. تتنقل بين مواصفاتك، وعميلك (Apidog)، ومحرر التعليمات البرمجية الخاص بك، والطرفية، وأداة التوثيق الخاصة بك. كل أداة تعرف جزءًا واحدًا من مشروعك.
يبدأ Cursor 3 بمعالجة هذا عن طريق جعل الوكلاء دائمين ومتوازيين، لكن التحسين الأعمق لعمل واجهة برمجة التطبيقات يأتي من طبقة MCP التي يستند إليها.
تطوير نقاط النهاية المتوازية
إذا كنت تقوم ببناء واجهة برمجة تطبيقات REST بعشرة نقاط نهاية، فلن تحتاج بعد الآن إلى بنائها بالتسلسل. يمكنك وصف الغرض من كل نقطة نهاية لوكيل منفصل وترك جميع العشرة تعمل. راجع المخرجات، وادمج تلك التي تجتاز فحوصاتك، وتجاهل البقية.
هذا لا يلغي وقت المراجعة. بل يضغط الوقت بين "أحتاج نقاط النهاية هذه" و "لدي مسودة عمل للمراجعة". بالنسبة للفرق التي تعمل تحت ضغط السرعة، فإن هذا الضغط مهم.
إنشاء كود واعي بالمخطط
عندما لا يتمكن الوكيل من الوصول إلى مواصفات OpenAPI الخاصة بك، فإنه يخمن. قد يحصل على أسماء الحقول بشكل صحيح. ومن المحتمل ألا يحصل على هياكل الكائنات المتداخلة، أو الحقول المطلوبة، أو قيم التعداد بشكل صحيح تمامًا من المحاولة الأولى.
عندما تربط مشروع Apidog الخاص بك بـ Cursor عبر خادم MCP، يسحب الوكيل المخطط الفعلي. يعرف أن نقطة نهاية POST /orders تتطلب سلسلة customerId ومصفوفة items مع حقلي productId و quantity محددين. الكود الذي تم إنشاؤه يعكس ذلك. عدد أقل من التصحيحات.
اختبار العقود داخل المحرر
يمكن لوكلاء Cursor 3 تشغيل أوامر الطرفية كجزء من سير عملهم. ادمج ذلك مع Apidog CLI، وستحصل على مسار للتحقق التلقائي من العقود داخل حلقة المحرر.
تصف سلوك نقطة النهاية بلغة بسيطة. ينشئ الوكيل التنفيذ. يشغل الأمر apidog run --scenario <test-id> مقابل الخادم المحلي الوهمي الخاص بك. إذا فشل الاختبار، يرى الوكيل المخرج ويكرر المحاولة. تشاهد كيف يعمل.
هذا أقرب إلى "مبرمج زوجي بالذكاء الاصطناعي يكتب ويدير الاختبارات أيضًا" من أي شيء متاح في إصدارات Cursor السابقة.
وثائق تبقى محدثة
إحدى المشكلات المستمرة في تطوير واجهة برمجة التطبيقات هي انحراف الوثائق. تتغير نقاط النهاية؛ لكن الوثائق لا تتغير. يمكن لوكلاء Cursor 3 قراءة وثائق Apidog الخاصة بك عبر خادم MCP والإبلاغ عن أي تناقضات بين التعليمات البرمجية الخاصة بك ومواصفاتك كجزء من حلقة المراجعة الخاصة بهم.
هذا ليس تلقائيًا. لا يزال يتعين عليك تكوين سير العمل. لكن اللبنات الأساسية موجودة بطريقة لم تكن موجودة من قبل.
ما لم يتغير
لا يقوم Cursor 3 باختبار واجهات برمجة التطبيقات الخاصة بك تلقائيًا. لا يكتشف أخطاء تكوين المصادقة أو يتحقق من أن منطق تحديد المعدل الخاص بك يعمل تحت الحمل. إنها واجهة وكيل، وليست منصة ضمان جودة. لا تزال بحاجة إلى أدوات مناسبة لتلك المخاوف.
تحسين المخرجات المهيكلة في MCP يعتمد أيضًا على الإصدار. يجب أن يدعم خادم MCP الخاص بك المحتوى المهيكل لكي تعمل المخرجات الأكثر ثراءً. خادم MCP الخاص بـ Apidog يدعم ذلك؛ قد لا تدعمه الخوادم الأخرى بعد.
Cursor 3 + خادم MCP من Apidog: سير عمل محدد
إليك سير عمل ملموس يستخدم ميزات Cursor 3 الجديدة جنبًا إلى جنب مع خادم MCP من Apidog. هذا ليس دليلاً عامًا لـ "استخدام الذكاء الاصطناعي لكتابة التعليمات البرمجية". إنه خاص بكيفية تفاعل الأداتين.
الإعداد
تقوم بتوصيل خادم Apidog MCP بـ Cursor. يعرض الخادم نقاط النهاية والمخططات والبيئات وسيناريوهات الاختبار الخاصة بمشروع Apidog الخاص بك كأدوات يمكن لوكلاء Cursor استدعاؤها. في إعدادات MCP في Cursor، تضيف:
{
"mcpServers": {
"apidog": {
"command": "npx",
"args": ["-y", "@apidog/mcp-server@latest"],
"env": {
"APIDOG_ACCESS_TOKEN": "your_access_token"
}
}
}
}
يأتي رمز الوصول الخاص بك من Apidog ضمن "إعدادات الحساب > رمز وصول واجهة برمجة التطبيقات" (Account Settings > API Access Token). بمجرد الاتصال، يمكن لوكلاء Cursor استدعاء أدوات مثل get_endpoint_detail و list_endpoints و get_schema مقابل مشروعك المباشر.
سير العمل: بناء نقطة نهاية جديدة من المواصفات
لنقل أنك أضفت نقطة نهاية جديدة إلى مواصفات Apidog الخاصة بك: POST /invoices. لقد حددت جسم الطلب، ومخطط الاستجابة، وربطت سيناريو اختبار. الآن تحتاج إلى كتابة التنفيذ.
في نافذة الوكلاء، تفتح جلسة وكيل جديدة وتصف المهمة:
"ابحث عن نقطة نهاية POST /invoices في مشروع Apidog. اقرأ مخططات الطلب والاستجابة الخاصة بها. قم بإنشاء معالج Node.js/Express يطابق المواصفات. ثم قم بتشغيل سيناريو الاختبار للتحقق منه."
الوكيل:
- يستدعي
get_endpoint_detailعبر خادم MCP لجلب المواصفات. - ينشئ كود المعالج بناءً على تعريفات المخطط الفعلية.
- يشغل
apidog run --scenario invoice-creation-test --env stagingفي الطرفية. - يراجع مخرجات الاختبار ويصلح المعالج إذا فشلت التأكيدات.
تقوم بمراجعة الاختلاف النهائي. يتطابق الكود بالفعل مع مواصفاتك لأن الوكيل قرأ المواصفات مباشرةً، وليس وصفًا كتبته يدويًا.
ميزة /best-of-n لنقاط النهاية المعقدة
بالنسبة لنقاط النهاية ذات المنطق التجاري المعقد، استخدم /best-of-n. اترك ثلاثة وكلاء ينشئ كل منهم تطبيقًا، حيث يقرأ كل منهم نفس مواصفات Apidog عبر MCP. قارن التطبيقات في عرض مساحة العمل (worktree view) في Cursor. اختر النهج الذي يتمتع بأفضل معالجة للأخطاء أو أنظف فصل للاهتمامات.
هنا تظهر قيمة مخرجات MCP المهيكلة. يحصل كل وكيل على نفس بيانات المخطط المهيكلة. يأتي الاختلاف في المخرجات من تفكير النموذج، وليس من الاختلافات في كيفية تحليل كل نموذج لكتلة نصية.
الحفاظ على تزامن الوثائق
بعد نشر نقطة النهاية، قم بتشغيل جولة ثانية للوكيل:
"تحقق من وثائق Apidog لنقطة النهاية POST /invoices. قارنها بالتعليمات البرمجية في invoices.js. حدد أي تناقضات. إذا كان شكل الاستجابة في التعليمات البرمجية يختلف عن المواصفات، قم بتحديث مواصفات Apidog لتتطابق."
يقرأ الوكيل كلا المصدرين عبر MCP، يقارنهما، ويقترح تحديثات للمواصفات أو تصحيحات للكود. تقوم بالموافقة أو الرفض. يصبح انحراف الوثائق خطوة في دورة المراجعة، وليس فكرة لاحقة.
يمكنك قراءة المزيد حول كيفية اتصال هذا بخادم MCP من Apidog وكيف يتناسب CLI مع خطوط الأنابيب المؤتمتة.
إعداد عملي: البدء
إليك ما تحتاجه للبدء في استخدام Cursor 3 مع خادم MCP من Apidog.
الخطوة 1: ترقية Cursor
قم بتنزيل أحدث إصدار من cursor.com. بعد التثبيت، افتح لوحة الأوامر (Cmd+Shift+P) وحدد "Agents Window" للتأكد من أنك تستخدم Cursor 3.
الخطوة 2: إنشاء رمز وصول Apidog
سجل الدخول إلى Apidog. انتقل إلى إعدادات الحساب (Account Settings) > رمز وصول API (API Access Token). أنشئ رمزًا جديدًا بإذن قراءة للمشاريع التي ترغب في عرضها. انسخ الرمز؛ ستحتاج إليه في الخطوة التالية.
الخطوة 3: إضافة خادم Apidog MCP إلى Cursor
افتح إعدادات Cursor (Cursor Settings) > MCP. أضف تكوين خادم جديد:
{
"mcpServers": {
"apidog": {
"command": "npx",
"args": ["-y", "@apidog/mcp-server@latest"],
"env": {
"APIDOG_ACCESS_TOKEN": "your_token_here",
"APIDOG_PROJECT_ID": "your_project_id"
}
}
}
}
يظهر معرف مشروعك في عنوان URL الخاص بـ Apidog عند فتح مشروع. احفظ وأعد تشغيل Cursor.
الخطوة 4: التحقق من الاتصال
افتح نافذة الوكلاء. ابدأ جلسة جديدة واكتب: "اذكر نقاط النهاية في مشروع Apidog الخاص بي." إذا أعاد الوكيل قائمة بنقاط النهاية الخاصة بك، فإن الاتصال يعمل.
الخطوة 5: تثبيت وتكوين Apidog CLI
لجزء تنفيذ الاختبار من سير العمل، قم بتثبيت Apidog CLI:
npm install -g apidog-cli
تحقق باستخدام apidog -v. داخل Apidog، افتح أي سيناريو اختبار وانتقل إلى علامة التبويب CI/CD. انسخ أمر CLI الذي تم إنشاؤه مسبقًا، والذي يتضمن بيانات اعتماد مشروعك ومعرف السيناريو. يمكنك تشغيل هذا الأمر مباشرة من الطرفية المدمجة في Cursor، أو جعل وكيل يقوم بتشغيله كجزء من سير عمله.
الخطوة 6: تشغيل أول مهمة وكيل مدعومة بـ MCP
في نافذة الوكلاء، اصف مهمة حقيقية تتطلب معرفة المواصفات. شيء مثل: "ابحث عن مخطط كائن المستخدم (User object) في Apidog. قم بإنشاء واجهة TypeScript تطابقه تمامًا." راجع المخرج مقابل مخططك الفعلي. إذا كان دقيقًا، فإن التكامل يعمل بشكل صحيح.
من هنا، يمكنك بناء سير عمل أكثر تعقيدًا يجمع بين قراءة المواصفات، وتوليد الكود، وتنفيذ الاختبارات في جلسة وكيل واحدة.
الخلاصة
يمثل Cursor 3 تغييرًا كبيرًا في كيفية عملك مع الذكاء الاصطناعي في بيئة التطوير. يتوافق التحول من التصميم المرتكز على المحرر إلى التصميم المرتكز على الوكيل مع الاتجاه الذي يسلكه تطوير واجهات برمجة التطبيقات. أنت لا تكتب دالة واحدة في كل مرة. بل تقوم بتنسيق العمل عبر نقاط نهاية متعددة، وخدمات، وبيئات مختلفة.
إن تحسين مخرجات MCP المهيكلة غير مذكور بشكل كافٍ في سجل التغييرات، ولكنه أحد أكثر التغييرات فائدة لمطوري واجهات برمجة التطبيقات. عندما يتلقى الوكلاء بيانات نظيفة ومحددة النوع من أدوات API الخاصة بك، يكون الكود الذي يولدونه أفضل. تصحيحات أقل، وتراجع أقل.
يمنحك إقران Cursor 3 مع خادم Apidog MCP و CLI سير عمل حيث يعرف وكيل الذكاء الاصطناعي واجهة برمجة التطبيقات الخاصة بك حقًا. يقرأ مواصفاتك، وينشئ كودًا يطابقها، ويشغل سيناريوهات الاختبار الخاصة بك للتحقق. هذا ليس سيناريو عرض توضيحي. إنها حلقة يمكنك استخدامها كل يوم.
الأسئلة المتداولة
هل يحل Cursor 3 محل واجهة بيئة التطوير المتكاملة (IDE) الحالية؟
لا. يضيف Cursor 3 نافذة الوكلاء (Agents Window) كواجهة جديدة. يمكنك العودة إلى بيئة التطوير المتكاملة (IDE) في أي وقت، أو إبقاء كليهما مفتوحين في وقت واحد. لم تتم إزالة أي شيء من الإصدار السابق.
ما الفرق بين Cursor 3 والإصدار السابق من Cursor؟
يكمن الاختلاف الجوهري في البنية. كانت الإصدارات السابقة تركز على المحرر مع وجود الوكلاء كميزة جانبية. يركز Cursor 3 على الوكلاء، مع توفر المحرر عندما تحتاج إلى التعمق في ملفات معينة. كما تضيف نافذة الوكلاء الجديدة التنفيذ المتوازي، وميزة الانتقال من السحابة إلى الجهاز المحلي، ووضع التصميم (Design Mode)، وأوامر /worktree و /best-of-n.
كيف يتصل خادم Apidog MCP بـ Cursor 3؟
تقوم بإضافة خادم Apidog MCP كتكوين MCP في إعدادات Cursor. يعرض الخادم بيانات واجهة برمجة التطبيقات لمشروع Apidog الخاص بك كأدوات قابلة للاستدعاء. يستخدم وكلاء Cursor هذه الأدوات لقراءة مواصفات نقاط النهاية، والمخططات، وسيناريوهات الاختبار دون الحاجة إلى نسخ أي محتوى يدويًا. دعم المحتوى المهيكل في Cursor 3 يعني أن الوكلاء يتلقون تلك البيانات بتنسيق محدد النوع، وليس نصًا عاديًا.
هل يمكن لوكلاء Cursor 3 تشغيل سيناريوهات اختبار Apidog تلقائيًا؟
نعم، عبر Apidog CLI. يمكن للوكلاء تنفيذ أوامر الطرفية كجزء من سير عملهم. إذا قمت بتكوين CLI وتقديم أمر السيناريو الصحيح، يمكن للوكلاء تشغيل سيناريوهات الاختبار الخاصة بك، وقراءة المخرجات، وتعديل الكود الخاص بهم بناءً على حالات الفشل. هذا يخلق حلقة تغذية راجعة محكمة بين توليد الكود والتحقق من عقد واجهة برمجة التطبيقات.
هل أحتاج إلى خطة مدفوعة في Cursor لاستخدام نافذة الوكلاء؟
نافذة الوكلاء (Agents Window) متاحة في Cursor 3 عبر جميع الخطط، ولكن تنفيذ وكيل السحابة (الميزة التي تتيح للوكلاء الاستمرار في العمل أثناء عدم اتصالك بالإنترنت) يتطلب اشتراكًا مدفوعًا. يعمل تنفيذ الوكيل المحلي على الطبقة المجانية. تحقق من cursor.com/pricing للحصول على تفاصيل الخطة الحالية.
