منتشر شده: ۲۲ ژوئن ۲۰۲۶
P2ER ، یک آژانس راهکارهای دیجیتال، از Chrome DevTools برای عاملها استفاده میکند تا اطمینان حاصل کند که فقط نرمافزارهای تأیید شده و کارآمد برای بررسی نهایی به انسانها تحویل داده میشوند. آنها با تبدیل گردش کار خود به یک زیرساخت عاملمحور، به عاملهای هوش مصنوعی این قدرت را دادهاند که تأیید رابط کاربری تجربی را انجام دهند و فرکانس استقرار را از یک بار در هفته به چندین بار در روز افزایش دهند.
چالش: مقیاسپذیری کیفیت در برنامههای موجود
P2ER تجربیات دیجیتالی سطح بالایی را برای برندهای جهانی، از جمله تولیدکنندگان خودرو، برندهای ساعت و شرکتهای مهماننوازی، ارائه میدهد. چالش اصلی آنها، مانند بسیاری از شرکتها، کار در برنامههای کاربردی پیچیده و موجود بود. همانطور که تیم، کدگذاری عاملی را اتخاذ میکرد، با سه مانع عمده روبرو شدند:
- تست رابط کاربری شکننده. مجموعههای تست استاندارد با دادههای پویا، مانند نوسان قیمت هتلها یا پیشنهادات فصلی در برخی از پروژههای P2ER، مشکل داشتند. دادههای ساختگی اغلب نقصهای ادغام را پنهان میکردند که یک تستر انسانی بلافاصله آنها را پیدا میکرد.
- مشکلات مربوط به قابلیت اطمینان عامل. بدون دستورالعملهای صریح، عاملهای هوش مصنوعی گاهی اوقات ادعا میکردند که یک کار بدون تأیید واقعی آن، کامل شده است.
- از دست دادن زمینه. وظایف گسترده و وقفههای مدل باعث میشد که عاملها اهداف جلسه را از دست بدهند. این امر ردیابی و ادامه کاری را که یک عامل شروع کرده بود، برای توسعهدهندگان دشوار میکرد.
راه حل: ایجاد زیرساخت برای صنایع دستی
P2ER زیرساختی ایجاد کرده است که هوش مصنوعی را به عنوان یک "شریک رقابتی" در نظر میگیرد که میتواند جنبههای تکراری توسعه را نیز مدیریت کند. این رویکرد به تیم اجازه میدهد تا با تمرکز بر معماری و حل خلاقانه مسئله، مهارت خود را ارتقا دهد.
تأیید تجربی را با DevTools برای سرور MCP عاملها اعمال کنید
برای اطمینان از قابلیت اطمینان، P2ER یک قانون تأیید تجربی اجباری وضع کرد. این الزام مهندسی که در فایل AGENTS.md پروژه مدون شده است، بیان میکند:
All claims regarding service availability and component rendering
MUST be empirically verified (log output, dev compiler, browser/devtools inspection)
before asserting to the user.
این تیم به جای اینکه حرف نماینده را باور کند، از Chrome DevTools برای نمایندهها استفاده میکند تا محیطی امن برای پیمایش بصری و تعاملی در برنامه فراهم کند.
این «عوامل تست» چندین وظیفه کلیدی را انجام میدهند که تستهای استاتیک استاندارد از آنها غافل هستند:
- آزمایش پویای دادهها: حتی در یک محیط آزمایشی، عاملها (agents) دادههای واقعی و متغیر (مانند تغییر قیمت هتلها در طول فصلها) را آزمایش میکنند تا برنامه را دقیقاً مانند یک کاربر تجربه کنند. این قابلیت توسط DevTools برای ابزارهای تعاملی عاملها مانند
new_page،navigate_page،fill،clickوhoverکه در مهارتgithub-issue-testفراخوانی میشوند، فعال شده است و به عامل اجازه میدهد تا به صورت پویا یک مسیر کلیک واقعی کاربر را تأیید و شبیهسازی کند. - ممیزیهای بصری: نمایندگان، اختلافات بصری بین طرحبندیهای فیگما و پیادهسازی واقعی را شناسایی میکنند. با استفاده از ابزار
take_screenshotاز DevTools برای نمایندگان، مهارتfigma-validateآنها، تصاویر با وضوح بالا از رندرهای زنده Storybook را ضبط میکند تا مقایسهای پهلو به پهلو با خروجیهای فیگما انجام دهد. - بررسیهای کاربردپذیری: عاملها، ترجمههای از دست رفته یا خطاهای کاربردپذیری را که اسکریپتهای خودکار اغلب نادیده میگیرند، شناسایی میکنند. با تعامل مستقیم با درخت دسترسی و بررسی اسنپشاتهای بصری، که از طریق
take_snapshotوtake_screenshotبازیابی میشوند، عاملها به طور فعال ناهنجاریهای رابط کاربری مانند رشتههای MISSING_MESSAGE را همانطور که به صراحت در گردشهای کاری تأیید خودکار آنها دستور داده شده است، اسکن میکنند.
تجزیه و حفظ زیروظایف
برای مقابله با وقفههای زمانی نشست و از دست رفتن اطلاعات، P2ER کار را از طریق عاملهای فرعی به شدت بخشبندی میکند. سپس آنها به عاملهای خود دستور میدهند که به عنوان هماهنگکننده مانند این عمل کنند:
Rather than executing everything in the main thread, you must decompose large
or complex objectives into modular subtasks that can be delegated
to specialized subagents.
برای اینکه صاحبان محصولات انسانی در این فرآیند مطلع باشند، تیم یک مهارت سفارشی برای عاملها (agent) تعبیه کرد تا کار خود را در مسائل گیتهاب (GitHub Issues) پیگیری کنند. این امر تضمین میکند که هر وظیفه زیرعامل و نتایج آن به عنوان یک زیرمسئله با استفاده از API گیتهاب (GitHub API) ثبت و مستندسازی میشود و یک مسیر حسابرسی واضح و زمینهای پایدار ایجاد میکند که سایر توسعهدهندگان میتوانند آن را دریافت کنند.
محیطهای ایزوله برای اجرای موازی
برای مقیاسبندی فرآیند توسعه خود به گونهای که چندین عامل به صورت موازی کد را اجرا کنند، P2ER محیطهای ایزولهای را برای هر وظیفه برای عوامل خود الزامی میکند. این امر از تداخل وضعیتها و مشکلات شبکه در طول تأیید رابط کاربری جلوگیری میکند.
تنظیمات فنی برای این جداسازی شامل موارد زیر است:
- درختهای کاری مجزای گیت: برای جلوگیری از تصادم فایلها و آلودگی فضای کاری هنگام کار موازی چندین عامل، وظایف در درختهای کاری مجزای گیت اجرا میشوند. هر عامل یک فضای سیستم فایل اختصاصی دریافت میکند که در آن متغیرهای محیطی کپی میشوند و وابستگیها به هم پیوند داده میشوند، و تضمین میشود که تغییرات فایل هرگز روی یکدیگر بازنویسی نمیشوند.
- محیطهای منحصر به فرد: هر عامل و وظیفه، سرور توسعه Next.js خود را روی یک پورت ایزوله منحصر به فرد اجرا میکند. طبق قوانین پروژه آنها، سرورها به صورت پویا با
npx next dev -p <custom_port> --turbopackشروع میشوند تا اجرای موازی بدون تداخل شبکه تضمین شود. - کلونهای پایگاه داده: برای جلوگیری از تصادم دادهها در طول آزمایش موازی، P2ER به صورت برنامهنویسیشده، پایگاه داده اصلی را در هنگام راهاندازی عامل، در یک طرحواره مختص به وظیفه کپی میکند. پس از اینکه عامل تأیید خود را تکمیل کرد و وظیفه تأیید شد، یک فرآیند پاکسازی خودکار، پایگاه داده ایزوله را حذف میکند. این چرخه حیات تضمین میکند که هر عامل در یک فضای کاری بکر فعالیت میکند و هیچ داده معلقی را پشت سر نمیگذارد.
- تست هدفمند: تمام تستهای مرورگر از طریق Chrome DevTools برای عاملها باید دقیقاً پورت سفارشی اختصاص داده شده به آن نمونه عامل خاص را هدف قرار دهند. دستورالعمل تست آنها، کدگذاری سخت پورتهای پیشفرض را ممنوع میکند و نیاز به URLهای هدف تست مانند
http://localhost:<custom_port>دارد.
تأثیر: افزایش ۱۰ برابری سرعت توسعه در عین حفظ کیفیت
تغییر به کدنویسی عاملمحور با محافظهای با قابلیت اطمینان بالا، خروجی P2ER را متحول کرد. این تغییرات در ابتدا برای اطمینان از عملکرد قابل اعتماد عامل ضروری بودند، اما به کل چرخه عمر توسعه نیز سود رساندند:
- چرخههای کاری ۱۰ برابر سریعتر: اکثر مشکلات اکنون در عرض یک روز بسته میشوند، در مقایسه با میانگین ۱ تا ۳ روز قبلی. فرکانس استقرار از یک بار در هفته به چندین بار در روز افزایش یافته است.
- تمرکز استراتژیک برای تیمهای تضمین کیفیت : از آنجا که اکنون عاملها رگرسیونهای اولیه و «میوههای دمدستی» را تشخیص میدهند، تیم آزمایش انسانی میتواند روی سناریوهای آزمایش عمیقتر و پیچیدهتر تمرکز کند.
- پیادهسازیهای قوی برای ذینفعان: پیادهسازیها اکنون انعطافپذیرتر هستند زیرا آزمایش فراتر از «مسیر شاد» استاندارد برنامهنویس حرکت میکند.
- ارتباط واضحتر و قابلیت ردیابی: با اجرای قانون «از مشکل انسانی تا زیرمسئله پیادهسازی»، ذینفعان به جای خواندن تیکتهای پر از جزئیات پیادهسازی فنی و نحوه آزمایش آنها، دستورالعملهای روشنی در مورد بهبودهای منطقی انجام شده دریافت میکنند.
به عنوان مثالی از چگونگی تأثیر این موضوع بر سرعت توسعه، P2ER پلتفرم جدیدی را در عرض شش ماه ساخت که با روشهای تثبیتشدهی آنها سالها طول میکشید. نیروی انسانی همچنان دروازهی کیفیت نهایی است و درخواستهای Pull را که قبلاً توسط عوامل تأیید شدهاند، بررسی میکند.
بینشهای فنی برای تیمها
P2ER هنگام ساخت این گردش کار، چندین استراتژی را شناسایی کرد که به آنها کمک کرد تا از آزمایش به یک مدل توسعه بالغ و با کمک عامل (agent-assisted development model) گذار کنند.
این استراتژیها میتوانند به تیمهای دیگر کمک کنند تا پیادهسازیهای عاملمحور خود را اصلاح کنند:
بهینهسازی استفاده از توکن با تزریق اسکریپت و دستهبندی CLI
اگر عاملها صرفاً به پیمایش گام به گام (مثلاً گرفتن اسنپشات، یافتن شناسه، پر کردن ورودی و انتظار) تکیه کنند، سرورهای MCP میتوانند در طول جلسات توسعه طولانی، توکن-محور شوند. برای به حداقل رساندن این سربار، P2ER از یک رویکرد دو جانبه استفاده میکند:
- تزریق اسکریپت درونخطی: برای تعاملات هدفمند، مانند احراز هویت از طریق فرمهای پیچیده React، عاملها از ابزار
evaluate_scriptبرای تزریق مستقیم جاوا اسکریپت معمولی به مرورگر استفاده میکنند. این کار، overrideهای داخلی setter را دور میزند و چندین عمل را همزمان اجرا میکند و در نتیجه، از تعداد زیادی نوبت مکالمه جلوگیری میکند. - دستهبندی اسکریپتهای CLI: وقتی عاملها به یک «مانع» برمیخورند یا با یک جریان مرورگر بسیار طولانی و تکراری مواجه میشوند، به یک جایگزین دستهبندی CLI روی میآورند. به جای صرف توکنها برای ابزارهای MCP تکراری و منفرد یا نوشتن اسکریپتهای اتوماسیون سفارشی از ابتدا، P2ER رابط خط فرمان DevTools کروم را وادار میکند تا اقدامات مرورگر را ادامه داده و دستهبندی کند. این به عاملها اجازه میدهد تا به صورت برنامهنویسی، کل جریانهای چند مرحلهای را به صورت یکجا اجرا کنند و سربار ارتباط مداوم مدل با ابزار را به شدت کاهش دهند.
خودکارسازی ردیابی عملکرد با استفاده از تحلیل ردیابی
P2ER به جای تکیه صرف بر ادراک انسانی، یک مهارت review-performance ایجاد کرد که از DevTools برای عاملها استفاده میکند تا ممیزیهای خودکار Lighthouse و ردیابی عملکرد را اجرا کنند.
نمایندگان از ابزارهای performance_start_trace و performance_analyze_insight برای ثبت و بررسی Core Web Vitals (LCP، INP، CLS) و شناسایی گلوگاههای اصلی نخ یا تغییرات طرحبندی استفاده میکنند. برای تکمیل دروازه کیفیت، نمایندگان میتوانند یک lighthouse_audit کامل را اجرا کنند تا به طور خاص از پسرفت در دسترسیپذیری (a11y)، سئو و بهترین شیوههای کلی وب جلوگیری کنند و اطمینان حاصل کنند که فقط کد با کیفیت بالا برای درخواست Pull ارسال میشود.
بهبود تأیید با Chrome DevTools برای نمایندگان
علاوه بر مهارتهای سفارشی خود، P2ER از قابلیتهای اصلی Chrome DevTools برای سرورهای MCP agent برای انجام تأیید عملکرد استفاده میکند. این شامل استفاده از سرور برای شبیهسازی دستگاههای مختلف و آزمایش پاسخگویی و اطمینان از عملکرد رابط کاربری در اندازهها و دستگاههای مختلف صفحه نمایش میشود.
با استفاده از سرور MCP برای پیمایش برنامه، عاملها میتوانند اختلافات بصری بین طرحبندیها و پیادهسازی واقعی را شناسایی کنند و خطاهایی را که تستهای استاتیک اغلب نادیده میگیرند، شناسایی کنند.
منابع
برای بررسی بیشتر موارد استفاده P2ER، تمام مهارتهای ذکر شده را در مخزن گیتهاب مربوطه بررسی کنید.
برای شروع کار و کسب اطلاعات بیشتر در مورد پیادهسازی گردشهای کاری مشابه با DevTools برای نمایندگان، این منابع را بررسی کنید: