تأیید انسانی باید به کدام اقدام وصل باشد؟
عامل می‌تواند پیش‌نویس یک درخواست خرید را بسازد، اما ثبت نهایی آن اثر عملیاتی دارد. تأیید انسانی زمانی مؤثر است که کاربر بداند دقیقاً چه چیزی، در کدام سامانه و با چه پیامدی تغییر می‌کند. تأیید کلی در شروع گفت‌وگو نمی‌تواند جای بازبینی اقدام مشخص را بگیرد.
مستندات LangGraph الگوی توقف و ادامه اجرا با ذخیره وضعیت را شرح می‌دهد. این سازوکار فنی نقطه توقف را فراهم می‌کند؛ سیاست اینکه چه کسی اجازه تأیید دارد و چه داده‌ای باید نشان داده شود، مسئولیت برنامه سازمانی است.
برای ادامهٔ این بحث، مقالهٔ «هویت و دسترسی امن برای عامل‌های هوش مصنوعی» را در دانشنامهٔ لیان بخوانید.
پیشنهاد اجرایی: بسته تأیید قابل‌بررسی
برای درخواست خرید، اقلام، تعداد، واحد پول، تأمین‌کننده و جمع نهایی را کنار تفاوت با وضعیت فعلی نمایش دهید. منابعی که عامل از آن‌ها استفاده کرده نیز در دسترس باشند. کاربر باید بتواند رد کند، اصلاح بخواهد یا تأیید کند؛ یک دکمه مبهم «ادامه» برای چنین تصمیمی کافی نیست.
تأیید را به شناسه اقدام و نسخه محتوای پیشنهادی وصل کنید. اگر تعداد یا گیرنده تغییر کرد، تأیید قبلی دیگر معتبر نیست. اعتبار زمانی محدود نیز از اجرای پیشنهاد کهنه پس از تغییر شرایط جلوگیری می‌کند.
ادامه اجرا نباید عملیات را تکرار کند
پس از قطع شبکه یا راه‌اندازی مجدد، برنامه باید وضعیت اقدام را بداند: در انتظار تأیید، تأییدشده، در حال اجرا یا انجام‌شده. شناسه یکتای عملیات کمک می‌کند ادامه اجرا دوباره همان سفارش را نسازد. بررسی وضعیت در سامانه مقصد نیز بخشی از بازیابی خطاست.
اگر نتیجه عملیات نامعلوم است، پیش از تلاش مجدد آن را با مقصد تطبیق دهید. نمایش موفقیت پیش از دریافت نتیجه قطعی می‌تواند هم کاربر را گمراه کند و هم عامل را به اجرای دوباره هدایت کند.
ثبت شواهد و آزمون حالت‌های شکست
نام تأییدکننده، زمان، نسخه پیشنهاد و نتیجه اقدام را با حداقل داده لازم ثبت کنید. متن حساس و رمزها نباید صرفاً برای کامل شدن گزارش در لاگ ذخیره شوند. مسیر دسترسی به گزارش نیز باید متناسب با نقش سازمانی محدود باشد.
در آزمون پذیرش، تغییر پیشنهاد بعد از تأیید، تأیید توسط کاربر فاقد نقش، پایان اعتبار و دو بار کلیک را بررسی کنید. معیار موفقیت فقط اجرای مسیر عادی نیست؛ سیستم باید در این حالت‌ها نیز از اقدام بی‌اجازه یا تکراری جلوگیری کند.
سناریوی خرید: کاربر دقیقاً چه چیزی را تأیید می‌کند؟
فرض کنید دستیار برای واحد اداری پیش‌نویس سفارش تجهیزات آماده می‌کند. صفحه تأیید باید فروشنده، اقلام، تعداد، مبلغ، مقصد ارسال و عملی که پس از تأیید انجام می‌شود را یکجا نشان دهد. عبارت مبهم «ادامه بده» برای کاربر روشن نمی‌کند که فقط پیش‌نویس ذخیره می‌شود یا سفارش برای طرف بیرونی ارسال خواهد شد. دکمه‌ها را با نتیجه عمل نام‌گذاری کنید و امکان بازگشت برای اصلاح داشته باشید.
تأیید را به نسخه معین پیشنهاد وصل کنید. اگر پس از بازبینی، تعداد کالا یا فروشنده عوض شد، تأیید قبلی نباید روی نسخه تازه اعمال شود. نمونه پیشنهادی این است که شناسه پیشنهاد، نسخه، مهلت اعتبار و هویت تأییدکننده کنار تصمیم ثبت شوند. قبل از اجرا دوباره بررسی کنید کاربر هنوز اختیار همان اقدام را دارد؛ داشتن مجوز در زمان ساخت پیش‌نویس لزوماً برای ساعت اجرای بعدی کافی نیست.
وضعیت‌های فرایند را روی کاغذ روشن کنید
پیش از اتصال ابزار واقعی، مسیر را با وضعیت‌های پیش‌نویس، منتظر تأیید، ردشده، منقضی، در حال اجرا، انجام‌شده و نیازمند پیگیری رسم کنید. برای هر انتقال بنویسید چه کسی یا چه رخدادی آن را مجاز می‌کند. رد پیشنهاد باید مسیر اجرا را ببندد؛ درخواست اصلاح هم باید نسخه جدید بسازد و دوباره به بازبینی برسد. این مدل پیشنهادی را با فرایند سازمان تطبیق دهید، نه اینکه نام وضعیت‌ها را بدون معنا به رابط اضافه کنید.
اگر کاربر صفحه را ببندد یا فرایند متوقف شود، پیشنهاد در انتظار نباید از حافظه موقت گم شود. امکان ادامه از وضعیت ذخیره‌شده لازم است، همراه با بررسی دوباره انقضا و مجوز. مسئول پیگیری پیشنهادهای معطل را هم تعیین کنید. ارسال پی‌درپی اعلان جای سیاست روشن درباره مهلت و جانشین تأییدکننده را نمی‌گیرد؛ پیشنهاد قدیمی بهتر است منقضی شود تا بی‌خبر اجرا شود.
وقتی پاسخ ابزار قطع شد، دوباره اجرا نکنید مگر با بررسی
یک حالت حساس زمانی است که درخواست ثبت سفارش ارسال شده، اما پاسخ ابزار به دست دستیار نمی‌رسد. این وضعیت با شکست قطعی یکسان نیست؛ ممکن است سفارش ثبت شده باشد. برای هر اقدام شناسه یکتا تعریف کنید و ابتدا وضعیت همان شناسه را در سامانه مقصد بررسی کنید. اگر مقصد از جلوگیری از ثبت تکراری پشتیبانی نمی‌کند، باید راه تطبیق و بازبینی را از قبل طراحی کنید.
در صفحه کاربر، وضعیت نامعلوم را به‌صورت «نیازمند بررسی نتیجه» نمایش دهید. زدن دوباره دکمه نباید یک سفارش مستقل بسازد. آزمون قطع ارتباط را در سه نقطه اجرا کنید: قبل از ارسال، پس از دریافت مقصد و بعد از انجام عمل. نتیجه قابل‌قبول آن است که برای هر پیشنهاد مشخص شود چه چیزی واقعاً رخ داده و چه کسی باید پیگیری کند؛ یک پیام عمومی «خطا، دوباره تلاش کنید» برای عملیات اثرگذار کافی نیست.
آزمون نقش‌ها و کیفیت تجربه تأیید
با دو کاربر آزمایش کنید: سازنده پیش‌نویس و تأییدکننده دارای اختیار. سپس حالت‌های تأیید توسط فرد فاقد مجوز، تأیید دوباره، تغییر مبلغ پس از تأیید و اجرای پیشنهاد منقضی را بسنجید. اگر سیاست سازمان جداسازی سازنده و تأییدکننده را لازم می‌داند، آن را در منطق اجرا کنترل کنید؛ پنهان کردن یک دکمه کافی نیست. همه موارد را ابتدا با ابزار آزمایشی و داده غیرحساس انجام دهید.
معیار کیفیت فقط توقف اقدام خطرناک نیست. اندازه بگیرید کارشناس برای فهم پیشنهاد چند بار به سند اصلی مراجعه می‌کند، چه تعداد پیشنهاد به‌علت ابهام برمی‌گردد و کدام فیلد بیشترین اصلاح را دارد. تأییدی که اطلاعات کافی ندارد ممکن است به کلیک تشریفاتی تبدیل شود. هدف، تصمیم آگاهانه درباره یک عمل مشخص است؛ جزئیات فنی غیرضروری را از خلاصه تصمیم جدا نگه دارید و شاهد لازم را با یک مسیر روشن در دسترس بگذارید.
پرسش‌های متداول
آیا هر پاسخ به تأیید نیاز دارد؟
خیر. نقطه تأیید را بر اساس اثر اقدام و سیاست سازمان تعریف کنید؛ خواندن سند با ثبت سفارش یکسان نیست.
با تغییر پیشنهاد چه می‌شود؟
تأیید باید به نسخه مشخص وصل باشد؛ تغییر مؤثر به بازبینی دوباره نیاز دارد.
منابع
- LangChainInterruptsOfficial documentation
- NISTAI Risk Management FrameworkOfficial framework
مطالعهٔ بیشتر در دانشنامهٔ لیان
- لیان داتا پارسهویت و دسترسی امن برای عامل‌های هوش مصنوعیبرای تکمیل بحث اختیار عامل، مدیریت هویت ماشینی، حداقل دسترسی و ثبت اقدام‌ها را در دانشنامهٔ لیان مطالعه کنید.
- لیان داتا پارسوقتی یک سند به دستیار هوشمند دستور می‌دهدبرای بررسی تزریق دستور غیرمستقیم، توضیح لیان دربارهٔ محتوای بیرونی، محدودکردن ابزار و کنترل انسانی را بخوانید.