معظم أنظمة إدارة علاقات العملاء تُبنى بنفس المنطق: قاعدة بيانات، ونموذج إدخال، وربما مساعد ذكاء اصطناعي يُضاف لاحقًا كميزة جانبية. مشروع CRM من trycompai (رخصة MIT) يقلب هذا الترتيب: الوكيل ليس ميزة داخل النظام، بل النظام هو المكان الذي يسجّل فيه الوكيل ما توصّل إليه.
الوكيل يعمل باستقلالية حقيقية
لا يعمل الوكيل بنمط طلب واستجابة. له نشر مستقل، وجدولة خاصة به، وقائمة مهام ينفّذها بنفسه. يقرر ما يبحث عنه تاليًا، ويحجز مواعيد متابعة لنفسه، وينفق ميزانية بحث محددة، ويتوقف عند نفادها. إغلاق المتصفح لا يوقفه.
لماذا الواجهة البرمجية بلا ذكاء
واجهة NestJS البرمجية مصممة عمدًا بلا أي منطق استنتاجي. كل ما تفعله أن تسجّل حدثًا وقع، مثل استلام رسالة أو إنشاء شركة، في طابور انتظار. الوكيل يستلم هذا السجل ويقرر بنفسه ماذا يعني. أي خدمة داخل الواجهة تستدعي API إثراء بيانات تُعامَل كخطأ برمجي، ووثيقة docs/api.md في المشروع توثّق العطل الذي جعل هذا قاعدة صارمة.
قاعدة لا يخرقها الوكيل أبدًا
لا معلومة عن شخص تُخمَّن. لا أداة في النظام تقبل درجة ثقة (confidence score)، لأن النموذج المطلوب منه تقييم يقينه سيفعل ذلك، وسيخطئ في الاتجاه الذي يجعله يبدو مفيدًا. الأدوات تُبلّغ بما لاحظته فعليًا، مثل توقيع بريد إلكتروني أو هوية حساب GitHub، وسجل مركزي يقيّم قوة كل دليل. الدليل القوي يُكتب في السجل مباشرة، والدليل الضعيف يتحول لاقتراح يبتّ فيه إنسان. حقيقة خاطئة بثقة أسوأ من حقل فارغ، لأن لا أحد يكتشف خطأها.
الأدوات والمهارات كملفات
المشروع مبني على إطار eve من Vercel، وهو إطار للوكلاء الدائمين يعامل كل شيء كملف: الأداة ملف، والمهارة ملف Markdown، والجدولة ملف. يوفر 18 أداة مؤلَّفة (قراءة سجل CRM، البحث فيه، تحديد هوية جهة اتصال، إثراء بيانات شركة، تسجيل حقيقة، جدولة مراجعة لاحقة)، و4 مهارات نثرية يقرأها الوكيل ومُصدرة بالإصدار مثل الكود.
بيئة معزولة بلا شبكة ولا قاعدة بيانات
بيئة التنفيذ المعزولة للوكيل توفر bash وgrep وglob ومساحة عمل خاصة، لكن بلا أي اتصال شبكي صادر (deny-all egress). البحث على الويب يمر عبر مزوّد النموذج نفسه لا عبر البيئة المعزولة، فحجب الشبكة عنها لا يكلّف شيئًا وظيفيًا. والنصف الآخر من هذه القاعدة غياب متعمَّد: البيئة المعزولة لا تحصل أبدًا على رابط قاعدة البيانات. صدفة ومفاتيح دون شبكة أداة معالجة نصوص، لا مسار تسريب.
مصادر خارجية اختيارية بالكامل
يعمل النظام بلا أي مفتاح API على الإطلاق: أداة قراءة سجل CRM تقرأ محادثاتك واجتماعاتك وتوقيعاتك البريدية، وهذا دليل مجاني ولا يمكن لأي مزوّد بيانات بيعه لأنه يأتي من عنوان الشخص نفسه. كل مفتاح إضافي (RapidAPI لبيانات LinkedIn، Perplexity للبحث المفتوح، Context.dev لشعار الشركة وصناعتها) يفتح مصدرًا إضافيًا فقط، ويُخبَر الوكيل في بداية كل جلسة بالمصادر المتاحة فعليًا بدل اكتشاف الفجوات باستدعاء فاشل تلو الآخر.
التقنيات المستخدمة
| الطبقة | التقنية |
|---|---|
| الوكيل | eve، جلسات دائمة وأدوات ومهارات وجدولة وبيئات معزولة |
| النموذج | Vercel AI Gateway، بلا SDK مزوّد منفصل ولا مفتاح يُدار يدويًا |
| البيئة المعزولة | Vercel Sandbox في الإنتاج، Docker أو microsandbox محليًا |
| الواجهة | Next.js App Router · shadcn/ui · nuqs لحالة الرابط |
| الواجهة البرمجية | NestJS مع nestjs-trpc |
| البيانات | Prisma · Postgres (Neon) · Redis اختياري (Upstash) |
| المصادقة | Better Auth، تسجيل دخول Google فقط، قائمة سماح واحدة |
تصميم أحادي المستأجر عن قصد
النظام مصمم للاستخدام الداخلي فقط. تسجيل الدخول عبر Google، وقائمة السماح متغيّر بيئة واحد، وكل من يدخل يرى كل شيء. هذا هو نموذج الصلاحيات بالكامل، ووثيقة SECURITY.md في المشروع تنص صراحة على مراجعتها قبل توجيهه لبيانات عملاء حقيقيين. لا مفهوم لمؤسسات متعددة في الكود عمدًا، لأن عمود organizationId بقيمة ثابتة دائمًا يبدو كضابط صلاحيات حقيقي في المراجعة بينما لا يضيف شيئًا.
البدء السريع
يحتاج Bun وDocker. أمر استنساخ، وتثبيت، وتشغيل حاوية Postgres، ثم تعبئة أربع قيم في ملف البيئة (سر مصادقة، نطاق البريد المسموح، ومعرّف وسر عميل Google OAuth). التطبيق يعمل على المنفذ 3000 والواجهة البرمجية على 3001. النشر الفعلي يتطلب ثلاث عمليات نشر منفصلة (التطبيق والواجهة البرمجية والوكيل) وقاعدة Postgres واحدة، تتفق فقط على رابط القاعدة وسر المصادقة.