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

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

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

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

لغو سه معنای متفاوت دارد

تیم‌ها معمولاً سه وضعیت را در واژه «لغوشده» فشرده می‌کنند:

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

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

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

پروتکل‌ها چه چیزی را ثابت می‌کنند

استاندارد DOM در WHATWG AbortController را راهی برای ذخیره دلیل توقف و خبرکردن مشاهده‌گرها تعریف می‌کند؛ سیگنال وابسته نیز می‌تواند چند منشأ مانند اقدام کاربر و پایان مهلت را ترکیب کند. این سازوکار محلی مفید است، اما پروتکل بازگردانی توزیع‌شده نیست. هر API باید الگوریتم واکنش به سیگنال داشته باشد و سامانه دوردست فقط وقتی آن را می‌بیند که برنامه نیت توقف را منتقل کند.

راهنمای لغو gRPC بر همکاری‌پذیربودن این رفتار تأکید دارد: ممکن است هندلر سرور مشغول باشد، کتابخانه معمولاً نمی‌تواند کد برنامه را قطع کند و هندلر طولانی باید وضعیت لغو را بررسی و کار خودش را متوقف کند. در بعضی زبان‌ها انتشار به فراخوانی بالادستی خودکار و در بعضی دیگر مسئولیت برنامه است. مفاهیم پایه gRPC هشدار مهم‌تری می‌دهد: تغییرهای پیش از لغو بازگردانده نمی‌شوند و حتی مشتری و سرور می‌توانند درباره نتیجه همان RPC به جمع‌بندی محلی متفاوت برسند.

توقف زیرساخت نیز مرز مشابهی دارد. Kubernetes در چرخه عمر Pod مرحله آرام و سپس توقف اجباری را توضیح می‌دهد: فرایند سیگنال توقف و مهلت می‌گیرد و بعد ممکن است SIGKILL دریافت کند. حذف اجباری در API منتظر اثبات حذف فرایند از گره نمی‌ماند. کشتن کارگر نیز به‌تنهایی درباره پرداخت، پیام، رزرو یا نوشتنی که پیش‌تر به سامانه دیگر فرستاده شده چیزی نمی‌گوید.

ارکستراتورها این فاصله را صریح نشان می‌دهند. AWS Step Functions لغو کارهای یکپارچه .sync را تلاشی با بهترین توان می‌داند که ممکن است به‌دلیل مجوز یا اختلال شکست بخورد. مایکروسافت در مستند مدیریت نمونه Durable Task می‌گوید درخواست پایان در صف قرار می‌گیرد، وضعیت Terminated بعداً حاصل می‌شود و در حال حاضر این توقف به فعالیت‌ها یا زیرارکستراسیون‌ها منتشر نمی‌شود؛ آن‌ها ممکن است تا پایان ادامه دهند.

Temporal انتخاب را در حالت‌های لغو فعالیت در SDK رسمی جاوا نمایان می‌کند: انتظار برای تأیید، تلاش برای لغو و بازگشت فوری، یا رهاکردن بدون درخواست لغو. اگر فعالیت ضربان نفرستد یا درخواست را نادیده بگیرد، انتظار برای تأیید می‌تواند طولانی شود. این اسناد سازوکار و محدودیت را ثابت می‌کنند. قرارداد عملیاتی ادامه این مقاله تحلیل ژرف است، نه استانداردی منتشرشده از سوی این پروژه‌ها.

یکی از چهار قرارداد توقف را انتخاب کنید

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

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

نیت منطقی را در پاکت لغو قرار دهید

لغو باید یک کار منطقی را در همه تلاش‌ها و فرزندان نشانه بگیرد. این پاکت مورد اعتماد را بیرون متن تولیدشده مدل حمل کنید:

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

ماشین حالتی بسازید که ابهام را می‌پذیرد

یک مقدار cancelled=true گذار واقعی را نشان نمی‌دهد. حالت‌های صریح به کار ببرید:

• RUNNING: کار ممکن است آغاز یا ثبت شود؛
• STOP_REQUESTED: نیت تغییر کرده و ساخت فرزند تازه ممنوع است؛
• QUIESCING: فرزندان شناخته‌شده در حال تأیید، تخلیه یا توقف اجباری‌اند؛
• STOPPED_CLEAN: فرزندان لازم تأیید کرده‌اند اثر مرتبطی در حال حرکت نیست؛
• STOPPED_WITH_EFFECTS: اجرا متوقف شده، اما اثر ثبت‌شده معتبر و آشکار مانده است؛
• COMPENSATING: اقدام معکوس مجاز در حال اجراست؛
• RECONCILIATION_REQUIRED: سامانه نمی‌تواند وضعیت تجاری لازم را خودکار تشخیص دهد یا بازگرداند؛
• UNKNOWN: یک فرزند یا سامانه بیرونی در دسترس نیست و نتیجه حل‌نشده است.

فقط کنترل‌گر باید با شاهد کارگر و سامانه بیرونی این حالت‌ها را جلو ببرد. رابط می‌تواند فوراً «درخواست توقف ثبت شد» بگوید و بعد به «متوقف شد»، «متوقف شد؛ دو اثر باقی است» یا «نیازمند بررسی» تغییر کند. وضعیت میانی صادقانه از پایان مطمئن اما نادرست بهتر است.

حالت UNKNOWN را پس از پایان مهلت موفق نکنید؛ تطبیق را زمان‌بندی و شناسه‌ها را حفظ کنید. راهنمای گردش کار پایدار عامل توضیح می‌دهد چرا وضعیت قابل بازسازی باید بیرون فرایند گذرای مدل بماند.

لغو را در درخت کار منتشر کنید، نه فقط در یک سوکت

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

با رسیدن STOP_REQUESTED:

1. پذیرش فرزند تازه را ببندید؛
2. درخواست توقف را پایدار منتشر کنید، نه فقط روی اتصال مشتری؛
3. دلیل و مهلت باقی‌مانده را به فرزندان فعال برسانید؛
4. کار صف‌شده را پیش از اجاره کارگر نهایی کنید؛
5. از کارگر همکاری‌پذیر بخواهید نقطه امن ذخیره کند، منبع را آزاد سازد و تأیید بدهد؛
6. کارگر بی‌پاسخ را طبق قرارداد تشدید کنید؛
7. اثر بیرونی را مستقل از زنده‌بودن کارگر جویا شوید؛
8. حالت نهایی را از تأییدها و دفتر اثر محاسبه کنید.

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

نقطه تعهد را پیش از اجرای ابزار مشخص کنید

هر رابط ابزار باید کلاس اثر و شاهد تعهد خود را اعلام کند:

هرجا یکپارچه‌سازی اجازه می‌دهد، prepared، submitted، accepted، committed و verified را جدا ثبت کنید. خطرناک‌ترین لحظه رقابت لغو با تعهد بیرونی است. فروشنده شاید درست پیش از دیدن توقف درخواست را پذیرفته باشد، اما پاسخ هنوز نرسیده باشد. با شناسه نیت یا کلید تکرارپذیری جست‌وجو کنید؛ از لغو انتقال نتیجه نگیرید که ثبت رخ نداده است.

جبران، پاک‌کن نیست؛ اقدام پیامددار تازه‌ای با مجوز، تکرارپذیری، شاهد و تأیید مستقل است. پیش از اجرا وضعیت تجاری مطلوب و کم‌زیان‌ترین مسیر رسیدن به آن را تعریف کنید.

مثال عملی: توقف عامل تأسیسات

به هشدار کاذب سرمایش برگردیم. گردش کار پنج فرزند دارد:

رابط نخست «درخواست توقف» نشان می‌دهد. فرزند تازه بسته می‌شود. تولید سریع تأیید می‌کند. رابط تیکت و تکنسین حالت نهایی را گزارش می‌دهند. API فروشنده در دسترس نیست؛ بنابراین گردش کار به RECONCILIATION_REQUIRED می‌رود، نه STOPPED_CLEAN.

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

توقف را با شاهد کامل برای تصمیم ثابت کنید

برای هر نیت منطقی، کمینه شاهد لازم برای پاسخ به این پرسش‌ها را نگه دارید:

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

این رخدادها را بدون ثبت بی‌دلیل محتوای پرامپت یا رازها پیوند دهید. راهنمای شاهد حسابرسی الگوی گسترده‌تر را می‌دهد: شاهد را پیرامون گزاره‌ای بسازید که بازرس باید ثابت کند، نه پیرامون هر فیلدی که ابزار پایش اتفاقی نشان می‌دهد.

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

رقابت زمانی، جدایی شبکه و تکمیل دیرهنگام را بیازمایید

آزمون لغو باید مرزهای زمان را هدف بگیرد:

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

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

دروازه لغو

پیش از آنکه گردش کار ابزارمحور هوش مصنوعی دکمه توقف تولیدی ارائه کند، پاسخ باید مثبت باشد:

1. آیا «توقف» برای علاقه کاربر، پذیرش ارکستراتور، اجرای کارگر و اثر بیرونی جدا تعریف شده است؟
2. آیا هر نیت منطقی و درخواست توقف شناسه پایدار و تکرارپذیر دارد؟
3. آیا قرارداد لازم—رهاکردن، درخواست، تأیید یا جبران—برای هر عملیات تعیین شده است؟
4. آیا کنترل‌گر پیش از انتظار برای فرزند قدیمی، ساخت فرزند تازه را می‌بندد؟
5. آیا کارگر لغو را بررسی، مهلت باقی را منتشر و حالت نهایی را تأیید می‌کند؟
6. آیا کار صف‌شده پیش از اجاره کارگر بعدی بی‌اعتبار می‌شود؟
7. آیا نقطه تعهد ابزار و شناسه مرجع اثر ثبت می‌شود؟
8. آیا سامانه می‌تواند نامعلوم، اثر باقیمانده و نیاز به تطبیق را نمایش دهد؟
9. آیا جبران مجوز و تأیید مستقل دارد؟
10. آیا ترافیک کنترل و پاک‌سازی هنگام اضافه‌بار محافظت می‌شود؟
11. آیا آزمون رقابت و جدایی شبکه به‌جای فرایند بسته، وضعیت تجاری را می‌سنجد؟
12. آیا کاربر قوی‌ترین ادعای پشتیبانی‌شده با شاهد را می‌بیند، نه قوی‌تر از آن؟

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

یادداشت منابع — بازبینی ۱۱ اوت ۲۰۲۶

• استاندارد DOM در WHATWG — استاندارد زنده، بازبینی‌شده در تاریخ انتشار؛ منبع دلیل توقف، مشاهده‌گر لغو، سیگنال وابسته و ترکیب با مهلت.
• gRPC: لغو — مستند جاری پروژه، بازبینی‌شده در تاریخ انتشار؛ منبع لغو همکاری‌پذیر هندلر و مسئولیت انتشار.
• gRPC: مفاهیم، معماری و چرخه عمر — مستند جاری پروژه، بازبینی‌شده در تاریخ انتشار؛ منبع تفاوت جمع‌بندی مشتری و سرور و بازنگشتن تغییرهای پیش از لغو.
• Kubernetes: چرخه عمر Pod — مستند زنده، بازبینی‌شده در تاریخ انتشار؛ منبع توقف آرام، توقف اجباری و محدودیت حذف اجباری API به‌عنوان شاهد.
• AWS Step Functions: الگوهای یکپارچه‌سازی سرویس — مستند جاری سرویس، بازبینی‌شده در تاریخ انتشار؛ منبع تلاش با بهترین توان برای لغو کار یکپارچه متوقف‌شده.
• Microsoft Durable Task: مدیریت نمونه ارکستراسیون — مستند جاری، بازبینی‌شده در تاریخ انتشار؛ منبع درخواست پایان صف‌شده، وضعیت نهایی دیرتر و منتشرنشدن توقف به فعالیت و زیرارکستراسیون.
• Temporal Java SDK: ActivityCancellationType — کد رسمی SDK، بازبینی‌شده در تاریخ انتشار؛ منبع انتظار تأییدشده، تلاش برای لغو و رهاکردن، از جمله وابستگی تأیید به ضربان فعالیت.