آبان
اخبار
گوگل برای هر ایجنت هوش مصنوعی یک کامپیوتر اختصاصی ساخت؛ Agent Compute Engine چیست؟
گوگل کلود در کنفرانس AGNTCon و MCPCon سرویسی به نام Agent Compute Engine معرفی کرد که به هر ایجنت هوش مصنوعی یک ماشین مجازی ایزوله، پایدار و بدون هیچ رمز و کلیدی می‌دهد؛ زیرساختی که از قبل پشت Gemini و Antigravity کار می‌کند.
لیست مطالب
۱. ماجرا چیست و کجا اعلام شد؟
شرکت گوگل کلود روز پنجشنبه ۲۲ اکتبر ۲۰۲۶ (۳۰ مهر ۱۴۰۵) در کنفرانس AGNTCon و MCPCon بنیاد لینوکس در شهر سن‌خوزه از سرویس تازه‌ای رونمایی کرد. نام این سرویس Agent Compute Engine است و هدفش روشن است: هر ایجنت هوش مصنوعی باید کامپیوتر مخصوص خودش را داشته باشد، نه این‌که چند ایجنت یا چند کاربر روی یک محیط مشترک کار کنند.
گوگل می‌گوید این زیرساخت تازه نیست و از قبل ایجنت Gemini برای کارهای سازمانی، ابزار Antigravity و خط‌لولهٔ آموزش مدل‌های خود این شرکت را اجرا می‌کند. تازگی ماجرا این است که حالا قرار است همین پلتفرم به‌صورت سرویس ابری در اختیار مشتریان Google Cloud قرار بگیرد. اگر دربارهٔ ایجنت سازمانی گوگل پیش‌تر خوانده‌اید، بخش اخبار مستر چت‌جی‌پی‌تی پوشش کامل آن را دارد.
۲. چرا ایجنت‌ها به کامپیوتر اختصاصی نیاز دارند؟
چت‌بات‌های معمولی فقط متن تولید می‌کنند، اما ایجنت‌ها کار انجام می‌دهند: فایل می‌سازند، کد اجرا می‌کنند، وب را مرور می‌کنند و با ابزارهای مختلف حرف می‌زنند. برای این کارها باید جایی وجود داشته باشد که دستورها در آن اجرا شود. اگر این محیط مشترک یا ناایمن باشد، یک دستور اشتباه یا یک حملهٔ تزریق پرامپت می‌تواند به داده‌های دیگران برسد.
راه‌حل سنتی این بود که هر ایجنت داخل یک کانتینر اجرا شود. کانتینر سریع است اما هستهٔ سیستم‌عامل را با دیگران شریک می‌شود. ماشین مجازی ایزوله امن‌تر است ولی معمولاً سنگین و کند. گوگل می‌خواهد سرعت کانتینر را با امنیت سندباکس ترکیب کند و برای همین به سراغ microVM رفته است. برای آشنایی با مفهوم هوش مصنوعی و کاربردهای واقعی آن می‌توانید مقالهٔ توانایی‌ها و محدودیت‌های هوش مصنوعی در دنیای واقعی را بخوانید.
۳. معماری «مغز و دست‌ها»
در طراحی گوگل هر ایجنت به دو بخش تقسیم می‌شود. بخش اول «مغز» یا همان harness است که مدل را صدا می‌زند و کاملاً بیرون از سندباکس اجرا می‌شود. بخش دوم «دست‌ها» یعنی سندباکسی است که کد، دستورهای شل و مرورگر را اجرا می‌کند. مغز فقط دستورهای مشخص را به سندباکس می‌فرستد و نتیجه را برمی‌گرداند.
این جداسازی مهم است، چون اگر مهاجم سندباکس را بگیرد، به مغز ایجنت و اعتبارنامه‌هایش دسترسی پیدا نمی‌کند. هر نشست یک microVM تک‌مستأجره دارد که پشت مرز Cloud Hypervisor اجرا می‌شود، هستهٔ مهمان مخصوص خودش را دارد، دسترسی روت می‌دهد و از فضای ذخیره‌سازی Hyperdisk استفاده می‌کند.
۴. امنیت: فرض کنید مهاجم همه‌چیز را در دست دارد
اصل راهنمای تیم گوگل این است که باید فرض کرد مهاجم می‌تواند هر چیزی داخل سندباکس را کنترل کند. بنابراین هیچ رمز، کلید یا اعتبارنامه‌ای در حافظه یا دیسک ماشین نگهداری نمی‌شود. ماشین فقط یک گواهی SPIFFE مخصوص همان نشست و یک توکن هویت کوتاه‌مدت دارد که از طریق یک شنوندهٔ محلی به آن می‌رسد.
ماشین رابط شبکهٔ معمولی، دروازهٔ پیش‌فرض یا دسترسی مستقیم به VPC ندارد. تمام ترافیک از مسیر virtio-vsock به یک پروکسی محلی و از آنجا به Agent Gateway بیرونی می‌رود. دروازه ابتدا اجازهٔ کاربر و هویت سندباکس را بررسی می‌کند و سپس اعتبارنامهٔ واقعی سرویس مقصد را بیرون از سندباکس اضافه می‌کند. یعنی حتی اگر ایجنت فریب بخورد، کلیدی برای دزدیدن وجود ندارد.
میزبان‌ها هم بدون حالت (stateless) هستند و سیستم فایل ریشهٔ آن‌ها فقط‌خواندنی است و با dm-verity تأیید می‌شود. سخت‌افزار و فرم‌ور در هر بوت به‌صورت رمزنگاری‌شده راستی‌آزمایی می‌شود و کل پشته روی تراشهٔ Titan و پردازندهٔ Titanium IPU تکیه دارد. ترافیک در مسیر و اسنپ‌شات‌ها و دیسک‌ها در حالت ذخیره رمزنگاری می‌شوند.
۵. چهار هویت برای هر ایجنت
گوگل برای هر ایجنت چهار هویت متفاوت تعریف کرده است. هویت اول خود کاربر است. هویت دوم مجوز تفویض‌شده به نمایندگی از کاربر (on-behalf-of) است که در یک سرویس مجوزدهی مرکزی نگهداری می‌شود و نه روی نود. هویت سوم Agent Workload Identity است که تنها هویت مورد استفاده برای ترافیک سندباکس است. هویت چهارم Agent Workforce Identity است که مثل یک حساب کارمند برای خود ایجنت و منابعش عمل می‌کند.
این تفکیک به مدیران امنیت اجازه می‌دهد دقیقاً بدانند هر عمل را چه کسی، با چه مجوزی و از طرف چه کسی انجام داده است. برای سازمان‌هایی که ایجنت‌ها را در فرایندهای کاری جدی به‌کار می‌گیرند، همین ردپای قابل‌حسابرسی اهمیت زیادی دارد؛ دربارهٔ اهمیت این موضوع در کسب‌وکار می‌توانید مقالهٔ اهمیت هوش مصنوعی در کسب‌وکار را ببینید.
۶. چک‌پوینت و صرفه‌جویی در منابع
ایجنت‌ها بیشتر وقتشان را در انتظار پاسخ مدل یا کاربر می‌گذرانند. اگر ماشین در این مدت روشن و فعال بماند، هزینه و منابع هدر می‌رود. در ACE بعد از هر فراخوانی ابزار، میزبان از microVM چک‌پوینت می‌گیرد و ماشین تا فراخوانی بعدی صفر منبع فعال مصرف می‌کند. با درخواست بعدی، ماشین از همان نقطه از سر گرفته می‌شود.
تراکم بالا از اشتراک حافظه به روش copy-on-write می‌آید: تصاویر اسنپ‌شات از پیش‌گرم‌شده با DAX نگاشت می‌شوند تا ماشین‌ها صفحه‌های سیستم‌عامل و کتابخانه‌های پایه را به اشتراک بگذارند. به گفتهٔ گزارش‌ها، harnessها امکان کلون، اسنپ‌شات و فورک، بازگشت به عقب (rewind) و رولبک دارند. فضای ذخیره‌سازی نیز سه لایه دارد: لایه‌های موقت دور‌ریختنی، حجم‌های اشتراکی فقط‌خواندنی و فضای کاری پایدار روی Hyperdisk. گوگل هنوز عددهای زمان بوت، تراکم یا زمان ازسرگیری ACE را منتشر نکرده است.
۷. Agent Substrate؛ نسخهٔ متن‌باز برای Kubernetes
همزمان با ACE، گوگل نسخهٔ متن‌باز و Kubernetes-محور Agent Substrate را هم معرفی کرد که از ۱۵ سپتامبر ۲۰۲۶ روی GKE در دسترس است و با هر سندباکس microVM یا gVisor کار می‌کند. کدش روی گیت‌هاب است و با harnessهایی مانند Claude Code، OpenClaw و Hermes شرکت Nous Research سازگار است.
گوگل ادعا می‌کند Agent Substrate تا ۱۰ برابر تراکم محاسباتی بیشتر از محاسبات سنتی می‌دهد و بیش از هزار ایجنت خوابیده را روی هر میزبان نگه می‌دارد. در یک بنچمارک با ۲۰۰ هزار ایجنت، سیستم ۵۰۰ فعال‌سازی در ثانیه را پشتیبانی کرده و تعلیق و ازسرگیری ایجنت‌ها کمتر از نیم ثانیه طول کشیده است. این عددها از خود گوگل است و مستقل تأیید نشده‌اند. برای استفادهٔ غیرتولیدی برای همهٔ مشتریان GKE باز است، اما نسخهٔ تولیدی فعلاً فقط با فهرست مجاز (allowlist) در دسترس قرار می‌گیرد.
۸. مقایسه با AWS، Azure و E2B
گوگل تنها بازیگر این میدان نیست. AWS Bedrock AgentCore Runtime برای هر نشست یک microVM اختصاصی می‌دهد و طول نشست را تا ۸ ساعت برای microVMها و تا ۱۴ روز برای Instances پشتیبانی می‌کند. سرویس dynamic sessions در Azure از سندباکس Hyper-V برای هر نشست استفاده می‌کند و تخصیص را در حد میلی‌ثانیه از استخرهای پیش‌گرم‌شده انجام می‌دهد. شرکت E2B هم بر پایهٔ Firecracker کار می‌کند و ازسرگیری آن حدود یک ثانیه طول می‌کشد.
در میان این گزینه‌ها ACE تنها سرویسی است که متن‌باز نیست؛ هرچند نسخهٔ Substrate آن متن‌باز است. برای توسعه‌دهندگانی که می‌خواهند مدل‌ها و ابزارها را مقایسه کنند، نبرد ChatGPT و DeepSeek در شطرنج نمونهٔ جالبی از سنجش عملی مدل‌هاست.
۹. حاکمیت ایجنت‌ها (Agent Governance) هم گسترش می‌یابد
گوگل علاوه بر ACE، حاکمیت ایجنت‌های Gemini Enterprise را به Agent Runtime، Cloud Run، Agent Sandboxes، GKE و ACE گسترش می‌دهد. این مجموعه شامل Agent Gateway، Agent Registry، Agent Identity و مشاهده‌پذیری مبتنی بر OpenTelemetry است. چند قابلیت به‌زودی در پیش‌نمایش می‌آیند، از جمله نقاط اعمال سیاست مبتنی بر Envoy برای محیط‌های چندابری و ترکیبی و حاکمیت بر ایجنت‌های کدنویسی محلی مانند Claude Code و Antigravity CLI روی دستگاه‌های مدیریت‌شده.
در همین سه‌ماههٔ جاری، مدیریت توکن، مسیریابی مدل، اتصال Service Extensions و Express Link برای Cloud Run نیز به پیش‌نمایش می‌رسد. همچنین مجوزدهی تفویضی با شرکت‌های Ping Identity، SailPoint و Saviynt عرضه می‌شود. پیام گوگل روشن است: ایجنت‌ها باید مثل کارمندان دیجیتال با هویت، مجوز و گزارش‌گیری مدیریت شوند.
۱۰. برای کاربران و توسعه‌دهندگان فارسی‌زبان چه معنایی دارد؟
برای کاربر عادی، این خبر یعنی ایجنت‌هایی که کارهای واقعی انجام می‌دهند قرار است امن‌تر شوند. بزرگ‌ترین ترس دربارهٔ ایجنت‌ها این است که با یک دستور مخرب کلیدهای شما را بدهند یا به سیستم‌های دیگر نفوذ کنند. ACE دقیقاً برای کاهش این ریسک طراحی شده است. اگر تازه با پرامپت‌نویسی شروع کرده‌اید، راهنمای نوشتن پرامپت برای مبتدیان و آموزش‌های ChatGPT نقطهٔ شروع خوبی هستند.
برای توسعه‌دهندگان، نکتهٔ کلیدی الگوی طراحی است: اعتبارنامه‌ها بیرون از محیط اجرای ایجنت بمانند، ترافیک از یک دروازهٔ سیاست‌گذار بگذرد و هر ایجنت هویت جدا داشته باشد. حتی اگر از ACE استفاده نکنید، این الگو را می‌شود با ابزارهای دیگر پیاده کرد. البته هنوز باید واقع‌بین بود؛ همان‌طور که در مقالهٔ توهم توسعه‌دهندهٔ تنها در برابر مهندس واقعی گفته‌ایم، ابزار هوش مصنوعی جای مهندسی دقیق را نمی‌گیرد.
۱۱. پرسش‌های پرتکرار
Agent Compute Engine چیست؟
سرویسی از Google Cloud که به هر ایجنت هوش مصنوعی یک microVM ایزوله با هستهٔ مخصوص می‌دهد تا کد، شل و مرورگر را امن اجرا کند.
چه زمانی در دسترس می‌شود؟
گوگل پیش‌نمایش را برای ماه‌های پیش‌رو برنامه‌ریزی کرده است. تاریخ دقیق، قیمت و API عمومی هنوز اعلام نشده و علاقه‌مندان می‌توانند از فرم ثبت‌نام پیش‌نمایش استفاده کنند.
تفاوت ACE و Agent Substrate چیست؟
ACE سرویس مدیریت‌شدهٔ Google Cloud است، ولی Agent Substrate نسخهٔ متن‌باز و Kubernetes-محور است که همین حالا روی GKE برای استفادهٔ غیرتولیدی در دسترس است.
آیا ایجنت داخل ماشین به رمزها دسترسی دارد؟
خیر. ماشین هیچ اعتبارنامهٔ بلندمدتی ندارد و اعتبارنامهٔ واقعی را دروازهٔ ایجنت بیرون از سندباکس و پس از بررسی سیاست‌ها اضافه می‌کند.
آیا این سرویس برای مشتریان ایرانی قابل استفاده است؟
سرویس‌های Google Cloud معمولاً با محدودیت‌های تحریمی همراه هستند و گوگل دربارهٔ ACE هنوز جزئیات دسترسی منطقه‌ای را اعلام نکرده است. بهتر است شرایط رسمی را هنگام انتشار پیش‌نمایش بررسی کنید.
نسخهٔ فوری این مطلب در تلگرام: اینجا بخوانید
