تصور کنید یک سیستم خودکار برای مدیریت ۸۶ عملیات هفتگی طراحی کرده‌اید، اما هر اقدام نیاز به تایید شما دارد؛ در واقع شما دیگر مدیر یک عامل هوشمند نیستید، بلکه تنها کارمند یک صف انتظار طولانی شده‌اید. این همان نقطه‌ای است که توان عملیاتی (Throughput) — یعنی تعداد کارهایی که سیستم در واحد زمان به پایان می‌رساند — به شدت سقوط می‌کند. تایید انسانی گران‌ترین ابزار در پشته‌ی ایمنی هوش مصنوعی و سقف اصلی برای ظرفیت پردازشی عامل‌هاست.
وقتی حجم درخواست‌ها بالا می‌رود، پدیده‌ای به نام «تئاتر تایید» رخ می‌دهد. برای مثال، گردش‌کاری را در نظر بگیرید که شامل ۲۱ پست در پنج پلتفرم مختلف، ۱۵ بازه‌ی تعاملی و ۵۰ درخواست شغلی در هفته باشد. در چنین وضعیتی، کاربر از اواسط هفته دیگر متن درخواست‌ها را نمی‌خواند و صرفاً برای خالی کردن صف، دکمه تایید را می‌زند. در نتیجه، تایید انسانی که قرار بود لایه ایمنی باشد، به یک امضای صوری تبدیل می‌شود که مسئولیت را به جای امنیت واقعی، به یک امضا منتقل می‌کند. این چالش‌های عملیاتی نشان می‌دهد که ساخت زیرساخت‌های ساده برای تاییدات، لزوماً به معنای نگهداری آسان آن‌ها در مقیاس بالا نیست.
همان‌طور که در تحلیل قبلی ما درباره‌ی حفاظ‌های ایمنی در مدل‌های عامل‌محور (مانند Impri) اشاره کردیم، بحث اکنون از «چگونه» پیاده‌سازی یک گیت تایید به «کجا» باید قرار گیرد تغییر کرده است. بسیاری از توسعه‌دهندگان تایید انسانی را یک کلید روشن/خاموش می‌بینند، اما در محیط‌های عملیاتی، این باید آخرین راهکار باشد. در همین راستا، راهکار Impri برای مهار ریسک عملیاتی بر مدیریت دقیق نقاط تعلیق و بازگشت در گردش‌کارهای خودکار متمرکز است.
مایکل کامینسکی (Michael Kaminski) در مستنداتی که در وب‌سایت شخصی‌اش (michael-kaminski.io) منتشر کرده، یک سلسله‌مراتب ایمنی را پیشنهاد می‌دهد که بر اساس میزان توجه انسانی مورد نیاز برای هر واحد از حفاظت، به سه سطح تقسیم می‌شود:
- حذف قابلیت (Capability Removal): موثرترین روش ایمنی، حذف کامل «فعل» از کد عامل است. اگر یک ابزار خواندن حساب بانکی، ذاتاً دسترسی نوشتن نداشته باشد، هیچ پرامپتی نمی‌تواند پول جابه‌جا کند. کامینسکی این روش را برای ۱۹ مورد از ۴۷ مهارت عامل‌های خود به کار برده تا حتی در زمان خوابش هم سیستم امن باشد. هزینه هر بار اجرا در این روش صفر است.
- گیت‌های حذف (Kill Gates): برخلاف «گیت‌های توقف» که منتظر انسان می‌مانند، گیت‌های حذف قوانین خودکاری هستند که اگر موردی معیارها را پاس نکند، آن را برای همیشه دور می‌اندازند. این‌ها شبیه یک فیلتر هستند نه یک صف انتظار. این گیت‌ها تا زمانی که فعال نشوند هزینه‌ای ندارند و وقتی فعال می‌شوند، دیگر چیزی برای بررسی توسط انسان باقی نمی‌ماند.
- گیت‌های تایید انسانی (Human Approval Gates): این لایه فقط برای اقداماتی رزرو می‌شود که دکمه «بازگشت» (Undo) ندارند. این گران‌ترین ابزار است چون هر بار نیاز به تصمیم‌گیری دارد و به محض اینکه انسان در دسترس نباشد، کل سیستم متوقف می‌شود.
به نقل از کامینسکی، گیت‌های حذف اولویت را به پایداری سیستم می‌دهند تا خروجی بی‌نقص. یک «گیت توقف» دو بار هزینه توجه می‌طلبد: یک بار وقتی فعال می‌شود و یک بار وقتی فعال نمی‌شود، زیرا اپراتور باید بررسی کند که کدام اتفاق افتاده است. اما گیت حذف این سربار را از بین می‌برد.
در یک گردش‌کار انتشار محتوا، یک پست ممکن است بر اساس ۶ قانون خودکار حذف شود:
- عدم ابداع حقیقت: هرگز نباید حقیقتی را از خود اختراع کند.
- معیارهای داخلی: عدم انتشار آمارهای داخلی مربوط به کارفرما.
- امتیاز ارزیابی: کسب حداقل ۲۴ از ۳۰ امتیاز در روباریک ارزیابی، به طوری که هیچ بُعدی امتیاز ۲ یا کمتر نگیرد.
- تازگی موضوع: عدم تکرار موضوع در بازه ۹۰ روزه.
- امنیت: اسکن کامل برای عدم نشت کدهای محرمانه (Secret Scan) پیش از هرگونه انتشار عمومی.
- تایید نهایی: بازخوانی متن منتشر شده پیش از گزارش موفقیت.
اگرچه این روش باعث می‌شود برخی کارهای «خوب» (مثلاً متنی که امتیاز ۲۳ به جای ۲۴ گرفته) دور ریخته شوند، اما مانع تبدیل شدن انسان به گلوگاه می‌شود. از نظر او، یک جای خالی در تقویم انتشار، بسیار بهتر از یک پست اشتباه یا صفی است که تا پنجشنبه نادیده گرفته شود.
در این معماری، تصمیم برای ایجاد گیت بر اساس «شعاع تخریب» (Blast Radius) و هزینه بازگشت است، نه اهمیت وظیفه. برای مثال، لغو یک جلسه آموزشی برای فرزندش اتفاق مهمی است، اما چون بازگرداندن آن تنها ۴ کلیک در همان سیستم زمان می‌برد، دستورالعمل آن این است که اقدام را بدون توقف در مرحله تایید به پایان برساند. در مقابل، خرید آنلاین چون فرآیند بازگشت آن شامل مراحل پیچیده بانکی (Chargebacks)، بازه‌های زمانی مرجوعی و ایمیل به غریبه‌ها است، حتماً گیت تایید دارد؛ عامل محصول را می‌یابد، سبد خرید و فرم ارسال را پر می‌کند، اما یک کلیک مانده به دکمه نهایی پرداخت متوقف می‌شود.
این منطق حتی در ویرایش کدها و دستورالعمل‌ها نیز جاری است. تغییرات کم‌ریسک در لحن یا فرمت به‌طور خودکار اعمال می‌شوند، اما تغییرات پرریسک مانند قوانین رفتاری جدید یا افزودن بخش‌های جدید، پیشنهاد شده و منتظر تایید می‌مانند. این حساسیت در محیط‌های برنامه‌نویسی حیاتی است، چرا که برخی مطالعات نشان داده‌اند حتی در محیط‌های تخصصی، درصد قابل توجهی از دستورات خطرناک عامل‌های کدنویس با تایید برنامه‌نویسان اجرا می‌شوند.
برای اطمینان از مفید بودن این تغییرات، آن‌ها تحت یک گیت آماری قرار می‌گیرند: یک آزمون t-ولچ (Welch's t-test) با مقدار p < 0.10 در برابر یک خط مبنای ۱۴ روزه متحرک، تا ثابت شود که تغییر جدید حداقل ۵٪ بهبود آماری ایجاد کرده است. در این سیستم، آمار تصمیم می‌گیرد تغییر «زنده بماند» و انسان تصمیم می‌گیرد که «اعمال شود».
بر اساس بررسی‌های کامینسکی، تکیه بر لاگ‌ها (Logs) برای بررسی پس از حادثه، راهکاری ارزان اما خطرناک است. استدلال رایج این است که گیت‌ها را حذف کنیم و به لاگ‌ها اعتماد کنیم تا جریان کار متوقف نشود. اما برای اقدامات غیرقابل بازگشت، لاگ فقط ثبت می‌کند که فاجعه رخ داده است، اما آن را خنثی نمی‌کند.
او اشاره می‌کند که تایید دو مهارت حساس در ماه تنها ۴ تصمیم می‌طلبد، اما بررسی لاگ ۸۶ اقدام هفتگی برای یافتن یک خطای احتمالی، هزینه ذهنی بسیار بیشتری دارد و خطا را تنها پس از وقوع شناسایی می‌کند. لاگ ابزاری برای یادگیری این است که «چه چیزی را باید گیت کرد»، اما خودش یک گیت نیست.
با این حال، سیستم فعلی او هنوز شکاف‌هایی دارد. بسیاری از محدودیت‌ها به جای کد، در فایل‌های متنی (Markdown) نوشته شده‌اند (مثلاً جمله‌ای که می‌گوید این مهارت فقط-خواندنی است) و توسط ماشین اجرا نمی‌شوند. ۲۸ مورد از ۴۷ مهارت هیچ خط محدودیتی ندارند و هیچ چیزی این تاکسونومی را اجبار نمی‌کند.
همچنین سیستم «کلید قطع اضطراری» (Kill-switch) پراکنده است. در حالی که دستور state/STOP باید کل ناوگان را متوقف کند، تنها ۳ مهارت از ۴۷ مهارت (درخواست شغلی، اسکن هزینه‌ها و پیش‌نویس CPA) این دستور را بررسی می‌کنند. از ۶ مهارتی که اقداماتشان برای اشخاص ثالث قابل مشاهده است (پست کردن، ایمیل، درخواست شغل، رزرو و نوشتن در دیتابیس)، ۵ مورد هرگز فایل کلید قطع را چک نمی‌کنند. مهارتی که در سه حساب اجتماعی پست می‌گذارد، اصلاً کلید قطعی ندارد.
این وضعیت ریسکی ایجاد می‌کند که قابلیت‌های یک مهارت در طول زمان رشد کند در حالی که مستندات آن ایستا بماند. مهارتی که روز سه‌شنبه به عنوان «فقط-خواندنی» نوشته شده، ممکن است روز پنجشنبه قابلیت «نوشتن» پیدا کند، در حالی که جمله بالای فایل همچنان غلط و نادیده گرفته شده باقی بماند.
برای حل این مشکل، گام بعدی انتقال از «نیات خوب» به «اعلامیه‌های ماشین‌خوان» است. هدف این است که کلاس قابلیت‌ها در متادیتای فایل (Frontmatter) تعریف شود تا ماشین بتواند آن را چک کند.
با پیاده‌سازی این روش، موتور اجرا (Runner) می‌تواند هرگونه تلاش برای نوشتن (Outbound Write) را از هر مهارتی که خودش را «فقط-خواندنی» اعلام کرده، مسدود کند. این کار بررسی کلید قطع را از ۴۷ فایل مجزا خارج کرده و به هسته موتور اجرا منتقل می‌کند. بدین ترتیب، گیت از آنچه توسعه‌دهنده در یک فایل مارک‌داون نوشته است، به آنچه سیستم واقعاً اجرا می‌کند تغییر می‌یابد.
گام بعدی شما
- بررسی کنید کدام اقدامات در گردش‌کارهای شما «غیرقابل بازگشت» هستند و فقط برای آن‌ها گیت انسانی بگذارید.
- به جای تایید تک‌تک خروجی‌ها، مجموعه‌ای از «قوانین حذف» (Kill Gates) برای فیلتر کردن خودکار محتوای نامناسب تعریف کنید.
- قابلیت‌های حساس را از سطح پرامپت به سطح دسترسی‌های سیستمی (Read-only) منتقل کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو