«تصمیم‌گیری محدود»؛ راهکار Jev برای حذف خطاهای متنی در عامل‌های هوش مصنوعی

تصور کنید عاملی در مرورگر وجود داشته باشد که بدون نوشتن حتی یک خط کد یا یک سلکتور CSS، با دقتی خیره‌کننده عمل کند. این وعده‌ی Jev است؛ محصول شرکت TypeSafe AI که به‌جای تولید متن، بر اساس احتمالات از میان مجموعه‌ای از گزینه‌های تعریف‌شده توسط برنامه‌نویس، تصمیم می‌گیرد. Jev در واقع یک مدل «سیستم یک» (System One) است که نه با تولید کلمات، بلکه با اتخاذ تصمیمات احتمالی از یک مجموعه کاندیدای محدود، عمل می‌کند.

این تحول در حالی رخ می‌دهد که صنعت با «شکاف توهم» (hallucination gap) در گردش‌کارهای عامل‌محور دست‌وپنجه نرم می‌کند. اکثر عامل‌های فعلی، ابتدا یک اسکرین‌شات یا DOM را تحلیل می‌کنند و سپس سعی می‌کنند مختصات کلیک یا یک درخت JSON تولید کنند. این فرآیند بسیار شکننده است؛ یک غلط املایی کوچک در سلکتور یا تغییر جزئی در چیدمان صفحه، کل عملیات را با شکست مواجه می‌کند. همان‌طور که در تحلیل قبلی ما درباره‌ی کاهش هزینه‌های توکن در Browser Use اشاره کردیم، معماری Jev هوشمندی را از مرحله‌ی «تولید» به مرحله‌ی «طراحی سیستم» منتقل می‌کند. در همین راستا، حذف حالت‌های پیش‌فرض در Browser Use توانست هزینه‌های توکن را تا ۶۰٪ کاهش دهد و مسیر را برای بهینه‌سازی‌های ساختاری هموار کند.

هوش مصنوعی زاینده (Generative AI) — شبیه به نویسنده‌ای است که هر بار سعی می‌کند از صفر یک داستان بنویسد و احتمال اشتباه در آن زیاد است — در Jev جای خود را به یک موتور تصمیم‌گیر داده است. طبق گزارشی که در ۲۳ سپتامبر ۲۰۲۶ منتشر شد، Jev به‌صورت یک تابع تصمیم عمل می‌کند. این سیستم وضعیت فعلی محیط و مجموعه‌ای از پرسش‌های تایپ‌شده را دریافت کرده و به‌جای تولید پاراگراف‌های استدلالی، نتایجی ساختاریافته شامل یک «انتخاب» (Choice)، یک «امتیاز» (Score) یا یک «Noul» (احتمال درست بودن یک گزاره) برمی‌گرداند. برای درک بهتر این مکانیسم، می‌توان به بررسی OpenJev اشاره کرد که نشان می‌دهد چگونه استخراج مستقیم داده‌های درونی مدل، سرعت عملیات را نسبت به تولید توکن‌های متنی افزایش می‌دهد.

شرکت TypeSafe این الگو را «ورودی وضعیت بدون ساختار، خروجی تصمیمات احتمالی تایپ‌شده» می‌نامد. در اینجا تفکیک مسئولیت‌ها مطلق است: Jev هرگز متن صفحه، سلکتورهای مرورگر، جاوااسکریپت یا JSONهای کامل را تولید نمی‌کند. کد برنامه‌نویسی همچنان مالک وضعیت، جریان کنترل، مجوزها و اجراست.

فرآیند تصمیم‌گیری در Jev به این ترتیب است:

• وضعیت فعلی: سیستم محیط را ثبت می‌کند.
• مجموعه کاندیداها: برنامه‌نویس مجموعه‌ای محدود از گزینه‌های ممکن را می‌سازد.
• ارزیابی Jev: مدل یکی از کاندیداها را انتخاب، امتیازدهی یا ارزیابی می‌کند.
• اعتبارسنجی: کد معمولی نتیجه را تایید می‌کند.
• اجرا: سیستم اقدام را انجام داده یا رابط کاربری را رندر می‌کند.

در پیاده‌سازی Browser Use، این سیستم یک حلقه چهارمرحله‌ای سخت‌گیرانه را دنبال می‌کند تا مرورگر را مدیریت کند. دمو jev-ultrafast این فرآیند را برای یک تسک خاص، یعنی جست‌وجوی پروازهای یک‌طرفه از زوریخ به لندن در گوگل‌فلایتس به نمایش گذاشته است.

در مرحله اول (استخراج DOM)، کد معمولی صفحه را خوانده و جدولی شماره‌گذاری شده از عناصر تعاملی می‌سازد. برای مثال، ممکن است موارد زیر را شناسایی کند:

• [1] دکمه Change ticket type · Round trip
• [2] کومبوباکس Where from? · San Francisco
• [3] کومبوباکس Where to? · empty
• [4] تکست‌باکس Departure · empty
• [5] دکمه Search

Jev هرگز مختصات را از روی اسکرین‌شات «حدس» نمی‌زند. اگرچه اسکرین‌شات‌ها برای نمایش به انسان و دموها استفاده می‌شوند، اما تصمیمات واقعی بر اساس وضعیت ساختاریافته استخراج‌شده از DOM گرفته می‌شوند. برچسب‌های صفحه‌ای که هنگام رندر اسکرین‌شات اضافه می‌شوند، هدایت‌کننده مرورگر نیستند. این تفکیک حیاتی است؛ زیرا اگر مدل مختصات یا سلکتورهای CSS را آزادانه تولید کند، ریسک بازگرداندن سلکتورهایی که وجود ندارند، موقعیت‌هایی که منقضی شده‌اند یا کنترل‌هایی که پوشانده شده و غیرقابل کلیک هستند، بسیار زیاد است.

در مرحله دوم (انتخاب اقدام)، Jev از میان مجموعه‌ای محدود از اقدامات مانند CLICK، TYPE_TEXT، SELECT، SCROLL_UP، SCROLL_DOWN، WAIT، DONE یا BLOCKED انتخاب می‌کند. برنامه فقط اقداماتی را پیشنهاد می‌دهد که در آن لحظه سازگار باشند. اگر هیچ منوی کشویی در صفحه نباشد، گزینه SELECT اصلاً به مدل پیشنهاد نمی‌شود. اگر ده المان قابل کلیک وجود داشته باشد، اهداف کلیک محدود به همان ده مورد خواهد بود.

در مرحله سوم (نگاشت هدف)، اگر Jev گزینه CLICK را انتخاب کند، باید یک ایندکس از جدول استخراج‌شده در مرحله اول برگزیند. او نمی‌تواند سلکتور جدیدی اختراع کند. این پرسش‌ها (اقدام، هدف کلیک، هدف متن) می‌توانند به‌صورت موازی در یک درخواست ارزیابی شوند. این فضای اقدام پویا و ایندکس‌شده، تعداد فراخوانی‌های متوالی مدل را کاهش داده و از تولید سلکتورهای CSS نامعتبر یا مختصات منقضی‌شده جلوگیری می‌کند.

تنها در مرحله چهارم و زمانی که اقدام مورد نظر TYPE_TEXT باشد، سیستم یک مدل زبانی کوچک (SLM) — شبیه به یک دستیار سریع که فقط برای کارهای کوتاه و خاص آموزش دیده — را برای تولید رشته متنی خاص (مثلاً { "text": "Zürich" }) فراخوانی می‌کند. این نتیجه پیش از تایپ شدن در مرورگر، به عنوان یک شیء JSON کوچک پارس می‌شود.

بر اساس داده‌های دمو گوگل‌فلایتس، پروژه jev-ultrafast زمان تکمیل عملیات را به ۷.۱ ثانیه رساند. این زمان شامل فراخوانی‌های مدل، اجرای مرورگر و تلاش‌های مجدد ناشی از تصمیمات منقضی‌شده است.

در مقایسه دو پیاده‌سازی در ۶ اجرای متناوب، نتایج زیر گزارش شده است:

• میانه زمان انجام تسک: از ۹.۴۵۰ ثانیه به ۷.۰۹۲ ثانیه کاهش یافت (حدود ۲۵٪ بهبود).
• فراخوانی‌های پروتکل مرورگر: از ۱۰۹۲ مورد به ۱۰۱ مورد رسید.

این بهره‌وری از گروه‌بندی پرسش‌های اقدام و هدف در یک درخواست واحد و حذف سربار تولید متن‌های طولانی حاصل شده است. با این حال، نویسنده اشاره می‌کند که این یک بنچمارک کلی برای تمام وب‌سایت‌ها نیست. MVP فعلی هنوز از Shadow DOM، iframeها، Canvas، آپلود فایل، تب‌های پاپ‌آپ و اسکرول‌های تو در تو پشتیبانی نمی‌کند. حتی زمانی که مدل گزینه DONE را انتخاب می‌کند، سیستم همچنان به یک بررسی مستقل نیاز دارد تا تایید کند تسک واقعاً تکمیل شده است.

برای تضمین پایداری، یک لایه اعتبارسنجی (Verification Layer) پیش از هر اجرا قرار دارد. سیستم یک «بررسی تازگی» (freshness check) انجام می‌دهد و موارد زیر را تایید می‌کند:

• آیا صفحه فعلی هنوز همان صفحه‌ای است که مدل مشاهده کرده است؟
• آیا گره DOM هنوز وجود دارد و توسط محتوای دیگر پوشانده نشده است؟
• آیا هندسه و مقادیر فرم هنوز با اسنپ‌شات مطابقت دارند؟
• آیا ورودی درخواست تولید متن تغییر کرده است؟

اگر صفحه پیش از بازگشت پاسخ مدل تغییر کند، سیستم آن را یک «تصمیم منقضی‌شده» تلقی کرده و از تعامل با المان قدیمی خودداری می‌کند. این یعنی خروجی مدل هرگز مستقیماً به یک دستور شل یا جاوااسکریپت اجرایی تبدیل نمی‌شود. هر هدفی که اجرا می‌شود باید دوباره به یک گره DOM واقعی که قبلاً مشاهده شده بود، تبدیل شود.

همین منطق در json-render برای ساخت رابط‌های کاربری (UI) به کار گرفته شده است. به‌جای اینکه از یک مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — بخواهیم یک کامپوننت React کامل یا یک درخت JSON پیچیده برای UI بنویسد، اپلیکیشن فهرستی از نمونه‌های معتبر کامپوننت‌ها را ارائه می‌دهد. این رویکرد مشکل شکنندگی UIهای زاینده سنتی را حل می‌کند، جایی که مدل‌ها اغلب نام کامپوننت‌ها را غلط می‌نویسند، ویژگی‌های ناموجود تولید می‌کنند یا JSONهای غیرقابل پارس می‌سازند.

در رویکرد «کاتالوگ کامپوننت»، اگر کاربر یک داشبورد فروش با جدول سفارشات، متریک‌ها و یک نمودار بخواهد، اپلیکیشن ابتدا کاندیداهایی مثل Dashboard ،OrdersTable ،MetricRow ،RevenueMetric ،OrdersMetric ،NewCustomersMetric و RevenueBarGraph را ارائه می‌دهد.

هر کاندیدا شامل موارد زیر است:

• نوع کامپوننت و ویژگی‌های ثابت.
• پیکربندی‌های لایه (Layout) موجود و پیوندهای داده/وضعیت.
• اقدامات مجاز (مثلاً یک کاندیدای Button که به savePreferences متصل است و آرگومان‌هایی برای خواندن وضعیت /name دارد).
• توصیفی که برای مدل نوشته شده است.

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

فرآیند ترکیب در دو فاز مجزا انجام می‌شود:

فاز ۱: انتخاب کامپوننت
Jev تصمیم می‌گیرد کدام کاندیداها در رابط کاربری باشند، چند نمونه از یک کامپوننت قابل استفاده مجدد نیاز است و از کدام واریانت استفاده شود. سپس کد معمولی یک Spec اولیه را جمع‌آوری کرده و یک پیش‌نمایش رندرپذیر را استریم می‌کند. Jev کد JSON سریال‌شده نمی‌نویسد؛ بلکه کد آن را از روی انتخاب‌ها می‌سازد.

فاز ۲: ترتیب‌بندی لایه (Layout)
Jev روابط والد-فرزندی، اسلات (Slot) نام‌گذاری شده‌ای که کامپوننت باید در آن قرار گیرد و ترتیب میان هم‌ردیف‌ها را تعیین می‌کند. سپس سیستم درخت را برای موارد زیر اعتبارسنجی می‌کند:

• وجود دقیقاً یک ریشه (Root) معتبر.
• نبود چرخه‌های والد-فرزندی.
• محدودیت‌های عمق (حداکثر عمق پیش‌فرض ۸).
• جایگذاری معتبر در اسلات و اعتبارسنجی شمای ویژگی‌ها.
• اطمینان از اینکه هر کاندیدا به تعداد مجاز استفاده شده است.

ویرایش رابط کاربری نیز به‌جای بازنویسی، به عنوان یک تسک «انتخاب» مدیریت می‌شود. سیستم از یک پروتکل متوالی استفاده می‌کند: ابتدا المان مورد نظر برای تغییر انتخاب می‌شود، سپس دستور (Recipe) جدید یا مقصد انتخاب شده و در نهایت تغییر در کد اعمال می‌شود. این کار باعث می‌شود شناسه‌های کامپوننت‌ها و پیوندهای داده‌ای بدون تغییر باقی بمانند و از تغییرات ناخواسته در Spec ورودی جلوگیری شود.

این معماری یک دیوار سخت بین «ترکیب» (Composing) و «اجرا» (Executing) ایجاد می‌کند. در json-render، Jev ممکن است دکمه‌ای را برای ذخیره تنظیمات انتخاب کند، اما هرگز آن را اجرا نمی‌کند. اجرا بر عهده اپلیکیشن میزبان است که مجوزها، احراز هویت سمت سرور و ثبت لاگ‌های حسابرسی (Audit Logging) را مدیریت می‌کند. مستندات صراحتاً هشدار می‌دهند که ثبت یک اقدام در کاتالوگ، به معنای ایمن بودن آن برای پذیرش آرگومان‌های دلخواه نیست، زیرا کامپوزر نمی‌تواند وضعیت زمان اجرای آینده را اعتبارسنجی کند.

با این حال، اعتبار ساختاری به معنای صحت معنایی نیست. مستندات هشدار می‌دهند که Jev همچنان ممکن است دکمه اشتباهی را انتخاب کند یا تسک را زودتر از موعد «تمام‌شده» اعلام کند. برای مثال، درخواستی برای «داشبوردی با جدول در بالا» ممکن است منجر به انتخاب تنها یک جدول شود، زیرا متریک‌ها صراحتاً درخواست نشده بودند. برای اطمینان از انتخاب تمام کاندیداها، درخواستی دقیق‌تر که ردیف متریک‌ها و نمودار را شرح دهد، لازم است.

برای حفظ پایداری، محدودیت‌های سخت‌گیرانه‌ای اعمال شده است:

• API عمومی: حداکثر ۳۲ ارزیابی، ۳۲ المان در هر دسته و عمق ۸.
• Playground: حداکثر ۱۴ ارزیابی، ۱۴ المان در هر دسته و عمق ۴.

در صورت رسیدن به این سقف، سیستم ممکن است یک Spec ناقص برگرداند، به این معنی که «تکمیل فرآیند» لزوماً به معنای صحت معنایی نتیجه نیست.

این رویکرد نشان‌دهنده فاصله گرفتن از ایده «مدل خدا» (God Model) است؛ این تصور که یک LLM باید هم‌زمان برنامه‌ریزی، استدلال و اجرا کند. با تبدیل هوش مصنوعی به یک گره تصمیم‌گیر در یک گردش‌کار کنترل‌شده توسط کد، برنامه‌نویسان دوباره کنترل ماشین وضعیت (State Machine) را به دست می‌گیرند. در اینجا هوشمندی دیگر در قالب یک رشته متنی بیان نمی‌شود، بلکه مجموعه‌ای از انتخاب‌هاست که نرم‌افزار می‌تواند مستقیماً مصرف کند. برای کسانی که به دنبال پیاده‌سازی‌های عملی این الگو هستند، ۳۳ پروژه منتخب برای تصمیمات محدود در TypeSafe Jev منبعی جامع برای مشاهده کاربردهای متنوع این معماری است.

مقایسه معماری‌ها

چه تسک‌هایی با این الگو سازگارند؟

اگر تسکی را بتوان به «انتخاب از یک مجموعه کاندیدای محدود» تجزیه کرد، برای این معماری مناسب است.

تسک‌های ایده‌آل:

• انتخاب اقدام در مرورگرها یا اپلیکیشن‌های دسکتاپ.
• مسیریابی ابزارها و مهارت‌های عامل (Agent Tool Routing).
• ترکیب رابط‌های کاربری از یک کاتالوگ کنترل‌شده.
• طبقه‌بندی ایمیل‌ها، تیکت‌های پشتیبانی یا اسناد.
• انتخاب محتوای مرتبط از میان شواهد کاندید.
• تصمیم‌گیری درباره تلاش مجدد (Retry) یا ارجاع یک نتیجه به سطح بالاتر.

تسک‌های نامناسب:

• نوشتن مقالات طولانی یا پاسخ به مشتریان.
• تولید متون جدیدی که در مجموعه کاندیداها نیستند.
• طراحی سیستم‌های بصری کاملاً جدید از صفر.
• محاسبات پیچیده ریاضی یا تاریخ‌های چندمرحله‌ای.
• برنامه‌ریزی باز (Open-ended) که هیچ اقدام کاندیدای مشخصی ندارد.

برای متخصصان، این بدان معناست که چالش اصلی مهندسی از «مهندسی پرامپت» به «مهندسی فضای کاندیدا» تغییر می‌کند. پایداری عامل اکنون به این بستگی دارد که برنامه‌نویس تا چه حد اقدامات موجود و اسنپ‌شات‌های وضعیت ارائه شده به مدل را به خوبی تعریف کند.

برای مشاهده این سیستم در عمل، منتظر انتشار نسخه‌های پایدار experimental_composeSpec و experimental_createEvaluator در API شرکت json-render باشید که احتمالاً الگوی «انتخاب به‌جای تولید» را برای رابط‌های کاربری سازمانی استاندارد می‌کند.

گام بعدی شما

• اگر در حال توسعه عامل‌های مرورگر هستید، به‌جای تکیه بر تولید JSON، فضای اقدامات (Action Space) خود را به مجموعه‌ای از ایندکس‌های عددی محدود کنید.
• برای کاهش نرخ توهم در UI، از الگوی «کاتالوگ کامپوننت» استفاده کنید تا مدل هرگز نام‌های نامعتبر تولید نکند.
• انتشار نسخه‌های پایدار experimental_composeSpec و experimental_createEvaluator در API شرکت TypeSafe را دنبال کنید تا این الگو را در پروژه‌های سازمانی پیاده کنید.

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