الكثير من المعرفة التجارية تكمن في البريد الإلكتروني، والجزء الذي تحتاجه يكون عادةً في مرفق: العرض، التعديل الموقع، الجدول المعدل. GroupDocs.Search.Mcp، الذي يعمل محليًا في Docker، يفتح ملفات البريد الإلكتروني والأرشيفات (PST، OST، MSG، EML) ويُفهرس كل رسالة وكل مرفق، بحيث يمكن لـ Claude Desktop أو Cursor أو Copilot البحث في الأرشيف في مكانه وتحديد بالضبط أي مرفق جاء منه التطابق:

فهرس مجلد البريد. أي رسالة تذكر زيادة في السعر، وماذا تقول بالضبط؟

الإصدار خطوة بخطوة مع الإعدادات واستكشاف الأخطاء موجود في الوثائق: كيفية البحث في أرشيفات البريد الإلكتروني والمرفقات باستخدام وكيل ذكاء اصطناعي، محليًا.

لماذا يُعَدّ البريد الإلكتروني صعبًا على الوكيل؟

لأن الأرشيف هو حاوية داخل حاويات. ملف PST يحتوي على مجلدات، المجلدات تحتوي على رسائل، الرسائل تحتوي على مرفقات، والمرفقات هي ملفات Word أو PDF أو جداول بيانات بحد ذاتها. الوكيل الذي يستخدم أدوات الملفات يرى ملفًا ثنائيًا كبيرًا واحدًا. تصدير الأرشيف إلى ملفات منفصلة أولًا يعمل، لكنه بطيء، ويُكرّر البيانات الحساسة على القرص، ويجب إعادته عندما يتغير الأرشيف. ولا يستطيع النموذج قراءة ملف PST على الإطلاق.

محرك البحث يتعامل مع التداخل بنفسه. كل رسالة وكل مرفق يصبح عنصرًا قابلاً للبحث، ويسجل الناتج كلًا من موقع الحاوية وموقع التطابق داخلها.

كيف يبدو التطابق داخل مرفق؟

هذا ما أعاده الخادم في اختبارنا مع ثلاث رسائل EML. العبارة “price increase” تظهر فقط داخل عرض Word المرفق بأحدها؛ بينما نص الرسالة يقتصر على “please find the updated quotation attached”.

-> add_to_index {"documentsPath":"mail","indexName":"mail"}
<- Indexed 'mail' into index 'mail': 3 document(s) added, 3 in the index.

-> search {"query":"\"price increase\"","indexName":"mail"}
<- { "documentsFound": 1, "documents": [
     { "filePath": "mail/2026-09-18-re-q3-pricing.eml",
       "innerPath": "quotation-Q-2026-118.docx",
       "occurrences": 1 } ] }

-> get_text_fragments {"query":"\"price increase\"","indexName":"mail"}
<- === mail/2026-09-18-re-q3-pricing.eml → quotation-Q-2026-118.docx
   (1 occurrence(s)) ===
     …Due to raw material costs we announce a price increase
   of 6 percent from 2026-11-01.…

filePath هو الرسالة؛ innerPath هو المرفق. يمكن للوكيل أن يجيب: “رسالة Re: Q3 pricing من Contoso، في عرض الاقتباس المرفق Q-2026-118: زيادة بنسبة 6٪ اعتبارًا من 1 نوفمبر”، وكل جزء من هذا الجملة قابل للتتبع.

mail/2026-09-18-re-q3-pricing.eml          <- filePath
  |- body: "please find the updated quotation attached"
  '- attachment: quotation-Q-2026-118.docx  <- innerPath
        "...we announce a price increase of 6 percent..."

أسئلة تعمل على البريد

لغة الاستعلام المعتادة تُطبق، وهناك بعض الأنماط المفيدة بشكل خاص للمراسلات. تم التحقق من جميع هذه ضد نفس صندوق البريد التجريبي:

  • “أي رسالة من Fabrikam تذكر تأخيرًا في التسليم؟” : fabrikam AND delay. عناوين المرسلين مفهرسة مع الرسالة، لذا contoso وجد أيضًا فاتورة لا يذكر نصها الشركة.
  • “ابحث عن كل بريد إلكتروني يذكر الطلب 77812” : 77812. الأرقام الكاملة تُعامل ككلمات.
  • “أي فواتير تستحق في أكتوبر؟” : invoice AND content: daterange(2026-10-01 ~~ 2026-10-31). هذا يطابق التواريخ المكتوبة في نص الرسالة، مثل “due on 2026-10-22”. بادئة content: مهمة: بدونها، نطاق التاريخ يطابق أيضًا التواريخ التي يسجلها المحرك لكل ملف.

لماذا يهم العمل محليًا أكثر للبريد مقارنة بأي شيء آخر

البريد هو المكان الذي توجد فيه المواد الحساسة: البيانات الشخصية، المفاوضات، سلاسل الموارد البشرية، النصائح القانونية. أدوات البحث التي تتطلب رفع صندوق البريد أو مزامنته مع خدمة تُعد غير مقبولة للعديد من الفرق. هنا يُركّب الأرشيف للقراءة فقط داخل حاوية على الجهاز، يُفهرس هناك، ويُبحث هناك. النص الوحيد الذي يخرج هو ما يقتبسه الوكيل في إجابته، ومع نموذج مستضاف محليًا، لا يُرسل حتى ذلك.

لإعداد أكثر صرامة، ركب الأرشيف للقراءة فقط وامنح الفهرس حجمه الخاص:

docker run --rm -i \
  -v /srv/mail:/data:ro \
  -v /srv/mail-index:/index -e GROUPDOCS_MCP_INDEX_PATH=/index \
  ghcr.io/groupdocs-search/search-net-mcp:latest

تحديد نطاق أرشيف كبير

أرشيف يحتوي على عشرات الآلاف من الرسائل يُفهرس بسهولة مع ترخيص، لكن من الأفضل التخطيط. فهرس حسب المجلد أو حسب السنة كمسارات منفصلة (mail/2025, mail/2026)، بحيث يمكن إزالة سنة أو إعادة بنائها بمفردها، لأن المحرك يزيل مسارات مفهرسة بالكامل بدلاً من ملفات فردية. احتفظ بالبريد في فهرس خاص به، منفصل عن العقود أو التقارير، حتى لا يضطر سؤال حول المراسلات إلى الخوض في كل شيء آخر. وعندما ينمو الأرشيف، يلتقط update_index الرسائل الجديدة دون إعادة قراءة القديمة.

حدود صريحة

  • في وضع التقييم، الفهرس يحتوي على أقصى حد 100 مستند، والبحث يُعيد أقصى حد 10، وكل رسالة ومرفق يُحسبان، لذا الأرشيف الحقيقي يحتاج إلى ترخيص. استدعِ get_license_status أولًا.
  • فهرسة ملف PST كبير تستغرق وقتًا: كل رسالة ومرفق يُفتح. فهرس مرة واحدة، ثم استخدم update_index.
  • المرفقات الممسوحة ضوئيًا بدون طبقة نص تُفهرس فقط بخصائص ملفها؛ لا يوجد OCR.
  • Docker فقط؛ على Linux أضف --user "$(id -u):$(id -g)" ما لم تستخدم إعداد القراءة فقط أعلاه.

الأسئلة المتكررة

هل يمكنني البحث في ملف PST باستخدام الذكاء الاصطناعي دون Outlook؟
نعم. المحرك يقرأ PST وOST وMSG وEML مباشرةً؛ لا يُشارك Outlook، ولا يتم تصدير أي شيء.

هل يبحث داخل مرفقات البريد الإلكتروني؟
نعم. تُفهرس المرفقات كعناصر لرسالتها، ويعود التطابق داخل أحدها مع إرجاع innerPath الذي يحدد المرفق.

هل يتم رفع صندوق بريدي إلى أي مكان؟
لا. يُقرأ داخل حاوية محلية؛ فقط المقاطع التي يقتبسها الوكيل تصل إلى مزود النموذج الخاص بك.

تعمق أكثر