Cursor تطلق Agent SDK: وكلاء بالكود ونشر بأمر واحد

فتحت Cursor أداة Agent SDK للجميع، وهي الإطار الداخلي الذي تبني عليه الشركة وكلاءها المُدارين: Bugbot وSecurity Reviewer وRollouts. الفكرة بسيطة: يُوصَف الوكيل بالكود ويُحفَظ في المستودع، ويخضع للمراجعة كأي برنامج آخر، وينتقل إلى بيئة الإنتاج بالأمر agent-sdk deploy. وقد بلغت الأداة بالفعل حالة الإتاحة العامة (general availability).

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

الوكيل كمشروع برمجي صغير

تشبه بنية الوكيل مستودعًا برمجيًا عاديًا. تُكتب التعليمات بلغة Markdown، وتُعرَّف الأدوات كدوال بلغة TypeScript، وإلى جانبها الاتصالات بالخدمات الخارجية وملفات evals التي تُختبَر بها جودة الوكيل. ويتولى كل ملف جانبًا مما يعرفه الوكيل أو يستطيع فعله.

ومن هنا تأتي أهم نتيجة عملية: التغييرات في سلوك الوكيل تمر عبر pull request نفسه، وسجل الـ commits نفسه، والمراجعة نفسها التي يمر بها بقية الكود. وبإمكان الفريق قراءة السياسات التي يعمل الوكيل وفقها وتعديلها، بدل أن يخمّن ما يجري داخل صندوق أسود يملكه طرف آخر.

يشغل التعريف الأساسي للوكيل بضعة أسطر. ففي المثال الوارد في التوثيق يُستدعى defineAgent من الحزمة @cursor/agent-sdk، ويُحدَّد الاسم Robo، والنموذج composer-2.5 بالمعاملين effort: high وfast: true، إضافةً إلى مجلد عمل محلي. بعد ذلك يمكن التطوير تدريجيًا في playground محلي، وتشغيل evals، ثم النشر لاحقًا فقط.

الاستجابة للأحداث والعمل بفريق من الوكلاء

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

داخل Cursor، راكم أحد الفرق قاعدة معرفية كبيرة تنمو بسرعة، تضم دروسًا من قرارات سابقة، وأراد أن يُفحَص كل PR للتأكد من توافقه معها. وعلى Agent SDK بنى الفريق kb-reviewer في يوم واحد تقريبًا. يعمل الوكيل على كل PR في قاعدة الأكواد الرئيسية، ويشير إلى التغييرات المخالفة لدرس مدوَّن، ويحيل إلى الملاحظة التي تقف خلف كل تعليق، ويدفع المهندسين إلى معالجة أوجه التعارض.

وفي المهام المعقدة، يمكن للوكيل أن يسلّم العمل إلى وكيل متخصص آخر له أدواته وجلساته الخاصة، أو أن يقسّم المهمة بين وكلاء فرعيين يعملون بالتوازي. أما evals وإعادة تشغيل الأحداث (event replay) فمدمجان في الأداة أصلًا، ما يتيح اختبار السيناريوهات الحرجة قبل النشر.

النشر والعملاء الأوائل

يجمع الأمر agent-sdk deploy، عند تنفيذه من مجلد المشروع، الوكيل ويمنحه عنوان URL ويشغّله على بنية Cursor التحتية. وتُضبَط الأسرار والتكاملات في لوحة التحكم (dashboard)، بينما تعمل السجلات وevals وplayground بالطريقة نفسها التي تعمل بها محليًا. وثمة بديل هو تشغيل الوكيل لديك: فكل وكيل عملية Node واحدة، ويمكن تغليفه في حاوية.

وأول عميل بارز ذُكر هو PGA Tour. فبحسب مايكل غيارماتهي، كبير المهندسين في PGA America، بنى الفريق جميع مكونات مصنعه لتطوير البرمجيات على بنية Cursor التحتية، وتتيح evals المدمجة اختبار الأفكار الجديدة بسرعة وتحسين الإمكانات القائمة بثقة.

ماذا يتضمن الإصدار

• إطار لوصف الوكلاء بالكود: الـ prompts في Markdown والأدوات في TypeScript
• قوالب للبدء ومهارات (skills) ترشد وكيل البرمجة خلال عملية التطوير
• مشغّلات (triggers) لأحداث GitHub وGitLab وBitbucket
• تسليم المهام بين وكلاء متخصصين ووكلاء فرعيين يعملون بالتوازي
• evals وevent replay مدمجان
• playground محلي ونشر على بنية Cursor التحتية بالأمر agent-sdk deploy
• لوحة تحكم للأسرار والتكاملات والسجلات
• التشغيل على بنية تحتية خاصة: عملية Node واحدة، وحاوية

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

أما بالنسبة إلى الفرق التي تؤتمت بالفعل المراجعة والامتثال (compliance) وتحليل الحوادث، فالخلاصة العملية هي: ابدأوا بعملية واحدة متكررة ذات قواعد واضحة، مثل فحص PR وفق قاعدة معرفية داخلية، كما فعل kb-reviewer. أنشئوا evals قبل أول نشر، واحفظوا الوكيل في المستودع الرئيسي، وقرروا مسبقًا هل تحتاجون إلى استضافة Cursor أم إلى حاوية خاصة بكم. عندها يصبح الوكيل جزءًا قابلًا للإدارة من المنظومة، مثل بقية الكود.