آمازون وب سرویس (AWS) بهتازگی از Loom، یک پلتفرم عامل منبعباز و اصولگرا رونمایی کرد که نشان میدهد سازمانها چگونه میتوانند عاملهای هوش مصنوعی را با کنترلهای امنیتی یکپارچه در AWS بسازند، مستقر کنند و مدیریت نمایند. Loom عاملها را با استفاده از Strands Agents SDK میسازد، آنها را روی Amazon Bedrock AgentCore Runtime اجرا میکند و در AWS Labs در دسترس است. AWS تأکید دارد که Loom یک سرویس مدیریتشده نیست، بلکه نمونهای عملی از نحوهی ساخت پلتفرمهای عاملی توسط سازمانها است.
چالشهای هفتگانه در مقیاسسازی استقرار عاملها
پست وبلاگ رسمی Loom را حول هفت چالش اصلی که تیمهای مهندسی پلتفرم هنگام مقیاسسازی استقرار عاملها با آن مواجه هستند، ساختار میدهد:
- اعمال برچسبگذاری یکسان منابع
- پیادهسازی کنترلهای دسترسی مبتنی بر نقش و ویژگی
- ساخت بلوپرینتهای استقرار
- اعتبارسنجی نرمافزار قبل از استقرار
- انتشار هویت از طریق زنجیرههای عامل نماینده
- مدیریت گسترش عاملها
- نیاز به بررسی انسانی قبل از اقدامات حساس
انتشار هویت: سختترین مسئله
یکی از برجستهترین قابلیتهای Loom، مدیریت انتشار هویت در زنجیرهی فراخوانیها است. وقتی یک عامل از طرف یک کاربر عمل میکند و یک سرور MCP را فراخوانی میکند که به نوبهی خود یک REST API را صدا میزند، هر گام به یک توکن دسترسی نیاز دارد که هویت و مجوزهای کاربر مبدأ را حفظ کند. Loom برای این کار از جریان کد مجوز کامل و فرآیند تبادل توکن RFC 8693 که توسط AgentCore Identity پشتیبانی میشود، استفاده میکند. بدین ترتیب هم هویت کاربر نهایی و هم عامل در توکنهای دسترسی پاییندستی حرکت میکنند و زنجیرهی نمایندگی دست نخورده باقی میماند. این پلتفرم هر گام از تبادل را از عامل به سرور MCP و سپس به نقطهی پایانی Amazon API Gateway تجسم میکند که هر کدام توکن مخصوص به خود را دارند. سیستمهای پاییندستی فقط دادههایی را که کاربر مبدأ مجاز به دسترسی است، نمایش میدهند.
مدل استقرار مبتنی بر پیکربندی
Loom موضعی عمدی در برابر تولید کد در زمان اجرا اتخاذ کرده است. این پلتفرم یک عامل Python از پیش نوشته شده و قابل تنظیم که با Strands Agents ساخته شده است را مستقر میکند و دستورالعملهای رفتاری، منابع حافظه و پیکربندیهای Model Context Protocol (MCP) یا A2A را در زمان استقرار تزریق میکند. کد هرگز بین استقرارها تغییر نمیکند؛ فقط پیکربندی تغییر میکند. تیمهای پلتفرم میتوانند کد عامل را یک بار اسکن کنند، سفارشیسازیهای سازمانی مانند الزامات ثبت رویداد را اضافه کنند و آن را در هر استقرار مجدد استفاده نمایند. تیمهایی که نیازی به سفارشیسازی ندارند میتوانند از مسیر بدون کد از طریق مهار مدیریتشده AgentCore استفاده کنند. رمزها و اعتبارنامهها به هیچ وجه در Loom ذخیره نمیشوند؛ آنها در AWS Secrets Manager زندگی میکنند و فقط در صورت نیاز فراخوانی میشوند.
حکمرانی و کنترل دسترسی
مدیریت در Loom از طریق دو مکانیسم اصلی انجام میشود. پروفایلهای برچسب سه برچسب اجباری (loom:application، loom:group، loom:owner) را روی هر منبع مستقر شده اعمال میکنند، با برچسبهای سفارشی اختیاری مانند شناسه مرکز هزینه. کنترل دسترسی دو بعد را ترکیب میکند: نوع نقش قابلیتها و نمای کاربر را تعیین میکند، در حالی که برچسبهای گروه مشخص میکنند که کاربر چه منابعی را میتواند ببیند. مدیران به یک داشبورد کاتالوگ دسترسی دارند؛ کاربران نهایی فقط یک رابط چت، عاملهای گروه خود و تاریخچه مکالمات خود را مشاهده میکنند.
کشف عامل و بررسی انسانی
برای کشف عامل، Loom با AWS Agent Registry (در پیشنمایش عمومی) یکپارچه میشود و با مشخصات کارت عامل A2A و طرح ابزار MCP مطابقت دارد. عاملها قبل از انتشار برای استفاده تولیدی، یک فرآیند بررسی را طی میکنند. همچنین، بررسی human-in-the-loop به سه روش با استفاده از چارچوب قلابهای Strands Agents و استخراجهای بومی MCP پیادهسازی شده است.
Loom حاصل یک نمونه اولیه است که Heeki Park، معمار اصلی راهحل در AWS، در ماه ژوئن در Medium مستند کرده بود. اکنون این پروژه به AWS Labs ارتقا یافته و به عنوان یک پلتفرم مرجع منبعباز در اختیار سازمانها قرار گرفته است. AWS امیدوار است Loom به تیمهای پلتفرم کمک کند تا چالشهای مقیاسسازی عاملهای هوش مصنوعی را با امنیت و کارایی بیشتری مدیریت کنند.
