عامل‌های OpenAI داخل AWS اجرا می‌شوند؛ پیش‌نمایش فقط در سه منطقه است

AWS در اعلام عرضهٔ ۲۹ سپتامبر ۲۰۲۶، پیش‌نمایش عمومی Amazon Bedrock Managed Agents، محصول مشترک خود با OpenAI، را برای سه منطقهٔ ویرجینیای شمالی، اورگن و اوهایو در دسترس قرار داد. مدل‌های پشتیبانی‌شدهٔ OpenAI و نشست عامل در Bedrock مدیریت می‌شوند؛ فرمان‌ها و ابزارهای عامل در محیط محاسباتی انتخابی مشتری اجرا می‌شوند. AWS برای خود سرویس در دورهٔ پیش‌نمایش هزینهٔ افزوده‌ای نمی‌گیرد، اما استنتاج مدل و منابع زیرساختی مصرف‌شده هزینه دارند.

این مرز برای تیمی که عامل را به فایل‌ها، ابزارها یا سامانه‌های خود وصل می‌کند تعیین‌کننده است. Bedrock گفت‌وگو و تعامل با مدل را اداره می‌کند، در حالی که محل اجرای ابزار می‌تواند میزبان خود مشتری یا AgentCore Runtime در حساب AWS او باشد. بنابراین محل اجرای مدل، اختیار یک فرمان و محل نگهداری فایل حاصل از آن را باید جداگانه شناخت.

نشست عامل در Bedrock چگونه کار می‌کند؟

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

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

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

نقشهٔ مسئولیت میان AWS، مشتری و AgentCore

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

• Bedrock و AWS: وضعیت گفت‌وگو، تعامل با مدل و اقلام نشست را مدیریت می‌کنند. سرویس با نقش نشستِ تعریف‌شده از سوی مشتری عملیات مجاز، از جمله فراخوانی مدل، را انجام می‌دهد. فعالیت APIهای پشتیبانی‌شده در CloudTrail ثبت می‌شود؛ این ثبت، گزارش کامل کارهای درون میزبان اجرای ابزار نیست.
• برنامه و حساب مشتری: برنامه نشست را ایجاد می‌کند، پیام‌ها را می‌فرستد و نتیجه را می‌خواند. مشتری دستورها، ابزارهای قابل دسترس و نقش‌های IAM را تعیین می‌کند و برای فراخواننده مجوز واگذاری نقش نشست را می‌گذارد. وقتی ابزار روی میزبان خود او اجرا شود، فایل‌ها، اعتبارنامه‌ها، دسترسی شبکه و نگهداری آن میزبان نیز در اختیار اوست.
• AgentCore Runtime: در صورت انتخاب، محل اجرای فرمان و ابزار در حساب AWS مشتری است. Runtime هویت اجرایی جداگانه‌ای برای اتصال و دسترسی به منابع محیط خود دارد؛ نقش نشست Bedrock جانشین آن نمی‌شود. فضای ذخیره‌سازی و شبکه‌ای که برای این Runtime ساخته می‌شوند نیز منابع همان محیط‌اند و می‌توانند پس از پایان یک نوبت کار باقی بمانند.

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

حذف نشست چه اثری بر فایل‌ها دارد؟

راهنمای Bedrock Managed Agents چرخهٔ عمر گفت‌وگوی مدیریت‌شده را از فایل‌های محیط اجرا جدا می‌داند: حذف نشست، فایل‌های ذخیره‌شده روی میزبان مشتری یا در مخزن S3 او را حذف نمی‌کند. نشست، سابقهٔ پیام‌ها و اقلام کار عامل را نگه می‌دارد؛ فایل تولیدشده در فضای ذخیره‌سازی‌ای باقی می‌ماند که برای اجرای ابزار انتخاب شده است. این تفاوت حتی وقتی ابزار در AgentCore Runtime اجرا شود برقرار است، زیرا منابع ذخیره‌سازی آن در حساب مشتری قرار دارند.

در نتیجه، سیاست حذف داده باید هر محل نگهداری را جداگانه پوشش دهد. اگر ابزار علاوه بر ساختن فایل، داده‌ای را در سامانهٔ بیرونی نوشته باشد، پایان گفت‌وگو آن نسخه را هم از میان نمی‌برد. از سوی دیگر، باقی‌ماندن نشست تضمین نمی‌کند که فایل فضای کار همیشه در دسترس بماند؛ دوام آن به تنظیمات میزبان یا ذخیره‌سازی Runtime بستگی دارد.

مرز عرضهٔ منطقه‌ای و هزینهٔ پیش‌نمایش

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

وضعیت پیش‌نمایش عمومی به معنی تثبیت قابلیت‌ها و APIها نیست و این اجزا ممکن است تغییر کنند. همچنین نبود هزینهٔ افزوده برای خود Managed Agents به معنی رایگان‌بودن کار عامل نیست: استنتاج مدل، محاسبات محیط اجرا و منابعی مانند ذخیره‌سازی و شبکه همچنان در صورت مصرف هزینه دارند. دامنهٔ مناطق پشتیبانی‌شده و قیمت خود سرویس پس از پیش‌نمایش، بر هزینه و محل استقرار نهایی چنین معماری اثر خواهند گذاشت.

بیشتر بخوانید:

• تأیید انسانی برای عامل‌ها بسازید؛ توقف را فقط پیش از کار پرخطر بگذارید
• GraphRAG یا Vector RAG؛ گراف فقط در پرسش‌های چندمرحله‌ای جلو می‌افتد
• Passkey یا اپ احراز هویت؛ فقط یکی در برابر فیشینگ طراحی شده است