تورم پرامپت؛ دلیل واقعی کندی عامل‌های مرورگر نه محدودیت مدل‌هاست

اگر امروز یک عامل (Agent) برای اتوماسیون مرورگر ساخته‌اید و از سرعت آن ناراضی هستید، احتمالاً مشکل از مدل نیست، بلکه از حجم زباله‌ای است که به آن می‌خورانید. طبق گزارش‌های فنی منتشرشده در ۲۵ ژوئیه ۲۰۲۶، کالبدشکافی دقیق ردپاهای عملیاتی (Traces) نشان می‌دهد که توسعه‌دهندگان اغلب «زباله» را به درون پرامپت می‌رانند. این کار باعث ایجاد یک تأخیر خود-تحمیلی می‌شود که دقیقاً شبیه به کند بودن خودِ مدل به نظر می‌رسد.

وقتی یک عامل کند عمل می‌کند، واکنش معمول این است که مقصر را GPT-5، Claude Opus 4.6، کتابخانه Playwright یا محدودیت‌های نرخ فراخوانی (Rate Limits) بدانیم. اما واقعیت تلخ‌تر است: ردپاهای واقعی نشان می‌دهند که عامل در هر گام، حجم عظیمی از اطلاعات بی‌ربط را ارسال می‌کند؛ مواردی مانند تخلیه کامل متن صفحه (Full Page Dumps)، اسکرین‌شات‌های تکراری، دستورالعمل‌های بازگشتی و تاریخچه‌های استدلال قدیمی.

این چالش درست زمانی رخ می‌دهد که صنعت از رابط‌های سادهٔ چت به سمت جریان‌های کاری عامل‌محور (Agentic) و خودکار حرکت می‌کند. همان‌طور که در تحلیل قبلی ما درباره‌ی اینکه چگونه شفافیت واقعی به عامل‌های هوش مصنوعی کمک می‌کند تا مشتری جذب کنند اشاره کردیم، حالا تمرکز روی بهره‌وری عملیاتی این عامل‌ها در محیط تولید (Production) است. برای اکثر توسعه‌دهندگان، جهش از یک دموی موفق به یک عامل آماده برای تولید، نقطه‌ای است که مشکل «لندفیل یا محل دفن زباله‌های متنی» (Context Landfill) برای اولین بار ظاهر می‌شود. بحث‌های جاری در انجمن r/openclaw درباره‌ی استفاده بهینه از توکن‌ها در مرورگر، تأیید می‌کند که بسیاری از مشکلات عملکردی در واقع مشکلات مدیریت زمینه (Context Management) هستند. در کنار این بهینه‌سازی‌ها، مدیریت دقیق‌تر تنظیمات استدلال نیز حیاتی است؛ برای مثال، تنظیمات Effort در مدل‌های کلود می‌تواند با برنامه‌ریزی عمیق‌تر به کاهش هزینه عامل‌های پیچیده کمک کند.

کالبدشکافی تورم پرامپت (Prompt Bloat)

یک حلقهٔ ساده و ابتدایی (Naive) برای عامل معمولاً چنین مسیری را طی می‌کند: باز کردن صفحه $\rightarrow$ گرفتن اسکرین‌شات $\rightarrow$ استخراج متن صفحه $\rightarrow$ گنجاندن تمام دستورات تسک $\rightarrow$ گنجاندن تمام تاریخچه قبلی $\rightarrow$ پرسش از مدل برای گام بعدی $\rightarrow$ تکرار این چرخه ۲۰ بار. اگرچه این روش برای دموها جواب می‌دهد، اما در محیط تولید زشت و ناکارآمد است. تا گام دهم یا بیستم، مدل دیگر بر اساس یک وضعیت پاک تصمیم نمی‌گیرد، بلکه مجبور است از میان کوهی از داده‌های تکراری و زائد بگردد. این تورم به‌طور همزمان باعث تخریب تأخیر (Latency)، کاهش قابلیت اطمینان (Reliability) و افزایش هزینه می‌شود. توسعه‌دهندگان اغلب زمان خود را صرف عیب‌یابی محدودیت‌های نرخ فراخوانی یا تایم-اوت‌های مدل می‌کنند، در حالی که مشکل واقعی این است که هر پرامپت از پرامپت قبلی بزرگ‌تر شده است. این مسئله به نوعی شباهت زیادی به پدیده لغزش پرامپت دارد که در رویکردهای darwin-agents با استفاده از درگاه‌های اعتبارسنجی خودکار مهار می‌شود.

هنگام بررسی اجرای کندِ یک عامل، ردپاها معمولاً چندین لایه از اتلاف را آشکار می‌کنند:

• تکرار دستورات: همان دستورات سیستمی و گردش کاری در هر نوبت تکرار می‌شوند.
• افراط بصری (Visual Overkill): اسکرین‌شات‌های کامل ضمیمه می‌شوند، حتی زمانی که صفحه عمدتاً شامل متن است.
• تخلیه DOM: کل متن صفحه در پرامپت ریخته می‌شود، به‌جای اینکه فقط قطعات مرتبط ایزوله شوند.
• کشش تاریخچه (History Drag): تاریخچه کامل اقدامات و ردپاهای استدلالی قدیمی تا ابد یدک کشیده می‌شوند، به‌جای اینکه خلاصه‌سازی شوند.

این وضعیت «داشتن زمینه بیشتر» نیست؛ بلکه تحمیل تأخیر به خود است.

بهره‌گیری از حافظهٔ موقت پرامپت (Prompt Caching)

بسیاری از توسعه‌دهندگان قوانین طراحی حافظه موقت پرامپت را که در APIهای سازگار با OpenAI موجود است، نادیده می‌گیرند. حافظه موقت معمولاً به‌صورت خودکار در حجم‌های بیش از ۱۰۲۴ توکن (T) — تکه‌های کوچکی از متن، شبیه برش‌های یک کیک طولانی که مدل تکه‌تکه می‌خورد — فعال می‌شود و به ثبات پیشوند (Prefix) پرامپت وابسته است. اگر ابتدای پرامپت در هر نوبت تغییر کند، برخورد با حافظه (Cache Hit) با شکست مواجه می‌شود و توسعه‌دهنده در هر دو مورد زمان و هزینه، «مالیات توکن» پرداخت می‌کند. برای رسیدن به مسیری ارزان و سریع، بخش اول پرامپت باید ثابت بماند.

یک اشتباه رایج این است که «زباله‌های پویا» را در بالای پرامپت قرار دهند؛ مواردی مثل یک Blob اسکرین‌شات، تخلیه جاری صفحه یا سریال‌سازی DOM و سپس دستورات سیستمی را بیاورند. این ترتیب کاملاً معکوس است. اگر می‌خواهید پرامپت‌های شما با حافظه موقت سازگار باشند، بخش بالایی باید خسته‎‌کننده و ثابت باشد. این یعنی انتقال عناصر پویا به انتهای محموله (Payload).

برای بهینه‌سازی حافظه موقت، ساختار پرامپت باید معکوس شود:
۱. پرامپت سیستمی ثابت
۲. چارچوب ثابت تسک (Task Framing)
۳. دستورالعمل‌های ثابت ابزار
۴. خلاصه‌ی وضعیت فشرده
۵. ۱ تا ۳ اقدام اخیر
۶. تغییرات جزئی (Delta) مربوط به گام جاری

با ثابت نگه داشتن پیشوند، احتمال برخورد با حافظه را به حداکثر می‌رسانید که می‌تواند به‌طور چشمگیری ارزان‌تر و سریع‌تر از ورودی‌های بدون حافظه باشد. قبل از اینکه مدل خود را از GPT-5 به Claude Opus 4.6 تغییر دهید، стоит بپرسید که آیا پرامپت شما اصلاً به‌گونه‌ای طراحی شده که اجازه دهد حافظه موقت عمل کند یا خیر.

استراتژی‌های بهینه‌سازی در Browser Use

کتابخانه Browser Use پیچ‌های تنظیم (Knobs) خاصی برای مبارزه با اتلاف زمینه فراهم می‌کند. این‌ها ارتقای مدل نیستند، بلکه روش‌هایی برای متوقف کردن هدر رفتن زمینه هستند:

• use_vision=False: ارسال اسکرین‌شات‌ها را متوقف کنید، مگر اینکه واقعاً به زمینه بصری نیاز داشته باشید.
• use_vision='auto': قابلیت بینایی را در دسترس نگه دارید، اما ورودی تصویر را در هر نوبت اجباری نکنید.
• page_extraction_llm: از یک مدل کوچک‌تر برای استخراج داده‌ها استفاده کنید به‌جای اینکه مدل اصلی را هدر دهید.
• max_history_items: از یدک کشیدن کل گذشته در هر گام جلوگیری کنید.
• flash_mode=True: زمانی که سرعت اهمیت دارد، سربار اضافی تفکر و ارزیابی را کاهش دهید.

یک تنظیم عملی با استفاده از این گزینه‌ها می‌تواند به این شکل باشد:

from browser_use import Agent, ChatBrowserUse

agent = Agent(
    task="Log into Stripe, export last month's payouts CSV, upload it to Google Drive",
    llm=ChatBrowserUse(model="openai/gpt-5.5"),
    use_vision="auto",
    max_history_items=3,
    flash_mode=True, # page_extraction_llm=ChatBrowserUse(model="openai/gpt-5.5-mini")
)
history = await agent.run(max_steps=25)

در این معماری، مدل اصلی (GPT-5.5) تصمیمات سطح بالا می‌گیرد، در حالی که یک مدل ارزان‌تر یا کوچک‌تر، کارهای سخت استخراج صفحه را بر عهده می‌گیرد. این کار مانع از آن می‌شود که مدل پیشرو نیمی از زمان خود را صرف بازخوانی دامپ‌های غول‌پیکر صفحه کند.

جداسازی استخراج از استدلال

یک معماری بالغ‌تر، استخراج را از استدلال جدا می‌کند. یک مدل پیشرو مانند GPT-5.5 یا Claude Opus 4.6 نباید کارهای ارزان‌قیمت استخراج را انجام دهد اگر یک مدل کوچک‌تر می‌تواند آن را انجام دهد. برای مثال، یک مدل کوچک‌تر می‌تواند متن‌های قابل مشاهده، برچسب‌ها و وضعیت فرم‌ها را استخراج کند، در حالی که مدل پیشرو تصمیمات سطح بالا را مدیریت می‌کند.

در شبه-کد، این الگو به این شکل است:
state = small_extraction_model.extract(page) $\rightarrow$ decision = frontier_model.decide(task, summarized_history, state) $\rightarrow$ execute(decision).

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

پیاده‌سازی عملی با Playwright

برای کسانی که با Playwright یا Selenium ابزارهای سفارشی می‌سازند، کلید موفقیت «بی‌رحم بودن» است. شما باید «تغییرات» (Deltas) را ارسال کنید، نه «رمان‌ها» را. یک شیء وضعیت فشرده اغلب کافی است. برای مثال، یک تابع evaluate در Playwright می‌تواند فقط URL، عنوان صفحه، ۲۰ دکمه و لینک اول و بخشی از متن بدنه (تا ۲۰۰۰ کاراکتر) را ثبت کند.

() => {
  const buttons = [...document.querySelectorAll('button')].slice(0, 20).map(b => b.innerText.trim()).filter(Boolean);
  const links = [...document.querySelectorAll('a')].slice(0, 20).map(a => a.innerText.trim()).filter(Boolean);
  return {
    url: location.href,
    title: document.title,
    buttons,
    links,
    bodyText: document.body.innerText.slice(0, 2000)
  }
}

سپس، مدل به‌جای یک دامپ کامل DOM، یک شیء JSON سبک دریافت می‌کند:

• تسک: "Export last month's payouts CSV"
• URL: "https://dashboard.stripe.com/payouts"
• عنوان: "Payouts | Stripe Dashboard"
• دکمه‌ها: ["Export", "Filter", "Download"]
• اقدامات اخیر: ["opened payouts page", "set date filter to last month"]
• خلاصه تغییرات: "Export button is now visible"

مدیریت بی‌رحمانه حافظه باید جایگزین ذهنیت «محض احتیاط» شود. مؤثرترین عامل‌ها از حافظه فشرده استفاده می‌کنند. همان‌طور که در r/openclaw برجسته شده، گذار از تاریخچه خام به «پایداری جریان کار» (Workflow Persistence) و «مهارت‌های قابل استفاده مجدد» است که باعث می‌شود عامل‌ها کاربردی به نظر برسند. به‌جای لیست کردن هر کلیک، یک عامل می‌تواند به‌سادگی یک مهارت نام‌گذاری شده مانند monthly_finance_export را فعال کند. این کار مالیات توکنیِ توضیح مجدد یک روتین تکراری را در هر اجرا حذف می‌کند.

چه زمانی بینایی واقعاً اهمیت دارد؟

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

• رابط‌های کاربری حساس به چیدمان (Layout-sensitive) و اپلیکیشن‌های Canvas-heavy.
• تضمین کیفیت بصری (Visual QA) و حالت‌های مبهمی که در آن استخراج متن نکته اصلی را از دست می‌دهد.
• اقدامات ضد-بات یا رفتارهای عجیب مودال‌ها (Modals).

استفاده از use_vision='auto' پیش‌فرض بالغ‌تری است و تضمین می‌کند که غنی‌سازی داده‌ها تنها زمانی اضافه شود که نرخ موفقیت را بهبود بخشد. برای کسانی که می‌خواهند این مورد را سریعاً تست کنند، نصب ساده است: از طریق pip install playwright و npx playwright install یا استفاده از uv add browser-use برای کتابخانه Browser Use.

زاویه مالی آزمایش‌ها

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

اینجاست که مدل‌های قیمت‌گذاری تخت (Flat-pricing)، مانند آنچه Standard Compute ارائه می‌دهد، مزیت پیدا می‌کنند. Standard Compute یک API سازگار با OpenAI با قیمت ماهانه ثابت فراهم می‌کند. این به توسعه‌دهندگان اجازه می‌دهد تا حلقه را در n8n، Make، Zapier یا جریان‌های کاری سفارشی Playwright تنظیم کنند، بدون اینکه وسواس هزینه هر پرامپت شکست‌خورده را داشته باشند. این امر «مالیات عجیب» روی اصلاح بهره‌وری ساختاری را حذف می‌کند. همچنین باید در نظر داشت که زیرساخت اجرا نیز تأثیرگذار است؛ برخی گزارش‌ها نشان می‌دهند که حذف محیط‌های ابری و انتقال به اپلیکیشن‌های دسکتاپ، تأخیر اجرای عامل‌های تک‌کاربره را به‌طور چشمگیری کاهش داده است.

در نهایت، «حقیقت ناگواری» این است که عملکرد عامل اغلب یک مسئله «بسته‌بندی» است، نه یک مسئله «هوش». قبل از ارتقا به یک مدل جدیدتر یا عیب‌یابی محدودیت‌های نرخ فراخوانی، توسعه‌دهندگان باید محموله‌های خود را در گام‌های ۱، ۵ و ۲۰ بررسی کنند تا ببینند آیا پرامپت به‌صورت یکنواخت (Monotonically) در حال رشد است یا خیر. اگر عامل صرفاً در حال بازخوانی دستورات تکراری و تجزیه اسکرین‌شات‌های غیرضروری است، هیچ ارتقای مدلی آن را نجات نخواهد داد.

اگر در حال عیب‌یابی یک عامل کند هستید، ابتدا این چهار اصلاح را امتحان کنید:
۱. پیشوند پرامپت را منجمد کنید: بخش بالایی را ثابت نگه دارید تا برخورد با حافظه حداکثری شود.
۲. اسکرین‌شات‌ها را به‌طور پیش‌فرض خاموش کنید: آن‌ها را فقط در جاهایی که موفقیت را افزایش می‌دهند، برگردانید.
۳. استخراج را از استدلال جدا کنید: از یک مدل ارزان‌تر برای داده‌های صفحه و یک مدل قوی برای تصمیم‌گیری استفاده کنید.
۴. حافظه را به‌طور تهاجمی کوتاه کنید: فقط اقدامات اخیر و یک خلاصه فشرده را نگه دارید. تمام متن گفتگو را دوباره پخش نکنید.

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