اگر هر روز برای جذب مشتری جدید در فضای B2B تلاش نمی‌کنید، احتمالاً بخش بزرگی از فرصت‌های رشد خود را از دست می‌دهید. مشکل اینجاست که تکیه به نظم انسانی در این فرآیند، معمولاً با شکست مواجه می‌شود. اشتباهات انسانی اغلب منجر به از دست رفتن پنجره‌های زمانی مناسب برای ارتباط با مشتریان می‌شود.
این چالش، هسته اصلی ایجاد پروتکل فانتوم (Phantom Protocol) است؛ سامانه‌ای که شکاف «تداوم» را در جذب مشتری می‌بندد. یک توسعه‌دهنده این پروژه را برای پل زدن بر روی این شکاف در اکتساب مشتری B2B منتشر کرده است. این سیستم عامل‌محور (Agentic) — شبیه به داشتن یک تیم کوچک از کارمندان مجازی است که هر کدام وظیفه مشخصی دارند و بدون نظارت شما، زنجیره کار را پیش می‌برند — تمام مسیر از کشف سرنخ (Lead) تا مدیریت پاسخ‌ها را خودکار می‌کند و به‌طور مؤثر عناصری را که مانع رشد می‌شوند، حذف می‌کند.
مسئله: شکاف تداوم
این پروژه از یک تجربه شخصی و دشواری در جذب مشتریe آغاز شد. توسعه‌دهنده متوجه شد که بازاریابی مستقیم (Outreach) تنها در صورتی نتیجه می‌دهد که هر روز، بدون استثنا، انجام شود. با این حال، اجرای دستی این فرآیند غیرقابل اعتماد بود. برخی روزها هیچ سرنخی یافت نمی‌شد؛ روزهای دیگر، سرنخ‌ها شناسایی می‌شدند اما پیام‌ها ارسال نمی‌شدند. در موارد دیگر، به‌دلیل اولویت‌های متقاطع و مشغله‌های دیگر، پنجره زمانی ارسال به‌طور کامل از دست می‌رفت.
او این مسئله را نه به عنوان یک مشکل انگیزشی، بلکه به عنوان یک مشکل «تداوم» شناسایی کرد. توسعه‌دهنده意识到 کرد که نمی‌توان برای اجرای دستی و روزانه این فرآیند به خودش اعتماد کند. این درک منجر به خلق سیستمی شد که می‌توانست به‌صورت مستمر، به‌موقع و هر روز این کار را انجام دهد.
اکثر ابزارهای فعلی بازاریابی، کاربران را مجبور می‌کنند تا خدمات مجزا را برای یافتن لیدها، غنی‌سازی داده‌ها و ارسال ایمیل‌ها به هم بچسبانند. این پراکندگی باعث ایجاد یک بار نگهداری می‌شود که در آن کاربر همچنان به عنوان «چسب» برای متصل نگه داشتن ابزارها عمل می‌کند. پروتکل فانتوم با بستن کل این حلقه در یک خط لوله مستقل و خودگردان، نیاز کاربر به مدیریت عملیاتی فرآیند را به‌طور کامل از بین می‌برد.
طبق مستندات پروژه که در ۸ ژوئیه ۲۰۲۶ منتشر شد، این سیستم به عنوان مجموعه‌ای از عامل‌های تخصصی عمل می‌کند که با یکدیگر ارتباط مستقیم ندارند. در عوض، آن‌ها داده‌ها را در یک پایگاه‌داده ماتگو‌دی‌بی (MongoDB) می‌خوانند و می‌نویسند، در حالی که بال-ام‌کیو (BullMQ) صف وظایف را مدیریت می‌کند تا اطمینان حاصل شود که هیچ سرنخی در حین ری‌استارت شدن سیستم گم نمی‌شود.
گردش کار عامل‌محور
پروتکل فانتوم از یک معماری چندعاملی استفاده می‌کند که در آن هر عامل تنها یک وظیفه شفاف دارد و نه بیشتر:
- استراتژیست (Strategist): رویکرد کلی کمپین را طراحی و تعیین می‌کند.
- شکارچی (Hunter): به دنبال شرکت‌هایی می‌گردد که با پروفایل هدف مطابقت دارند.
- پژوهشگر (Researcher): در هر شرکت تحقیق می‌کند تا مخاطب مناسب را بیابد و زمینه (Context) کامل شرکت را استخراج کند.
- ارسال‌کننده (Outreacher): یک ایمیل شخصی‌سازی شده می‌نویسد و آن را ارسال می‌کند.
- مدیریت پاسخ (Reply Handler): صندوق ورودی را زیر نظر می‌گیرد و تعیین می‌کند که یک پاسخ در واقع چه معنایی دارد.
- عامل یادگیرنده (Learning Agent): به‌طور دوره‌ای نتایج را بازبینی کرده و استراتژی را بر اساس آنچه در واقعیت جواب داده است، اصلاح می‌کند.
پیاده‌سازی فنی و زیرساخت
این سیستم بر بستر مدل Qwen3.7 و از طریق API سرویس DashScope شرکت علی‌بابا کلاود اجرا می‌شود. بسته به اینکه هر وظیفه خاص به چه میزان استدلال (Reasoning) نیاز دارد، از سطوح مختلف مدل استفاده می‌شود.
برای تضمین کیفیت داده‌ها، توسعه‌دهنده در ابتدا تلاش کرد تا داده‌ها را مستقیماً از دایرکتوری‌های تجاری استخراج (Scrape) کند. این روش شکست خورد زیرا داده‌ها ناسازگار بودند و به‌جای تولید لیدهای واجد شرایط، نویز تولید می‌کردند. در نتیجه، توسعه‌دهنده مسیر خود را تغییر داد و از Hunter.io به عنوان یک تامین‌کننده داده مناسب برای یافتن مخاطبان استفاده کرد.
استقرار (Deployment) سیستم یک مانع فنی بزرگ بود. نویسنده به‌جای استفاده از پلتفرم‌های مدیریت‌شده مانند Vercel، Render یا Railway، یک VPS خام را انتخاب کرد. این کار نیازمند ورود دستی از طریق SSH به سرور و پیکربندی دستی ان‌جین‌ایکس (Nginx) بود. این انتقال بدون مشکل نبود؛ تلاش‌های اولیه منجر به ناتوانی کامل در ورود به سیستم شد.
پس از فعال شدن قابلیت ورود، مشکل ثانویه‌ای ظاهر شد: کاربر هنگام تلاش برای دسترسی به داشبورد، دوباره به صفحه ورود هدایت می‌شد. تشخیص داده شد که این مشکل ناشی از دامنه کوکی‌ها در ترکیب با مشکل CORS است، زیرا کلاینت و سرور روی زیردامنه‌های مختلف بودند. راه حل این مشکل، افزودن یک فیلد دامنه به پیکربندی کوکی و تنظیم مجدد تنظیمات CORS بود. این فرآیند با اولین تجربه واقعی توسعه‌دهنده در استفاده از ردیس (Redis) و BullMQ هم‌زمان شد.
این انتخاب معماری — یعنی تفکیک عامل‌ها از طریق دیتابیس به‌جای پیام‌رسانی مستقیم — شفافیت کامل را فراهم می‌کند. کاربر می‌تواند در هر لحظه دیتابیس MongoDB را بررسی کند تا ببیند هر لید دقیقاً در چه مرحله‌ای قرار دارد. این کار یک فرآیند انتزاعی هوش مصنوعی را به یک خط لوله تجاری قابل ردیابی تبدیل می‌کند.
برای یک «ایندی هکر» (Indie Hacker)، این تغییر به معنای گذار از «کار با ابزار» به «مانیتورینگ سیستم» است. ارزش واقعی اینجا نه در داشتن یک نویسنده ایمیل بهتر، بلکه در سیستمی است که تضمین می‌کند فرآیند هر روز بدون شکست اجرا می‌شود.
پروتکل فانتوم در حال حاضر تحت لایسنس AGPL v3 به‌صورت متن‌باز است و به‌طور کامل قابلیت میزبانی شخصی (Self-hosting) دارد. به‌روزرسانی‌های آینده شامل اتوماسیون کانال‌های ارتباطی فراتر از ایمیل، یک لایه یادگیری مناسب که کمپین‌ها را به‌طور خودکار در طول زمان بهبود بخشد و یک نسخه ابری مدیریت‌شده برای کاربران غیرفنی که نمی‌خواهند زیرساخت خود را راه‌اندازی کنند، خواهد بود.
توسعه‌دهندگان علاقه‌مند می‌توانند کد منبع را در گیت‌هاب بررسی کرده و سیستم را به‌صورت شخصی مستقر کنند.
گام بعدی شما
- اگر توسعه‌دهنده هستید، کد منبع Phantom Protocol را در گیت‌هاب بررسی کرده و آن را روی VPS شخصی خود مستقر کنید.
- برای بهینه‌سازی نرخ تبدیل، مدل Qwen3.7 را با داده‌های خاص صنعت خود برای نوشتن ایمیل‌ها تنظیم کنید.
- ساختار تفکیک‌شده دیتابیس این پروژه را برای سایر اتوماسیون‌های تجاری خود الگو قرار دهید.
اما داستان سخت‌افزاری پشت اجرای این مدل‌ها در مقیاس بالا حتی شگفت‌انگیزتر است — به تحلیل ما درباره معماری‌های جدید استنتاج مراجعه کنید.
گفتگو