چک‌پوینت‌ها و بازگشت به عقب در ایجنت‌های هوش مصنوعی

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

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

تمام انتقال‌های وضعیت در گراف پایدارسازی و ذخیره می‌شوند. وقتی یک ورکر از کار می‌افتد (کرش می‌کند)، اجاره‌اش (lease) منقضی می‌شود و ورکر دیگری کار را از آخرین چک‌پوینت (Checkpoint) ادامه می‌دهد. آبجکت‌های پایدار کلودفلر (Cloudflare Durable Objects) وضعیت را در طول ساعت‌ها یا هفته‌ها حفظ می‌کنند. الگوی «پیشنهاد و سپس commit» (درس 15) برای هر اقدام یک طرح بازگشت به عقب (Rollback Plan) تعریف می‌کند. اعتبارسنجیِ پس از اقدام نیز این چرخه را کامل می‌بندد. ماده‌ی 14 قانون هوش مصنوعی اتحادیه‌ی اروپا (EU AI Act) نظارت مؤثر انسانی را برای سیستم‌های پرخطر اجباری کرده است؛ در عمل، یعنی چک‌پوینت‌ها باید قابل جست‌وجو باشند، بازگشت به عقب تمرین و آزمایش شده باشد، و ردپای حسابرسی پس از دیپلوی از بین نرود. حالت شکست بحرانی: بدون کلید یکتایی تراکنش (Idempotency key) و بررسی پیش‌شرط‌ها، تلاش مجدد پس از یک خطای گذرا می‌تواند اقدامی را که قبلاً تأیید شده، دوبار اجرا کند. این اعتبارسنجی پس از اقدام است که جلوی این خطا را می‌گیرد.

صورت مسئله

اجرای پایدار (Durable Execution در درس 12) به ایجنتی که کرش کرده امکان ادامه‌ی کار می‌دهد. الگوی «پیشنهاد و سپس commit» (درس 15) اقدامِ تأییدشده را قابل‌حسابرسی می‌کند. این درس این دو مفهوم را به هم پیوند می‌زند: اگر اقدامی تأیید شود، بخشی از آن اجرا گردد، سیستم کرش کند و دوباره بالا بیاید، چه رخ می‌دهد؟ بازگشت به عقب چه زمانی و بر اساس کدام وضعیت اجرا می‌شود؟

سیستم‌های دنیای واقعی این سازوکار را به شکل‌های متفاوتی پیاده می‌کنند:

• LangGraph هر انتقال وضعیت در گراف را در PostgreSQL چک‌پوینت می‌کند. با کرش ورکر، اجاره آزاد می‌شود و ورکر دیگری کار را از آخرین چک‌پوینت ادامه می‌دهد. جریان‌های کاری با interrupt() متوقف می‌شوند و خود این وقفه نیز پایدار و ذخیره می‌ماند.
• Cloudflare Durable Objects وضعیت مربوط به هر کلید را ساعت‌ها یا هفته‌ها نگه می‌دارند؛ به این ترتیب پردازش در همان محل ذخیره‌سازی داده‌های اقدامِ تأییدشده مستقر می‌شود.
• Microsoft Agent Framework مفاهیم پایه‌ایِ Checkpoint را در API جریان کاری ارائه می‌دهد؛ بازپخش (replay) به‌همراه قابلیت یکتایی تراکنش، تلاش‌های مجدد را پوشش می‌دهد.

در تمام این رویکردها، ترکیبی که واقعاً جواب می‌دهد این است: کلید یکتایی تراکنش (جلوگیری از اجرای دوباره) + بررسی پیش‌شرط (اطمینان از اینکه وضعیت هنوز همان چیزی است که تأیید کردیم) + اعتبارسنجی پس از اقدام (بررسی اینکه اثر جانبی واقعاً اعمال شده باشد) + بازگشت به عقب در صورت شکست اعتبارسنجی.

مفاهیم اصلی

پایداری تمام انتقال‌ها

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

بازیابی اجاره

وقتی یک ورکر کرش می‌کند، جریان کاری از بین نمی‌رود؛ بلکه اجاره‌ی آن (ادعای کوتاه‌مدتی مبنی بر اینکه این ورکر در حال اجرای این پردازش است) منقضی می‌شود. ورکر دیگری آخرین چک‌پوینت را برمی‌دارد و ادامه می‌دهد. سازوکار اجاره همان چیزی است که به سیستم‌های عملیاتی اجازه می‌دهد دیپلوی‌های تدریجی (rolling deploys) را بدون از دست دادن کارهای در حال اجرا پشت سر بگذارند.

یکتایی تراکنش به‌همراه پیش‌شرط‌ها

یکتایی تراکنش به‌تنهایی کافی نیست. این سناریو را در نظر بگیرید: جریان کاری تأیید شده تا «اگر موجودی بیشتر از 1000 دلار بود، مبلغ 100 دلار از حساب A به B منتقل شود». این جریان کاری commit می‌شود، وسط اجرا کرش می‌کند، و سپس ادامه می‌یابد. اگر فقط کلید یکتایی بررسی شود و اجرای جریان ادامه پیدا کند، انتقال فقط یک بار انجام می‌گیرد (که درست است). اما فرض کنید بین زمان کرش و ادامه‌ی کار، موجودی حساب A از طریق جریان کاری دیگری به 500 دلار رسیده باشد. کلید یکتایی باز هم تأیید می‌شود؛ اما پیش‌شرط دیگر برقرار نیست. بدون بررسی پیش‌شرط، برداشتی بیش از موجودی ثبت خواهیم کرد.

هر اقدام سرنوشت‌ساز و مهمی به هر دوی این‌ها نیاز دارد:

• کلید یکتایی تراکنش (Idempotency key): از اجرای دوباره جلوگیری می‌کند.
• بررسی پیش‌شرط (Precondition check): تأیید می‌کند وضعیت هنوز با آنچه تأیید شده بود همخوانی دارد.

اعتبارسنجی پس از اقدام

اینکه «ابزار کد 200 برگرداند» به‌معنای اعتبارسنجی نیست. اعتبارسنجی واقعی یعنی وضعیت سیستم مقصد را دوباره بخوانید و مطمئن شوید اثر جانبی واقعاً اعمال شده است. الگوهای رایج:

• به‌روزرسانی پایگاه داده: اجرای UPDATE ... RETURNING * و سپس بررسی اینکه سطر بازگشتی با وضعیت مورد نظر مطابقت دارد.
• ارسال ایمیل: بررسی پوشه‌ی پیام‌های ارسالی برای وجود شناسه‌ی پیام (message ID) پس از ثبت.
• نوشتن فایل: خواندن مجدد فایل و محاسبه‌ی هش آن.
• فراخوانی API: ارسال یک درخواست GET تکمیلی روی منبع مقصد.

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

طرح‌های بازگشت به عقب

هر اقدام سرنوشت‌سازی در الگوی «پیشنهاد و سپس commit» (درس 15) باید یک طرح بازگشت به عقب به همراه داشته باشد. انواع آن:

• بازگشت به عقب درون‌باند (In-band): بازگرداندن مستقیم اثر جانبی (مثلاً DELETE بعد از INSERT، یا ارسال ایمیل اصلاحی پس از ارسال ایمیل اصلی).
• تراکنش جبرانی (Compensating transaction): اقدامی جدید که اثر اقدام قبلی را خنثی می‌کند (الگوی استاندارد SAGA).
• بازگشت به عقب برون‌باند (Out-of-band): هشدار به انسان، متوقف کردن جریان کاری، و دست‌نخورده گذاشتن وضعیت معیوب برای بررسی بیشتر.

طرح‌های بدون عملیات بازگشت («امکان بازگردانی وجود ندارد») باید در همان مرحله‌ی پیشنهاد مشخص شوند. اقداماتی که بازگشت به عقب ندارند، هنگام commit به نظارت قوی‌تری از سوی انسان در چرخه (Human-in-the-loop) نیاز دارند (پرسش و پاسخ چالشی در درس 15).

خوانش عملیاتی ماده‌ی 14 قانون هوش مصنوعی اتحادیه‌ی اروپا

ماده‌ی 14 خواستار «نظارت مؤثر انسانی» برای سیستم‌های پرخطر است. مجریان در عمل این بند را این‌گونه تعبیر می‌کنند:

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

جریان کاری‌ای که وسط فرایند commit کرش کند، بالا بیاید و اثر جانبی را بدون مسیر اعتبارسنجی و بازگشت به عقب تکمیل کند، از آزمون ماده‌ی 14 سربلند بیرون نمی‌آید.

حالت شکست بحرانی: اجرای مضاعف

رایج‌ترین رخداد در محیط‌های عملیاتی:

1. اقدام با کلید یکتایی k تأیید می‌شود.
2. فرایند commit شروع شده، اجرا می‌شود و کد 200 برمی‌گرداند.
3. جریان کاری قبل از ذخیره‌ی وضعیت «committed» کرش می‌کند.
4. جریان کاری بالا می‌آید؛ وضعیت را می‌بیند: «تأییدشده ولی commitنشده»؛ پس دوباره اجرا می‌کند.
5. اثر جانبی دوبار اتفاق می‌افتد.

راهکار: قبل از اجرا، نیت را در وضعیت «در حال اجرا» (in-flight) ذخیره کنید، آن را با کلید یکتایی اجرا نمایید، و وضعیت را فقط زمانی به «committed» تغییر دهید که اعتبارسنجی پس از اقدام موفقیت‌آمیز بوده باشد. اگر اقدام رخ داد اما ثبت وضعیت شکست خورد، می‌دانید که باید اعتبارسنجی کنید و (در صورت نیاز) دوباره فراخوانی نمایید. اگر ثبت وضعیت موفق بود ولی خود اقدام شکست خورد، اعتبارسنجی می‌کنید و دقیقاً یک بار از طریق مسیر بازیابی آن را انجام می‌دهید.

استفاده از ابزارهای واقعی

فایل code/main.py یک جریان کاری چک‌پوینت‌دار را با قابلیت یکتایی تراکنش، پیش‌شرط‌ها، اعتبارسنجی و بازگشت به عقب پیاده کرده است. بخش اجرایی کد چهار سناریو را شبیه‌سازی می‌کند: اجرای تمیز و بدون خطا، تلاش مجدد پس از کرش (که کلید یکتایی جلویش را می‌گیرد)، شکست پیش‌شرط (جریان کاری قبل از اجرا متوقف می‌شود)، و شکست اعتبارسنجی (که بازگشت به عقب را فعال می‌کند).

خروجی این درس

فایل outputs/skill-rollback-rehearsal.md آزمایشی برای تمرین بازگشت به عقب در یک جریان کاری پیشنهادی طراحی می‌کند و بستر ذخیره‌سازی چک‌پوینت‌ها را از نظر پایداری ردپای حسابرسی مورد ارزیابی قرار می‌دهد.

تمرین‌ها

1. کد code/main.py را اجرا کنید. صحت چهار سناریو را بررسی نمایید. برای حالت کرش حین commit، مطمئن شوید که اقدام در تمامی تلاش‌های مجدد دقیقاً یک بار اجرا می‌شود.

2. الگوی «اول ثبت کن، بعد انجام بده» را طوری دستکاری کنید که ثبت وضعیت بعد از انجام اقدام اجرا شود. سناریوی کرش را دوباره اجرا کنید. بسنجید چند اقدام تکراری رخ می‌دهد.

3. برای یک اقدام عملیاتی واقعی (مثلاً «ارسال پیام به یک کانال Slack») یک طرح بازگشت به عقب طراحی کنید. آن را در یکی از دسته‌های درون‌باند، جبرانی، یا برون‌باند طبقه‌بندی کرده و دلیل انتخابتان را شرح دهید.

4. یکی از جریان‌های کاریِ آشنای خودتان را در نظر بگیرید. تمام انتقال‌های وضعیت آن را مشخص کنید. برای هر کدام الزام پایداری (نیاز به ذخیره / عدم نیاز به ذخیره) تعیین کنید. مواردی را که در حال حاضر ذخیره نمی‌کنید بشمارید.

5. تست تمرین بازگشت به عقب: یک تست سرتاسری طراحی کنید که یک جریان کاری واقعی را اجرا کرده، به آن کرش تزریق کند، و تأیید نماید که مسیر بازگشت به عقب فعال می‌شود. این تست دقیقاً چه مواردی را بررسی (assert) می‌کند؟

اصطلاحات کلیدی

برای مطالعه‌ی بیشتر

• Microsoft Agent Framework — Checkpointing and HITL — مفاهیم پایه‌ای چک‌پوینت و بازیابی اجاره.
• Cloudflare Agents — Human in the loop — استفاده از Durable Objects به‌عنوان بستر نگهداری وضعیت.
• EU AI Act — Article 14: Human oversight — خط مبنای قانونی برای نظارت انسانی.
• Anthropic — Measuring agent autonomy in practice — چارچوب قابلیت اطمینان برای جریان‌های کاری بلندمدت.
• Anthropic — Claude Code Agent SDK: agent loop — ساختار جریان کاری برای روتین‌های Claude Code.