وكيل الذكاء الاصطناعي يكرر الخطأ نفسه؟ افحص ملاحظاته المحفوظة أولا

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

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

ملاحظة محفوظة يمكن أن تتغلب على الأمر الذي كتبته

في مقال مكوّنات ذاكرة الوكلاء المنشور في 6 نوفمبر 2026، تصف Anthropic وكيلًا كان يلعب Pokémon Red، وهي لعبة لا مهمة عمل، وحفظ ملاحظة خاطئة تفيد بأن جزءًا من اللعبة قد اكتمل. وفي التشغيل الذي بقيت فيه الملاحظة دون تصحيح، عاد الوكيل إلى مسار سابق ثلاث مرات. ثم جاءت جولة مراجعة فقارنت الملاحظة بنص الجلسة، واكتشفت الخطأ فيها، وأعادت كتابتها. وما يُظهره تشغيل واحد للعبة واحدة هو آلية المشكلة، لا مدى تكرار حدوثها.

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

تخيّل الآن مثالًا افتراضيًا من عالم الأعمال. وكيلٌ يقارن عروض أسعار الموردين حفظ في ملاحظاته «المورّد B: الدفع خلال 30 يومًا»، بينما ينص العرض على الدفع خلال 60 يومًا. كل خطوة لاحقة تقرأ هذه الملاحظة تعمل بشروط خاطئة. وإضافة «راجع شروط الدفع بعناية» إلى الأمر لا تفيد كثيرًا، لأن الوكيل يعتقد أن شروط الدفع لديه بالفعل. فالمعلومة الناقصة تترك فجوة قد ينتبه لها الوكيل فيعود للبحث عنها، أما المعلومة الخاطئة فتعطيه إجابة واثقة يتصرف بناءً عليها.

افحص ما حفظه الوكيل قبل أن تعيد صياغة الأمر

أجرِ هذا الفحص كلما تكرر خطأ، وقبل أن تغيّر التعليمات:

1. حدّد أين يكتب الوكيل. ملف ذاكرة، أو مجلد ملاحظات، أو مستند مشترك، أو جدول، أو ويكي. وإذا لم يستطع أحد في الفريق أن يحدد أين يكتب، فهذه أول نتيجة تخرج بها، والإصلاح التالي أن تجعل ذلك المكان مرئيًا.
2. استخرج ملاحظات العناصر التي وقع فيها الخطأ. واترك بقية المخزن. فإذا كان الخطأ في مواعيد الدفع، فاستخرج سجلات الموردين أو الفواتير المعنية.
3. ضع كل ملاحظة محفوظة بجانب مصدرها. عرض السعر، أو العقد، أو طلب الدعم. وقارن فقط المعلومات التي يجب أن تكون دقيقة: الأسماء، والأسعار، وشروط الدفع، والتواريخ، والحالة.
4. صنّف كل معلومة في واحدة من أربع فئات. مطابقة (نُقلت كما هي)، أو ملخّصة (صار معناها مبهمًا، مثل «نحو أسبوعين» بدل تاريخ مذكور)، أو خاطئة، أو ناقصة.
5. أصلح الخاطئة أولًا، في الملاحظات نفسها. صحّح السجل أو احذفه، ثم أعد تشغيل المهمة. تأتي المعلومات الخاطئة أولًا لأن الوكيل يتصرف بناءً عليها، ثم تأتي الملخّصة والناقصة.
6. بعد ذلك فقط غيّر التعليمات. فإذا تكرر الخطأ والملاحظات صحيحة، فالمشكلة فعلًا في الأمر أو في ملف التعليمات.

وعند الخطوة 6 يأتي دور نصائح الشركات المطوِّرة للأدوات. ففي توثيق Claude Code، كما كان يوم 9 نوفمبر 2026، يرد تكرار Claude للخطأ نفسه مرة ثانية بين أسباب الإضافة إلى ملف تعليمات المشروع. وتبقى هذه النصيحة قائمة، لكن الفحص يأتي قبلها. ويقول التوثيق نفسه إن Claude قد يختار اعتباطًا إحدى تعليمتين متناقضتين. وإضافة تعليمة جديدة فوق ملاحظة خاطئة قد تؤدي إلى تعارض مشابه بين ما قلته أنت وما حفظه الوكيل. وهذه النقطة الأخيرة استنتاج، والتوثيق لا يختبرها.

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

بقيت 18 معلومة من 24 مطابقة كما هي، ولم تبقَ 6 كذلك. ومن هذه المعلومات الست، معلومة واحدة فقط خاطئة، وهي شروط الدفع في العرض 3: وهي التفسير الأرجح لخطأ في الدفع يتكرر، وهي ما لن تصل إليه إعادة صياغة الأمر. انسخ الجدول وضع مكان صفوفه عناصرك أنت والمعلومات التي يجب أن تكون دقيقة فيها.

اجعل لكل سجل كاتبًا واحدًا، وانقل المعلومات الدقيقة حرفيًا

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

ويعرض مقال Anthropic اختبارًا واحدًا من هذا النوع، وهو محاكاة لاستحواذ على شركة ضمن اختبارها المعياري LAB. كتب عدة وكلاء في جدول مشترك لشروط العقود في الوقت نفسه، وحين قُيِّم موجزٌ أُنشئ من الويكي الناتج، لم يتضمن إلا 41 من 57 حقيقة (72%): فقد لُخّصت الشروط تلخيصًا رديئًا، وغاب بعضها لأن وكلاء محوا ما كتبه وكلاء آخرون ووضعوا عملهم مكانه. وبعد التغيير، صار لكل عقد صفحته الخاصة، يكتبها وكيل واحد ينقل الشروط حرفيًا، وأمكن استيفاء 100% من المعايير.

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

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

وهكذا يبدو سجل منظّم بهذه الطريقة (مثال افتراضي):

السجل: عرض سعر، المورّد B
المالك: الوكيل 2 (الوكيل الوحيد الذي يعدّل هذا السجل)
تُستخدم هذه الملاحظات في مقارنة الموردين. والأولوية للأسعار وشروط الدفع والتواريخ.

المعلومات الدقيقة، منقولة حرفيًا من العرض:
- سعر الوحدة: "..." (الصفحة 1، السطر 4)
- شروط الدفع: "..." (الصفحة 2، البند 3)
- موعد التسليم: "..." (الصفحة 1، السطر 9)
- تاريخ انتهاء الصلاحية: "..." (الصفحة 2، التذييل)

الملخص (بكلمات الوكيل):

أما أي معلومات يُسمح بحفظها أصلًا، ومن يملك تصحيحها، فمسألة حوكمة منفصلة يتناولها مقال ذاكرة الذكاء الاصطناعي: من يحدد ما يُحفظ ومن يملك تصحيحه؟. وهذا التنظيم يتعلق بمسألة أخرى: هل تبقى الحقائق سليمة حتى نهاية المهمة.

أخبر الوكلاء بالغرض من الملاحظات، لا بطريقة كتابتها

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

وفي التطبيق يعني هذا طبقتين لا أكثر. أنت من يحدد البنية (سجل واحد، وكاتب واحد، ومعلومات دقيقة منقولة حرفيًا)، وأنت من يكتب سطر الغرض («هذه الصفحات تُستخدم في موجز الاستحواذ، وشروط العقود هي الأولوية»). أما ما يختار الوكيل تدوينه بعد ذلك، فاتركه للوكيل.

واجعل الطبقة التي تُحمَّل في كل جلسة قصيرة كذلك. فتوثيق Claude Code، كما كان يوم 9 نوفمبر 2026، ينصح بأن يبقى كل ملف تعليمات دون 200 سطر لأن الملفات الأطول تقلل الالتزام بها، وبمراجعة هذه الملفات دوريًا بحثًا عن التعليمات القديمة أو المتعارضة. وهذه إرشادات من Anthropic لمنتج واحد لم تُدعم بقياس، لكنها تشير إلى الاتجاه نفسه: كل قاعدة تضيفها بعد تكرار خطأ تجعل الملف أطول، والتعارض التالي أرجح.

دع عملية التنظيف تقترح، ولا تدعها تستبدل القديم أبدًا

الملاحظات التي تبقى عبر جلسات كثيرة تتقادم. ويقول توثيق Dreams من Anthropic، كما كان يوم 9 نوفمبر 2026، إن مخزن الذاكرة تتراكم فيه إدخالات مكررة ومتناقضة وقديمة. أما Dreams، وهي ميزة في Claude Managed Agents في مرحلة المعاينة البحثية وتُحتسب تكلفتها بالسعر المعتاد للرموز، فتقرأ المخزن إلى جانب نصوص الجلسات السابقة، وتُنتج مخزنًا جديدًا أُعيد تنظيمه، وتترك المخزن الأصلي دون مساس، حتى يمكن مراجعة الناتج ثم استخدامه أو التخلص منه.

وانقل هذا النمط إلى أي عملية تنظيف، سواء كانت ميزة في منتج أو نصًا برمجيًا يشغّله فريقك:

• تكتب عملية التنظيف نسخة جديدة من الملاحظات، وتبقى النسخة القديمة دون مساس حتى تُقبل الجديدة.
• تعمل عملية التنظيف بالمقارنة مع المصدر (نصوص الجلسات، والعقود، وطلبات الدعم)، لا مع الملاحظات القديمة وحدها. فقد اكتُشف الخطأ في تجربة Pokémon لأن المراجعة قارنت الملاحظة بنص الجلسة، أما عملية التنظيف التي تكتفي بإعادة قراءة الملاحظات فليس لديها ما تكشف به الخطأ.
• يقارن شخصٌ النسخة الجديدة بالمصدر قبل أن تحل محل القديمة. والجدول السابق هو هذه المقارنة: طبّقه على عينة من السجلات، وأصلح النسخة الجديدة أو ارفضها إذا ظهرت فيها معلومة خاطئة.

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

متى يكون الوكيل الواحد هو الحل الأفضل

الكاتب الواحد لكل سجل هو الإصلاح المحدود. أما الإصلاح الأوسع فألّا تشغّل عدة كتّاب بالتوازي أصلًا. ففي مقال Don’t Build Multi-Agents (Walden Yan، 2025)، ترى Cognition أن الوكلاء الفرعيين العاملين بالتوازي قد يقدمون إجابات متعارضة، وأن أبسط طريقة لاتباع مبادئها هي وكيل واحد يعمل في مسار واحد متسلسل. وهذه حجة تسوقها Cognition بصفتها شركة مطوِّرة، ولا تستند إلى اختبار. وفي سياق منفصل، يرى Yu وزملاؤه، في ورقة تعرض رأيهم في ذاكرة الأنظمة متعددة الوكلاء، أن اتساق الذاكرة بين الوكلاء هو أكثر التحديات المفتوحة إلحاحًا. وتعامل مع الملاحظات المشتركة بين عدة وكلاء على أنها مشكلة تصميم لم تُحل بعد.

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