اگر تصور می‌کنید داشتن یک فایل پشتیبان برای نجات عامل هوش مصنوعی شما کافی است، احتمالاً در اولین بحران فنی، تمام حافظه و مهارت‌های مدل خود را از دست خواهید داد. تنها راه تایید تاب‌آوری یک عامل این است که از روز اول با آن به‌گونه‌ای رفتار کنید که انگار سرور میزبانش هر لحظه قابل جایگزینی است.
به نقل از راهنمای عملی منتشر شده در ۲۸ سپتامبر ۲۰۲۶، یک عامل (Agent) — شبیه به کارمندی دیجیتال که می‌تواند به‌طور مستقل ابزارها را اجرا کند و تصمیم بگیرد — تنها زمانی قابل اعتماد است که آخرین بار با موفقیت روی یک سرور کاملاً خام بازگردانی شده باشد. کسانی که با سرور مجازی (VPS) خود مانند یک خانه دائمی رفتار می‌کنند، در صورت بروز نقص فنی شدید، با خطر نابودی کامل «وضعیت» (State) مدل مواجه‌اند.
بسیاری از اپراتورها پشتیبان داشتن را با داشتن برنامه بازیابی اشتباه می‌گیرند. در دنیای عامل‌های خودمختار، وضعیت مدل فقط یک پایگاه‌داده ساده نیست؛ بلکه شامل جلسات فعال، اعتبارنامه‌های ابزارها و تاریخچه اجرای کارهای زمان‌بندی شده است. همان‌طور که در تحلیل‌های قبلی ما درباره امنیت مدل‌های بازمتن اشاره کردیم، بدون تعیین دقیق هدف برای «نقطه بازیابی» (RPO) و «زمان بازیابی» (RTO)، پشتیبان شما فقط یک فایل است، نه تضمینی برای تداوم سرویس. این لایه‌ی مدیریتی در واقع بخشی از سیستم‌های مدیریت عامل است که نقش سیستم‌عامل را برای نرم‌افزارهای خودگردان ایفا می‌کنند و پایداری کل ساختار را تضمین می‌کنند.
تعریف هدف بازیابی
برای ساخت یک برنامه قابل تست، ابتدا باید تعریف کنید که وضعیت عامل شامل چه مواردی است. این موارد عبارتند از:
- تنظیمات پیکربندی و تنظیمات ارائه‌دهنده
- حافظه، جلسات، مهارت‌ها و داده‌های محلی عامل
- متریال‌های احراز هویت و اعتبارنامه‌های ابزار
- کارهای زمان‌بندی شده (Cron jobs) و وضعیت آخرین اجراهای آن‌ها
- فایل‌های فضای کاری و داده‌های برنامه‌ای که به‌صورت خارجی ذخیره شده‌اند
طبق مستندات این راهنما، برای اجرای یک تمرین بازیابی درست، باید یک فرآیند شش‌مرحله‌ای را طی کنید. در این تمرین، سرور قدیمی باید خاموش بماند و از یک میزبان جایگزین با محیط کاملاً خالی استفاده شود. عامل بازگردانی‌شده باید بتواند بدون دسترسی به سرور اصلی، حافظه، مهارت‌ها، اعتبارنامه‌ها، زمان‌بندی‌ها و دسترسی به ابزارهای خود را بازیابی کند.
گردش‌کار بازگردانی
۱. ثبت محیط: نسخه دقیق Hermes، سیستم‌عامل و محیط پایتون را مستند کنید تا مشکلات بازگردانی با به‌روزرسانی‌های نسخه مخلوط نشود. برای این کار به کدها و یادداشت‌های نسخه‌بندی شده در GitHub releases مراجعه کنید.
۲. آرشیو کامل: از دستور hermes backup در CLI برای بسته‌بندی پیکربندی‌ها، مهارت‌ها و جلسات در یک آرشیو رمزنگاری‌شده خارج از سرور استفاده کنید. توجه داشته باشید که CLI رسمی، پشتیبان‌های قبلی و دایرکتوری Checkpoint را حذف می‌کند، بنابراین بازیابی فضای کاری نیاز به یک فهرست موجودی جداگانه دارد.
۳. تجهیز پاک: یک نمونه تازه را از طریق اسکریپت رسمی (curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash) روی VPS جدید نصب کنید. درگاه (Gateway) قدیمی را متوقف کنید تا کارهای زمان‌بندی شده دو بار اجرا نشوند.
۴. وارد کردن وضعیت: پس از توقف Gateway، دستور hermes import /path/to/backup.zip را اجرا کنید تا مجوزهای فایل‌ها به‌درستی اعمال شوند.
۵. اعتبارسنجی: از دستورات hermes doctor و hermes cron doctor برای تایید نصب استفاده کنید. سوابق اخیر کارهای زمان‌بندی شده را با دستور hermes cron runs [job-id] --limit 20 بررسی کنید.
۶. اندازه‌گیری شکاف: زمان واقعی توقف را با RTO و داده‌های از دست رفته را با RPO مقایسه کنید. زمان راه‌اندازی فرآیند به عنوان یک نشانگر میانی در نظر گرفته می‌شود.
تست رفتار بازگردانی‌شده
اعتبارسنجی نیازمند یک «تسک قناری» (Canary Task) است که بازیابی حافظه، یک مهارت نمونه و یک فراخوانی ابزار کم‌ریسک را آزمایش کند. این رویکرد مشابه متدولوژی «تست قرمز اول» برای جلوگیری از توهمات کدنویسی است که در آن پیش از پذیرش تغییرات، صحت عملکرد مدل با تست‌های سخت‌گیرانه سنجیده می‌شود. همچنین باید اکشن‌های ممنوعه را تست کنید؛ بازگردانی‌ای که دسترسی‌ها را گسترده‌تر کند، یک عقب‌گرد امنیتی است. رمزهای مورد انتظار باید کار کنند، در حالی که رمزهایی که توسط ارائه‌دهنده لغو شده‌اند باید با خطا مواجه شوند. اسکن لاگ‌ها باید تایید کند که هیچ مقدار حساسی از رمزها (Secrets) افشا نشده است.
این فرآیند تفاوت حیاتی بین نقطه بازرسی (Checkpoint) — شبیه به ذخیره کردن بازی در یک مرحله خاص برای بازگشت سریع — و پشتیبان کامل را آشکار می‌کند. نقاط بازرسی Hermes برای محافظت از تغییرات فضای کاری در حین فعالیت هستند و جایگزین پشتیبان‌های خارج از سرور نمی‌شوند. فایل‌های محلی نمی‌توانند یک ایمیل ارسال شده به مشتری یا یک تغییر در API را لغو کنند.
برای اپراتور، این تغییر به معنای گذار از پشتیبان‌های «مبتنی بر امید» به بازیابی «مبتنی بر شواهد» است. با اجرای تسک قناری، می‌توانید پیش از هدایت ترافیک واقعی، از عملکرد عامل مطمئن شوید.
عملیات قابل اعتماد عامل‌ها اکنون به یک استراتژی سه‌گانه نیاز دارد: پشتیبان برای وضعیت محلی، کنترل‌های هم‌توان‌سازی (Idempotency) برای اثرات جانبی و برنامه‌های بازیابی مجزا برای داده‌های خارجی. این ساختار تضمین می‌کند که سقوط یک سرور منجر به از دست رفتن دائمی هویت یا مهارت‌های آموخته‌شده عامل نشود.
گام بعدی شما
- مکان فعلی پشتیبان‌های خود را بازرسی کنید و همین امروز یک تلاش برای بازگردانی روی یک محیط خالی انجام دهید.
- یک «تسک قناری» تعریف کنید که سه رکن حافظه، مهارت و ابزار را به‌طور هم‌زمان تست کند.
- لیست اعتبارنامه‌های ابزارهایی که در پشتیبان ذخیره نمی‌شوند را استخراج و به‌صورت مجزا مدیریت کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره تراشه‌های Blackwell مراجعه کنید.
گفتگو