«تداوم وظایف»؛ راهکار Earendil برای بازیابی عامل‌ها پس از کرش

تصور کنید یک عامل هوش مصنوعی در حال اجرای یک پروژه برنامه‌نویسی چندروزه است و ناگهان سرور ری‌استارت می‌شود؛ در حالت عادی، تمام پیشرفت‌ها و حافظهٔ لحظه‌ای مدل می‌سوزد. اما حالا با معرفی Pi Durable، کرش کردن یک پردازش دیگر به معنای از دست رفتن کل جلسهٔ کاری نیست.

در ۱ اکتبر ۲۰۲۶، شرکت Earendil از Pi Durable پرده‌برداری کرد؛ یک چارچوب آزمایشی که تضمین می‌کند عامل‌های بلندمدت بتوانند از شکست‌های سیستمی، سرریز حافظه یا بازنشر کانتینرها بدون گم کردن جایگاه خود جان سالم به در ببرند. طبق اعلام این شرکت، اکثر عامل‌های فعلی به صورت پردازش‌های ناپایدار عمل می‌کنند؛ یعنی اگر ترمینال بسته شود یا سرور ری‌استارت شود، وضعیت داخلی عامل ناپدید می‌شود. این موضوع یک شکاف اعتباری بزرگ برای جریان‌های کاری حرفه‌ای ایجاد می‌کند که در آن‌ها عامل‌ها باید وظایف پیچیده و چندروزه را مدیریت کنند.

Pi Durable با تبدیل هر اقدام — از یک درخواست مدل تا فراخوانی یک ابزار — به یک وظیفه ماندگار با یک نقطه بازرسی (Checkpoint) — شبیه به ذخیره کردن بازی در یک مرحله خاص برای جلوگیری از تکرار کل بازی — این مشکل را حل می‌کند. همان‌طور که در تحلیل‌های قبلی ما درباره‌ی پایداری سیستم‌های عامل‌محور اشاره کردیم، جداسازی وضعیت از پردازش، کلید رسیدن به اتونومی واقعی است. این رویکرد در راستای توسعه‌ی سیستم‌هایی است که مانند پلتفرم Pion برای مدیریت کسب‌وکارهای خودگردان، تلاش می‌کنند استقلال عملیاتی AI را در محیط‌های واقعی افزایش دهند.

این سیستم بر پایه پایداری Pi 1.0 بنا شده است که زیرساختی سخت‌افزاری برای عامل‌های کدنویس فراهم می‌کند. در حالی که Pi 1.0 در تعاملات تک‌کاربره در ترمینال می‌درخشد، Pi Durable چارچوبی برای ساخت هر اپلیکیشن عامل‌محور است که به در دسترس بودن بالا و هدایت چندکاربره نیاز دارد.

مفهوم هارنس (Harness)

برای درک Pi Durable باید ابتدا مفهوم «هارنس» را شناخت. Earendil هارنس را ترکیبی از فضای ذخیره‌سازی و ماشینری لازم برای اجرای موازی یک یا چند گفتگو با مدل‌های زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — تعریف می‌کند. هارنس ابزارهایی را که مدل‌ها فراخوانی می‌کنند و محیط‌های اجرایی آن‌ها را فراهم می‌سازد.

در این معماری، یک گفتگو تعاملی بین کاربر و عامل است که به صورت یک متن (Transcript) ثبت می‌شود. عامل نیز شامل LLM و تنظیمات خاص آن، مانند سطح تفکر و ابزارهای مجاز برای فراخوانی است.

سازوکار ماندگاری

بر اساس مستندات earendil.com، هسته Pi Durable از یک رابط ذخیره‌سازی کوچک پشتیبانی می‌کند که با SQLite، JSONL و حافظه (Memory) سازگار است. از آنجایی که پیاده‌سازی‌های SQLite و JSONL از APIهای Node اجتناب می‌کنند، می‌توانند روی Bun یا درون Cloudflare Durable Objects با کمترین آداپتور اجرا شوند. این یعنی هارنس در هر جایی که یک محیط اجرای جاوااسکریپت وجود داشته باشد فعال است، در حالی که ابزارهای واقعی (مثل یک شل bash) می‌توانند در یک محیط اجرای راه دور مجزا اجرا شوند.

محیط‌های اجرا و ذخیره‌سازی

Pi Durable محل استقرار هارنس را از محل اجرای ابزارها جدا می‌کند. هارنس روی یک بک‌اند ذخیره‌سازی باز می‌شود و تنها مجموعه کاری — شامل متن‌های فعال، وظایف زنده و ارسال‌های در انتظار — در حافظه نگه داشته می‌شود و بقیه داده‌ها روی دیسک می‌مانند.

• انعطاف‌پذیری ذخیره‌سازی: رابط ذخیره‌سازی به گونه‌ای طراحی شده که به راحتی روی سیستم‌های موجود مثل Postgres یا ذخیره‌سازهای کلید-مقدار پیاده شود. در هر لحظه تنها یک پردازش مالک یک فضای ذخیره‌سازی است و سایر کلاینت‌ها به آن پردازش متصل می‌شوند.
• ایزولاسیون محیطی: تابع env محیط هر فراخوانی ابزار را از دایرکتوری کاری گفتگو می‌سازد؛ بنابراین هر گفتگو می‌تواند در یک مکان فیزیکی یا مجازی متفاوت اجرا شود.
• اجرای راه دور: به دلیل کوچک بودن رابط محیط اجرا، هارنس می‌تواند روی یک ماشین باشد و ابزارهایش روی ماشینی دیگر اجرا شوند.

بقا در برابر کرش

این سیستم یک سازوکار سخت‌گیرانه برای نقاط بازرسی پیاده کرده است. هر مرحله از اجرا به عنوان یک وظیفه ثبت می‌شود. اگر پردازش در میانه اجرا بمیرد — چه به دلیل خواب رفتن لپ‌تاپ یا بازنشر کانتینر — پردازش جدید صرفاً همان ذخیره‌ساز را باز کرده، وظایف ناتمام را شناسایی می‌کند و از آخرین نقطه بازرسی موفق ادامه می‌دهد.

• درخواست‌های مدل: اگر درخواستی قطع شود، مجدداً ارسال می‌گردد. پاسخ‌های ناقص در متن نگه داشته می‌شوند اما به عنوان «لغو شده» علامت می‌خورند.
• فراخوانی ابزارها: ابزارها به دو دسته «ایمن» یا «ناایمن» برای اجرای مجدد تقسیم می‌شوند. یک جست‌وجوی فقط-خواندنی ایمن است، اما یک استقرار در محیط تولید (Production) ناایمن است. اگر ابزاری ناایمن قطع شود، مدل از شکست مطلع شده و باید تصمیم بگیرد چگونه پیش برود.
• ارسال دقیقاً-یک‌بار: با استفاده از requestId سیستم تضمین می‌کند که تلاش‌های مجدد پس از کرش منجر به درخواست‌های تکراری نشود. کلاینتی که پس از کرش تلاش مجدد می‌کند، به جای ارسال درخواست دوم، پاسخ ارسال اصلی را دریافت می‌کند.

زیرعامل‌ها و مالکیت وظایف

اگرچه Pi Durable زیرعامل‌های داخلی ندارد، اما می‌توان آن‌ها را با چند خط کد ساخت. یک زیرعامل در گفتگوی خودش اجرا می‌شود و بنابراین پس از کرش، از همان‌جایی که رها شده بود ادامه می‌دهد. یک ابزار زیرعامل که اجرای مجدد آن ایمن است، صرفاً زیرعامل خود را دوباره پیدا کرده و منتظر پاسخ آن می‌ماند.

وظایف و گفتگوها یک درخت مالکیت تشکیل می‌دهند؛ لغو یک وظیفه، تمام متعلقات آن را از پایین به بالا لغو می‌کند تا هر وظیفه ابتدا اثرات خود را پاک‌سازی کند. این ساختار اجازه می‌دهد دو نوع وظیفه تعریف شود:

• وظایف پیش‌زمینه: بخشی از کار فعلی گفتگو هستند و تا زمان اتمام، گفتگو مشغول می‌ماند. فشردن کلید Esc این وظایف را لغو می‌کند.
• وظایف پس‌زمینه: متعلق به گفتگو هستند اما نه لزوماً کار فعلی؛ مثلاً یادآورهایی که فردا فعال می‌شوند یا زیرعامل‌هایی که پس از پایان نوبت کاربر همچنان فعال می‌مانند. لغو خودِ وظیفه یا لغو گفتگو با پارامتر { background: true } باعث توقف آن‌ها می‌شود.

مدیریت زمینه نامحدود

برای مدیریت گفتگوهایی با ده‌ها هزار پیام، Pi Durable از یک فرآیند فشرده‌سازی پس‌زمینه استفاده می‌کند. به جای متوقف کردن عامل برای خلاصه‌سازی، وقتی پنجره زمینه (Context Window) — شبیه به میز کاری که فقط جای چند ورق دارد و نه کل کتابخانه — به حد خود نزدیک می‌شود، یک وظیفه پس‌زمینه فعال می‌گردد.

فشرده‌سازی مانند هر وظیفه دیگر است. وقتی زمینه به حد مدل نزدیک می‌شود، یک وظیفه پس‌زمینه پیام‌های قدیمی را خلاصه کرده و خلاصه در مرز نوبت بعدی قرار می‌گیرد. گفتگو تنها زمانی منتظر خلاصه می‌ماند که درخواست بعدی در صورت عدم فشرده‌سازی در پنجره زمینه جا نشود. اگر ارائه‌دهنده مدل همچنان درخواست را به دلیل طولانی بودن رد کند، هارنس یک بار دیگر فشرده‌سازی را انجام داده و تلاش مجدد می‌کند.

کاربر همچنین می‌تواند به صورت دستی و با دستورات سفارشی فشرده‌سازی را انجام دهد. همچنین مکانیزم «تحویل» (Handoff) اجازه می‌دهد عامل زمینه خود را با یک یادداشت خاص ریست کند در حالی که تمام پیام‌های قبلی در تاریخچه قابل جست‌وجو باقی می‌مانند. این قابلیت به عامل اجازه می‌دهد کار را به خودش تحویل دهد و بعداً جزئیات قبلی را با ابزارهایی مثل search_history پیدا کند.

افزونه‌ها و قلاب‌های قابل تعویض

هر کاری که یک عامل در Pi Durable انجام می‌دهد از طریق افزونه‌ها قابل تغییر است. یک افزونه بسته‌ای از بخش‌های پرامپت سیستمی، ابزارها، قلاب‌ها و وظایف است.

• بخش‌های پرامپت سیستمی: این بخش‌ها قبل از هر درخواست بازسازی می‌شوند، بنابراین تغییرات کد در پرامپت فوراً اعمال می‌شود. Pi Durable تغییرات را در متن ثبت می‌کند تا شاخه‌های مختلف (Forks) دقیقاً همان چیزی را ببینند که مدل دیده است. در مدل‌های پشتیبانی شده، برای حفظ اعتبار کش پرامپت، تنها تغییرات ارسال می‌شوند.
• ابزارها: هر فراخوانی ابزار به عنوان یک وظیفه ماندگار اجرا می‌شود و قصد آن قبل از اجرا ذخیره می‌گردد. ابزارها می‌توانند «پوشش» (Wrap) شوند؛ مثلاً یک افزونه Timing می‌تواند ابزار bash را پوشش دهد تا مدت زمان هر فراخوانی را بدون توجه به نوع پیاده‌سازی bash ثبت کند.
• قلاب‌ها (Hooks): افزونه‌ها می‌توانند وظایف را رهگیری کنند. مثلاً یک قلاب «تأیید» می‌تواند ابزار deploy را تا زمان تأیید انسانی در Slack متوقف کند. قلاب‌ها می‌توانند تصمیمات را در یک «یادداشت» (Memo) — مقداری کوچک که اولین نوشتن در آن برنده است — ذخیره کنند تا تصمیم پس از کرش نیز باقی بماند. قلاب‌ها به صورت زنجیره‌ای اجرا می‌شوند؛ beforeTool آرگومان‌های بازنویسی شده را به پایین زنجیره می‌فرستد و اولین block باعث توقف آن می‌شود.
• تغییرپذیری: رجیستری می‌تواند در حین اجرای گفتگوها به‌روز شود. نصب یک افزونه با نام موجود، آن را در یک مرحله جایگزین می‌کند. کد جدید جایگزین ابزارهای قدیمی شده و فراخوانی بعدی ابزار از منطق به‌روز شده استفاده می‌کند بدون اینکه عامل متوقف شود.

چندکاربره بودن و پایداری وضعیت

Pi Durable وضعیت عامل را به عنوان مجموعه‌ای از «اسناد» (JSONهای تایپ‌شده) در کنار متن گفتگو ذخیره می‌کند. این اسناد در همان تراکنش‌های اتمیک متن ثبت می‌شوند تا وضعیت هرگز با گفتگویی که آن را تولید کرده، تضاد نداشته باشد.

اسناد می‌توانند برای رفتار در هنگام ایجاد شاخه (Fork) پیکربندی شوند: آن‌ها می‌توانند با مقدار والد در نقطه شاخه (asOf)، یک مقدار تازه، یا مقدار فعلی شروع شوند.

به دلیل ثبت تمام وضعیت‌ها در ذخیره‌ساز، چندین کلاینت می‌توانند به یک گفتگو متصل شوند. یک کاربر می‌تواند کار عامل را تماشا کند و کاربر دیگر دیرتر ملحق شود تا مسیر گفتگو را تغییر دهد یا پیام‌های بعدی را با دستور «هدایت» (Steer) در صف قرار دهد. برای کلاینت‌های راه دور، thread.watch() عملیات دقیق هر کامیت را از طریق سوکت ارسال می‌کند. اگر کاربر رویدادهای آشناتر را ترجیح دهد، می‌تواند از watchEvents() استفاده کند، هرچند این روش حجم داده بیشتری در شبکه مصرف می‌کند.

ردپای فنی

با وجود این قابلیت‌ها، کل کد منبع (بدون تست‌ها) حدود ۱۵,۰۰۰ خط است. این یعنی حدود ۱۵۰,۰۰۰ توکن برای GPT و ۲۵۰,۰۰۰ توکن برای Claude؛ بنابراین کل کدبیس به اندازه کافی کوچک است که یک عامل بتواند هارنس خودش را بخواند و بفهمد. بخش‌های ذخیره‌سازی به تنهایی ۳,۰۰۰ خط هستند که عامل معمولاً می‌تواند از آن‌ها بگذرد.

این طراحی اجازه می‌دهد عامل‌های پیچیده با کمترین سربار ساخته شوند. Earendil این موضوع را با یک عامل برنامه‌ریزی سفر (حدود ۱,۳۰۰ خط تایپ‌اسکریپت) نشان داد که از زیرعامل‌ها برای جست‌وجوی موازی آب‌وهوا و موزه‌ها استفاده می‌کند. اگر پردازش بمیرد، سیستم تشخیص می‌دهد که جست‌وجوی آب‌وهوا و موزه‌ها «ایمن» هستند یا قبلاً کامل شده‌اند، و تنها جست‌وجوی ناتمام قطار پس از ری‌استارت مجدداً اجرا می‌شود.

این تغییر معماری، عامل‌های هوش مصنوعی را از «چت‌بات‌های ابزاردار» به «سیستم‌های توزیع‌شده ماندگار» تبدیل می‌کند. با جداسازی محیط اجرا از هارنس وضعیت، Earendil نقشه‌ای برای عامل‌هایی ارائه می‌دهد که می‌توانند برای اتونومی بلندمدت در سطح تولید (Production) مورد اعتماد باشند.

توسعه‌دهندگان اکنون می‌توانند با نصب @earendil-works/pi-durable و @earendil-works/pi-ai و @earendil-works/chord و بررسی دموهای TUI برای کدنویسی و برنامه‌ریزی سفر، این ابزارها را آزمایش کنند. اگرچه سیستم فعلاً برای سهولت در راه‌اندازی با تایپ‌اسکریپت نوشته شده است، اما Earendil اشاره می‌کند که در آینده می‌تواند به Rust یا اسمبلی پورت شود.

گام بعدی شما

• اگر در حال توسعه عامل‌های پیچیده هستید، کتابخانه‌های @earendil-works/pi-durable و @earendil-works/pi-ai را برای پیاده‌سازی نقاط بازرسی بررسی کنید.
• دموهای TUI مربوط به برنامه‌ریزی سفر را برای درک نحوه مدیریت زیرعامل‌های موازی مطالعه کنید.
• ساختار ذخیره‌سازی SQLite را برای کاهش تأخیر در دسترسی به وضعیت عامل در محیط‌های لبه (Edge) آزمایش کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.