خداحافظی با کدهای تکراری؛ اجرای خودکار ایجنت‌های مرورگر و دسکتاپ به SDK کلود آمد!

مدیریت خودکار حلقه‌های ایجنت مرورگر و دسکتاپ در SDK کلود

تا پیش از این، ساختن یک ایجنت مرورگر یا دسکتاپ با مدل‌های کلود (Claude) حسابی دردسر داشت؛ چون توسعه‌دهنده باید یک «حلقه کنترل» (Control Loop) سفارشی می‌نوشت. برنامه باید تک‌تک بلوک‌های tool_use را پردازش می‌کرد، آن‌ها را به اکشن‌های درایور تبدیل می‌کرد، نتیجه را در قالب tool_result برمی‌گرداند و این چرخه را آن‌قدر تکرار می‌کرد تا کلود دیگر درخواستی برای اجرای ابزار نداشته باشد.

حالا شرکت آنتروپیک (Anthropic) در SDKهای پایتون و تایپ‌اسکریپت خود، تمام این حلقه و رفت‌وآمدها را به کلاس‌های مرورگر و کامپیوتر سپرده است که جزییات کامل آن در مستندات رسمی تول‌ست‌ها (Toolset Docs) آمده است. این مجموعه‌ابزارها اکشن‌هایی مثل navigate (مسیریابی)، left_click (کلیک چپ) و type (تایپ متن) را که برای مدل قابل مشاهده هستند، یک‌جا بسته‌بندی می‌کنند. توسعه‌دهنده‌ها این اکشن‌ها را روی درایور اتوماسیون دلخواهشان پیاده‌سازی می‌کنند و بقیه کارها، یعنی هدایت فراخوانی‌ها، اجرای سیاست‌های تعریف‌شده، گرفتن تأییدیه‌ها و قالب‌بندی نتایج، خودکار به عهده SDK خواهد بود.

حلقه کنترل در دستان SDK؛ خداحافظی با کدهای تکراری

رانر جدید ابزار‌ها (Tool Runner) حالا تماس‌های کلود را پردازش می‌کند، آن‌ها را به متد مربوطه می‌فرستد، نتایج را ضمیمه کرده و گفت‌وگو را ادامه می‌دهد. البته کدهای برنامه شما همچنان مسئول مدیریت محیط مرورگر یا دسکتاپ، کنترل شبکه، چرخه حیات درایور و نحوه اجرای دقیق هر اکشن باقی می‌مانند.

برنامه‌ها با ارث‌بری از کلاس‌های BetaAbstractBrowserToolset20260801 یا BetaAbstractComputerToolset20260801 متدهای مورد نظر را پیاده‌سازی می‌کنند. تاریخ موجود در نام کلاس‌ها نسخه بتا این ابزار‌ها را مشخص می‌کند. در نظر داشته باشید که این SDK به خودی خود شامل مرورگر، محیط دسکتاپ، درایور یا لیست پیش‌فرض سایت‌های مجاز نیست.

• نمونه ساخته‌شده از این ابزار (Instance) مستقیماً درون آرایه tools درخواست قرار می‌گیرد.
• متدهایی که هنوز پیاده‌سازی نکرده‌اید، به صورت غیرفعال (Disabled) به API فرستاده می‌شوند.
• اگر کلود باز هم بخواهد متد غیرفعالی را فراخوانی کند، SDK با بازگرداندن خطا به مسیر اجرای خود ادامه می‌دهد.
• در صورت بروز خطا در یک فراخوانی، فراخوانی‌های بعدی همان تول‌ست در همان نوبت رد می‌شوند.
• رانر پس از اتمام اجرا تول‌ست را باز نگه می‌دارد تا برنامه بتواند درباره استفاده مجدد، همزمانی و پاک‌سازی منابع تصمیم بگیرد.
• با بازنویسی (Override) متد execute، می‌توانید قابلیت‌هایی مثل رهگیری (Tracing)، پنهان‌سازی داده‌های حساس (Redaction)، اعتبارسنجی یا بازنویسی ورودی را به تمام فراخوانی‌ها اضافه کنید.

اجرای مشتاقانه (Eager Calls)؛ تبادل تأخیر در ازای ریسک قطعیت

قابلیت «اجرای مشتاقانه» یا Eager Execution می‌تواند با آغاز اجرای ابزار پیش از اینکه استریم پاسخ کلود به پایان برسد، تأخیر زمانی (Latency) را به شکل محسوسی کاهش دهد. رانر پیش‌فرض تا پایان نوبت صبر می‌کند، اما برنامه‌های پایتون می‌توانند با تنظیم stream=True و run_tools_eagerly=True این قابلیت جذاب را فعال کنند.

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

انعطاف‌پذیری کامل در تعویض درایورها

تیم‌های فنی به راحتی می‌توانند این مجموعه‌ابزارها را به کرومیوم، پلی‌رایت (Playwright)، پروتکل CDP، VNC یا هر لایه اتوماسیون دسکتاپ دیگری متصل کنند. پلتفرم‌های محبوبی مثل Browser Use، Browserbase و E2B قبلاً یکپارچه‌سازی‌های خود را منتشر کرده‌اند و آنتروپیک در معرفی رسمی خود به Daytona نیز اشاره کرده است. علاوه بر این، آنتروپیک یک پروژه راهنمای سریع (Quickstart) با یک نمونه ساده بر پایه CDP منتشر کرده است.

در این نمونه ساده، اکشن‌های navigate، screenshot و left_click روی یک رپر سمت سرور پیاده‌سازی شده‌اند و متد _browser_state تب‌های باز و تغییرات اخیر را گزارش می‌دهد. یک آداپتور حداقلی برای دسکتاپ هم از همین ساختار تمیز پیروی می‌کند:

class MyDesktop(BetaAbstractComputerToolset20260801):
    def screenshot(self, context, input):
        return BetaScreenshotResult(
            data=self.display.png_base64(),
            media_type="image/png",
        )

    def left_click(self, context, input):
        self.display.click(input.coordinate, input.text)

    def type(self, context, input):
        self.display.type(input.text)

سیاست‌های امنیتی پشت مرز شبکه متوقف می‌شوند

کلاس مرورگر یک کال‌بک به نام url_policy برای بررسی آدرس قبل از هر مسیریابی صریح، یک file_policy برای دانلود و آپلود فایل‌ها، و یک کال‌بک confirm برای اکشن‌های نیازمند تأیید در اختیارتان می‌گذارد. رفتار پیش‌فرض این بخش نکات امنیتی مهمی به همراه دارد:

• بدون تعریف URL Policy، هیچ اعتبارسنجی روی آدرس‌ها توسط SDK انجام نمی‌شود و API آنتروپیک هم به خودی خود فیلتری روی لینک‌ها اعمال نمی‌کند.
• متدهای javascript_exec و file_upload به طور پیش‌فرض غیرفعال هستند.
• اگر هرکدام از این متدها را بدون تعریف کال‌بک confirm فعال کنید، در زمان ساخت کلاس با خطای پیکربندی مواجه خواهید شد.

اما داستان به همین‌جا ختم نمی‌شود؛ کال‌بک آدرس به‌تنهایی نمی‌تواند درخواست‌هایی را که با کلیک روی لینک‌ها، تغییر مسیرها (Redirects)، منابع داخلی صفحه یا عملکردهای داخلی مرورگر ارسال می‌شوند مهار کند. چنین درخواست‌هایی به راحتی ممکن است به آدرس‌های لوپ‌بک نظیر localhost و 127.0.0.1، رنج‌های شبکه خصوصی یا سرویس‌های محلی مانند اندپوینت متادیتای ابری 169.254.169.254 برسند. این مسأله یک ریسک جدی برای حملات جعل درخواست سمت سرور (SSRF) ایجاد می‌کند که می‌تواند سرویس‌های داخلی یا اطلاعات محرمانه را افشا کند.

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

از طرفی، ورودی‌های دسکتاپ حتی حساسیت بالاتری دارند؛ چرا که کنترل کیبورد می‌تواند روی هر برنامه‌ای که در حالت فوکوس باشد تأثیر بگذارد. تول‌ست کامپیوتری که از type، key یا hold_key استفاده می‌کند، به تأیید دستی (Confirm Callback) نیاز دارد، مگر اینکه این متدها غیرفعال شده باشند. در غیر این صورت، ترکیب ورودی کیبورد با یک ترمینال باز می‌تواند مستقیماً دستورات خطرناکی را تحت دسترسی اکانت ایجنت اجرا کند!

اجرای همزمان دو تول‌ست در یک نوبت

یک درخواست می‌تواند شامل نمونه‌های هر دو تول‌ست مرورگر و کامپیوتر به صورت همزمان باشد. هر فراخوانی با یک شناسه toolset_name مشخص می‌کند که متعلق به browser است یا computer تا رانر بتواند آن را بدون تداخل به نمونه متناظر تحویل دهد.

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

باگ‌های کمتر، مهاجرت ساده‌تر و سریع‌تر

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

از طرف دیگر، وجود یک اینترفیس مشترک باعث می‌شود درایورهای محلی و ابری ظاهر برنامه‌نویسی کاملاً یکسانی داشته باشند. به عنوان مثال، پروتوتایپی که روی Playwright محلی ساخته شده به آسانی به Browserbase منتقل می‌شود و یک ایجنت دسکتاپ نیز بدون تغییر منطق اصلی می‌تواند بین E2B و Daytona جابه‌جا شود. بدین ترتیب پرامپت‌ها، سیستم مسیردهی ابزارها، تأییدیه‌ها و هسته اصلی هوش ایجنت شما کاملاً دست‌نخورده و پایدار باقی می‌ماند.