درون سازوکار Opslane برای تبدیل رفتار کاربر به اصلاحات کد

تصور کنید خطای یک کاربر در مرورگر، بدون اینکه برنامه‌نویس حتی داشبورد خطاها را باز کند، مستقیماً به یک Pull Request تأییدشده تبدیل شود. این هسته‌ی مرکزی Opslane است که در ۲۷ اوت ۲۰۲۶ منتشر شد و با مشاهده‌ی نحوه‌ی تعامل واقعی انسان‌ها با اپلیکیشن، کل چرخه‌ی کشف، بررسی و رفع باگ را خودکار می‌کند.

بیشتر ابزارهای ردیابی خطا تنها زمانی هشدار می‌دهند که برنامه کرش کند. اما بسیاری از بدترین تجربه‌های کاربری — مثل دکمه‌ای که هیچ واکنشی نشان نمی‌دهد، فرمی که کاربران از پر کردن آن منصرف می‌شوند، یا منوی کشویی که پیش از موعد بسته می‌شود — هرگز خطای رسمی (Exception) تولید نمی‌کنند. Opslane با ضبط تمام جلسات، این باگ‌های ساکت را شناسایی کرده و آن‌ها را بر اساس تعداد کاربران آسیب‌دیده رتبه‌بندی می‌کند.

زمینه و زیرساخت

Opslane بر اساس فلسفه‌ی «عامل‌محور» (Agent-first) ساخته شده است. هدف این است که نیاز برنامه‌نویس به گشت‌وگذار دستی در داشبوردهای خطا حذف شود. به همین دلیل، این ابزار با یک سرور پروتکل زمینهٔ مدل (MCP) — شبیه به یک مترجم که ابزارهای مختلف را به زبان مدل‌های هوش مصنوعی ترجمه می‌کند — عرضه شده تا عامل‌های (Agents) کدنویس بتوانند خلاصه‌ها را استخراج کنند، گزارش‌های بررسی را بخوانند و باگ‌ها را مستقیماً از ترمینال رفع کنند. این رویکرد یادآور توانمندی‌های مدل Codex در رفع سریع باگ‌های Node.js با استفاده از پروتکل MCP است. سیستم با تحلیل هم‌زمان کدبیس و رفتار واقعی کاربران، محصول را می‌شناسد.

طبق مستندات این پروژه، زیرساخت آن برای میزبانی شخصی (Self-hosting) و سبک طراحی شده است. این سیستم تنها به یک فایل Docker Compose نیاز دارد. برای مدیریت وضعیت و صف پردازش از Postgres و برای ذخیره‌سازی سازگار با S3 برای ضبط‌های جلسات از MinIO استفاده می‌کند. در حال حاضر، این پلتفرم به‌طور کامل از اپلیکیشن‌های جاوااسکریپت پشتیبانی می‌کند.

اجزای سیستم

این سامانه از چهار بخش اصلی تشکیل شده است:

• Browser SDK: ثبت خطاها و ضبط جلسات در مرورگر کاربر. در این بخش، ماسک کردن ورودی‌ها (Input Masking) به‌طور پیش‌فرض فعال است تا حریم خصوصی حفظ شود.
• Ingestion service: دریافت داده‌های SDK، گروه‌بندی خطاها و رتبه‌بندی آن‌ها بر اساس میزان اثرگذاری بر کاربر.
• Worker: بررسی ریشه‌ای مسائل، نوشتن و تأیید اصلاحیه‌ها در یک محیط ایزوله (Sandbox) و در نهایت باز کردن Pull Requestها.
• Dashboard: یک اپلیکیشن وب برای مرور مسائل، تماشای بازپخش جلسات و مدیریت تنظیمات پروژه.

الزامات فنی

به گزارش توسعه‌دهندگان، برای اجرای کامل مسیر «بررسی و رفع»، سیستم به چهار اتصال کلیدی نیاز دارد:

• بررسی (Investigation): یک کلید ANTHROPIC_API_KEY برای موتور استدلال هوش مصنوعی.
• تأیید در محیط ایزوله: یک کلید E2B_API_KEY برای اجرای کد در یک محیط امن.
• Pull Requestها: اعتبارنامه‌های GitHub با دسترسی به مخزن هدف.
• احراز هویت: یک GitHub App یا WorkOS برای استقرار‌های ابری.

خط لوله‌ی رفع خودکار

فرآیند رفع خطا در این سیستم از یک توالی مشخص شامل «ثبت، گروه‌بندی، ارزیابی، بررسی، تأیید و تحویل» می‌گذرد. Browser SDK تنها با دو خط کد نصب، داده‌ها را به سرویس Ingestion ارسال می‌کند. سپس Opslane اثرات فشرده‌شده‌ی کد (Minified stack traces) را با استفاده از Source Maps به نام فایل‌های واقعی برمی‌گرداند و هر تکرار از یک باگ مشابه را در یک مسئله‌ی واحد گروه‌بندی می‌کند.

پس از گروه‌بندی، Opslane یک فیلتر ارزیابی (Qualification filter) را اعمال می‌کند. سیستم بررسی می‌کند که چه تعداد کاربر با این باگ مواجه شده‌اند و این اتفاق هر چند وقت یک‌بار رخ داده است. سپس مخزن کد را می‌خواند تا تصمیم بگیرد آیا این یک مشکل واقعی در محصول است یا خیر. تنها باگ‌هایی که از هر دو بررسی عبور کنند، مورد بررسی قرار می‌گیرند؛ سایر موارد صرفاً تحت نظارت می‌مانند.

جزئیات رفع مشکل

در مرحله‌ی نهایی، بخش Worker فرآیند چندمرحله‌ای زیر را اجرا می‌کند:

• بررسی: عامل هوش مصنوعی مخزن کد را کلون کرده و کدها را تا زمان یافتن علت ریشه‌ای می‌خواند.
• تأیید: اصلاحیه‌ی پیشنهادی در محیط ایزوله‌ی E2B اجرا می‌شود. این کار تضمین می‌کند که بیلد (Build) و تست‌ها با موفقیت پاس شوند؛ به گونه‌ای که هر آنچه پیش از اصلاحیه پاس می‌شد، همچنان پاس شود. استفاده از محیط‌های ایزوله برای اعتبارسنجی خروجی‌های AI، مشابه رویکرد Patchwright در کاهش نرخ خطای اسکرپرهای AI است. سپس یک مدل هوش مصنوعی دوم، تغییرات را بازبینی می‌کند.
• تحویل: اصلاحیه‌ی تأییدشده به صورت یک Pull Request در گیت‌هاب ارسال می‌شود. اگر تأیید اصلاحیه ممکن نباشد، سیستم دلیل دقیق را به صورت مکتوب ارائه داده و فراخوانی (Call) خاصی که برنامه‌نویس باید انجام دهد را مشخص می‌کند.

برای فعال‌سازی این قابلیت‌ها، Opslane با Anthropic برای استدلال در بررسی، E2B برای اجرای محیط ایزوله و GitHub برای کلون کردن و ارسال Pull Requestها ادغام شده است.

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

از منظر تجربه‌ی توسعه‌دهنده، این یک حرکت به سمت نگهداری خودکار (Autonomous Maintenance) است. با پیوند دادن مستقیم بازپخش جلسات به اصلاح کد، شکاف بین نارضایتی کاربر و حل فنی تقریباً از بین می‌رود.

استقرار محلی و تست

برنامه‌نویسان می‌توانند هم‌اکنون Opslane را برای اپلیکیشن‌های جاوااسکریپت مستقر کنند. برای شروع، کافی است مخزن گیت‌هاب را کلون کرده و استک را با Docker Compose v2 اجرا کنید. برای اجرای اولیه، نیازی به حساب کاربری یا کلیدهای API نیست.

کاربران می‌توانند نصب صحیح را با بررسی اندپوینت سلامت در آدرس http://localhost:8082/health تأیید کنند. برای تست خط لوله، می‌توان از اسکریپت scripts/seed-e2e.sql برای ایجاد یک پروژه آزمایشی استفاده کرد. سپس می‌توان یک خطای نمونه را از طریق درخواست POST به اندپوینت /api/v1/events ارسال کرد. برای مثال، ارسال یک ReferenceError با پیام "demo is not defined" به کاربر اجازه می‌دهد ببیند Opslane چگونه رویداد را ثبت کرده و Stack Trace را به فایل منبع نگاشت می‌کند.

این پروژه تحت مجوز AGPL-3.0 منتشر شده است، هرچند SDKهای مرورگر و پایتون و انواع مشترک (Shared Types) تحت مجوز MIT هستند. این ساختار به توسعه‌دهندگان اجازه می‌دهد SDKها را در اپلیکیشن‌های خود قرار دهند در حالی که زیرساخت اصلی عامل‌محور را حفظ می‌کنند.