تصور کنید فرمی دولتی پیش روی شماست که دستورالعملهای متناقض دارد و در نهایت شما را به یک صفحه خطا میرساند؛ حالا تصور کنید ابزاری وجود داشته باشد که دقیقاً همین حس کلافگی را تجربه کند تا نقصها را پیش از کاربر واقعی پیدا کند. Onmitsu، عامل هوش مصنوعی جدیدی که در ۱۲ ژوئیه ۲۰۲۶ در گیتهاب منتشر شد، دقیقاً همین هدف را دنبال میکند. این ابزار توسط توسعهدهندهای ساخته شده تا نقش یک «شهروند ناکام و کلافه» را ایفا کند. Onmitsu صرفاً به دنبال خطاهای کدنویسی نیست، بلکه تلاش میکند فرمهای دولتی را تکمیل کند و دقیقاً گزارش دهد که در کدام نقطه متوقف شده یا دچار سردرگمی شده است.
این رویکرد هدفش پر کردن یک شکاف خاص در حاکمیت دیجیتال است. در ژاپن، آژانس دیجیتال (Digital Agency) پلتفرم داخلی مبتنی بر هوش مصنوعی مولد به نام Genai (源内) را اداره میکند. این پلتفرم به سازمانها اجازه میدهد تا REST APIهای خارجی را به عنوان اپلیکیشنهای اداری ثبت کنند. در حالی که Genai بخش رابط کاربری (Frontend) را مدیریت میکند، منطق بکاند این اپلیکیشنها اغلب دارای نقاط اصطکاک نامرئی است. این نقاط توسط تحلیلگرهای کد (Linters) استاندارد یا اسکنهای axe-core نادیده گرفته میشوند، زیرا این ابزارها برخلاف یک انسان، فرم را «تجربه» نمیکنند. این چالش با مشکلاتی مشابه در شناسایی نقصهای منطقی در کدهایی که توسط AI تولید شدهاند همخوانی دارد، مشابه آنچه در پروژه Loupe برای شناسایی باگهای خاموش بررسی شده بود.
برای آزمایش این ادعا، سازنده یک هدف مجازی ساخت: یک اپلیکیشن Next.js که شبیهساز فرم کمکهزینه فرزندپروری در یک شهرداری ژاپنی بود. این نمونه اولیه عمداً با «ضدالگوهای تجربه کاربری» (UX anti-patterns) طراحی شده بود؛ مواردی مانند دستورالعملهای متناقض برای چکباکسهای اجباری و محدودیتهای پنهان در آپلود فایل که کاربر را به اشتباه میانداخت.
معماری یک «مشتری ناشناس»
از آنجا که عاملهای هوش مصنوعی برای به اتمام رساندن یک کار در مرورگر ممکن است چندین دقیقه زمان نیاز داشته باشند، نمیتوانند در قالب درخواستهای HTTP همگام (Synchronous) استاندارد جای گیرند. توسعهدهنده برای حل این مشکل از یک قرارداد ناهمگام (Async) خاص استفاده کرد: یک نقطه انتهایی POST /requests که وضعیت ۲۰۲ Accepted را برمیگرداند و پس از آن، سیستم باید از طریق نقطه انتهایی /status وضعیت پیشرفت کار را پیگیری (Polling) کند.
این معماری به عامل اجازه میدهد بدون برخورد با محدودیت زمانی ۲۹ ثانیهای AWS API Gateway، در صفحات وب ناوبری کند. این عامل توسط Strands Agents و Amazon Bedrock AgentCore نیرو میگیرد و از مجموعهای شامل هشت ابزار تخصصی برای تعامل با وب استفاده میکند:
open_urlوobserve_pageبرای باز کردن صفحات و تحلیل ساختار DOM.click_elementوfill_fieldبرای کلیک روی عناصر و پر کردن فیلدها.take_screenshotوrecord_findingبرای ثبت شواهد بصری و گزارش یافتهها.read_page_textوwait_secondsبرای خواندن متون صفحه و مدیریت زمانبندی جهت اعتبارسنجی.
در این میان، ابزار observe_page حیاتیترین نقش را دارد. این ابزار یک قطعه کد جاوااسکریپت را اجرا میکند که عناصر تعاملی صفحه را با یک شناسه منحصربهفرد data-onmitsu-id علامتگذاری میکند. این مکانیسم به مدل زبانی بزرگ (LLM) اجازه میدهد تا به جای تحلیل کدهای خام و شلوغ HTML، روی لیستی فشرده از برچسبها و نقشها استدلال کند. در واقع، این ابزار باعث میشود عامل صفحه را دقیقاً مشابه یک «صفحهخوان» (Screen Reader) ببیند و تحلیل کند.
یافتن باگهای «ناخواسته»
گزارشها نشان میدهد که Onmitsu نه تنها تلههای برنامهریزیشده را شناسایی کرد، بلکه باگهای شدیدی را یافت که توسعهدهنده عمداً آنها را ایجاد نکرده بود. یکی از یافتههای اصلی، وجود تناقض در چکباکسهایی بود که برچسب «اجباری» داشتند اما در واقعیت، ویژگی HTML required در DOM آنها تعریف نشده بود.
کشف بحرانی دیگر مربوط به بینالمللیسازی (i18n) بود. عامل متوجه شد که اگر کاربر مستقیماً به مرحله خاصی از درخواست در اپلیکیشن برود، علیرغم اینکه بقیه سایت به زبان ژاپنی است، صفحه ۴۰۴ به زبان انگلیسی نمایش داده میشود. این خطا در واقع اثر جانبی تلاش عامل برای «دور زدن» یک مرحله مسدود شده بود که دقیقاً شبیهساز تلاش یک کاربر واقعی برای عبور از موانع است.
علاوه بر این، عامل فقدان کامل ویژگیهای aria-label در فیلدهای ورودی را گزارش کرد. از آنجا که Onmitsu برای ناوبری به «درخت دسترسیپذیری» (Accessibility Tree) تکیه میکرد، بهطور طبیعی تشخیص داد که یک صفحهخوان هیچ محتوایی برای اعلام کردن نخواهد داشت. این یعنی ابزار در حین انجام مأموریت اصلی خود، عملاً یک ممیزی کامل دسترسیپذیری را نیز انجام داد.
چالشهای مهندسی و استقرار
انتقال این عامل به فضای ابری با دشواریهای فنی متعددی همراه بود. اولین چالش، تضاد در مدیریت رشتهها (Threading) بود؛ API همگام Playwright ایجاب میکند که تمام فراخوانیها از یک رشته واحد در سیستمعامل ارسال شوند. اما چون Strands Agents ابزارها را از طریق یک استخر رشتههای همرده (Concurrent Thread Pool) اجرا میکند، عامل مکرراً با خطای greenlet.error کراش میکرد. توسعهدهنده برای رفع این مشکل، یک پروکسی به نام BrowserWorker ساخت تا تمام فراخوانیهای Playwright را بر روی یک رشته اختصاصی سریالسازی کند.
استقرار در AWS نیز تداخلات منطقهای ایجاد کرد. Runtime مربوط به AgentCore روی منطقه us-east-1 تنظیم شده بود، در حالی که زیرساخت توسعهدهنده به صورت پیشفرض روی ap-northeast-1 (توکیو) بود. یک نقص در منطق Fallback مربوط به CDK باعث شد استک (Stack) در منطقه اشتباه مستقر شود و منجر به شکستهای اولیه در اجرا گردد.
مدیریت دسترسیهای IAM نیز گمراهکننده بود. توسعهدهنده ابتدا دسترسیها را برای یک «پروفایل استنتاج متقاطع-منطقهای» صادر کرد، اما Amazon Bedrock دسترسیها را بر اساس منبع مدل بنیادی (Foundation Model) ارزیابی میکرد. این موضوع مستلزم تعریف دو عبارت سیاست (Policy Statement) مجزا بود: یکی برای پروفایل استنتاج و دیگری با استفاده از Wildcard منطقهای برای مدل بنیادی.
در نهایت، توسعهدهنده با محدودیت سختافزاری سهمیه توکنهای روزانه مدل مواجه شد. این اتفاق باعث شد یک باگ پنهان آشکار شود: تایماوت ۶۰ ثانیهای کلاینت در هندلر Lambda، خطای محدودیت (Throttling) سمت سرور را بهاشتباه به عنوان «تایماوت خواندن» گزارش میکرد و علت واقعی شکست عملیات را میپوشاند.
چرا این موضوع برای تجربه کاربری (UX) اهمیت دارد؟
این آزمایش پارادایم تستهای پایان-به-پایان (E2E) را تغییر میدهد. تستهای سنتی مبتنی بر اسکریپت، تنها سناریوهایی را بررسی میکنند که برنامهنویس پیشبینی کرده است. در مقابل، یک عامل مبتنی بر LLM کشف میکند که یک انسان سردرگم در واقعیت با چه مشکلاتی روبرو میشود. با قرار دادن «درخت دسترسیپذیری» به عنوان سیگنال اصلی، این عامل همزمان باگهای عملکردی و شکستهای مربوط به شمولیت (Inclusivity) را شناسایی میکند.
برای توسعهدهندگان و سازمانهای دولتی، این بدان معناست که هدف تست از «آیا کد کار میکند؟» به «آیا یک انسان واقعاً میتواند این فرم را تکمیل کند؟» تغییر میکند. Onmitsu هوش مصنوعی را از یک چتبات ساده به یک شبیهساز دقیق از «کلافگی انسانی» تبدیل میکند تا کیفیت خدمات دیجیتال ارتقا یابد.
گام بعدی شما
- بررسی کد منبع Onmitsu در گیتهاب برای تحلیل نحوه پیادهسازی
BrowserWorkerدر محیطهای توزیعشده. - تست کردن فرمهای پیچیده سازمان خود با متد «نقشآفرینی کاربر ناکام» به جای تستهای سناریو-محور.
- مطالعه مستندات Amazon Bedrock AgentCore برای پیادهسازی ابزارهای مشابه ناوبری وب.
اما چالش واقعی، مدیریت هزینههای استنتاج در مقیاس وسیع است — در تحلیل ما دربارهی بهینهسازی هزینه GPU و رقابت مدلهای جدید برای کاهش هزینههای API بخوانید.
گفتگو