۴.۸ میلیثانیه؛ این عدد همان زمان «راهاندازی سرد» (Cold Start) است که یک تغییر ساختاری در نحوه استقرار کدهای خودکار توسط توسعهدهندگان ایجاد میکند. اگر محصول شما را با تأخیری در حد چند میلیثانیه میسنجند، باید بدانید که agentOS اجازه میدهد عاملهای هوش مصنوعی بهجای اجرا در کانتینرهای خارجی، بهصورت یک کتابخانه در پسزمینه Node.js اجرا شوند. این رویکرد که توسط Rivet Dev منتشر شده است، دقیقاً گلوگاههای زیرساختی یعنی تأخیر (Latency) و هزینه را هدف قرار داده است که در حال حاضر جریانهای کاری عاملمحور (Agentic Workflows) را دچار مشکل کرده است. این پروژه به عنوان مقاله شماره ۱۳۷ در سری «هر روز یک پروژه متنباز» معرفی شده است.
اجرای یک عامل هوش مصنوعی معمولاً به یک محیط ایزولهشده یا سندباکس (Sandbox) برای امنیت نیاز دارد. در استانداردهای فعلی صنعت، ابزارهایی مثل E2B یا Daytona از میکرو-ماشینهای مجازی (microVMs) استفاده میکنند که حداقل ۱ گیگابایت حافظه میبلعند و بوت شدن آنها صدها میلیثانیه زمان میبرد. برای یک توسعهنده، این به معنای پرداخت هزینه برای یک CPU مجازی کامل است، حتی اگر فقط بخواهد یک دستور ساده مانند ls را اجرا کند. این وضعیت شبیه این است که برای یک شب اقامت، بهجای اجاره یک تخت در خوابگاه، مجبور شوید یک خانه کامل را اجاره کنید. agentOS این الگو را میشکند و سیستمعامل را در قالب یک کتابخانه به عاملها میدهد.
بر اساس دادههای اندازهگیری شده توسط تیم توسعه در ۳۰ مارس ۲۰۲۶، agentOS در مقایسه با سریعترین سندباکسهای رایج، ۹۲ برابر سرعت بیشتری در راهاندازی سرد دارد. این سیستم بهجای یک سیستمعامل کامل، از V8 Isolates (محیطهای ایزولهای که موتور جاوااسکریپت کروم برای اجرای سریع کدها به کار میبرد) و WebAssembly (Wasm) برای ایجاد یک محیط اجرای سبک استفاده میکند. نتیجه این تغییر، کاهش کف حافظه از ۱۰۲۴ مگابایت به تنها ۲۲ مگابایت برای دستورات ساده شل است؛ این یعنی به طور مؤثر ۴۷ برابر حافظه کمتر و ۲۵۴ برابر ارزانتر از سندباکسهای سنتی. این بهینهسازی در لایه اجرا، گامی در جهت رفع محدودیتهایی است که پیشتر در تحلیلهای مربوط به برتری اپلیکیشنهای دسکتاپ بر سندباکسهای ابری برای کاربردهای تککاربره مورد بحث قرار گرفته بود.
معماری و ادغام
این سامانه بهصورت یک بسته npm تحت عنوان @rivet-dev/agentos توزیع شده است. هسته اصلی آن برای حداکثر کارایی با زبان Rust و SDK آن با TypeScript نوشته شده است. عملکرد این سیستم به این صورت است که یک هسته مجازی را مستقیماً در فرآیند میزبان جاسازی میکند، و این بدان معناست که هیچ جابهجایی دادهای در شبکه (Network Hop) برای ارتباط با عامل مورد نیاز نیست. برای شروع، توسعهدهندگان بسته @rivet-dev/agentos و یک بسته عامل مانند @agentos-software/pi را نصب میکنند، VM و رجیستری را در یک فایل سرور مقداردهی اولیه کرده و از طریق یک کلاینت با استفاده از یک نقطه اتصال مشخص (مانند http://localhost:6420) متصل میشوند.
طبق مستندات فنی، ویژگیهای کلیدی این معماری عبارتاند از:
- V8 Isolates: کدهای جاوااسکریپت مهمان بر روی V8 بومی با کامپایل کامل JIT اجرا میشوند.
- WebAssembly: ابزارهای کامپایلشده بهصورت باینریهای Wasm اجرا میگردند.
- فرآیند Sidecar: یک فرآیند مورد اعتماد، هسته مجازی شامل سیستم فایل مجازی، جدول فرآیندها، لولهها (Pipes)، PTYها و یک پشته شبکه مجازی را مدیریت میکند.
- سیستم Proxy: تمام فراخوانیهای سیستم (Syscalls) مهمان از طریق Sidecar پروکسی میشوند؛ بنابراین هیچیک از اقدامات مهمان مستقیماً سختافزار واقعی میزبان را لمس نمیکند.
- اشتراک منابع: چندین VM از یک فرآیند Sidecar مشترک استفاده میکنند. هر VM اضافی تنها هزینه یک V8 isolate به علاوه وضعیت هسته را تحمیل میکند، بهجای اینکه نیاز به یک فرآیند سیستمعامل جدید داشته باشد.
مکانیزم Bindings: پایان تأخیرهای شبکه
یکی از چشمگیرترین تفاوتهای agentOS با سندباکسینگ سنتی، استفاده از «اتصالات» یا Bindings است. در یک ساختار استاندارد، یک عامل برای دسترسی به دادههای میزبان باید یک API شبکه را فراخوانی کند، که این امر باعث ایجاد تأخیر شده و ریسکهای امنیتی را به دلیل انتقال اعتبارنامهها به داخل سندباکس افزایش میدهد (سندباکس $ \rightarrow $ HTTP $ \rightarrow $ بکاند).
در agentOS، توسعهدهندگان توابع TypeScript را در میزبان تعریف کرده و آنها را بهعنوان دستورات خط فرمان (CLI) به داخل VM معرفی میکنند. برای مثال، یک Binding به نام get_user_data میتواند در میزبان تعریف شود تا یک جستجوی مستقیم در دیتابیس با استفاده از db.users.findById(userId) انجام دهد. وقتی عامل در داخل VM دستور get_user_data 123 را اجرا میکند، این دستور مانند هر دستور شل دیگری اجرا میشود، اما در واقع در حال اجرای تابع TypeScript میزبان است. در این مدل، اتصالات دیتابیس و کلیدهای سری در میزبان باقی میمانند و هرگز وارد محیط مهمان نمیشوند.
بنچمارکهای هزینه و عملکرد
شکاف هزینه در اینجا ساختاری است و نه صرفاً نتیجه بهینهسازی. زیرا سندباکسهای سنتی بر اساس حداقل اندازه نمونه (۱ vCPU + ۱ گیگابایت رم) صورتحساب دقیقهای میفرستند، برای کارهای با فرکانس بالا و مدتزمان کوتاه بسیار گران هستند. برای مقایسه، خط پایه Daytona برابر با $0.0504 برای هر vCPU-h و $0.0162 برای هر GiB-h است.
عملکرد راهاندازی سرد (اندازهگیری شده در ۳۰ مارس ۲۰۲۶ روی Intel i7-12700KF):
این بنچمارکها شکاف عظیم بین V8 isolates و microVMها را نشان میدهد:
- p50: ابزار agentOS (۴.۸ میلیثانیه) در برابر سریعترین سندباکس/E2B (۴۴۰ میلیثانیه) $ \rightarrow $ ۹۲ برابر سریعتر
- p95: ابزار agentOS (۵.۶ میلیثانیه) در برابر سریعترین سندباکس/E2B (۹۵۰ میلیثانیه) $ \rightarrow $ ۱۷۰ برابر سریعتر
- p99: ابزار agentOS (۶.۱ میلیثانیه) در برابر سریعترین سندباکس/E2B (۳,۱۵۰ میلیثانیه) $ \rightarrow $ ۵۱۶ برابر سریعتر
مصرف حافظه:
- دستور شل ساده: agentOS (
۲۲ مگابایت) در برابر Daytona (۱۰۲۴ مگابایت) $ \rightarrow $ ۴۷ برابر کمتر - عامل کدنویسی کامل (Pi + MCP + سیستم فایل): agentOS (
۱۳۱ مگابایت) در برابر Daytona (۱۰۲۴ مگابایت) $ \rightarrow $ ۸ برابر کمتر
هزینه اجرا (میزبانی شخصی، عامل کدنویسی کامل):
- AWS ARM: ابزار agentOS ($0.00000058/s$) در برابر Daytona ($0.000018/s$) $ \rightarrow $ ۳۲ برابر ارزانتر
- Hetzner ARM: ابزار agentOS ($0.000000066/s$) در برابر Daytona ($0.000018/s$) $ \rightarrow $ ۲۸۱ برابر ارزانتر
اکوسیستم و قابلیتهای پیشرفته
agentOS شامل یک رجیستری از عاملها و ابزارهایی است که بهصورت بستههای npm در دسترس هستند و استقرار عاملهای کدنویسی AI را ساده میکنند. اینها بهعنوان اجزای نرمافزاری ماژولار در محیط اجرا مدیریت میشوند:
- Pi (
@agentos-software/pi): عامل کدنویسی اصلی و چندمنظوره. - Claude Code (
@agentos-software/claude-code): ادغام Claude Code شرکت Anthropic (نسخه بتا). - OpenCode (
@agentos-software/opencode): نسخه بتا از OpenCode. - Codex (
@agentos-software/codex): نسخه بتا از OpenAI Codex. - ابزارهای CLI: شامل
git,ripgrep,jq,sqlite3,duckdb,curlوvim. - بستههای OS: متا-بستههایی مانند
commonوbuild-essentialدر دسترس هستند و ابزارهای رایج POSIX (مانندsed,grep,gawk,findutils,diffutils,tar,gzip) بهصورت پیشفرض عرضه میشوند.
علاوه بر اجرای ساده، این Runtime از الگوهای پیچیده عاملمحور برای محیطهای عملیاتی (Production) پشتیبانی میکند:
در حالی که بسیاری از پیادهسازیهای فعلی در سازمانها تنها به سطح سادهای از تعامل محدود شدهاند — چنانکه برخی گزارشها نشان میدهند ۷۱٪ از عاملهای سازمانی تنها پوششی برای چتباتها هستند — agentOS با قابلیتهایی مانند تفویض کار بین عاملها، سعی در ارتقای این سطح از اتوماسیون دارد.
- اتصال فایلسیستم (Mounts): پشتیبانی از اتصال در هنگام بوت یا بهصورت پویا. انواع اتصال شامل باکتهای
s3، دایرکتوریهای محلی میزبان (مثلاً./local-dirبه/workspace)، حافظه موقت (memoryبرای/tmp) وgdrive(از طریق OAuth) است. - مجوزهای دقیق (Granular Permissions): خروجی شبکه بهطور پیشفرض بسته است. توسعهدهندگان باید صراحتاً میزبانها را اجازه دهند (مثلاً
api.github.com) در حالی که بقیه از طریق یک Wildcard (*) مسدود میشوند. مجوزهای فایلسیستم را میتوان تفکیک کرد؛ مثلاً اجازهreadبرای/workspaceو/dataداده شود اما دسترسیwriteفقط برای/workspaceمحدود گردد. - تفویض کار بین عاملها (Agent-to-Agent Delegation): یک عامل اصلی میتواند یک Binding را برای راهاندازی یک عامل ثانویه فعال کند. برای مثال، Pi میتواند Binding مربوط به
run_code_reviewرا فراخوانی کند تا یک عامل Claude Code را برای یک URL خاص از PR اجرا کرده و منتظر بازگشت نتیجه به عامل اصلی بماند. - جلسات چندنفره (Multiplayer Sessions): چندین کلاینت میتوانند بهطور همزمان یک جلسه عامل را مشاهده کرده یا با آن تعامل داشته باشند. یک کلاینت ممکن است فقط ناظر (Read-only) باشد در حالی که کلاینت دیگر پرامپتها را ارسال میکند.
- جلسات از طریق ACP: با استفاده از پروتکل کلاینت عامل (Agent Client Protocol)، جلسات بهطور خودکار بدون نیاز به کدنویسی اضافی ذخیره میشوند، امکان بازگشت به جلسات قطع شده را فراهم میکنند و یک فرمت یکپارچه از تاریخچه (Transcript) برای دیباگ و مقایسه ارائه میدهند.
- اتوماسیون: ویژگی
registry.cronامکان وظایف زمانبندی شده (مثلاً تولید گزارش روزانه در ساعت ۹ صبح) را فراهم میکند وregistry.webhookاجازه میدهد تریگرهای خارجی مانند رویدادهای GitHub، کارها را به یک عامل تفویض کنند.
agentOS در برابر سندباکسهای کامل: چه زمانی کدام را انتخاب کنیم؟
تیم Rivet Dev صراحتاً بیان میکند که agentOS مکمل سندباکسهای کامل است و نه جایگزینی برای آنها. توازن بین این دو بر اساس نیازهای خاص هر تسک تعیین میشود.
زمان انتخاب agentOS:
- ادغام مستقیم با بکاند: وقتی عاملها نیاز دارند دیتابیس یا توابع بکاند شما را از طریق Bindings مستقیم و بدون جابهجایی شبکه فراخوانی کنند.
- همزمانی بالا (High Concurrency): نیازهای کم حافظه (~۲۲ مگابایت) اجازه میدهد تعداد بسیار بیشتری از نمونهها روی یک میزبان قرار گیرند.
- تجربه کاربری آنی (Real-time UX): زمانی که تأخیر راهاندازی سرد ۴.۸ میلیثانیهای برای جریانهای کاری کاربر-محور حیاتی است.
- میزبانی شخصی (Self-hosting): وقتی میخواهید از پرداخت هزینههای هر-دقیقهای خدمات سندباکسهای تجاری اجتناب کنید.
زمان انتخاب سندباکس کامل (E2B/Daytona):
- کامپایل بومی: نیاز به اجرای کامل زنجیره ابزارهای C/C++ یا Rust (و نه فقط Wasm).
- سرورهای داخلی: نیاز به راهاندازی یک سرور HTTP کامل Node.js یا Python در داخل VM.
- محیطهای واقعی مرورگر: نیاز به اتوماسیون واقعی مرورگر (اگرچه نسخه بتای Browserbase برای agentOS در دسترس است).
- بارهای کاری سنگین: زمانی که حجم کار چنان زیاد است که کف حافظه ۱ گیگابایتی در برابر آن ناچیز است.
برای حل محدودیت نبود هسته کامل لینوکس، agentOS قابلیت «اتصال سندباکس» را دارد. توسعهدهندگان میتوانند بهطور پیشفرض از VM سبک استفاده کنند و تنها زمانی که یک بار کاری سنگین شناسایی شد، یک فایلسیستم سندباکس کامل (مثلاً با provider: "e2b") را به نقطه اتصال /sandbox در VM متصل کنند.
این تغییر در لایه ایزولهسازی، اقتصاد استقرار عاملها را تغییر میدهد. با تبدیل سیستمعامل به یک کتابخانه، مانع اجرای عاملهای آنی با همزمانی بالا در محیط عملیاتی بهشدت کاهش مییابد. این پروژه با لایسنس Apache-2.0 که از زمان ایجاد در ۷ فوریه ۲۰۲۴ تاکنون بیش از ۴۲۶۵ ستاره و ۲۱۴ فورک در گیتهاب دریافت کرده، ثابت میکند که صنعت به سمت ایزولهسازی دانهبندیشده (Granular Isolation) حرکت میکند.
اگر در حال ساخت یک محصول AI کاربر-محور هستید که در آن تأخیر ۴۰۰ میلیثانیهای مانند یک ابدیت طولانی به نظر میرسد، ارزیابی یک Runtime مبتنی بر V8 isolate اکنون جایگزینی واقعی برای پرداخت «مالیات میکرو-VM» است. برای بررسی بیشتر به مستندات رسمی در agentos-sdk.dev مراجعه کنید یا در دیسکورد جامعه آنها بپیوندید تا ببینید این Runtime چگونه سناریوهای پیچیده Tool-calling سازمانی را مدیریت میکند.
گام بعدی شما
- اگر از E2B یا Daytona استفاده میکنید، هزینه استنتاج و زمان بوت یک مدل ساده را با
@rivet-dev/agentosمقایسه کنید. - مستندات agentos-sdk.dev را برای پیادهسازی Bindings مطالعه کنید تا دسترسی به دیتابیس را از حالت API به توابع مستقیم تبدیل کنید.
- در دیسکورد این پروژه بررسی کنید که چگونه سناریوهای پیچیده Tool-calling سازمانی مدیریت میشوند.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما درباره تأثیر تراشههای Blackwell بر هزینه استنتاج مراجعه کنید.
گفتگو