تصور کنید یک برنامهنویس ابزاری ساخته که قرار است بهجای او وبگردی کند، اما هر دو دقیقه متوقف میشود تا بپرسد: «آیا این دکمه را میبینید؟». این دقیقاً همان نقطهای است که بسیاری از عاملهای هوش مصنوعی امروز شکست میخورند و کاربر را به یک ابزار رایگان برای نویسهخوانی نوری تبدیل میکنند.
بر اساس بررسی یک مورد در ۲۰ اوت ۲۰۲۶، یک عامل (Agent) — شبیه دستیاری که قرار است کارهای اداری شما را انجام دهد اما مدام برای جزئیات ساده زنگ میزند — در پلتفرم تیکتاک (TikTok) دچار خطای جریان کاری شد؛ او از کاربر خواست صفحهای را بررسی کند که خودش همین حالا میتوانست آن را بخواند. این مشکل از نبودِ توانایی نیست، بلکه یک خطای طراحی است. در واقع، این چالشها نشان میدهند که چرا ارزیابی عملکرد عاملها نباید صرفاً در محیطهای داخلی و ایزوله آنها صورت گیرد تا نقاط کور عملیاتی شناسایی شوند.
اکثر عاملهای مدرن به هر دو منبع دسترسی دارند: اسکرینشات رندر شده (آنچه انسان میبیند) و DOM (Document Object Model) — که در واقع کد ساختاری پشت صحنه و شبیه نقشهی مهندسی یک ساختمان است. طبق گزارش dev.to، وقتی این دو منبع با هم مطابقت دارند، پرسیدن از کاربر هیچ دادهی جدیدی اضافه نمیکند. اما وقتی این دو با هم تضاد دارند، خودِ این «عدم تطابق» همان دلیلی است که عامل باید به کاربر گزارش دهد.
همانطور که در تحلیلهای قبلی ما دربارهی امنیت و استقلال عاملهای هوش مصنوعی اشاره کردیم، هدف نهایی حذف مداخلات غیرضروری است. در این راستا، توازن میان دسترسیهای Read-Only و Read-Write نقشی کلیدی در تعیین سطح استقلال عامل از کاربر و تضمین امنیت عملیات دارد. برای رسیدن به این هدف، یک مسیر تصمیمگیری عملی برای عاملها پیشنهاد شده است:
- خواندن اسکرینشات قابل مشاهده
- بررسی بخش مربوطه در DOM
- مقایسه هویت محتوا، برچسبهای وضعیت و تعداد ردیفها
- گزارش آنچه هر دو منبع ثابت میکنند و ارجاع تنها شکافهای حلنشده به انسان
این رویکرد باعث میشود انسانها فقط برای کارهای واقعاً انسانی رزرو شوند؛ مواردی مثل حل CAPTCHA، وارد کردن رمزهای یکبار مصرف، پرداختها و قضاوتهای حساس. خواندن پیکسلهای یک مرورگر هرگز در این دسته جای نمیگیرد.
همین منطق باید بعد از هر اقدام «نوشتاری» (مثل کلیک روی یک دکمه) اجرا شود. عامل نباید فرض کند عملیات موفق بوده یا از کاربر بخواهد چک کند؛ بلکه باید رسیدِ پلتفرم یا صفحه عمومی را بخواند تا وضعیت را طبقهبندی کند. اگر URL یا شناسه جدیدی ظاهر نشد، عامل باید این عدم قطعیت را ثبت کند، نه اینکه وظیفهی کنترل کیفیت را به کاربر منتقل کند. این نوع نظارت بر خروجیها مشابه رویکردی است که در ادغام ابزارهای تحلیل کیفیت مانند Codecov در جریان کاری عاملها برای کاهش خطاها به کار گرفته میشود.
گام بعدی شما
- اگر در حال توسعه عامل هستید، لایهای برای مقایسهٔ خروجی Vision و DOM اضافه کنید تا نرخ ارجاع به کاربر کاهش یابد.
- در پرامپتهای سیستمی، به مدل دستور دهید ابتدا تضاد بین کد و تصویر را بررسی کند و سپس درخواست کمک کند.
- برای هر اکشن حساس، یک «تأییدیهٔ داخلی» بر اساس تغییرات DOM تعریف کنید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو