ساخت پلتفرم هوش مصنوعی عامل‌محور با استفاده از Amazon Bedrock AgentCore

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

هر تیم جریان کاری به مسیری استاندارد و آماده استفاده نیاز دارد که مدل‌ها و ابزارهای تأییدشده، هویت موقت برای بارهای کاری، محیط اجرایی و حافظه ایزوله، ارزیابی خودکار، امکان بازگشت به نسخه قبلی، داده‌های تله‌متری و انتساب هزینه‌ها را در اختیارش قرار دهد. این کنترل‌ها باید حتی زمانی که تیم‌ها پرامپت‌ها، ابزارها، دسترسی به داده‌ها و رفتار برنامه‌های خود را سفارشی می‌کنند، یکپارچه باقی بمانند. اگر هر تیم این سازوکارها را مستقلاً پیاده‌سازی کند، کنترل‌ها به‌تدریج از یکدیگر فاصله می‌گیرند، سرویس‌های مشترک به گلوگاه تبدیل می‌شوند و ممیزی مالکیت و مسئولیت‌پذیری دشوار خواهد شد.

در این مقاله، معماری و پیاده‌سازی مرجع یک پلتفرم سازمانی هوش مصنوعی عامل‌محور را بر پایه Amazon Bedrock و Amazon Bedrock AgentCore بررسی می‌کنیم. موضوعات مقاله شامل مدل عملیاتی چندحسابی، صفحه کنترل پلتفرم، الگوی تکرارپذیر استقرار برای هر جریان کاری، درگاه‌های مجزای استنتاج و ابزار و خط لوله ارزیابی است که پیش از انتقال هر عامل به محیط تولید، آن را بررسی می‌کند. در پایان، باید بتوانید با استفاده از طرح مرجع همراه مقاله، یک جریان کاری تحت حاکمیت سازمانی مستقر کنید، انطباق آن با الزامات امنیتی و چرخه عمر را بسنجید و از آن به‌عنوان پایه‌ای برای ساخت پلتفرم اختصاصی هوش مصنوعی عامل‌محور در سازمان خود استفاده کنید.

Amazon Bedrock AgentCore مجموعه‌ای از سرویس‌های ماژولار برای ساخت، استقرار و بهره‌برداری از عامل‌ها در مقیاس گسترده فراهم می‌کند؛ از جمله محیط اجرا، درگاه، هویت، حافظه، سیاست‌گذاری، ثبت در مخزن و ارزیابی. طرح Enterprise Agentic AI Platform Blueprint که بر پایه AgentCore ساخته شده است، زیرساخت‌های موردنیاز سازمان را نیز به‌صورت کد قابل استقرار ارائه می‌دهد؛ از جمله قراردادهای مربوط به مالکیت، مرزبندی حساب‌ها، تحویل نرم‌افزار، مشاهده‌پذیری، حاکمیت هزینه‌ها و بازنشسته‌کردن منابع.

اصول معماری

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

1. دسترسی کنترل‌شده به مدل‌ها: هر درخواست استنتاجی که از منبعی غیرقابل‌اعتماد می‌آید، باید از یک درگاه استنتاج تأییدشده عبور کند. این درگاه، ضوابط حفاظتی سازمان را اعمال می‌کند؛ برای مثال، از Amazon Bedrock Guardrails یا راهکارهای ارائه‌دهندگان ثالث استفاده می‌کند. همچنین مشخص می‌کند هر جریان کاری مجاز به استفاده از کدام مدل‌ها و مناطق جغرافیایی AWS برای استنتاج است و محدودیت نرخ درخواست، سهمیه توکن و بودجه اختصاصی هر جریان کاری را اعمال می‌کند تا یک تیم نتواند ظرفیت مشترک را به‌تنهایی مصرف کند. این درگاه هویت بار کاری را نیز منتقل می‌کند و داده‌های لازم برای انتساب هزینه‌ها را ثبت می‌کند.
2. دسترسی کنترل‌شده به ابزارها: عامل‌ها باید فقط بتوانند ابزارهای تأییدشده را از طریق یک درگاه احرازشده مبتنی بر پروتکل زمینه مدل (MCP) شناسایی و فراخوانی کنند. مقصد دقیق درخواست‌ها، نقش‌های اجرایی با حداقل سطح دسترسی، تصمیم‌های سیاست‌گذاری و مالک قابل‌ممیزی هر ابزار باید مشخص باشند.
3. تحویل مستقل برنامه‌ها: تیم‌های جریان کاری، برای مثال تیم‌های محصول، باید بتوانند بدون انتظار برای استقرار هر برنامه توسط تیم پلتفرم، تغییرات خود را در محدوده‌های از پیش تأییدشده منتشر یا به نسخه قبلی بازگردانند. در عین حال، نباید به توسعه‌دهندگان امکان نوشتن مستقیم در زیرساخت داده شود.
4. عملیات ناوگان عامل‌ها و مدیریت هزینه: چند گروه مختلف باید بتوانند منابع و وضعیت سامانه را در حساب‌های گوناگون مشاهده کنند، بی‌آنکه به منابع متعلق به تیم‌ها دسترسی نوشتن داشته باشند. مهندسان عملیات عامل‌ها به گزارش‌ها، سنجه‌ها، ردگیری‌ها و سهمیه‌ها نیاز دارند. مالکان جریان‌های کاری باید هزینه هر عامل را در مقایسه با بودجه اختصاص‌یافته ببینند. تیم‌های مدیریت مالی فناوری (FinOps) و امور مالی نیز به سازوکار تخصیص هزینه به هر تیم یا واحد کسب‌وکار از طریق AWS Cost Explorer و گزارش هزینه و مصرف AWS (CUR) نیاز دارند. مسئولان امنیت و حاکمیت نیز باید بتوانند مشخص کنند هر بار کاری کدام مدل و ابزار را فراخوانی کرده است.
5. شواهد قابل‌راستی‌آزمایی و چرخه عمر کنترل‌شده: انتشار هر نسخه از عامل باید در تمام مرزهایی که با آن‌ها تعامل دارد، شواهد قابل‌بررسی ارائه کند:
   1. دسترسی به مدل: فراخوانی یک مدل تأییدشده باید موفق باشد و درخواست به مدل یا منطقه تأییدنشده باید رد شود.
   2. دسترسی به ابزار: فراخوانی ابزار ثبت‌شده در اشتراک عامل باید موفق باشد و فراخوانی ابزاری خارج از اشتراک آن باید با خطای مورد انتظار رد شود.
   3. هویت: درخواست صادرشده از حساب یا هویت جریان کاری دیگر باید رد شود.
   4. انتشار نسخه: امکان بازیابی نسخه قبلی محیط اجرای عامل باید وجود داشته باشد.
   5. بازنشسته‌کردن: فرایند حذف باید محیط اجرا، حافظه، درگاه ابزار و مجوزهای ابزار عامل را به ترتیب وابستگی حذف کند و تأیید کند که هیچ منبعی باقی نمانده است.

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

مدل‌های عملیاتی و اجزای پلتفرم

سازمان‌ها معمولاً یکی از سه مدل عملیاتی زیر را برای هوش مصنوعی عامل‌محور انتخاب می‌کنند:

• متمرکز: یک تیم واحد هوش مصنوعی و یادگیری ماشین (AI/ML) تمام عامل‌ها را می‌سازد و اداره می‌کند. این مدل حاکمیت یکپارچه‌ای دارد، اما با افزایش تعداد کاربردها، تیم مرکزی به‌سرعت به گلوگاه تبدیل می‌شود.
• غیرمتمرکز: هر واحد کسب‌وکار عامل‌های خود را می‌سازد و اداره می‌کند. تیم‌ها می‌توانند سریع حرکت کنند، اما نبود استانداردهای مشترک به ناهماهنگی کنترل‌ها، تکرار کارها و کاهش شفافیت هزینه‌ها منجر می‌شود.
• فدرال: تیم مرکزی پلتفرم، سرویس‌های مشترک و تحت حاکمیت را فراهم می‌کند و تیم‌های حوزه‌ای همچنان مالک عامل‌ها، ابزارها و داده‌های خود هستند. این مدل میان استقلال تیم‌ها و اجرای یکپارچه ضوابط حفاظتی تعادل برقرار می‌کند و معمولاً انتخاب نهایی بسیاری از سازمان‌هاست.
• برای انتخاب مدل مناسب، به راهنمای تجویزی AWS درباره مدل‌های حاکمیت مراجعه کنید.

این طرح مرجع با تکیه بر الگوهایی که در همکاری با مشتریان مشاهده شده‌اند، مدل فدرال را پیاده‌سازی می‌کند. تیم پلتفرم نقش مرکز این ساختار را دارد و معمولاً از مدیر محصول پلتفرم، معمار، مهندسان پلتفرم، مهندسان عملیات عامل‌ها و مسئول امنیت و حاکمیت تشکیل می‌شود. تیم‌های جریان کاری در نقش شاخه‌های این ساختار فعالیت می‌کنند و توسعه‌دهندگان عامل، سرپرست فنی حوزه و مهندسان هوش مصنوعی و یادگیری ماشین را در بر می‌گیرند. حامی اجرایی طرح و مدیر ارشد امنیت اطلاعات (CISO) نیز در سطحی بالاتر از هر دو گروه قرار دارند.

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

نمای کلی راهکار

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

در مقیاس سازمانی، صفحه تجربه توسعه‌دهنده شامل فهرستی از قالب‌های عامل نسخه‌بندی‌شده و تأییدشده توسط سازمان است. این طرح مرجع قالب‌هایی برای Strands، LangGraph و CrewAI ارائه می‌دهد؛ بااین‌حال، می‌توان از هر چارچوب دلخواه دیگری نیز استفاده کرد، به شرط آنکه قالب مربوطه همان قراردادهای مربوط به درگاه استنتاج، درگاه ابزار، هویت، سیاست‌گذاری، ارزیابی و تحویل را حفظ کند. تیم‌های برنامه‌نویسی مالک پرامپت‌ها، منطق عامل، ابزارها و موارد آزمون ارزیابی هستند؛ در مقابل، کنترل‌های مشترک و الزامات انتشار را تیم پلتفرم تعیین می‌کند.

از میان چهار صفحه معماری، دو صفحه بیشترین نقش را در ساختار راهکار دارند:

1. صفحه کنترل پلتفرم هوش مصنوعی عامل‌محور: حساب پلتفرم، قالب‌ها و رابط‌های نسخه‌بندی‌شده را منتشر می‌کند، سوابق حاکمیتی AWS Agent Registry و درگاه‌های استنتاج مشترک را مدیریت می‌کند، مدل‌ها و ضوابط حفاظتی را به فرایند پذیرش وارد می‌کند، انتشارهای بازبینی‌شده را هماهنگ می‌سازد و داده‌های عملیاتی کل ناوگان را تجمیع می‌کند. تیم‌ها از طریق کد، توصیف‌گرها و خط لوله‌ها از این قابلیت‌ها بهره می‌برند، نه از طریق نشست‌های مدیریتی یا درخواست‌های دستی استقرار.
2. سلول تکرارپذیر جریان کاری: هر محصول یا حوزه، محیطی ایزوله دریافت می‌کند که شامل مخزن کد منبع تحت مالکیت تیم، خط لوله بار کاری و سه قابلیت Amazon Bedrock AgentCore است: AgentCore Runtime، حافظه AgentCore Memory با محدوده دسترسی مشخص برای هر عامل یا کنشگر و AgentCore Gateway که از مجوزدهی AWS_IAM استفاده می‌کند و فقط مقصدهای ابزار تأییدشده را در دسترس قرار می‌دهد. این سلول همچنین کلیدهای AWS KMS تحت مدیریت مشتری، برچسب‌ها، هشدارها، بودجه‌ها و پیوند منبع CloudWatch Observability Access Manager (OAM) اختصاصی خود را دارد. هر سلول می‌تواند بدون هماهنگی با انتشارهای سایر تیم‌ها، مستقر شود، با شکست مواجه شود، به نسخه قبلی بازگردد یا بازنشسته شود.

اجزای کلیدی

نمودار زیر مدل عملیاتی و جریان کنترل‌شده راهکار را نشان می‌دهد.

معماری از لایه‌های حساب زیر تشکیل شده است:

1. زیربنای مدیریت و حاکمیت: AWS Organizations، سرویس AWS IAM Identity Center، سیاست‌های پیشگیرانه، ممیزی، نگهداری داده‌ها و سیاست‌های هزینه، مرزهای سازمانی را تعیین می‌کنند. این موارد مسئولیت‌های منطقی هستند و می‌توان آن‌ها را در ساختار موجود AWS Control Tower، یعنی محیط پایه امن، از پیش پیکربندی‌شده و مقیاس‌پذیر چندحسابی AWS، پیاده‌سازی کرد؛ بنابراین نیازی به ایجاد ساختار حساب تکراری نیست.
2. لایه امنیت، ممیزی و مشاهده‌پذیری: سرویس‌های AWS CloudTrail، AWS Config، AWS Security Hub و Amazon GuardDuty، به همراه حساب بایگانی گزارش‌ها و مقصد Amazon CloudWatch OAM، شواهد مستقل از وضعیت صفحه کنترل و امکان مشاهده وضعیت کل ناوگان را فراهم می‌کنند. اپراتورهای مرکزی می‌توانند سیگنال‌های مشترک را بررسی کنند، بدون آنکه مجوز نوشتن در منابع جریان‌های کاری را به دست آورند.
3. لایه پلتفرم هوش مصنوعی عامل‌محور: محیط‌های جداگانه پلتفرم، مسیرهای استاندارد توسعه، کاتالوگ حاکمیت، ضوابط حفاظتی، درگاه‌های استنتاج مشترک، نام‌های مستعار دقیق ابزارها، خط لوله‌ها، سازگاری، سهمیه‌ها و رابط‌های عملیاتی مشترک را مدیریت می‌کنند. تغییرات پلتفرم پیش از گسترش در سطح سازمان، روی سلول‌های نماینده آزمایش می‌شوند.
4. لایه ناوگان جریان‌های کاری: برای هر محصول، حوزه یا محدوده دارای الزامات نظارتی، یک یا چند سلول غیرتولیدی و تولیدی ایجاد می‌شود. تیم‌ها مالک محیط اجرا، حافظه، درگاه ابزار، ابزارها، داده‌ها، پرامپت‌ها، موارد ارزیابی، رخدادهای برنامه و اهداف سطح خدمت (SLO) هستند. می‌توان یک خط مبنای یکسان را در سلول‌های متعدد تکرار کرد و در عین حال، جداسازی در سطح حساب را حفظ کرد.

بررسی گام‌به‌گام راهکار

در بخش‌های بعد، تصمیم‌های اصلی طراحی بررسی می‌شوند: ساختار حساب‌ها، کنترل‌های پیشگیرانه و آشکارساز، مسیر اجرای AgentCore و خط لوله تحویل.

ساختار حساب‌ها و واحدهای سازمانی

این طرح مرجع نقش‌های منطقی حساب‌ها را برای جداسازی حاکمیت سازمانی، سرویس‌های مشترک پلتفرم و اجرای تحت مالکیت تیم‌ها تعریف می‌کند:

این ساختار در محیط پایه موجود سازمان، یعنی محیط چندحسابی امن، از پیش پیکربندی‌شده و مقیاس‌پذیر AWS، ادغام می‌شود. برچسب‌های مدیریت، پلتفرم و جریان کاری نشان‌دهنده مسئولیت‌ها هستند، نه الزام به استفاده از دقیقاً سه حساب. سازمان می‌تواند چند محیط معتبر پلتفرم و تعداد زیادی جفت حساب جریان کاری داشته باشد. توصیه می‌شود ابتدا یک سلول نماینده ایجاد کنید و فرایند ورود به پلتفرم، انتقال به تولید، بازگشت به نسخه قبلی، مشاهده‌پذیری متمرکز و بازنشسته‌کردن بدون باقی‌ماندن منابع را در آن به اثبات برسانید؛ سپس همان خط مبنا را در سلول‌های دیگر تکرار کنید.

سیاست‌های کنترلی سرویس

سیاست‌های کنترلی سرویس، حداکثر مجوزهای قابل‌دسترسی برای حساب‌های پلتفرم و جریان‌های کاری را محدود می‌کنند. این سیاست‌ها مکمل IAM، مجوزدهی درگاه‌ها، ضوابط حفاظتی، سیاست‌های منابع، کنترل‌های شبکه و شواهد خط لوله هستند و جایگزین آن‌ها نمی‌شوند. در این طرح مرجع، سیاست‌های مؤثر برای حساب و منطقه جغرافیایی دقیق تولید و بررسی می‌شوند؛ بنابراین، تصمیم‌گیری صرفاً بر اساس آنچه کد منبع قصد انجامش را دارد، کافی نیست.

1. پذیرش مدل و منطقه: سیاست‌های سازمان و نقش‌های اجرایی درگاه، استنتاج را به مدل‌های تأییدشده و مناطق پشتیبانی‌شده محدود می‌کنند. افزودن مدل یا منطقه جدید مستلزم بررسی دسترس‌پذیری سرویس، محل نگهداری داده‌ها، IAM، کیفیت، هزینه، بازگشت به نسخه قبلی، مشاهده‌پذیری و آزمون رد درخواست‌های غیرمجاز است.
2. اعمال ضوابط حفاظتی و کنترل استنتاج: عامل‌ها مستقیماً با ارائه‌دهندگان مدل تماس نمی‌گیرند. تمام درخواست‌های استنتاج از درگاه تحت حاکمیت عبور می‌کنند و ضوابط حفاظتی و فهرست مجاز مدل‌ها در آن اعمال می‌شوند.
3. محدودکردن تغییرات جریان کاری به خط لوله: تیم‌های جریان کاری درخواست ادغام تغییرات کد (Pull Request) ثبت می‌کنند و از خط لوله بار کاری استفاده می‌کنند. استقرار مستقیم توسط توسعه‌دهنده در حساب جریان کاری، خارج از مدل عملیاتی پشتیبانی‌شده است؛ این محدودیت تضمین می‌کند که مسیر انتشار بازبینی‌شده و ثبت شواهد قابل دور زدن نباشد.
4. حاکمیت مخزن و درگاه: اگر سابقه ابزار مورد اشتراک در Registry وجود نداشته باشد، تغییر کرده باشد یا تأیید نشده باشد، فرایند تولید پیکربندی Gateway برای جریان کاری با خطا متوقف می‌شود.
5. نقش‌های محدود استقرار: سیاست‌های راه‌اندازی اولیه برای هر حساب و منطقه به‌صورت جداگانه تولید می‌شوند، با AWS Identity and Access Management Access Analyzer (IAM Analyzer) اعتبارسنجی می‌شوند و از طریق شبیه‌سازی سیاست مؤثر مورد بررسی قرار می‌گیرند. دسترسی مدیر سیستم برای راه‌اندازی اولیه محفوظ است و در اجرای معمول خط لوله به کار نمی‌رود.
6. تفکیک وظایف و آزمون خصمانه: تیم پلتفرم پذیرش مدل‌ها، ضوابط حفاظتی، سوابق Registry و سرویس‌های مشترک را کنترل می‌کند؛ تیم‌های جریان کاری نیز رفتار برنامه را مدیریت می‌کنند. برای هر مسیر مسدودشده، یک فراخوانی مجاز و موفق و یک تغییر آزمایشی همراه آن در نظر گرفته می‌شود تا ثابت شود کنترل موردنظر علت رد درخواست بوده است.

حتی مدیر یک حساب جریان کاری نیز نمی‌تواند از مسیرهای مورد پشتیبانی، راهی میان‌بر برای دورزدن این کنترل‌ها ایجاد کند. سیاست‌های سازمانی جدید یا تغییر‌یافته باید پیش از اعمال گسترده، در محیط آزمایشی یا یک سلول نماینده به‌اندازه کافی آزمایش شوند. آزمون‌های دقیق مجاز و غیرمجاز و برنامه بازگشت به وضعیت قبلی نیز باید آماده باشند.

خط لوله CI/CD همراه با دروازه‌های ارزیابی

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

1. کد منبع و بازبینی: یک درخواست ادغام، نسخه تغییرناپذیر کد منبع را مشخص می‌کند. خط لوله شاخه موردنظر را به‌طور صریح تعیین می‌کند تا تغییر ادغام‌نشده نتواند بی‌سروصدا باعث ساخت نسخه پیش‌فرض مخزن شود.
2. ساخت و تولید پیکربندی: خط لوله کد را کامپایل می‌کند، آزمون‌ها و بررسی‌های کیفیت کد را اجرا می‌کند، مانیفست عامل را می‌سازد، تصویر نرم‌افزاری متصل به شناسه هش را اسکن می‌کند، سیاست‌ها را اعتبارسنجی می‌کند، توصیف‌گرهای تأییدشده Registry را بازیابی می‌کند و خروجی تولیدشده AWS CloudFormation و گزارش‌های cdk-nag را بررسی می‌کند.
3. نقش‌های پایدار و واگذاری مجوزها: خط لوله بار کاری نقش‌های پایدار جریان کاری را ایجاد می‌کند و موقتاً متوقف می‌شود. سپس خط لوله پلتفرم، نام‌های مستعار دقیق ابزارها را به نقش دقیق Gateway اعطا می‌کند. پس از بررسی سیاست‌های فعال، خط لوله بار کاری ادامه می‌یابد.
4. استقرار در محیط غیرتولیدی: خط لوله محیط اجرا، حافظه، درگاه ابزار، مشاهده‌پذیری، هشدارها، بودجه‌ها، برچسب‌ها و منابع برنامه را در محدوده غیرتولیدی سلول مستقر می‌کند.
5. ارزیابی عامل مستقرشده: دروازه ارزیابی، محیط اجرای واقعی عامل را فراخوانی می‌کند و میزان پسرفت، کیفیت، موفقیت ابزارها، رفتار امتناع از درخواست‌های نامجاز، تأخیر دریافت نخستین توکن و هزینه را می‌سنجد. هر فراخوانی مجاز با یک آزمون خصمانه متناظر همراه است: ابتدا مدل تأییدشده فراخوانی و موفقیت آن تأیید می‌شود، سپس فراخوانی مدل تأییدنشده باید رد شود. همین الگو برای ابزارها، هویت بین‌حسابی و محدودسازی نرخ درخواست نیز اجرا می‌شود. اگر درخواست غیرمجاز برخلاف انتظار رد نشود، ساخت نسخه با شکست مواجه خواهد شد.
6. تأیید انسانی: بازبین، شواهد حاصل از اجرای واقعی، محدودیت‌های شناخته‌شده و ریسک باقی‌مانده را بررسی می‌کند. سبزشدن عمومی وضعیت ساخت به‌تنهایی کافی نیست؛ به‌ویژه اگر آزمون الزامی، منبع موردنیاز یا رد درخواست غیرمجاز مطابق انتظار انجام نشده باشد.
7. انتقال به تولید، پایش و بازگشت: انتقال به محیط تولید بر اساس نسخه بازبینی‌شده و بررسی‌های تداوم سرویس انجام می‌شود. نشست‌های محیط اجرا در مراحل به‌روزرسانی، لغو، بازگشت به نسخه قبلی، بازیابی و اجرای مجدد نمونه‌برداری و بررسی می‌شوند تا خط لوله هم مسیر پیشرفت و هم مسیر بازیابی را اثبات کند.

هیچ مرحله‌ای از استقرار جریان کاری، مسیر دستی و میان‌بری ندارد. تیم پلتفرم قرارداد انتشار را تعیین می‌کند، اما تیم‌های جریان کاری نمونه‌های اختصاصی خط لوله خود را اداره می‌کنند و زمان‌بندی انتشارشان را مستقلاً تعیین می‌کنند. بازنشسته‌کردن منابع نیز از ترتیب وابستگی مشخصی پیروی می‌کند: ابتدا مجوزهای نام مستعار در پلتفرم لغو می‌شوند، سپس Gateway و نقش‌های ابزار در جریان کاری حذف می‌شوند و در ادامه، محیط اجرا، حافظه و منابع برنامه از بین می‌روند. هر مرحله پیش از رفتن به مرحله بعدی بررسی می‌شود و در پایان، فهرست‌برداری نهایی تأیید می‌کند که هیچ منبعی باقی نمانده است.

امنیت و حاکمیت

این طرح مرجع با ترکیب کنترل‌های هویت، سیاست‌گذاری، تحویل نرم‌افزار، داده و شواهد، رویکرد دفاع در عمق را پیاده‌سازی می‌کند:

1. هویت و مرزهای اعتماد: قابلیت AgentCore Identity در Amazon Bedrock AgentCore و سرویس Amazon Cognito، اعتبارنامه‌های موقت برای استنتاج فراهم می‌کنند. ترافیک ابزارها با AWS_IAM و امضای SigV4 احراز هویت می‌شود. نقش‌های دقیق Runtime و Gateway، بررسی صادرکننده و مخاطب توکن، زمینه حساب و منطقه و محدودکردن اعتماد هنگام راه‌اندازی، هر هویت را به مسیر موردنظر خود محدود می‌کنند.
2. ایمنی مدل و پذیرش: تمام درخواست‌های استنتاج از درگاه تحت حاکمیت که در بخش نمای کلی راهکار توضیح داده شد عبور می‌کنند؛ در این مسیر، ضوابط حفاظتی و فهرست مجاز مدل‌ها پیش از هر فراخوانی اعمال می‌شوند.
3. مجوزدهی ابزارها: درگاه ابزار فقط نام‌های مستعار تأییدشده در Registry را فراخوانی می‌کند؛ این سازوکار نیز در بخش نمای کلی راهکار شرح داده شده است. سیاست‌های Cedar مجوزدهی را انجام می‌دهند و یک پوشش مبتنی بر AWS Lambda برای تقویت دفاع در عمق حفظ می‌شود.
4. حفاظت از داده‌های مستأجران: حساب‌های جریان کاری، وضعیت و داده‌های برنامه را از یکدیگر جدا می‌کنند. حافظه AgentCore از فضای نام مختص هر کنشگر و کلیدهای KMS تحت مدیریت مشتری استفاده می‌کند. ابزارها و داده‌های برنامه تحت مالکیت تیم‌ها باقی می‌مانند و سیاست‌های نگهداری، حذف و دسترسی به‌طور صریح تعریف می‌شوند؛ این سیاست‌ها از یک حساب مشترک و قابل‌تغییر برای بارهای کاری به ارث برده نمی‌شوند.
5. زنجیره تأمین نرم‌افزار و انتشار: کد منبع بازبینی‌شده، هش‌گذاری مانیفست، ساخت‌های تکرارپذیر، اسکن تصاویر متصل به شناسه هش، اعتبارسنجی سیاست‌ها، بررسی‌های cdk-nag، ارزیابی محیط اجرای مستقرشده، تأیید انسانی، بازگشت به نسخه قبلی و حذف منابع به ترتیب وابستگی، همگی بخشی از یک قرارداد واحد انتشار هستند. در صورت فقدان هر بررسی الزامی، فرایند به‌صورت ایمن متوقف می‌شود.
6. ممیزی، مشاهده‌پذیری و حاکمیت هزینه: CloudTrail و داده‌های نگهداری‌شده صفحه کنترل، شواهد ثبت‌شده در خط لوله را تأیید می‌کنند. OAM گزارش‌ها، سنجه‌ها و ردگیری‌ها را با اپراتورهای مرکزی به اشتراک می‌گذارد. برچسب‌های استاندارد تخصیص هزینه، بودجه‌ها، سهمیه‌ها و تطبیق گزارش هزینه و مصرف AWS، امکان تعیین مالکیت هزینه‌ها را فراهم می‌کنند، بی‌آنکه عامل بتواند داده‌های مربوط به انتساب هزینه خودش را تغییر دهد.

این مخزن یک پیاده‌سازی مرجع است و توسعه‌دهندگان می‌توانند آن را مطابق نیازهای خود تغییر دهند. استقرار و قابلیت‌های موجود بر اساس منطقه eu-west-1 (ایرلند) ارائه شده‌اند. استفاده از یک جزء جایگزین، استقرار در منطقه‌ای دیگر یا گسترش راهکار در سطح وسیع‌تر سازمان، مستلزم تهیه شواهد مستقل درباره دسترس‌پذیری، امنیت، بار کاری، بازگشت به نسخه قبلی، مشاهده‌پذیری و حذف منابع است.

جمع‌بندی

در این مقاله، پلتفرمی سازمانی برای هوش مصنوعی عامل‌محور بر پایه Amazon Bedrock AgentCore بررسی شد. این معماری، صفحه کنترل پلتفرم تحت حاکمیت متمرکز را از سلول‌های تکرارپذیر و تحت مالکیت تیم‌ها جدا می‌کند، برای استنتاج و ابزارها درگاه‌های مستقلی در نظر می‌گیرد و انتقال به محیط تولید را به ارزیابی عامل در محیط اجرای واقعی مشروط می‌سازد.

مخزن همراه مقاله شامل طرحی مرجع است که این کنترل‌ها را از ابتدا تا انتها اعتبارسنجی می‌کند؛ از دروازه‌های خط لوله و آزمون‌های خصمانه مرزهای دسترسی گرفته تا حذف منابع بدون باقی‌ماندن هیچ اثری. ادعای پشتیبانی این راهکار به همان محدوده‌ای محدود است که در آزمون‌ها اعتبارسنجی شده است.

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

منابع مرتبط:

1. طرح مرجع پلتفرم سازمانی هوش مصنوعی عامل‌محور در گیت‌هاب
2. معماری سازمانی چندحسابی برای اجرای هوش مصنوعی عامل‌محور در محیط تولید AWS؛ راهنمای تجویزی
3. کارگاه ساخت پلتفرم سازمانی هوش مصنوعی عامل‌محور با Amazon Bedrock AgentCore
4. مستندات Amazon Bedrock AgentCore

درباره نویسندگان