Sentinel: استخراج جریان‌های تجاری از طریق تحلیل کد منبع

یک مهندس تست (QA) خبره، کار خود را با کلیک روی دکمه‌ها شروع نمی‌کند، بلکه ابتدا روح محصول را می‌شناسند. سنتینل (Sentinel)، یک عامل (Agent) متن‌باز که در ۱۶ ژوئیه ۲۰۲۶ توسط سیمب‌استک (Simbastack) منتشر شد، دقیقاً همین فلسفه انسانی را پیاده می‌کند. سنتینل با مطالعه کامل یک مخزن کد (Codebase) برای درک منطق تجاری، پیش از آنکه حتی یک بار مرورگر را باز کند، از رویکرد متخصصان تقلید می‌کند. این ابزار تحت لایسنس MIT در دسترس قرار گرفته است.

اکثر عامل‌های هوش مصنوعی فعلی شبیه به تست‌های دوده‌ای (Smoke Tests) ساده عمل می‌کنند؛ آن‌ها صفحه‌ای را باز می‌کنند، یک المان جابه‌جا شده یا یک خطای کنسول می‌بینند و اعلام می‌کنند که اجرا به پایان رسیده است. چنین ابزارهایی از مدل ذهنی دقیقی درباره اینکه محصول واقعاً چه کاری انجام می‌دهد، تهی هستند. در مقابل، سنتینل با تحلیل ریپازیتوری، این مدل ذهنی را می‌سازد تا جریان‌های حیاتی — مانند چرخه حیات رزرو در یک سیستم هتلداری یا خط لوله استرداد وجه در سیستم‌های پرداخت — را شناسایی کند.

این تغییر رویکرد از «کلیک‌های کورکورانه» به «استدلال آگاه از کد» (Code-aware reasoning)، شکافی مزمن در تست‌های عاملی را برطرف می‌کند. در حالی که ابزارهای مبتنی بر UI فقط بررسی می‌کنند که آیا یک دکمه ظاهر مناسبی دارد یا خیر، سنتینل تایید می‌کند که آیا داده‌ها واقعاً در سرور ذخیره شده‌اند یا نه. یک مهندس QA استخدام شده می‌داند که نباید فقط یک کلیک را تست کند، بلکه باید رزروهای گروهی، کنسلی‌هایی که اتاق را آزاد می‌کنند و حسابرسی شبانه (Night Audit) را بررسی کرده و هر تغییر وضعیت را در بک‌اند تایید نماید. این رویکرد دقیق استدلالی، پاسخی به چالش‌هایی است که در پروژه Loupe برای شناسایی باگ‌های خاموش در کدهای AI مورد بررسی قرار گرفته بود.

معماری موتور جریان (Flow Engine)

این سامانه به عنوان یک خط لوله قطعی (Deterministic Pipeline) عمل می‌کند تا از کندی و تصادفی بودنِ خزش‌های گسترده در تک‌مخزن (Monorepo) جلوگیری کند. فرآیند با یک مرحله شناسایی سریع (Recon) با استفاده از دستورات grep و find آغاز می‌شود — بدون اینکه هیچ فراخوانی مدل هوش مصنوعی صورت گیرد — تا مسیرهای فرانت‌اند، ماژول‌های مسیر API، سرویس‌ها و موجودیت‌های پایگاه‌داده استخراج شوند. این خلاصه (Digest)، به عنوان زیربنای استدلال هوش مصنوعی عمل می‌کند و اجازه می‌دهد هر پشته JS رایج، از جمله مسیرهای Next.js، ماژول‌های Express و Fastify، و طرح‌های SQL مانند Prisma, Drizzle یا SQL ساده را پشتیبانی کند.

در گام بعد، مدل Mimo (از طریق چارچوب pi agent) این خلاصه را به لیستی اولویت‌بندی شده از جریان‌های تجاری پایان‌به-پایان (End-to-End) تبدیل می‌کند. هر جریان شامل گام‌های مشخص UI، تاییدیه های بک‌اند و موارد خاص (Edge Cases) است. برای کاهش هزینه‌ها و زمان، این برنامه برای هر کامیت (Commit) کش می‌شود و تنها در صورت تغییر کد، دوباره استخراج می‌گردد.

اجرا در یک حلقه عاملی صورت می‌گیرد که در آن مدل تصمیم می‌گیرد اقدام بعدی چه باشد و پلی‌رایت (Playwright) مرورگر را هدایت می‌کند. نکته کلیدی این است که سنتینل از یک ابزار درجه اول به نام api_request استفاده می‌کند تا در هر مرحله، وضعیت سرور را با بازپخش هدرهای احراز هویت (Authorization headers) خودِ فرانت‌اند بررسی کند. مدل تنها به ابزارهای مرورگر و API دسترسی دارد و هرگز نمی‌تواند به شل (Shell) یا سیستم فایل شما نفوذ کند. برای جلوگیری از حلقه‌های بی‌نهایت، یک بودجه سخت تعیین شده است: پس از ۹۰ فراخوانی ابزار، ابزارهای عملیاتی از پاسخدهی خودداری می‌کنند و عامل باید اجرا را به پایان برساند.

برای مدیریت ماهیت غیرقطعی مدل‌های زبانی بزرگ (LLM)، سنتینل به‌صورت پیش‌فرض هر جریان را دو بار اجرا می‌کند (این مورد توسط پیچ تنظیم FLOW_ATTEMPTS کنترل می‌شود). اگر یک تلاش هیچ باگی نیابد و تلاش دوم پنج مورد را شناسایی کند، گزارش نهایی تمام یافته‌ها را ادغام می‌کند تا بحرانی‌ترین شکست‌ها ثبت شوند. هر جریان، بدترین حکم (Verdict) خود را در میان تمام تلاش‌ها حفظ می‌کند.

ارزیابی بصری و طراحی

فراتر از جریان‌های عملکردی، سنتینل یک لایه بررسی طراحی انجام می‌دهد. هر صفحه مجزایی که بازدید شده است (که بر اساس URL حذف تکرار شده و محدودیت پیش‌فرض ۸ صفحه در هر اجرا دارد)، توسط یک مدل چندوجهی (Multimodal) مورد بررسی قرار می‌گیرد. این لایه مواردی را شکار می‌کند که بررسی‌های مبتنی بر DOM نمی‌توانند ببینند:

• مشکلات سلسله‌مراتب بصری و فاصله‌گذاری
• متونی که احتمالاً استانداردهای کنتراست WCAG را نقض می‌کنند
• خطاهای تایپوگرافی
• وضعیت‌های بصری شکسته یا ناقص

در حالی که Mimo-v2.5-pro مدیریت متن را بر عهده دارد، سیستم برای این فراخوانی‌های بصری از mimo-v2-omni از طریق یک API سازگار با OpenAI استفاده می‌کند. چون omni یک مدل استدلالی (Reasoning Model) است، بودجه توکن آن به ۶۰۰۰ توکن حداکثری افزایش یافته تا از قطع شدن پاسخ پیش از صدور حکم JSON جلوگیری شود. در هر فراخوانی، یک اسکرین‌شات با استفاده از رویکرد One-shot که بر اساس یک دستورالعمل (Rubric) امتیازدهی شده است ارسال می‌شود؛ این روش نیاز به یک چارچوب عاملی (Agent Harness) را از بین می‌برد.

عملکرد واقعی: سیستم مدیریت هتل (PMS)

در تست روی KaribuKit (سیستم مدیریت هتل سیمب‌استک)، به سنتینل تنها دسترسی به ریپازیتوری و اعتبارنامه‌های ادمین برای یک مستاجر (Tenant) آزمایشی و موقت داده شد. هیچ برنامه تست یا دستوری ارائه نشد. عامل کد را خواند، نتیجه گرفت که محصول یک PMS برای هتل‌های بوتیک و سفاری است و ۹ جریان حیاتی را استخراج کرد:

• چرخه کامل رزرو
• رزروهای گروهی
• خط لوله تبدیل لید (Lead) به پیشنهاد (Proposal)
• مدیریت نرخ‌ها
• خدمات خودکار مهمان
• تغییر اتاق در حین اقامت
• حسابرسی شبانه (Night Audit)
• پرداخت از فاکتور تا استرداد وجه
• کمک‌خلبان هوش مصنوعی

مواردی مانند کنسلی‌ها نیز تست شدند، اگرچه آن‌ها به عنوان موارد خاص (Edge cases) و بررسی‌های بک‌اند در جریان‌های دیگر گنجانده شدند.

در یک اجرا، عامل با پیام «اتاقی در دسترس نیست» (No rooms available) در رزرویی مواجه شد که در واقع اتاقی داشت. با بررسی هم‌زمان API و UI، مشخص شد که تقویم اتاق را موجود نشان می‌دهد در حالی که یک رزرو وجود داشت. این یک باگ ماشین-وضعیت (State-machine) در بک‌اند بود که در آن API و UI با هم ناسازگاری داشتند؛ شکستی که تنها با بررسی هر دو لایه قابل شناسایی است. در برخی تلاش‌ها، این باگ باعث نمایش پیام گمراه‌کننده می‌شد و در برخی دیگر، هیچ بازخوردی نمی‌داد.

ردپای عامل نشان‌دهنده یک فرآیند عیب‌یابی شبیه به انسان است. او GET /api/availability را فراخوانی کرد، خطای ۴۰۰ گرفت، نتیجه گرفت که پارامترها ناقص است و با adults=2&children=0 تلاش مجدد کرد تا پاسخ ۲۰۰ را دریافت کند. او با موفقیت یک رزرو را از طریق POST /api/reservations ایجاد کرد (کد ۲۰۱)، تایید کرد که با اتاق و نرخ درست ذخیره شده است و سپس چرخه وضعیت را ردیابی کرد. در جستجوی نقطه ورود check-in، ابتدا /checkin (خطای ۴۰۴) و سپس /check-in (خطای ۴۰۰) را آزمود تا در نهایت مسیر درست را یافت. او وضعیت فولیو (Folio) را بررسی کرد: سه شب هزینه اتاق با مبلغ ۱۷۸ دلار، با مانده بدهی ۵۳۴ دلار. همچنین یک باگ بحرانی در انتقال وضعیت را شکار کرد: عملیات check-in پاسخ ۲۰۰ داد، اما وضعیت registrationStatus مهمان در سرور همچنان NONE باقی ماند.

حل چالش کیف‌پول‌ها در Web3

سنتینل چالش اپلیکیشن‌های گیت‌شده با MetaMask یا Rabby را نیز حل کرده است. چون عامل‌های بدون سر (Headless) نمی‌توانند با پاپ-آپ‌های افزونه مرورگر تعامل کنند، سنتینل پیش از بارگذاری صفحه، پیاده‌سازی خاص خود از رابط window.ethereum (یا اعلان‌های EIP-6963) را تزریق می‌کند. این پیاده‌سازی توسط یک کلید خصوصی موقت (Throwaway private key) که در محیط Node نگهداری می‌شود پشتیبانی می‌گردد، به این معنی که کلید هرگز وارد صفحه وب نمی‌شود.

برای جلوگیری از ضرر مالی در شبکه‌های اصلی، سنتینل از یک کیف‌پول یک‌بارمصرف (Burner Wallet) با کنترل‌های سخت استفاده می‌کند:

• کیف‌پول‌های بدون موجودی: کیف‌پول‌ها تازه تولید شده و هیچ سرمایه‌ای ندارند. بررسی اولیه موجودی با یک سیستم «بسته‌شده در صورت شکست» (Fail-closed) جایگزین شد، زیرا پیش از این، شکست‌های خاموش در 조회 موجودی به عنوان پرداخت موفق تلقی می‌شدند.
• پخش Fail-Closed: هیچ متدی که تراکنشی را ارسال (Submit) می‌کند به شبکه فوروارد نمی‌شود. این مورد از طریق نام متد مسدود شده است.
• لیست سفید سخت‌گیرانه: تنها متدهای صریحاً خواندنی (Read-only) مجاز هستند؛ هر نوع متغیر ارسال (Send) ناشناخته فوراً رد می‌شود.
• چرخه عمر کلید: اگر کلیدی حتی برای یک تراکنش استفاده شود، کل اجرا متوقف می‌گردد.

در تست یک صرافی پرپچوال (Perpetuals)، عامل با موانع ادغامی متعددی روبرو شد. او نیاز به یک بوت سفارشی برای راه‌اندازی و تخریب (Boot and Teardown) داشت که کل درخت فرآیند را پاک کند تا از مرگ سرور توسعه جلوگیری شود. همچنین برای رفع خطاهای ۴۰۰ ناشی از ارسال فرم‌های خالی، از یک بازنویسی تزریق داده (Hydration-safe retype) استفاده کرد تا مطمئن شود فرم‌های ورود پس از Hydration در React پر شده‌اند. همچنین برای دور زدن هدرهای CORS معیوب ('*,*') در RPC عمومی که باعث ۷۱ هزار خطای کنسول و ۳۵ هزار درخواست شکست‌خورده در یک اجرای قبلی شده بود، فراخوانی‌ها را از طریق Node مسیریابی کرد.

علاوه بر این، تیم مجبور شد یک لایه پوششی (Overlay) تمام‌صفحه را که به دلیل ID پروژه پیش‌فرض در یک SDK کیف‌پول ایجاد شده بود حذف کند، زیرا این لایه تمام کلیک‌های عامل را می‌بلعید. پس از تثبیت، عامل در یک نشست ۶۱ مرحله‌ای، ۹ باگ عملکردی را با هزینه تنها ۰.۲۸ دلار یافت؛ از جمله:

• دکمه «Open Position» که ۸ ثانیه معلق می‌ماند و هیچ مدال تأییدی نمایش نمی‌داد.
• نبود پیش‌نمایش سفارش پس از وارد کردن وثیقه (Collateral).
• فقدان کامل کنترل لغزش (Slippage) در رابط کاربری.
• یک بررسی موجودی که اجازه مقدار ۹۹۹,۹۹۹ را بدون اعتبارسنجی می‌داد.
• قطع شدن اتصال کیف‌پول هنگام تغییر حالت مارجین (Margin modes).
• لغزنده‌ی اهرمی (Leverage slider) که به‌جای برچسب، ID داخلی خود (slider-ex-2) را نمایش می‌داد.
• اعتبارسنجی ناقص برای مقادیر منفی.

تکامل تکرار شونده: نسخه ۱ تا ۳

موتور جریان فعلی حاصل سه نسخه متمایز است. نسخه اول یک حلقه قطعی Node بود. اسکریپت، جریان کنترل را در اختیار داشت و Mimo را به عنوان یک مغز تک‌مرحله‌ای (One-shot) بدون ابزار، در هر گام (ورودی DOM، خروجی یک اقدام بعدی) فراخوانی می‌کرد. این روش برای اپلیکیشن‌های کوچک جستجوی محصول کار می‌کرد — مثلاً قیمت‌های ناقص مانند "₹4,19" را در اجراهایی با هزینه بسیار اندک (۰.۰۰۴۴ دلار) شناسایی می‌کرد — اما حافظه نداشت و نمی‌توانست سیاق (Context) کافی برای تست جریان‌های طولانی‌تر جمع کند.

نسخه دوم، با نام pi-native، کنترل را به مدل منتقل کرد. این نسخه ابزارهای مرورگر مبتنی بر Playwright را به عنوان یک افزونه pi ثبت کرد و به Mimo اجازه داد تا آن‌ها را در حلقه عاملی خود pi با حافظه کامل نشست هدایت کند. این امر امکان کاوش عمیق‌تر در یک هدف واحد را فراهم کرد، اما اهداف هنوز باید به صورت دستی نوشته می‌شدند.

نسخه سوم، همان موتور جریانی است که در اینجا توصیف شد و با خواندن ریپازیتوری برای استخراج خودکار جریان‌ها، دشواری دستیِ هدف‌گذاری را حذف کرده است.

اقتصاد و اکوسیستم QA مستمر

هزینه، یک محدودیت اصلی در طراحی است. Mimo به‌دلیل ارزان بودن برای اجراهای حجیم — بازبینی هر کامیت در تمام ریپازیتوری‌ها — انتخاب شده است. یک تصمیم Mimo کسری از یک سنت هزینه دارد. یک اجرای سبک QA چند سنت و یک اجرای عمیق (مثل هتل PMS) برای ۳۶۴ گام، ۱.۹۵ دلار هزینه داشت.

مدل‌های دیگر در مواردی که دقت بر قیمت اولویت دارد، استفاده می‌شوند. Claude برای ویرایش‌های جراحی Markdown در عامل‌های همگام‌ساز مستندات (Docs-sync) و مغز (Brain-sync) به کار می‌رود. Codex (بر روی gpt-5.5) به عنوان یک موتور بازبینی فقط-خواندنی اختیاری برای نظرات ثانویه عمیق‌تر اما کندتر عمل می‌کند.

سنتینل بخشی از یک ناوگان چهار عاملی است:

1. عامل QA: همان موتور جریانی که در اینجا شرح داده شد.
2. عامل بررسی کد (Code-Review): هر Diff جدید را می‌خواند.
3. عامل همگام‌ساز مستندات (Docs-Sync): فایل‌های Markdown را با کد هماهنگ نگه می‌دارد.
4. عامل همگام‌ساز مغز (Brain-Sync): تغییرات ریپو را در یک پایگاه دانش مشترک تیمی تلخیص می‌کند.

عامل‌هایی که کد می‌نویسند در محیط‌های ایزوله (Worktrees) عمل کرده و PR باز می‌کنند؛ آن‌ها هرگز تغییرات خود را مستقیماً ادغام (Merge) نمی‌کنند. کل این پشته برای «ساده» و شفاف بودن طراحی شده و از حدود ۲۵۰۰ خط Bash، Node و TypeScript تشکیل شده است. هیچ پایگاه داده اختصاصی وجود ندارد؛ سیستم از طریق یک زمان‌بند launchd هر ۱۵ دقیقه برای بررسی به‌روزرسانی‌های ریپوزیتوری‌ها اجرا می‌شود و اجرای کامل QA هر ۱۲ یا ۲۴ ساعت یک‌بار رخ می‌دهد.

محدودیت‌ها و راه‌اندازی

با وجود قدرت زیاد، سیستم مرزهایی دارد. اکتشاف‌ها غیرقطعی هستند، به همین دلیل جریان‌ها چندین بار اجرا می‌شوند. راه‌اندازی پشته‌های پیچیده نیاز به تنظیمات خاص برای پورت‌ها، احراز هویت و دیتابیس‌های تست دارد. در وب۳، عامل تا لحظه تسویه (Settlement) تست می‌کند اما تراکنش‌ها را روی یک فورک محلی anvil (Foundry) اجرا نمی‌کند، زیرا بلوک پخش (Broadcast block) فعال باقی می‌ماند. در واقع، تکمیل یک معامله روی فورک قابلیتی است که هنوز ساخته نشده است.

برای تست سنتینل، کاربران می‌توانند ریپازیتوری را از github.com/Simbastack-hq/sentinel کلون کرده، وابستگی‌ها را نصب و فایل targets.json را پیکربندی کنند. سیستم به CLI ابزار pi نیاز دارد. اگرچه Mimo پیش‌فرض است، اما کاربران می‌توانند مدل‌ها را از طریق متغیرهای QA_PROVIDER ،QA_MODEL و VISION_* تغییر دهند تا از هر نقطه پایانی سازگار با OpenAI، از جمله OpenRouter یا مدل‌های محلی استفاده کنند. دستور bin/sentinel doctor قطعات گم‌شده را شناسایی می‌کند. پوشه examples/ شامل ریجستری‌های هدف آماده برای کپی است، از جمله نمونه dApp کیف‌پول وب۳.

گام بعدی شما

• اگر پروژه بزرگی با منطق پیچیده دارید، به جای نوشتن تست‌های دستی، سنتینل را روی یک محیط ایزوله اجرا کنید تا جریان‌های پنهانی که فراموش کرده‌اید را استخراج کند.
• برای کاهش هزینه‌های استنتاج، مدل‌های کوچک‌تر را برای شناسایی اولیه و مدل‌های reasoning را برای تایید نهایی باگ‌ها تنظیم کنید.
• اگر در حوزه Web3 فعالیت می‌کنید، پیاده‌سازی window.ethereum در این ابزار را برای اتوماسیون تست‌های کیف‌پول بررسی کنید.

اما نحوه مدیریت حافظه در این حجم از تحلیل کدها داستانی پیچیده‌تر دارد؛ به بررسی ما درباره زبان bet برای مدیریت حافظه اختصاصی مراجعه کنید.