العرض التوضيحي ينتهي دائماً عند الإدراك. يقرأ الوكيل بيانات أوامر الشراء ويُحدد شذوذاً ويُقدّم توصية. الغرفة تومئ. ثم يسأل أحدهم: “وماذا بعد؟ هل يُحدّث السجل؟” تصمت الغرفة. تلك هي اللحظة التي يبدأ فيها المشروع الحقيقي.
الكتابة العكسية هي حيث تفشل أو تنجح مشاريع وكلاء المؤسسات. إنها حيث تصبح القرارات المعمارية التي تخطّيتها في مرحلة النموذج الأولي محتومة.
مشكلة الكتابة العكسية التي لا يحلها أحد في العرض التوضيحي
العروض التوضيحية للوكلاء مبنية حول النصف الآمن من الحلقة: قراءة بيانات ERP وتوليد رؤية وتلخيصها بتنسيق قابل للقراءة. النموذج يؤدي ذلك بشكل جيد. عمليات القراءة ذات طبيعة توكيدية. الأخطاء مرئية وقابلة للتصحيح. لا أحد يتأثر راتبه.
الإنتاج مختلف. يحتاج الوكيل إلى الكتابة العكسية: تحديث حالة أمر الشراء، وإغلاق تذكرة، وإعادة تصنيف معاملة، وتشغيل سير عمل موافقة، وإنشاء سجل مورّد. هذه العمليات لا تتمتع بطابع توكيدي. حل الكيان الخاطئ يُنشئ سجلات مكررة. المعاملات غير المكتملة تترك نظام ERP في حالة غير متسقة. عمليات الكتابة المكررة تُفسد البيانات التي تعتمد عليها الأنظمة الطرفية. وعلى خلاف استجابة RAG المهلوسة التي يمكن للمستخدم تجاهلها، تتطلب كتابة ERP سيئة من إنسان إيجادها وفهمها وتصحيحها يدوياً.
ثلاثة أنماط فشل تُفسّر معظم حوادث الكتابة العكسية:
حل الكيان الخاطئ. يتلقى الوكيل “حدّث الطلب لـ Carlos Lima” ويجد سجلين يطابقان الاسم، أحدهما لموظف والآخر لجهة اتصال خارجية. بدون خطوة توضيح، يختار أحدهما. يختار الخاطئ 40% من الوقت، وهو 40% من الوقت أكثر مما يُقبل حين تكون العملية غير قابلة للعكس.
المعاملة غير المكتملة. يتطلب سير عمل ERP ثلاث خطوات: إنشاء سجل وإرفاق وثيقة وتشغيل توجيه الموافقة. يُكمل الوكيل الخطوتين الأولى والثانية. انتهاء مهلة API يقاطع الخطوة الثالثة. نظام ERP الآن في حالة غير متسقة: سجل موجود ووثيقة مرفقة، لكن سير عمل الموافقة لم يُشغَّل. الشخص التالي الذي ينظر إلى السجل لا يستطيع معرفة ما إذا اكتملت العملية أم هُجرت.
لا خطة استرداد. يبدأ الوكيل سير عمل متعدد الخطوات. تفشل الخطوة الرابعة. لا إجراء استرداد مُحدد للخطوات الأولى إلى الثالثة. يستغرق التصحيح اليدوي أربع ساعات. مشروع الوكيل مُعلَّق في انتظار مراجعة الحوكمة.
هذه ليست مشاكل نموذج لغوي. هي مشاكل بنية برمجية. لها حلول بنية برمجية.
حل الكيانات قبل الكتابة العكسية
القاعدة الأساسية للكتابة العكسية في ERP: لا تكتب على سجل باستخدام سلسلة اسم أبداً. حلّ دائماً إلى معرّف قانوني أولاً.
حل الكيانات طبقة بحث مخصصة بين الوكيل ونظام ERP. تتلقى مدخلات اللغة الطبيعية وتستعلم من نموذج هوية ERP الخاص وتُرجع المعرّف القانوني للسجل المستهدف وتوفر درجة ثقة ومعلومات توضيح.
البنية: يُنتج الوكيل كائن نية منظم (“حدّث أمر الشراء للمورّد X، غيّر الحالة إلى مُوافق عليه، المبلغ Y”). تتلقى طبقة حل الكيانات ذلك الكائن وتستعلم من ERP عن السجلات التي تطابق المورّد X وتُرجع صفراً أو أكثر من المرشحين بدرجات ثقة. إذا تجاوز مرشح واحد عتبة الثقة، يُمرَّر المعرّف إلى طبقة الكتابة العكسية. إذا لم يتجاوز أي مرشح العتبة، يتوقف الوكيل ويُظهر الغموض للحل البشري.
عتبة الثقة ليست اعتباطية. إنها معايرة مقابل جودة بيانات ERP المحددة لديك. أنظمة ERP ذات بيانات رئيسية نظيفة تتحمل عتبة أعلى. أنظمة ERP ذات بيانات موروثة على مر السنين وسجلات مكررة واتساق تسمية غير منتظم تتطلب عتبة أدنى وبوابات حل بشري أكثر تكراراً. طبقة حل الكيانات تكشف جودة بيانات ERP الخاصة بك قبل التأثير على عمليات الإنتاج.
لنظامي TOTVS Protheus وSAP وOracle: يجب أن يحترم حل الكيانات نموذج هوية ERP الخاص. يستخدم Protheus مخطط معرّف الكيانات الخاص به. فرض نموذج هوية خارجي فوقه يُدخل طبقة تعيين تصبح التزام صيانة. استعلم من معرّفات كيانات ERP الخاصة عبر API الخاص به.
بنية إنسان في الحلقة لإجراءات ERP
يجب تصنيف كل إجراء يستطيع الوكيل اتخاذه في ERP قبل تشغيل الوكيل، لا بعد فشله.
إطار التصنيف:
| نوع الإجراء | قابلية العكس | متطلب الموافقة |
|---|---|---|
| قراءة | لا ينطبق | لا شيء |
| كتابة منخفضة المخاطر | قابلة للعكس، أثر تجاري منخفض | تسجيل وتنفيذ |
| كتابة عالية المخاطر | قابلة للعكس، أثر تجاري كبير | موافقة بشرية قبل التنفيذ |
| غير قابل للعكس | لا يمكن التراجع عنه | موافقة مزدوجة مع سجل تدقيق كامل |
هذا التصنيف إعداد برمجي، لا تعليمة للنموذج. لا يُقرّر الوكيل في وقت التشغيل أي فئة يقع فيها الإجراء. الفئات مُحددة في وقت التصميم ومُعيَّنة لأنواع الإجراءات ومُطبَّقة من طبقة التنسيق.
قنوات الموافقة التي تعمل في الممارسة: رسالة Slack مع أزرار موافقة ورفض، أو بريد إلكتروني مع رمز موافقة موقّع، أو قائمة انتظار بوابة داخلية مع إشعار. يجب أن تُظهر واجهة الموافقة للمُوافِق بالضبط ما يُنوي الوكيل فعله بلغة واضحة مع السياق التجاري الذي دفع الإجراء. “وافق على إغلاق أمر شراء PO-2891 (المورّد: ABC Manufacturing، المبلغ: 45,000 فرنك سويسري، السبب: تأكيد التسليم من نظام المستودع في 2026-04-12)” قابل للموافقة. “يقترح الوكيل عملية كتابة على سجل ERP بمعرّف 2891” ليس كذلك.
مبدأ تصميم من إطار 12-Factor Agents: الموافقة البشرية مكوّن نظام، لا مسار استثنائي. ابنِ سير عمل الموافقة قبل أن يلمس إجراء الوكيل الأول بيانات الإنتاج. إذا لم يكن سير عمل الموافقة موجوداً حين يصل الوكيل إلى إجراء عالي المخاطر، إما سيتخطى الموافقة (مُنتجاً الحادثة) أو سيتوقف بلا مسار تصعيد (مُنتجاً تذكرة الدعم).
معاملات ERP كثيراً ما تكون غير ذرية. إذا بدأ الوكيل سير عمل متعدد الخطوات، يجب تحديد خطة الاسترداد واختبارها قبل تنفيذ الخطوة الأولى. لا “سنفكر في الاسترداد إذا ساء شيء”. إجراءات استرداد مُحددة مُعيَّنة لكل نوع إجراء ومُختبَرة على بيئة مرحلية. المرة الأولى التي يكون فيها إجراء الاسترداد مطلوباً ليست الوقت المناسب لكتابته.
نمط خادم MCP لتكامل ERP
كشف قدرات ERP كخوادم MCP يحوّل كل قدرة إلى واجهة محكومة: مخطط مدخلات مكتوب بوضوح ووصول مُصادَق عليه وتقييد معدل وسجل تدقيق لكل استدعاء.
النمط: كل قدرة ERP، “إنشاء أمر شراء”، “تحديث سجل مورّد”، “إغلاق تذكرة”، تصبح أداة MCP منفصلة بمخطط مدخلات مُحدد وأذونات مُحددة وسلوك تدقيق مُحدد. يصل الوكلاء إلى قدرات ERP عبر هذه الأدوات. مكالمات قاعدة البيانات المباشرة ومكالمات REST API المباشرة بدون حوكمة والتكاملات المخصصة التي تتجاوز طبقة الأذونات غير مسموح بها.
الفوائد على طبقة الحوكمة: أذونات عمليات الكتابة في ERP مُضبَّطة مرة واحدة على طبقة MCP ومكتسبة من قِبل كل وكيل يستخدم تلك الأدوات. القدرات الجديدة تُضاف إلى خادم MCP وتصبح متاحة لجميع الوكلاء المصرَّح لهم في آن واحد. القدرات المُهملة تُزال مرة واحدة وتختفي في كل مكان.
بالنسبة لـ TOTVS Protheus تحديداً: لا يوجد خادم MCP رسمي من TOTVS اعتباراً من أحدث بحث [تحقق من الحالة الحالية قبل النشر]. التنفيذ المخصص باستخدام Protheus REST APIs مطلوب. هذا عمل هندسي لا مهمة إعداد.
اعتبار أمني واحد لا يمكن تأجيله: اكتشاف فئة ثغرة RCE في تصميم بروتوكول MCP في 2026 أكد أن خوادم MCP برمجيات وتتطلب نفس ممارسات الأمن كأي مكوّن إنتاجي آخر. قوائم بيضاء وتصحيحات حالية وتسجيل تدقيق على مستوى البوابة. خادم MCP يتصل بنظام ERP للإنتاج هو سطح هجوم عالي القيمة.
الطرح التدريجي الذي يمنع الكارثة
لا يجب أن ينتقل أي مشروع وكيل مؤسسي من التجريب إلى الاستقلالية الكاملة في الكتابة العكسية في خطوة واحدة. يوجد الطرح التدريجي لأن كل مرحلة تكشف مشاكل قبل أن تكون العواقب على نطاق الإنتاج.
المرحلة الأولى: قراءة فقط. يقرأ الوكيل بيانات ERP ويقدم توصيات ويتوقف. لا قدرة كتابة. يُشغَّل لأربعة إلى ثمانية أسابيع. يتحقق من دقة حل الكيانات ويكشف مشاكل جودة البيانات في البيانات الرئيسية ويؤكد أن التوصيات صحيحة الاتجاه. نتائج جودة البيانات من المرحلة الأولى تعيد ترتيب عمل المراحل الثانية إلى الرابعة في الغالب.
المرحلة الثانية: كتابة خاضعة للإشراف. يقترح الوكيل إجراءات. يراجع إنسان كل واحدة ويوافق عليها قبل التنفيذ. يُشغَّل حتى تستقر نسبة الموافقة، عادةً فوق 95% بدون تعديل. المقترحات المرفوضة مواد تشخيصية لتحسين حل الكيانات.
المرحلة الثالثة: كتابة مستقلة مع رصد. أنواع الإجراءات المُعتمدة مسبقاً تُنفَّذ بدون مراجعة بشرية. جميع عمليات التنفيذ مُسجَّلة. اكتشاف الشذوذ يُعلم المراجعة البشرية بالانحرافات.
المرحلة الرابعة: أتمتة عالية الحجم. لأنواع الإجراءات ذات الدقة المثبتة ومخاطر قابلية العكس المنخفضة عبر المراحل الأولى إلى الثالثة.
تخطّ مرحلة، تتقدم نحو حادثة تلف البيانات التي توقف البرنامج لربعَين.
خلاصة الأعمال للقيام بذلك بشكل صحيح
موردو ERP يطرحون طبقاتهم الخاصة من AI: TOTVS LYNN (المُعلن عنه في فبراير 2026)، وSAP Joule، ومساعدات Oracle المدمجة. هذه حلول عامة. لم تُبنَ حول عملياتك المحددة وخصائص جودة بياناتك ومتطلباتك التنظيمية.
الوكلاء المخصصون ذوو معرفة عميقة بالعمليات وطبقة تكامل محكومة يتفوقون على مساعدات الموردين العامة لسير العمل المتخصصة. البنية التحتية للتكامل وخدمة حل الكيانات ومسار تدقيق الإجراءات قابلة لإعادة الاستخدام عبر كل مشروع وكيل لاحق. المشروع الثاني يكلف جزءاً بسيطاً من الأول.
الفرق الذي يتقدم بأسرع في تكامل وكلاء ERP هو الذي استثمر في الحوكمة مبكراً بما يكفي لامتلاك أساس مستقر حين طالب العمل بالتوسع.
للفرق المؤسسية التي تُقيّم تكامل الوكلاء مع الأنظمة التجارية الأساسية، رحلة فرصة AI ترسم خريطة البنية التكاملية قبل كتابة أي كود.