ساخت AI Website Operator روی VPS؛ بررسی روزانه سایت، تست فرم‌ها و پیگیری خودکار خطاها با Agent

یک سایت ممکن است در ظاهر آنلاین باشد، اما هم‌زمان یکی از فرم‌های تماس کار نکند، صفحه‌ای سفید نمایش دهد، دکمه‌ای به مقصد اشتباه برود، خطای JavaScript ایجاد شود یا فرایند خرید در یک مرحله متوقف شود. مشکل اصلی اینجاست که ابزارهای ساده مانیتورینگ معمولاً فقط می‌پرسند «آیا سایت پاسخ می‌دهد؟»؛ در حالی که یک AI Website Operator می‌تواند با مرورگر واقعی وارد سایت شود، مسیرهای مشخص را طی کند، نتیجه را بررسی کند و گزارش قابل پیگیری بسازد.

در این آموزش یک معماری عملی برای ساخت چنین اپراتوری روی VPS لینوکس طراحی می‌کنیم؛ سیستمی که هر روز سایت را بررسی می‌کند، صفحات مهم را باز می‌کند، فرم‌ها و سناریوهای عملیاتی را تست می‌کند، شواهد خطا را ذخیره می‌کند و در صورت مشاهده مشکل، آن را برای بررسی انسانی آماده می‌سازد.

AI Website Operator دقیقاً چه مشکلی را حل می‌کند؟

فرض کنید یک سایت فروشگاهی، شرکتی یا خدماتی دارید. سرور روشن است و حتی صفحه اصلی با کد وضعیت HTTP 200 پاسخ می‌دهد. با این حال ممکن است فرم تماس ارسال نشود، منوی موبایل باز نشود یا صفحه پرداخت در مرحله‌ای از فرایند از کار افتاده باشد.

این تفاوت میان «سایت در دسترس است» و «سایت واقعاً قابل استفاده است» نقطه‌ای است که Website Operator ارزش پیدا می‌کند. ابزارهای مرورگرمحور جدید می‌توانند صفحات را مانند کاربر مشاهده کنند و حتی با عناصر رابط کاربری تعامل داشته باشند. برای نمونه، Playwright امروزه علاوه بر تست مرورگر، برای workflowهای مربوط به AI Agent نیز مستند شده است و امکان کنترل مرورگرهای Chromium، Firefox و WebKit را فراهم می‌کند.

مستندات رسمی Playwright نیز قابلیت‌هایی مانند assertion، انتظار خودکار برای آماده‌شدن عناصر، tracing و کنترل مرورگر برای workflowهای Agent را پوشش می‌دهد.

تفاوت Website Monitoring معمولی با AI Website Operator

معماری پیشنهادی AI Website Operator روی VPS

برای ساخت نسخه قابل اتکا، بهتر است سیستم را به چند بخش مستقل تقسیم کنیم. در این مدل، Agent مغز تصمیم‌گیرنده است، مرورگر ابزار مشاهده و تعامل با سایت است و Scheduler مسئول اجرای روزانه سناریوهاست.

این معماری یک مزیت مهم دارد: اگر مدل زبانی اشتباه کرد، داده خام مرورگر همچنان باقی می‌ماند. بنابراین گزارش Agent تنها منبع حقیقت نیست و می‌توان Screenshot، Console Log، URL و زمان اجرای تست را نیز بررسی کرد.

چه تست‌هایی را به AI Website Operator بسپاریم؟

۱. تست صفحات حیاتی

صفحات اصلی سایت، صفحات خدمات، صفحه تماس، صفحات ورود، سبد خرید و هر صفحه‌ای که مستقیماً روی درآمد اثر می‌گذارد باید در فهرست تست قرار بگیرند.

۲. تست فرم‌ها

Agent می‌تواند صفحه فرم را باز کند، فیلدهای آزمایشی را پر کند و بررسی کند که آیا پیام موفقیت ظاهر می‌شود یا نه. برای سایت‌های واقعی، اطلاعات تست باید کاملاً ساختگی و مشخص باشد تا پیام آزمایشی با اطلاعات مشتری اشتباه نشود.

۳. بررسی لینک‌ها و دکمه‌های مهم

قرار نیست Agent روی تمام عناصر صفحه کلیک کند. بهتر است سناریوهای مشخصی تعریف کنید؛ مثلاً «صفحه خدمات را باز کن، روی دکمه خرید کلیک کن و بررسی کن که صفحه مقصد قابل مشاهده است».

۴. بررسی خطاهای ظاهری

یک صفحه ممکن است HTTP 200 بدهد اما محتوای اصلی آن نمایش داده نشود. حتی سرویس‌های تخصصی جدید مانیتورینگ Agent نیز روی همین تفاوت میان پاسخ HTTP و تجربه واقعی صفحه تمرکز کرده‌اند. بنابراین Screenshot و بررسی DOM می‌توانند مکمل بررسی HTTP باشند.

۵. تست نسخه موبایل

برخی مشکلات فقط در viewport کوچک ظاهر می‌شوند. بنابراین بخشی از سناریوها را با اندازه صفحه موبایل اجرا کنید و مشکلاتی مانند بیرون‌زدگی محتوا، پنهان‌شدن دکمه یا خراب‌شدن منو را بررسی کنید.

انتخاب VPS مناسب برای اجرای Agent

اگر قرار است Browser Worker، Chromium، Scheduler و یک Agent پردازشی روی یک ماشین اجرا شوند، انتخاب VPS صرفاً بر اساس فضای دیسک اشتباه است. مرورگرهای headless می‌توانند هم‌زمان RAM و CPU مصرف کنند و اگر تعداد تست‌ها افزایش یابد، منابع بیشتری لازم خواهد بود.

این اعداد نسخه ثابت برای همه پروژه‌ها نیستند. تعداد صفحات، تعداد مرورگرهای هم‌زمان، مدل AI، حجم Screenshotها و دفعات اجرای تست باید در محاسبه منابع لحاظ شوند.

نصب محیط مرورگر روی VPS لینوکس

در این نمونه از Ubuntu استفاده می‌کنیم. ابتدا سیستم را به‌روزرسانی کنید:

sudo apt update && sudo apt upgrade -y
sudo apt install -y python3 python3-pip python3-venv

سپس یک محیط مجازی برای Worker ایجاد کنید:

mkdir -p ~/website-operator
cd ~/website-operator

python3 -m venv .venv
source .venv/bin/activate

pip install --upgrade pip
pip install playwright
playwright install chromium
playwright install-deps chromium

Playwright به‌طور رسمی برای کنترل مرورگر و اجرای تست‌های وب استفاده می‌شود و قابلیت اجرای workflowهای مبتنی بر Agent را نیز مستند کرده است. اگر هدف شما استفاده مستقیم از یک Agent مرورگرمحور باشد، پروژه‌هایی مانند Browser Use نیز امکان ساخت Agentهای مرورگرمحور را فراهم می‌کنند.

اولین تست: بررسی صفحه و عنوان سایت

برای شروع بهتر است از سناریویی ساده استفاده کنیم. این Worker صفحه را باز می‌کند، عنوان را می‌خواند و نتیجه را چاپ می‌کند.

from playwright.sync_api import sync_playwright

URL = "https://example.com"

with sync_playwright() as p:
    browser = p.chromium.launch(headless=True)
    page = browser.new_page()

    response = page.goto(URL, wait_until="domcontentloaded", timeout=30000)

    print("Status:", response.status if response else "NO_RESPONSE")
    print("Title:", page.title())

    browser.close()

در پروژه واقعی، example.com را با سایت خودتان جایگزین کنید و بهتر است URLهای حساس را از فایل تنظیمات یا متغیر محیطی بخوانید، نه اینکه اطلاعات خصوصی را داخل کد قرار دهید.

تست فرم تماس با داده آزمایشی

در تست فرم، هدف فقط پیدا کردن فیلدها نیست. باید نتیجه نهایی نیز بررسی شود. برای مثال، Agent باید بداند بعد از ارسال فرم چه چیزی نشان‌دهنده موفقیت است.

from playwright.sync_api import sync_playwright

with sync_playwright() as p:
    browser = p.chromium.launch(headless=True)
    page = browser.new_page()

    page.goto("https://example.com/contact", wait_until="networkidle")

    page.get_by_label("Name").fill("Website Operator Test")
    page.get_by_label("Email").fill("test@example.invalid")
    page.get_by_label("Message").fill("Automated website health check.")

    page.get_by_role("button", name="Submit").click()

    page.wait_for_load_state("networkidle")

    print("URL:", page.url())
    print("Title:", page.title())

    browser.close()

چطور Agent بفهمد یک سایت خراب شده است؟

این بخش مهم‌ترین قسمت پروژه است. اگر فقط از مدل زبانی بپرسیم «آیا سایت سالم است؟»، معیار مشخصی نداریم. باید برای هر سناریو شرط موفقیت تعریف کنیم.

نقش هوش مصنوعی در این معماری چیست؟

Playwright یا هر Browser Worker دیگر بهتر است داده خام را جمع‌آوری کند. سپس AI Agent می‌تواند این داده‌ها را تحلیل کند. این جداسازی باعث می‌شود مدل مجبور نباشد خودش تمام جزئیات فنی مرورگر را مدیریت کند.

برای مثال Worker می‌تواند گزارش زیر را تولید کند:

{
  "url": "/contact",
  "status": 200,
  "title": "Contact",
  "form_found": true,
  "form_submitted": false,
  "success_message": false,
  "console_errors": 2,
  "screenshot": "contact-error.png"
}

حالا مدل زبانی می‌تواند همین داده ساختاریافته را بررسی کند و بگوید مشکل احتمالاً مربوط به فرم، JavaScript یا سرویس مقصد است. بنابراین AI بیشتر نقش تحلیلگر و هماهنگ‌کننده دارد و ابزارهای deterministic مثل Playwright نقش اجرای تست را برعهده می‌گیرند.

طراحی گزارش روزانه AI Website Operator

گزارش روزانه نباید یک متن طولانی و مبهم باشد. مدیر سایت باید در چند ثانیه متوجه شود چه چیزی سالم بوده، چه چیزی خراب شده و کدام مورد نیازمند اقدام است.

اجرای خودکار هر روز با Cron

بعد از اینکه Worker آماده شد، می‌توانید اجرای آن را به Cron بسپارید. برای مثال، اجرای روزانه در ساعت ۸ صبح:

crontab -e

0 8 * * * /home/user/website-operator/.venv/bin/python /home/user/website-operator/operator.py >> /home/user/website-operator/operator.log 2>&1

برای پروژه جدی‌تر، بهتر است به‌جای تکیه کامل بر Cron، Worker را به شکل سرویس مدیریت‌شده اجرا کنید تا وضعیت پردازش، restart و لاگ‌ها کنترل بهتری داشته باشند.

AI Website Operator را به یک Agent همیشه‌فعال تبدیل کنیم

تفاوت نسخه ساده و نسخه حرفه‌ای در همین مرحله مشخص می‌شود. در نسخه ساده، یک اسکریپت ساعت مشخصی اجرا می‌شود و نتیجه را گزارش می‌کند. در نسخه پیشرفته، Agent می‌تواند نتیجه تست را وارد یک چرخه پیگیری کند.

در این مدل، Agent صرفاً «خبررسان خطا» نیست؛ بلکه می‌تواند یک Issue را دنبال کند. البته تغییر مستقیم فایل‌ها یا اجرای دستورات حساس روی سرور باید در سطح دسترسی جداگانه و با تأیید انسان انجام شود.

امنیت؛ مهم‌تر از هوشمندی Agent

هرچه اختیار Agent بیشتر شود، ریسک نیز افزایش پیدا می‌کند. یک Website Operator نباید به‌صورت پیش‌فرض دسترسی کامل root، کل فایل‌های سایت و تمام Credentialها را در اختیار داشته باشد.

این رویکرد با روند فعلی توسعه Agentهای مرورگرمحور نیز هم‌راستا است؛ برای نمونه، مدل Computer-Using Agent در توضیحات رسمی OpenAI برای تعامل با رابط‌های گرافیکی و اجرای وظایف چندمرحله‌ای معرفی شده است. برای استفاده عملی، همچنان باید مرز دسترسی و تأیید عملیات را در معماری خودتان مشخص کنید.

معرفی رسمی Computer-Using Agent

چه زمانی AI Website Operator ارزش واقعی پیدا می‌کند؟

اگر یک سایت کوچک دارید و روزی فقط یک صفحه را بررسی می‌کنید، یک Uptime Monitor ساده ممکن است کافی باشد. اما وقتی سایت دارای فرم، فرایند ثبت سفارش، پنل، صفحات خدمات متعدد یا Workflowهای مهم است، تست‌های مرورگرمحور ارزش بیشتری پیدا می‌کنند.

یک سناریوی کامل برای سایت خدماتی

برای یک سایت ارائه‌دهنده خدمات، می‌توان سناریوی روزانه را این‌گونه طراحی کرد: Agent صفحه اصلی را باز کند، چند صفحه مهم خدمات را بررسی کند، صفحه تماس را باز کند، فرم آزمایشی را با داده مخصوص تست پر کند، یک مسیر CTA را دنبال کند و در پایان نتیجه را در قالب گزارش ساختاریافته ذخیره کند.

اگر همه چیز درست باشد، گزارش کوتاه ارسال می‌شود. اگر تست شکست بخورد، Agent دوباره همان سناریو را اجرا می‌کند تا احتمال خطای موقت کاهش یابد. سپس Screenshot، URL و خطای ثبت‌شده به گزارش اضافه می‌شوند.

باکس رفع مشکل و کانفیگ سرور

ساختار پیشنهادی پروژه

website-operator/
├── operator.py
├── tests/
│   ├── homepage.py
│   ├── contact.py
│   └── services.py
├── reports/
├── screenshots/
├── logs/
├── config/
│   └── settings.env
└── .venv/

جداکردن سناریوها باعث می‌شود بعدها بتوانید تست جدید اضافه کنید بدون اینکه کل Agent را بازنویسی کنید. این موضوع برای سایتی که صفحات و فرایندهای آن به‌مرور افزایش پیدا می‌کند اهمیت زیادی دارد.

چطور این سیستم را حرفه‌ای‌تر کنیم؟

آیا باید همه چیز را به AI بسپاریم؟

خیر. طراحی حرفه‌ای دقیقاً برعکس است. بخش‌هایی که باید دقیق و قابل تکرار باشند بهتر است با ابزارهای deterministic اجرا شوند و هوش مصنوعی روی تحلیل، دسته‌بندی، خلاصه‌سازی و پیگیری تمرکز کند.

مثلاً اینکه «آیا دکمه وجود دارد؟» را می‌توان با یک assertion مشخص بررسی کرد. اما اینکه «این شکست احتمالاً از تغییر CSS یا خطای JavaScript ناشی شده است؟» جایی است که مدل زبانی می‌تواند ارزش بیشتری ایجاد کند.

منابع رسمی مرتبط: Playwright، Browser Use و Computer-Using Agent.