تصور کنید یک عامل هوش مصنوعی در ساعت ۲ صبح، بدون اینکه حتی یک انسان لاگها را بررسی کند، یک Pull Request (درخواست ادغام کد) معیوب را ادغام کند. این کابوس برای توسعهدهندگانی که از عاملهای مبتنی بر وبهوک استفاده میکنند، یک واقعیت است. چون این عاملها بلافاصله پس از وقوع یک رویداد — مانند رویداد charge.dispute.created در Stripe یا رویداد pull_request در GitHub — فعال میشوند، فاقد آن پنجره چت داخلی هستند که معمولاً به انسان اجازه میدهد مداخله کرده و بگوید «نه، این کار را نکن».
با تکیه بر پوشش قبلی ما درباره نحوه پیادهسازی دروازههای تأیید (Approval Gates) برای عاملهای Local-first توسط شرکت Stram، چالش اصلی در سیستمهای مبتنی بر وبهوک، نبود یک نشست فعال (Active Session) است. در یک محیط چت، انسان از قبل حضور دارد؛ اما در یک وبهوک، عامل تنهاست. این موضوع شکافی خطرناک ایجاد میکند که در آن یک تصمیم خودکار اشتباه میتواند محیطهای عملیاتی (Production) را پیش از آنکه کسی متوجه شود، تخریب کند.
زمینه و بستر عاملهای بدون نظارت
بسیاری از توصیههای مربوط به «انسان در حلقه» (Human-in-the-loop)، فرض را بر این میگذارند که عامل در داخل یک نشست چت در حال اجرا است. در آن موارد، یک شخص از قبل در حال نظارت است و میتواند به سادگی پاسخ دهد: «بله، آن را ارسال کن». اما محرکهای وبهوک مسئله متفاوتی هستند زیرا اغلب بدون نظارت (Unattended) اجرا میشوند. این چالش با شکست سیستمهای نظارت انسانی در مقیاس بالا مرتبط است، جایی که حجم بالای درخواستها باعث کاهش دقت نظارت میشود.
چه صحبت از اتمام یک خط لوله CI (یکپارچهسازی مداوم) باشد و چه یک بهروزرسانی نسخه توسط بات، این هندلرها در پسزمینه اجرا میشوند. اگر مرحله نهایی «صدور بازپرداخت وجه» یا «ادغام PR» باشد، دروازه تأیید باید در خودِ هندلر تعبیه شده باشد. مرحله تأیید نمیتواند صرفاً یک پیام در Slack باشد که عامل «امیدوار» است کسی آن را بخواند؛ بلکه باید یک مکانیسم واقعی «تعلیق و بازگشت» (Suspend-and-Resume) در سطح کد باشد.
برای حل این مشکل، شرکت Impri یک معماری خاص «تعلیق و بازگشت» را پیادهسازی کرده است. در این مدل، بهجای اینکه عامل مستقیماً یک دستور را اجرا کند، یک درخواست را به API شرکت Impri ارسال کرده و سپس فرآیند فعلی خود را کاملاً متوقف میکند. این رویکرد تکاملیافتهی استراتژی نظارت پیش از ارسال Impri است که پیشتر برای عاملهای Slack طراحی شده بود. طبق یک راهنمای فنی که در ۹ اوت ۲۰۲۶ منتشر شد، این گردش کار از یک الگوی سختگیرانه سه مرحلهای پیروی میکند:
جزئیات پیادهسازی
- مرحله تحریک (The Trigger): یک گیرنده Flask وبهوک را دریافت میکند. اگر یک PR بر اساس یک تحلیل اکتشافی (Heuristic) ایمن به نظر برسد، تابع
POST /v1/actionsرا برای قرار دادن تصمیم در صف فراخوانی میکند. این سیستم یکpreviewدر قالب Markdown حاوی شماره PR و نام کاربری کاربر، و یکtarget_urlبرای آن PR ارسال میکند. - دروازه تأیید (The Gate): عملیات در Impri در وضعیت «در انتظار» (Pending) باقی میماند. هندلر وبهوک بلافاصله وضعیت
202 Acceptedرا برمیگرداند و کار خود را به پایان میرساند. این هندلر خودش هیچ چیزی را ادغام نمیکند. - اجرای نهایی (The Execution): یک Worker مجزا — مانند یک Poller کوچک یا مصرفکننده صف (Queue Consumer) — تنها جایی است که تابع
merge_pull_request()در آن فراخوانی میشود. این Worker بهطور مداوم API را بررسی میکند و تنها زمانی ادغام را اجرا میکند که وضعیت را به صورتstatus: "approved"ببیند.
این جداسازی حیاتی است زیرا هندلرهای وبهوک باید در عرض چند ثانیه پاسخ دهند. مسدود کردن (Blocking) یک هندلر برای چندین ساعت در انتظار تأیید انسان، باعث کرش کردن یکپارچگی سیستم (Integration) میشود. با بازگرداندن وضعیت 202، سیستم پایدار میماند در حالی که تصمیمگیری به یک رابط کاربری «انسان در حلقه» منتقل شده است.
مدیریت رویدادهای منقضی شده
یک نکته ظریف در این معماری، استفاده از پارامتر expires_in است. در حالی که تأییدیههای مبتنی بر چت میتوانند روزها طول بکشانند، رویدادهای وبهوک حساس به زمان هستند. ممکن است یک PR کامیتهای جدیدی دریافت کند یا یک حادثه (Incident) بهطور خودکار برطرف شود.
- ادغامهای PR: روی ۶ ساعت (۲۱,۶۰۰ ثانیه) تنظیم شدهاند، زیرا تأییدیههای قدیمی ارزش اجرا ندارند.
- رفع حوادث (Incident Remediation): ممکن است در بازههای کوتاهتری، حتی ۳۰ دقیقه، تنظیم شوند.
این تغییر در رویکرد، ایمنی عاملهای هوش مصنوعی را از ایمنی «امیدوارانه» — جایی که توسعهدهندگان امیدوارند کسی اعلان Slack را ببیند — به ایمنی «دروازهای سخت» (Hard-gated) منتقل میکند. این ضرورت زمانی بیشتر میشود که بدانیم بسیاری از دستورات خطرناک عاملهای کدنویس حتی با وجود تایید برنامهنویسان اجرا میشوند. امنیت این سیستم کاملاً به مسیریابی اعتبارنامهها (Credential Routing) وابسته است. اگر فرآیند عامل همچنان توکن API را برای ادغام مستقل کد در اختیار داشته باشد، این دروازه صرفاً جنبه تزئینی دارد.
برای اینکه دروازه مؤثر باشد، اعتبارنامههای ابزار هدف باید منحصراً از طریق کدی عبور کنند که وضعیت «تأیید شده» را از Impri تأیید میکند. این امر تضمین میکند که هیچ مسیری به محیط عملیاتی بدون امضای انسان وجود نداشته باشد. توسعهدهندگان اکنون میتوانند این الگوی مبتنی بر Flask را برای هر منبع رویداد-محور، از خط لولههای CI گرفته تا درگاههای پرداخت، به کار بگیرند تا از اشتباهات برگشتناپذیر عاملهای خودمختار جلوگیری کنند.
گام بعدی شما
- اگر از Flask برای مدیریت وبهوکها استفاده میکنید، الگوی بازگشت وضعیت
202را برای عملیات حساس پیاده کنید. - برای هر عملیات خودکار، یک زمان انقضا (TTL) تعریف کنید تا از اجرای دستورات قدیمی و نامربوط جلوگیری شود.
- دسترسی مستقیم عاملها به APIهای حساس را حذف کرده و آنها را به یک لایه تأیید واسط منتقل کنید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو