نقاط بازرسی و بازپسین
Type: Learn
Languages: Python (stdlib, checkpoint and rollback state machine)
Prerequisites: Phase 15 · 12 (Durable execution), Phase 15 · 15 (Propose-then-commit)
Time: ~60 minutes
مشکل
اجرای پایدار (درسه 12) باعث می شود که یک عامل تصادفی دوباره اجرا شود. پیشنهاد پس از انجام (درسه 15) باعث می شود که یک عمل تایید شده قابل بررسی باشد. این درس به آنها ملحق می شود: چه اتفاقی می افتد وقتی یک عمل تایید شده جزوی اجرا می شود، تصادف می کند و دوباره اجرا می شود؟ rollback چه زمانی اجرا می شود و در برابر چه حالت؟
سیستم های واقعی این را به طور متفاوتی نشان می دهند:
- LangGraphدر هر انتقال گرافیک به PostgreSQL، اجاره باز می گردد و یک کارمند دیگر در آخرین نقطه بازرسی ادامه می یابد. جریان کار متوقف می شود
interrupt()، که خودش ادامه داره - Cloudflare Durable Objectsحالت هر کلید را در طول ساعت ها یا هفته ها نگه دارید. محاسبه را با ذخیره سازی برای اقدام تایید شده قرار دهید.
- Microsoft Agent Frameworkافشا می کند
Checkpointدر API جریان کار، تکرار و بی اختیار بودن شامل تلاش های مجدد می شود.
در هر مورد، ترکیبی که واقعا کار می کند این است: کلید idempotency (ممنع دو بار اجرا) + بررسی پیش شرط (حال هنوز چیزی است که ما علیه آن تایید کردیم) + تأیید پس از عمل (علاقه جانبی واقعا اتفاق افتاد) + بازگشت به تایید شکست.
مفهوم
هر انتقال ادامه داره
یک انتقال حالت گرافیک هر مرحله ای است که جریان کار را از یک حالت نامگذاری به حالت دیگر منتقل می کند. پیاده سازی های نابغه فقط در نقاط تعهد خاص باقی می مانند؛ پیاده سازی های تولید هر انتقال باقی می مانند. هزینه (چند نفر اضافه می نویسند) نسبت به افزایش قابلیت اطمینان کوچک است (بازخورد در هر نقطه، بازیابی اجاره دقیق است).
بازیافت اجاره
وقتی یک کارگر سقوط می کند، جریان کار از دست نمی رود؛ اجاره (یک ادعای کوتاه مدت که این کارگر این کار را انجام می دهد) به سادگی به پایان می رسد. یک کارگر دیگر آخرین نقطه بازرسی را برمی گیرد و از کار خود ادامه می دهد. مکانیسم اجاره کاری این است که به سیستم های تولید اجازه می دهد بدون از دست دادن کار در پرواز، از کار در حال اجرا در جریان باشد.
بی قدرت و شرط های پیش فرض
تنها بی اختیار بودن کافی نیست. به این نکته توجه کنید: یک جریان کار برای "تغییر" تأیید شده است.$100 from A to B when balance > $1000. " جریان کار انجام می شود، در میان اجرای سقوط می کند و شروع می شود. اگر فقط کلید idempotency چک شود و اجرای دوباره شروع شود، انتقال یک بار اجرا می شود (صحيح). اما در نظر بگیرید که بین توقف و شروع کار، تراز A به 500 دلار از طریق یک جریان کار متفاوت کاهش می یابد. بررسی idempotency هنوز هم عبور می کند؛ شرط پیش فرض نمی کند. بدون بررسی پیش شرط، ما یک اوورتراف را ارسال می کنیم.
هر اقدام بعدی به هر دو نیاز دارد:
- Idempotency key: از دو بار اجرا جلوگیری می کند.
- Precondition check: تایید می کند که دولت هنوز با آنچه تایید شده است سازگار است.
بررسی پس از اقدام
" ابزار برگشت 200 " تایید نیست. تایید واقعی حالت هدف را دوباره می خواند و تأکید می کند که اثر جانبی واقعا رخ داده است. الگوها:
- به روز رسانی پایگاه داده:
UPDATE ... RETURNING *سپس وضعیت مورد نظر مطابقت خط برگشت را تأیید کنید. - ارسال ایمیل: فولدر ارسال شده را برای شناسایی پیام پس از ارسال بررسی کنید.
- نوشتن فایل: فایل را دوباره بخوانید و هش کنید.
- تماس با API: پیگیری
GETدر مورد منبع هدف.
اگه تاییدش شکست خورد، جریان کار در حالت بد شناخته شده است.
برنامه های رول بیک
هر اقدام بعدی در پیشنهاد پس از تعهد (درسی 15) دارای یک برنامه برگشت است.
- In-band rollback: اثرات جانبی را مستقیماً معکوس کنید (
DELETEبعد ازINSERT،Send-correction-emailبعد از ارسال) - Compensating transaction: یک عمل جدید که اصل را خنثی می کند (نمونه استاندارد SAGA).
- Out-of-band rollback: هشدار دادن به انسان، توقف جریان کار، ترک وضعیت بد برای تحقیق.
در این پیشنهاد باید بدون پیشگیری از فعالیت ها (ما نمی توانیم این کار را از بین ببریم) ذکر شود.
قانون هوش مصنوعی اتحادیه اروپا ماده 14 خواندن عملیاتی
ماده 14 نیاز به " نظارت موثر انسانی " برای سیستم های با ریسک بالا دارد.
- پوائنتهاي بازرسي توسط حسابدار قابل بازرسي هستند.
- تمرینات رول بیک (که حداقل یک بار از پایان به آخر آزمایش می شود) انجام می شود.
- مسیر حسابرسی از یک انتشار زنده می ماند (پشت بازبینی نقطه چک فوري نیست).
- تاییدات شکست خورده به خاطرش هشدار داده می شود، نه به طور خاموش ثبت شده.
یک جریان کار که در نیمه انجام کار رکود می کند، اثر جانبی را ادامه می دهد و بدون یک مسیر تأیید + بازگشت کامل می کند، از آزمایش ماده 14 زنده نمی ماند.
حالت شکست حاد: دو مرحله اجرا
شایع ترین حادثه تولید در این فضا:
- اقدام تایید شده، کلید آزادسازی k.
- انجام شروع ميشه، اجرا ميشه، 200 رو باز ميکنه
- جریان کار قبل از ادامه وضعیت "مکلف" خراب می شود.
- جریان کار ادامه می یابد؛ "مقرر شده اما متعهد نشده" را می بیند؛ مجددا اجرا می شود.
- اثر جانبي دو بار مياد
کاهش: قصد "در پرواز" را قبل از اجرا ادامه دهید، با کلید idempotency اجرا کنید، سپس "تعهد" را تنها پس از تأیید پس از عمل نشان دهید. اگر آتش بازی عمل و نوشتن وضعیت شکست خورده باشد، می دانید که باید تأیید و (اگر لازم باشد) دوباره آتش بزنید. اگر نوشتن وضعیت موفق شود و عمل شکست یابد، شما دقیقاً یک بار از طریق مسیر بازیابی تأیید و آتش می کنید.
ازش استفاده کن
code/main.pyیک جریان کار کنترل شده با idempotency، پیش شرط، تایید و رول بیک را اجرا می کند. راننده چهار سناریو را شبیه سازی می کند: clean run، try again after crash (idempotency catches), fail precondition (aborts workflow without firing), check fail (rollback fires).
-باده
outputs/skill-rollback-rehearsal.mdیک آزمایش آزمایشی بازگشت برای یک جریان کاری پیشنهادی را طراحی می کند و پس زمینه نقطه بازرسی را برای پایداری مسیر بازرسی بررسی می کند.
تمرینات
- فرار کن
code/main.pyبراي پرونده تصادف در طول انجام، يک بار در هر بار دوباره، آتش سوزی ها رو تایید کن
- الگوی "بذار نشان اول انجام شود، سپس انجامش بده" را تغییر دهید تا وضعیت بعد از عمل آتش را بنویسید. سناریو تصادف را تکرار کنید. اندازه گیری کنید که چند عمل تکراری آتش می زند.
- طرح بازپسین برای یک عمل تولید خاص (به عنوان مثال "پست به یک کانال Slack") طراحی کنید. به عنوان باند، تعویض یا خارج از باند طبقه بندی کنید. انتخاب را توجیه کنید.
- یک جریان کار را که می دانید، شناسایی کنید. هر انتقال حالت را شناسایی کنید. هر یک را با یک نیاز به دوام (مستقیم / ادامه ندهید) نشان دهید. آنهایی را که در حال حاضر ادامه نمی دهید، شمارش کنید.
- آزمایش تکراری: طراحی یک آزمایش انتهای تا انتهای که یک جریان کار واقعی را اجرا کند، آن را خراب کند و آتش های مسیر برگشت را تأیید کند. آزمایش چه چیزی را ادعا می کند؟
اصطلاحات کلیدی
| Term | What people say | What it actually means |
|---|---|---|
| Checkpoint | "Save point" | Every graph-state transition persists to a durable store |
| Lease | "Worker claim" | Short-lived claim that a worker is executing a run; expires on crash |
| Precondition | "State gate" | Assertion that the state is still consistent with the approved action |
| Post-action verify | "Re-read check" | Confirm the side effect actually happened in the target system |
| In-band rollback | "Direct undo" | Reverse the side effect with the inverse operation |
| Compensating transaction | "SAGA undo" | A new action that neutralizes the original |
| Mark-as-done-first | "Status write order" | Persist the committed status before returning from commit |
| Article 14 | "EU AI Act human oversight" | Operational: queryable checkpoints, rehearsed rollbacks, auditable trail |
خواندن بیشتر
- Microsoft Agent Framework — Checkpointing and HITL پریمتیو پوائنترها و بازیافت اجاره
- Cloudflare Agents — Human in the loop اشیاء پایدار به عنوان یک زیربنای حالت.
- EU AI Act — Article 14: Human oversight پایه ی تنظیم کننده.
- Anthropic — Measuring agent autonomy in practice چارچوبی برای روند کار درازمدت
- Anthropic — Claude Code Agent SDK: agent loop شکل جریان کار برای روتین های کد کلاود
This free lesson is part of the AI Engineering from Scratch curriculum. Read the full explanation, run the lesson code, and verify the result in the interactive reader or from the repository source.
Browse the complete course catalog or open this lesson on GitHub.