AWS تشغّل Claude Code عن بُعد: microVM مستقلة لكل مهمة

يعالج وكيل البرمجة البعيد مشكلة مألوفة: يكون Claude Code المحلي مفيدًا ما دام الحاسوب المحمول مفتوحًا، وبيئة العمل غير مشغولة، والمهمة لا تتطلب تشغيل الاختبارات لفترة طويلة. تقترح AWS نقل هذه العملية إلى Amazon Bedrock AgentCore. يصوغ المطور المهمة، ويغلق حاسوبه، ثم يحصل لاحقًا على مسودة pull request تتضمن التعديلات ونتيجة التحقق.

المهم هنا ليس مجرد تشغيل Claude في السحابة. تكمن القيمة في المنظومة المتكاملة: بيئة مستقلة لكل مهمة، ووصول مؤقت إلى GitHub، واتصالات خاصة بخدمات AWS، ودور IAM محدود، ومراجعة بشرية إلزامية. يستطيع الوكيل كتابة الكود، لكنه لا يستطيع دمجه بنفسه في الفرع الرئيسي.

كيف تسير المهمة الواحدة

لنفترض وجود خطأ صغير: تعيد API الرمز 500 بدلًا من 404 عندما لا يكون السجل موجودًا. يرسل المطور الوصف عبر إضافة Claude Code أو وحدة تحكم الويب. يُوقَّع الطلب باستخدام بيانات اعتماد AWS، ويفحصه Amazon Bedrock Guardrails، ثم يُحفظ في DynamoDB ويُرسل إلى طابور SQS.

يشغّل الموزّع جلسة مستقلة من AgentCore Runtime. تُنشأ لكل مهمة microVM خاصة بها، مع معالج وذاكرة ونظام ملفات معزولة. وتكون Claude Code CLI وClaude Agent SDK وgit وmake موجودة فيها مسبقًا. يحصل الوكيل على رمز GitHub مؤقت، ويستنسخ المستودع، ويطّلع على الإرشادات المحفوظة من عمليات التشغيل السابقة للمشروع نفسه.

بعد ذلك يضع Claude Opus الخطة، بينما ينفّذ Claude Sonnet التعديلات. يشغّل الوكيل أوامر التثبيت والاختبار التي يحددها المستودع نفسه. ثم يراجع Opus النتيجة، ويعيد العمل إلى دورة جديدة عند الحاجة. يسمح النظام بما يصل إلى ثلاث محاولات إجمالًا. وفي النهاية، ينشئ الوكيل فرعًا بالصيغة agent/<taskId> ويفتح pull request يذكر فيه أمر التحقق، ورمز خروجه، وعدد المحاولات. وإذا لم تنجح الاختبارات، تظل pull request مسودة.

أين يكمن الأمان

لا تحصل الحاوية على مفاتيح AWS دائمة. تمر استدعاءات النماذج عبر Amazon Bedrock باستخدام بيانات اعتماد IAM المؤقتة لبيئة التشغيل. ولا تُثبَّت GitHub App إلا في المستودعات المحددة، بينما يظل الرمز الممنوح للوكيل صالحًا لمدة تصل إلى 8 ساعات. تقتصر الصلاحيات على محتوى المستودع وطلبات pull request، وتُوقَّع الالتزامات باستخدام حساب التطبيق.

الشبكة مقيّدة أيضًا: تعمل البيئة داخل شبكات VPC فرعية خاصة، وتتصل بـ Bedrock وخدمات AWS الأخرى عبر نقاط نهاية خاصة. ويظل الاتصال بالإنترنت ضروريًا للوصول إلى GitHub وسجلات الحزم. في المثال، تُحظر نطاقات مزود النموذج عبر DNS Firewall، لكن AWS تحذّر بصراحة من أن قائمة النطاقات المحظورة لا تتحكم في حركة HTTPS بأكملها. وللاستخدام في بيئة الإنتاج، يلزم تطبيق قائمة سماح على مستوى AWS Network Firewall.

يفحص Guardrails المهمة الأصلية بحثًا عن محاولات الاختراق والطلبات الضارة والأسرار. لكن ملفات المستودع ومخرجات الأوامر لا تمر بهذا الفحص. لذلك تظل التعليمات الضارة المخفية داخل README أو أحد نصوص البناء خطرًا قائمًا. يحمي عزل microVM المهام الأخرى وحاسوب المطور، لكنه لا يحوّل الكود غير الموثوق إلى كود آمن.

ما الذي ينبغي للفريق فعله

يُستحسن البدء بمهام ضيقة النطاق داخل مستودع موثوق: ميزة صغيرة، أو إصلاح خطأ، أو إضافة اختبارات. ويجب أن يتضمن المشروع أوامر setup وtest قابلة لإعادة التنفيذ، مع حماية الفرع الرئيسي بمراجعة إلزامية. أما أعمال الاستكشاف المفتوحة وعمليات إعادة الهيكلة الكبيرة فهي أقل ملاءمة، لأن الوكيل محدود بثلاث محاولات، كما أن التحكم فيه أثناء التنفيذ أصعب من التحكم في جلسة محلية.

هناك تكلفة أيضًا. يستغرق النشر من 15 إلى 25 دقيقة، ويستغرق تسجيل المستودع من 8 إلى 12 دقيقة إضافية. وتُفرض رسوم NAT Gateway ونقاط النهاية الشبكية وWAF وCognito وDNS Firewall ومخازن الصور والسجلات حتى عند عدم وجود مهام نشطة. أما ميزانية بقيمة 200 دولار فلا تفعل سوى إرسال إشعار، ولا توقف الإنفاق.

الخلاصة العملية بسيطة: هذا ليس «Claude Code على خادم بعيد»، بل قالب لمصنع مُدار لإنتاج pull requests. قد يهم الفرق التي تحتاج إلى مهام خلفية متوازية، وسجل تدقيق داخل AWS، وعزل عن حواسيب العمل. لكن ينبغي تشغيله فقط مع حماية الفروع، والتحكم في حركة البيانات الصادرة، ووضع حدود للإنفاق، واتباع قاعدة صارمة: يقترح الوكيل التغييرات، ويقرر الإنسان ما يصل إلى بيئة الإنتاج.