كل محادثة جديدة تبدأ بوكيل نسي مستنداتك. يمكنه إعادة قراءتها، بتكلفة من الوقت والسياق، أو يمكنه استشارة شيء يتذكر. يحتفظ GroupDocs.Search.Mcp بفهرس نص كامل مسمى على القرص، محليًا، يبقى بين الجلسات وإعادة تشغيل الحاوية، لذا يبدأ Claude Desktop أو Cursor أو Copilot كل جلسة مع مستندات المشروع قابلة للبحث بالفعل ويقوم بتحديثها باستدعاء واحد عندما تتغير الملفات:

قمت بتحرير بعض العقود. قم بتحديث فهرس العقود، ثم أخبرني أي العقود تذكر غرامة الآن.

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

ماذا يعني “الذاكرة” للوكيل؟

في الواقع، شيئين: حالة تستمر خارج المحادثة، وطريقة رخيصة للحفاظ على صحة تلك الحالة. تاريخ الدردشة يفشل في كليهما: ينتهي مع الجلسة، ولا شيء يحدثه عندما يتغير مستند. فهرس البحث هو الأنسب للمستندات. يعيش على القرص بجوارها، يجيب على سؤال “أي ملفات تقول X” دون تحميلها، ويمكن تحديثه تدريجيًا.

session 1    add_to_index --> index "contracts" --+
                                                 |  kept on disk in
session 2    search, get_text_fragments <--------+  /data/.groupdocs-search-
             (nothing is re-read)                    index/contracts
files edit   update_index --> re-reads changed, added, deleted files only
new project  create_index {"indexName":"legal-2026"} --> a separate index

كيف يعمل التحديث؟

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

-> get_index_info {"indexName":"contracts"}
<- { "documentCount": 5, "indexedPaths": [ "contracts" ],
     "documentsWithErrors": [], "status": "Ready" }

-> update_index {"indexName":"contracts"}
<- Index 'contracts' updated: 0 added, 1 updated, 0 removed;
   5 document(s) in the index.

-> search {"query":"penalty","indexName":"contracts"}
<- documentsFound 3, including the edited initech-nda.docx

الأعداد تخبرك بما حدث: ملف واحد أعيد قراءته، ولم يتأثر شيء آخر. الملفات المحذوفة تُزال في نفس الاستدعاء.

لماذا فهرس واحد لكل مشروع؟

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

-> create_index {"indexName":"legal-2026"}
<- Index 'legal-2026' created. Add documents with add_to_index
   (indexName: 'legal-2026').

كل فهرس هو مجلد تحت /data/.groupdocs-search-index، وget_index_info بدون اسم يسردهم جميعًا. نادرًا ما تحتاج إلى create_index صراحةً، لأن add_to_index ينشئ فهرسًا عند الاستخدام الأول، لكن تسمية الفهارس عمدًا هي ما يحول “فهرسًا” إلى “ذاكرة هذا المشروع”.

القاعدة الوحيدة حول الإزالة

المحرك يزيل المسارات التي أضيفت، وليس الملفات الفردية داخلها. الخادم يوضح ذلك بوضوح عندما تحاول:

-> remove_from_index {"documentPath":"contracts/hooli-supply-terms.txt",...}
<- Removal failed for 'contracts/hooli-supply-terms.txt':
   'contracts/hooli-supply-terms.txt' is inside the indexed folder
   'contracts'. GroupDocs.Search removes whole indexed paths only: ...

لذا صمم لذلك: إذا كنت تتوقع حذف جزء من مجموعة البيانات لاحقًا، مثل سنة أو عميل أو مسودات، فهرس تلك الأجزاء كمسارات منفصلة (contracts/2025, contracts/2026) ويمكن حذف كل منها على حدة. حذف ملف على القرص وتشغيل update_index يزيله أيضًا.

الحفاظ على تحديثه دون طلب

create_index (optional)
      |
      v
add_to_index ---> search ---> get_text_fragments
      ^              ^
      |              |  get_index_info: counts, paths, status
update_index  (files changed on disk)
      |
remove_from_index  (only a path that was given to add_to_index)

ثلاث طرق عملية لجعل التحديث تلقائيًا:

  1. في تعليمات الوكيل. سطر في CLAUDE.md أو AGENTS.md، “استدعِ update_index لفهرس هذا المشروع قبل الإجابة إذا كان من الممكن أن تكون الملفات قد تغيرت”، يجعل الوكيل يقوم بذلك في بداية الجلسة.
  2. على جدول زمني. أي أتمتة تدعم MCP يمكنها استدعاء update_index ليلاً؛ عندما يتغير القليل، يكون الاستدعاء سريعًا.
  3. بعد نسخة جماعية. استدعاء واحد يلتقط كل ملف أضيف.

الفهارس أيضًا تبقى بعد الترقيات: الفهارس التي بنتها GroupDocs.Search من 22.7 إلى 26.8 تُحوَّل عند الاستخدام الأول، مع نسخة احتياطية تُحفظ بجوارها.

ما يقرره الوكيل، وما يفعله الفهرس

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

التقسيم متعمد. الحكم يبقى مع النموذج، والحقائق التي يستند إليها تأتي من أداة يمكنك فحص مخرجاتها.

حدود صريحة

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

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

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

هل أحتاج إلى إعادة بناء الفهرس عندما تتغير الملفات؟
لا. update_index يعيد قراءة الملفات التي تغيرت أو أضيفت أو حُذفت فقط.

هل يمكنني إبقاء الفهرس منفصلًا عن المستندات للقراءة فقط؟
نعم. اربط المستندات للقراءة فقط، واربط مجلدًا قابلًا للكتابة على /index، واضبط GROUPDOCS_MCP_INDEX_PATH=/index.

تعمق أكثر