فتحت AWS مشروع Kiro Crew. وأبقت الـ Harness مغلقا.

هل Kiro Crew مفتوح المصدر؟ نعم، فعلا، وبقدر أكبر مما توقعت. هل الجزء الذي يجعله مفيدا مفتوح المصدر أيضا؟ هذا سؤال مختلف، وإجابته هي موضع الجزء الأكثر إثارة للاهتمام في هذا الإطلاق.

في 4 أغسطس، أطلقت AWS مشروع Kiro Crew، وهو مساحة عمل وكيلية دائمة تبقي وكلاء البرمجة قيد التشغيل عبر الجلسات والجداول الزمنية وواجهات المراسلة، تحت ترخيص Apache 2.0. بدأ المشروع داخل Amazon كمشروع جانبي اسمه MeshClaw، وانتشر إلى أكثر من 39,000 مطور داخلي في أقل من ستة أشهر، وأصبح الآن في مستودع عام بنموذج حوكمة مفتوح. قرأت الإعلان والمستودع والترخيص، وقضيت وقتا في مطابقة ما هو موجود فعلا داخل المستودع مع ما لا يزال المنتج يحتاجه من AWS حتى يعمل. هذا الحد مرسوم عمدا، ويستحق الفهم قبل أن تبني على أي جانب منه.

الخلاصات الرئيسية - Kiro Crew مساحة عمل وكيلية دائمة من AWS، أصدرت كمشروع مفتوح المصدر تحت Apache 2.0 في 4 أغسطس 2026. بدأت كمشروع جانبي داخلي في Amazon باسم MeshClaw واستخدمها أكثر من 39,000 مطور قبل الإطلاق العام. - ما هو مفتوح: الـ Gateway، بما يشمل الجلسات والذاكرة والجدولة والموافقات وسياسات الأمن، ولوحة التحكم، وCLI، وتطبيق سطح المكتب، وApps وApp SDK، والـ skills، وكامل حزمة الأمن. يمكنك قراءة كل ذلك وعمل fork له واستضافته بنفسك. - ما يبقى مغلقا: Kiro CLI، وهو محرك الوكلاء الذي يديره Crew عبر Agent Client Protocol، إلى جانب تسجيل الدخول إلى Kiro، وتوجيه النماذج، وفوترة الاعتمادات. موفر الوكلاء في Crew ثابت على ACP وkiro-cli، لذلك يظل كل استدعاء للنموذج يمر عبر منتج AWS التجاري. - هذا vendor harness مفتوح جزئيا، وليس agent runtime مفتوحا. قارن ذلك بـ TrueForge، الذي فتح الـ harness نفسه تحت MIT ويتعامل مع أي نموذج على أنه endpoint آخر. - التصميم يظل مفيدا. الحالة المستضافة ذاتيا، والذاكرة المرئية، ونموذج الأمن الجاد فوائد حقيقية. فقط كن واضحا تماما بشأن الطبقة التي تلتزم بها.

ما الذي حدث

في 4 أغسطس 2026، نشرت AWS إعلان Kiro Crew وفتحت مستودع kirodotdev/KiroCrew تحت Apache 2.0. ظهرت التغطية في الأسبوع نفسه على SiliconANGLE وDevOps.com، وكان المستودع عند مراجعتي له يقترب من 3,400 نجمة و400 fork. الحقائق الأساسية:

• Kiro Crew مساحة عمل دائمة لوكلاء التطوير: مهام متعددة الخطوات تعمل دون إشراف، ووظائف دورية وفق جدول، وheartbeats تراقب PR أو deployment حتى يحتاج شيء إلى تدخل، ووكلاء فرعيون يتوزعون بالتوازي ثم يعودون بالنتائج.

• يعمل حيث تضعه: كتطبيق سطح مكتب، أو تثبيت بسطر واحد، أو صورة Docker على GHCR، أو مضيف Linux بعيد تتحكم به. الحالة، بما في ذلك الجلسات والذاكرة وcheckpoints، تعيش على أجهزتك تحت ~/.kiro/crew، وليس داخل control plane تابع لـ AWS.

• يصل العمل إليه عبر لوحة تحكم ويب، أو CLI، أو تطبيق سطح مكتب، أو واجهات المراسلة: Slack وDiscord وTelegram وTeams وWebex وWeCom وWeChat وWhatsApp.

• نشأ من MeshClaw، وهو مشروع جانبي داخلي في Amazon مستوحى من OpenClaw. يقول الإعلان إنه وصل إلى أكثر من 39,000 مطور داخلي، مع ما يقارب 500 مساهم أرسلوا قرابة 600 تحديث قبل الإصدار العام.

• الحوكمة عامة: لجنة توجيه مدرجة في MAINTAINERS.md، ومقترحات تقدم وتناقش على شكل pull requests. في الوقت الحالي، المشرفون مهندسون من Kiro وAWS، مع نية معلنة لإضافة مشرفين من خارج الشركة مع ظهور مساهمين موثوقين.

Kiro Crew مساحة عمل وكيلية دائمة مفتوحة المصدر تحت Apache 2.0 أطلقتها AWS في 4 أغسطس 2026. تشغل مهاما متعددة الخطوات دون إشراف، ووظائف مجدولة، وheartbeats، ووكلاء فرعيين، مع استضافة ذاتية على أجهزة المستخدم، وفقا لـ إعلان AWS ومستودع المشروع.

أي الطبقات مفتوحة وأيها ليست كذلك

هذا هو الجزء الذي تجاوزته معظم التغطية، لذلك ذهبت إلى المستودع بنفسي. تتكون البنية من ثلاثة مستويات: الواجهات التي تتعامل معها، مثل لوحة التحكم وسطح المكتب وCLI والمراسلة، ثم الـ Gateway الذي يحتفظ بالحالة، مثل الجلسات والذاكرة والجداول والموافقات وسياسة الأمن، ثم جلسات الوكلاء التي تشغل حلقة النموذج فعليا. وهنا يقع حد الترخيص:

الخط الحامل للمنظومة موجود في وثائق الإعداد: agent.provider ثابت على acp، وKiro Crew يقود kiro-cli عبر Agent Client Protocol. كل طلب إلى نموذج يعالجه kiro-cli تحت حساب Kiro الخاص بك وإعدادات النماذج فيه. مساحة العمل، والذاكرة، والجداول، والوضع الأمني: كلها لك، ويمكن عمل fork لها والتحقق منها. المحرك الذي يستدل، والفوترة التي تقيسه: لـ AWS.

الـ Gateway والواجهات وApps وطبقات الأمن في Kiro Crew مفتوحة المصدر تحت Apache 2.0 داخل مستودع KiroCrew، لكن محرك الوكلاء الموجود تحتها، kiro-cli، يبقى منتجا مغلقا من AWS. موفر الوكلاء في Crew ثابت على ACP عبر kiro-cli، ولذلك يظل الوصول إلى النماذج وتسجيل الدخول وفوترة الاعتمادات تحت سيطرة AWS.

لماذا يقع الحد هناك بالضبط

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

أعط مساحة العمل مجانا، واحتفظ بالمحرك والعداد. هذه هي الصفقة نفسها في كثير من البنية التحتية مفتوحة المصدر المعقولة، وAWS صريحة بشأنها: يقول الإعلان إن Crew يعمل على Kiro CLI ويقرأ إعداد .kiro الموجود لديك مباشرة. إذا كنت تعيش أصلا داخل Kiro، فـ Crew هدية. ملفات steering والـ skills والوكلاء المخصصون تنتقل معك، ويحصل وكلاؤك على الاستمرارية والجدولة ونحو اثنتي عشرة واجهة مراسلة مجانا. وجود 39,000 مستخدم داخلي دليل على أن هذا الشكل يعمل على نطاق واسع، وليس مجرد عبارة تسويقية.

لكن لاحظ ما الذي تمنحه هذه الانفتاحية لـ AWS. كل تثبيت لـ Crew هو أيضا تثبيت لـ Kiro، لأن التشغيل الأول يثبت kiro-cli ويعد تسجيل الدخول عبر device code. كل دورة للوكيل تقاس باعتمادات Kiro على النماذج التي يوجه Kiro إليها، وتوجيه Kiro يعمل عبر Claude والنماذج الصينية المفتوحة Qwen وDeepSeek وGLM وMiniMax على Bedrock. أحد المستخدمين الأوائل استهلك 5,000 اعتماد في أسبوع على مشروعات شخصية، وهذا يخبرك بما تفعله مساحة عمل وكلاء تعمل دائما بخطة نماذج محسوبة الاستخدام. الطبقة المفتوحة توسع القمع التجاري للطبقة المغلقة، والطبقة المغلقة هي موضع الإيراد. لا شيء من ذلك مخفي، ولا شيء منه شرير. فقط يستحق أن يرى بوضوح، لأن الأسبوع نفسه جاء بـ بديل مفتوح بالكامل رسم الحد في مكان مختلف.

هناك شيء آخر داخل الطبقة المفتوحة يستحق التقدير. نموذج الأمن يطبق عند حد الـ runtime وليس داخل prompts: sandboxing على مستوى نظام التشغيل في Linux وmacOS، وأوامر مرفوضة افتراضيا، وحجب بيانات الاعتماد، ونهج fail-closed على Windows حيث ترفض subprocesses الخاصة بالوكيل بدلا من تشغيلها دون قيود ما لم توافق صراحة. ولأن كل ذلك موجود في المستودع، يمكنك التحقق من كل طبقة بدلا من الوثوق بصفحة البائع. هذه أقوى حجة على أن الجزء المفتوح حقيقي وليس مجرد عرض.

مساحة العمل المفتوحة في Kiro Crew توجه المستخدمين إلى محرك Kiro المغلق والمحسوب: كل تثبيت يعد kiro-cli وتسجيل الدخول إلى Kiro، وكل دورة للوكيل تحسب على اعتمادات Kiro. حزمة الأمن، بما فيها OS sandbox والأوامر المرفوضة افتراضيا وحجب بيانات الاعتماد وسجلات التدقيق، مفتوحة فعلا وقابلة للتدقيق في المستودع.

المقارنة مع TrueForge

بعد أسبوعين من Kiro Crew، أصدرت TrueFoundry مشروع TrueForge تحت MIT، ويشكل الاثنان تجربة طبيعية واضحة بشأن مقدار ما يمكن أن يقدمه البائع من agent stack.

TrueForge فتح الـ harness نفسه: الحلقة المحيطة بالنموذج، والجلسات، وsandboxing، والموافقات، وإدارة السياق. يمكن توصيل أي endpoint متوافق مع OpenAI، بحيث يمكن لأرخص نموذج ينجز المهمة أن يحصل على workload، بينما تقع الطبقة التجارية تحته كبوابة اختيارية يمكنك عدم استخدامها. Kiro Crew فتح كل ما حول الـ harness: الاستمرارية والجدولة والواجهات وسياسة الأمن. أما الـ harness نفسه، kiro-cli، فظل مغلقا، والـ model plane خلفه هو المنتج.

لا أحد منهما غير صادق، لكنهما التزامان مختلفان ويفشلان بطرق مختلفة. إذا عملت fork لـ TrueForge فسيبقى لديك agent runtime يعمل، لكنك تفقد gateway ودعم TrueFoundry. وإذا عملت fork لـ Kiro Crew فسيبقى لديك workspace ممتاز من دون محرك داخله. في اللحظة التي يغير فيها kiro-cli البروتوكول أو الأسعار أو جدول الإيقاف، يرث fork الخاص بك المشكلة. إذا كنت توازن بين البناء والشراء في agent stack الخاص بك، فهذا هو السؤال الذي يجب طرحه على أي منتج مفتوح جزئيا: أي طبقة تتوقف عن العمل عندما يتغير roadmap البائع؟ طرحت النقطة نفسها عن البنية الوكيلية عموما: السؤال المثير للاهتمام نادرا ما يكون أي نموذج، بل ما الذي يحيط به ومن يملك ذلك الغلاف.

وهناك ملاحظة هانغتشو التي لا أستطيع مقاومة إضافتها: توجيه Kiro يعامل بالفعل Qwen وDeepSeek وGLM وMiniMax كخيارات من الدرجة الأولى على Bedrock، وCrew يأتي مع موصلات WeCom وWeChat مباشرة. نماذج صينية وواجهات مراسلة صينية كأجزاء عادية من stack بائع أمريكي. سجلت ذلك، بشيء من الرضا، من المدينة التي يصنع فيها نصف تلك النماذج.

ماذا تفعل الآن

إذا كنت تقيم Kiro Crew، فهناك ثلاث خطوات، بهذا الترتيب.

1. اليوم: اقرأ المستودع قبل تثبيت أي شيء. ابدأ بقسم البنية في README، ثم GOVERNANCE.md وMAINTAINERS.md، ثم وثائق الأمن. الهدف من الطبقة المفتوحة هو أنك تستطيع التحقق منها، فتحقق منها. التثبيت نفسه سطر واحد، ولوحة التحكم ترتبط بـ localhost افتراضيا.

2. هذا الأسبوع: شغله على workload واحدة محدودة ومنخفضة المخاطر: مراقبة PR مجدولة، أو ملخص صباحي، أو مراجعة متكررة. راقب ما يفعله عبر عرض Activity وسجل التدقيق، وراقب استهلاك الاعتمادات. الوكلاء الدائمون ينفقون المال وأنت نائم. هذا هو المنتج يعمل كما صمم، وهو أيضا نقاش ميزانية.

3. هذا الشهر: قرر أي طبقة ستلتزم بها. إذا كنت تستخدم Kiro بالفعل، فـ Crew خيار سهل. وإذا كنت تختار stack من الصفر، فقارن الحد بـ harness مفتوح بالكامل مثل TrueForge، وفكر في مقايضات الاستضافة الذاتية قبل أن تتصلب workflows فريقك حول أحد الخيارين. وإذا واصلت، فإن دعم MCP في Crew يعني أن أدواتك الحالية تأتي معك؛ قائمتي المختصرة من خوادم MCP التي تستحق التوصيل نقطة بداية معقولة.

الأسئلة الشائعة

هل Kiro Crew مفتوح المصدر؟

مساحة العمل نعم: الـ Gateway ولوحة التحكم وتطبيق سطح المكتب وCLI وApps والـ skills وكامل حزمة الأمن كلها تحت Apache 2.0 في مستودع kirodotdev/KiroCrew، ويمكنك استضافة كل ذلك على أجهزتك من دون control plane تابع لـ AWS. لكن محرك الوكلاء تحته، kiro-cli، ليس مفتوح المصدر، ولا يستطيع Crew العمل من دونه. لذلك عبارة "مفتوح المصدر" دقيقة بالنسبة للمستودع، لكنها غير كاملة كوصف للمنتج كله.

هل يحتاج Kiro Crew إلى حساب AWS؟

يحتاج إلى تسجيل دخول Kiro، وهو الذي يدير الوصول إلى النماذج وفوترة الاعتمادات عبر kiro-cli. لا تحتاج إلى نشر أي شيء داخل حساب AWS للاستخدام المحلي؛ مساحة العمل وحالتها تبقيان على جهازك. وإذا أردت نسخة بعيدة تعمل دائما، فيمكن للأمر kirocrew cloud launch إنشاء واحدة على EC2 داخل حساب AWS الخاص بك، لكن خادم Linux عادي أو home lab يعمل أيضا.

كيف يختلف Kiro Crew عن الوضع autonomous في Kiro؟

في النطاق. الوضع autonomous يتولى مهمة واحدة في جلسة واحدة وأنت تراقب. Crew يبقى عبر الجلسات وإعادة التشغيل، وينفذ أعمالا مجدولة وتفاعلية سواء كنت متصلا أم لا، وينسق الوكلاء الفرعيين بالتوازي، ويحمل الذاكرة والدروس والـ skills من تشغيل إلى آخر. إنه واجهة جديدة فوق محرك Kiro نفسه ويقرأ إعداد .kiro نفسه.

هل يمكنني استخدام Kiro Crew مع محرك وكلاء أو موفر نماذج مختلف؟

ليس اليوم. موفر الوكلاء ثابت على ACP عبر kiro-cli، لذلك تأتي النماذج مما يوجه إليه حساب Kiro الخاص بك، ويشمل ذلك حاليا Claude ونماذج مفتوحة مثل Qwen وDeepSeek وGLM وMiniMax على Bedrock. نموذج الحوكمة عام، والمشرفون يقولون إن المساهمات الخارجية مرحب بها، لذلك يمكن تصور محرك قابل للاستبدال، لكنه ليس التصميم المتاح الآن، ولن أبني خطة على افتراض ظهوره.

الخلاصة

Kiro Crew مشروع مفتوح المصدر جيد مبني حول محرك تجاري مغلق، وAWS كانت أكثر صراحة بشأن هذا الترتيب مما يفعله معظم البائعين. الطبقة المفتوحة حقيقية: حالة مستضافة ذاتيا، وذاكرة مرئية، ونموذج أمن قابل للتدقيق، وحوكمة عامة. والطبقة المغلقة حقيقية أيضا: الـ harness الفعلي، وتسجيل الدخول، والعداد. إذا دخلت وأنت تعرف تماما على أي جانب من الخط يقع التزامك، فإن Crew يستحق وقتك. وإذا كنت تحتاج إلى الخط في مكان آخر، فقد منحك الشهر نفسه harness بترخيص MIT يضعه هناك.

إذا كنت تحاول تحديد أين ينبغي أن يقع الحد المفتوح في agent stack الخاص بك، فهذا نقاش أجريه مع العملاء بانتظام. تواصل معي.

المصادر

• Kiro (AWS)، "Introducing Kiro Crew": https://kiro.dev/blog/introducing-kiro-crew/ (نشر 2026-08-04، تم الاطلاع 2026-08-29)

• kirodotdev، مستودع KiroCrew (README، LICENSE، GOVERNANCE.md، وثائق الأمن): https://github.com/kirodotdev/KiroCrew (تم الاطلاع 2026-08-29)

• Kiro، صفحة منتج Kiro Crew (FAQ عن الترخيص والقدرات): https://kiro.dev/crew/ (تم الاطلاع 2026-08-29)

• SiliconANGLE، "AWS launches Kiro Crew, an autonomous agentic orchestrator for 24/7 code development": https://siliconangle.com/2026/08/04/aws-launches-kiro-crew-autonomous-agentic-orchestrator-24-7-code-development/ (نشر 2026-08-04، تم الاطلاع 2026-08-29)

• DevOps.com، "AWS Adds Agentic Workspace to Kiro AI Coding Tool": https://devops.com/aws-adds-agentic-workspace-to-kiro-ai-coding-tool/ (نشر 2026-08-05، تم الاطلاع 2026-08-29)

• Playing AWS، "Kiro Crew after one week (and more than 5000 credits)": https://www.playingaws.com/posts/what-is-kirocrew/ (نشر 2026-08-08، تم الاطلاع 2026-08-29)