وقتی یک سرویس API مناسب ندارد، کار با مرورگر میتواند راه اتصال باشد. ایجنت مرورگر دقیقاً همین کار را میکند؛ مثل یک کاربر صفحه را باز میکند، دکمهها را میبیند، کلیک میکند و اطلاعات را میخواند. اما رابطهای تصویری تغییر میکنند و یک کلیک اشتباه ممکن است اقدامی واقعی انجام دهد.
در این قسمت از مجموعهی آموزش هوش مصنوعی تخته سبز یاد میگیریم کی سراغ ایجنت مرورگر برویم و کی کنترل مستقیم بهتر است. بعد معماری ترکیبی Browser-Use و Playwright را میبینیم. در پایان هفت محافظ ایمنی برای کار روی سایتهای واقعی را مرور میکنیم.
ایجنت مرورگر چیست؟
ایجنت مرورگر، یا بهطور کلیتر ایجنت استفاده از رایانه (CUA)، همانطور که یک انسان با وبسایت کار میکند، کار میکند. مرورگر را باز میکند، صفحه را بررسی میکند، دکمه میزند، فرم پر میکند و اطلاعات را میخواند.
این قابلیت وقتی ارزشمند است که کار به چیزی بستگی دارد که فقط در رابط وب دیده میشود. مثلاً سایتی که API عمومی ندارد، یا صفحهای که ساختارش آنقدر عوض میشود که اسکریپت ثابت مدام خراب میشود.
کاربردهای رایج
ایجنتهای مرورگر در کارهای متنوعی به کار میروند:
- رزرو و پایش قیمت: مقایسهی قیمت سفر یا کالا در چند سایت.
- استخراج ساختاریافته: بیرون کشیدن داده از صفحههای پویا.
- آزمون رابط کاربری: بررسی اینکه صفحه درست نمایش داده میشود.
- پایش و هشدار: خبر دادن وقتی چیزی در یک سایت تغییر کرد.
- پر کردن فرم چندمرحلهای: با تأیید انسان پیش از ارسال.
یک نمونهی واقعی
پروژهی Opal مایکروسافت نسخهی عملیاتی همین ایده است. کاربر کاری را توصیف میکند و ایجنت روی یک رایانهی ابری ایزوله انجامش میدهد؛ مثل جمعآوری شواهد حسابرسی یا بهروز کردن وضعیت تیکتها.
نکتهی آموزندهی Opal، اصولی است که رعایت میکند. برای ورود به حساب، دادهی حساس یا دستور مبهم توقف میکند و بدون تأیید صریح کاربر کاری انجام نمیدهد. ابتدا برنامه میسازد و در هر قدم استدلالش را پایش میکند. همان اصولی که در قسمتهای قبل این مجموعه دیدیم.
ایجنت یا کنترل مستقیم؟
دو راه برای خودکارسازی مرورگر هست. ایجنت، که با زبان طبیعی و بینایی تصمیم میگیرد کجا کلیک کند. و کنترل مستقیم، که کد با انتخابگرهای دقیق مثل #submit کار میکند. هر کدام جای خودش را دارد.
| موقعیت | ایجنت | کنترل مستقیم |
|---|---|---|
| چیدمان پویا | بله، با تغییر صفحه کنار میآید | خیر، انتخابگر خراب میشود |
| ساختار شناختهشده | خیر، کندتر است | بله، سریع و دقیق |
| پیدا کردن عنصر | بله، با زبان طبیعی | فقط با انتخابگر دقیق |
| کنترل زمانبندی | کمتر قابل پیشبینی | کنترل کامل بر انتظار و تکرار |
| وضعیت غیرمنتظره | بله، مثل پاپآپ | نیاز به شاخهبندی صریح |
الگوی ترکیبی
بهترین نتیجه معمولاً از ترکیب این دو میآید. با ایجنت برای کشف و ناوبری پویا شروع کنید. وقتی تعامل قابل پیشبینی شد، کنترل را به کد مستقیم بسپارید.
مثلاً ایجنت صفحهی درست را پیدا میکند و پاپآپها را میبندد. اما خواندن فیلدهای مشخص و مقایسهی قیمتها با کد قطعی انجام میشود. اینطوری هم انعطاف دارید و هم دقت.
معماری ترکیبی با Browser-Use و Playwright
Browser-Use یک کتابخانهی پایتون برای ناوبری با کمک هوش مصنوعی است و Playwright ابزار شناختهشدهی کنترل مرورگر. نکتهی کلیدی این است که هر دو از طریق پروتکل CDP به یک جلسهی مشترک Chrome وصل میشوند.
چهار قدم معماری
معماری نمونه چهار قدم دارد. اول، Chrome با CDP فعال اجرا میشود تا هر دو ابزار یک جلسه را به اشتراک بگذارند. دوم، ایجنت Browser-Use کارهای ناوبری باز را انجام میدهد؛ مثل باز کردن سایت، رد کردن پاپآپ و جستجو.
سوم، صفحهی فعال با یک طرح Pydantic بررسی میشود تا عنوان، قیمت، امتیاز و نشانی هر مورد استخراج شود. چهارم، منطق معمولی پایتون نتایج را مقایسه میکند و ارزانترین را پیدا میکند. تصمیم نهایی با کد قطعی است، نه مدل.
خروجی ساختاریافته
استخراج با طرح Pydantic باعث میشود دادهی خروجی اعتبارسنجیشده و نوعدار باشد:
from pydantic import BaseModel, HttpUrl
class CourseSession(BaseModel):
title: str
start_date: str
capacity_left: int | None
url: HttpUrl
class CoursePage(BaseModel):
sessions: list[CourseSession]اگر مدل قیمتی را بهصورت متن نامعتبر برگرداند، اعتبارسنجی خطا میدهد و ایجنت دوباره تلاش میکند. بهتر از این است که عدد اشتباه بیصدا وارد منطق کسبوکار شود.
نکتههای اجرایی
پس از اقدامی که صفحه را تغییر میدهد، کمی صبر کنید تا صفحه پایدار شود. در دورهی توسعه از هر قدم تصویر بگیرید تا اشکالزدایی آسانتر شود. و انتظار تغییر سایت را داشته باشید؛ برای پاپآپها و تغییر چیدمان راه جایگزین طراحی کنید.
هفت محافظ ایمنی برای ایجنت مرورگر
ایجنت مرورگر روی سایتهای زنده کار میکند؛ پس به محدودیتهای سختگیرانهتری از یک اسکریپت API نیاز دارد. نمودار زیر مسیر امن را نشان میدهد و در ادامه هفت محافظ را مرور میکنیم.

محدوده، جداسازی و اطلاعات حساس
یک؛ محدوده را تنگ کنید. ایجنت را در پروفایل مرورگر جدا یا محیط ایزوله اجرا کنید و به دامنههای لازم محدود کنید. دو؛ مشاهده را از اقدام جدا کنید. ایجنت اول جستجو کند و بخواند؛ پیش از ارسال فرم، خرید، ورود به حساب یا حذف داده یک مرحلهی تأیید صریح بگذارید.
سه؛ رمز عبور، اطلاعات پرداخت، کوکی جلسه و دادهی شخصی را از متن درخواست و لاگها دور نگه دارید. چهار؛ محتوای صفحه را ورودی غیرقابلاعتماد بدانید. یک وبسایت ممکن است دستوری برای ایجنت داشته باشد که بخواهد آن را از کارش منحرف کند؛ همان تزریق پرامپت غیرمستقیم.
بررسی قطعی، بودجه و شواهد
پنج؛ اطراف قدمهای پرخطر بررسی قطعی بگذارید. پیش از هر اقدام، نشانی فعلی، عنوان صفحه، مورد انتخابشده و مبلغ را با کد بررسی کنید. شش؛ بودجه و شرط توقف تعیین کنید؛ تعداد اقدامها، تلاشهای دوباره، زبانهها و دقیقههای مجاز.
هفت؛ شواهد مفید ثبت کنید، نه همهچیز را. خلاصهی اقدامها، زمانها، نشانیها و ارجاع به تصویرها کافی است. تصویر کامل صفحههایی که اطلاعات شخصی دارند را بیدلیل نگه ندارید.
سناریوی عملی؛ خواندن زمانبندی دورهها
دستیار باید زمان برگزاری چند دوره را از صفحههای عمومی یک آموزشگاه بخواند. ورودی آزمون، نشانی صفحههای مجاز و فیلدهای موردنیاز است. یک نمونهی عادی و یک نمونهی ناقص، مثلاً صفحهای که ساختارش عوض شده، آماده کنید.
معیار پذیرش و نمونهی شکست
اقدام مورد بررسی، خواندن صفحه، ثبت شواهد و استخراج داده بدون ارسال هیچ فرمی است. معیار پذیرش دو بخش دارد: اطلاعات استخراجشده با صفحه تطبیق داشته باشد و ایجنت هنگام تغییر غیرمنتظرهی ساختار توقف کند؛ نه اینکه حدس بزند.
شکستی که باید عمداً دنبالش بگردید، اشتباه گرفتن دکمهی «مشاهدهی جزئیات» با دکمهی «ثبت درخواست» است. صفحهی آزمایشی بسازید که این دو دکمه کنار هم و شبیه هم باشند. ایجنت فقطخواندنی نباید هرگز دکمهی دوم را بزند؛ بهتر است دسترسی کلیک روی فرمها را از اساس نداشته باشد.
تمرین عملی؛ ایجنت فقطخواندنی
خروجی این تمرین یک ایجنت مرورگر محدود به خواندن، با گزارش مسیر و دادهی استخراجشده است:
- فهرست دامنههای مجاز و طرح Pydantic دادهی خروجی را بنویسید.
- ایجنت را طوری پیکربندی کنید که هیچ فرمی ارسال نکند و پس از تعداد مشخصی قدم متوقف شود.
- خروجی را با صفحهی واقعی مقایسه کنید و نمونهی ساختار تغییرکرده را هم امتحان کنید.
مشخص کنید کدام بخش را واقعاً اجرا کردهاید و کدام هنوز فرض است.
سخن پایانی
ایجنت مرورگر وقتی API وجود ندارد، راه اتصال به وب است. بهترین معماری، ترکیب ایجنت برای ناوبری پویا با کنترل مستقیم Playwright برای کارهای قابل پیشبینی است و خروجی باید با طرح ساختاریافته اعتبارسنجی شود. اما چون ایجنت روی سایتهای واقعی کار میکند، محافظها اهمیت حیاتی دارند: محدودهی تنگ، جدایی مشاهده از اقدام، دور نگه داشتن اطلاعات حساس، بیاعتمادی به محتوای صفحه، بررسی قطعی، بودجه و شواهد کافی.
در قسمت بعد میبینیم ایجنت را چطور برای تعداد زیادی کاربر مستقر کنیم.
این آموزش بر پایهی درس Building Computer Use Agents از مجموعهی آزاد AI Agents for Beginners مایکروسافت (مجوز MIT) به فارسی بازنویسی و تکمیل شده است.
پرسشهای پرتکرار
ایجنت مرورگر چیست؟
ایجنتی که مثل یک کاربر با وبسایت کار میکند؛ مرورگر را باز میکند، صفحه را میبیند، کلیک میکند، فرم پر میکند و اطلاعات را میخواند. به آن ایجنت استفاده از رایانه یا CUA هم میگویند.
کی ایجنت مرورگر بهتر از فراخوانی API است؟
وقتی کار به چیزی بستگی دارد که فقط در رابط وب دیده میشود، سایت API مناسبی ندارد یا صفحه آنقدر تغییر میکند که اسکریپت ثابت مدام خراب میشود. اگر API پایدار وجود دارد، معمولاً انتخاب بهتری است.
فرق ایجنت و کنترل مستقیم با Playwright چیست؟
ایجنت با زبان طبیعی و بینایی با صفحههای پویا و پاپآپهای غیرمنتظره کنار میآید اما کندتر و کمتر قابل پیشبینی است. کنترل مستقیم با Playwright سریع و دقیق است اما به انتخابگرهای مشخص نیاز دارد. ترکیب این دو معمولاً بهترین نتیجه را میدهد.
اگر صفحهی وب به ایجنت دستور بدهد چه باید کرد؟
محتوای صفحه را ورودی غیرقابلاعتماد بدانید، نه دستور کاربر یا توسعهدهنده. ایجنت باید در دامنههای مجاز بماند، دستور صفحه را نادیده بگیرد، اطلاعات حساس را افشا نکند و در صورت لزوم توقف کند و گزارش دهد.







دیدگاهها
هنوز دیدگاهی ثبت نشده است. شروعکننده باشید — پرسش و اصلاح را با آغوش باز میپذیریم.