تصور کنید سیستمی دارید که اسکرپرهای وب خراب را بدون نیاز به بررسی دستی کدهای HTML تعمیر میکند. این همان Patchwright است؛ یک سامانه عاملمحور (Agentic) — شبیه به کارمندی که نه تنها مشکل را میبیند، بلکه خودش دست به آچار شده و ابزار را تعمیر میکند — که در هکاتون گوگل با عنوان All Things Agentic طراحی شده تا هیچ کد تولیدشده توسط هوش مصنوعی را بدون اثبات ریاضی در یک محیط ایزوله (Sandbox)، مستقر نکند.
استخراج داده از وب یا اسکرپینگ بهشدت شکننده است چون ساختار سایتها بدون اطلاع قبلی تغییر میکند. برای سازنده Aroppo (سایتی که فرصتهای شغلی برای تولیدکنندگان محتوا را تجمیع میکند)، این موضوع به معنای مدیریت ۱۹ اسکرپر بود که در یک بازه زمانی کوتاه دو هفتهای، ۷۴۴ بار عملیات واکشی (Fetch) را در ۳۸۰ اجرای جذب داده انجام داده بودند. وقتی یک انتخابگر (Selector) میشکند، دادهها اغلب بهطور خاموش به صفر میرسند یا بدتر از آن، اطلاعات نادرست ثبت میشوند؛ وضعیتی که برنامهنویسان را مجبور میکند تمام بعدازظهر خود را صرف دیباگ کردن کدهای خام HTML کنند. در این میان، وبمسترهای بسیاری نیز در تلاشاند تا دسترسیهای هوش مصنوعی به دادههای وب را از طریق استانداردهایی مانند robots.txt مدیریت کنند تا تعادلی میان دسترسی و حریم خصوصی ایجاد شود.
در حالی که اسکرپرهای خودترمیمشونده در بازار به صورت تجاری وجود دارند، Patchwright روی «شکاف اعتماد» تمرکز کرده است. اکثر ابزارهای موجود این موضوع را نادیده میگیرند که چگونه میتوان تأیید کرد یک اسکرپر بازنویسیشده واقعاً درست عمل میکند. Patchwright این مشکل را با استفاده از یک سایت جعلی به نام Fauxpost بهعنوان موتور اعتبارسنجی حل کرده است.
مکانیزم اعتبارسنجی
نوآوری اصلی این ابزار در استفاده از دادههای ثابت است. Fauxpost دارای ۱۲ رکورد دائمی است؛ وقتی ساختار سایت «میشکند»، کد فقط قالب (Template) را تغییر میدهد و هرگز به آن ۱۲ رکورد دست نمیزند. این یک آزمون دوتایی (Binary Test) ایجاد میکند: آیا خروجی اسکرپر با آن ۱۲ رکورد اصلی که صفحه از روی آنها ساخته شده، دقیقاً مطابقت دارد یا خیر؟
به نقل از مستندات پروژه، چون دادههای مرجع (Ground Truth) نمیتوانند تغییر کنند یا دچار رانش شوند، هیچ نیازی به نگهداری فایلهای تست (Fixture) نیست و راهی برای فریب دادن سیستم اعتبارسنجی وجود ندارد. هر پچی که ۱۲ رکورد خوشساخت اما اشتباه برگرداند، فوراً رد میشود چون «اشتباه بودن» در برابر چیزی که تکان نمیخورد، کاملاً قابل اندازهگیری است. تمام تضمینهای دیگر در این پروژه بر پایه همین یک تصمیم طراحی استوار است.
پشته فنی (Technical Stack)
این سامانه از یک معماری چندمدلی برای جداسازی اجرا از نظارت استفاده میکند و روی یک سرور ساده Node بدون هیچگونه فریمورک اجرا میشود:
- Gemini 3.7 Flash: تشخیص اولیه خرابی و بازنویسی کد متعاقب آن را بر عهده دارد.
- Gemma 4: بهعنوان بازبین مستقل عمل کرده و گزارشی کوتاه درباره تغییرات اعمال شده و ریسکهای مرتبط با آنها مینویسد.
- Google Agent Development Kit: منطق عاملهای مبتنی بر جاوااسکریپت را هدایت میکند.
- Cloud Run & Firestore: مدیریت میزبانی و ذخیره وضعیت (State Persistence) را بر عهده دارند.
- سقف هزینه (Spending Cap): یک محدودیت سختگیرانه برای سیستم تعریف شده است تا اطمینان حاصل شود که یک حلقه تکرار خارج از کنترل، منجر به صورتحسابهای نجومی نشود.
درسهایی در پرامپتنویسی و منطق
توسعه این ابزار نشان داد که حتی نامگذاریها بهعنوان پرامپت عمل میکنند. برنامهنویس یکی از عاملها را s3_diagnose نامید و این باعث شد مدل تصور کند با سرویس Amazon S3 طرف است. در نتیجه، مدل با اطمینان کامل تشخیص داد که مشکل از دسترسیهای Bucket است، در حالی که خرابی هیچ ربطی به فضای ذخیرهسازی نداشت.
مانع دیگر، بودجه توکن (Token) بود. مدل Gemini 3.7 قبل از پاسخ دادن، توکنهای زیادی را صرف «تفکر» (Thinking) میکند. چون سقف خروجی (Output Budget) بیش از حد پایین تنظیم شده بود، پاسخها در وسط کلمات قطع میشدند. در ابتدا تصور میشد این یک باگ در سریالسازی دادههاست، اما بعد مشخص شد که یک خطای پیکربندی است.
حل مسئله سندباکس
ایمنسازی کدهای تولیدشده توسط AI سختترین چالش مهندسی بود. محیط ساده node:vm به تنهایی کافی نبود چون متغیرهای سراسری (Globals) را نشت میداد و برخی خطاها باعث کرش کردن کل پروسه اصلی میشد. بهطور مشخص، پچی که سعی میکرد یک ماژول Node را وارد (Import) کند، بهجای اینکه در سندباکس خطا دهد، در پروسه اصلی خطا میداد که میتوانست کل سرویس را از کار بیندازد. این چالشها با ضعف مدلهای زبانی در رعایت قراردادهای بازگشتی (Rollback) هنگام تولید اسکریپتها همسو است که ریسکهای عملیاتی کدهای تولیدشده توسط AI را افزایش میدهد.
برای جلوگیری از اینکه هوش مصنوعی حلقههای بینهایت ایجاد کند یا تماسهای شبکه غیرمجاز برای «بررسی» چیزی برقرار کند، یک سندباکس دو لایه پیاده شد:
- لایه اول: یک پروسه مجزا که هیچ چیزی از پروسه والد به ارث نمیبرد.
- لایه دوم: یک محیط
vmداخل آن پروسه که تمام دسترسیها از آن گرفته شده و فقط به یک لیست سفید (Allowlist) ثابت دسترسی دارد.
برنامهنویس متوجه شد که هیچکدام از این لایهها به تنهایی کافی نیستند و این موضوع را تنها زمانی کشف کرد که سعی کرد بهطور دستی از سندباکس فرار کند.
واقعیتهای محیط عملیاتی
استقرار سیستم باگهایی را آشکار کرد که بیش از ۱۰۰ تست شبیهسازیشده (Mock) نتوانسته بودند پیدا کنند، زیرا تستهای Mock مدلها را شبیهسازی میکنند و هرگز با سرویسهای واقعی ابری تماس نمیگیرند. برای مثال، Cloud Logging کلمه severity را برای تعیین سطح یک ورودی لاگ رزرو کرده است. چون عامل Patchwright از همین کلمه برای توصیف شدت خرابی اسکرپر استفاده میکرد، هر تعمیر موفق بهطور اشتباه بهعنوان یک خطای «CRITICAL» ثبت میشد.
سایر مشکلات عملیاتی شامل موارد زیر بود:
- Race Conditions: رویدادها بهطور همزمان نوشته میشدند و بر سر یک شماره توالی (Sequence Number) رقابت میکردند. این موضوع باعث میشد حدود نیمی از آنها بهطور خاموش حذف شوند تا زمانی که سیستم شمارهگذاری به یک تراکنش (Transaction) واقعی تبدیل شد.
- پایداری مدل: فریمورک در ابتدا از پذیرفتن مدل Gemma با نامش امتناع میکرد. علاوه بر این، مدل کوچکتر Gemma در مواجهه با فرمتهای خروجی سختگیرانه دچار تکرار میشد و نیاز بود برای دریافت پاسخهای تمیز، از مدل بزرگتر استفاده شود.
حلقه بازبین
حیاتیترین ویژگی ایمنی، عامل «بازبین» است. با استفاده از خانواده مدل متفاوت (Gemma) نسبت به نویسنده (Gemini)، سیستم تضمین میکند که نویسنده کار خودش را بازبینی نکند. این بازبین گزارشی انسانی از تغییرات، نقاطی که کد در آنها منعطفتر شده و مواردی که ریسک آنها افزایش یافته است، ارائه میدهد.
این فرآیند بهصورت مشورتی (Advisory) طراحی شده است. نقطه انتهایی (Endpoint) تأیید، گزارش بازبین را نمیخواند؛ به این معنی که دکمه «تأیید» حتی اگر بازبین کند باشد، با محدودیت نرخ (Rate-limit) مواجه شود یا اصلاً حضور نداشته باشد، همچنان کار میکند. چون این بخش روی لایه رایگان اجرا میشود، هیچ هزینهای اضافه نمیکند اما یک نظر دوم حیاتی در لحظه تأیید انسانی فراهم میکند.
تحلیل نهایی
بررسی نتایج نشان داد انتخاب مدل بسیار مهمتر از تنظیم پرامپت (Prompt Tuning) است. مهاجرت از Gemini 3.5 به 3.7 زمان تعمیر را نصف کرد و دستههای کاملی از خطاها را حذف کرد. برنامهنویس به این نتیجه رسید که تنظیم مدل برای رسیدن به «صفر خطا» صرفاً به مدل یاد میدهد که «نویز» تولید کند.
جالب اینجاست که AI بهندرت در تشخیص مشکل شکست خورد؛ هر بار که بررسی شد، تشخیص درست بود. شکستهای اصلی مربوط به خطاهای کوچک سینتکسی در کد تولیدشده بود. این تغییر در درک مسئله به این معناست که نسخههای آینده Patchwright بهجای تلاش برای ساخت یک تشخیصدهنده 똑똑تر، روی یک مرحله اختصاصی برای تعمیر سینتکس تمرکز خواهند کرد.
گام بعدی شما
- اگر از اسکرپرهای وب استفاده میکنید، ساختار «دادههای ثابت» را برای اعتبارسنجی خروجیهای AI در پروژههای خود پیاده کنید.
- برای کاهش توهمات در کدهای تولیدشده، از معماری دو-مدلی (یک مدل برای تولید و یکی برای بازبینی) استفاده کنید.
- در نامگذاری عاملهای AI، از کلمات کلیدی مربوط به سرویسهای ابری (مثل S3 یا Blob) پرهیز کنید تا مدل دچار سوگیری نشود.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو