شهریور
Opsless و آینده کار
Human-in-the-loop؛ قانون طلایی «قبل از ارسال نشانم بده»
وقتی یک Agent میتواند خودش رکورد بسازد، پیام بفرستد یا پرداخت را تأیید کند، یک سؤال ساده ولی سرنوشتساز پیش میآید: تا کجا اجازه دارد بدون پرسیدن از انسان پیش برود؟ در معماریهای اولیهٔ Agent، پاسخ رایج این بود که هرچه خودکاری بیشتر، بهتر. تجربهٔ عملی نشان داده این نگاه اشتباه است. قانون طلاییای که در تیمهای جدی محصولات ایجنتی شکل گرفته این است: «قبل از ارسال نشانم بده». این مقاله دربارهٔ Human-in-the-loop (HITL) است؛ نه بهعنوان یک مانع در برابر خودکاری، بلکه بهعنوان شرط بقای اعتماد در یک محصول Opsless.
لیست مطالب
چرا HITL حذف نمیشود
در یک محصول Opsless، کاربر دیگر رابط کاربری سیستم را نمیبیند؛ او فقط Intent میدهد و Outcome میگیرد. همین غیبت رابط، ریسک را بالا میبرد: اگر Agent در تفسیر Intent اشتباه کند، کاربر تا وقتی که Outcome نهایی را نبیند، متوجه نمیشود. برای اقداماتی که برگشتپذیرند — مثلاً خواندن یک گزارش — این مشکلی ندارد. اما برای اقداماتی که برگشتناپذیرند یا از سازمان بیرون میروند — ارسال ایمیل به مشتری، تغییر قیمت، پرداخت وجه — یک اشتباه تفسیری میتواند خسارت واقعی بزند. HITL دقیقاً همان نقطهای است که پیش از عبور از این مرز، کنترل را به انسان برمیگرداند.
سطوح ریسک؛ نه همهچیز به یک اندازه حساس است
اشتباه رایج این است که یا همهچیز نیاز به تأیید دارد (که خودکاری را بیمعنا میکند) یا هیچچیز نیاز ندارد (که اعتماد را از بین میبرد). راهحل درست، دستهبندی اقدامات بر اساس ریسک است:
- خواندن (Read): جستوجوی رکورد، تولید گزارش، خلاصهسازی مکالمه. اینها هیچوقت نیاز به تأیید ندارند چون هیچ تغییری در دنیای بیرون ایجاد نمیکنند.
- نوشتن داخلی (Internal Write): بهروزرسانی یک فیلد، تغییر مرحلهٔ یک Deal، افزودن یادداشت. اینها معمولاً قابل بازگشتاند و میتوانند با یک سیاست محتاطانهتر، بدون تأیید لحظهای، اما با امکان Undo انجام شوند.
- ارسال به بیرون (External Send): ایمیل، پیامک، پیام در شبکهٔ اجتماعی، هر چیزی که به یک انسان واقعی خارج از سازمان میرسد. اینها برگشتناپذیرند — پیام ارسالشده را نمیتوان پس گرفت — و همیشه باید از دروازهٔ تأیید انسانی عبور کنند.
- اقدام مالی یا حقوقی: پرداخت، تغییر قرارداد، صدور فاکتور. بالاترین سطح ریسک؛ معمولاً به تأییدی چندمرحلهای نیاز دارد، نه فقط یک کلیک.
الگوی Confirmation و Dry-Run
پیادهسازی عملی HITL معمولاً روی دو مفهوم میایستد. اول، Dry-Run: Agent میتواند اقدام را تا مرحلهٔ آخر پیش ببرد، خروجی نهایی را بسازد، اما آن را واقعاً اجرا نکند — دقیقاً مثل پیشنویس یک ایمیل که هنوز ارسال نشده. دوم، Confirmation Gate: نقطهای مشخص در زنجیره که اجرای واقعی فقط با یک تأیید صریح از کاربر آزاد میشود. تعریف این گیت در همان Schema فراخوانی ابزار مشخص میشود:
{
"tool_call": {
"name": "message.send",
"arguments": {
"channel": "whatsapp",
"to": "+98912xxxxxxx",
"body": "سلام سارا، پیگیری قیمت واحد پیشنهادی رو ارسال کردم..."
},
"requires_approval": true,
"preview": true
}
}در این حالت، سیستم میزبان بهجای اجرای فوری، متن پیام را همراه با گزینهٔ تأیید یا ویرایش به کاربر نشان میدهد. تنها بعد از تأیید صریح، همان فراخوانی دوباره بدون preview اجرا میشود.
طراحی تجربهٔ کاربری پیش از ارسال
نمایش پیش از ارسال فقط یک تیک تأیید ساده نیست؛ باید سه چیز را واضح نشان دهد: چه کاری قرار است انجام شود (مثلاً متن دقیق پیام)، برای چه کسی یا چه چیزی (گیرنده یا رکورد هدف)، و چه اثری برگشتناپذیر خواهد داشت. تجربهٔ خوب معمولاً اجازهٔ ویرایش سریع در همان لحظه را هم میدهد؛ کاربر نباید برای اصلاح یک کلمه، کل درخواست را از نو بدهد.
محدودیت مقیاسپذیری
HITL یک هزینه دارد: اگر Agent قرار باشد صد پیگیری در روز بفرستد و هرکدام نیاز به تأیید تکبهتک داشته باشد، خودکاری عملاً بیمعنا میشود. راهحل رایج، تأیید دستهای (Batch Approval) است — کاربر یکبار همهٔ صد پیشنویس را با هم میبیند و یا همه را تأیید میکند یا مواردی را کنار میگذارد. رویکرد دیگر، تعریف سیاستهای ازپیشتأییدشده است: مثلاً «پیامهای پیگیری استاندارد نیاز به تأیید ندارند، اما هر پیامی که شامل عدد یا قیمت باشد، نیاز به تأیید دارد». این تعادل بین سرعت و کنترل، همان چیزی است که یک محصول Opsless را از یک اسکریپت خودکار پرریسک متمایز میکند.
جمعبندی
- HITL مانع خودکاری نیست؛ شرط بقای اعتماد در محصولی است که رابط کاربریاش را کنار گذاشته.
- اقدامات را بر اساس ریسک دستهبندی کنید: خواندن، نوشتن داخلی، ارسال بیرونی و اقدام مالی، هرکدام سیاست تأیید متفاوتی میخواهند.
- الگوی Dry-Run و Confirmation Gate را در همان Schema فراخوانی ابزار تعریف کنید، نه بهصورت جداگانه در رابط کاربری.
- نمایش پیش از ارسال باید محتوا، مقصد و اثر برگشتناپذیر را شفاف نشان دهد و امکان ویرایش سریع بدهد.
- برای مقیاسپذیری، از تأیید دستهای و سیاستهای ازپیشتعریفشده استفاده کنید، نه تأیید تکبهتک بیپایان.
این مقاله بخشی از دورهٔ Opsless است.
