پارسر کلاسیک یک لیست از پروکسی‌ها دریافت می‌کند، آن را به صورت دورانی مرور می‌کند و به محض اینکه سیستم ضد ربات الگو را تشخیص می‌دهد، سقوط می‌کند. عامل هوش مصنوعی به گونه‌ای دیگر عمل می‌کند: او مسدودیت را می‌بیند، خود تصمیم می‌گیرد که IP را تغییر دهد، هدرها را تغییر می‌دهد، درخواست‌ها را کند می‌کند — و همه اینها بدون دخالت شما انجام می‌شود. در اینجا بررسی می‌کنیم که چگونه عامل، سرور MCP و API پروکسی را به یک مجموعه کاری متصل کنیم که جلسات را حتی در وب‌سایت‌های محافظت شده زنده نگه می‌دارد.
سرور MCP چیست و چرا به پارسر نیاز دارد
MCP (پروتکل زمینه مدل) — یک پروتکل باز است که به عامل هوش مصنوعی (به عنوان مثال، مبتنی بر Claude یا هر LLM با پشتیبانی از فراخوانی ابزار) اجازه می‌دهد به ابزارهای خارجی از طریق یک رابط واحد دسترسی پیدا کند. قبلاً، برای دادن دسترسی به مدل به API خارجی، باید یک پوشش سفارشی برای هر وظیفه نوشته می‌شد. سرور MCP این مشکل را به گونه‌ای دیگر حل می‌کند: او مجموعه‌ای از «ابزارها» (tools) را توصیف می‌کند — توابعی که عامل می‌تواند خود به آنها فراخوانی کند، زمانی که متوجه می‌شود که به آنها نیاز دارد.
در زمینه پارسینگ، این به این شکل است: عامل وظیفه «جمع‌آوری قیمت‌ها برای 500 محصول از بازار» را دریافت می‌کند. او شروع به انجام درخواست‌ها از طریق ابزار fetch_page می‌کند، پاسخ 403 یا کپچا را می‌بیند، خود ابزار rotate_proxy را فراخوانی می‌کند، IP جدیدی دریافت می‌کند و درخواست را تکرار می‌کند — بدون دخالت اپراتور. سرور MCP در اینجا نقش «پل» بین منطق عامل و زیرساخت واقعی پروکسی را ایفا می‌کند.
تفاوت کلیدی با اسکریپت معمولی با چرخش بر اساس تایمر: عامل تصمیم می‌گیرد که IP را بر اساس زمینه — کد پاسخ، محتوای صفحه، سرعت مسدودسازی دامنه خاص تغییر دهد. او می‌تواند یک IP را برای جلسه احراز هویت نگه دارد و فقط برای درخواست‌های «سرد» جمع‌آوری داده‌ها IP را تغییر دهد، استراتژی‌ها را در حین کار ترکیب کند.
چرا عامل هوش مصنوعی به تغییر IP نیاز دارد و نه فقط لیست پروکسی
اگر به سادگی به عامل یک لیست ثابت از 50 پروکسی بدهید و از او بخواهید که آنها را به صورت دورانی مرور کند، دقیقاً همان چیزی را خواهید گرفت که با اسکریپت معمولی: الگوی درخواست‌ها به سرعت توسط سیستم ضد ربات از طریق فواصل، هدرها و توالی IP محاسبه می‌شود. Wildberries، Ozon، Avito و دیگر بازارهای بزرگ از تحلیل رفتاری استفاده می‌کنند — آنها نه تنها به IP نگاه می‌کنند، بلکه به اینکه چگونه User-Agent، کوکی‌ها، فینگرپرینت TLS و سرعت درخواست‌ها در ارتباط با آدرس خاص تغییر می‌کند نیز توجه دارند.
عامل هوش مصنوعی این مشکل را به طور اصولی متفاوت حل می‌کند. او می‌تواند:
- با توجه به کد پاسخ (403، 429، ریدایرکت به کپچا)، تشخیص دهد که IP فعلی «سوزانده شده» است و برای این دامنه دقیقاً یک IP جدید درخواست کند؛
- یک جلسه «چسبنده» (sticky session) را بر روی یک IP برای سناریوهای چند مرحله‌ای نگه دارد — به عنوان مثال، احراز هویت + پارسینگ پنل کاربری؛
- فرکانس درخواست‌ها را با توجه به واکنش وب‌سایت تنظیم کند، نه اینکه بر اساس یک تایمر سخت کار کند؛
- تغییر IP را با تغییر هدرها و شبیه‌سازی مرورگر از طریق ابزارهای ضد شناسایی مانند Dolphin Anty یا AdsPower ترکیب کند، اگر پارسینگ از طریق مرورگر headless انجام شود.
به همین دلیل است که مجموعه «عامل + سرور MCP + API پروکسی» به طور قابل توجهی درصد مسدودیت‌ها را نسبت به چرخش ثابت کاهش می‌دهد: تصمیم در مورد تغییر IP بر اساس واقعیت مسدودیت اتخاذ می‌شود، نه بر اساس زمان‌بندی.
معماری مجموعه: عامل → MCP → API پروکسی → پارسر
طرح کار شامل چهار لایه است و مهم است که حوزه مسئولیت هر یک را درک کنیم:
- عامل هوش مصنوعی (LLM با فراخوانی ابزار) — تصمیم‌گیری می‌کند: کدام صفحه را باید بعدی پارس کند، آیا نیاز به تغییر IP است، آیا باید کندتر شود؛
- سرور MCP — مجموعه‌ای از ابزارها را به عامل ارائه می‌دهد:
get_page،rotate_ip،check_proxy_status; - API ارائه‌دهنده پروکسی — IP جدید را بر اساس درخواست ارائه می‌دهد، موقعیت جغرافیایی و نوع اتصال (مسکونی، موبایل، دیتاسنتر) را نشان می‌دهد؛
- پارسر/کلاینت HTTP — درخواست واقعی به وب‌سایت هدف را با پارامترهای پروکسی دریافت شده اجرا می‌کند.
نکته مهم: سرور MCP خود وب‌سایت را پارس نمی‌کند — او فقط امکانات را به عامل ارائه می‌دهد. منطق «چه کار کنیم در صورت 403» در اختیار مدل باقی می‌ماند و سرور MCP فقط دستورات را اجرا می‌کند و نتیجه را برمی‌گرداند. این تفکیک اجازه می‌دهد تا ارائه‌دهنده پروکسی یا پارسر بدون بازنویسی منطق عامل تغییر کند — کافی است پیاده‌سازی ابزار را در سرور MCP به‌روزرسانی کنید.
نکته عملی
به عامل دسترسی مستقیم به API «خام» ارائه‌دهنده پروکسی ندهید — آن را در یک ابزار MCP جداگانه با مجموعه محدودی از پارامترها (کشور، نوع IP، session_id) بپیچید. این خطر اینکه مدل به طور تصادفی یک درخواست نادرست تولید کند و «حد» را بسوزاند، کاهش می‌دهد.
کدام نوع پروکسی برای پارسینگ عامل انتخاب کنیم
نوع پروکسی به طور مستقیم بر این تأثیر می‌گذارد که چقدر اغلب عامل باید rotate_ip را فراخوانی کند و چند درخواست بدون مسدودیت عبور می‌کند. در زیر — مقایسه بر اساس وظایف مربوط به پارسینگ عامل.
| نوع پروکسی | کی باید عامل استفاده کند | مزایا | معایب |
|---|---|---|---|
| پروکسی‌های مسکونی | پارسینگ بازارها، وب‌سایت‌های با حفاظت ضد ربات (Wildberries، Ozon) | IPهای واقعی کاربران، درصد پایین مسدودیت | گران‌تر از دیتاسنترها، سرعت به گره بستگی دارد |
| پروکسی‌های موبایل | کار با شبکه‌های اجتماعی و پنل‌های تبلیغاتی درون فلو عامل | بیشترین اعتماد وب‌سایت‌ها، IP مانند اپراتور ارتباطی | هزینه بالاتر، سرعت چرخش محدود |
| پروکسی‌های دیتاسنتر | جمع‌آوری داده‌های انبوه از وب‌سایت‌ها بدون حفاظت سخت ضد ربات | سرعت بالا، قیمت پایین برای IP | به راحتی شناسایی می‌شوند، اغلب نیاز به چرخش از طریق عامل دارند |
در عمل، عامل می‌تواند انواع را ترکیب کند: جلسه را از طریق پروکسی‌های مسکونی برای «گرم کردن» شروع کند و برای دور زدن محدودیت نرخ به طور خالص به دیتاسنترها سوئیچ کند — اگر ابزار MCP اجازه دهد نوع IP را به عنوان پارامتر درخواست مشخص کند.
تنظیم گام به گام سرور MCP با چرخش پروکسی
بیایید یک مجموعه کاری حداقلی را در پایتون بررسی کنیم. سرور MCP دو ابزار را توصیف می‌کند: دریافت صفحه و تغییر IP از طریق API ارائه‌دهنده پروکسی.
from mcp.server.fastmcp import FastMCP
import httpx
mcp = FastMCP("proxy-parser-agent")
# ذخیره‌سازی جلسه فعلی پروکسی
current_session = {"proxy_url": None, "country": "ru"}
def get_new_proxy(country: str = "ru") -> str:
"""درخواست IP جدید از ارائه‌دهنده پروکسی از طریق API او"""
response = httpx.get(
"https://api.proxycove.com/v1/get-endpoint",
params={"country": country, "type": "residential"},
headers={"Authorization": "Bearer YOUR_API_KEY"},
)
data = response.json()
return f"http://{data['username']}:{data['password']}@{data['host']}:{data['port']}"
@mcp.tool()
def rotate_ip(country: str = "ru") -> str:
"""ابزار برای عامل: تغییر آدرس IP به جدید از کشور مشخص شده"""
current_session["proxy_url"] = get_new_proxy(country)
current_session["country"] = country
return f"IP به‌روزرسانی شد، منطقه: {country}"
@mcp.tool()
def fetch_page(url: str) -> dict:
"""ابزار برای عامل: دریافت صفحه از طریق پروکسی فعلی"""
if not current_session["proxy_url"]:
current_session["proxy_url"] = get_new_proxy(current_session["country"])
proxies = {"http://": current_session["proxy_url"], "https://": current_session["proxy_url"]}
try:
r = httpx.get(url, proxies=proxies, timeout=15)
return {"status_code": r.status_code, "content": r.text[:3000]}
except httpx.RequestError as e:
return {"status_code": 0, "error": str(e)}
if __name__ == "__main__":
mcp.run()
منطق ساده است: عامل fetch_page را فراخوانی می‌کند، در پاسخ status_code: 403 را می‌بیند و بر اساس آن خود تصمیم می‌گیرد که rotate_ip را فراخوانی کند. هیچ کد سختی برای «هر 10 درخواست IP را تغییر کن» وجود ندارد — مدل بر اساس پاسخ واقعی سرور هدایت می‌شود.
برای تولید، باید به این کد اضافه کنید: ثبت هر چرخش با زمان‌سنجی، محدود کردن تعداد چرخش‌ها در دقیقه (تا مدل در تغییر IP به جای حل مشکل واقعی «چرخه» نشود) و تایم‌اوت‌ها در سطح جلسه، تا IP «چسبنده» بیشتر از حد نیاز نگه داشته نشود.
ادغام با Claude، LangChain و AutoGPT
MCP در ابتدا به عنوان پروتکلی برای Claude Desktop و Claude API ترویج می‌شود، اما به لطف مشخصات باز، فریم‌ورک‌های خارجی نیز از آن پشتیبانی می‌کنند. اگر شما یک عامل را بر روی LangChain می‌سازید، سرور MCP از طریق آداپتور langchain-mcp-adapters متصل می‌شود، که ابزارهای MCP را به ابزارهای معمولی LangChain تبدیل می‌کند — عامل آنها را مانند هر تابع دیگری می‌بیند.
برای عوامل مشابه AutoGPT، که در آن پشتیبانی بومی از MCP وجود ندارد، می‌توان یک پل HTTP محلی راه‌اندازی کرد: سرور MCP به عنوان یک سرویس REST معمولی عمل می‌کند و عامل از طریق مکانیزم استاندارد خود به نام function calling به انتهای آن دسترسی پیدا می‌کند. این کمی کمتر زیبا است، اما گزینه‌ای کارآمد برای تیم‌هایی است که قبلاً به یک استک خاص وابسته شده‌اند.
به طور جداگانه باید در مورد ارتباط با مرورگرهای ضد شناسایی صحبت کرد. اگر پارسینگ از طریق درخواست‌های HTTP مستقیم انجام نشود، بلکه از طریق Chrome/Playwright headless (برای وب‌سایت‌های با حفاظت سنگین JS نیاز است)، سرور MCP می‌تواند نه تنها پروکسی را مدیریت کند، بلکه پروفایل مرورگر را نیز — ابزاری برای راه‌اندازی پروفایل در Dolphin Anty یا Octo Browser با پروکسی انتهایی متصل شده را به عامل منتقل کند. در این صورت، عامل فقط مشخص می‌کند که کدام پروفایل و کدام کشور را استفاده کند، و تمام قسمت‌های فنی پشت ابزار MCP پنهان است.
موارد عملی: Wildberries، Ozon، تحلیل SMM
نظارت بر قیمت‌ها در Wildberries. عامل یک لیست از 2000 SKU دریافت می‌کند، کارت‌های محصولات را مرور می‌کند، و در صورت دریافت کپچا یا پاسخ خالی، خود IP را از طریق پروکسی‌های مسکونی تغییر می‌دهد و درخواست را با تأخیر تکرار می‌کند. بر خلاف اسکریپت ثابت با چرخش ثابت، چنین مجموعه‌ای سرعت جمع‌آوری ثابتی را حتی در صورت تقویت حفاظت در سمت بازار حفظ می‌کند — عامل به سادگی «کندتر» به الگوهای مسدودیت واکنش نشان می‌دهد و فرکانس درخواست‌ها را کاهش می‌دهد به جای اینکه فقط IPها را تا زمانی که همه مسدود شوند، مرور کند.
جمع‌آوری داده‌ها از Ozon Seller API و رابط وب. در اینجا عامل دو حالت را ترکیب می‌کند: درخواست‌های مجاز به پنل کاربری از طریق IP «چسبنده» در طول روز کاری انجام می‌شود (تا دوباره دو مرحله‌ای را تحریک نکند)، در حالی که پارسینگ عمومی کارت‌های محصولات — از طریق چرخش در هر درخواست انجام می‌شود.
تحلیل SMM بر روی رقبا در Instagram و TikTok. عامل آمار عمومی (لایک‌ها، نظرات، دسترسی‌ها) را بر اساس لیست حساب‌های رقبا جمع‌آوری می‌کند و درخواست‌ها را از طریق پروکسی‌های موبایل توزیع می‌کند تا ترافیک معمولی کاربران اپلیکیشن را شبیه‌سازی کند، نه رباتی با IP دیتاسنتری.
در هر سه مورد، صرفه‌جویی در زمان تیم — نه در خود پارسینگ (که می‌توانست قبلاً خودکار شود)، بلکه در عدم نیاز به نوشتن و نگهداری منطق پیچیده دستی برای تلاش‌های مجدد، بک‌اف‌ها و قوانین چرخش است. عامل به طور خودکار به تغییر حفاظت وب‌سایت سازگار می‌شود، بدون نیاز به بازنویسی کد.
اشتباهات رایج در ارتباط عامل هوش مصنوعی و پروکسی
- چرخش بیش از حد. اگر به عامل اجازه دهید که IP را با هر بار تغییر کند، وب‌سایت ممکن است شروع به مسدود کردن کل دامنه زیرشبکه به دلیل سرعت غیرعادی تغییر آدرس‌ها با یک User-Agent کند.
- عدم پیوند کوکی‌ها به IP. اگر عامل IP را تغییر دهد، اما همچنان از کوکی‌های قدیمی جلسه استفاده کند، سیستم ضد ربات بلافاصله عدم تطابق موقعیت جغرافیایی و جلسه را شناسایی می‌کند.
- عدم وجود محدودیت بر تعداد چرخش‌ها. بدون محدودیت، مدل در چرخه خطاها می‌تواند تمام حد ترافیک را بر روی تلاش‌های بی‌فایده در صورت وجود مشکل سیستم (به عنوان مثال، وب‌سایت به طور کامل از کار افتاده است، نه اینکه یک IP خاص را مسدود کند) «بسوزاند».
- نادیده گرفتن فینگرپرینت TLS. تغییر IP بدون تغییر کلاینت HTTP کمک نمی‌کند، اگر وب‌سایت ربات‌ها را بر اساس امضای TLS handshake شناسایی کند — در اینجا نیاز به ارتباط با مرورگر headless است، نه فقط درخواست‌های httpx.
- دسترسی مستقیم عامل به «اعتبارات» خام پروکسی. با دادن دسترسی به مدل به نام کاربری/گذرواژه API پروکسی به طور مستقیم در پرامپت، شما خطر نشت اطلاعات در هنگام ثبت گفتگوها را دارید — از ابزار MCP به عنوان یک واسطه استفاده کنید.
نتیجه‌گیری
ارتباط عامل هوش مصنوعی با سرور MCP و API پروکسی منطق پارسینگ را تغییر می‌دهد: به جای قوانین سخت چرخش بر اساس تایمر، عامل تصمیم می‌گیرد که IP را بر اساس واقعیت مسدودیت تغییر دهد، جلسات «چسبنده» و یک‌باره را ترکیب می‌کند و خود را به وب‌سایت خاص بدون نیاز به بازنویسی کد تطبیق می‌دهد. این موضوع به ویژه در بازارهایی با حفاظت فعال ضد ربات — بازارها، شبکه‌های اجتماعی، پلتفرم‌های تبلیغاتی مشهود است.
برای پارسینگ بازارها و وب‌سایت‌های با حفاظت جدی، بهتر است از ابتدا در معماری پروکسی‌های مسکونی را در نظر بگیرید — آنها به عامل فضای بیشتری برای مانور بدون سوختن سریع IP می‌دهند. اگر وظیفه به شبکه‌های اجتماعی و اپلیکیشن‌های موبایل مربوط می‌شود، به پروکسی‌های موبایل توجه کنید — آنها کمتر باعث ایجاد شک و تردید در سیستم‌های ضد ربات می‌شوند. و برای جمع‌آوری داده‌های فنی انبوه از منابع کمتر محافظت شده، پروکسی‌های سریع و مقرون به صرفه دیتاسنتر مناسب هستند که عامل می‌تواند آنها را در ترکیب با IPهای مسکونی برای بهینه‌سازی بودجه استفاده کند.