‏کیرو سه ایجنتش رو یکی کرد

کیرو (Kiro) از اول برای هر کلاینتش یه هارنس ایجنت جدا داشت؛ به گفتهٔ تیم سازنده، IDE با تایپ‌اسکریپت نوشته شده بود تا با مدل افزونهٔ Code OSS جور دربیاد، CLI با Rust برای سرعت، و کلاینت وب با پایتون تا به تحقیقات روز ایجنت‌ها نزدیک بمونه. این جدایی اولش سرعت می‌داد، ولی کم‌کم هر قابلیت باید سه بار ساخته می‌شد، هر باگ سه بار درست می‌شد و رفتار ایجنت هم بین کلاینت‌ها یکی نبود.

تو مقاله اومده که نقطهٔ عطف، آماده‌شدن نسخهٔ وب بود: به‌جای اضافه‌کردن یه ایجنت چهارم، همه‌چیز به یک هارنس واحد منتقل شد. نکتهٔ اصلی معماری اینه که این هارنس یه کتابخونهٔ کامپایل‌شده توی کلاینت نیست، بلکه یه پروسهٔ مستقل و سبکه که کنار کدبیس اجرا می‌شه. برای همین هم می‌تونه روی لپ‌تاپ بالا بیاد، هم داخل یه سندباکس ابری، و کلاینت اصلاً فرقی حس نمی‌کنه.

مرز بین کلاینت و هارنس رو پروتکل ACP مشخص می‌کنه؛ همون استاندارد ارتباط ایجنت با ادیتور که Zed و Neovim و چندتای دیگه هم ازش پشتیبانی می‌کنن. کیرو براش یه ترنسپورت وب‌سوکتی اضافه کرده تا کلاینت وب و iOS بتونن به هارنس داخل سندباکس ابری وصل شن، و بالای پروتکل پایه هم افزونه‌های خودش رو زیر فضای نام _kiro/ گذاشته: بیشتر از ۲۰ متد تازه، برای چیزهایی مثل هدایت زندهٔ ایجنت وسط کار.

سود فوری این کار اینه که قابلیت‌های قفل‌شده روی یک کلاینت حالا همه‌جان: توسعهٔ spec-driven به CLI و وب هم رسیده و ایجنت‌های سفارشی و هوک‌ها با همون فرمت .kiro/agents/ و .kiro/hooks/*.json همه‌جا یکسان رفتار می‌کنن. سیستم مجوزها هم یکی شده و روی Cedar سوار شده: قانون‌ها به‌جای تک‌تک ابزارها روی «قابلیت»هایی مثل fs_read یا shell نوشته می‌شن، بین چند سطح ترکیب می‌شن و همیشه deny برنده‌ست.

نکات کلیدی:

• سه هارنس جدا با تایپ‌اسکریپت، Rust و پایتون جاشون رو به یک هارنس واحد دادن
• هارنس یه پروسهٔ مستقله نه کتابخونه، پس لپ‌تاپ یا سندباکس ابری براش فرقی نداره
• ارتباط کلاینت و ایجنت با ACP و افزونه‌های _kiro/ انجام می‌شه
• spec، هوک‌ها و ایجنت‌های سفارشی حالا تو هر چهار کلاینت با یک فرمت کار می‌کنن
• مجوزها با Cedar و بر پایهٔ قابلیت تعریف می‌شن، نه ابزار به ابزار