«نظارت انسانی پیش از ارسال»؛ استراتژی Impri برای کنترل عامل‌های AI

یک پاسخ اشتباه، توهم‌آمیز یا توهین‌آمیز در کانال‌های ارتباطی با مشتری، به‌مراتب آسیب‌زننده‌تر از یک پاسخ کند است. برای حل این چالش، پلتفرم Impri مکانیزمی را معرفی کرده است که یک مرحله تأیید انسانی (Human-in-the-loop) را دقیقاً پیش از فراخوانی هرگونه تابع chat.postMessage در Slack قرار می‌دهد.

بسیاری از تیم‌ها در حال حاضر میان مفهوم «اعلان» (Notification) و «اقدام» (Action) دچار سردرگمی هستند. در حالی که اکثر تیم‌ها از Slack برای دریافت هشدار می‌گیرند که هوش مصنوعی کاری را انجام داده است، نیاز به یک دروازه یا گیت (Gate) روی خودِ پیام خروجی، چالشی کاملاً متفاوت است. این موضوع به‌ویژه برای شرکت‌هایی که از بات‌ها در کانال‌های Slack Connect (کانال‌های مشترکی که با مشتریان خارجی به اشتراک گذاشته شده‌اند) استفاده می‌کنند، حیاتی و حساس است.

درک دو مسئله‌ی متفاوت در Slack

بسیار مهم است که به طور صریح مشخص کنیم کدام گردش کار در حال استفاده است. یک الگو شامل استفاده از Slack به عنوان یک کانال اعلان است؛ جایی که کارت‌های تأیید برای هرگونه اقدام — مانند مسائل GitHub، ایمیل‌ها یا بازپرداخت‌های مالی — به صورت دکمه‌دار در پیام‌های مستقیم (DM) اسلاک ظاهر می‌شوند.

این راهنما برعکس این الگو تمرکز دارد: در اینجا وظیفه خاصِ عامل (Agent) این است که پیام‌هایی را در Slack پست کند و یک انسان باید متن دقیق را پیش از ارسال نهایی بخواند. در این مورد، اقدامی که مورد نظارت قرار گرفته است از نوع slack.message.send است، نه صرفاً یک سیستم انتقال اعلان.

سناریوی بات پشتیبانی

یک سناریوی رایج مربوط به شرکتی است که یک بات پشتیبانی را در کانال Slack Connect مشترک با یک مشتری اجرا می‌کند. پیش از این، بات پیام‌های دریافتی را می‌خواند، پیش‌نویس پاسخ را می‌ساخت و آن را فوراً پست می‌کرد. اما از آنجایی که یک پاسخ بد در کانالی که برای مشتری قابل مشاهده است، ریسک بالایی دارد، اکنون هر پیش‌نویس منتظر می‌ماند تا یکی از هم‌تیمی‌ها آن را از طریق تلفن همراه خود تأیید کند.

طبق راهنمای منتشر شده در ۲۴ ژوئیه ۲۰۲۶ در وب‌سایت dev.to، گردش کار فنی از الگوی «ارسال $\rightarrow$ نظارت $\rightarrow$ اجرا» (Push $\rightarrow$ Poll $\rightarrow$ Execute) پیروی می‌کند. عامل هوش مصنوعی مستقیماً به مشتری پیام نمی‌دهد؛ در عوض، پیش‌نویس را با استفاده از نوع اقدام slack.message.send به Impri می‌فرستد. این کار باعث ایجاد یک کارت تأیید می‌شود که یک هم‌تیمی انسانی می‌تواند به آن دسترسی داشته باشد.

سازوکار فنی

• پیش‌نویس (Drafting): بات یک Payload از نوع JSON را به API شرکت Impri به آدرس https://api.impri.dev/v1/actions ارسال می‌کند. متن پیش‌نویس در بخش preview.body قرار می‌گیرد و عنوان اقدام برای آن کانال خاص مشخص می‌شود.
• ویرایش (Editing): با تنظیم editable: ["preview.body"]، بازبین می‌تواند پاسخ هوش مصنوعی را در لحظه بازنویسی کند تا مشکلات لحن یا لغزش‌های واقع‌گرایانه و خطاهای的事ی اصلاح شوند. فیلد final_preview.body همواره نسخه ویرایش شده را در صورت اعمال تغییرات حمل می‌کند.
• زمان‌بندی (Timing): یک پنجره زمانی سخت‌گیرانه ۱۵ دقیقه‌ای (expires_in: 900) تعریف شده است. این اطمینان می‌دهد که یک پاسخ پشتیبانی قدیمی که دیگر مرتبط نیست، ارسال نشود.
• اجرا (Execution): سیستم هر ۵ ثانیه وضعیت اقدام را نظارت (Poll) می‌کند. تنها در صورتی که وضعیت بازگشتی approved باشد، بات در نهایت slack_sdk WebClient را برای پست کردن متن فراخوانی می‌کند.

جزئیات پیاده‌سازی

• منطق نظارت (Polling Logic): تابع propose_and_wait تا زمانی که وضعیت دیگر pending نباشد، API مربوط به Impri را نظارت می‌کند. اگر وضعیت rejected شود یا زمان آن منقضی گردد، مقدار None برمی‌گرداند و بات ساکت می‌ماند.
• گزارش نتیجه: پس از اینکه chat_postMessage اجرا شد، بات یک درخواست POST نهایی به نقطه پایان /result با محتوای {"status": "executed"} ارسال می‌کند تا حلقه عملیاتی بسته شود.

این معماری تضمین می‌کند که توکنِ بات تنها در مسیراتی فعال شود که ابتدا از گیت تأیید عبور کرده‌اند. اگر یک بات دارای کارهای زمان‌بندی‌شده (Cron Jobs)، هندلرهای وب‌هوک یا سایر مسیرهای کدنویسی باشد که از همان SLACK_BOT_TOKEN استفاده می‌کنند، آن‌ها می‌توانند کاملاً این گیت را دور بزنند. Impri نمی‌تواند فراخوانی API اسلاکی را که هرگز نمی‌بیند، رهگیری کند.

برای تیم‌هایی که می‌خواهند از تنظیمات پیچیده OAuth در Slack صرفاً برای بازبینی پیام‌ها اجتناب کنند، اعلان‌های مربوط به این بازبینی‌ها را می‌توان از طریق ntfy یا وب‌پوش (Web Push) هدایت کرد. این امر به بازبین اجازه می‌دهد تا یک پیام را با یک ضربه (Tap) تأیید یا رد کند، بدون اینکه نیاز باشد اپلیکیشن Slack را باز کند.

این تغییر، عامل‌های هوش مصنوعی را از حالت «خودمختار» به حالت «تحت نظارت» می‌برد که تنها مسیر ممکن برای پشتیبانی مشتری در محیط‌های با ریسک بالا و حساس است. با جداسازی لایه‌ی انتقال اعلان (جایی که انسان درخواست را می‌بیند) از لایه‌ی انتقال اقدام (جایی که مشتری نتیجه را می‌بیند)، شرکت‌ها می‌توانند حضور حرفه‌ای خود را حفظ کنند. برای پیاده‌سازی این مورد، توسعه‌دهندگان باید کارت‌های تأیید را به کانال‌های داخلی هدایت کنند تا از نشت نویزهای «تأیید/رد» در دید مشتری جلوگیری شود.

گام بعدی شما

• اگر از بات‌های پشتیبانی استفاده می‌کنید، مسیرهای ارسال پیام را به جای اتصال مستقیم، از طریق یک API واسط نظارتی هدایت کنید.
• برای کاهش تأخیر در تایید، اعلان‌های بازبینی را به جای Slack، روی سرویس‌های Push-Notification سریع مثل ntfy تنظیم کنید.
• بررسی کنید آیا بات‌های شما مسیرهای مخفی (مانند Cron Jobs یا Webhooks) دارند که گیت‌های تأیید را دور می‌زنند یا خیر.

اما چالش واقعی زمانی آغاز می‌شود که حجم پیام‌ها از توان بررسی انسانی خارج شود؛ در تحلیل بعدی به بررسی روش‌های «نمونه‌برداری هوشمند برای بازبینی» خواهیم پرداخت.