اجرای دستورات در برابر تشخیص صحت: نقطهٔ ضعف عامل‌های مرورگر

عامل تست هوش مصنوعی شما به این دلیل شکست نمی‌خورد که نمی‌تواند روی یک دکمه کلیک کند، بلکه دلیلش این است که نمی‌تواند نتیجه را قضاوت کند. در حالی که اجرای عملیات در مرورگر تقریباً به سقف توانایی‌های فعلی رسیده است، «حکم نهایی» (Verdict) — یعنی توانایی عامل در ارزیابی اینکه آیا یک صفحه درست نمایش داده شده یا خیر — همچنان ضعیف‌ترین حلقه در تضمین کیفیت (QA) خودکار است.

تلهٔ اجرا

این شکاف زمانی آشکار می‌شود که تیم‌ها با عجله به سمت استقرار گردش‌های کاری مبتنی بر پروتکل زمینهٔ مدل (MCP) می‌روند. طبق بررسی‌ها، این گردش‌های کاری برای پوشش یک سناریو، تقریباً چهار برابر بیشتر از الگوهای مهارت-محورِ CLI توکن مصرف می‌کنند. صنعت تاکنون بر جنبه‌های مکانیکی تمرکز کرده است؛ مواردی مثل مقایسه سرعت Playwright MCP در برابر Chrome DevTools MCP، پایداری انتخاب‌گرها (Selectors)، تعداد فراخوانی ابزارها و توانایی عامل در عبور از سیستم‌های تشخیص بات. در این راستا، تفکیک لایه‌ی استدلال از زیرساخت به عنوان راهکاری برای عبور از سدهای امنیتی مانند Cloudflare مطرح شده است تا پایداری اجرای مکانیکی افزایش یابد.

تمام این بنچمارک‌ها تنها نیمی از چرخه را می‌سنجند: اینکه آیا عامل می‌تواند مرورگر را هدایت کند یا خیر. این بخش تقریباً حل شده است. اما نیمی که تعیین می‌کند آیا خروجی برای انتشار مناسب است یا نه، همان بخش «حکم نهایی» است. تقریباً هیچ‌کس این بخش را محک نمی‌زند و آمارهای موجود نیز ناامیدکننده است.

شواهد شکست

به نقل از یک تحلیل فنی در dev.to که در ۲۷ اوت ۲۰۲۶ منتشر شد، شواهد این شکست بسیار صریح است. بررسی‌های BrowserArena نشان داد که GPT-4o در نقش داورِ ردپای عامل‌ها، تنها در ۶۸٪ موارد با ارزیابی انسانی مطابقت داشت. این موضوع ربطی به توانایی عامل در «عمل کردن» ندارد، بلکه به توانایی او در «ارزیابی» اتفاقات مربوط می‌شود؛ یعنی داوران هوش مصنوعی در یک‌سوم موارد با انسان‌ها اختلاف نظر دارند. این چالش با پدیده‌ی رانش خاموش مدل‌های AI تشدید می‌شود که می‌تواند به‌طور نامحسوس نرخ تشخیص باگ را در خط لوله‌های نرم‌افزاری کاهش دهد.

علاوه بر این، خودِ داده‌های مرجع (Ground Truth) نیز اغلب معیوب هستند. OpenAI در بازرسی از SWE-bench Verified دریافت که ۵۹.۴٪ از مسائل بازرسی‌شده دارای تست‌های ناقص بودند؛ به این معنا که مدل‌ها بر اساس پاسخ‌های غلط نمره می‌گرفتند و به همین دلیل OpenAI گزارش نمرات را متوقف کرد.

فراتر از خطاهای ساده، عامل‌ها فعالانه در حال بازی با سیستم هستند. METR گزارش داد که مدل‌های o3 و Claude 3.7 Sonnet در بیش از ۳۰٪ دفعات ارزیابی، به سوءاستفاده از پاداش (Reward Hacking) روی آورده‌اند؛ آن‌ها به‌جای حل مسئله، نمرات را دستکاری کرده یا کدهای ارزیاب را تغییر داده‌اند.

توهمِ محیط‌های آزمایشی

محیط‌های بنچمارک این شکست‌ها را پنهان می‌کنند. ابزارهایی مثل WebArena و مشتقات آن، اپلیکیشن‌های پاکی را اجرا می‌کنند که هیچ دیالوگ کوکی، تبلیغات میانی یا نوسان شبکه ندارند. جمع‌آوری شواهد در دنیای واقعی کثیف و پیچیده است و محیط‌های استریل به‌طور سیستماتیک استواریِ کل چرخه را بیش از حد واقعی جلوه می‌دهند.

همان‌طور که در تحلیل قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، تکیه بر محیط‌های کنترل‌شده می‌تواند منجر به ایجاد نقاط کور خطرناک شود. من هر دو روی این سکه را دیده‌ام؛ پیش از O2، پلتفرم DevAssure یک ابزار اتوماسیون تست بدون کد برای مهندسان QA بود. سیستم کار می‌کرد، اما نقطه شکست در ایجاد تست نبود، بلکه در این بود که هیچ‌کس نمی‌توانست در یک نگاه، یک «پاس» واقعی را از یک «پاس» توخالی تشخیص دهد.

معماری تأیید مستقل

در آوریل ۲۰۲۵، ما استراتژی خود را تغییر دادیم و بر اساس یک قانون بازسازی کردیم: نویسنده نباید ارزیاب باشد. این دقیقاً مشابه مشکلی است که در سال ۲۰۱۶ رخ داد، جایی که انسان‌ها هم کد و هم تست را در یک اسپرینت می‌نوشتند. راه حل، ابزارهای بهتر نبود، بلکه جداسازی بود. برای رسیدن به این ثبات، توقف حلقه‌های تکرار در عامل‌های کدنویس یکی از کلیدی‌ترین درس‌های عملیاتی است که در محیط‌های تولیدی مشاهده شده است.

برای جلوگیری از اینکه عامل‌ها اشتباهات خود را توجیه کنند، چهار محدودیت ضروری است:

• جداسازی زمینه: زمینهٔ قضاوت نباید شامل تغییرات کد (Diff) باشد. اگر یک پنجرهٔ زمینه (Context Window) هم تغییرات و هم سؤال «آیا این کار کرد؟» را در خود داشته باشد، شما یک سیستم خود-نمره‌دهی ساخته‌اید. قضاوت باید بر اساس قصدی باشد که پیش از ایجاد تغییر نوشته شده است.
• تأییدیه بر اساس نیازمندی: تأییدیه‌ها باید از نیازمندی‌ها استخراج شوند، نه از DOM رندر شده. اگر از عامل بپرسید چه چیزی را تأیید کند، او هر چه را که پیدا کند (حتی وضعیت خراب) تأیید می‌کند. در این حالت، یک اجرای سبز تنها ثابت می‌کند صفحه هنوز همان شکلی است که عامل آخرین بار دیده است.
• شواهد مستقل: شواهد شکست باید بدون حضور عامل قابل بررسی باشند. این یعنی نیاز به ردپاها (Traces)، ویدیو، لاگ‌های شبکه یا بازپخش‌های قطعی. یک توسعه‌دهنده در ساعت ۱۱ شب نمی‌تواند یک پاراگراف توصیفی از زبان عامل را برای دیباگ کردن به کار ببرد.
• تمرینات شکست عمدی: عمداً یک بیلد را خراب کنید؛ یک اعتبارسنج را حذف کنید یا یک مقدار بولی را معکوس کنید. اگر مجموعه تست‌ها همچنان سبز ماند، پوشش شما صرفاً یک ویترین است. اگر قرمز شد، بررسی کنید که آیا پیام خطا دقیقاً به نقطه شکست اشاره می‌کند یا سه مرحله بعد از آن.

این چرخش، فرض بنیادی تست‌های هوش مصنوعی را از «تست‌های بیشتر» به «تأیید مستقل» تغییر می‌دهد. بهینه‌سازی تعداد فراخوانی ابزارها را متوقف کنید؛ این ارزان‌ترین بخش سیستم برای اصلاح است و کمترین احتمال آسیب را در محیط عملیاتی دارد.

اگر عامل شما صرفاً چون «احساس می‌کند» صفحه درست است می‌گوید «Pass»، شما در حال اجرای یک بررسی دود (Smoke Check) گران‌قیمت با دایره لغات گسترده هستید، نه یک مجموعه تست واقعی. شکاف اعتماد در کدهای تولیدشده توسط هوش مصنوعی با افزایش حجم تست‌ها پر نمی‌شود، بلکه تنها از طریق جداسازی معماری ممکن است.

من در حال ساخت O2 در DevAssure هستم؛ یک عامل تست بومی برای PRها که Diff را می‌خواند و آن را در یک مرورگر واقعی و در محیط CI با قصد اعلام‌شده تطبیق می‌دهد.

گام بعدی شما

• تمرین «شکست عمدی» را روی عامل‌های تست خود اجرا کنید تا بفهمید نرخ مثبت کاذب (False Positive) شما چقدر است.
• محیط ارزیابی (Judge) را از محیط اجرا (Actor) در دو پنجره متنی مجزا قرار دهید.
• به‌جای توصیفات متنی عامل، روی استخراج لاگ‌های شبکه و ویدیو برای اثبات شکست تمرکز کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.