المدوَّنة العربية

رحّل بوتيرة أسرع مع AWS Transform ووكيل البرمجة بالذكاء الاصطناعي

المقدمة

إذا كنت تعمل حاليًا مع وكيل برمجة بالذكاء الاصطناعي، فأنت تدرك حجم ما يمكنه إنجازه. فأدوات مثل Kiro وClaude Code وCursor تقرأ المستودعات البرمجية، وتستنتج من التعليمات البرمجية، وتنفذ مهام متعددة الخطوات من داخل بيئة التطوير المتكاملة (IDE) أو من سطر الأوامر. إنها وكلاء برمجة ممتازون متعددو الأغراض، صُممت للمساعدة في مهام تطوير البرمجيات اليومية. لكن تخطيط عمليات الترحيل وتنفيذها يتطلب معرفة متخصصة تشمل الاكتشاف، وتجميع التطبيقات، وتخطيط موجات الترحيل، وتحويل الشبكات، ونمذجة التكاليف، وهذا تخصص مختلف تماماً.

وهنا يأتي دور AWS Transform. فقد صُممت هذه الخدمة خصيصاً للترحيل والتحديث، وتستند إلى عقدين من خبرة AWS في عمليات الترحيل. وتتولى وكلاؤها المتخصصون استيعاب بيانات الاكتشاف، وإعداد دراسات جدوى قائمة على البيانات، وتجميع التطبيقات، وبناء خطط موجات الترحيل، وتصميم مناطق الأساس (Landing Zones) ونشرها، وتحويل الشبكات، وإعادة استضافة الخوادم ووحدات التخزين. أي أنها تتولى العمل الخاص بالترحيل الذي لم يُصمم وكيل البرمجة للقيام به أصلاً. ويتوفر AWS Transform لعمليات الترحيل بدون أي تكلفة إضافية، مما يجعله خياراً جذاباً لتولي العبء الأكبر في أي عملية ترحيل.

يمكنك استخدام AWS Transform من خلال واجهة الويب الخاصة به، إلا أن هناك خياراً آخر يدمجه مباشرةً في سير عملك الحالي، وهو بروتوكول سياق النموذج (Model Context Protocol – MCP). فعندما تربط AWS Transform بوكيل البرمجة الخاص بك عبر MCP، تحصل على الجمع بين أفضل ما في الأداتين: خبرة AWS Transform في الترحيل، تستدعيها مباشرةً من الوكيل الذي تعمل عليه. ويركز هذا المقال على هذا التكامل عبر MCP: كيف يعمل، وكيف تُعدّه في Kiro أو Claude Code أو Cursor أو غيرها من وكلاء البرمجة بالذكاء الاصطناعي، وكيف تكتب المطالبات (Prompts) لتشغيلهما معاً لتحقيق عملية ترحيل فعّالة.

ما فائدة ربط وكيل البرمجة بـ AWS Transform؟

عندما تربط AWS Transform بوكيل البرمجة عبر MCP، يصبح بإمكان وكيل البرمجة إدارة دورة حياة الترحيل بالكامل. فمن خلال المحادثة، يمكنه إنشاء مساحات العمل (Workspaces) والمهام (Jobs) في AWS Transform، والاستجابة لمهام المراجعة البشرية (Human-in-the-Loop – HITL)، ومتابعة حالة المهام، والتعامل مع المخرجات التي ينشئها AWS Transform. فإلى جانب كل ما يجيده وكيل البرمجة، أصبح الآن قادراً على تنفيذ مهام ترحيل معقدة أيضاً. ويتيح هذا الدمج سير عمل لا يمكن لأي من الأداتين تحقيقه بمفردهما:

  • بناء مسارات عمل مخصصة. اطلب من وكيل البرمجة إطلاق عدة مهام ترحيل؛ فينتظر تقدم كل منها، ويقرأ مخرجاتها، ثم يجمعها في مجموعة واحدة من المخرجات، وكل ذلك في جلسة واحدة.
  • تعزيز مرحلة الاكتشاف. يستطيع وكيل البرمجة قراءة مستودعاتك المحلية وملفات قواعد العمل وملاحظاتك، ثم يُدخل هذا السياق في مطالبات AWS Transform، بحيث تعكس مجموعات التطبيقات وتصنيفات استراتيجيات الترحيل (R-Strategies) واقع بيئتك الفعلي.
  • العمل من مكان واحد. يمكنك مراجعة الخطط، واعتماد خطوات المراجعة البشرية، وتحسين خطة موجات الترحيل، كل ذلك في المحادثة نفسها التي تكتب فيها التعليمات البرمجية، بدون الحاجة إلى التنقل بين الأدوات.
  • الأتمتة والتحقق. يمكنك بناء حلقات تحقق تفحص المخرجات مقابل معايير النجاح الخاصة بك، فتعيد تشغيل الخطوة عندما يبدو أمر ما غير صحيح، وتنبّهك إلى أي شيء يحتاج إلى مراجعتك. تحدد معيار الإنجاز مرة واحدة، ويتولى الوكيل المتابعة نيابةً عنك، فلا تحتاج إلى مراقبة المهام طويلة التشغيل بنفسك.
  • كفاءة التكلفة. تُحسب تكلفة وكلاء البرمجة بالذكاء الاصطناعي بحسب الرموز (Tokens)، أي أن لكل أمر واستجابة تكلفة. ولا يُضاف AWS Transform إلى هذه الفاتورة: فخدمة AWS Transform لعمليات الترحيل مجانية، أما التحويلات المخصصة في AWS Transform (Custom Transformations) فتُحتسب فقط على دقائق عمل الوكيل الفعلية أثناء التخطيط أو التحليل أو تعديل التعليمات البرمجية، ولا يُحتسب الوقت المستغرق في انتظار العمليات المحلية مثل الترجمة البرمجية (Compilation) والاختبارات. ومن خلال إسناد الجزء الأكبر من عمل الترحيل إلى AWS Transform، تضمن تركيز استهلاك الرموز في وكيل البرمجة على ما يضيف أكبر قيمة.

المتطلبات الأساسية

لاستخدام خادم MCP الخاص بـ AWS Transform مع وكيل برمجة بالذكاء الاصطناعي، ستحتاج إلى ما يلي:

  • وكيل برمجة. وإن لم يكن لديك وكيل، فنوصي باستخدام Kiro.
  • تثبيت Python الإصدار 3.10 أو أحدث.
  • تثبيت مدير حزم Python من Astral، UV/UVX.
  • حساب AWS تم فيه إعداد AWS Transform باستخدام تسجيل الدخول الموحد (SSO).

اختر طريقة الإعداد المناسبة

هناك أربع طرق للربط. ابدأ بالخيار الجاهز المخصص لوكيل البرمجة الذي تستخدمه. وإذا لم يتوفر تثبيت مخصص لوكيلك، فراجع وثائقه لمعرفة كيفية إضافة خوادم MCP، ثم استخدم الخيار الرابع. وتعتمد جميع الخيارات على تثبيت خادم MCP نفسه الخاص بـ AWS Transform واستخدامه، وهو خادم يعمل محلياً ويتصل بحساب AWS الخاص بك. وأنت من يتحكم في الهوية والصلاحيات التي يستخدمها الخادم، ولديك تحكم كامل فيما يمكنه الوصول إليه.

  1. Kiro

    ثبّت AWS Transform Kiro Power. حيث يمنحك وصولاً كاملاً إلى وكلاء AWS Transform من داخل بيئة Kiro، ويثبّت خادم MCP نيابةً عنك. من لوحة Powers، ابحث عن AWS Transform وثبّته، ثم افتح Kiro Chat، واختر الـ Power، ثم اختر Try power.

  2. إضافة الوكيل (Agent Plugin) لـ Claude Code وCodex وCursor

    ثبّت إضافة وكيل AWS Transform (AWS Transform agent plugin) من awslabs/agent-plugins. وتتضمن الإضافة ملفات الإعداد .claude-plugin و.codex-plugin و.mcp.json.

  3. إضافة بيئة التطوير (IDE Plugin) لـ VS Code وOpen VSX

  4. أي عميل متوافق مع MCP

ثبّت خادم MCP من PyPI باسم awslabs.aws-transform-mcp-server. ولا تستخدم هذه الطريقة إلا إذا كنت تريد الخادم دون Kiro Power أو إضافة وكيل.

بعد الانتهاء من الإعداد، أعد تشغيل العميل، ثم تحقق من الاتصال بسؤال مساعدك: “Check my AWS Transform connection status” (تحقق من حالة اتصالي بـ AWS Transform). سيفحص المساعد الاتصال بالخادم ويُعلمك بإصداره وحالة المصادقة.

المصادقة

اطلب من مساعدك: “Configure AWS Transform with SSO.” (اضبط AWS Transform باستخدام تسجيل الدخول الموحد SSO) سيطلب منك تحديد منطقة AWS ورابط البدء الخاص بـ IAM Identity Center (مثل https://d-1234567890.awsapps.com/start). ثم يفتح متصفحاً لتسجيل الدخول، ويحفظ بيانات الاعتماد محلياً، بحيث تُحمَّل الرموز المميزة مجدداً عند إعادة التشغيل.

تستخدم بعض عمليات مستوى التحكم (Control Plane)، مثل ربط دور IAM بموصّل (Connector)، بيانات اعتماد AWS القياسية. ويقرأ الخادم هذه البيانات تلقائياً من بيئتك (~/.aws/config). وإذا كنت تستخدم أكثر من ملف تعريف (Profile)، فاضبط المتغير AWS_PROFILE في إعدادات العميل لاختيار الملف الصحيح.

ابدأ أول سير عمل للترحيل

بعد ربط MCP وإتمام المصادقة، يمكنك البدء باستخدام AWS Transform مباشرةً من وكيل البرمجة. والمفهومان الأساسيان هنا هما مساحات العمل والمهام. فمساحة العمل حاوية منطقية لمهمة ترحيل واحدة أو أكثر، تمنحك مكاناً واحداً لإدارة عملية الترحيل بأكملها. وداخل مساحة العمل، تُنشئ مهام لأغراض محددة مثل التقييم أو تخطيط موجات الترحيل أو الترحيل الشامل من البداية إلى النهاية.

عرض مساحات العمل الحالية. إذا كان فريقك قد بدأ باستخدام AWS Transform، فاطلب من وكيل البرمجة:

List my AWS Transform workspaces

"اعرض مساحات العمل الخاصة بي في AWS Transform."

يستدعي الوكيل خادم MCP ويعرض لك مساحات العمل المتاحة، إلى جانب حالتها وأي مهام نشطة فيها.

إنشاء مساحة عمل جديدة. للبدء من الصفر:

Create a new AWS Transform workspace called data-center-exit-2026

"أنشئ مساحة عمل جديدة في AWS Transform باسم data-center-exit-2026."

يُنشئ الوكيل مساحة العمل ويعرض لك تأكيداً يتضمن معرّفها، ومن هنا يمكنك إطلاق مهام الترحيل داخلها.

عرض أنواع المهام المتاحة. قبل إطلاق أي مهمة، يمكنك الاطلاع على الأنواع المتاحة:

What job types can I run in AWS Transform

"ما أنواع المهام التي يمكنني تشغيلها في AWS Transform؟"

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

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

In the data-center-exit-2026 workspace, start a migration assessment

"في مساحة العمل data-center-exit-2026، ابدأ تقييماً للترحيل."

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

أفضل ممارسات كتابة المطالبات المُعتمَدة

تنطبق هذه العادات على أي وكيل ذكاء اصطناعي، ومن المهم مراعاتها أيضاً عندما يتولى وكيل البرمجة تنسيق العمل مع AWS Transform. فباتباع هذه الإرشادات، يمكنك كتابة مطالبات تساعد على تحقيق أفضل النتائج من وكيل البرمجة ومن AWS Transform معاً.

  1. ابدأ بالمُخرَج المطلوب. حدّد أولاً ما تريده: دراسة جدوى، أو خطة موجات، أو CDK لشبكتك، أو تقرير حالة الترحيل. فهذا يوجه الاستجابة نحو المُخرَج المنظم الأكثر صلة، بدلاً من محادثة مفتوحة.
  2. كن محدداً، وقل ما تريده لا ما تريد تجنبه. عبارة “اعرض خوادمي حسب نظام التشغيل وأشِر إلى أي خادم يعمل بنظام تشغيل غير مدعوم” أفضل من “حلّل خوادمي”. كما أن عبارة “ضع التطبيقات منخفضة المخاطر في موجة الترحيل الأولى” أفضل من “لا تجعل موجة الترحيل الأولى محفوفة بالمخاطر”. صِف النتيجة التي تريدها بعبارات واضحة.
  3. حدّد مدخلاتك. أخبر الوكيل بالملف وصيغته وأي سياق إضافي: ملاحظات، أو قائمة تطبيقات موجودة، أو ملفات قواعد العمل في المستودع. إذ يستطيع وكيل البرمجة قراءة هذا السياق محلياً وتمريره إلى AWS Transform.
  4. حدّد شكل المُخرَج مسبقاً. قرر مبكراً ما إذا كنت تريد تقريراً، أو لوحة معلومات، أو تصدير بيانات، أو مجموعة من الأقسام، ثم وضّح كيف ينبغي تنظيمه.
  5. اذكر قيودك كضوابط. الجداول الزمنية، والحد الأقصى لعدد الخوادم في كل موجة، وقواعد التراجع (Rollback)، وافتراضات الترخيص، كلها قيود ينبغي ذكرها. فإن لم تذكرها، سيملأ الوكيل الفراغات بافتراضاته الخاصة.
  6. رتّب الخطوات للعمل متعدد المراحل. عندما يمتد الطلب عبر عدة مراحل، وضّح المسار حتى لا يتخطى الوكيل أي خطوة: “حدّد النطاق وحلّله أولاً، ثم جمّع التطبيقات، ثم أنشئ مجموعات النقل (Move Groups)، ثم ابنِ موجات الترحيل واعرض الأدلة وراء كل تجميع”.
  7. اطلب الأدلة وتحقق منها. اطلب البيانات التي يستند إليها كل استنتاج: أعداد الخوادم، أو قوائم التبعيات (Dependencies)، أو القاعدة التي أدت إلى قرار ما. فهذا يساعدك على اكتشاف أي خلل مبكراً. ويستطيع AWS Transform تتبع قرارات التخطيط وصولاً إلى البيانات التي رفعتها بنفسك.
  8. كرّر وحسّن. ابدأ ببساطة، ثم راجع وحسّن. فكل تغيير يحدّث الخطة أو دراسة الجدوى مباشرةً، لذا فإن تحسين مدخلاتك لا يكلفك الكثير.

أمثلة على المطالبات للبدء

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

إطلاق تقييم بمُخرَج منظم:

Using AWS Transform, start a migration assessment. For the inventory, use the RVTools export files located in ./discovery/ folder. Target Region us-east-1, Savings Plans pricing, SQL Server licensing as License Included. When the business case is ready, return three sections: compute recommendations, licensing scenarios, and on-prem vs AWS cost comparison

"باستخدام AWS Transform، ابدأ تقييماً للترحيل. لبيانات الجرد، استخدم ملفات تصدير RVTools الموجودة في المجلد ./discovery/. المنطقة المستهدفة us-east-1، والتسعير وفق Savings Plans، وترخيص SQL Server بنموذج الترخيص المضمّن (License Included). وعندما تصبح دراسة الجدوى جاهزة، أعِد ثلاثة أقسام: توصيات الحوسبة، وسيناريوهات الترخيص، ومقارنة التكلفة بين البيئة المحلية وAWS."

تحسين التقييم عبر المحادثة:

Ask AWS Transform to add my hidden on-premises costs, colocation rent and networking spend, then switch SQL Server licensing to Bring Your Own License and show me what changed in the business case

"اطلب من AWS Transform إضافة التكاليف المحلية غير الظاهرة، وهي إيجار مراكز الاستضافة المشتركة (Colocation) ونفقات الشبكات، ثم حوّل ترخيص SQL Server إلى نموذج استخدام الترخيص الخاص بك (Bring Your Own License)، واعرض لي ما تغيّر في دراسة الجدوى."

تجميع التطبيقات وفق قواعدك الخاصة وسياق المستودع:

Read business_rules.txt and naming-conventions.md from this repo. Instruct AWS Transform to group servers into applications using our environment codes (PRD, DEV, UAT) and those business rules, then show me the application catalog with the evidence for each grouping

"اقرأ الملفين business_rules.txt وnaming-conventions.md من هذا المستودع. ثم وجّه AWS Transform لتجميع الخوادم في تطبيقات باستخدام رموز البيئات لدينا (PRD وDEV وUAT) وقواعد العمل تلك، واعرض لي كتالوج التطبيقات مع الأدلة التي يستند إليها كل تجميع."

بناء موجات الترحيل بقيود وتسلسل واضحين:

Have AWS Transform build a wave plan for a phased data-center exit. Put low-risk, low-complexity applications in the early waves and hold business-critical, high-complexity ones for later. Cap each wave at a manageable number of servers, and keep each application's production and non-production environments together. Then recommend 7Rs strategies before I assign them

"اطلب من AWS Transform بناء خطة موجات الترحيل للخروج التدريجي من مركز البيانات. ضع التطبيقات منخفضة المخاطر والتعقيد في الموجات الأولى، وأجّل التطبيقات الحيوية للأعمال عالية التعقيد إلى مراحل لاحقة. حدّد لكل موجة عدداً من الخوادم يمكن إدارته، وأبقِ بيئات الإنتاج وغير الإنتاج لكل تطبيق معاً. ثم أوصِ باستراتيجيات 7Rs قبل أن أعتمدها"

الحفاظ على الإشراف البشري:

Show me the pending AWS Transform approval task and its details. Don't submit a response, wait for my decision

"اعرض لي المهمة التي تحتاج موافقتي في AWS Transform وتفاصيلها. لا ترسل أي رد، وانتظر قراري."

افتراضياً، تتوقف كل خطوة من خطوات المراجعة البشرية وتنتظر الموافقة البشرية. غير أن المستخدم قد يضبط وكيل البرمجة للموافقة على هذه الخطوات تلقائياً. ويتجاوز الأمر أعلاه سلوك الموافقة التلقائية، ليضمن أن يعرض الوكيل المهمة والمُخرَج المرتبط بها دائماً لمراجعتك قبل أن توافق عليها أو ترفضها أو تصعّدها.

تشغيل التسلسل الكامل مع اشتراط الأدلة:

Use my migration job. Run this in order and pause for my review between stages: 1) scope and analyze the inventory and exclude anything on an unsupported OS; 2) group applications; 3) generate move groups from technical and business dependencies; 4) build and prioritize waves. Provide the evidence behind each grouping decision

"استخدم مهمة الترحيل الخاصة بي. نفّذ ما يلي بالترتيب وتوقف لمراجعتي بين المراحل: 1) حدّد نطاق الجرد وحلّله واستبعد أي خادم يعمل بنظام تشغيل غير مدعوم؛ 2) جمّع التطبيقات؛ 3) أنشئ مجموعات النقل بناءً على التبعيات (Dependencies) التقنية والتشغيلية؛ 4) ابنِ موجات الترحيل ورتّبها حسب الأولوية. وقدّم الأدلة التي يستند إليها كل قرار تجميع."

أتمتة عملية المتابعة والتحقق:

Start the wave-planning job, then poll it to completion. Check the status periodically and wait while it's still running. When it finishes, verify the result against these criteria: every in-scope server is assigned to exactly one wave, no wave exceeds 50 servers, and each application's production and non-production environments stay together. If any check fails, tell AWS Transform what's wrong, re-run that step, and re-check. Stop and summarize once all checks pass or flag anything you can't resolve for my review

"ابدأ مهمة تخطيط موجات الترحيل، ثم تابعها حتى تكتمل. تحقق من الحالة دورياً وانتظر ما دامت قيد التشغيل. وعند انتهائها، تحقق من النتيجة وفق المعايير التالية: أن يُخصَّص كل خادم ضمن النطاق لموجة واحدة فقط، وألا تتجاوز أي موجة 50 خادماً، وأن تبقى بيئات الإنتاج وغير الإنتاج لكل تطبيق معاً. وإذا فشل أي فحص، فأبلغ AWS Transform بالخطأ، وأعد تشغيل تلك الخطوة، ثم أعد الفحص. توقف وقدّم ملخصاً عند اجتياز جميع الفحوصات، أو أشِر إلى أي مشكلة لا يمكنك حلها لأراجعها."

وهنا يتجلى أفضل ما في الجمع بين الوكيلين. فـ AWS Transform يتولى التخطيط المتخصص، بينما يتولى وكيل البرمجة العملية: بدء المهمة، ومتابعتها حتى تكتمل، واختبار المُخرَج مقابل معايير النجاح الخاصة بك، والتكرار حتى تصبح الخطة صحيحة. تحدد المعيار مرة واحدة، ويلتزم الوكيل به في العمل.

وعندما تنتهي المهام، دع وكيل البرمجة يجمع المخرجات معاً:

Download the assessment and wave-plan artifacts from AWS Transform and combine them into one migration report, broken out by application, with a cost comparison and target-state architecture for each

"نزّل مخرجات التقييم وخطة موجات الترحيل من AWS Transform، وادمجها في تقرير ترحيل واحد مقسّم حسب التطبيق، يتضمن مقارنة للتكاليف وبنية الحالة المستهدفة لكل تطبيق."

الخلاصة

يعالج كل من وكلاء البرمجة وAWS Transform جوانب مختلفة من تحدي الترحيل، ومعاً يغطيان الصورة الكاملة. فوكيل البرمجة يوفر السياق والمنطق المخصص والأتمتة، بينما يوفر AWS Transform خبرة 20 عاماً في الترحيل، من تجميع التطبيقات وتسلسل موجات الترحيل إلى تصميم مناطق الأساس وتحديث التعليمات البرمجية. فهو يتولى التخطيط المتخصص حتى لا يضطر وكيل البرمجة إلى ذلك. وبروتوكول MCP هو ما يربط بينهما، وقد أوضح لك هذا المقال كيفية ذلك.

لمعرفة المزيد، راجع أدوات المطورين في AWS Transform ضمن دليل مستخدم AWS Transform، وكذلك خادم MCP الخاص بـ AWS Transform على GitHub.

اختر طريقة التثبيت المناسبة لك، واسأل وكيل البرمجة عمّا يمكن أن يقدمه AWS Transform لعملية الترحيل الخاصة بك. فهذا الربط البسيط يفتح لك خبرة الترحيل بسرعة كتابة أمر واحد.

بتصرف عن المقالة الأصلية

ملاحظة: يمكنك كتابة مطالباتك باللغة العربية أيضاً. فوكيل البرمجة هو من يفهم المطالبة ويحوّلها إلى طلبات لخادم MCP الخاص بـ AWS Transform. ويعتمد دعم اللغة العربية على النموذج (LLM) الذي يعمل عليه وكيلك، وأغلب النماذج الحديثة تدعمها.