تصور کنید یک عامل هوش مصنوعی را طراحی کرده‌اید که باید در یک پورتال قدیمی وب داده جمع کند، اما یک دیوار کپچا تمام پیشروی او را متوقف می‌کند. برای حل این مشکل، دیگر تولید یک توکن ساده کافی نیست، بلکه مدیریت کامل وضعیت مرورگر لازم است. اتوماسیون دور زدن چالش‌های کپچا دیگر تنها به تولید یک توکن محدود نمی‌شود؛ بلکه موضوع بر سر مدیریت کل وضعیت مرورگر است.
به گزارش Composio، ادغام این پلتفرم با CapSolver به توسعه‌دهندگان اجازه می‌دهد عامل‌هایی بسازند که توالی باز کردن صفحه، حل چالش و تأیید نتیجه را در یک اقدام واحد و اتمیک انجام دهند. این قابلیت در زمانی عرضه می‌شود که عامل‌های هوش مصنوعی (AI Agents) — شبیه به دستیاران دیجیتالی که می‌توانند به‌جای ما ابزارها را اجرا کنند — از فراخوانی‌های ساده API به سمت اتوماسیون‌های پیچیده مرورگر-محور حرکت می‌کنند. این روند تکامل عامل‌ها را به یاد رویکرد Oxlo.ai در اتوماسیون تحلیل ریشه‌ای حوادث SRE می‌اندازد که در آن عامل‌های چندوجهی وظایف پیچیده عملیاتی را بر عهده می‌گیرند. در حالی که بسیاری از ابزارها تنها یک توکن کپچا ارائه می‌دهند، آن‌ها اغلب عامل را در وضعیت بلاتکلیف رها می‌کنند، به‌طوری که مدل قادر نیست تأیید کند آیا توکن پذیرفته شده است یا فرم واقعاً ارسال شده است. این ادغام با در نظر گرفتن پاسخ واقعی صفحه به عنوان تنها شرط موفقیت، این شکاف را پر می‌کند.
معماری حل خودکار کپچا
این گردش‌کار بر یک پشته سه لایه استوار است. OpenAI Agents SDK به‌عنوان مغز عمل می‌کند، دستورات زبان طبیعی را درک کرده و تصمیم می‌گیرد چه زمانی یک ابزار فراخوانی شود. این استفاده از SDKهای پیشرفته OpenAI در راستای استراتژی جدید این شرکت برای تبدیل ابزارهای اختصاصی به عمومی است تا توسعه‌دهندگان دسترسی بهتری به قابلیت‌های امنیتی و اتوماسیون داشته باشند. Composio نقش ثبت‌کننده را دارد و توابع استاندارد پایتون را به ابزارهای قابل‌فراخوانی برای عامل تبدیل می‌کند. در نهایت، Playwright — ابزاری برای کنترل مرورگر که مثل یک کاربر واقعی کلیک می‌کند و می‌خواند — کارهای سخت اتوماسیون، از جمله باز کردن صفحات، اعمال نتایج و خواندن وضعیت نهایی صفحه را بر عهده می‌گیرد.
مسئولیت هر بخش در این خط لوله به شرح زیر است:
- OpenAI Agents SDK: درک دستورات زبان طبیعی، تصمیم‌گیری برای فراخوانی ابزار، اجرای آن و سازماندهی پاسخ نهایی.
- Composio: ثبت یک تابع پایتون استاندارد به‌عنوان ابزاری که توسط عامل قابل فراخوانی باشد.
- Playwright: باز کردن صفحه، اعمال نتیجه حل شده، ارسال فرم و خواندن وضعیت نهایی صفحه برای تأیید.
- CapSolver SDK: بازگرداندن نتیجه کپچا از طریق یک فراخوانی ساده و واحد
solve().
در مورد reCAPTCHA v2، فرآیند طبق مستندات فنی یک توالی سخت‌گیرانه را دنبال می‌کند: ابتدا Playwright آدرس URL هدف را باز می‌کند. سپس CapSolver SDK یک توکن gRecaptchaResponse را از طریق یک فراخوانی solve() با استفاده از نوع ReCaptchaV2TaskProxyLess برمی‌گرداند. عامل سپس این توکن را مستقیماً در ناحیه متنی g-recaptcha-response با استفاده از یک فراخوانی JavaScript page.evaluate تزریق می‌کند. در نهایت، ابزار روی دکمه ارسال (مثلاً #recaptcha-demo-submit) کلیک کرده و منتظر وضعیت بارگذاری networkidle می‌ماند.
نکته حیاتی این است که ابزار تنها به دلیل دریافت یک توکن، موفقیت را گزارش نمی‌کند. بلکه محتوای HTML حاصل را می‌خواند و تنها در صورتی پیام موفقیت را برمی‌گرداند که عبارت "Verification Success" در صفحه ظاهر شود. ابزار در نهایت یک شیء JSON شامل {"accepted": ..., "message": ...} را به عامل بازمی‌گرداند.
جزئیات پیاده‌سازی فنی
برای راه‌اندازی این محیط، توسعه‌دهندگان باید چندین وابستگی کلیدی را نصب کنند:
composio: برای ایجاد جلسات (sessions) و ثبت ابزارهای سفارشی.composio-openai-agents: برای تبدیل ابزارهای Composio به اشیایی که با OpenAI Agents سازگار باشند.openai-agents: برای فراهم کردنAgent،RunnerوSQLiteSessionجهت مدیریت حافظه در گفتگوهای چند مرحله‌ای.capsolver: SDK رسمی برای حل چالش‌ها از طریق متدsolve().pydantic: برای تعریف طرح‌واره (schema) ورودی ابزار.playwright: موتور اتوماسیون مرورگر (که نیازمند اجرای دستورplaywright install chromiumاست).
پیکربندی این سیستم نیازمند مدیریت دقیق متغیرهای محیطی است. کلید OPENAI_API_KEY باید در محیط سیستم (environment) نوشته شود زیرا SDK آن را از آنجا می‌خواند. همچنین از OpenAIAgentsProvider استفاده می‌شود تا اطمینان حاصل شود ابزارهای بازگشتی از session.tools() با کلاس Agent سازگار هستند.
پیکربندی ابزار و طرح‌واره
پلتفرم Composio یک طرح ورودی سخت‌گیرانه را می‌طلبد که از طریق BaseModel در Pydantic تعریف می‌شود. برای گردش‌کار reCAPTCHA v2، کلاس CompleteRecaptchaInput متغیرهای target_url (که به طور پیش‌فرض روی دموی گوگل تنظیم شده) و website_key (مثلاً 6Le-wvkSAAAAAPBMRTvw0Q4Muexq9bi0DJwx_mJ-) را تعریف می‌کند.
این ابزار با دکوراتور @composio.experimental.tool(preload=True) ثبت می‌شود. در پیاده‌سازی از یک بلوک try...finally استفاده شده است تا اطمینان حاصل شود مرورگر در هر دو مسیر موفقیت یا شکست بسته می‌شود. سپس عامل با یک مدل خاص (مثلاً gpt-5.2) و دستوراتی برای فراخوانی ابزار با مقادیر پیش‌فرض و گزارش موفقیت تنها در صورتی که accepted برابر با true باشد، مقداردهی اولیه می‌شود.
مدیریت کپچاهای تصویری
همین الگو برای چالش‌های تبدیل تصویر به متن (Image-to-Text)، مانند آنچه در دموی BotDetect CAPTCHA یافت می‌شود، به کار می‌رود. در این سناریو، عامل ابتدا باید المان تصویر کپچا (مثلاً #demoCaptcha_CaptchaImage) را مکان‌یابی کرده و منبع آن را به صورت یک رشته Base64 استخراج کند.
مکانیزم استخراج تصویر
فرآیند کپچاهای تصویری شامل این مراحل دقیق است:
- مکان‌یابی المان: Playwright منتظر می‌ماند تا
#demoCaptcha_CaptchaImageقابل مشاهده شود. - استخراج منبع: متد
get_attribute("src")آدرس URL داده را بازیابی می‌کند. - پاک‌سازی Base64: اسکریپت پیشوند
data:image/...;base64,را با تقسیم رشته در اولین کاما و برداشتن بخش دوم حذف می‌کند. - اعتبارسنجی: اگر هیچ URL داده معتبری یافت نشود، یک خطای
RuntimeErrorصادر می‌شود.
پس از ثبت تصویر، آن را به ImageToTextTask در CapSolver می‌فرستند. برخلاف وظایف مبتنی بر توکن، این مدل متن شناسایی شده را مستقیماً برمی‌گرداند و نیازی به حلقه نظارتی (polling loop) جداگانه ندارد. سپس عامل فیلد ورودی (مثلاً #captchaCode) را پر کرده و روی دکمه تایید (مثلاً #validateCaptchaButton) کلیک می‌کند و برای تایید نهایی، کلمه "Correct!" را جست‌وجو می‌کند.
مکانیزم‌های بازشناسی تصویر
توسعه‌دهندگان می‌توانند با انتخاب مدل‌های بازشناسی خاص از طریق پارامتر module این فرآیند را بهینه کنند:
- Common Module: تنظیم پیش‌فرض برای کپچاهای تصویری عمومی.
- Number Module: زمانی استفاده می‌شود که کپچا فقط شامل اعداد باشد. این مدل از چندین تصویر در یک ارسال پشتیبانی می‌کند و اجازه می‌دهد تا ۹ رشته Base64 در آرایه
imagesقرار گیرد. - مدل‌های مستقل: برای استایل‌های خاص، می‌توان از مدل‌های مستقل مستند شده در صورت لزوم استفاده کرد.
برای بازشناسی اعداد، فراخوانی solve به گونه‌ای تغییر می‌کند که از module: "number" استفاده کرده و تصویر را در یک لیست images ارسال کند، که نتیجه را در فیلد answers برمی‌گرداند.
تله‌های بحرانی در ادغام
دو خطای رایج در این استقرارها وجود دارد که اغلب باعث توقف پروژه می‌شوند. اول، ValidationError است که به دلیل نبود یادداشت‌های (annotations) Pydantic رخ می‌دهد. Composio طرح ورودی را از نوع اولین پارامتر استخراج می‌کند. اگر اولین پارامتر ابزاری مانند complete_recaptcha_v2 با یک زیرکلاس Pydantic BaseModel علامت‌گذاری نشده باشد، Composio خطایی برمی‌گرداند مبنی بر اینکه <class 'inspect._empty'> دریافت کرده است. این یک الزام عملکردی است، نه یک راهنمای نوع اختیاری.
دوم، خطای 403 APIKey_InsufficientPermissions است. این اتفاق زمانی می‌افتد که یک کلید API در Composio دسترسی فقط-خواندنی (read-only) داشته باشد اما اسکریپت بخواهد از طریق composio.sessions.create() یک جلسه ایجاد کند. خطا به طور مشخص اشاره می‌کند که این مسیر به دسترسی write برای "sessions" نیاز دارد.
برای حل این مشکل، توسعه‌دهندگان باید:
- داشبورد Composio را باز کنند.
- به تنظیمات API Keys برای پروژه مربوطه بروند.
- دسترسی sessions کلید را از "read" به "write" تغییر دهند یا یک کلید جدید با دسترسی‌های صحیح ایجاد کنند.
تحلیل: تغییر پارادایم اتوماسیون
این ادغام تمرکز را از «حل یک پازل» به «تکمیل یک فرآیند تجاری» تغییر می‌دهد. با بسته‌بندی حلقه «حل-ارسال-تأیید» در یک ابزار واحد، تعداد دفعاتی که مدل زبانی (LLM) باید پاسخ دهد (Turns) کاهش می‌یابد، که این امر باعث کاهش تأخیر و کم شدن احتمال توهم (Hallucination) در گزارش نتیجه می‌شود. این بهینه‌سازی در مدیریت توکن‌ها و پاسخ‌ها، مشابه تلاش‌هایی است که Oxlo.ai برای حذف هزینه‌های پنجره زمینه در مدل‌های زبانی انجام داده تا بهره‌وری مدل‌ها را افزایش دهد.
برای توسعه‌دهندگان، این یعنی عامل‌ها اکنون می‌توانند با پورتال‌های قدیمی وب که API ندارند اما توسط کپچاهای ساده محافظت شده‌اند، تعامل کنند. البته این قدرت ریسک نقض شرایط خدمات (ToS) سایت‌ها را افزایش می‌دهد. تغییر به سمت اتوماسیون تأییدشده بر اساس وضعیت صفحه، عامل‌ها را قابل‌اعتمادتر می‌کند، اما آن‌ها را به ابزارهایی قدرتمندتر برای استخراج غیرمجاز داده‌ها تبدیل می‌کند، مگر اینکه توسط منطق مجوزدهی سخت‌گیرانه کنترل شوند.
دستورالعمل‌های اخلاقی و عملیاتی
توانایی فنی به معنای اجازه دسترسی به داده‌های خصوصی، محدود یا غیرمجاز نیست. این گردش‌کار باید تنها برای اتوماسیون‌های قانونی، معقول و مورد تایید کاربر استفاده شود. توسعه‌دهندگان باید:
- از متغیرهای محیطی یا مدیریت‌کننده‌های رمز (secret managers) برای تمام کلیدهای API استفاده کنند.
- به شرایط سایت، محدودیت‌های نرخ درخواست (rate limits) و الزامات به حداقل رساندن داده‌ها احترام بگذارند.
- زمانی که صفحه به وضعیت تجاری مورد انتظار نرسید، فرآیند را متوقف کنند.
- به جای تلاش مجدد بی‌پایان، علت شکست‌های مکرر را بررسی کنند.
برای پیاده‌سازی این سیستم، شما نیاز به نصب composio ،composio-openai-agents ،capsolver و playwright دارید. اطمینان حاصل کنید که OPENAI_API_KEY در متغیرهای محیطی تنظیم شده است. برای کسانی که به دنبال افزایش بودجه اتوماسیون خود هستند، CapSolver کد تخفیف CAP26 را برای دریافت ۵٪ پاداش اضافی در شارژهای داشبورد ارائه می‌دهد.
گام بعدی شما
- نصب کتابخانه‌های
composioوcapsolverو پیکربندیOPENAI_API_KEYدر متغیرهای محیطی. - تعریف دقیق طرح ورودی ابزارها با استفاده از Pydantic برای جلوگیری از خطاهای ValidationError.
- بررسی دسترسی‌های Write در داشبورد Composio برای کلیدهای API جهت ایجاد جلسات فعال.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو