سپردن اقدامات حساس به ایجنت‌های هوش مصنوعی — از تراکنشهای مالی گرفته تا تغییرات دیتابیس — بدون نظارت دقیق انسانی ریسک بسیار بالایی دارد. با این حال، افزودن یک دکمه‌ی ساده‌ی «تأیید / رد» مشکلی را حل نمی‌کند؛ کاربران پس از مدتی به فشردن ناخودآگاه و بدون بررسی دکمه‌ی تأیید عادت می‌کنند؛ پدیده‌ای که در مهندسی نرم‌افزار به تأیید بی‌چون‌وچرا (rubber-stamp approval) معروف است و در زمان بروز خطا، هیچ حفاظی برای سیستم ایجاد نمی‌کند.
الگوی مدرن «پیشنهاد و سپس ثبت قطعی» (propose-then-commit) با تکیه بر ذخیره‌سازی وضعیت در پایگاه‌های داده‌ی پایا، تولید کلید یکتایی تراکنش (idempotency key)، الزام کاربر به پاسخ‌گویی به چک‌لیست‌های چالشی و نهایتاً اعتبارسنجی تغییرات در مقصد، ایمنی ایجنت را در سطح استانداردهای عملیاتی تضمین می‌کند. در این درس ساختار این ماشین وضعیت را پیاده‌سازی و بررسی می‌کنیم.
اجماع سال 2026 روی مسئله‌ی انسان در چرخه (HITL یا Human-in-the-loop) کاملاً مشخص است. این الگو دیگر «ایجنت می‌پرسد، کاربر روی تأیید کلیک می‌کند» نیست؛ بلکه الگوی «پیشنهاد و سپس ثبت قطعی» (propose-then-commit) است: اقدام پیشنهادی همراه با یک کلید یکتایی تراکنش (idempotency key) در یک حافظه‌ی پایا ذخیره می‌شود؛ سپس نیت، تبار داده (data lineage)، دسترسی‌های درگیر، دامنه‌ی تخریب (blast radius) و طرح بازگشت به عقب (rollback plan) به بازبین نمایش داده می‌شود؛ اقدام فقط پس از تأیید صریح کاربر commit می‌شود؛ و در نهایت پس از اجرا اعتبارسنجی صورت می‌گیرد تا اطمینان حاصل شود اثر جانبی واقعاً در عمل رخ داده است. متد
interrupt()در LangGraph به همراه چک‌پوینت‌گیری PostgreSQL، رویدادRequestInfoEventدر Microsoft Agent Framework و متدwaitForApproval()در Cloudflare همگی همین ساختار را پیاده‌سازی می‌کنند. حالت شکست سنتی و همیشگی این الگو، «تأیید بی‌چون‌وچرا» (rubber-stamp approval) است: کاربر بدون بررسی واقعی، روی «تأیید» کلیک می‌کند. راهکار مستندشده برای حل این مشکل، مکانیزم «پرسش و پاسخ چالشی» (challenge-and-response) به همراه یک چک‌لیست صریح است.
صورت مسئله
ایجنت اقدامی انجام می‌دهد. کاربر باید تصمیم بگیرد: تأیید کند یا نه. اگر تصمیم‌گیری آنی باشد، احتمالاً هیچ بررسی واقعی در کار نبوده است. اگر تصمیم‌گیری ساختاریافته باشد، فرایند کند اما قابل‌اعتماد می‌شود. مسئله‌ی مهندسی این است: چطور بررسی ساختاریافته را به ساده‌ترین و طبیعی‌ترین مسیر پیش روی کاربر تبدیل کنیم؟
الگوی مرسوم HITL در سال 2023 یک پرامپت همگام بود: «ایجنت می‌خواهد ایمیلی با متن Y به کاربر X بفرستد — تأیید می‌کنید؟» کاربر روی تأیید کلیک می‌کند و همه حس می‌کنند سیستم امن است. اما در عمل، این نقطه از سیستم مدام دچار تأییدهای بی‌چون‌وچرا می‌شود: کاربران خیلی سریع تأیید می‌کنند، این تأییدها ارزش پیش‌بینی پایینی دارند و امنیت اقدام را تضمین نمی‌کنند، و وقتی ایجنت به خطا می‌رود، لاگ‌های ممیزی تاریخچه‌ای طولانی از تأییدهایی را نشان می‌دهند که کاربر حتی آن‌ها را به خاطر نمی‌آورد.
الگوی سال 2026 — یعنی پیشنهاد و سپس ثبت قطعی — فرایند HITL را روی بستری پایا می‌برد، فراداده‌های ساختاریافته را به آن ضمیمه می‌کند و به یک commit صریح نیاز دارد. تمام SDKهای مدیریت‌شده‌ی ایجنت نسخه‌ای از آن را پیاده کرده‌اند: interrupt() در LangGraph، رویداد RequestInfoEvent در Microsoft Agent Framework و waitForApproval() در Cloudflare. نام APIها تفاوت دارد، اما ساختار زیرین یکی است.
مفاهیم پایه
ماشین وضعیت پیشنهاد و سپس ثبت قطعی
- پیشنهاد (Propose): ایجنت یک اقدام پیشنهادی تولید می‌کند. این اقدام در یک پایگاه داده‌ی پایا (PostgreSQL، Redis، Durable Object) ذخیره می‌شود و شامل موارد زیر است:
- نیت (چرا ایجنت چنین کاری می‌کند)
- تبار داده (چه منبعی به این پیشنهاد ختم شد)
- دسترسی‌های درگیر (کدام scopeها، فایل‌ها یا اندپوینت‌ها)
- دامنه‌ی تخریب (بدترین سناریوی ممکن چیست)
- طرح بازگشت به عقب (اگر commit شد، چطور آن را خنثی کنیم)
- کلید یکتایی تراکنش (یکتا به ازای هر پیشنهاد؛ ارسال مجدد همان رکورد را برمی‌گرداند)
- نمایش (Surface): بازبین، پیشنهاد را به همراه تمام فراداده‌ها می‌بیند. بازبین حتماً یک انسان است (نه ایجنتی که خروجی خودش را بازبینی کند).
- ثبت قطعی (Commit): تأیید صریح ثبت می‌شود و اقدام اجرا می‌گردد.
- اعتبارسنجی (Verify): پس از اجرا، وضعیت اثر جانبی دوباره خوانده می‌شود تا درستی وقوع آن تأیید شود. اگر گام اعتبارسنجی شکست بخورد، سیستم وارد یک وضعیت خطای شناخته‌شده می‌شود و هشدارها به صدا درمی‌آیند.
کلید یکتایی تراکنش
بدون کلید یکتایی تراکنش، یک تلاش مجدد پس از خطای گذرا می‌تواند اقدامی تأییدشده را دو بار اجرا کند. یک مثال ملموس: کاربر گزینه‌ی «انتقال 100 دلار از A به B» را تأیید می‌کند. شبکه برای لحظه‌ای قطع می‌شود. جریان کاری دوباره تلاش می‌کند. کاربر یک بار تأیید کرده، اما انتقال پول دو بار اجرا می‌شود! کلید یکتایی، تأیید کاربر را به یک اثر جانبی واحد و یکتا قفل می‌کند؛ در نتیجه اجرای دوم هیچ اثری ندارد (no-op).
این دقیقاً همان الگوی یکتایی تراکنشی است که در APIهای Stripe و AWS استفاده می‌شود. استفاده از همین الگو برای تأییدیه‌های ایجنت، در مستندات Microsoft Agent Framework صراحتاً قید شده است.
پایایی: چرا تأییدیه‌ها بیشتر از فرایندها عمر می‌کنند؟
اتاق انتظار تأیید، بخشی از وضعیت سیستم است که ایجنت مالک آن نیست. جریان کاری متوقف می‌شود (درس 12). وقتی تأییدیه می‌رسد، جریان کاری دقیقاً از همان نقطه ادامه می‌یابد. به همین دلیل است که LangGraph متد interrupt() را به جای نگه‌داری در حافظه (in-memory)، با چک‌پوینت‌گیری PostgreSQL جفت می‌کند؛ به این ترتیب حتی اگر تأییدیه دو روز بعد برسد، جریان کاری دست‌نخورده در دسترس خواهد بود.
تأیید بی‌چون‌وچرا و راهکار پرسش و پاسخ چالشی
رابط کاربری پیش‌فرض برای HITL (دکمه‌های «تأیید» / «رد») به تأییدهای شتاب‌زده بدون هیچ بازبینی واقعی ختم می‌شود. راهکار مستندشده برای این چالش: یک چک‌لیست پرسش و پاسخ چالشی که قبل از فعال شدن دکمه‌ی تأیید، پاسخ‌های صریح و مثبت به سؤالاتی مشخص را الزامی می‌کند. شکل عینی این روش:
- «آیا می‌دانید این اقدام به کدام منبع دست می‌زند؟ [ ]»
- «آیا بررسی کرده‌اید که دامنه‌ی تخریب قابل‌قبول است؟ [ ]»
- «آیا در صورت شکست، طرح بازگشت به عقب دارید؟ [ ]»
این بوروکراسی بیهوده نیست؛ یک سازوکار الزام‌آور است. بازبینی که نتواند این گزینه‌ها را تیک بزند، یا توضیحات بیشتری می‌خواهد (ارجاع به سطح بالاتر) یا اقدام را رد می‌کند (پیش‌فرض امن). پژوهش‌های شرکت Anthropic در زمینه‌ی ایمنی ایجنت‌ها، صراحتاً HITL مبتنی بر چک‌لیست را راهکاری برای الگوهای تأیید بی‌چون‌وچرا معرفی می‌کنند.
چه مواردی پیامددار محسوب می‌شوند؟
هر اقدامی به الگوی پیشنهاد و سپس ثبت قطعی نیاز ندارد. راهنمای سال 2026:
- اقدامات پیامددار (همیشه نیازمند HITL): نوشتنهای برگشتناپذیر، تراکنشهای مالی، ارتباطات به خارج از سیستم، تغییرات در دیتابیس محیط عملیاتی (پروداکشن)، عملیات مخرب روی فایل‌سیستم.
- اقدامات برگشت‌پذیر (گاهی نیازمند HITL): ویرایش فایل‌های محلی، تغییرات محیط آزمایشی (staging)، نوشتنهای برگشت‌پذیر با طرح بازگشت به عقبِ مشخص.
- خواندن‌ها و بازرسی‌ها (هرگز نیازمند HITL): خواندن یک فایل، فهرست کردن منابع، فراخوانی یک API فقط-خواندنی.
اعتبارسنجی پس از اقدام
«دستور commit اجرا شد» به معنای «اثر جانبی رخ داد» نیست. قطع ارتباط شبکه و شرایط رقابتی (race conditions) می‌توانند وضعیتی ایجاد کنند که جریان کاری فکر کند موفق شده، اما در لایه‌ی بک‌اند ثبت نشده باشد. در مرحله‌ی اعتبارسنجی، پس از commit منبع مقصد دوباره خوانده می‌شود تا از وقوع تغییر اطمینان حاصل شود. این دقیقاً شبیه تراکنشهای دیتابیس با بخش‌های RETURNING یا اجرای GetObject بعد از PutObject در AWS است.
ماده‌ی 14 قانون هوش مصنوعی اتحادیه‌ی اروپا (EU AI Act)
ماده‌ی 14 نظارت مؤثر انسانی را برای سیستم‌های هوش مصنوعی پرخطر در اتحادیه‌ی اروپا الزامی می‌کند. کلمه‌ی «مؤثر» جنبه‌ی تشریفاتی ندارد؛ متن مقررات صراحتاً الگوهای تأیید بی‌چون‌وچرا را رد می‌کند. در مستندات انطباق پلتفرم Microsoft Agent Governance Toolkit، ساختار «پیشنهاد و سپس ثبت قطعی همراه با پرسش و پاسخ چالشی»، تنها مدلی است که از آزمون دقیق ماده‌ی 14 سربلند بیرون می‌آید.
پیاده‌سازی و اجرا
فایل code/main.py یک ماشین وضعیتِ پیشنهاد و سپس ثبت قطعی را فقط با استفاده از کتابخانه‌ی استاندارد Python پیاده‌سازی می‌کند. حافظه‌ی پایا یک فایل JSON است. کلید یکتایی تراکنش از هش (thread_id, action_signature) ساخته می‌شود. کد راه‌انداز سه حالت را شبیه‌سازی می‌کند: یک فلو تأیید تمیز، تلاش مجدد پس از خطای گذرا (که نباید اقدام را دو بار اجرا کند)، و مقایسه‌ی حالت پیش‌فرضِ تأیید بی‌چون‌وچرا با فلو پرسش و پاسخ چالشی.
تحویل به پروداکشن
فایل outputs/skill-hitl-design.md یک جریان کاری پیشنهادی برای HITL را از نظر ساختار پیشنهاد و سپس ثبت قطعی بررسی می‌کند و نبودِ احتمالی فراداده‌ها، کلید یکتایی، اعتبارسنجی یا لایه‌های پرسش و پاسخ چالشی را علامت می‌زند.
تمرین‌ها
-
فایل
code/main.pyرا اجرا کنید. مطمئن شوید تلاش مجدد برای یک پیشنهاد تأییدشده، از رکورد پایا استفاده می‌کند و اقدام را دوباره اجرا نمی‌کند. حالا کلید یکتایی را طوری تغییر دهید که شامل برچسب زمان (timestamp) باشد و نشان دهید که تلاش مجدد باعث دو بار اجرا شدن اقدام می‌شود. -
رکورد پیشنهاد را گسترش دهید و یک فیلد
rollbackبه آن اضافه کنید. اجرایی را شبیه‌سازی کنید که مرحله‌ی اعتبارسنجی آن شکست می‌خورد. نشان دهید که فرایند بازگشت به عقب چطور به صورت خودکار فعال می‌شود. -
مستندات
RequestInfoEventدر Microsoft Agent Framework را بخوانید. یکی از فیلدهای فراداده را پیدا کنید که در این API وجود دارد اما موتور ساده‌ی ما فاقد آن است. آن را به کد اضافه کنید و توضیح دهید از سیستم در برابر چه خطری محافظت می‌کند. -
یک چک‌لیست پرسش و پاسخ چالشی برای یک اقدام مشخص (مثلاً «ارسال پست در یک حساب عمومی توییتر») طراحی کنید. بازبین باید به کدام سه سؤال پاسخ دهد؟ چرا این سه سؤال؟
-
حالتی را نام ببرید که در آن یک پرامپت همگام «تأیید می‌کنید؟» کافی است (نیازی به حافظه‌ی پایا نیست). دلیل خود را توضیح دهید و مشخص کنید چه سطح ریسکی را می‌پذیرید.
اصطلاحات کلیدی
| اصطلاح | آنچه افراد می‌گویند | معنای واقعی آن |
|---|---|---|
| پیشنهاد و سپس ثبت قطعی (Propose-then-commit) | «تأیید دو مرحله‌ای» | پیشنهاد پایدارشده + commit صریح + اعتبارسنجی |
| کلید یکتایی تراکنش (Idempotency key) | «توکن امن برای تلاش مجدد» | شناسه یکتا برای هر پیشنهاد؛ اجرای دوم بدون اثر (no-op) |
| تبار داده (Data lineage) | «از کجا آمده» | محتوای منبع دقیقی که به ثبت این پیشنهاد منجر شده است |
| دامنه‌ی تخریب (Blast radius) | «بدترین سناریو» | گستره‌ی اثرات سیستم اگر اقدام به خطا برود |
| تأیید بی‌چون‌وچرا (Rubber-stamp) | «تأیید سریع» | کلیک روی «تأیید» بدون بررسی واقعی |
| پرسش و پاسخ چالشی (Challenge-and-response) | «چک‌لیست الزام‌آور» | بازبین باید صراحتاً سؤالات مشخصی را تأیید کند |
| رویداد RequestInfoEvent | «عنصر پایه در MS Agent Framework» | درخواست پایای HITL همراه با فراداده‌های ساختاریافته |
متدهای interrupt() / waitForApproval() |
«عناصر پایه‌ی فریم‌ورک‌ها» | معادل‌های همین ساختار در LangGraph و Cloudflare |
برای مطالعه‌ی بیشتر
- Microsoft Agent Framework — انسان در چرخه — بررسی
RequestInfoEventو تأییدیه‌های پایا. - Cloudflare Agents — انسان در چرخه — بررسی
waitForApproval()و اشیای پایا (Durable Objects). - Anthropic — سنجش خودمختاری ایجنت در عمل — نقش HITL در کاهش ریسک‌های بلندمدت.
- قانون هوش مصنوعی اتحادیه‌ی اروپا — ماده‌ی 14: نظارت انسانی — خط مبنای قانونی برای سیستم‌های پرخطر.
- Anthropic — منشور کلود (ژانویه 2026) — چارچوب‌بندی منشوری در موضوع نظارت.