۷.۱ ثانیه؛ این تمام زمانی است که اکنون برای یک جستوجوی پرواز از زوریخ به لندن توسط Jev-Ultrafast لازم است. این عامل (Agent) — شبیه دستیاری که بهجای نگاه کردن به عکس صفحه، مستقیماً فهرست دکمهها را میخواند — با حذف اسکرینشاتهای حجیم و استفاده از یک فضای عملیاتی نمایه شده، چرخه تصمیمگیری را به تنها یک رفتوبرگشت شبکه در هر اقدام کاهش داده است. این اندازهگیری شامل تمام مراحل، از هدف اولیه به زبان طبیعی و تولید متن گرفته تا زمانهای انتظار برای بارگذاری صفحه است.
بسیاری از عاملهای فعلی با مشکل «تورم تأخیر» (Latency Bloat) دستوپنجه نرم میکنند؛ زیرا مدام از صفحه اسکرینشات میگیرند و حجم عظیمی از دادههای بصری را برای مدل میفرستند. این یک گلوگاه ایجاد میکند که در آن عامل زمان بیشتری را صرف انتظار برای رندر شدن صفحه و «دیدن» مدل میکند تا تعامل واقعی با سایت. رویکرد جدید شرکت TypeSafe، مرورگر را بهجای یک تصویر، مانند یک جدول ساختاریافته از عناصر میبیند.
طبق مستندات گیتهاب این پروژه، عامل از یک جدول عناصر پویا برای نقشهبرداری از صفحه استفاده میکند. هر مشاهده، یک جدول جدید تولید میکند؛ مثلاً [۱] دکمه تغییر نوع بلیط، [۲] کادرهای ورودی مبدأ و [۳] مقصد. مدل بهجای حدس زدن مختصات پیکسلها، از لیستی از کنترلهای مشاهدهشده و مجموعهای از عملیاتها شامل CLICK (کلیک)، TYPE_TEXT (تایپ متن)، SELECT (انتخاب)، SCROLL_UP (اسکرول به بالا)، SCROLL_DOWN (اسکرول به پایین)، WAIT (انتظار)، DONE (اتمام) و BLOCKED (مسدود شده) استفاده میکند.
زمینه و مکانیسمها
عامل از طریق یک جریان درخواست خاص عمل میکند: ابتدا صفحه به یک جدول عناصر تبدیل میشود و سپس این جدول، انتخاب عملیات و هدف را هدایت میکند. اگر عملیات انتخاب شده CLICK باشد، تنها click_target میتواند اجرا شود. همچنین، انتخابهای منوی کشویی بومی (Native dropdown) از طریق یک نمایه از عنصر مشاهدهشده و گزینه مربوطه مدیریت میشوند.
همانطور که در تحلیلهای قبلی ما دربارهی بهینهسازی استنتاج در مدلهای زبانی اشاره کردیم، کاهش حجم دادههای ورودی کلید افزایش سرعت است. در Jev-Ultrafast، برای حفظ سرعت، سیستم از اسکریپتهای خاص هر سایت یا رشتههای متنی آماده در سیاستهای خود پرهیز میکند. همچنین برای جلوگیری از کند شدن انیمیشنهای پسزمینه (Background animation throttling)، از شبیهسازی تمرکز (Focus Emulation) استفاده میکند تا نیازی به تغییر تب فعال در کروم نباشد. برای کوچک نگه داشتن ورودی مدل، بخشهای غیرضروری مانند بدنه مقالات خارج از صفحه و فوترها از بافت (Context) مدل حذف میشوند.
معماری فنی
معماری فنی این سیستم بر چند محور استوار است:
- توزیع گمانهزنانه (Speculative Fan-out): عامل در یک درخواست، همزمان دو تصمیم — «عملیات» و «هدف» — را اتخاذ میکند. هر سرِ هدف (Target head) تنها شامل عناصر سازگار با آن عملیات است، که این امر اجازه میدهد دو تصمیم در یک رفتوبرگشت شبکه گرفته شود.
- انتقال به دستیار متنی (Text-Helper Handoff): یک مدل زبانی بزرگ (LLM) — مثل کتابخانهداری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب میدهد — تنها زمانی فعال میشود که عملیات «تایپ متن» (TYPE_TEXT) باشد. خروجی این مدل باید پیش از تایپ، به صورت یک شیء JSON کوچک تجزیه (Parse) شود. در نسخه دموی این پروژه از مدل
inception/mercury-2.5با غیرفعال کردن قابلیت استدلال (Reasoning) استفاده شده، هرچند مدلهای Gemini، GLM و DeepSeek نیز از طریق نقاط انتهایی (Endpoints) سازگار با OpenAI پشتیبانی میشوند. - اسنپشاتهای اتمیک: سیستم با استفاده از
snapshot.jsکنترلها، نامها و مقادیر را بهصورت اتمیک میخواند. این سیستم بهجای استفاده از اسکرینشات در حلقه پیشفرض عامل، ارجاع مستقیم به گرههای واقعی DOM را حفظ میکند. - حفاظهای تازگی (Freshness Guards): اجراکننده پیش از هر ورودی، تازگی صفحه و عدم پوشانده شدن دکمه توسط المانهای دیگر (Click occlusion) را بررسی میکند. سیستم هندسه فعلی المان را حل کرده و کنترلهای پوشانده شده را رد میکند.
- منطق انتظار: پس از تایپ در یک کادر ورودی (Combobox)، عامل برای نمایش پیشنهادات بصری منتظر میماند (حداکثر ۲۰۰ میلیثانیه). سایر تعاملات به دو فریم انیمیشن یا ۵۰ میلیثانیه محدود شدهاند.
بر اساس گزارشهای فنی، در آزمون مقایسهای روی Google Flights، زمان میانگین تسک از ۹.۴۵۰ ثانیه به ۷.۰۹۲ ثانیه رسید که کاهش ۲۵ درصدی است. نکته تکاندهنده این است که تعداد فراخوانیهای پروتکل مرورگر از ۱۰۹۲ مورد به تنها ۱۰۱ مورد سقوط کرد. همچنین این عامل توانست یک مقاله ویکیپدیا درباره «قضیه ناتمامیت گودل» را در ۲.۷۹۸ ثانیه باز کند و یک تسک جستوجو و فیلتر هتل محلی را در ۱.۸۹۶ ثانیه به پایان برساند.
با این حال، این نسخه اولیه (MVP) محدودیتهایی دارد. خواننده DOM فعلی با کنترلهای استاندارد HTML و ARIA سازگار است اما هنوز از تمام مشخصات accessible-name پشتیبانی نمیکند. مواردی مانند Shadow roots، فریمها، Canvas، آپلود فایل، تبهای پاپآپ و اسکرولهای تودرتو (Nested scrolling) خارج از محدوده فعلی هستند. علاوه بر این، انتخاب گزینه DONE هنوز به یک تاییدیه مستقل از نتیجه نیاز دارد تا اطمینان حاصل شود که هدف نهایی واقعاً محقق شده است.
این تغییر رویکرد نشان میدهد آینده مرور وبِ عاملمحور در مدلهای بینایی بهتر نیست، بلکه در نمایش بهتر وضعیت (State Representation) است. با حذف سربار بصری و تبدیل DOM به یک نمایه قابل جستوجو، توسعهدهندگان میتوانند عاملها را روی مدلهای کوچکتر و سریعتر اجرا کنند بدون اینکه قابلیت اطمینان را از دست بدهند.
برای کاربر نهایی، این یعنی «دره وهم» تماشای کلنجار رفتن هوش مصنوعی برای پیدا کردن یک دکمه در حال ناپدید شدن است. ما به سمتی میرویم که عاملها با سرعت یک انسان سریع عمل کنند، نه با سرعت یک فراخوانی API کند.
گام بعدی شما
- اگر توسعهدهنده هستید، میتوانید با کلون کردن مخزن پروژه (
git clone https://github.com/browser-use/jev-ultrafast.git) و استفاده از مدیریت بستهuvبرای همگامسازی محیط، این پیادهسازی را تست کنید. - از ابزار Local Inspector برای مشاهده شماره عناصر، احتمالات عملیات و احتمالات اهداف در لحظه استفاده کنید.
- اتصال کروم از طریق Browser Harness برقرار میشود که میتوانید صحت آن را با دستور
uv run browser-harness --doctorبررسی کنید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو