AWS معماری Kiro را بازطراحی و سه پوستهٔ اجرایی جدا را در قالب یک پوستهٔ اجرایی مستقل یکپارچه کرده است. مرز ارتباطی کلاینت‌ها و عامل از طریق پروتکل استاندارد Agent Client Protocol (ACP) تعیین می‌شود؛ بنابراین انتخاب یک عامل متفاوت دیگر الزام تغییر ویرایشگر یا ترمینال را به همراه نخواهد داشت.

تجمیع اجراها: چه چیزی تغییر کرد

قبلاً IDE، CLI و رابط وب هر یک روی فناوری‌های متفاوتی (TypeScript، Rust و Python) تکیه داشتند. اکنون همهٔ این‌ها در قالب یک فرایند جدا اجرا می‌شوند که در کنار فضای کاری قرار می‌گیرد. مزایای این رویکرد:

  • ساده شدن نگهداری و همگام‌سازی کد
  • جلوگیری از نفوذ مستقیم کلاینت‌ها به APIهای داخلی عامل
  • قابلیت اجرای عامل به‌صورت محلی یا در سندباکس ابری بدون تغییر در کلاینت

ACP؛ اهمیت و نقش

ACP چیست

Agent Client Protocol که نخستین‌بار در پروژهٔ Zed مطرح شد و با مشارکت JetBrains توسعه می‌یابد، یک رابط عمومی بین کلاینت‌ها و عامل‌ها فراهم می‌کند. وقتی AWS این پروتکل را به‌عنوان مرز ارتباطی انتخاب می‌کند، تعامل‌ها به‌جای وابستگی به جزئیات پیاده‌سازی، از طریق یک قرارداد استاندارد انجام می‌شود.

اهمیت برای سازگاری

  • کلاینت‌ها تنها از طریق ACP با عامل گفتگو می‌کنند و پیاده‌سازی داخلی عامل پنهان می‌ماند.
  • افزایش امکان ترکیب‌پذیری بین عامل‌ها و کلاینت‌های مختلف بدون ادغام سفارشی.

مرز معماری: از کتابخانه‌های مشترک تا فرایند مستقل

تجربهٔ تیم Kiro نشان می‌دهد کتابخانه‌های مشترک در آغاز ساده به‌نظر می‌رسند اما رفته‌رفته کلاینت‌ها به APIهای داخلی وابسته می‌شوند و مرزها محو می‌گردند. اجرای عامل به‌صورت یک فرایند مستقل مانع از چنین نفوذی می‌شود و تنها راه تعامل را پروتکل ACP نگه می‌دارد.

تمایز از طریق افزونه‌ها

AWS به‌جای طرح یک پروتکل اختصاصی، ACP را گسترش داده است. نکات کلیدی توسعهٔ تیم Kiro:

  • افزودن بیش از 20 متد قابل‌فراخوانی توسط عامل و بیش از 15 متد قابل‌فراخوانی توسط کلاینت.
  • تعریف حدود 20 نوع اعلان جدید و قرارگیری همهٔ افزونه‌ها تحت فضای‌نام _kiro/.
  • پشتیبانی از ترنسپورت‌های متفاوت: WebSocket برای کلاینت‌های وب و iOS و ترنسپورت stdio برای اجراهای محلی.

این مدل امکان پیاده‌سازی قابلیت‌های اختصاصی هر فروشنده از طریق افزونه‌ها را می‌دهد در حالی که سازگاری پایه از طریق پروتکل حفظ می‌شود.

نمایش معماری Kiro و ACP

دیگران هم به همان سمت حرکت کرده‌اند

  • مایکروسافت در رویداد Build نمونه‌ای از Intelligent Terminal مبتنی بر ACP معرفی کرد که می‌تواند CLIهای عامل محلی را کشف و GitHub Copilot CLI را به‌عنوان عامل پیش‌فرض به‌کار گیرد.
  • JetBrains با آوردن Junie از طریق ACP به ReSharper 2026.2، مسیر پشتیبانی گسترده‌تر از پروتکل را آغاز کرده است.

حرکت این بازیگران نشان می‌دهد بازار به سمت جدا کردن تجربهٔ توسعه‌دهنده از پیاده‌سازی‌های عامل پیش می‌رود؛ مشابه تحول ایجادشده توسط Language Server Protocol (LSP) برای ابزارهای زبان.

حکمرانی و مدل دسترسی جدید

Kiro مدل دسترسی مبتنی بر قابلیت (capability) را بر پایهٔ Cedar پیاده‌سازی کرده است. به‌جای قواعد مبتنی بر لیست‌های مجاز/ممنوع یا تطابق‌های پیشوندی، مدل قابلیت‌ها دسترسی را حول نیت عملکردی می‌سازد.

نمونه‌هایی از قابلیت‌ها:

  • fs_read، fs_write
  • shell، web_fetch
  • mcp، subagent

برای مثال غیرفعال کردن fs_read به‌طور یکپارچه تمامی عملیات خواندن فایل را مسدود می‌کند، بدون توجه به اینکه کدام عامل یا ابزار آن را درخواست کرده است.

سیاست‌ها در سطوح مختلفی ارزیابی می‌شوند: مدیریت دستگاه (MDM)، کاربر، فضای کاری، پروفایل عامل و جلسهٔ ارزیابی. این ساختار کنترل دقیق‌تر و توجیه‌پذیری بیشتری فراهم می‌آورد.

پیامدها برای توسعه‌دهندگان و اکوسیستم

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

چشم‌انداز

گسترش ACP توسط بازیگران بزرگ می‌تواند سازگاری را آسان‌تر و رقابت را هدفمندتر کند؛ رقابتی که حول امنیت، قابلیت اطمینان و قابلیت‌ها شکل می‌گیرد. اگر این روند ادامه یابد، احتمال شکل‌گیری یک اکوسیستم قابل تعامل برای عامل‌های توسعه‌دهنده بسیار افزایش می‌یابد و انتخاب ابزار برای توسعه‌دهندگان ساده‌تر خواهد شد.