التطور المستمر للوكلاء

يواجه الوكلاء اليوم مفارقة لافتة: فقد ينجحون من المحاولة الأولى في حل مهمة معقدة لم يروها من قبل، لكنهم قد يكررون غدًا الخطأ الذي ارتكبوه اليوم حتى بعد تنفيذ آلاف المهام المشابهة. وبعد أن يبدأ النموذج عمله، هل يمكنه أن يتحسّن من عمله اليومي كما يفعل الموظف الجديد؟ وقد أصبحت القدرة على التعلم المستقل من الخبرة — أي ما يُسمى اليوم التعلم المستمر (continual learning) — شرطًا للانتقال من مجرد إنجاز المهام إلى العمل الموثوق، كما غدت محورًا بحثيًا للجيل القادم من النماذج. ومفهوم «التعلم المستمر» اليوم ليس هو المشكلة نفسها التي تناولتها الأبحاث القديمة عن «تعلّم مهمة جديدة ونسيان القديمة»؛ فالنسيان ليس سوى مسألة فرعية واحدة، والأصعب منه أن أحدًا لا يخبر النموذج أي أجزاء من تجربة اليوم كانت صحيحة وأيها كانت خاطئة. وحتى الآن، ما زالت النماذج الحالية بعيدة عن التعلم المستمر بمفردها.

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

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

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

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

لقد قدمت الفصول السابقة بالفعل المكونات الرئيسية التي يتطلبها هذا النظام. يتناول الفصل 2 حالة المهمة، ويوفر الفصل 3 البنية التحتية للمعرفة، ويمنح الفصل 5 الوكلاء القدرة الوصفية لإنشاء الأدوات وتعديل الأنظمة، ويحدد الفصل 7 التقييم والتحقق، ويشرح الفصل 8 كيفية تحديث معلمات النموذج. ومهمة الفصل التاسع هي تنظيم هذه المكونات في حلقة التطور المستمر المبينة في الشكل 9-1.

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

استخلاص إشارات التعلم من المسارات التشغيلية

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

تقييم مسار ما يعني في جوهره الإجابة عن ثلاثة أسئلة بالترتيب: هل أُنجزت المهمة، وهل أُنجزت بالطريقة المسموح بها، وهل كانت التجربة مريحة للمستخدم؟ ويعرض الشكل 9-2 تنظيمها في بنية تحقق من ثلاث طبقات.

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

مدقق العمليات في الطبقة الوسطى يجيب عن سؤال: «هل أُنجزت بالطريقة المسموح بها؟» فالنتيجة الصحيحة لا تعني عملية صحيحة: قد يؤدي حذف حالات الاختبار الفاشلة أيضًا إلى نجاح الاختبارات، في حين أن إخبار المستخدم: «سوف نعيد إليك أموالك في غضون سبعة أيام؛ يرجى التحلي بالصبر» قد يؤدي إلى رضا مؤقت. تفحص هذه الطبقة قواعد العمل، والصلاحيات، وتتابع الأفعال، للتمييز بين «تحققت النتيجة» و«تحققت النتيجة عبر مسار مسموح به». ويمكن التعبير بدقة عن مستودعات السياسات وجداول الصلاحيات ومسارات الأفعال، ولذلك يمكن الحكم على هذه الطبقة بالشيفرة أيضًا.

مدقق الجودة في الطبقة العليا يجيب عن سؤال: «هل كانت التجربة مريحة للمستخدم؟» مثال ذلك: هل تحلت خدمة العملاء بالصبر، وهل قدمت بدائل متوافقة، وهل حدد تقرير البحث الأدلة الرئيسية، وهل كان النص المولَّد طبيعيًا وموجزًا. هذه الأبعاد لا تحدد ما إذا كانت المهمة قد اكتملت، لكنها تؤثر في تجربة المستخدم. ويمكن هنا استخدام LLM-as-a-Judge الذي قُدِّم في الفصل 7: تحديد نموذج التقييم (Rubric) مسبقًا ومطالبة المدقق بتسجيل كل عنصر والاستشهاد بأدلة المسار.

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

جدول 9-1 أبعاد تقييم المسار لوكيل خدمة العملاء

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

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

التجربة 9-1 ★★: إنشاء أداة التحقق من المسار لوكيل خدمة العملاء

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

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

أربع طرق لتطور الوكيل المستمر

تشير إشارات التعلم إلى ضرورة تغيير الوكيل، ولكن ليس المكان الذي يجب أن يحدث فيه هذا التغيير. الأساس الأساسي لاختيار طريقة التحديث ليس مدة استمرار التجربة، ولكن ما إذا كان من الممكن تمثيل القدرة المستهدفة بشكل طبيعي بواسطة وسيط معين. تتناسب الحقائق والخبرات مع المستندات المعرفية؛ الاستراتيجيات التي يمكن التعبير عنها بوضوح باللغة تنتمي إلى الموجّهات أو المهارات؛ ينبغي تشفير الإجراءات والقيود القابلة للتنفيذ بدقة كبرامج؛ ويجب أن تدخل القدرات عالية الأبعاد مثل الإدراك وأسلوب اللغة والاستراتيجيات الضمنية في معلمات النموذج. ويبين الشكل 9-3 هذه الطرق الأربع والعلاقات بينها.

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

جدول 9-2 الحدود المطبقة لأربع طرق للتطور المستمر

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

دمج الخبرة في المعرفة

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

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

يتبع هذا التصميم المبدأ ذا المرحلتين الذي رأيناه في نهج «المستخدم بوصفه شفرة» في الفصل الثالث. فذلك النهج يسجل حقائق المحادثة أولًا في سجل ثابت، ثم يعيد دوريًا بناء نموذج منظّم للمستخدم. وبالمثل، ينبغي للتعلم من الخبرة أن يحفظ الأدلة أولًا، ثم يستخلص منها لاحقًا معرفة قابلة للتعديل في عملية منفصلة. ويوضح الشكل 9-4 هذا المسار. ويفصل هذا التصميم بين التسجيل والتنظيم، فلا يغيّر نجاح عابر أو عطل شبكي الوكيل فورًا، ولا يعتمد النظام نمطًا عامًا إلا بعد أن يراه في نجاحات وإخفاقات متعددة.

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

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

ويقدّم التعلم من تجارب GAIA مثالًا واضحًا. يتضمن معيار GAIA¹ مسائل متعددة الخطوات تجمع بين البحث وقراءة الويب ومعالجة الملفات والحساب، بينما يوفّر AWorld² بيئة لتشغيل الوكلاء واستدعاء الأدوات وتسجيل المسارات. فالأول أشبه بورقة الاختبار، والثاني بقاعة الاختبار ونظام تسجيل نتائجه. وقد يكتفي نهج ساذج بتلخيص استراتيجية تشغيل ناجح وإدخالها مباشرة في الموجّه. أما التطبيق المنضبط فيبدأ بمدقق إجابات GAIA، أو بمدقق بيئي آخر، لتصنيف كل تشغيل إلى ناجح أو ناجح جزئيًا أو فاشل، ثم يقارن مسارات عدة من عائلة المهمة نفسها. تقترح المسارات الناجحة استراتيجيات مرشحة، وتكشف الإخفاقات ما ينبغي تجنبه، وتبيّن النجاحات الجزئية الجزء الذي نجح والجزء الذي بقي عالقًا. وقد يساعد التأمل اللغوي الذي اقترحته Reflexion³ على صياغة دروس مرشحة، لكنه ليس دليلًا في ذاته. ولا ينبغي إدخال درس في وثائق الخبرة المعتمدة إلا إذا وافق نتائج البيئة، وتكرر تأييده عبر مسارات عدة، وأظهر أثرًا إيجابيًا عند نقله إلى مهام جديدة.

تحويل الخبرة إلى تعليمات

تمنح قاعدةُ معرفة الخبرة الوكيلَ «مادةً يمكن الرجوع إليها»، بينما يحدّد الـ Prompt والـ Skill «كيف ينبغي أن يتصرف». ولا يستحق رفعُ الخبرة إلى مرتبة التعليمات إلا حين تكشف مسارات متشابهة كثيرة، مرةً بعد مرة، الخطأ الاستراتيجي نفسَه، وحين يمكن وصف ذلك الخطأ باللغة وصفًا واضحًا. ولنفصل أولًا بين ثلاثة مفاهيم: الـ Prompt النظامي يسري على المهام كلها، والـ Skill لا يُحمَّل إلا عند الحاجة حين يطابق مجالًا أو أداةً بعينها، والبرنامج/Harness يتولى الصلاحيات وسائر القيود الصارمة.

سمّى أندريه كارباثي هذه الممارسة تعلّم الـ Prompt النظامي (System Prompt Learning)⁴: فبعد أن يصطدم النموذج بمشكلة، يترك جملةً واحدةً واضحةً تنبّه نفسَه في المستقبل. ويبحث DSPy⁵ عن التعليمات والأمثلة على مجموعة تطوير؛ ويقترح OPRO⁶ مطالبات جديدة اعتمادًا على تاريخ المطالبات ودرجاتها؛ ويولّد GEPA⁷ مقترحات مطالبات وينقّيها انطلاقًا من تأملات بلغة طبيعية في المسارات الفاشلة. وتناسب هذه الطرائق التحسين الدفعي غير المتصل؛ أما بيئة الإنتاج فالأنسب لها مقترحات تحديث دنيا قابلة للتدقيق مع الإبقاء على مسار تراجع سريع.

وتعلّمُ الـ Prompt النظامي ليس هو هندسةَ المطالبات في الفصل الثاني. فذلك الفصل ناقش كيف تُنظَّم مطالبة جيدة؛ أما هذا القسم فيناقش أيَّ تغذية راجعة تكفي لتفعيل تعديل، وكيف يُطلَق مقترح التحديث بأمان. وينبغي أن يكون التعديل diff أدنى مقترنًا بمصدره، لا إعادةَ كتابة المطالبة كاملةً في كل مرة — وهذا بالضبط نمط «الـ diff الأدنى مع إمكانية التراجع» الذي سُمِّي في الفصل الأول. ويجب اختبار النسخة المرشَّحة في آنٍ واحد على مجموعة الحدود التي أطلقت الإخفاق وعلى مجموعة احتفاظ تعمل أصلًا بصورة سليمة: فالأولى ينبغي أن تتحسن، والثانية لا يجوز أن تتراجع.

المثال الأول: تحويل حدّ التحويل إلى قواعد

في سياسة نطاق telecom من τ²-bench، لا يحكم التحويل إلى موظف بشري سوى نصّين مبدئيين: لا تُحوِّل إلا إذا خرج الطلب عن نطاق أفعال الوكيل، وابذل وسعك في الحل قبل التحويل. حين شرّح الفصل السابع هذه البيئة لم يُظهر هذان السطران أي خلل؛ لكن شغِّل البيئة نفسها بنموذج أضعف فيبرز النقص فورًا — بعد أن تُعيد الأداة خطأً يعاود الوكيل المحاولة مرارًا، ثم ينهي الأمر بالتحويل إلى موظف بشري. بهذه الطريقة انتهت 19 مهمة من أصل 20 في مجموعة الاستخلاص.

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

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

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

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

التجربة 9-2 ★★: استخلاص قواعد التحويل واستخدام الأدوات من مسارات τ²-bench الفاشلة

تُستعمل بيئة τ²-bench telecom من الفصل السابع كما هي. ومجموعة الاستخلاص ومجموعة النقل هما أصلًا مجموعتا مهام متباينتان في المستودع الأصلي، فلا تمس عملية الاستخلاص مجموعة النقل البتة.

شغِّل أولًا مجموعة الاستخلاص بنموذج ضعيف واحفظ المسارات الفاشلة؛ ولتستنبط القواعدَ نموذجٌ لا إنسان، وتُضاف بعد توليدها إلى نهاية السياسة الأصلية؛ ثم قارن على مجموعة النقل بين السياسة الأصلية والنسختين المتطورتين. ولا يُستبدل بين الأذرع الثلاثة سوى ملف السياسة، ويبقى محاكي المستخدم ثابتًا.

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

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

التجربة 9-3 ★★: تحسين المطالبة النظامية لخدمة عملاء الطيران انطلاقًا من المسارات الفاشلة

هدف التجربة: أن يصحّح وكيلُ خدمة عملاء الطيران سلوكَ «التحويل المبكر إلى موظف بشري عند أي خلاف عادي حول السياسة»، مع الإبقاء على قدرة التحويل عند الطلب الصريح لموظف بشري وعند حوادث السلامة.

وصف التجربة: تُستخلص من المسارات الفاشلة ثلاثة أبعاد — الالتزام بالقاعدة، وحلّ المهمة، والبديل الموافق للأنظمة — ويُولَّد رقعة Prompt دنيا واحدة مقترنة بمصدرها، ثم تُقارَن بالنسخة الأولى وبنسخة مضبوطة يدويًا في الظروف نفسها. ولا يدخل مقترح التحديث مرحلةَ الطرح التدريجي إلا بعد أن تتحسن حالات الحدود، وألا تتراجع المهام القديمة، وأن يجتاز بوابة الإصدار.

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

المثال الثاني: مهارة توضيح المتطلبات — من “البدء المباشر” إلى “التأكيد أولاً ثم التنفيذ”

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

هذه مشكلة إجرائية نموذجية. يقول المستخدم: «عدّل صفحة تسجيل الدخول لتدعم الدخول المؤسسي». فإن باشر الوكيل فورًا، فقد يتخذ نيابةً عن المستخدم خياراتٍ لم يفكر فيها بعد بشأن مزوّد الهوية، وطريقة التراجع، والتوافق مع المستخدمين القدامى، ونطاق الإطلاق. وإن هو، بغضّ النظر عن حجم المهمة، صفّ عشرات الأسئلة، تحوّل تعديلٌ بسيط إلى مقابلة. فالسؤال القليل جدًا يؤدي إلى إعادة العمل، والسؤال الكثير جدًا يؤدي إلى الإزعاج. وما ينبغي أن يعبّر عنه الـ Skill ليس «كل مهمة تحتاج إلى تأكيد»، بل مسارَ حكمٍ ذا نطاق.

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

ويبدأ التطور المستمر من أدلة التشغيل. فينبغي أن يسجّل النظام معًا: المهامّ، وأسئلة التوضيح، ونسخ الـ Spec، وتعديلات المستخدم، ونتائج التنفيذ، وإعادة العمل بعد التسليم. وقد تكون التغذية الراجعة السلبية «ما أُنجز ليس ما تخيلته»، وقد تكون «أنت تسأل أكثر من اللازم»؛ أما الإيجابية فتشمل تسليمًا سلسًا بعد تأكيد واحد، وانخفاض إعادة العمل بعد أن عدّل المستخدمُ الـ Spec بنفسه، ومهامَّ منخفضة الخطورة لم تقطعها أسئلة زائدة. ولا يكفي حفظ شكوى منفردة لتفعيل تحديث؛ بل يجب ربط التغذية الراجعة بمسارٍ محدد وبنوع المهمة وبالنتيجة.

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

ويحتاج هذا الإجراء إلى التحقق بتجربة ضابطة. إذ يمكن مقارنة ثلاث استراتيجيات — «التنفيذ المباشر»، و«السؤال ثم التنفيذ»، و«السؤال ثم توليد Spec والتأكيد ثم التنفيذ» — مع التقسيم الطبقي بحسب تعقيد المهمة. وينبغي أن تشمل المؤشرات على الأقل: نسبة الانحراف عن المتطلَّب، وعدد مرات إعادة العمل بعد التسليم، وعدد جولات التوضيح، والزمن حتى أول ناتج مفيد، ونسبة انسحاب المستخدمين، ونسبة الـ Spec التي عُدِّلت، ونسبة الخطأ في العمليات عالية الخطورة. ولا يبلغ مقترحُ التحديث مرحلةَ الطرح التدريجي إلا إذا قلّل الانحراف عن المتطلَّب من غير أن يزيد الإزعاجَ زيادةً ملحوظة، واجتاز الانحدار على مهام لم تشارك في الاستخلاص.

ويوضّح هذا المثال أيضًا الحدَّ الفاصل بين الـ Skill والـ Harness. فالـ Skill مسؤول عن فهم السياق وطرح الأسئلة بمبادرة منه، وترتيب الـ Spec، وشرح المفاضلات؛ والـ Harness مسؤول عن رفض الكتابة عالية الخطورة، أو العمل المباشر على main، أو الالتفاف على مسار الإصدار عند غياب التأكيد. ولا يستطيع رافضُ الـ Harness أن يقرّر بدلًا من النموذج كيف يوصَف الـ PR، ولا أن يختار عنه حلّ المتطلَّب. ومع تراكم الخبرة، يمكن أن تنتج مساراتُ الحوار المستقرة كذلك بيانات تدريب SFT أو RL التي يحتاج إليها الفصل الثامن.

التجربة 9-4 ★★: تطوير Skill توضيح المتطلبات وتأكيد الـ Spec انطلاقًا من تغذية المستخدمين الراجعة

هدف التجربة: اختبار قدرة الوكيل على إيجاد استراتيجية توضيح أفضل بين «الانحراف عن المتطلَّب» و«إزعاج التفاعل»، وكتابة التحسينات المتحقَّق منها في الـ Skill.

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

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

تحويل الخبرة إلى برامج

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

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

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

في إعداد المتصفح، تصبح عملية تقطير المعرفة الموضحة في الشكل 9-4 دورة حياة أكثر واقعية:

1. التقاط المسار: سجل التنقل والنقرات وإدخال النص واختيار القائمة المنسدلة، بالإضافة إلى معلمات الإجراء وعنوان URL الحالي وأدلة محدد موقع العناصر مثل XPath وCSS وid وrole وaria-label وdata-testid. يساعد دليل تحديد الموقع في العثور على العنصر مرة أخرى فقط؛ ولا يثبت أن المهمة قد اكتملت.
2. المعلمات: استبدل القيم الحرفية من التشغيل الأول بمتغيرات القالب — على سبيل المثال، تحويل test@example.com والموضوع والنص إلى {recipient} و{subject} و{content} — مع ترك الإجراءات الثابتة دون تغيير. يستخدم تنفيذ التدريس التعبيرات العادية واستبدال القالب؛ قد يستخدم نظام الإنتاج مدخلات مهمة منظمة أو نموذج استخراج مقيد.
3. تحديد عمليات التحقق من الحالة: أضف عمليات التحقق قبل الإجراءات وبعدها، مثل “زر الإرسال مرئي” و”عنوان URL بعد التنقل ينتمي إلى الموقع المستهدف”. أضف فحص الحالة النهائية لسير العمل ككل، مثل “تحتوي قائمة البريد المرسل على الرسالة الجديدة” أو “تغيرت قيمة حالة صفحة الاختبار كما هو متوقع”. إن تنفيذ الإجراء بنجاح ليس هو نفسه إكمال المهمة بنجاح؛ يجب أن يقرأ الفحص النهائي الصفحة الحقيقية أو حالة الواجهة الخلفية.
4. التحقق من صحة المرشح: النجاح الأول ينتج عنه candidate فقط. يجب على النظام إعادة تعيين حساب وضع الحماية أو موقع الاختبار إلى حالة أولية مستقلة وإعادة تشغيل المرشح بالكامل. يمكن نشره كـ validated فقط في حالة اجتياز جميع عمليات فحص ما قبل الإجراء وما بعده والحالة النهائية. إذا كانت إحدى المهام ذات التأثير الجانبي، مثل إرسال البريد أو تقديم طلب، لا تحتوي على إعادة اتصال آمنة لإعادة التعيين، فقد يتم الاحتفاظ بسير العمل كمرشح قابل للتدقيق ولكن يجب عدم التحقق من صحته من خلال تكرار الإجراء في حساب الإنتاج.
5. المطابقة وإعادة التشغيل: عند وصول مهمة جديدة، ابحث في مكتبة القدرات الرسمية عن سير العمل حسب النية والكلمات الرئيسية، واستخرج المعلمات الحالية، وقم بتنفيذها مباشرة باستخدام Playwright. لا تتطلب إعادة التشغيل مكالمات LLM خطوة بخطوة، ولكن لا يزال يتعين عليها الانتظار حتى تصبح العناصر متاحة وإكمال كل فحص للحالة.
6. إبطال وإعادة التعلم: إذا تعذر العثور على العنصر المستهدف، أو فشل فحص الحالة، أو تغير مخطط API، أو كانت الحالة النهائية خاطئة، فأوقف الإجراءات اللاحقة على الفور، وانقل الإصدار القديم من المكتبة القابلة للبحث إلى منطقة invalid، ثم ارجع إلى الوكيل الكامل لاستكشاف جديد. احتفظ بالملف القديم للتدقيق والمقارنة، لكن لا تسمح له مطلقًا بمواصلة المطابقة بصمت.

بالنسبة لسير عمل البريد الإلكتروني، فإن النتيجة المجمعة ليست مجرد “النقر على هذه الأزرار بالترتيب”، بل هي برنامج صغير يتم تحديد معلماته حسب المستلم والموضوع والنص: فهو يتحقق من نافذة الإنشاء والحقول قبل الإرسال، ويتحقق من مؤشر النجاح بعد ذلك، ويؤكد أخيرًا ظهور الرسالة المقابلة في القائمة المرسلة. في PreAct⁸، قدمت هذه البرامج تسريعًا شاملاً بمعدل 8.5–13× للمهام المتكررة ولم تتطلب مكالمات نموذج اللغة خطوة بخطوة أثناء إعادة التشغيل. والأهم من ذلك، تحتاج ذاكرة العملية إلى التحقق من صحة الإجراء، والتحقق من صحة ما بعد الإجراء، والتحقق من صحة ما قبل التخزين المستقل. وبخلاف ذلك، يمكن للنظام أن ينتج وهمًا خطيرًا: تغطية إعادة التشغيل بنسبة 100 بالمائة وتم النقر على كل زر، ومع ذلك كان هناك حقل واحد فارغ ولم تكتمل المهمة فعليًا أبدًا.

التجربة 9-5 ★★★: إنشاء مسارات عمل يمكن التحقق منها من مسارات المتصفح

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

سيناريو من أربع مراحل: في المرحلة الأولى، قم بتشغيل “إرسال رسالة بالموضوع “اختبار البريد الإلكتروني” إلى test@example.com” على موقع بريد اختباري أو صفحة رسائل محاكاة. يستكشف الوكيل الكامل، بينما يلتقط المجمّع الإجراءات والمعلمات وحالات الصفحة وينتج candidate. في المرحلة الثانية، اتصل بـ validation_reset لاستعادة وضع الحماية وإعادة تشغيل سير العمل بالكامل بشكل مستقل؛ لا يدخل المرشح إلى مكتبة القدرات الرسمية إلا في حالة اجتياز جميع فحوصات ما قبل الإجراء وبعده وفحوصات الحالة النهائية. في المرحلة الثالثة، قم بتنفيذ نفس النوع من المهام مع مستلم وموضوع وجسم مختلف. يجب أن يطابق النظام سير العمل الذي تم التحقق منه، وملء المعلمات الجديدة، وإعادة تشغيله من خلال Playwright دون الدخول في حلقة LLM خطوة بخطوة. في المرحلة الرابعة، قم بتغيير محدد موقع الزر أو نص الصفحة أو الحالة النهائية وتحقق من أن سير العمل القديم يصبح على الفور invalid ويقوم بإرجاع fallback_required=True.

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

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

يتوفر التنفيذ المصاحب في مشروع browser-use-rpa، والذي يوفر عرضًا توضيحيًا لآلة الحالة الحتمية ومسار تنفيذ يستدعي وكيل متصفح حقيقي.

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

إن جعل التصحيح صغيرًا لا يكفي للإسناد الموثوق به. يجب أن يكون كل طلب تعديل أيضًا عقد تغيير قابل للتزوير يسجل أدلة الفشل، والسبب الجذري المستنتج، ومكون الأدوات المسؤول، وتغيير المرشح، والسلوك المتوقع تحسينه، والسلوك الحالي الذي قد يتراجع، واختبارات لكليهما. تصف شركة Agentic Harness Engineering ذلك من حيث إمكانية ملاحظة مستوى المكونات والخبرة والقرار: كل مكون قابل للتحرير له تمثيل على مستوى الملف؛ يتم استخلاص مجموعات كبيرة من المسارات وتحويلها إلى أدلة يمكن فحصها بمستويات متزايدة من التفاصيل؛ ويعلن كل تعديل عن توقع التأثير قبل التنفيذ، والذي يتم بعد ذلك اختباره في الجولة التالية من النتائج⁹. يمكن بعد ذلك ربط النتيجة الأعلى بآلية محددة بدلاً من البقاء تجربة غير قابلة للتفسير.

يجب ألا يستقبل المولد المرشح الحالات الفاشلة فقط. يوفر Self-Harness أيضًا السلوك الناجح الذي يجب الحفاظ عليه وسجلات التعديلات المرفوضة مسبقًا¹⁰. يخبر الأول الوكيل بما يجب ألا ينكسر الإصلاح؛ فهذا الأخير يمنعها من إعادة طرح نفس الفكرة الفاشلة بكلمات مختلفة. تحدد أدلة الفشل، وقيود النجاح، والمحاولات السابقة معًا مساحة مرشحة محددة وتكون أكثر فائدة من التحميل العشوائي لجميع التعليمات البرمجية المصدر والسجلات الأولية في الوكيل المعدل.

يتبع إنشاء الأدوات البروتوكول نفسه. وتعرض Alita¹¹ حالة يُطلب فيها من الوكيل استخراج الرقم المذكور مباشرة بعد أول ظهور للديناصورات في مقطع YouTube بزاوية 360 درجة يرويه ممثل صوت شخصية Gollum في The Lord of the Rings. وحين يكتشف الوكيل أنه لا يملك وسيلة لقراءة النص المصاحب، يبحث عن مكتبة youtube-transcript-api ويختبرها، ثم يغلفها في أداة جديدة لاستخراج النص، ومنها يصل إلى الإجابة 100000000. ولا تدخل الأداة الجديدة مكتبة قدراته إلا بعد اجتياز فحص أمني واختبارات وظيفية وإثبات فائدتها في مهام لاحقة. يبحث الفصل الرابع عن الأداة المناسبة بين الأدوات الموجودة، ويشرح الفصل الخامس كيفية كتابة أداة، أما هذا الفصل فيسأل: ما الدليل التشغيلي الذي يبرر إنشاءها، وكيف تصبح الأداة الجديدة قدرة موثقة طويلة الأمد؟

التجربة 9-6 ★★★: تحفيز التعديل الذاتي للعامل من مسارات الفشل

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

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

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

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

التنفيذ المصاحب متاح في مشروع self-modifying-agent. وهو يدعم إما مولد مرشح حتمي أو وكيل تشفير LLM حقيقي، مع مشاركة كلا المسارين في نفس بوابة الإصدار.

تطبّق التجربة 9-7 البروتوكول نفسه على طبقة التحقق. لا يُنشأ طلب تعديل إلا عندما تشير تصحيحات متعددة من المستخدمين وتقييمات سلبية وتدقيقات لاحقة إلى عملية عالية المخاطر بلا تأكيد؛ ويُكتب المرشح في دليل معزول. يصنّف النظام عمليات الحذف الخطرة وgit push --force من اسم الأداة ومعاملاتها، ويربط رمز تأكيد أحادي الاستخدام بالعملية المحددة. يجب أن ينجح المرشح في فحوص AST/الفحوص الساكنة وإعادة تشغيل الحالات الحدّية (بما فيها الرموز المزيفة والمعاد استخدامها) ومجموعة الاحتفاظ.

التجربة 9-7 ★★: بوابة تأكيد للعمليات عالية المخاطر تُحدّثها ملاحظات المستخدم

تُستخدم الإشارات الثلاث ومسارات الضبط في failure_trajectories.json. فشل مرشح gpt-4o-mini الحقيقي في إعادة تشغيل المهام غير المكتملة والعمليات العادية وفحص الرمز أحادي الاستخدام، فرفضته بوابة الأمان. اجتاز المرشح الحتمي كل الفحوص وحصل على release_to_canary، مع تسجيل الفحوص والقرار وتجزئة الدليل المستقر. التنفيذ في harness-safety-gate.

حالة: التطور الذاتي في DeepSeek Harness، حيث كل شيء إضافة

يصنّف جدول الفصل الأول DeepSeek Harness (dsh) بوصفه «إطارًا للتطور الذاتي للوكلاء»¹². وتشير ورقة Cordis، أساسه النظري، إلى أن التركيب التقليدي ثابت: استدعاءات الدوال واستيراد الوحدات ووراثة الأصناف تُحسم وقت التجميع ولا تتغير أثناء التشغيل. أما أنظمة الإضافات وHarness ذاتي التطور فتحتاج إلى تركيب ديناميكي تُحمّل فيه المكونات وتُزال ويعاد إعدادها أثناء التشغيل¹³. وكل تعديل ذاتي يجريه Agent هو في جوهره عملية تركيب ديناميكي.

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

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

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

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

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

وللتطور كلفة أيضًا. تغيّر الإضافة العاملة مجموعة الأدوات ومقاطع الموجّه التي يراها النموذج؛ وحين تتغير بادئة الطلب يبطل KV Cache المذكور في الفصل الثاني من موضع التغيير. لذلك ينبغي لوثائق إضافة dsh أن تصف أثرها في السياق وKV Cache.

ترسيخ الخبرة في المعلمات

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

لا يتم تحديد ما إذا كان ينبغي تحديد معلمات للقدرة فقط من خلال ما إذا كانت المهمة مستقرة على المدى الطويل. قد تظل تحولات المجال الناتجة عن معدات التصوير الجديدة تتطلب LoRA أو الضبط الدقيق المستمر؛ ويمكن أيضًا استيعاب الأنماط اللغوية سريعة التغير من خلال التدريب الدوري على التفضيلات. يؤثر الاستقرار على تكرار التحديث والتكلفة، ولكن الطبيعة التمثيلية للقدرة تحدد وسطها الأساسي. وعلى العكس من ذلك، فإن القاعدة طويلة الأمد للموافقة على عمليات النقل لا ينبغي أن تعتمد فقط على الذاكرة البارامترية؛ يجب أن يظل الكود من جانب الخادم يوفر ضمانات حتمية.

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

من تحديث المخرجات إلى تحديث «طريقة التحديث»

تجيب الطرق الأربع السابقة عن سؤال أين تُحفظ الخبرة؟ لكن للتطور المستمر محورًا آخر مستقلًا: هل يحسّن النظام محتوى عنصر بعينه، أم يحسّن الطريقة التي تنتج العناصر وتديرها وتتحقق منها؟ وعلى هذا المحور قد يتسع هدف التحسين تدريجيًا من قاعدة أو ذكرى منفردة ← سياق منظم ← سير عمل ← شفرة منظومة التشغيل ← شفرة المحسّن الذي يولّد الحلول المرشحة¹⁴. ولا تمثل هذه السلسلة خمس وسائل تخزين جديدة، بل خمسة مستويات لمساحة البحث؛ فقد تظهر المعرفة والموجّهات والمهارات والبرامج في أكثر من مستوى.

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

في المستوى التالي لا يعود التحسين مقتصرًا على محتوى السياق، بل يشمل طريقة بنائه. تفصل هندسة سياق التعريف (MCE) المهمتين في حلقتين: تحسّن الحلقة الداخلية عناصر السياق للمهمة الحالية ضمن طريقة إدارة ثابتة، بينما تستفيد الحلقة الخارجية من نتائج تشغيلات واختبارات متعددة لتعديل عمليات البحث والاختيار والتصفية والتنسيق نفسها¹⁶. والفرق جوهري؛ فتعديل قاعدة استرجاع يغيّر آلية إدارة المحتوى، أما مقارنة آليات متعددة للاسترجاع والتنظيم والاحتفاظ ثم اختيار الأقدر على الانتقال بين المهام، فهي تعلّم لطريقة إدارة السياق ذاتها.

وتمتد الفكرة نفسها إلى سير العمل ومنظومة التشغيل بكاملها. يمثّل AFlow سير العمل المؤلف من استدعاءات متعددة للنموذج اللغوي على هيئة رسوم بيانية برمجية، ثم يبحث في تركيبات العقد وتدفق التحكم مستفيدًا من ملاحظات التنفيذ¹⁷. وفي Meta-Harness يفحص وكيل برمجي شفرة منظومة تشغيل مرشحة ونتائجها ومساراتها، ثم يبحث في الشفرة التي تحدد كيفية تخزين المعلومات واسترجاعها وعرضها¹⁸. قدّم الفصل الخامس الشفرة بوصفها لغة عامة للتعبير عن بنية نظام الوكيل؛ والجديد هنا أن الشفرة، مع سجل تقييمها، قد تصبح موضوعًا للتحسين المستمر بدل أن تكون مخرجًا يُنتج مرة واحدة.

التجربة 9-8 ★★★: ماذا يحدث إذا أعطينا Hermes هذا الكتاب؟ هل يستطيع ترقية نفسه؟

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

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

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

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

بناء حلقة تطور مستمر قابلة للعمل طويلًا

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

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

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

حلقة الاكتشاف: فرضية، تجربة، تقييم، تغذية راجعة. تتبع أنظمة التطور الذاتي مثل Voyager حلقة اكتشاف تتكون من فرضية وتجربة وتقييم وتغذية راجعة، وهي المنهج العلمي المتراكم عبر القرون. وقد اقترحت Discovery Loop، التي أسسها حديثًا Jeff Dean وزملاؤه، أتمتة الحلقة: اقتراح تجربة وتنفيذها وتقييمها وأخذ نتيجتها وإطعامها للجولة التالية²⁰. وهذا تطبيق للتطور الذاتي في العلم. ولكي لا يروي Agent لنفسه قصة نجاح ثم يصدقها، يجب أن يلتزم التطور الوارد في هذا الفصل بالمنهج العلمي.

في التطور المستمر يجب فصل قدرتين تختلطان كثيرًا. قدرة Harness على التحديث تنتج من المسارات تعديلات نافعة ودائمة؛ وقدرة الاستفادة من Harness هي قدرة Agent المنفذ على العثور على التعديلات وتنشيطها واستخدامها لاحقًا. قد تكون Skill صحيحة تمامًا، لكن نموذجًا أضعف لا يحملها في الموقف المناسب أو لا يتبعها طويلًا، فيبدو المجموع كأن شيئًا لم يتطور. لذلك لا يشخّص المجموع الشامل جودة نظام التحديث. وتبين تجارب تبديل النماذج لدى Lin وآخرين أن علاقتي القدرتين بقدرة النموذج الأساسي مختلفتان²¹.

جدول 9-3 مقاييس التقييم الطبقية للتطور المستمر

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

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

إن إصلاح الحالة الفاشلة الحالية فقط أثناء انخفاض الأداء في الحالات الأخرى الموجودة أو في المجالات الجديدة لا يشكل تطورًا مستمرًا ناجحًا.

التجربة 9-9 ★★★: تقييم ما إذا كان الوكيل يتطور باستمرار

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

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

مجموعات التحكم: static لا توجد تعليقات مستمرة. يتذكر append_only الإصدار الأول من القاعدة ولكن لا يمكنه حل التعارضات أو سحبها. يقوم evolving بتخزين الإصدارات واستبدال القواعد القديمة بأدلة جديدة. يتحقق التنفيذ المرجعي من أن أداة التقييم يمكنها التمييز بين هذه السلوكيات. يمكن للتجربة الحقيقية أن تضع LLM خلال نفس التدفق المرتب المكون من 14 مهمة، ولكن يجب حساب النتائج بواسطة أداة خارج النموذج.

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

التنفيذ المصاحب متاح في مشروع self-evolution-eval. بشكل افتراضي، يقوم بمقارنة ثلاثة وكلاء مرجعيين: قابل للتحديث، وإلحاق فقط، وثابت. استخدم --profile llm للحصول على LLM الحقيقي يخضع لنفس تدفق المهام طويل المدى.

حدود حلقة يمكن التحقق منها: عندما لا يعني “الانتهاء” “التقدم”

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

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

تتطلب هذه المهام تغييرات في هيكل الأدلة والإشراف، وليس مجرد نموذج يكتب أوراقًا بحثية أفضل:

• فصل الادعاءات عن الأدلة: سجّل مصادر الاستشهادات والأرقام والأساليب والاستنتاجات كلًّا على حدة؛ فالوثيقة النهائية ليست سوى عرض واحد لرسم الأدلة. ويربط تصميم «سلسلة الأدلة» في ScientistOne كل فئة من الادعاءات بمصادر قابلة للتدقيق. يحسّن ذلك قابلية التتبع، لكنه لا يجعل سؤال البحث ذا قيمة في حد ذاته²³.
• الاحتفاظ بالنتائج السلبية: اكتب التجارب الفاشلة والمرشحات المرفوضة وأسباب التوقف في سجل غير قابل للتغيير بنفس حالة الاسترجاع مثل النجاحات. وإلا فإن وحدة التطور ترى الناجين فقط، وتعيد النظر في المسارات التي تم دحضها، وتتعلم تفسير النتائج الغامضة على أنها نجاح.
• الحفاظ على تنوع البحث: يجب ألا يحتفظ البحث المفتوح بالسلسلة الحالية ذات أعلى الدرجات فقط. يجب أن تحافظ مجموعة المرشحين أيضًا على بعض الفروع ذات الدرجات المنخفضة ولكنها مختلفة بشكل كبير حسب الآلية أو حداثة الكود أو نوع الفرضية، بحيث لا يتقارب كل حل في نفس القالب سهل التسجيل.
• ارتقاء بالمشاركة البشرية إلى أعلى: لا تقتصر المدخلات البشرية على الموافقة على استدعاءات الأدوات الخطيرة. ويتضمن أيضًا تحديد المشكلات ومراجعة معايير التقييم وتفسير النتائج الشاذة وتحديد متى تتوقف. وفي ظل التغذية الراجعة الغامضة، يصعب أتمتة هذه الأحكام عالية المستوى - وأكثر قيمة - من تولي خطوات التنفيذ الفردية.

حدود الأمان للتطور المستمر

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

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

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

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

التعلم أثناء السكون: الدمج والنسيان وصون القدرات

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

تتكون دورة التعلم أثناء النوم النموذجية من خمس خطوات:

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

ذاكرة المستخدم هي المثال الأكثر بديهية، ولكن يجب تمييزها عن تجربة العمل. تحتفظ الذاكرة التلقائية لـ Claude Code بفهرس MEMORY.md وملفات التفاصيل الخاصة بالموضوع لكل مشروع. عند بدء الجلسة، يقوم بتحميل بادئة محدودة فقط من الفهرس ويقرأ المحتوى المتبقي عند الطلب؛ عندما يقترب الفهرس من الحد الأقصى، يُطلب من الوكيل دمج التفاصيل أو نقلها إلى مكان آخر. يوضح هذا أنه حتى ذاكرة النص العادي تتطلب حدودًا للسعة وتحميل متعدد الطبقات وتنظيمًا نشطًا. تقوم الآلية الموثقة حاليًا بكتابة الذاكرة بشكل أساسي أثناء الجلسات ولا ينبغي ببساطة أن تكون مساوية لمهمة خلفية ليلية ثابتة ²⁴.

يقدّم هيرميس مثالًا أكمل على تطور الذاكرة في الخلفية. فهو يوزع المعلومات طويلة الأمد بين ملفي MEMORY.md وUSER.md، وبحث SQLite/FTS5 في الجلسات السابقة، ومهارات تُحمّل عند الطلب، ومزوّدي ذاكرة خارجيين اختياريين مثل Honcho. ويعيد بحث الجلسات الرسائل الأصلية بدل تلخيصها أولًا بنموذج لغوي، فيبقى الاسترجاع منفصلًا عن التوليد وقابلًا للتدقيق. وحين تتضمن المهمة استدعاءات أدوات كثيرة، أو تتعافى من خطأ أو طريق مسدود، أو تتلقى تصحيحًا من المستخدم، أو تكشف سير عمل غير واضح، تستطيع مراجعة الخلفية إنشاء مهارة محلية أو تنقيحها. كما يمكن تمرير الكتابة في الذاكرة والمهارات عبر بوابة موافقة. ويتولى مكوّن مستقل متابعة استخدام المهارات وتدهورها وأرشفتها، ويجري تقليمًا موجّهًا في أوقات الخمول، ويمكنه الاستعانة بنموذج لغوي لدمج المحتوى. وتُؤخذ لقطات قبل التغيير كي يسهل التراجع عن أي دمج خاطئ²⁵.

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

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

ملخص الفصل

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

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

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

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

أسئلة للتأمل

1. ★★ وثيقة الخبرة مدعمة بثلاثة مسارات ناجحة ومسار واحد فاشل. حدث الفشل مع إصدار API الأحدث. كيف يجب على النظام تحديد ما إذا كانت التجربة قد تم إبطالها أو تغيرت شروط تطبيقها؟
2. ★★ يزداد رضا المستخدم لدى وكيل خدمة العملاء، ولكن معدل انتهاكات القواعد يرتفع أيضًا. لماذا لا يكون الرضا بمثابة إشارة التعلم الوحيدة؟ كيف يمكنك تصميم مقاييس ضوابط الأمان؟
3. ★★★ يمكن التخفيف من نفس مشكلة “الوعد الكاذب” من خلال الموجّهات أو عمليات التحقق من الموارد أو التدريب على المعلمات. ما الدليل الذي ستستخدمه لاختيار مكان إجراء التعديل؟
4. ★★★ يجوز للوكيل تعديل الأدوات وأدوات التحقق من الصحة، ولكن لا ينبغي السماح له بتعديل الجذر الموثوق الذي يوافق على التحديثات الخاصة به. كيف يمكنك فصل الأذونات وحدود التعليمات البرمجية لهذين الجزأين؟
5. ★★ مع نمو قاعدة معارف الخبرة، قد تؤدي أخطاء الاسترجاع وتضارب المعرفة إلى تعويض فوائد التعلم. كيف ينبغي تصميم آليات الإصدار والنضارة والتقاعد؟
6. ★★★ يُعد تعلم المعلمات فعالاً بالنسبة لأسلوب اللغة الطبيعية ولكنه يواجه صعوبة في ضمان قواعد عمل صارمة. صمم مخطط التطور المستمر لخدمة العملاء الطبيين الذي ينسق المعلمات والمعرفة والمهارات وقيود مستوى الكود.