ساخت AI Agent با قابلیت Computer Use؛ آموزش کنترل مرورگر روی VPS

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

با این حال، ساخت Agent مرورگر فقط به اتصال هوش مصنوعی به Playwright یا Selenium محدود نمی‌شود. اگر Agent به یک حساب واقعی وارد شود، ممکن است به داده‌های خصوصی، تنظیمات مدیریتی یا امکاناتی مانند حذف اطلاعات و ثبت سفارش دسترسی داشته باشد. بنابراین ایزوله کردن مرورگر، مدیریت امن ورود، محدود کردن دسترسی و تأیید واقعی اقدامات حساس بخش ضروری معماری Computer Use هستند.

در این آموزش ابتدا توضیح می‌دهیم Computer Use چگونه کار می‌کند و چه تفاوتی با Web Scraping و ابزارهای معمول Agent دارد. سپس با OpenAI Responses API، Python و Playwright یک نمونه عملی روی Ubuntu VPS می‌سازیم که صفحه را از طریق Screenshot مشاهده می‌کند، یک عملیات مشخص را انجام می‌دهد و نتیجه را از داخل مرورگر تأیید می‌کند.

در ادامه نیز روش تبدیل نمونه آزمایشی به یک سرویس API، مدیریت Login و Session، کنترل Retry، جلوگیری از Prompt Injection، حفاظت از اطلاعات حساس و آماده‌سازی زیرساخت Production را بررسی خواهیم کرد.

AI Computer Use چیست و چگونه کار می‌کند؟

Computer Use قابلیتی است که به مدل هوش مصنوعی اجازه می‌دهد از طریق یک محیط کنترل‌شده با رابط کاربری نرم‌افزار یا مرورگر تعامل داشته باشد.

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

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

یک مثال ساده

کاربر می‌گوید: «صفحه وضعیت سفارش آزمایشی را باز کن و شماره محل تحویل را پیدا کن.»

Agent می‌تواند این مسیر را طی کند:

1. از صفحه مرورگر Screenshot دریافت کند.
2. دکمه نمایش جزئیات سفارش را شناسایی کند.
3. درخواست کلیک روی آن دکمه را ارسال کند.
4. برنامه، مجاز بودن کلیک را بررسی و اجرا کند.
5. Agent تصویر جدید را مشاهده کند.
6. شماره محل تحویل را گزارش دهد.
7. برنامه، درستی نتیجه را از خود صفحه بررسی کند.

در این معماری، مدل مستقیماً کنترل نامحدود سیستم‌عامل را دریافت نمی‌کند. این برنامه اجرایی شما است که تعیین می‌کند چه ابزارهایی در دسترس باشند و هر عملیات چه محدودیتی داشته باشد.

آیا Computer Use به معنی اجرای مرورگر داخل ChatGPT است؟

خیر. در این مقاله یک برنامه مستقل با OpenAI API می‌سازیم. برنامه روی VPS شما اجرا می‌شود و مرورگر را نیز خودتان میزبانی می‌کنید.

البته در محصولات و APIهای مختلف ممکن است مرورگر توسط ارائه‌دهنده دیگری میزبانی شود. این موضوع را باید از معماری Self-hosted که در این آموزش پیاده‌سازی می‌کنیم جدا دانست.

تفاوت AI Computer Use با Playwright، Selenium و Web Scraping چیست؟

این فناوری‌ها به یکدیگر مرتبط‌اند، اما نقش یکسانی ندارند.

چه زمانی Computer Use بهتر از API است؟

اگر سرویس شما API رسمی و مناسبی دارد، معمولاً استفاده مستقیم از API ساده‌تر، سریع‌تر و قابل پیش‌بینی‌تر است.

Computer Use زمانی ارزش بیشتری دارد که انجام کار به رابط گرافیکی وابسته باشد؛ برای مثال، لازم باشد چند صفحه را بررسی کنید، با فرم‌های متغیر تعامل داشته باشید یا عملکرد یک سایت را مانند کاربر واقعی آزمایش کنید.

آیا Computer Use جایگزین کامل Playwright می‌شود؟

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

در بسیاری از پروژه‌ها، ترکیب Playwright و Computer Use مناسب‌تر از استفاده جداگانه از هرکدام است.

روش‌های فعلی ساخت Computer Use با OpenAI

در مستندات فعلی OpenAI، چند الگوی اصلی برای اتصال مدل به محیط مرورگر ارائه شده است.

۱. ComputerToolset و ابزار computer

این روش برای وظایفی مناسب است که مدل باید با Screenshot، مختصات و عملیات ماوس و صفحه‌کلید کار کند.

در این حالت برنامه شما یک Driver دارد که دستورهای مجاز را به Playwright یا محیط دسکتاپ منتقل می‌کند.

۲. BrowserToolset

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

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

۳. Code Execution با Playwright

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

اما اجرای کد تولیدشده توسط مدل بدون Sandbox و محدودیت‌های اجرایی، ریسک بالایی دارد. کد نباید مستقیماً روی میزبان دارای فایل‌ها و Credentialهای حساس اجرا شود.

۴. مرورگر میزبانی‌شده توسط سرویس خارجی

در معماری‌های Hosted Browser، محیط مرورگر توسط یک سرویس مجزا فراهم می‌شود. برای نمونه، OpenAI در Agents API مسیر مستقلی برای استفاده از مرورگر میزبانی‌شده ارائه می‌کند.

در این مقاله تمرکز ما روی اجرای مرورگر در زیرساخت خودمان است؛ بنابراین از Playwright و ابزار Computer در Responses API استفاده می‌کنیم.

مستندات رسمی Computer Use در OpenAI

معماری اجرای Computer Use Agent روی VPS

یک معماری مناسب باید بخش تصمیم‌گیری مدل را از محیط اجرای مرورگر جدا کند.

در این ساختار، API برنامه درخواست را دریافت می‌کند، هویت کاربر را بررسی می‌کند و سپس یک Job کنترل‌شده برای اجرای مرورگر ایجاد می‌شود.

User / Website
      |
HTTPS API
      |
Authentication + Permissions
      |
Task Controller
      |
OpenAI Responses API
      |
Computer Tool Driver
      |
Isolated Browser / Playwright
      |
Allowed Website
      |
Screenshot + Verified Result

نقش هر بخش

• Task Controller: محدودیت مراحل، زمان اجرا و سیاست تأیید را مدیریت می‌کند.
• OpenAI Responses API: تصمیم‌های مدل و فراخوانی ابزار Computer را پردازش می‌کند.
• Driver: عملیات مجاز را به دستورات واقعی مرورگر تبدیل می‌کند.
• Browser Sandbox: مرورگر را از اطلاعات و سرویس‌های حساس میزبان جدا می‌کند.
• Verifier: نتیجه واقعی صفحه را مستقل از ادعای مدل بررسی می‌کند.
• Audit: عملیات و تصمیم‌های مجوز را برای بررسی‌های بعدی ثبت می‌کند.

آیا مرورگر باید همیشه باز بماند؟

خیر. در بسیاری از کاربردها بهتر است برای هر Job یک محیط مرورگر ایجاد شود و پس از پایان یا توقف کار، منابع آن آزاد شوند.

اگر یک گردش کار چندمرحله‌ای به حفظ Login یا وضعیت صفحه نیاز دارد، Browser Context باید تا پایان همان گردش کار باقی بماند؛ اما نباید بدون نیاز برای مدت نامحدود فعال باشد.

منابع موردنیاز VPS برای اجرای Agent مرورگر

برخلاف Agentهای متنی ساده، اجرای مرورگر Chromium روی VPS مقداری از CPU و RAM را مصرف می‌کند. اگر چند مرورگر هم‌زمان اجرا شوند، مصرف منابع افزایش می‌یابد.

این اعداد پیشنهاد اولیه هستند و حداقل رسمی OpenAI یا Playwright محسوب نمی‌شوند. مصرف واقعی به نوع وب‌سایت، تعداد تب‌ها، تصاویر، اسکریپت‌های JavaScript و تعداد Browser Contextهای فعال بستگی دارد.

آیا به کارت گرافیک نیاز داریم؟

برای اجرای نمونه Headless Chromium و استفاده از OpenAI API معمولاً GPU اختصاصی لازم نیست.

پردازش مدل توسط OpenAI API انجام می‌شود و VPS وظیفه اجرای مرورگر و برنامه کنترلی را بر عهده دارد.

چرا RAM بیشتر می‌تواند مهم باشد؟

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

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

Browser Isolation چیست و چگونه مرورگر را ایزوله کنیم؟

Browser Isolation یعنی محیط مرورگر به‌گونه‌ای اجرا شود که دسترسی آن به فایل‌ها، شبکه و سایر داده‌های سیستم محدود باشد.

برای مثال، مرورگری که برای مشاهده یک صفحه عمومی اجرا شده است نباید به‌صورت پیش‌فرض امکان خواندن فایل‌های خصوصی کاربران یا ارتباط با API مدیریتی داخلی VPS را داشته باشد.

لایه اول: Browser Context مستقل

Playwright امکان ساخت Browser Context جداگانه را فراهم می‌کند. هر Context به‌طور معمول Cookieها و وضعیت مرورگر مخصوص خودش را دارد.

برای ساخت یک Context جدید:

context = await browser.new_context(
    viewport={"width": 1024, "height": 768},
    accept_downloads=False,
)

page = await context.new_page()

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

لایه دوم: فرآیند و کاربر مستقل

مرورگر بهتر است با کاربر غیر root اجرا شود. همچنین نباید مجوزهای مدیریتی سیستم‌عامل، Docker Socket یا مسیرهای حساس میزبان بدون نیاز به آن داده شوند.

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

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

مستندات Playwright هشدار می‌دهند که اجرای Chromium با کاربر root در Docker می‌تواند Sandbox مرورگر را غیرفعال کند. بنابراین برای مرور صفحات نامطمئن باید به اجرای غیر root، تنظیمات مناسب Sandbox و کنترل شبکه توجه کرد.

لایه چهارم: محدودیت دسترسی شبکه

یک Agent مرورگر نباید بتواند آزادانه به تمام شبکه داخلی VPS، سرویس‌های Metadata یا رابط‌های مدیریتی دسترسی داشته باشد.

بهترین روش این است که مقصدهای مجاز از طریق Firewall خروجی، Proxy یا سیاست شبکه محیط اجرا محدود شوند.

قانون Playwright برای مسدود کردن درخواست‌ها می‌تواند یک لایه کمکی باشد؛ اما جایگزین Firewall و جداسازی واقعی شبکه نیست.

لایه پنجم: پاک‌سازی محیط پس از پایان Job

پس از پایان کار باید مرورگر بسته شود، فایل‌های موقت پاک‌سازی شوند و Sessionهای بدون استفاده آزاد شوند.

اگر اطلاعات ورود یا Screenshot ذخیره شده‌اند، نگهداری آن‌ها باید مطابق سیاست مشخص و با دسترسی محدود انجام شود.

راهنمای رسمی Playwright برای Docker و Browser Sandbox

مرحله اول: نصب Python، Playwright و OpenAI SDK روی Ubuntu VPS

در این آموزش از Ubuntu 24.04 LTS استفاده می‌کنیم. پیش از نصب، مطمئن شوید VPS دسترسی شبکه لازم برای دانلود بسته‌ها و فراخوانی OpenAI API را دارد.

نصب پیش‌نیازهای سیستم

sudo apt update
sudo apt install -y python3 python3-venv python3-pip \
curl ca-certificates

ساخت پوشه پروژه

mkdir -p ~/computer-agent
cd ~/computer-agent

ایجاد محیط مجازی Python

python3 -m venv .venv
.venv/bin/python -m pip install --upgrade pip

نصب کتابخانه‌ها

نسخه‌های زیر مطابق نمونه فعلی SDK در راهنمای رسمی Computer Use انتخاب شده‌اند:

.venv/bin/python -m pip install \
"openai==3.31.0" "playwright==1.61.0" \
"fastapi" "uvicorn"

این نسخه‌ها برای بازتولید مثال انتخاب شده‌اند و به معنی جدیدترین انتشار تمام کتابخانه‌ها در هر زمان نیستند. قبل از ارتقا، سازگاری APIها و مرورگر نصب‌شده را بررسی کنید.

نصب Chromium و وابستگی‌های لازم

.venv/bin/python -m playwright install chromium

اگر Chromium هنگام اجرا با خطای نبود کتابخانه‌های سیستمی مواجه شد، وابستگی‌های مرورگر را نصب کنید:

sudo .venv/bin/python -m playwright install-deps chromium

این مرحله برای نصب وابستگی‌های سیستم‌عامل به دسترسی مدیریتی نیاز دارد. خود مرورگر را در محیط عملیاتی با کاربر غیر root اجرا کنید.

ساخت API Key

برای استفاده از مدل، به OpenAI API Key معتبر نیاز دارید. می‌توانید آن را از بخش مدیریت API Keys ایجاد کنید.

برای تست اولیه، متغیر زیر را در محیط اجرای خود تنظیم کنید:

export OPENAI_API_KEY="YOUR_REAL_OPENAI_API_KEY"

این روش فقط برای تست کوتاه مناسب است. در Production بهتر است کلید با سازوکار مدیریت Secrets نگهداری شود و داخل کد یا فایل عمومی قرار نگیرد.

چرخه Computer Use؛ از Screenshot تا Action و Observation

در معماری Computer Use، مدل برای تصمیم‌گیری باید بتواند وضعیت محیط را مشاهده کند. این وضعیت می‌تواند Screenshot یا اطلاعات ساختاریافته صفحه باشد.

در روش تصویری، چرخه به شکل زیر اجرا می‌شود:

1. Capture Screenshot
         |
2. Send Observation to Model
         |
3. Receive Computer Actions
         |
4. Validate Permissions
         |
5. Execute Allowed Actions
         |
6. Capture Updated Screenshot
         |
7. Continue or Verify Result

ابزار computer چه عملیات‌هایی ارائه می‌کند؟

بسته به Driver و محیط اجرایی، مدل می‌تواند عملیات‌هایی مانند click، double_click، scroll، keypress، type، move، drag، wait و screenshot درخواست کند.

اما وجود یک نوع عملیات در پروتکل به این معنی نیست که برنامه باید اجرای آن را مجاز کند.

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

چرا باید بعد از عملیات دوباره Screenshot بگیریم؟

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

اگر Agent فقط براساس تصویر قدیمی تصمیم بگیرد، ممکن است روی نقطه اشتباه کلیک کند.

چگونه تعداد مراحل را محدود کنیم؟

در ابزارهای کمکی SDK می‌توانید برای Runner تعداد مراحل مشخص کنید. برای محیط Production علاوه بر آن باید محدودیت زمانی، هزینه مصرف مدل و تعداد عملیات مرورگر نیز داشته باشید.

این محدودیت‌ها از حلقه‌های بی‌پایان و مصرف غیرمنتظره منابع جلوگیری می‌کنند.

مرحله دوم: ساخت یک AI Computer Use Agent واقعی با Python

اکنون یک نمونه عملی و محدود می‌سازیم که فقط با یک صفحه HTML آزمایشی کار می‌کند. این صفحه شامل جزئیات یک درخواست پشتیبانی فرضی است.

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

این نمونه از الگوی رسمی AsyncComputerToolset استفاده می‌کند و برای تمرین Computer Use طراحی شده است. صفحه از طریق set_content ساخته می‌شود و هیچ حساب واقعی یا وب‌سایت خارجی درگیر نیست.

ایجاد فایل demo.py

nano ~/computer-agent/demo.py

کد کامل نمونه

import asyncio
import base64

from openai import AsyncComputerToolset, AsyncOpenAI
from playwright.async_api import async_playwright


class SupportPageDriver:
    def __init__(self, page):
        self.page = page

    async def screenshot(self):
        image = await self.page.screenshot(type="png")
        return {
            "type": "computer_screenshot",
            "image_url": (
                "data:image/png;base64,"
                + base64.b64encode(image).decode("ascii")
            ),
        }

    async def allowed(self, action):
        if action.type == "screenshot":
            return True

        if (
            action.type != "click"
            or action.button != "left"
            or action.keys
        ):
            return False

        box = await self.page.locator(
            "#show-details"
        ).bounding_box()

        if not box:
            return False

        return (
            box["x"] <= action.x < box["x"] + box["width"]
            and box["y"] <= action.y < box["y"] + box["height"]
        )

    async def click(self, action):
        if not await self.allowed(action):
            raise RuntimeError("Action is not permitted")

        await self.page.mouse.click(
            action.x,
            action.y,
        )

    async def refuse(self, action):
        raise RuntimeError(
            f"Unsupported action: {action.type}"
        )

    double_click = drag = keypress = move = scroll = type = wait = refuse


async def run_demo():
    async with (
        async_playwright() as playwright,
        AsyncOpenAI(
            timeout=30,
            max_retries=0,
        ) as client,
    ):
        browser = await playwright.chromium.launch(
            env={},
            chromium_sandbox=True,
        )

        try:
            context = await browser.new_context(
                viewport={
                    "width": 1024,
                    "height": 768,
                },
                accept_downloads=False,
            )

            try:
                page = await context.new_page()

                # This exercise does not allow network requests.
                await page.route(
                    "**/*",
                    lambda route: route.abort(),
                )

                await page.set_content(
                    "<title>Support Status</title>"
                    "<main>"
                    "<h1>IranicaServer Support Demo</h1>"
                    "<p>Service: demo-vps-01</p>"
                    "<details>"
                    "<summary id='show-details'>"
                    "Show service details"
                    "</summary>"
                    "<p id='service-result'>"
                    "Service status: online. "
                    "Active users: 4."
                    "</p>"
                    "</details>"
                    "</main>"
                )

                driver = SupportPageDriver(page)
                tools = AsyncComputerToolset(driver)

                try:
                    response = await tools.run(
                        client,
                        {
                            "model": "gpt-6.1-sol",
                            "store": False,
                            "input": (
                                "Take a screenshot. "
                                "Open Show service details "
                                "using a left click. "
                                "Report the service status "
                                "and number of active users. "
                                "Do not perform other actions."
                            ),
                        },
                        before_action=driver.allowed,
                        max_steps=6,
                    )

                    opened = await page.locator(
                        "details"
                    ).get_attribute("open")

                    if opened is None:
                        raise RuntimeError(
                            "Details were not opened"
                        )

                    actual = await page.locator(
                        "#service-result"
                    ).inner_text()

                    if (
                        "Service status: online" not in actual
                        or "Active users: 4" not in actual
                    ):
                        raise RuntimeError(
                            "Expected status not found"
                        )

                    return {
                        "verified": True,
                        "browser_result": actual,
                        "agent_answer": response.output_text,
                    }

                finally:
                    tools.close()

            finally:
                await context.close()

        finally:
            await browser.close()


if __name__ == "__main__":
    print(asyncio.run(run_demo()))

این برنامه چگونه کار می‌کند؟

ابتدا Playwright یک مرورگر Chromium بدون رابط گرافیکی ایجاد می‌کند. صفحه آزمایشی در همان Browser Context بارگذاری می‌شود.

سپس AsyncComputerToolset به Driver متصل می‌شود. مدل می‌تواند Screenshot دریافت کند و یک کلیک روی بخش مشخص درخواست کند.

تابع allowed پیش از اجرای عملیات، نوع Action و مختصات آن را بررسی می‌کند. اگر عملیات خارج از محدوده باشد، مجاز شناخته نمی‌شود.

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

در پایان، مرورگر و Context بسته می‌شوند تا منابع آزاد شوند.

چرا از Driver محدود استفاده کردیم؟

برای اینکه مدل حتی در صورت انتخاب یک عملیات اشتباه نتواند خارج از وظیفه آموزشی تعیین‌شده عمل کند.

در مثال حاضر، تایپ، Drag، اسکرول و کلیک روی عناصر دیگر ممنوع هستند. همچنین درخواست شبکه خارجی نیز در این تمرین مسدود شده است.

این نمونه، الگوی محدودسازی قابلیت‌ها را نشان می‌دهد؛ اما Browser Context به‌تنهایی Sandbox امنیتی کافی برای صفحات نامطمئن نیست.

مرحله سوم: اجرای نمونه و بررسی نتیجه واقعی

وارد پوشه پروژه شوید و فایل Python را اجرا کنید:

cd ~/computer-agent
.venv/bin/python demo.py

اگر API Key معتبر باشد، پروژه به مدل دارای قابلیت Computer Use دسترسی داشته باشد و تمام مراحل با موفقیت اجرا شوند، خروجی باید شامل verified و اطلاعات خوانده‌شده از صفحه باشد.

نمونه نتیجه مورد انتظار:

{
  "verified": true,
  "browser_result": "Service status: online. Active users: 4.",
  "agent_answer": "..."
}

متن agent_answer توسط مدل تولید می‌شود و ممکن است در اجراهای مختلف متفاوت باشد.

توجه: این نتیجه نشان‌دهنده رفتار مورد انتظار کد است، نه ادعای اجرای موفق آن روی VPS شما. قبل از استفاده واقعی، نمونه را در محیط خودتان آزمایش کنید.

اگر مدل ابزار Computer را نشناخت چه کنیم؟

ابتدا دسترسی پروژه API و سازگاری مدل با Computer Use را بررسی کنید. تمام مدل‌هایی که از متن یا تصویر پشتیبانی می‌کنند الزاماً از ابزار computer نیز پشتیبانی نمی‌کنند.

فهرست مدل‌ها و ابزارهای قابل استفاده در مستندات مدل‌های OpenAI ارائه شده است.

مدیریت Screenshot در AI Computer Use

Screenshot یکی از ورودی‌های اصلی در Agentهایی است که با مختصات صفحه کار می‌کنند. کیفیت و دقت تصویر روی انتخاب عملیات تأثیر دارد.

تفاوت Screenshot تصویری با داده ساختاریافته

در روش تصویری، مدل باید موقعیت عناصر را از روی عکس تشخیص دهد. در روش ساختاریافته، برنامه می‌تواند نقش و شناسه عناصر را در اختیار مدل قرار دهد.

برای یک صفحه دارای دکمه‌های ثابت، استفاده از Locator در Playwright می‌تواند از کلیک مختصاتی قابل اعتمادتر باشد. اما برای رابط‌هایی که دسترسی به عناصر ساختاریافته محدود است، Screenshot کاربرد بیشتری دارد.

مشکل تغییر اندازه Screenshot

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

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

آیا لازم است تمام Screenshotها ذخیره شوند؟

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

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

پنهان کردن اطلاعات حساس در Screenshot

Playwright امکان Mask کردن عناصر مشخص در Screenshot را فراهم می‌کند:

image = await page.screenshot(
    type="png",
    mask=[
        page.locator("input[type='password']"),
        page.locator("[data-sensitive='true']"),
    ],
)

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

برای کارهای حساس، علاوه بر Mask کردن عناصر، بهتر است دسترسی Agent به داده‌های خصوصی غیرضروری اساساً محدود شود.

آیا Screenshot به OpenAI ارسال می‌شود؟

بله. وقتی از Computer Use مبتنی بر OpenAI API استفاده می‌کنید، Screenshotهایی که به‌عنوان Observation به مدل می‌فرستید، برای پردازش درخواست به API ارسال می‌شوند.

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

تأیید انسانی و جلوگیری از اقدامات ناامن مرورگر

بزرگ‌ترین تفاوت یک Agent آزمایشی با Agent عملیاتی، توانایی آن برای تغییر اطلاعات واقعی است.

کلیک روی دکمه نمایش جزئیات معمولاً کم‌خطر است؛ اما دکمه‌هایی مانند پرداخت، حذف، ارسال ایمیل، تغییر رمز، انتشار محتوا یا تغییر تنظیمات امنیتی پیامدهای متفاوتی دارند.

چه عملیاتی به تأیید نیاز دارند؟

چرا دستور «قبل از خرید از من بپرس» کافی نیست؟

چون دستورالعمل مدل به‌تنهایی یک کنترل اجرایی تضمین‌شده محسوب نمی‌شود.

اگر می‌خواهید امکان انجام عملیات حساس بدون تأیید وجود نداشته باشد، باید در Driver یا Backend از اجرای آن جلوگیری کنید تا یک تصمیم مدل نتواند کنترل را دور بزند.

تأیید باید به عملیات دقیق متصل باشد

فرض کنید Agent قصد ثبت یک سفارش دارد. رابط تأیید باید مشخص کند چه محصولی، به چه مبلغی، برای چه حسابی و با چه شرایطی ثبت می‌شود.

اگر یکی از این اطلاعات تغییر کند، تأیید قبلی نباید معتبر بماند.

مدل نباید تأیید خودش را صادر کند

نباید صرفاً یک پارامتر مانند approved=true از مدل دریافت کنید. این مقدار اثبات‌کننده موافقت کاربر واقعی نیست.

یک پیاده‌سازی مناسب می‌تواند از یک شناسه تأیید یک‌بارمصرف استفاده کند که در Backend مورد اعتماد ذخیره شده و به کاربر، عملیات و پارامترهای دقیق وابسته باشد.

آیا می‌توان تمام کلیک‌های خطرناک را از روی متن دکمه شناخت؟

خیر. یک دکمه ممکن است متن ساده‌ای مانند Continue داشته باشد، اما باعث ارسال فرم یا اجرای درخواست حساس شود.

همچنین یک صفحه ممکن است هنگام تغییر مقدار فرم یا اجرای JavaScript، درخواست شبکه‌ای ارسال کند.

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

الگوی امن‌تر برای عملیات حساس

1. Agent داده‌ها و پیشنهاد اقدام را آماده کند.
2. برنامه جزئیات دقیق عملیات را به کاربر نمایش دهد.
3. کاربر از طریق رابط مورد اعتماد تأیید کند.
4. Backend هویت، مالکیت و پارامترهای عملیات را بررسی کند.
5. عملیات فقط یک بار اجرا شود.
6. نتیجه از منبع معتبر بررسی و ثبت شود.

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

مدیریت Login، Cookie، رمز عبور و MFA در Browser Agent

بسیاری از وظایف Computer Use به ورود به حساب کاربری نیاز دارند. اما اطلاعات ورود از حساس‌ترین بخش‌های این معماری هستند.

آیا باید رمز عبور را داخل Prompt قرار دهیم؟

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

فرستادن این اطلاعات به متن عمومی گفتگو یا قرار دادن آن‌ها در دستورهای مدل می‌تواند خطر افشا را افزایش دهد.

روش اول: ورود توسط کاربر

در این روش، برنامه مرورگر را در اختیار کاربر قرار می‌دهد تا Login و تأیید دومرحله‌ای را انجام دهد. پس از تکمیل ورود، کنترل مرورگر در همان محیط مجاز به Agent بازگردانده می‌شود.

این روش برای ورودهای تعاملی، CAPTCHA و مراحل هویتی مناسب‌تر است؛ مشروط بر اینکه زیرساخت شما امکان انتقال امن کنترل را فراهم کرده باشد.

روش دوم: استفاده از Storage State در Playwright

Playwright می‌تواند وضعیت احراز هویت مرورگر را ذخیره کند و در یک Context جدید دوباره بارگذاری کند.

نمونه ذخیره وضعیت:

await context.storage_state(
    path="/secure/session-state.json"
)

و برای بازیابی:

context = await browser.new_context(
    storage_state="/secure/session-state.json"
)

مسیر فوق صرفاً نمونه است و پوشه امن آن باید از قبل وجود داشته باشد.

هشدار: فایل Storage State ممکن است Cookieها و Tokenهای فعالی داشته باشد که برای ورود به حساب کافی باشند. بنابراین باید مانند Credential محرمانه با آن رفتار کنید.

چرا اشتراک Cookie بین کاربران خطرناک است؟

اگر Browser Context یا Storage State یک کاربر به اشتباه برای کاربر دیگری استفاده شود، احتمال افشای اطلاعات و دسترسی به حساب اشتباه وجود دارد.

در محیط چندکاربره، هر Job باید به مالک مشخصی وابسته باشد و Browser Context یا وضعیت احراز هویت آن با کاربران دیگر مشترک نباشد.

اگر سایت MFA یا CAPTCHA بخواهد چه کنیم؟

Agent باید امکان توقف امن و انتقال کنترل به کاربر را داشته باشد. کاربر می‌تواند مرحله احراز هویت موردنیاز را از طریق رابط مورد اعتماد تکمیل کند.

نباید برای عبور غیرمجاز از CAPTCHA، MFA یا سایر کنترل‌های امنیتی سایت تلاش کنید.

ورود در OpenAI-hosted Computer Use

در مسیر مرورگر میزبانی‌شده Agents API، مستندات OpenAI جریان جداگانه‌ای برای درخواست ورود و ارائه اطلاعات لازم توسط برنامه معرفی می‌کنند.

همچنین تأیید دسترسی به Origin با تأیید انجام عملیات حساس تفاوت دارد. اجازه ورود به یک سایت به معنی اجازه حذف، خرید یا ارسال اطلاعات از آن سایت نیست.

مستندات Computer Use و Login در Agents API

مدیریت Retry، Timeout و بازیابی عملیات Browser Agent

مرورگر همیشه طبق انتظار عمل نمی‌کند. ممکن است وب‌سایت دیر بارگذاری شود، اتصال شبکه قطع شود، یک دکمه جابه‌جا شود یا درخواست مدل با خطا مواجه شود.

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

Retry برای خواندن صفحه

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

نمونه ساده با Playwright:

import asyncio
from playwright.async_api import TimeoutError as PWTimeout


async def open_with_retry(page, url):
    delays = [1, 2, 4]

    for attempt in range(3):
        try:
            response = await page.goto(
                url,
                wait_until="domcontentloaded",
                timeout=15000,
            )

            if response is None:
                raise RuntimeError("No navigation response")

            if response.status >= 500:
                raise RuntimeError("Temporary server error")

            return response

        except (PWTimeout, RuntimeError):
            if attempt == 2:
                raise

            await asyncio.sleep(delays[attempt])

این تابع برای صفحه خواندنی و URL از قبل مجازشده طراحی شده است. بررسی مقصد و شبکه باید مستقل از آن انجام شده باشد.

همچنین تمام خطاهای HTTP نباید Retry شوند؛ برای مثال، 401 و 403 معمولاً نیازمند بررسی مجوز هستند، نه ارسال دوباره همان درخواست.

چرا نباید عملیات Submit را کورکورانه Retry کنیم؟

اگر درخواست ثبت سفارش ارسال شده ولی پاسخ سایت به علت Timeout دریافت نشده باشد، ممکن است سفارش واقعاً ثبت شده باشد.

کلیک دوباره می‌تواند باعث ایجاد سفارش تکراری شود.

در چنین شرایطی ابتدا باید وضعیت واقعی عملیات را از صفحه، شناسه تراکنش یا Backend معتبر بررسی کنید.

Idempotency در Computer Use

اگر عملیات نوشتنی از طریق API شما انجام می‌شود، می‌توانید از Idempotency Key برای جلوگیری از اجرای تکراری استفاده کنید.

اما اگر Agent فقط روی یک وب‌سایت شخص ثالث کلیک می‌کند، وجود Idempotency تضمین‌شده نیست و باید وضعیت نهایی را قبل از هر تلاش مجدد بررسی کند.

حفظ وضعیت مرورگر هنگام Retry

اگر مدل پاسخ نداد اما مرورگر همچنان فعال بود، ممکن است لازم باشد از همان Browser Context و یک Screenshot جدید ادامه دهید.

ایجاد مرورگر تازه بدون بررسی، می‌تواند باعث از دست رفتن Login یا وضعیت نیمه‌تمام فرم شود.

از طرف دیگر، اگر مرورگر Crash کرده باشد، ادامه دادن با Response ID قبلی لزوماً محیط مرورگر را بازیابی نمی‌کند.

محدودیت‌های پیشنهادی برای هر Job

این مقادیر نمونه‌اند و حداقل یا حداکثر رسمی محسوب نمی‌شوند. محدودیت واقعی باید با تست بار و نوع وب‌سایت تعیین شود.

مقابله با Prompt Injection در صفحات وب

یکی از خطرات Computer Use این است که متن نمایش‌داده‌شده در صفحه وب می‌تواند حاوی دستورهایی برای مدل باشد.

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

این متن باید محتوای غیرقابل اعتماد صفحه تلقی شود؛ نه دستورالعمل معتبر برنامه.

نمونه سناریوی حمله

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

وجود چنین عبارتی به معنی درخواست واقعی کاربر صاحب Agent نیست و نباید مجوز انجام عملیات ایجاد کند.

کنترل‌های ضروری

• مقاصد مرورگر را به سایت‌های مجاز محدود کنید.
• محتوای صفحه را از دستورالعمل‌های مورد اعتماد جدا نگه دارید.
• ابزارهای حساس را بدون نیاز در اختیار Agent نگذارید.
• برای تغییرات مهم تأیید معتبر و مستقل داشته باشید.
• ارسال اطلاعات به دامنه‌های ناشناس را محدود کنید.
• در صورت مشاهده تغییر غیرمنتظره مقصد، Job را متوقف کنید.
• نتیجه عملیات را از منبع معتبر بررسی کنید.

آیا Prompt Injection فقط در متن صفحه است؟

خیر. ممکن است داخل تصویر، عنوان یک فایل، متن یک ایمیل، اعلان مرورگر یا داده برگشتی ابزار نیز قرار بگیرد.

به همین دلیل نباید تنها به فیلتر چند عبارت مشکوک اکتفا کرد. کنترل مجوز باید در لایه اجرای عملیات برقرار باشد.

آیا Browser Isolation جلوی Prompt Injection را می‌گیرد؟

Browser Isolation به محدود کردن پیامدهای احتمالی کمک می‌کند، اما تضمین نمی‌کند مدل محتوای غیرقابل اعتماد را اشتباه تفسیر نکند.

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

مرحله چهارم: ارائه Agent مرورگر از طریق FastAPI

پس از اجرای نمونه محلی، می‌توانید آن را به یک API تبدیل کنید تا برنامه دیگری بتواند اجرای وظیفه آزمایشی را درخواست کند.

در این بخش فقط همان سناریوی ثابت و بدون دسترسی شبکه را ارائه می‌کنیم. این API اجازه دریافت URL دلخواه یا اجرای عملیات آزاد مرورگر را ندارد.

ساخت فایل app.py

nano ~/computer-agent/app.py

کد زیر را قرار دهید:

import asyncio
import os
import secrets

from fastapi import FastAPI, Header, HTTPException

from demo import run_demo


app = FastAPI(
    title="Computer Use Demo API",
    docs_url=None,
    redoc_url=None,
)

API_TOKEN = os.environ["COMPUTER_AGENT_TOKEN"]

job_lock = asyncio.Lock()


@app.get("/healthz")
async def health():
    return {"ok": True}


@app.post("/v1/run-demo")
async def run_browser_demo(
    x_agent_token: str | None = Header(default=None),
):
    if (
        x_agent_token is None
        or not secrets.compare_digest(
            x_agent_token,
            API_TOKEN,
        )
    ):
        raise HTTPException(
            status_code=401,
            detail="Unauthorized",
        )

    if job_lock.locked():
        raise HTTPException(
            status_code=429,
            detail="A demo task is already running",
        )

    async with job_lock:
        try:
            return await asyncio.wait_for(
                run_demo(),
                timeout=120,
            )

        except asyncio.TimeoutError:
            raise HTTPException(
                status_code=504,
                detail="Task timed out",
            )

        except Exception:
            raise HTTPException(
                status_code=502,
                detail="Browser task failed",
            )

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

این طراحی برای نمونه تک‌فرآیندی مناسب است. اگر چند Worker اجرا کنید، Lock داخل حافظه هر Worker مستقل است و محدودیت سراسری ایجاد نمی‌کند.

برای Production چندکاربره باید از صف کار، احراز هویت اختصاصی، سهمیه کاربران و هماهنگی میان Workerها استفاده کنید.

تست API روی Loopback

ابتدا یک توکن مناسب به محیط اضافه کنید و Uvicorn را فقط روی آدرس محلی اجرا کنید:

export COMPUTER_AGENT_TOKEN="YOUR_LONG_RANDOM_TOKEN"

.venv/bin/uvicorn app:app \
--host 127.0.0.1 \
--port 8766 \
--workers 1

در یک ترمینال دیگر می‌توانید وضعیت API را بررسی کنید:

curl http://127.0.0.1:8766/healthz

این تست فقط فعال بودن برنامه را بررسی می‌کند. برای آزمون کامل باید endpoint مربوط به اجرای Demo را با توکن معتبر فراخوانی کنید.

مرحله پنجم: اجرای Computer Use Agent با systemd و Nginx

برای اینکه سرویس API پس از Restart سرور نیز فعال شود، می‌توانید آن را با systemd مدیریت کنید.

پیش از این مرحله، بهتر است پروژه از مسیر Home کاربر توسعه به یک مسیر ثابت، با مالکیت و مجوزهای محدود منتقل شود. نمونه زیر فرض می‌کند برنامه در مسیر /opt/computer-agent نصب شده و کاربر مستقلی به نام browseragent برای اجرای آن ساخته‌اید.

نمونه سرویس systemd

[Unit]
Description=Computer Use Agent API
Wants=network-online.target
After=network-online.target

[Service]
Type=simple
User=browseragent
Group=browseragent
WorkingDirectory=/opt/computer-agent

EnvironmentFile=/etc/computer-agent/agent.env

ExecStart=/opt/computer-agent/.venv/bin/uvicorn app:app --host 127.0.0.1 --port 8766 --workers 1

Restart=on-failure
RestartSec=10

NoNewPrivileges=true
PrivateTmp=true

CPUAccounting=true
MemoryAccounting=true
TasksAccounting=true

MemoryMax=3G
TasksMax=512

[Install]
WantedBy=multi-user.target

این سرویس فقط یک قالب برای استقرار است و قبل از اجرا باید کاربر، مسیر برنامه، EnvironmentFile و دسترسی به فایل‌های مرورگر در محیط واقعی آماده شده باشند.

مقدار MemoryMax صرفاً نمونه است. برای مرورگرهای سنگین یا چند Job ممکن است به حافظه بیشتری نیاز داشته باشید.

چرا Uvicorn را مستقیماً روی اینترنت منتشر نکنیم؟

بهتر است API داخلی روی Loopback اجرا شود و دسترسی عمومی فقط از طریق Reverse Proxy و HTTPS انجام شود.

با این روش می‌توانید در Nginx محدودیت نرخ درخواست، اندازه درخواست و تنظیمات TLS را مدیریت کنید.

نمونه Reverse Proxy

server {
    listen 80;
    server_name agent.example.com;

    client_max_body_size 16k;

    location / {
        proxy_pass http://127.0.0.1:8766;
        proxy_http_version 1.1;

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        proxy_connect_timeout 10s;
        proxy_read_timeout 180s;
    }
}

دامنه example.com صرفاً نمونه است. قبل از انتشار عمومی باید DNS و HTTPS فعال شوند.

همچنین این تنظیم اولیه Nginx، به‌تنهایی Rate Limit یا تأیید عملیاتی اضافه نمی‌کند. برای سرویس عمومی باید کنترل‌های مربوط به آن‌ها را جداگانه پیاده‌سازی کنید.

فعال‌سازی HTTPS

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

sudo apt install -y nginx certbot python3-certbot-nginx

sudo nginx -t

sudo certbot --nginx -d agent.example.com

این دستور فرض می‌کند Virtual Host به‌درستی فعال و دامنه به سرور متصل شده است.

پس از صدور گواهی، مطمئن شوید ارتباط HTTP به HTTPS هدایت می‌شود و پورت داخلی 8766 برای اینترنت باز نیست.

نکته درباره اجرای مرورگر داخل systemd

اجرای Chromium می‌تواند به کتابخانه‌های سیستمی، پوشه‌های موقت و دسترسی‌های Sandbox نیاز داشته باشد. تنظیمات سخت‌گیرانه systemd باید با آزمایش واقعی سازگاری مرورگر اعمال شوند.

برای صفحات غیرقابل اعتماد، توصیه می‌شود Browser Worker در یک محیط مستقل و دارای محدودیت شبکه اجرا شود؛ نه اینکه فقط به تنظیمات سرویس API تکیه کنید.

مانیتورینگ Agent مرورگر و مدیریت هزینه API

برای یک سرویس Computer Use، فعال بودن فرآیند Python به‌تنهایی کافی نیست. باید وضعیت مرورگر، تعداد Jobها، زمان اجرای عملیات و هزینه استفاده از مدل نیز بررسی شوند.

شاخص‌های مهم

چرا Screenshot روی هزینه تأثیر دارد؟

در Computer Use، مدل علاوه بر متن درخواست، تصاویر صفحه را نیز دریافت می‌کند. بنابراین تعداد مراحل و اندازه تصاویر می‌تواند روی مصرف API اثر بگذارد.

از طرف دیگر، کاهش شدید وضوح تصاویر ممکن است دقت تشخیص عناصر و کلیک را کم کند.

بهتر است با یک اندازه Viewport ثابت و تعداد مراحل محدود شروع کنید و هزینه و نرخ موفقیت را هم‌زمان اندازه بگیرید.

آیا CPU بیشتر VPS پاسخ مدل را سریع‌تر می‌کند؟

لزوماً خیر. افزایش CPU می‌تواند اجرای Chromium و پردازش‌های محلی را بهبود دهد؛ اما زمان پاسخ مدل به OpenAI API، پیچیدگی درخواست و شرایط سرویس مدل نیز وابسته است.

برای کاهش تأخیر باید مشخص کنید بخش اصلی زمان در بارگذاری صفحه، اجرای Browser Driver یا پاسخ مدل صرف می‌شود.

ثبت Audit بدون افشای اطلاعات

برای بررسی رخدادها می‌توانید نام Job، شناسه کاربر، نام دامنه مجاز، تعداد مراحل، زمان اجرا و نتیجه کنترل مجوز را ثبت کنید.

از ذخیره بی‌دلیل Screenshotهای خصوصی، Cookieها، رمز عبور و متن کامل فرم‌های حساس خودداری کنید.

پایش سرویس در Ubuntu

sudo systemctl status computer-agent --no-pager
sudo journalctl -u computer-agent -n 100 --no-pager
free -h
df -h

این دستورات فرض می‌کنند سرویس شما با نام computer-agent ثبت شده است. نام واقعی سرویس را متناسب با فایل Unit استفاده کنید.

رفع خطاهای رایج AI Computer Use روی VPS

۱. Chromium اجرا نمی‌شود

ممکن است وابستگی‌های سیستمی نصب نشده باشند، Sandbox مرورگر با محیط فعلی سازگار نباشد یا VPS حافظه کافی نداشته باشد.

ابتدا نصب Playwright و وابستگی‌ها، سطح دسترسی کاربر و لاگ خطای Chromium را بررسی کنید.

۲. خطای Executable doesn’t exist

این خطا معمولاً نشان می‌دهد نسخه مرورگر موردنیاز Playwright نصب نشده یا محیط اجرای برنامه به مسیر نصب مرورگر دسترسی ندارد.

از همان محیط Python که برنامه استفاده می‌کند، دستور نصب Chromium را اجرا کنید.

۳. خطای Browser closed unexpectedly

کمبود RAM، محدودیت‌های cgroup، اشکال Sandbox یا Crash داخلی مرورگر از دلایل احتمالی هستند.

مصرف منابع و رخدادهای OOM را بررسی کنید.

۴. مدل روی محل اشتباه کلیک می‌کند

ابعاد Viewport، وضوح Screenshot و تغییر موقعیت عناصر را بررسی کنید.

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

۵. بعد از کلیک اتفاقی نمی‌افتد

ممکن است عنصر هنوز آماده نباشد، یک لایه روی آن قرار گرفته باشد یا صفحه در حال بارگذاری باشد.

یک Screenshot جدید بگیرید و وضعیت واقعی عنصر را بررسی کنید. در صورت امکان، برای عملیات ساختاریافته از Locator و Auto-waiting استفاده کنید.

۶. Agent دائماً یک کار را تکرار می‌کند

ممکن است مدل نتیجه عملیات قبلی را درست تشخیص ندهد یا صفحه وضعیت مشخصی ارائه نکند.

تعداد مراحل را محدود کنید و پس از هر عملیات مهم، وضعیت نهایی را از صفحه یا Backend بررسی کنید.

۷. Login بعد از Restart از بین می‌رود

اگر از Context موقت استفاده می‌کنید، Cookieها پس از بسته شدن آن حفظ نمی‌شوند؛ مگر اینکه وضعیت احراز هویت به‌شکل کنترل‌شده ذخیره و بازیابی شود.

از Storage State محافظت‌شده استفاده کنید و برای حساب‌های حساس، روش ورود مجدد یا تأیید انسانی را در نظر بگیرید.

۸. MFA یا CAPTCHA مانع ادامه کار می‌شود

در این شرایط باید فرآیند را متوقف و کنترل را برای تکمیل مرحله احراز هویت به کاربر واگذار کنید.

بعد از پایان مرحله، وضعیت ورود را بررسی کنید و فقط در صورت مجاز بودن کار را ادامه دهید.

۹. خطای 401 در OpenAI API

API Key، وضعیت پروژه و دسترسی به مدل انتخاب‌شده را بررسی کنید.

کلید واقعی را در خروجی عمومی، تیکت یا Log قرار ندهید.

۱۰. مدل از ابزار computer استفاده نمی‌کند

ممکن است مدل انتخاب‌شده از ابزار پشتیبانی نکند یا SDK با مثال موردنظر سازگار نباشد.

به مستندات فعلی ابزار Computer و فهرست مدل‌های قابل استفاده مراجعه کنید.

۱۱. عملیات حساس بدون تأیید انجام می‌شود

این یک مشکل جدی طراحی است. اگر عملیات فقط براساس دستور مدل متوقف می‌شود، کنترل اجرایی کافی وجود ندارد.

باید امکان اجرای عملیات در Driver یا Backend بدون تأیید معتبر مسدود شود.

۱۲. درخواست Submit موفق بوده اما Agent خطا گزارش می‌دهد

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

پیش از هر Retry، وضعیت نهایی را از منبع معتبر بررسی کنید تا از عملیات تکراری جلوگیری شود.

۱۳. Nginx خطای 502 برمی‌گرداند

وضعیت سرویس Uvicorn، پورت داخلی و خطاهای Python را بررسی کنید.

همچنین در وظایف طولانی، Timeoutهای Reverse Proxy باید با مهلت اجرای Job هماهنگ باشند. برای کارهای طولانی بهتر است به‌جای نگه داشتن یک اتصال HTTP، از صف کار و API وضعیت Job استفاده کنید.

۱۴. Screenshot اطلاعات حساس را نمایش می‌دهد

قبل از ارسال Screenshot به مدل، سیاست نمایش داده را بررسی کنید. در صورت امکان عناصر حساس را Mask کنید یا از محیط آزمایشی دارای داده‌های غیرواقعی استفاده کنید.

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

چک‌لیست راه‌اندازی امن AI Computer Use روی سرور

• مدل و SDK با ابزار Computer فعلی سازگار هستند.
• مرورگر در محیط غیر root و محدود اجرا می‌شود.
• برای Jobها Browser Context مستقل تعریف شده است.
• شبکه خروجی به مقصدهای لازم محدود شده است.
• صفحات خارجی به‌عنوان داده غیرقابل اعتماد پردازش می‌شوند.
• فقط عملیات موردنیاز در Driver فعال هستند.
• محدودیت تعداد مراحل، زمان و هزینه تعریف شده است.
• Screenshotها بدون نیاز ذخیره نمی‌شوند.
• Credentialها داخل Prompt یا فایل عمومی قرار ندارند.
• Storage State کاربران با یکدیگر مشترک نیست.
• MFA و Login از مسیر امن و مورد اعتماد مدیریت می‌شوند.
• عملیات حساس به تأیید واقعی نیاز دارند.
• تأیید به کاربر و پارامترهای دقیق عملیات متصل است.
• Retry عملیات نوشتنی بدون بررسی نتیجه انجام نمی‌شود.
• نتیجه هر کار از وضعیت واقعی صفحه یا Backend تأیید می‌شود.
• Browser Context و منابع پس از پایان Job آزاد می‌شوند.
• Audit Log بدون ذخیره غیرضروری Secrets نگهداری می‌شود.
• تست خطا، Cancel و Crash مرورگر انجام شده است.
• برای کاربران متعدد، صف Job و کنترل هم‌زمانی وجود دارد.
• سرویس دارای مانیتورینگ و برنامه بازیابی است.

سؤالات متداول درباره AI Computer Use

AI Computer Use چیست؟

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

آیا می‌توان Computer Use را روی VPS اجرا کرد؟

بله. می‌توانید برنامه کنترلی و مرورگر Headless را روی VPS اجرا کنید و مدل را از طریق OpenAI API به آن متصل کنید.

آیا برای Computer Use باید مرورگر گرافیکی باز باشد؟

خیر. در بسیاری از سناریوها می‌توان از مرورگر Headless استفاده کرد؛ البته برخی برنامه‌های دسکتاپ به محیط گرافیکی کامل نیاز دارند.

تفاوت Computer Use با Playwright چیست؟

Playwright ابزار اجرای عملیات مرورگر است، درحالی‌که Computer Use می‌تواند از مدل هوش مصنوعی برای انتخاب و هدایت این عملیات استفاده کند.

آیا برای Computer Use به GPU نیاز داریم؟

برای نمونه مبتنی بر Chromium Headless و OpenAI API معمولاً خیر؛ اما نیاز واقعی به نوع پردازش‌های محلی بستگی دارد.

چگونه Agent صفحه را می‌بیند؟

با دریافت Screenshot یا داده‌های ساختاریافته صفحه که توسط Driver مرورگر فراهم می‌شوند.

آیا AI Computer Use می‌تواند روی دکمه‌ها کلیک کند؟

بله، به شرط اینکه Driver اجازه انجام عملیات موردنظر را داده باشد.

آیا می‌توان عملیات تایپ و اسکرول را نیز انجام داد؟

بله. ابزارهای Computer Use می‌توانند انواع عملیات ماوس و صفحه‌کلید را ارائه کنند، اما برنامه باید دسترسی‌ها را محدود کند.

Browser Isolation چیست؟

جداسازی محیط مرورگر از اطلاعات، کاربران و منابع حساس سیستم‌عامل است که می‌تواند با Browser Context، حساب اجرایی مستقل و Sandbox انجام شود.

آیا Browser Context برای امنیت کافی است؟

خیر. Browser Context عمدتاً وضعیت مرورگر را جدا می‌کند و جایگزین Sandbox یا جداسازی شبکه و فرآیند نیست.

آیا Agent می‌تواند وارد حساب کاربری شود؟

بله، اما ورود باید با روش امن مدیریت شود و اطلاعات محرمانه بی‌دلیل در اختیار مدل قرار نگیرد.

آیا باید رمز عبور را در Prompt وارد کنیم؟

خیر. بهتر است رمز عبور و اطلاعات احراز هویت از طریق بخش مورد اعتماد برنامه یا ورود مستقیم کاربر مدیریت شوند.

آیا می‌توان Cookieهای ورود را ذخیره کرد؟

بله. Playwright امکان ذخیره Storage State را فراهم می‌کند؛ اما فایل آن ممکن است شامل اطلاعات حساس ورود باشد و باید محافظت شود.

اگر سایت کد تأیید دومرحله‌ای بخواهد چه می‌شود؟

برنامه باید امکان توقف و انتقال کنترل به کاربر را برای تکمیل مرحله احراز هویت فراهم کند.

آیا Agent می‌تواند خرید انجام دهد؟

از نظر فنی ممکن است، اما خرید و سایر عملیات حساس باید تحت کنترل مجوز و تأیید معتبر انجام شوند.

آیا دستور «قبل از انجام خرید تأیید بگیر» کافی است؟

خیر. برای جلوگیری تضمین‌شده از عملیات ناخواسته باید کنترل تأیید در Driver یا Backend قابل اعتماد اجرا شود.

Prompt Injection در Computer Use چیست؟

تلاش برای تغییر رفتار Agent از طریق محتوای غیرقابل اعتماد صفحه، فایل یا اطلاعات نمایش‌داده‌شده در مرورگر است.

چرا Agent روی محل اشتباه کلیک می‌کند؟

ممکن است ابعاد Screenshot و Viewport متفاوت باشند یا عناصر صفحه پس از مشاهده تصویر جابه‌جا شده باشند.

آیا Retry خودکار همیشه امن است؟

خیر. برای عملیات نوشتنی مانند سفارش یا پرداخت، Retry بدون بررسی نتیجه می‌تواند باعث اجرای تکراری شود.

آیا می‌توان چند Browser Agent روی یک VPS اجرا کرد؟

بله. اما باید مصرف CPU و RAM، تعداد Jobهای هم‌زمان، جداسازی کاربران و کنترل شبکه را مدیریت کنید.

آیا Computer Use هزینه API دارد؟

بله. درخواست‌های مدل و تصاویر ارسالی ممکن است هزینه API داشته باشند. هزینه VPS نیز جداگانه محاسبه می‌شود.

آیا Computer Use جایگزین API سایت‌ها است؟

خیر. اگر API رسمی و مناسبی وجود دارد، معمولاً اتصال مستقیم به آن قابل پیش‌بینی‌تر است. Computer Use بیشتر برای تعامل با رابط کاربری کاربرد دارد.

چگونه بفهمیم Agent واقعاً کار را انجام داده است؟

باید نتیجه را از صفحه، وضعیت ذخیره‌شده یا Backend معتبر بررسی کنید؛ نه اینکه فقط به متن پاسخ مدل اکتفا کنید.

آیا می‌توان از Computer Use برای تست پنل مدیریتی استفاده کرد؟

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

جمع‌بندی

قابلیت AI Computer Use امکان ساخت Agentهایی را فراهم می‌کند که از طریق مرورگر با رابط کاربری وب‌سایت‌ها و نرم‌افزارها تعامل داشته باشند.

برای اجرای این قابلیت روی VPS می‌توانید از OpenAI Responses API، Python و Playwright استفاده کنید. در این معماری، مدل وظیفه انتخاب عملیات را بر عهده دارد و Driver شما اجرای واقعی آن‌ها را کنترل می‌کند.

در این آموزش یک نمونه عملی ساختیم که از صفحه Screenshot می‌گیرد، یک دکمه مجاز را انتخاب می‌کند و نتیجه را به‌صورت مستقل تأیید می‌کند. سپس روش ارائه آن از طریق FastAPI و اجرای سرویس با systemd را بررسی کردیم.

مهم‌ترین بخش طراحی Computer Use، امنیت محیط مرورگر است. ایزوله کردن مرورگر، محدودیت دسترسی شبکه، مدیریت Login، حفاظت از Screenshotها، کنترل Retry و تأیید مستقل اقدامات حساس باید از ابتدا در معماری برنامه وجود داشته باشند.

اگر هدف شما اجرای کارهای مهم روی حساب‌های واقعی است، بهتر است ابتدا همان گردش کار را در محیط آزمایشی اجرا و اعتبارسنجی کنید و سپس با کنترل‌های مجوز و تأیید مناسب، استفاده عملیاتی را آغاز کنید.