كيف تستضيف KiroCrew ذاتياً على خادم VPS؟

لماذا تستضيف KiroCrew ذاتياً على خادم VPS بدلاً من حاسوب محمول

تؤتي استضافة KiroCrew ذاتياً ثمارها فقط على جهاز لا يدخل في وضع السكون، لذا فإن خادم VPS هو المكان المناسب لها وليس الحاسوب المحمول. تحتفظ KiroCrew بسجل الجلسات، والذاكرة الدلالية، والمهام المجدولة، وقائمة الموافقة على القرص، وتقوم بإعادة تحميل كل ذلك عند إعادة تشغيل العملية. لا فائدة من أي من هذا إذا لم تكن العملية قيد التشغيل في الساعة 03:00 عند حلول موعد مهمة مجدولة، والحاسوب المحمول المغلق لا يشغلها.

KiroCrew هي مساحة عمل للوكلاء مفتوحة المصدر من فريق Kiro، مرخصة بموجب Apache 2.0، وقد صدرت أولى نسخها العامة في أوائل أغسطس 2026. عملية واحدة، تسمى البوابة (gateway)، تمتلك الحالة وتخدم لوحة تحكم ويب على المنفذ 5476. يمكنك الوصول إلى تلك البوابة من لوحة التحكم، أو من kirocrew CLI، أو من قناة محادثة مثل Slack. البوابة هي الشيء الوحيد الذي تستضيفه ذاتياً، لذا يدور هذا الدليل حول إبقائها قيد التشغيل، وإبقائها بعيدة عن الإنترنت العام، والقدرة على استعادتها بعد ترقية فاشلة.

أمران يجب معرفتهما قبل البدء. تشغّل KiroCrew خدمة kiro-cli، التي تتطلب تسجيل دخول لمرة واحدة باستخدام حساب Kiro، وتتم محاسبة استنتاج الوكيل (agent inference) وفق خطة Kiro، لذا اعتباراً من أغسطس 2026، هذا ليس إعداداً يعمل دون اتصال بالإنترنت. المشروع أيضاً عمره أسابيع فقط. افترض أنك ستحتاج إلى التراجع عن التغييرات في مرحلة ما، وقم بتثبيته بطريقة تسمح لك بذلك. إذا لم يسبق لك تشغيل وكيل على خادم، فإن تشغيل وكيل برمجي على خادم VPS يغطي القواعد الأساسية التي يبني عليها هذا الدليل.

ما تحتاجه KiroCrew، وأين تُحفظ حالتها

يتطلب التثبيت الأصلي (Native) إصدار Python 3.10 أو أحدث (يوصي المشروع بـ 3.12)، وNode.js 18 أو أحدث إذا كنت تبني لوحة التحكم من المصدر، بالإضافة إلى kiro-cli، الذي يقوم التشغيل الأول بتثبيته وتسجيل الدخول إليه نيابةً عنك. لا يتطلب التثبيت عبر الحاويات (Container) أياً من ذلك على المضيف، بل يحتاج فقط إلى Docker. وهذا هو السبب الرئيسي لتفضيل هذا الخيار.

تُحفظ الحالة في ~/.kiro/crew، ويقوم متغير البيئة KIROCREW_HOME بنقلها إلى مكان آخر. إليك ما يوجد بداخلها:

• config.json: إعدادات البوابة (gateway) وبيانات اعتماد قنوات الدردشة.
• .env: الأسرار (secrets).
• workspace/memory/: التفضيلات، وملاحظات المشروع، وسجل الدردشة.
• memory.db و memory_index.db: الفهارس الدلالية (semantic) وفهارس النص الكامل (full-text).
• models/: نموذج التضمين (embedding model)، الذي يتم تنزيله عند التشغيل الأول.
• gateway.log و security_events.jsonl: سجل وقت التشغيل وسجل الأحداث الأمنية.

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

خطط للمساحة التخزينية بدلاً من الذاكرة العشوائية (RAM). البوابة هي عملية Python؛ أما ما يستهلك موارد الخادم فعلياً فهو ما يقوم الوكيل بتشغيله، سواء كان عملية بناء أو مجموعة اختبارات. ينمو مجلد الحالة مع زيادة سجل الدردشة، ويصل نموذج التضمين عند البدء الأول، لذا قم بقياس المساحة على خادمك الخاص باستخدام du -sh ~/.kiro/crew بعد بضعة أسابيع بدلاً من الاعتماد على أي أرقام منشورة في الشهر الأول من عمر المشروع.

أي مسارات التثبيت الثلاثة يجب أن تستخدم

ينشر المشروع ثلاثة مسارات. يقوم المثبّت المكون من سطر واحد بجلب حزمة wheel ويضع kirocrew في مسار PATH الخاص بك:

curl -fsSL https://download.crew.kiro.dev/cli.sh | sh

يأخذ هذا المثبّت علامة القناة وعلامة الإصدار:

curl -fsSL https://download.crew.kiro.dev/cli.sh | sh -s -- --channel insider
curl -fsSL https://download.crew.kiro.dev/cli.sh | sh -s -- --version 0.1.3

تُنشر صورة الحاوية في ghcr.io/kirodotdev/kirocrew، وتدعم linux/amd64 وlinux/arm64 تحت كل وسم. بناء المصدر هو git clone بالإضافة إلى make build، وهو مخصص للأشخاص الذين يعدلون الكود، وليس للأشخاص الذين يشغلونه.

استخدم الحاوية. التثبيت الأصلي يضع حزم Python وNode وkiro-cli على نفس المضيف الذي يشغل خدماتك الأخرى، لذا فإن أي ترقية تفشل ستتركك أمام مهمة إصلاحها يدوياً. تحافظ الحاوية على بيئة التشغيل في صورة واحدة والحالة في وحدة تخزين (volume) واحدة، مما يجعل التراجع عن التغييرات مجرد تغيير للوسم وإعادة تشغيل.

ثبّت الصورة على وسم إصدار محدد، لا على stable

يستخدم مثال المشروع نفسه الوسم stable:

docker run -d --name kirocrew \
  -p 127.0.0.1:5476:5476 \
  -v kirocrew-home:/home/kirocrew \
  ghcr.io/kirodotdev/kirocrew:stable

الوسم stable هو وسم متغيّر. فهو يشير دائماً إلى أحدث إصدار مستقر متاح، مما يعني أن عملية السحب (pull) التالية قد تغيّر النسخة التي تشغلها دون تدخّل منك، كما أن هذا الوسم لا يسجل أي معلومات حول النسخة التي يشير إليها. وسوم الإصدارات غير قابلة للتغيير، لذا احرص على تثبيت أحدها. أحدث إصدار بتاريخ 6 أغسطس 2026 هو 0.1.3، والذي نُشر في 5 أغسطس 2026. يوجد أيضاً وسم nightly، وهو في مشروع حديث كهذا يعني أن الكود قد تغيّر هذا الصباح.

اكتب /opt/kirocrew/compose.yaml:

services:
  kirocrew:
    image: ghcr.io/kirodotdev/kirocrew:0.1.3
    container_name: kirocrew
    restart: unless-stopped
    ports:
      - "127.0.0.1:5476:5476"
    volumes:
      - kirocrew-home:/home/kirocrew

volumes:
  kirocrew-home:

شغّل الحاوية، ثم افحص نقطة نهاية السلامة (health endpoint) التي تستخدمها الصورة أيضاً لغرض HEALTHCHECK الخاص بها:

cd /opt/kirocrew
docker compose up -d
docker compose ps
curl -s http://127.0.0.1:5476/api/health

يجب أن يبلغ docker compose ps عن حالة الحاوية بأنها سليمة (healthy) في غضون دقيقة تقريباً، ويستجيب /api/health دون الحاجة إلى رمز مميز (token) (وكذلك /api/live و/api/ready، وهو ما يجعلها قابلة للاستخدام كأدوات فحص). إذا بقيت الحالة عند starting، اقرأ docker logs kirocrew قبل تغيير أي شيء. التشغيل الأول يقوم بتنزيل نموذج التضمين (embedding model)، لذا فإن بطء الاتصال قد يجعل عملية البدء الأولى تستغرق وقتاً طويلاً.

الحفاظ على استمرارية العمل باستخدام systemd

يضمن restart: unless-stopped إعادة تشغيل الحاوية بعد تعطلها أو بعد إعادة تشغيل الخادم، طالما أن Docker نفسه يبدأ عند الإقلاع. يجعل ملف الوحدة (unit file) هذا الاعتماد صريحاً، ويمنحك أمراً واحداً لإيقاف حزمة الخدمات بالكامل قبل إجراء النسخ الاحتياطي. يغطي بدء تشغيل حزمة Docker Compose عند الإقلاع النمط العام لهذا الإجراء. هذا هو شكل KiroCrew الخاص به في /etc/systemd/system/kirocrew.service:

[Unit]
Description=KiroCrew gateway
Requires=docker.service
After=docker.service

[Service]
Type=oneshot
RemainAfterExit=yes
WorkingDirectory=/opt/kirocrew
ExecStart=/usr/bin/docker compose up -d
ExecStop=/usr/bin/docker compose down
TimeoutStartSec=0

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now kirocrew
systemctl status kirocrew

يجب أن تقرأ systemctl status kirocrew القيمة active (exited)، وهي النتيجة السليمة لهذه الوحدة. وُضع Type=oneshot مع RemainAfterExit=yes هنا لأن docker compose up -d يعود فور بدء تشغيل الحاوية: فـ systemd يتتبع حالة عمل الحزمة، وليس عملية تعمل في الواجهة الأمامية. إذا كتبت Type=simple بدلاً من ذلك، سيرى systemd الأمر ينهي عمله فوراً، ويصنّف الخدمة كمتوقفة، ثم إما يتوقف عن المحاولة أو يدخل في حلقة إعادة تشغيل بناءً على إعداد Restart= الخاص بك. بالنسبة للتثبيت الأصلي (native install)، يوفر المشروع ما يعادله وهو kirocrew service install، الذي يكتب /etc/systemd/system/kirocrew.service ويشغل البوابة بصلاحيات المستخدم الخاص بك. لا تشغل الوحدتين معاً. النسخة الأوسع من هذا الموضوع موجودة في خدمات ومؤقتات systemd على خادم افتراضي خاص (VPS).

التشغيل الأول: تسجيل الدخول والحصول على رمز لوحة التحكم

يبدأ الحاوية بتشغيل البوابة، لكن وقت تشغيل الوكيل (agent runtime) لم يسجل دخوله بعد. سجل دخولك داخل الحاوية:

docker exec -it kirocrew kiro-cli login

يطبع هذا الأمر رمز جهاز ورابطاً تفتحه في متصفحك الخاص. بعد ذلك، أنشئ رمزاً للوحة التحكم:

docker exec kirocrew kirocrew token --ttl 2h

رابط لوحة التحكم هو http://localhost:5476/?token=<the token>. تنتهي صلاحية الرموز: الجلسات تستمر افتراضياً لمدة ساعة واحدة، والحد الأقصى الموثق هو عشرون ساعة. إذا كانت لوحة التحكم تظهر فارغة أو تعيد توجيهك للخارج مباشرة، فهذا يعني عادةً أن الرمز قد انتهت صلاحيته، لذا أنشئ رمزاً آخر. لا تضع الرمز أبداً في تذكرة دعم أو رسالة دردشة، لأن من يملك الرمز يملك وكيلك.

الوصول إلى لوحة التحكم عبر SSH، وتجنب نشر المنفذ 5476

ألقِ نظرة مجدداً على عنوان الربط في مثال المشروع: -p 127.0.0.1:5476:5476. داخل الحاوية، تستمع البوابة على 0.0.0.0، لأنها يجب أن تكون قابلة للوصول عبر تعيين المنفذ، لكن التعيين نفسه ينشر الخدمة على واجهة الاسترجاع (loopback) في المضيف فقط. إذا حذفت البادئة 127.0.0.1:، ستصبح البوابة متاحة على الإنترنت العام لأي شخص يمسح ذلك المنفذ. لن تحميك قاعدة جدار ناري أيضاً: يقوم Docker بنشر المنافذ عبر كتابة قواعد DNAT التي تُقيَّم قبل تصفية ufw، لذا فإن ufw deny 5476 لا تؤثر على المنفذ المنشور. يشرح الرابط تجاوز منافذ Docker لجدار ناري ufw هذه الآلية بالتفصيل.

بدلاً من ذلك، قم بتوجيه المنفذ عبر SSH من حاسوبك المحمول:

ssh -N -L 5476:127.0.0.1:5476 you@your-server.example.com

اترك هذا الأمر يعمل وافتح http://localhost:5476/?token=<the token> محلياً. لجعل التوجيه تلقائياً عند كل اتصال، أضفه إلى ~/.ssh/config:

Host your-server.example.com
    LocalForward 5476 127.0.0.1:5476

إذا كان المنفذ 5476 مستخدماً بالفعل على حاسوبك، غيّر الرقم الموجود على اليسار فقط: ssh -N -L 45476:127.0.0.1:5476 you@your-server.example.com، ثم تصفح http://localhost:45476/?token=....

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

docker cp kirocrew:/home/kirocrew/.kiro/crew/config.json .
# edit config.json here
docker cp config.json kirocrew:/home/kirocrew/.kiro/crew/config.json
docker exec -u 0 kirocrew chown kirocrew:kirocrew /home/kirocrew/.kiro/crew/config.json
docker restart kirocrew

للوصول عبر الهاتف، يشير المشروع إلى tailscale serve الخاص بـ Tailscale، والذي يبقي لوحة التحكم داخل شبكتك الخاصة (tailnet) بدلاً من وضعها على اسم نطاق عام. فضل هذا الخيار على استخدام وكيل عكسي (reverse proxy) عام. ينتقل الرمز (token) ضمن الرابط (URL)، ويُكتب الرابط في كل سجل وصول على مساره.

امنح الوكيل أصغر نطاق تأثير ممكن

يتحقق الحاوية من دعم وضع الحماية (sandbox) عند التشغيل الأول، وتحدد النتيجة ما إذا كان بإمكان الوكلاء تنفيذ أي شيء. إذا كان عزل مساحة الأسماء (namespace isolation) متاحاً، تعمل العمليات الفرعية للوكيل معزولة. إذا لم يكن متاحاً ولم يتم ضبط KIROCREW_ALLOW_UNSANDBOXED=1، يُرفض التنفيذ بدلاً من التشغيل دون قيود؛ لذا فإن البوابة التي تبدو سليمة بينما تتعطل كل المهام عادة ما تعاني من هذه المشكلة. يُحفظ قرار التشغيل في docker logs kirocrew منذ تلك المرة الأولى. ينشر المشروع أيضاً ملف تعريف seccomp (وضع الحوسبة الآمن) يمكنك تطبيقه:

curl -fsSL https://raw.githubusercontent.com/kirodotdev/KiroCrew/main/docker/seccomp/kirocrew-seccomp.json \
  -o /opt/kirocrew/kirocrew-seccomp.json

    security_opt:
      - seccomp:./kirocrew-seccomp.json

إذا قمت بضبط KIROCREW_ALLOW_UNSANDBOXED=1، فكن على دراية بما تغير: أصبحت الحاوية الآن هي الحاجز الوحيد بين الوكيل وخادمك. تحذير المشروع يستحق التكرار بالكامل. لا تقم بعمل mount لمسارات المضيف التي لا تود تسليمها مباشرة للوكيل. عملياً، هذا يستبعد مقبس Docker، وأي bind mount لـ /، وأي دليل يحتوي على بيانات خدمة أخرى.

ما تبقى هو الإطار الذي ينطبق على كل وكيل مسموح له بتنفيذ الأوامر. احصر صلاحياته في المستودع الواحد أو الحاوية (bucket) الواحدة التي يحتاجها، ولا تستخدم أبداً رمزاً شخصياً (token) يتمتع بصلاحيات على مستوى الحساب بالكامل. شغّله كمستخدم مخصص لا يحتوي مجلد منزله على أي شيء آخر، وهو ما يوضحه مستخدمو الصلاحيات الدنيا على خادم VPS. عندما يكتب الوكيل كوداً ثم ينفذه، امنحه جهازاً يُسمح له بكسره: جهاز افتراضي مؤقت لوكلاء البرمجة يمثل حاجزاً أقوى من أي flag في ملف compose هذا، لأنك تحذفه بدلاً من تنظيفه. المنطق نفسه يشكّل تشغيل OpenClaw بأمان على خادم VPS واستضافة وكيل Hermes ذاتياً على خادم VPS. المهام المجدولة تستهلك المال أيضاً أثناء نومك، حيث تُحسب تكاليف الاستنتاج ضمن خطة Kiro الخاصة بك، لذا اضبط الحدود الموضحة في التحكم في تكاليف وكيل الذكاء الاصطناعي على خادم VPS قبل إضافة مهمة ليلية.

نسخ وحدة التخزين الاحتياطية قبل كل ترقية

اعثر على الاسم الحقيقي لوحدة التخزين أولاً. تُلحق Docker Compose بادئة باسم المشروع بأسماء وحدات التخزين، حيث يُستخدم اسم المجلد كقيمة افتراضية، لذا فإن وحدة التخزين المُعرّفة باسم kirocrew-home في ملف /opt/kirocrew/compose.yaml يتم إنشاؤها بالاسم kirocrew_kirocrew-home:

docker volume ls

أوقف البوابة (gateway) قبل نسخ أي شيء. الملفان memory.db وmemory_index.db هما قاعدتا بيانات SQLite، ونسخ قاعدة بيانات أثناء الكتابة فيها قد يؤدي إلى التقاط معاملة غير مكتملة، مما يجعل الملف المستعاد تالفاً. تنص تعليمات الترحيل الخاصة بالمشروع على الأمر نفسه: انقل البيانات فقط أثناء توقف البوابات.

sudo systemctl stop kirocrew
docker run --rm -v kirocrew_kirocrew-home:/data:ro -v "$PWD":/backup \
  alpine tar czf /backup/kirocrew-2026-08-06.tgz -C /data .
sudo systemctl start kirocrew

انسخ الأرشيف خارج الخادم. عملية الاستعادة تتم بنفس الأمر مع إيقاف الحاوية واستبدال tar xzf بـ tar czf:

sudo systemctl stop kirocrew
docker run --rm -v kirocrew_kirocrew-home:/data -v "$PWD":/backup \
  alpine tar xzf /backup/kirocrew-2026-08-06.tgz -C /data
sudo systemctl start kirocrew

الانتقال إلى مضيف جديد يختلف عن الاستعادة في نفس المكان، والمشروع يحدد خطوات ذلك بدقة. يتم نقل سجل المحادثات وملاحظات المشروع الموجودة تحت workspace/memory/، وكذلك ملفا قاعدة البيانات وconfig.json. أما ملفات PID وسجل الأحداث الأمنية و.env فهي مرتبطة بالمضيف القديم، لذا اتركها ولا تنقلها، وأعد إدخال الأسرار (secrets) مجدداً على الخادم الجديد.

كيف تتراجع عن ترقية سيئة

عملية الترقية قصيرة، وهي آمنة فقط لأنك قمت بتثبيت إصدار محدد. خذ نسخة احتياطية أولاً، ثم غيّر الوسم (tag):

sudo systemctl stop kirocrew
# take the backup here, as above
sudo nano /opt/kirocrew/compose.yaml   # set the new image tag
sudo systemctl start kirocrew
docker compose -f /opt/kirocrew/compose.yaml ps
curl -s http://127.0.0.1:5476/api/health

يقوم docker compose up -d بسحب الصورة إذا لم تكن موجودة مسبقاً على الخادم، لذا فإن تعديل الوسم هو كل ما تتطلبه الترقية. التراجع عن الترقية هو نفس التسلسل باستخدام الرقم القديم، وهو يمنحك الصورة الدقيقة التي كنت تستخدمها من قبل، لأن وسوم الإصدارات غير قابلة للتغيير.

يتم التراجع عن الملف الثنائي (binary) بشكل نظيف. أما الحالة (state) فهي الجزء الذي قد لا يكون كذلك. يمكن للبوابة (gateway) الأحدث إعادة كتابة config.json أو ترحيل قواعد بيانات الذاكرة إلى شكل لا تستطيع البوابة الأقدم قراءته، ولا يوجد مسار تراجع موثق حتى أغسطس 2026. لذا إذا بدأت الصورة الأقدم بالعمل ثم تصرفت بشكل غريب، فلا تحاول تصحيح الأخطاء. أوقفها، واستعد النسخة الاحتياطية التي أخذتها قبل الترقية، وابدأ من جديد. هذا هو السبب الكامل لأخذ النسخة الاحتياطية أولاً، وهو السبب في أن عادة الترقية الآن والنسخ الاحتياطي لاحقاً تفشل في مشروع بهذا الحداثة.

ما لم يتم إثباته هنا

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

هناك سلوكان يستحقان الاختبار بنفسك قبل الاعتماد عليهما. أولاً، ما إذا كانت عملية الرجوع إلى إصدار أقدم (downgrade) تقرأ الحالة التي كتبها إصدار أحدث: جرب ذلك على نسخة من وحدة التخزين (volume) في وقت لا يهم فيه الأمر، وليس أثناء انقطاع الخدمة. ثانياً، ما يفعله البوابة (gateway) عندما تنتهي صلاحية تسجيل دخول Kiro بينما تكون هناك مهمة مجدولة في موعدها. كلاهما من نوع الحواف الخشنة التي يسويها المشروع الناشئ بهدوء بين الإصدارات، وكلاهما سهل التحقق منه الآن.

FAQ

لماذا لا تفتح لوحة تحكم KiroCrew على عنوان IP العام الخاص بخادمي؟

لأن المثال المنشور يربط المنفذ بـ loopback. يقوم -p 127.0.0.1:5476:5476 بتعيين منفذ الحاوية على عنوان loopback الخاص بالمضيف فقط، وهذا إجراء مقصود. يمكنك الوصول إليها عن طريق توجيه المنفذ عبر SSH باستخدام ssh -N -L 5476:127.0.0.1:5476 you@your-server، ثم افتح http://localhost:5476/?token=<token> على حاسوبك المحمول. إزالة البادئة 127.0.0.1: لجعلها قابلة للوصول تضع البوابة على الإنترنت العام، ولن تتمكن قواعد جدار الحماية من حصرها، لأن قواعد DNAT للمنافذ المنشورة في Docker تُقيَّم قبل أن يقوم ufw بفلترة حركة المرور.

أين تخزن KiroCrew بياناتها، وما الذي يجب عليّ نسخه احتياطياً؟

يوجد كل شيء تحت ~/.kiro/crew، وهو ما يمثل /home/kirocrew/.kiro/crew داخل صورة الحاوية، ويقوم KIROCREW_HOME بنقل موقعه. انسخ الدليل بالكامل، أو وحدة تخزين Docker بالكامل، مع إيقاف البوابة. memory.db وmemory_index.db هما قاعدتا بيانات SQLite، لذا فإن النسخة المأخوذة أثناء كتابة البوابة للبيانات قد تكون غير متسقة. عند الانتقال إلى مضيف جديد، انقل workspace/memory/ وملفي قاعدة البيانات وconfig.json، بينما تنتمي ملفات PID وسجل الأحداث الأمنية و.env إلى المضيف القديم.

هل يجب عليّ استخدام الوسم stable أم وسم إصدار محدد؟

استخدم وسم إصدار. يتحرك stable في كل مرة يصدر فيها إصدار جديد، لذا يمكن أن تتغير النسخة التي تشغلها دون علمك عند عملية pull التالية، كما أن الوسم نفسه لا يخبرك بشيء عما يتم تشغيله. وسوم الإصدارات مثل 0.1.3 غير قابلة للتغيير، وهذا بالضبط ما يجعل التراجع عن التحديث ممكناً: فأنت تعيد الرقم القديم وتحصل على الصورة المطابقة تماماً. اعتباراً من 6 أغسطس 2026، أحدث إصدار هو 0.1.3.

لماذا يرفض الوكيل الخاص بي تنفيذ أي أوامر؟

تقوم الحاوية بفحص دعم وضع الحماية (sandbox) عند بدء تشغيلها لأول مرة. إذا لم تتمكن من عزل العمليات الفرعية للوكيل ولم يتم تعيين KIROCREW_ALLOW_UNSANDBOXED=1، فإنها ترفض تنفيذها بدلاً من تشغيلها دون قيود، لذا تبدو البوابة سليمة بينما تتوقف كل المهام. يعرض docker logs kirocrew قرار وضع الحماية من ذلك التشغيل الأول. تعيين هذا المتغير يجعل الحاوية هي الحدود الوحيدة بين الوكيل والمضيف، لذا إذا قمت بتعيينه، فلا تقم بعمل mount لأي شيء لا ترغب في تسليمه للوكيل مباشرة.

هل أحتاج إلى حساب Kiro لاستضافة KiroCrew ذاتياً؟

نعم، اعتباراً من أغسطس 2026. KiroCrew برنامج مجاني بموجب ترخيص Apache 2.0، لكنه يعمل مع kiro-cli، والذي يتطلب تسجيل دخول لمرة واحدة، وتتم محاسبة استنتاجات الوكيل (agent inference) ضمن خطة Kiro. داخل الحاوية، قم بتشغيل docker exec -it kirocrew kiro-cli login ووافق على رمز الجهاز في متصفحك. حتى يكتمل تسجيل الدخول هذا، تبدأ البوابة وتحمل لوحة التحكم، لكن الوكيل لا يملك نموذجاً للتواصل معه.