تصور کنید برنامهنویسی هستید که برای جلوگیری از خواب رفتن لپتاپش، درب آن را نیمهباز گذاشته تا یک عامل هوش مصنوعی ساعتها روی کدی کار کند. این صحنه، نمادی از یک تلهٔ مهندسی است: قربانی کردن پایداری بلندمدت برای راحتی کوتاهمدت. انتقال از یک لپتاپ محلی به ابر در ابتدا شبیه به یک پورت ساده به نظر میرسد، اما اجرای یک عامل هوش مصنوعی در یک سندباکس یا ماشین مجازی (VM)، در واقع تلهای است که پایداری بلندمدت را با راحتی کوتاهمدت معاوضه میکند. این الگو باعث ایجاد سرویسهای شکنندهای میشود که در اصطلاح به آنها «سرویسهای حیوان خانگی» (Pet Services) میگویند و در هنگام جهشهای مصرف حافظه، بهطور کامل سقوط میکنند.
بسیاری از توسعهدهندگان ابتدا عامل (Agent) — شبیه دستیاری که میتواند بهجای شما ابزارها را اجرا کند — را بهصورت محلی روی دستگاههای خود اجرا میکنند. احتمالاً شما هم صحنهٔ لپتاپی را دیدهاید که برای جلوگیری از حالت Sleep، نیمهباز مانده تا عامل بتواند به کار خود ادامه دهد. این ساختار اساساً معیوب است، چون عمر عامل را به بازهٔ توجه یک انسان و محدودیتهای سختافزاری گره میزند. لپتاپ در این حالت دو پیام را به شما منتقل میکند: اول اینکه عامل آنقدر مفید است که مردم حاضرند سختافزار را برایش «پرستاری» کنند، و دوم اینکه این عامل در جای اشتباهی اجرا شده است.
همانطور که در تحلیلهای قبلی ما دربارهی زیرساختهای مدلهای زبانی اشاره کردیم، انتقال به ابر تنها گام اول است و نحوهٔ این انتقال تعیینکننده است. سه دلیل اصلی برای خروج از محیط محلی و انتقال عاملها به زیرساختهای ابری وجود دارد:
اول، تداوم اجرا (Continuous Running) است. هر وظیفهای که فراتر از بازهٔ توجه انسان باشد، نمیتواند روی ماشینی که به خواب میرود بماند. برای مثال، عاملی که درخواست تأیید وام برای بازپرداخت وامهای مسکن را مدیریت میکند، ممکن است دوشنبه زمانی که متقاضی دربارهٔ نرخها سؤال میکند، شروع به کار کند، اما درخواست نهایی ممکن است تا هفتهٔ بعد ارسال نشود. در این فاصله، عامل باید استعلامات قیمت را بگیرد، پرسوجوهای پرونده را ثبت کند، دو روز منتظر بماند، به ایمیلها پاسخ دهد و با متقاضیان تماس بگیرد تا ضربالاجلها را یادآوری کند. این نوع وظایف با افق زمانی بلند، برای یک لپتاپ غیرممکن است.
دوم، انعطافپذیری (Elasticity) است. سختافزار لپتاپ توان مدیریت بارهای کاری غیرقابلپیشبینی و ناگهانی را ندارد. اگر بخواهید برای کدهای یک شرکت یک ویکی (Wiki) بسازید، دو راه دارید: یا یک عامل واحد را روی لپتاپ اجرا کنید که یک هفته زمان میبرد، یا یک گروه (Swarm) متشکل از ۵۰۰ عامل را در ابر فعال کنید که کار را در ۲۰ دقیقه به پایان میرساند. خرید ۵۰۰ لپتاپ برای یک وظیفهٔ موردی و سپس رها کردن آنها در حالت بیکار، غیرمنطقی است. زیرساخت ابری به شما اجازه میدهد در یک روز سهشنبه برای ۲۰ دقیقه مقیاس را بالا ببرید و سپس دوباره به صفر برگردانید.
سوم، ایزولاسیون (Isolation) است. در لپتاپ، عامل با دسترسی کاربر اجرا میشود، به این معنی که به تمام کلیدهای API، اعتبارنامههای ابری و پروفایلهای مرورگر دسترسی دارد. اگرچه این موضوع در ابتدا حس راحتی ایجاد میکند، اما یک معاوضهٔ امنیتی بزرگ است. در ابر، شما میتوانید حداقل محیط مورد نیاز را تعریف کنید. برای مثال، یک وظیفهٔ بازنویسی کد (Refactoring) تنها به مجوز GitHub نیاز دارد؛ یا یک عامل دستهبندی تیکتهای On-call تنها به دسترسی خواندن (Read access) برای نقاط انتهایی نظارتی (Observability endpoints) نیاز دارد و اصلاً نباید دسترسی نوشتن داشته باشد.
با این حال، بسیاری از سرویسهای SaaS اکنون ابزارهایی مثل OpenClaw را مستقیماً در یک ماشین مجازی (VM) مستقر میکنند. این رویکرد، حلقهٔ تصمیمگیری، پوستهٔ اجرا و فایلهای جلسه را به عنوان یک واحد واحد ارسال میکند. به نقل از گزارشی در dev.to که در ۸ سپتامبر ۲۰۲۶ منتشر شد، این روش «پورت مستقیم» شکست میخورد چون زمینهٔ کاری (Working Context) موجود در ماشین شخصی را نادیده میگیرد. وقتی عامل به یک VM ابری منتقل میشود، محیط محلی را که برای اثربخشی واقعی به آن نیاز دارد، از دست میدهد. این یک تصمیم خاموش است که کاربران را از تجربهٔ قدرت واقعی عاملهای مبتنی بر ابر باز میدارد.
وقتی مغز و دستهای عامل در یک کانتینر باشند، هر شکست، یک شکست کلی است. این مدل «سرویسهای حیوان خانگی» آسیبپذیریهای شدیدی دارد:
- سقوط حافظه: اگر عامل از مرورگر استفاده کند، مصرف حافظه میتواند بهطور سریع و غیرقابلپیشبینی افزایش یابد. سیستم OOM Killer (قاتل کمبود حافظه) تفاوتی بین حلقهٔ مهم عامل و فرآیند مرورگر قائل نمیشود و بهسادگی کل کانتینر را متوقف میکند.
- از دست رفتن دادهها: عاملی را تصور کنید که ۴۰ دقیقه در حال اجرا بوده، بیش از ۳۰ فایل را خوانده و دو بار تستهای واحد (Unit Tests) را اجرا کرده است. اگر کانتینر بمیرد، تمام این پیشرفتها که در حافظهٔ فرآیند و فایلهای JSONL روی دیسک محلی قرار داشت، ناپدید میشود. چون دیسک دیگر وجود ندارد، امکان بازگشت به حالت قبلی (Resume) وجود ندارد.
- نابهینگی هزینه: بهدلیل عدم امکان بازیابی پس از سقوط، باید کل فرآیند را از ابتدا شروع کرد. این یعنی پرداخت دوباره هزینهٔ توکنها برای بازسازی جلسه از نقطه صفر.
- دامنه اثر تخریب (Blast Radius): در لپتاپ، مهندسان تنها پس از وقوع یک حادثهٔ واقعی متوجه میشوند که دامنه اثر تخریب چقدر بوده است. با انتقال به یک مدل ابری مجزا (Decoupled)، میتوان دامنه اثر تخریب را از پیش تعریف کرد.
در آوریل ۲۰۲۶، شرکت Anthropic با معرفی Claude Managed Agent و انتشار یادداشتی با عنوان «مقیاسبندی عاملهای مدیریتشده: جداسازی مغز از دستها»، مفهومی را مطرح کرد: «حیوان خانگی نگیرید». منظور این است که نباید سرویسهای غیرقابلجایگزیر (Non-disposable) داشت. برای تبدیل سرویسها به «گله» (Cattle) — یعنی سرویسهای یکبارمصرف و بدون وضعیت (Stateless) — عامل باید به سه بخش مستقل تقسیم شود:
۱. ذخیرهساز جلسه (Session Store): این بخش جایگزین فایلهای محلی JSONL یا پایگاهداده SQLite میشود. این لایه به یک سیستم لاگ توزیعشده تبدیل میشود که به عنوان «منبع واحد حقیقت» عمل میکند. هر پیام کاربر، نتیجهٔ استنتاج و درخواست/نتیجهٔ ابزار در اینجا ثبت میشود. چون توزیعشده است، خرابی یک ماشین باعث سقوط کل جلسه نمیشود و ریسک از دست رفتن اطلاعات جلسه وجود ندارد.
۲. حلقهٔ عامل (Agent Loop): این بخش از یک حلقهٔ تکرار محلی while true به یک «کارگر بدون وضعیت» (Stateless Worker) تبدیل میشود. کارگر انتهای لاگ را میخواند، دقیقاً یک گام — یا استنتاج یا اجرای ابزار — را انجام میدهد، نتیجه را به ذخیرهساز جلسه اضافه میکند و سپس همه چیز را فراموش میکند. این کارگر هیچ وضعیت جلسهای را بین نوبتها نگه نمیدارد. این یعنی هر کارگری میتواند هر جلسهای را بردارد و یک کارگر مرده میتواند فوراً با یک کارگر جدید جایگزین شود.
۳. لایه اجرا (Execution Layer): این محیط واقعی یا سندباکسی است که محیط کاری عامل در آن پیکربندی میشود. اینجا جایی است که کاربر بستهها را نصب میکند و مهارتها را بارگذاری میکند. برای حل مشکل زمینه (Context)، کاربران میتوانند سیستمهای فایل سفارشی را متصل (Mount) کنند تا زمینهٔ کاری اضافی فراهم شود و خروجیهای تولید شده توسط عامل حفظ گردد.
این معماری، اقتصاد و قابلیت اطمینان گردشکارهای عاملمحور را تغییر میدهد. اکنون بازیابی یک خطا، بهجای کل جلسه، تنها هزینهٔ یک گام را دارد. نقطهٔ واحد شکست (Single Point of Failure) حذف شده و انعطافپذیری به ویژگی ذاتی سیستم تبدیل میشود.
برای مثال، همان عامل تأیید وام میتواند اکنون طی چندین هفته فعالیت کند. میتواند با دریافت یک سیگنال بیدار شود، استعلام ثبت کند، دو روز منتظر بماند و بدون نیاز به نظارت انسان روی سرور، ایمیلی برای یادآوری به مشتری ارسال کند.
همچنین در محیط ابری، میتوانید «دامنه اثر تخریب» یک عامل را از پیش تعریف کنید. یک وظیفهٔ بازنویسی کد فقط مجوز GitHub میگیرد، در حالی که یک عامل دستهبندی تیکتها فقط دسترسی خواندن به نقاط انتهایی نظارتی دارد. این یک ارتقای امنیتی عظیم نسبت به دسترسی «همه یا هیچ» در لپتاپهای محلی است، جایی که اعتبارنامهها اغلب سرقت میشوند یا ایمیلها بهاشتباه حذف میگردند.
البته سندباکسهای ساده هنوز برای نمونههای اولیه (Prototype) مفیدند. اگر در حال ساخت یک اثبات مفهومی (PoC) هستید که قصد دارید پایان روز آن را دور بریزید، سربارِ جداسازی لایهها فقط سرعت شما را میگیرد. دوام، انعطافپذیری و بهینگی هزینه برای یک نمونهٔ اولیه الزامی نیستند.
اما برای سرویسهای تولیدی (Production) که در مقیاس بزرگ اجرا میشوند، جداسازی تنها راه دستیابی به دوام است. انتقال از یک VM «حیوان خانگی» به یک معماری مجزا، همان چیزی است که یک ابزار آماتور را از یک سرویس عامل در سطح سازمانی (Enterprise-grade) جدا میکند.
این چرخش معماری نشان میدهد آیندهٔ عاملهای هوش مصنوعی نه در مدلهای بزرگتر، بلکه در زیرساختهای مقاومتر است. تمرکز از «هوش مدل» به «قابلیت اطمینان حلقهٔ اجرا» منتقل شده است.
گام بعدی شما
- اگر از VMهای ساده برای استقرار عاملها استفاده میکنید، لایه ذخیرهسازی وضعیت (State) را از لایه اجرا جدا کنید.
- برای کاهش هزینههای توکن، مکانیزمی برای ذخیرهٔ گامهای میانی در یک پایگاهداده توزیعشده پیاده کنید.
- دسترسیهای عامل را بر اساس وظیفه (Task-based) محدود کنید تا دامنه اثر تخریب در صورت بروز خطا کاهش یابد.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو