Cloudflare Workers · Containers · August 3, 2026

عنوان: Your agent needs a computer, not a container — introducing @cloudflare/computer 🚀

بسیاری از قوی‌ترین agentها یک نقطه مشترک ساده دارند: به آن‌ها یک “computer” اختصاصی داده می‌شود تا با آن کار کنند. منظور از “computer” در اینجا چیزی فراتر از یک کانتینر ساده است — یک محیط کامل شامل filesystem، shell، ابزارها و بسته‌ها که امکان اجرای کد، بازرسی محیط، اعمال تغییرات، و آزمون نتایج را فراهم می‌کند.

در عمل، همین مدل را برای coding agents می‌بینیم: به agent اجازه می‌دهند تا در یک محیط واقعی کار کند، تغییر ایجاد کند، تست بگیرد و ادامه دهد. داشتن چنین محیطی به مدل یک روش ملموس برای تعامل با “جهان” می‌دهد و به آن کمک می‌کند تا عملکردی مشابهِ یک توسعه‌دهنده یا اپراتور واقعی داشته باشد.

امروز یک پیش‌نمایش اولیه از @cloudflare/computer منتشر شده است. این package یک runtime برای agentها فراهم می‌کند که جزئیات اجرایی مانند اینکه کد در یک isolate، در یک container sandbox یا در web browser اجرا شود را به عهده پلتفرم می‌گذارد. نتیجه این است که هر agent یک “computer” دارد و runtime تلاش می‌کند کارایی و مقیاس‌پذیری را بهینه کند.

نکته کلیدی این است که برای پاسخ به نیاز رو به رشد محاسباتی سیستم‌های agentic نمی‌توان تنها به مدل‌های سنتی containerization بسنده کرد. ایجاد یک کانتینر مجزا برای هر agent، وقتی تعداد agentها بالا می‌رود، از نظر منابع و هزینه مشکل‌ساز می‌شود — در تمام cloudها و hyperscalers ظرفیت لازم برای این رویکرد وجود ندارد.

در چند ماه گذشته شاهد یک تکامل تدریجی بودیم: اوایل سال معمولاً یک کانتینر ساخته می‌شد و agent داخل آن اجرا می‌شد. اخیراً رویکردهای جدیدی رایج شده که harnessها اجرای کد را در sandboxها از طریق ابزارها فراهم می‌کنند؛ این جداکردنِ “دست‌ها” (sandbox که کار انجام می‌شود) از “مغز” (agent loop) است. به عبارت دیگر، harness محیط ایزوله‌ای برای انجام وظایف فراهم می‌کند و خود حلقه عامل در سطح بالاتر تصمیم‌گیری می‌کند.

این جداسازی مزایا و چالش‌هایی دارد: مزیتش کاهش سربار و امکان اجرای ایمن‌تر کدهای ناشناس است، اما اگر برای هر agent یک کانتینر کامل راه‌اندازی کنیم، از نظر مقیاس و هزینه به بن‌بست می‌خوریم. راه‌حل‌هایی مثل @cloudflare/computer تلاش می‌کنند با ارائه primitives مناسب و runtime بهینه، تعادل میان ایزولاسیون امنیتی و کارایی منابع را حفظ کنند تا بتوان agentهای بیشتر و پیچیده‌تری را با هزینه منطقی اجرا کرد.

برای تیم‌های SRE/DevOps، این یعنی فرصت برای بازتعریف نحوه اورکستراسیون، تخصیص منابع و سیاست‌های ایزولاسیون: به‌جای ایجاد هزار کانتینر سنگین، می‌توان روی runtimeهای سبک‌تر و specialized برای agentها سرمایه‌گذاری کرد که هم ایمنی لازم را فراهم کنند و هم هزینه و پیچیدگی را پایین بیاورند. ✅

اگر می‌خواهید درباره نحوه عملکرد runtimeها، تفاوت isolate vs container، یا تاثیر این مدل بر observability و هزینه‌ها جزئیات بیشتری داشته باشید، می‌تونم بیشتر توضیح بدم و نمونه‌های عملی یا چک‌لیست مهاجرتی آماده کنم. 🙂