“إعادة تسمية ACME Corp إلى Globex في هذا العقد” هي مهمة تستغرق ثلاث ثوانٍ لشخص وفخ لوكيل ذكاء اصطناعي. الطريقة الواضحة، قراءة المستند وكتابة نسخة جديدة، تتخلص من الأنماط، حدود الجداول، رؤوس الصفحات وثقة المراجع بأن لا شيء آخر تحرك. مع تشغيل خادم GroupDocs.Editor MCP محليًا، يقوم Claude أو Cursor أو Copilot بتحرير الملف بدلاً من إعادة كتابته: يجد الكلمات، يستبدلها في مكانها، يحافظ على التنسيق، ويخبرك بعدد التغييرات التي أجراها:

إعادة تسمية ACME Corp إلى Globex Ltd في contract.docx مع الحفاظ على التنسيق.

الإصدار خطوة بخطوة مع الإعداد، التعليمات وإصلاح الأخطاء موجود في الوثائق: How to edit documents with AI agents using MCP.

ما الذي يحدث عندما يعيد النموذج كتابة الملف؟

النموذج اللغوي لا يحمل ملف .docx. إنه يحمل نصًا. عندما تطلب منه “تحديث العقد”، المسار الطبيعي هو قراءة الكلمات، تعديلها، وإنتاج مستند جديد من نسخته الخاصة. ثلاث أشياء تُفقد في الطريق.

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

كل ما لم يُطلب من النموذج لمسه. التجديد يعني أن كل جملة تمر عبر النموذج مرة أخرى. قد يتم “تنظيف” بند، إعادة تنسيق رقم، أو حذف جملة لأن نافذة السياق امتلأت. الآن على المراجع مقارنة المستند بالكامل للثقة في تغيير من ثلاث كلمات.

سجل التدقيق. “قمت بتحديث العقد” هو الرد نفسه سواء غير النموذج اسمًا واحدًا أو سبعة. لا يوجد عدد، ولا طريقة للتمييز بين تعديل دقيق وآخر واثق.

خوادم التحرير التي تدعم DOCX فقط والتي موجودة بالفعل حلت المشكلة الأولى للـ Word. المشكلتين الأخريين، وكل تنسيق ليس Word، ما زالا مفتوحين.

كيف يبدو التحرير المستهدف؟

مكالمتان. مأخوذة من GroupDocs.Editor.Mcp 26.10.0 ضد اتفاقية خدمات صناعية حيث يظهر “ACME Corp” سبع مرات:

-> get_document_info {"file":{"filePath":"contract.docx"}}
<- { "family": "WordProcessing", "pageCount": 1, "canEdit": true,
     "canSaveTo": [ "docx", "doc", "rtf", "odt", "pdf", "md", ... ] }

-> replace_text {"file":{"filePath":"contract.docx"},
                 "find":"ACME Corp","replace":"Globex Ltd","wholeWord":true}
<- Replaced 6 occurrence(s) of 'ACME Corp' in 'contract.docx'
   Saved to: …/contract_edited.docx

-> replace_text {"file":{"filePath":"contract.docx"},
                 "find":"Initech","replace":"Globex Ltd"}
<- Text replacement found no matches for 'Initech' in 'contract.docx'.
   No file was written.

النسخة المعدلة تحتفظ باسم الطرف بالخط العريض، أنماط العناوين وجدول الرسوم. الأصل يبقى دون تغيير؛ النتيجة ملف جديد، contract_edited.docx، في مجلد التخزين.

لماذا ستة وليس سبعة؟

هذا هو التفصيل الذي يستحق القراءة مرتين. الظهور السابع لـ “ACME Corp” يقع في بند الإشعارات، حيث “ACME” مائل و" Corp" ليس كذلك. في الملف هذان تشغيلا تنسيق مختلفين، وreplace_text يطابق داخل تشغيل واحد. لم يخمن، ولم يدمج الأنماط لإجبار المطابقة؛ أبلغ عن ستة، والظهور السابع لا يزال “ACME Corp”.

هذا هو السلوك الذي تريده من أداة تُحرّر العقود. عدد أقل مما توقعت هو إشارة للبحث؛ إعادة كتابة “كاملة” صامتة ليست كذلك. يمكن للوكيل المتابعة بالمسار الآخر الذي يقدمه الخادم: استخراج ذلك الجزء كـ HTML، تحريره، ثم حفظه مرة أخرى. يغطي ذلك round-trip post.

المكالمات، بالترتيب

user              agent                        Editor MCP server
 |  "Rename ACME Corp to Globex Ltd in contract.docx"          |
 |---------------->|                                           |
 |                 |-- get_document_info {"file":...} -------->|
 |                 |<- WordProcessing, 1 page, canEdit --------|
 |                 |-- replace_text {"find":"ACME Corp",       |
 |                 |     "replace":"Globex Ltd",               |
 |                 |     "wholeWord":true} ------------------->|
 |                 |<- "Replaced 6 occurrence(s) ...           |
 |                 |    Saved to: .../contract_edited.docx" ---|
 |<- "6 changed; one more is split across formatting - check  |
 |    the notices clause. The original is kept."               |
      (a find that matches nothing: 'No file was written.')

لماذا هذا أكثر من حيلة Word

نفس المكالمة تعمل على ورقة عمل، شريحة، PDF أو ملف نصي. في اختبارنا، "worksheet": 1 أعاد تسمية المورد في ورقة ملخص الميزانية وترك الورقتين الأخريين دون تغيير؛ "slide": 1 فعل نفس الشيء على عرض تقديمي. "format": "pdf" يحرّر ويحوّل في مكالمة واحدة، لذا “إصلاح الاسم وإرسال PDF” هو خطوة واحدة. "regex": true يتعامل مع أنماط مثل سلاسل الإصدارات.

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

الإعداد

dnx GroupDocs.Editor.Mcp --yes

مع تعيين GROUPDOCS_MCP_STORAGE_PATH إلى المجلد الذي قد يحرّره الوكيل، أو صورة Docker ghcr.io/groupdocs-editor/editor-net-mcp. تكوين كل عميل موجود في documentation hub. ما تغير في المحرك نفسه موجود في GroupDocs.Editor for .NET 26.6 release notes.

حدود صريحة

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

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

هل سيكتب الوكيل فوق ملفي الأصلي؟
لا. كل تعديل يكتب ملفًا جديدًا، <name>_edited.<ext> افتراضيًا أو outputName الذي تحدده، داخل مجلد التخزين.

ماذا يحدث إذا لم يكن النص موجودًا في المستند؟
لا يُكتب شيء. يرد الخادم “found no matches … No file was written."، لذا يمكن للوكيل إبلاغك بدلاً من إرجاع نسخة غير مُغيّرة.

هل يعمل بدون تثبيت Word؟
نعم. الخادم يعمل محليًا بمحرك GroupDocs.Editor؛ لا حاجة لتثبيت Office ولا للرفع.

تعمق أكثر