إجابات مرجعية لأسئلة التأمل

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

الفصل الأول: البدء مع وكلاء الذكاء الاصطناعي

1. (★★) إذا كان بإمكانك إضافة قدرة واحدة فقط إلى نظام الوكيل - نموذج أقوى، أو سياق أكثر ثراء، أو المزيد من الأدوات - فما الذي ستختاره؟ تحت أي ظروف قد يتغير اختيارك؟

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

2. (★★★) في حلقة ReAct، تتلقى كل استدعاءات LLM الخاصة بالوكيل مسار التاريخ الكامل، لذا مع نمو المسار، تنمو تكلفة هذا التصميم بشكل تربيعي. هل يمكن كسر هذا النمو التربيعي دون فقدان المعلومات المهمة؟

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

3. (★★) يعني نموذج "النموذج بوصفه وكيلًا" أن النماذج أصبحت أكثر استقلالية في قرارات استدعاء الأدوات. ومع ذلك، يرى هذا الفصل أن أهمية هندسة منظومة التشغيل تتزايد بالفعل. فكيف يمكن أن يتعايش هذان الاتجاهان؟ أين تكمن القيمة الأساسية المستقبلية لأطر عمل الوكيل؟

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

4. (★★) في تجربة الاستئصال، أدى غياب "التغذية الراجعة لنتائج الأداة" إلى وقوع الوكيل في حلقة لا نهائية. في بيئة الإنتاج، إلى جانب فقدان نتائج الأداة، ما هي المواقف الأخرى التي قد تتسبب في تكرار الوكيل؟ ما هي آليات الكشف والإنهاء التي ستصممها؟

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

5. (★) حلّل هذا الفصل خمسة منتجات قائمة على الوكلاء من خلال ثلاثة أبعاد: سياق العمل، وواجهات الفعل، والاستراتيجية. اختر منتجًا تستخدمه يوميًا وحلّله بالأبعاد نفسها. هل بنيته ملائمة لغرضه؟ وما الذي كنت ستغيّره لو توليت تصميمه؟

مفتوحة. النقاط الأساسية: باتباع الجدول الموجود في الفصل، اكتب العيون (ما هي مصادر المعلومات التي يمكنه رؤيتها)، واليدين والقدمين (ما إذا كانت مساحة العمل مفتوحة، وما إذا كان يمكنه التفكير داخليًا)، والاستراتيجية (نمط حلقة تنفيذ الوكيل).

6. (★★) إذا كنت ستقوم بتصميم نظام خدمة عملاء خصيصًا لحجز الرحلات الجوية، فهل ستختار نمط سير العمل أم نمط الوكيل المستقل؟ هل من الممكن المزج بين كلا النموذجين في نفس النظام؟

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

7. (★★★) ذكر قسم ضوابط الأمان تصنيفات مخاطر الأداة. إذا كانت الأداة منخفضة المخاطر بشكل عام ولكنها تصبح عالية الخطورة مع مجموعات معلمات محددة (على سبيل المثال، delete_file حذف ملف عادي مقابل حذف ملف نظام)، فكيف يمكنك تصميم تقييم ديناميكي للمخاطر؟

قم بتحسين هدف التصنيف من "أداة" إلى "أداة + وسيطات": حساب المخاطر في وقت الاتصال بناءً على إمكانية الرجوع والأذونات ونصف قطر الانفجار. استخدم عمليات التحقق الحتمية القائمة على القواعد (القوائم المسموح بها/قوائم الحظر، والتعبيرات العادية) بدلاً من الحكم النموذجي. يجب أن ينظر التحقق من الصحة فقط إلى البيانات المنظمة للحماية من التلاعب بحقن الموجّهات.

8. (★★) في جدول منتجات الوكلاء في هذا الفصل، يتمتع جميع الوكلاء بمساحة عمل "مفتوحة النهاية". في أي سيناريوهات تكون مساحة العمل المقيدة (على سبيل المثال، القدرة فقط على الاختيار من بين الخيارات المحددة مسبقًا) أفضل من المساحة المفتوحة؟

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

9. (★★) تتطلب آلية التدخل البشري من الوكيل "تسليم السيطرة بأمان". ومع ذلك، من الناحية العملية، قد يكون المستخدم غير متصل بالإنترنت، أو يستجيب ببطء، أو يعطي تعليمات غامضة. ماذا يجب على الوكيل أن يفعل في مثل هذه الحالات؟

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

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

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

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

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

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

الفصل الثاني: هندسة السياق

1. (★★★) وجدت التجربة 2-3 أن النافذة المنزلقة لسجل المحادثة تؤدي إلى قيام الوكيل بتنفيذ نفس استدعاءات الأداة بشكل متكرر. ومع ذلك، يؤدي الاحتفاظ بالتاريخ الكامل إلى توسيع السياق إلى أجل غير مسمى. صمم إستراتيجية يمكنها تجنب فقدان المعلومات مع التحكم في طول السياق، دون كسر البادئة KV Cache.

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

2. (★★) تحتفظ آلية الاحتفاظ بسلسلة الأفكار في قالب الدردشة في Qwen3 بمحتوى الاستدلال فقط "بعد آخر رسالة مستخدم حقيقية." إذا امتدت حلقة ReAct إلى مئات من استدعاءات الأداة، فقد يستهلك محتوى الاستدلال المتراكم قدرًا كبيرًا من السياق. كيف يمكنك تعديل هذه الآلية للتعامل مع الحلقات الطويلة جدًا؟ تطلبت DeepSeek R1 ذات مرة تجريد كل محتوى الاستدلال التاريخي، بينما عكست DeepSeek V4 هذا لتفرض تمرير كل reasoning_content - بمقارنة هاتين الاستراتيجيتين المتعارضتين، ما هي إيجابيات وسلبيات كل منهما؟ ماذا يشير هذا الانعكاس؟

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

3. (★★) في تجربة الضغط المدرك للسياق، الضغط من حوالي 148 ألف حرف إلى حوالي 2000 حرف - هل يؤدي هذا الضغط الشديد إلى خطر "فقدان المعلومات بشكل لا رجعة فيه"؟ كيف يمكن معالجة ذلك؟

نعم، هناك خطر: فالضغط إسقاط خاسر، وإذا وقع السؤال على بعد لم يتم الحفاظ عليه، ينكسر. الحل: "الضغط مع فقدان البيانات + الفهرسة بدون فقدان البيانات" — كل حقيقة تحمل عنوان URL مصدرًا لإمكانية التتبع؛ يتم تخزين المخرجات الأولية على القرص مع معاينات موجزة فقط في السياق؛ أولويات الاحتفاظ الصريحة - يتم الاحتفاظ بالقرارات المعمارية، والسلامة الدلالية (الأوقات، وأسماء الشركات)، وحالة التحقق، والمعرفات مثل UUIDs/التجزئة حرفيًا؛ النوافذ التكيفية تؤجل لحظة الضغط.

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

يثق النموذج في شريط الحالة دون قيد أو شرط تقريبًا، لذلك تنتشر الأخطاء كما هي. إجراءات التخفيف: ① احتفظ بها باستخدام كود حتمي - لا تسمح أبدًا لمجموعة LLM بحساب التواريخ الطويلة (إذا كان يجب عليك، فاستخرج عنصرًا تلو الآخر وقم بتجميعها في التعليمات البرمجية)؛ ② تتبع دقة شريط الحالة كمقياس إنتاج من الدرجة الأولى؛ ③ المعلومات تأتي فقط من الملاحظات الموثوقة للعالم الحقيقي، للحماية من التسمم بشريط الحالة.

5. (★★) أظهرت تجربة الاستئصال الهندسي السريع أن المعلومات غير المنظمة تؤدي إلى انخفاض معدل النجاح بنسبة تزيد عن 30%. ومع ذلك، في التطوير الواقعي، غالبًا ما تتم صيانة موجّهات النظام بواسطة عدة أشخاص في أوقات مختلفة. ما هي الممارسات الهندسية التي ستستخدمها لمنع موجّهات النظام من أن تصبح غير منظمة بشكل متزايد بمرور الوقت؟

① تعامل مع الموجّهات باعتبارها تعليمات برمجية: التحكم في الإصدار ومراجعته، حيث يقوم مديرو المنتجات بتحديد قواعد العمل ويقوم المهندسون بالتشفير؛ ② استخدم معايير نمط Tau-Bench كاختبارات انحدار، وإجراء عمليات الاجتثاث قبل التغييرات وبعدها لتحديد التأثير؛ ③ هيكل الإنفاذ: التدفق الذي يحركه SOP بدلاً من أكوام القواعد، مع طبقات XML/Markdown؛ ④ تصنيف الأجزاء وتسميتها على أنها "قابلة للتخزين المؤقت / كسر ذاكرة التخزين المؤقت"، ووضع المحتوى الديناميكي بعد حدود ذاكرة التخزين المؤقت؛ ⑤ تقسيم المحتوى المتضخم إلى مهارات يتم تحميلها حسب الطلب.

6. (★★★) يقترح هذا الفصل أن "التعلم في السياق هو في الأساس استرجاع وليس تفكيرًا". إذا كان هذا التأكيد صحيحًا، فيجب إعادة تقييم جميع اتجاهات التحسين الحالية المستندة إلى "وضع المزيد من المعلومات في السياق". كيف تعتقد أنه ينبغي التغلب على هذا القيد؟

أضف طبقة التقطير إلى "نصف محرك الاسترجاع": ① تقطير السياق / شريط الحالة - استخدم الكود لحساب الاستنتاجات مسبقًا للاسترجاع المباشر؛ ② الضغط النشط، واستبدال السجلات الأولية بالمعرفة المنظمة عالية الكثافة؛ ③ عزل الوكيل الفرعي، وإبعاد الضوضاء عن السياق الرئيسي؛ ④ التفاعل كمحور ثالث - تقوم الأدوات الخارجية بمراقبة وكتابة المعلومات الجديدة التي لم يتمكن النموذج من ابتكارها؛ ⑤ الاتجاهات الحدودية: "ملاحظات" KV Cache قابلة للتحرير والتركيب وتوحيد الذاكرة عبر الجلسات.

7. (★★★) يؤدي الكشف التدريجي للمهارات إلى تحميل المحتوى الكامل فقط عندما يرى الوكيل أن هناك حاجة إليه. ومع ذلك، يعتمد هذا الحكم نفسه على قدرة النموذج - إذا كان النموذج لا يعرف ما لا يعرفه، فلا يمكنه تشغيل تحميل المهارة بشكل صحيح. كيف يمكن حل مشكلة "ما وراء المعرفة" هذه؟

① احتفظ بالبيانات الوصفية للمهارة (الاسم والوصف) في السياق بحيث "يعرف النموذج دائمًا ما يحتويه"؛ ② اكتب وصف المهارة كشروط توجيه بدلاً من مقدمة ميزة - "استخدم متى / لا تستخدم متى" - مع تجنب الأوصاف الغامضة.

8. (★★) في آلية المهارات، بعد أن يقوم الوكيل بتحميل التعليمات ديناميكيًا من SKILL.md، هل يمكن للعمليات اللاحقة متابعتها بشكل موثوق؟ ما هي الاختلافات في دعم النموذج لنمط المهارات؟

يعتمد ذلك على كيفية حقن المهارة: الحقن في موجّه النظام يعطي أقوى التعليمات التالية ولكنه يكسر KV Cache؛ قد تؤدي قراءته كملف عادي في منتصف السياق إلى اتباع تعليمات أقل؛ الحقن في نهاية السياق يعطي تعليمات جيدة، ولكن يجب إعادة حساب KV لجزء المهارة عند كل استدعاء للأداة، وهو أمر مكلف.

9. (★★★) يؤكد هذا الفصل على أن التغييرات في المعلومات الديناميكية (على سبيل المثال، الطوابع الزمنية للنظام، وترتيب قائمة الأدوات) يمكن أن تؤدي إلى كسر نتائج البادئة KV Cache. في نظام إنتاج يحتوي على عدد كبير من الأدوات ومجموعة أدوات متغيرة بشكل متكرر، كيف يمكنك تصميم تخطيط السياق لزيادة معدل ضربات ذاكرة التخزين المؤقت إلى الحد الأقصى؟

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

الفصل الثالث: ذاكرة المستخدم وقاعدة المعرفة

1. (★★) في نظام ذاكرة المستخدم، عندما يقدم نفس المستخدم معلومات متناقضة في جلسات مختلفة (على سبيل المثال، ذكر عنوانين مختلفين للمنزل)، كيف يجب على نظام الذاكرة التعامل مع هذا التعارض؟

استخدم خط أنابيب "استخراج - مقارنة - اتخاذ قرار" بنمط Mem0: قم أولاً باسترداد الذكريات القديمة المشابهة عن طريق البحث المتجه، ثم اطلب من LLM تحديد ADD/UPDATE/DELETE/NOOP - على سبيل المثال، يجب تحديث عبارة "الانتقال إلى شنغهاي" والكتابة فوق عبارة "يعيش في بكين". تعيين الإصدار: احتفظ فقط بأحدث إصدار من معلومات نوع العنوان مع طابع زمني، ولكن احتفظ بالسجل الكامل لمعلومات نوع خبرة العمل. ومن ناحية الاسترجاع، يمكن أن تساعد البادئات السياقية (الشخص، الوقت، النية - كما في حالة التحويل البنكي المعدل ثلاث مرات) في تحديد الإدخال الصحيح في النهاية.

2. (★★) يضيف الاسترجاع السياقي سياقًا من المستند الأصلي إلى كل جزء. ومع ذلك، إذا كان المستند الأصلي نفسه فوضويًا من الناحية الهيكلية أو يحتوي على معلومات متناقضة، فقد تؤدي هذه الطريقة إلى نشر الأخطاء أو حتى تضخيمها. كيف يمكنك إدخال إشارة "جودة المعلومات" في مرحلة الاسترجاع؟

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

3. (★★★) يسمح الوكيل RAG للوكيل بأن يقرر بشكل فعال متى يبحث، وما الذي يبحث عنه، وما إذا كان سيستمر في البحث. ولكن إذا كان النموذج لا يعرف ما لا يعرفه، فلن يتمكن من تشغيل البحث بشكل صحيح. كيف يمكن حل مشكلة "ما وراء المعرفة" هذه؟

① الكود الثابت "يقيم ما إذا كانت المعلومات كافية" كخطوة صريحة في الموجّه/المهارات: كما في التجربة 3-9، قم أولاً باسترداد الأسئلة الفرعية بالتوازي، واكتشف الحلقة المفقودة - "كيف يؤثر السجل السابق على الحكم على جرائم الإهمال" - ثم قم بإجراء جولة ثانية من الاسترداد؛ ② احتفظ بالمعلومات الوصفية الخفيفة في السياق لتوفير عرض عالمي - على سبيل المثال، نظرة عامة على بطاقات JSON أو ملخصات L0/L1 الخاصة بـ OpenViking - حتى يعرف الوكيل "ما هو موجود في المتجر."

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

أمثلة: العلاقات المنطقية في مخطط بنية النظام، أو موضع تقاطع منحنيين في مخطط خطي، أو مراسلات الصفوف والأعمدة بين الخلايا والرؤوس في جدول PDF. الخيار الأول: المعالجة الأصلية المتعددة الوسائط؛ الخيار الثاني: توفير أداة متعددة الوسائط لتحليل الصور.

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

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

6. (★★★) مع تحسن قدرات النموذج، هل تعتقد أن قواعد المعرفة الخاصة بالمجال ستظل مهمة؟ هل من الممكن أن يحتوي نموذج الأساس القوي المستقبلي على جميع المعلومات الموجودة في قاعدة معارف المجال، وبالتالي إلغاء الحاجة إلى واحدة؟

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

7. (★) يبني RAPTOR فهرسًا شجريًا من خلال التلخيص الهرمي من الأسفل إلى الأعلى، بينما يبني GraphRAG فهرسًا منظمًا بالرسم البياني من خلال علاقات الكيانات. ما هي أنواع الاستعلامات التي يجيد كل من هذين الفهرسين المنظمين الإجابة عليها؟

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

8. (★★) ينظم نموذج نظام الملفات المعرفة في هيكل هرمي مشابه لنظام الملفات. بالمقارنة مع قاعدة بيانات المتجهات التقليدية RAG، ما هي السيناريوهات التي يتمتع فيها هذا النهج بميزة؟

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

9. (★★★) الاكتشاف التلقائي لـ "عوامل الحكم" و"التسلسلات الهرمية لأهمية العوامل" من البيانات المنظمة (على سبيل المثال، قواعد بيانات الأحكام القضائية) يتضمن بشكل أساسي قيام الوكيل بتحفيز القواعد من البيانات. هل يمكن لاستخلاص المعرفة المبني على البيانات أن يحقق جودة القواعد التي وضعها الخبراء البشريون يدويًا؟

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

الفصل الرابع: الأدوات

1. (★★) يفصل معيار MCP تعريفات الأداة عن إطار عمل الوكيل. ومع ذلك، يعني التقييس أيضًا أن أنماط تفاعل الأدوات المعقدة (على سبيل المثال، إخراج التدفق، والاتصالات ثنائية الاتجاه، والجلسات ذات الحالة) قد يكون من الصعب التعبير عنها ضمن بروتوكول قياسي. ما هي الإمكانية التي تعتقد أن MCP بحاجة إلى توسيعها في المستقبل؟

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

2. (★★) في بنية الوكيل غير المتزامنة، يجب تحديد إستراتيجية الأولوية لقائمة انتظار الأحداث في وقت التصميم. ولكن إذا كان حكم الأولوية نفسه يتطلب فهمًا دلاليًا (على سبيل المثال، تحديد ما إذا كانت الرسالة الجديدة أكثر إلحاحًا من المهمة الحالية)، فمن الذي يجب أن يصدر هذا الحكم - محرك القواعد أو استدعاء LLM آخر؟ ما هي تكاليف كل منهما؟

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

3. (★★) في النظام البيئي MCP، قد توفر خوادم MCP المختلفة أدوات ذات وظائف متداخلة للغاية. عندما يواجه الوكيل أدوات متعددة من مصادر مختلفة متشابهة وظيفيًا، كيف يجب عليه الاختيار؟ إذا كانت الأدوات التي تحمل نفس الاسم من مصادر مختلفة تتصرف بشكل مختلف قليلاً (على سبيل المثال، تقوم إحداها بإرجاع ملخص، بينما تقوم الأخرى بإرجاع النص الكامل)، فهل يمكن للوكيل إدراك هذا الاختلاف واستغلاله؟

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

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

الافتراضي هو الهوية الافتراضية: يمكن أن تعمل بشكل مستقل في الخلفية وتكون قابلة للتدقيق، وإذا أخطأت أو تم اختراقها، فإنها لا تكشف الهوية الرقمية بالكامل للمستخدم - تمامًا كما تستخدم السكرتيرة البريد الإلكتروني الخاص بمكتبها؛ تحتاج إلى التعامل مع مشكلات سمعة CAPTCHA/IP (الوكلاء السكنيون). السيناريوهات التي يجب أن تستخدم هوية المستخدم الخاصة (التحقق من هوية الحساب، تأكيد المكالمة الثلاثية - كما هو الحال عندما يتصل Pine بخدمة العملاء) تستخدم مصادقة الإنسان في الحلقة: يتيح VNC/RDP للمستخدم تسجيل الدخول شخصيًا ومرئيًا. المعايير: ما إذا كان الطرف المقابل يتطلب صاحب الحساب شخصيًا، ومخاطر العملية ونطاق بيانات الاعتماد.

5. (★★) في معالجة الأحداث القائمة على قائمة الانتظار، تميل النماذج إلى التركيز فقط على الحدث الأخير. يخفف هذا الفصل من هذه المشكلة من خلال علامات شريط حالة الوكيل وتلخيصها. ولكن إذا كانت قائمة الانتظار تحتوي على 20 حدثًا متراكمًا (10 نتائج أدوات + 5 رسائل مستخدم + 5 تنبيهات للنظام)، فكيف يمكنك تنظيم ترتيب العرض التقديمي وتنسيق هذه الأحداث بحيث لا يفوت النموذج المعلومات الأساسية؟

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

6. (★★) يقترح هذا الفصل حلقة "تنفيذ-التحقق من صحة-التعليقات" (على سبيل المثال، تشغيل برنامج linter تلقائيًا بعد كتابة التعليمات البرمجية). ما هي سيناريوهات الأدوات الأخرى التي يمكن تطبيق نمط "التحقق التلقائي الفوري بعد العملية" عليها؟ هل هناك عمليات تتجاوز فيها تكلفة أو مخاطر التحقق من الصحة تكلفة العملية، مما يجعل هذا النمط غير ممكن؟

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

7. (★★) يثير هذا الفصل مشكلة "انفجار الأداة" - حيث تنخفض دقة اختيار الوكيل عند مواجهة آلاف الأدوات. إلى جانب الاكتشاف الاستباقي للأداة، ما هي الأساليب الأخرى الموجودة؟ فكر في الاعتماد على كيفية تعامل الخبراء البشريين مع مجموعة كبيرة من الأدوات المتاحة.

① التجميع الهرمي: حدد أولاً موقع "الخادم/التطبيق"، ثم اختر الأداة المحددة؛ ② "استشارة عند الطلب" على نمط المهارات: مثل البحث عن كتاب مرجعي - يظل الكتالوج موجودًا في السياق، ويتم تحميل التفاصيل عند الطلب؛ ③ عدد قليل من الأدوات الأساسية شائعة الاستخدام "الموجودة في متناول اليد" المقيمة في السياق، ويمكن الوصول إلى الباقي من خلال فهرس الكتالوج.

الفصل الخامس: وكيل البرمجة وتوليد الشفرة

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

عزل الطبقة المعزولة حسب السيناريو (الحاويات/أجهزة microVM)؛ الافتراضي هو عدم وجود شبكة، مع وكيل القائمة البيضاء الذي يمنح الوصول عند الطلب؛ قم بتثبيت كود المصدر للقراءة فقط واحتفظ بمفاتيح API خارج وضع الحماية؛ تعيين حدود موارد وضع الحماية؛ إدارة دورة حياة وضع الحماية (المهلات).

2. (★★★) يؤدي تمهيد الوكيل - وهو وكيل يمكنه إنشاء وكلاء - إلى تحقيق "النسخ الذاتي للذكاء". لكن كل تكرار للتمهيد قد يؤدي إلى تحيزات أو أخطاء جديدة. فهل تتراكم هذه الأخطاء عبر الأجيال؟ كيف يمكننا منع الوكلاء الذين تم تشغيلهم من التدهور؟

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

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

التشخيص قبل التكيف: تحقق من التنسيق الجديد مقابل مستندات الهندسة المعمارية وPRD للحكم على ما إذا كان متوقعًا (فكرة التجربة 5-8)؛ التحقق من سجلات التحكم في الإصدار للتأكد من أن التغيير يتوافق مع التزام رمزي شرعي بدلاً من الانجراف بدون مصدر؛ مشابه لـ log_mismatch الخاص بـ τ-bench، حتى عندما تختار التكيف، قم بتسجيل تنبيه وتقديم مشكلة تلقائيًا بدلاً من التسامح معها بصمت؛ عندما تكون غير متأكد، الطريق إلى تأكيد الإنسان في الحلقة. المبدأ: التكيف والإبلاغ بالتوازي - يجب ألا يبتلع التكيف إشارات الشذوذ.

4. (★★) يستخدم هذا الفصل بشكل متكرر آلية المقترح والمراجع في إنشاء PPT وتحرير الفيديو وتصور السجل. إذا كانت التفضيلات الجمالية للمحكم تختلف عن تفضيلات المستخدم المستهدف - على سبيل المثال، يعتبر المحكم كثافة المعلومات معقولة، ولكن المستخدم يجدها مزدحمة للغاية - فقد تتقارب حلقة التغذية الراجعة على المستوى الأمثل المحلي الخاطئ. كيف يمكن دمج تعليقات تفضيلات المستخدم في حلقة المراجع؟

قم بإدخال ملاحظات المستخدم في مسار الوكيل باعتباره الحدث المنظم ذو الأولوية القصوى؛ إضفاء الطابع الخارجي على تفضيلات المستخدم ودمجها عن طريق كتابتها في MEMORY.md بحيث تصبح التفضيلات نافذة المفعول عبر المهام؛ تسليم المستندات بتنسيق HTML بدلاً من Markdown حتى يتمكن المستخدمون من فحصها.

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

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

6. (★) "الفرق الصديقة للعمل عن بعد غالبًا ما تكون أيضًا صديقة لوكلاء الذكاء الاصطناعي." ما مدى قرب فريقك أو مؤسستك من أن تكون "جاهزة للذكاء الاصطناعي" فيما يتعلق بتوثيق المعرفة؟ ما هو العائق الأكبر؟

مفتوحة. يمكنك التحقق ذاتيًا باستخدام مقياس الوكيل الخاص بهذا الفصل: هل يمكن للوافد الجديد عن بعد العمل بشكل مستقل باستخدام المستودع والوثائق فقط؟ قائمة المراجعة: هي القرارات المسجلة في الوثائق؛ هو السياق مكتوب في القضايا/العلاقات العامة؛ تحتوي أوامر البناء والاختبار على ملفات تعليمات مثل CLAUDE.md/AGENTS.md؛ هل تم تقطير المعرفة القبلية في أدلة المطورين؟ العائق الأكبر والأكثر شيوعًا: النقل الشفهي وثقافة السبورة البيضاء التي تعتمد على "سؤال الزميل المجاور لك" - لا يستطيع الوكيل قراءة الاتفاقيات الشفهية، بل المستندات فقط.

7. (★★★) اقترح سايمون ويليسون "الثالوث المميت" للعملاء (الوصول إلى البيانات الخاصة، والتعرض لمحتوى غير موثوق به، وقدرات الاتصال الخارجية). ويضيف هذا الفصل فصلا رابعا: الذاكرة الدائمة. في بيئة إنتاج تحتاج إلى التعامل مع العناصر الأربعة في وقت واحد، كيف يمكنك تصميم استراتيجية أمنية؟

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

8. (★★) يسمح النمط Artifact بتنفيذ كود SQL أو كود الواجهة الأمامية الذي تم إنشاؤه بواسطة الوكيل مباشرة في متصفح المستخدم أو قاعدة بياناته. ومع ذلك، قد يقوم SQL الذي تم إنشاؤه بتنفيذ عمليات مدمرة، وقد يحتوي HTML الذي تم إنشاؤه على ثغرات أمنية. كيف يمكن ضمان أمان النظام؟

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

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

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

10. (★★) يسمح النمط الاصطناعي للوكيل بإنشاء تعليمات برمجية SQL أو تعليمات برمجية مرئية للمكونات النهائية ليتم تنفيذها مباشرة، لذلك لا يتعين على LLM معالجة كميات كبيرة من البيانات. ما هي إيجابيات وسلبيات تقسيم العمل "الوكيل ينشئ التعليمات البرمجية، والنظام ينفذ التعليمات البرمجية" مقارنة بالنمط التقليدي "الوكيل يوفر الإجابة مباشرة"؟

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

الفصل السادس: تقييم الوكلاء

1. (★★) يستخدم LLM-as-a-Judge نموذجًا لغويًا لتقييم مخرجات نموذج اللغة. هل يحتوي هذا "التقييم الذاتي" على نقاط عمياء منهجية - على سبيل المثال، قد يعطي النموذج باستمرار درجات عالية لأسلوب معين من الاستجابة، وهو تفضيل لا يتوافق مع الحكم البشري؟ كيف يمكن اكتشاف مثل هذه التحيزات وتصحيحها؟

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

2. (★★★) يعد التصميم "المانع للتسرب" لمجموعات بيانات التقييم أمرًا بالغ الأهمية. ومع ذلك، في النظام البيئي مفتوح المصدر، بمجرد نشر البيانات القياسية، يتم دمجها بسرعة في بيانات التدريب. هل لهذه "لعبة القط والفأر" نهاية؟ صمم طريقة تقييم تقاوم بشكل أساسي تسرب البيانات.

لا يوجد نهاية لبنك الأسئلة الثابت، بل يمكنك فقط المطاردة. الحل الأساسي هو جعل "آلية التوليد" عامة مع الحفاظ على خصوصية "المثيلات الملموسة": قوالب ذات معلمات مثل تلك الخاصة بـ τ²-bench وAndroidWorld، والتي يتم إنشاء مثيل لها بشكل عشوائي في كل مرة، مع التحقق بناءً على حالة البيئة النهائية بدلاً من تسلسل إجابات ثابت.

3. (★★) تهدف المعايير الأربعة لـ Scale AI (توجيه الخبراء، والتغطية الشاملة، وترجيح الأهمية القياسية، والتقييم المستقل) إلى القضاء على الذاتية في التقييم. ومع ذلك، فإن بعض أبعاد المهمة (على سبيل المثال، "هل الإجابة مفيدة؟" "هل النبرة مناسبة؟") هي أبعاد ذاتية بطبيعتها. كيف يمكن تصميم نماذج موثوقة لهذه الأبعاد الذاتية؟

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

4. (★★) يقوم τ-bench بتقييم الوكلاء من خلال محاكاة سلوك المستخدم الحقيقي. لكن المستخدم الذي تمت محاكاته نفسه هو LLM - وقد يقلل بشكل منهجي من بعض حالات الحافة (على سبيل المثال، المستخدمين المضطربين عاطفيًا أو غير الواضحين). كيف يمكن التحقق من جودة محاكاة المستخدم نفسه؟

الدرس المستفاد من الإصدار الأول من τ-bench: كان جهاز المحاكاة ميكانيكيًا جدًا وتعليماته بسيطة جدًا (يمكن للوكيل تخمين الإجابات). طرق التحقق من الصحة: ​​التحقق يدويًا من حوارات المحاكاة للتحقق مما إذا كانت تتبع الكشف التدريجي ولا تقوم بتلفيق معلومات خارج النص؛ قم بإجراء اختبارات عينة صغيرة مع مستخدمين حقيقيين لمعرفة ما إذا كانت التصنيفات تتطابق مع التقييم المحاكي.

5. (★★) تفترض المقارنة الزوجية (نموذج برادلي-تيري) أن التفضيلات متعدية (إذا كان A > B وB > C، ثم A > C). ومع ذلك، غالبًا ما تنتهك التفضيلات البشرية العبورية. في تقييم الوكيل، في أي سيناريوهات قد تظهر التفضيلات غير المتعدية؟ كيف يؤثر ذلك على موثوقية التصنيف؟

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

6. (★★) يقترح هذا الفصل المنهج العلمي "لاحظ → افترض → جرب → تحقق". ومع ذلك، من الناحية العملية، فإن مساحة سلوك الوكيل واسعة، وقد يتطلب التحقق من صحة فرضية واحدة مئات من عمليات التقييم. كيف يمكن تعظيم المعلومات المكتسبة من التقييم في ظل ميزانية حسابية محدودة؟

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

7. (★) في تجربة AndroidWorld، رفعت شجرة العناصر الكاملة النجاح من 25% إلى 100%، لكنها رفعت استخدام الرموز إلى 2.498× من مجموعة الضبط؛ وحافظ التقليم على نجاح 100% مع خفض الرموز إلى 0.506×. كيف تصمم قواعد تلقائية تزيل عقد واجهة المستخدم الخالية من الدلالة من دون إسقاط معلومات لازمة لإمكانية الوصول أو التحقق من الحالة أو الإجراءات اللاحقة؟

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

8. (★★) تستخدم محاكاة مستخدم τ-bench "الكشف التدريجي عن المعلومات" - لا تقدم جميع المعلومات مرة واحدة، ولكنها تكشفها تدريجيًا بناءً على أسئلة الوكيل. كيف يؤثر هذا التصميم على نتائج التقييم؟ إذا كانت استراتيجية الكشف عن معلومات المستخدم المحاكى تختلف بشكل كبير عن المستخدمين الحقيقيين، فهل لا تزال استنتاجات التقييم موثوقة؟

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

الفصل السابع: مرحلة ما بعد تدريب النموذج

1. (★★) النسيان الكارثي - حيث يؤدي الضبط الدقيق لمهمة معينة إلى تدمير القدرات العامة الأصلية للنموذج (على سبيل المثال، استدعاء الأداة العامة) - يعد أمرًا مزعجًا بشكل خاص في سيناريوهات الوكيل. بالمقارنة مع الضبط الدقيق للمعلمات الكاملة، يقوم LoRA بتجميد الأوزان الأساسية وينطوي على خطر أقل للنسيان، لكنه ليس محصنًا. ما هي الاستراتيجيات التي يمكن أن تخفف بشكل أكبر من نسيان القدرة أثناء الضبط الدقيق؟

خلط البيانات: مزج حوالي 20% من بيانات التوزيع العامة/الأصلية بحيث لا تؤدي مشاركة المهمة الجديدة إلى سحق القدرات القديمة؛ حجم التدريب المقيد: قم بإيقاف SFT بمجرد "استقرار التنسيق ووجود القدرات الأساسية" - الإيقاف المبكر يمنع الانهيار؛ استخدم رتبة صغيرة (8–32) لـ RL واحتفظ بعقوبة KL لإبقاء السياسة بالقرب من النموذج المرجعي؛ تجميد المكونات الرئيسية (على سبيل المثال، تدريب طبقة الإسقاط الخاصة بـ VLM فقط)؛ إرفاق محولات LoRA متعددة لكل مهمة لعزل القدرات؛ إجراء اختبارات الانحدار على المعايير العامة.

2. (★★) يعمل ما بعد التدريب على ترسيخ القدرات في نماذج الأوزان ("ذاكرة العضلات")، بينما يضع التعلم في السياق المعرفة في المدخلات أثناء الاستدلال. ومع ذلك، يمكن تعلم بعض القدرات (مثل معرفة المجال) إما من خلال التدريب اللاحق أو من خلال أمثلة قليلة. ما هي المعايير التي ستستخدمها لتحديد المسار الذي يجب أن تسلكه قدرة معينة؟

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

3. (★★) يتيح تقطير النماذج لنموذج صغير تعلّم سلوك نموذج أكبر. ويمكن تقسيم النماذج المراد تقطيرها، بحسب مستوى القدرة، إلى ثلاثة أصناف تقريبية: نماذج الدردشة، ونماذج التفكير، ونماذج الوكلاء. ما التحديات الخاصة بتقطير كل صنف؟

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

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

4. (★★★) في تفاعلات الوكيل متعددة المنعطفات، تكون مشكلة تعيين الرصيد أكثر خطورة مما هي عليه في سيناريوهات المنعطف الواحد - من الصعب أن يُعزى النجاح أو الفشل النهائي إلى القرار المتخذ في الدور الثالث مقابل الدور السابع. كيف يمكنك تصميم استراتيجية تخصيص المكافأة؟

عندما تكون الخطوات المتوسطة قابلة للحكم، أضف مكافآت العملية (يعطي V-IRL ±1 لكل خطوة)؛ بعد RLVP، استخدم القواعد الحتمية لإعطاء إشارات مسار لكل إجراء، واستعادة التباين داخل المجموعة لمجموعات الفشل/التمرير بالكامل.

5. (★★★) إذا كانت لديك ميزانية ثابتة، مثل 10000 دولار أمريكي، لتحسين وكيل خدمة العملاء، فكيف يمكنك تخصيصها بين السياق والمعرفة، والموجّهات/المهارات، والقيود البرمجية، والتدريب على المعلمات؟ ما هي العوامل التي ستحدد قرارك؟

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

6. (★★★) يعتبر البعض أن التعلم النموذجي المستقل، بدون وظيفة مكافأة واضحة وبعينات نادرة، هو الهدف النهائي لمرحلة ما بعد التدريب. إلى أي مدى تبتعد أساليب التدريب الحالية RL عن هذا الهدف؟ من أين سيأتي الاختراق التالي على الأرجح؟

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

7. (★★) يشير هذا الفصل إلى أن تكلفة ضبط LoRA ليست عالية. لذا، هل من الممكن تدريب LoRA مخصص لكل مستخدم (أو كل شركة عميل)، وكتابة ذاكرة المستخدم أو معرفة المؤسسة في المعلمات، بدلاً من تخزينها في قاعدة معرفة خارجية كما في الفصل 3؟ في أي سيناريوهات يكون لـ "كتابة الذاكرة في معلمات" ميزة على "تخزين الذاكرة في قاعدة المعرفة"؟ وفي أي السيناريوهات قد يؤدي ذلك إلى نتائج عكسية؟

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

8. (★★★) يعتمد التقطير على السياسة على نموذج معلم أقوى للإشراف على الطالب. ومع ذلك، اقترح بحث التعميم من الضعيف إلى القوي الذي أجراه OpenAI نتيجة غير بديهية: يمكن للإشارة الإشرافية من نموذج ضعيف أن تطلق أحيانًا العنان للقدرات الكامنة ولكن غير النشطة في نموذج قوي. إذا تم تطبيق هذه الفكرة على تدريب الوكلاء، فهل يمكن تحقيق "نموذج صغير يعلم النموذج الكبير" بالتقطير العكسي؟

نعم، هذا ممكن - والمفتاح هو أن "التحقق أسهل من التوليد": لا ينبغي للنموذج الضعيف أن يعمل كدليل (سقف SFT هو مستوى العرض التوضيحي)، ولكن كنموذج للتحقق/المكافأة، حيث يستكشف النموذج القوي من تلقاء نفسه والنموذج الضعيف يحكم فقط.

9. (★★) يقوم نموذج مكافأة العملية (PRM) بتقييم كل خطوة تفكير، بينما ينظر نموذج مكافأة النتيجة (ORM) إلى النتيجة النهائية فقط. ولكن أيهما أحق بالمكافأة: "عملية صحيحة تؤدي إلى نتيجة خاطئة" أم "عملية خاطئة تؤدي لحسن الحظ إلى نتيجة صحيحة"؟ في سيناريو استدعاء الأدوات متعدد الخطوات للوكيل، كيف يمكنك وزن هذه الأدوات؟

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

10. (★★★) يمكن استخدام مجموعات بيانات التقييم التي تمت مناقشتها في هذا الفصل (على سبيل المثال، SWE-Bench Verified، τ²-bench، AndroidWorld) لكل من التقييم وما بعد التدريب. ومع ذلك، إذا تم استخدام مجموعة التقييم للتدريب، فإنها لم تعد مجموعة تقييم مستقلة - فهل ينتهك هذا المبدأ الأساسي الذي يقضي بضرورة فصل مجموعات التدريب والاختبار؟ يؤدي إنشاء المعلمات الديناميكية لـ τ²-bench والقوالب ذات المعلمات في AndroidWorld إلى تخفيف هذه المشكلة إلى حد ما، لكن بنية القالب نفسها تظل ثابتة. كيف يمكننا إيجاد توازن بين الاستفادة الكاملة من القيمة التدريبية لبيانات التقييم والحفاظ على استقلالية التقييم؟

إعادة استخدام البيئات، وليس الأسئلة. تمنع المعلمات الديناميكية فقط "حفظ الإجابات"، وليس الإفراط في ملاءمة القالب، لذا يجب عليك الاحتفاظ بدفعات كاملة من القوالب غير المرئية/سيناريوهات خارج المجال للتقييم (مماثلة لتدريب V-IRL في نيويورك والاختبار في تسع مدن غير مألوفة). استخدم القوالب ذات المعلمات لإنشاء متغيرات التدريب على دفعات لدعم تعلم المناهج الدراسية، وأخذ درجات OOD كمقياس تعميم حقيقي.

11. (★★★) يقترح هذا الفصل نموذج تدريب "الشكل أولاً، الروح ثانيًا": قم بإيقاف SFT بمجرد "استقرار التنسيق ووجود القدرات الأساسية"، ثم قم بالتبديل إلى RL. ولكن من الناحية العملية، كيف يمكنك تحديد متى يكون SFT "كافيًا" وحان وقت التبديل؟

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

12. (★★★) تظهر ديناميكيات التدريب في ReTool (انظر التجربة 7-15) أن عددًا صغيرًا من الاستجابات الطويلة جدًا يمكن أن يطيل بشكل كبير دورة التدريب بأكملها - يتم إنشاء معظم مسارات التوليد في الدفعة بالفعل، ولكن عليك الانتظار حتى تنتهي تلك الاستجابات القليلة الأطول، والتي يكون خلالها استخدام وحدة معالجة الرسومات في المجموعة منخفضًا جدًا. كيف يمكن تحسين استخدام الموارد في مجموعات التدريب لمثل سيناريوهات الاستجابة الطويلة الأمد؟

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

13. (★★★) عند تدريب وكيل على بيئات محاكاة LLM (مثل محرك بحث مقلد أو مستخدمين محاكيين)، يتحول هدف استغلال الوكيل من "قواعد البيئة الحقيقية" إلى "التحيزات والثغرات الموجودة في جهاز المحاكاة نفسه." ما هي سلوكيات المكافأة الملموسة التي يمكن أن تنشأ في هذا النوع من التدريب، وكيف ينبغي منعها؟

السلوكيات النموذجية: المبالغة في الوعود لـ "المستخدمين المحاكيين" وتراكم الاعتذارات والعبارات المتملقّة - يمكن استرضاء المستخدمين المحاكيين بسهولة، وعلى عكس المستخدمين الحقيقيين، لا يفرضون على الوكيل أبدًا ما إذا كان يتم الوفاء بوعوده بالفعل أم لا؛ تلفيق الحقائق التي لن يتمكن جهاز المحاكاة من التحقق منها؛ صياغة استعلامات رائدة ضد "محرك بحث محاكى" يستغل ميله إلى إعادة المستندات التي تحتوي على إجابات، ويتخذ طريقًا مختصرًا بدلاً من تعلم الاسترجاع الحقيقي؛ عندما تأتي المكافأة من جهاز محاكاة أو درجات القاضي LLM، مما يؤدي إلى إنتاج استجابات مطولة ونموذجية "ذات مظهر احترافي" لنقاط المزرعة؛ والأمر الأكثر دقة هو أن السياسة تتراجع إلى التوزيع المألوف للمحاكي وتتجنب نقاط المعرفة العمياء، حيث تكون التعليقات غير موثوقة وغالبًا ما يتم إساءة تقديرها، لذلك يتعلم الوكيل التصرف فقط في "العالم الذي يجيده المحاكي". المبدأ الأول للدفاع هو ربط المكافأة بحالة حقيقية يمكن التحقق منها برمجيًا (إكمال المهمة، وكتابة قاعدة البيانات، وإرجاع API الحقيقي)، والتعامل مع نتائج المحاكي أو LLM كإشارات مساعدة فقط، ومراجعة ارتباطها بالنتائج الحقيقية بشكل دوري، وإقران ذلك بقيود المسار التي تعاقب المشبوهين الإجراءات. علاوة على ذلك، قم بالتمييز بين نوعين من المحاكيات: بالنسبة لأولئك الذين لديهم نظير حقيقي، مثل البحث، اتبع المسار "المختلط" — تمر معظم التفاعلات عبر جهاز المحاكاة مع مكالمات API الحقيقية مختلطة، ويتم استخدام المكالمات الحقيقية لمعايرة جهاز المحاكاة بشكل دوري (على سبيل المثال، تدهور الجودة على غرار المنهج الدراسي لـ ZeroSearch). لكن بالنسبة للمستخدمين المحاكيين، لا يمكن إشراك المستخدمين الحقيقيين في التدريب، لذا يصبح "مدى إخلاص المستخدم المحاكى للمستخدم الحقيقي" مشكلة منفصلة لا يمكن حلها إلا من خلال التتبع عبر الإنترنت: مقارنة سلوك المستخدمين الحقيقيين في آثار الإنتاج مع سلوك المستخدم الذي تمت محاكاته في نفس المواقف، وتحديد الاختلافات المنهجية (يطرح المستخدمون الحقيقيون أسئلة للمتابعة، وينفد صبرهم، وينهون المحادثات فجأة - غالبًا لا يفعل المستخدمون المحاكيون ذلك)، ومعايرة جهاز المحاكاة بشكل مستمر وفقًا لذلك؛ المقاييس الحقيقية عبر الإنترنت هي أيضًا بوابة الإصدار الوحيدة - لا يتم احتساب أي نتيجة داخل جهاز المحاكاة.

الفصل الثامن: التطور المستمر للوكلاء

1. (★★) وثيقة الخبرة مدعمة بثلاثة مسارات ناجحة ومسار واحد فاشل. حدث الفشل في إصدار API الأحدث. كيف يمكن للنظام تحديد ما إذا كان قد تم دحض التجربة أو تغيرت شروط تطبيقها؟

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

2. (★★) يرتفع رضا المستخدم عن وكيل خدمة العملاء، ولكن معدل انتهاك القواعد يرتفع أيضًا. لماذا لا يكون الرضا بمثابة إشارة التعلم الوحيدة؟ كيف يمكنك تصميم مقاييس ضوابط الأمان؟

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

3. (★★★) يمكن التخفيف من نفس مشكلة "الوعد الكاذب" من خلال الموجّه أو فحص منظومة التشغيل أو تدريب المعلمات. ما الدليل الذي ستستخدمه لاختيار موقع التحديث؟

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

4. (★★★) يجوز للوكيل تعديل الأدوات وأدوات التحقق من الصحة، ولكن لا يجوز له تعديل آليات الأمان التي توافق على التحديثات الخاصة به. كيف يمكنك تقسيم الأذونات وحدود التعليمات البرمجية بين هذين الجزأين؟

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

5. (★★) مع نمو قاعدة المعرفة التجريبية، قد تؤدي أخطاء الاسترجاع وتضارب المعرفة إلى تعويض فوائد التعلم. كيف ينبغي تصميم آليات الإصدار والحداثة والتقاعد؟

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

6. (★★★) يتفوق تعلم المعلمات بأسلوب اللغة الطبيعية ولكن لا يمكنه ضمان قواعد العمل الصارمة. صمم مخططًا للتطور المستمر لخدمة العملاء الطبيين ينسق المعلمات والمعرفة والمهارات وقيود التعليمات البرمجية.

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

الفصل التاسع: تعدد الوسائط والتفاعل الآني

1. (★★) يدمج النموذج الشامل لوكلاء الصوت ASR-LLM-TTS في نموذج واحد، مما يقلل زمن الوصول ولكنه يفقد النمطية. إذا حدث خطأ في النموذج الشامل في مرحلة معينة (على سبيل المثال، التعرف على الكلام)، فإن تصحيح الأخطاء وإصلاحها يكون أصعب بكثير من خط أنابيب تسلسلي. كيف يمكنك تصميم نظام مراقبة لوكيل صوتي شامل؟

اجعل النموذج يُصدر تمثيلات وسيطة قابلة للقراءة إلى جانب مخرجاته، مثل دفق نص "المونولوج الداخلي" الخاص بموشي وعلامات الأحداث الصوتية (<emotion>، <noise>). استخدم "التتالي الذاتي" لتحديد طبقة الخطأ: يقوم نفس النموذج أولاً بالتسجيل ثم الأسباب، والمقارنة بالنتيجة الشاملة توضح ما إذا كان الخطأ يكمن في الإدراك أو التفكير. في وضع عدم الاتصال، قم بإجراء اختبارات الانحدار المفصلة على طول أبعاد مثل الفهم شبه اللغوي والحكم على تبادل الأدوار.

2. (★) يحقق Step-Audio R1 "التفكير أثناء التحدث" من خلال بنية MPS ثنائية الدماغ. ومع ذلك، فإن البشر، عندما "يفكرون أثناء التحدث"، غالبًا ما يتلفظون بكلمات غير مدروسة، أو يصححون أنفسهم، أو يستخدمون كلمات حشو. هل يجب أن يحاكي "تفكير الوكيل أثناء التحدث" هذه الخصائص البشرية؟

يجب أن تحاكي "العيوب" التي تحمل قيمة الإشارة: توقفات مؤقتة وكلمات حشو تُظهِر التفكير ويمكن أن تخفي الكمون، مع تحديد LLM مكان إدراجها. ولا ينبغي لها أن تحاكي تصحيح الذات المدمر للثقة: فالتناقض السريع البطيء في الحل الأول («هل ينبغي لي أن أشتريه أم لا؟!») يؤدي إلى انهيار الثقة. تظهر تجارب MPS أن بداية CoT تعيد طرح السؤال في الغالب؛ يعد البدء مبكرًا مع الأساس أمرًا آمنًا، دون الحاجة إلى الأخطاء في الكلام ثم التصحيح.

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

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

4. (★★) منصات الروبوت التي تبلغ قيمتها ألف دولار مثل XleRobot تجعل جمع بيانات التشغيل عن بعد غير مكلف. ومع ذلك، فإن جودة بيانات التشغيل عن بعد تعتمد بشكل كبير على مهارة المشغل. كيف ستؤثر البيانات منخفضة الجودة الواردة من مشغل غير ماهر على تدريب نموذج VLA؟ كيف يمكن تصفية البيانات منخفضة الجودة تلقائيًا أثناء مرحلة جمع البيانات؟

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

5. (★★★) يغطي هذا الفصل ثلاث طرق للتفاعل: الصوت، واستخدام الكمبيوتر، والروبوتات. الاتجاه الشائع عبر هذه الطرائق هو التطور من خطوط الأنابيب التسلسلية إلى النماذج الشاملة. إذا استمر هذا الاتجاه، كيف قد تبدو طبقة تفاعل الوكيل بعد خمس سنوات؟

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

6. (★★★) يعمل استخدام الكمبيوتر الحالي في حلقة منفصلة "لقطة شاشة ← إجراء ← لقطة شاشة"، حيث تكون كل ملاحظة عبارة عن إطار ثابت. لكن الإدراك البشري للشاشة مستمر، فنحن نرى الرسوم المتحركة قيد التشغيل، ونلاحظ تقدم التحميل، ونفهم محتوى الفيديو. وهذا يعني أن استخدام الكمبيوتر اليوم لا يمكنه التعامل مع المهام التي تتطلب فهمًا بصريًا مؤقتًا. كيف يمكنك إعادة تصميم طبقة الإدراك لدعم فهم التدفق المرئي المستمر؟

تحتاج "واجهة المراقبة" إلى إعادة تصميم بحيث يتم استخراج الإطارات الرئيسية من محتوى الفيديو وتقديمها إلى النموذج، بدلاً من توفير الإطار النهائي فقط. راجع ورقة AOI (واجهة مراقبة الوكيل).

7. (★★) تعمل فهرسة عناصر DOM/Accessibility Tree بشكل جيد على تطبيقات الويب القياسية، ولكن عددًا متزايدًا من واجهات البرامج (عرض Canvas/WebGL، وعناصر التحكم المرسومة حسب الطلب عبر الأنظمة الأساسية) لا توفر معلومات منظمة يمكن الوصول إليها، وتعتمد فقط على التعليقات التوضيحية المرئية أو توقع الإحداثيات. هل تعتقد أن استخدام الكمبيوتر يجب أن يراهن على نهج مرئي بحت، أو يحافظ على المسارات المنظمة والمرئية؟ ما هي تكاليف وفوائد الحفاظ على كلا المسارين؟

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

8. (★★) تستخدم نماذج VLA تقسيم الإجراء - كما هو مذكور في النص، فإن التكوين النموذجي لـ π₀ يولد 25-50 إجراءً مستقبليًا عند 50 هرتز - لإخفاء زمن انتقال الاستدلال خلال وقت التنفيذ. ومع ذلك، إذا تغيرت البيئة فجأة أثناء التنفيذ (على سبيل المثال، تم نقل كائن)، يصبح تسلسل الإجراء الذي تم إنشاؤه مسبقًا غير صالح. كيف يمكننا الموازنة بين ميزة الكفاءة في تقسيم الإجراءات والحاجة إلى الاستجابة للتغيرات البيئية؟

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

9. (★★★) تواجه السيناريوهات الثلاثة في هذا الفصل (الصوت، واستخدام الكمبيوتر، والروبوتات) مشكلة زمن الوصول لحلقة "الإدراك والتفكير والفعل" وتتطور نحو موازنة التفكير السريع والبطيء. ويتجلى ذلك في الصوت على أنه "التصحيح بعد الخطأ في الكلام". في استخدام الكمبيوتر، مثل "النقر أولاً، ثم البحث"؛ في علم الروبوتات، مثل "الخطوة ثم النظر". كيف يمكننا التأكد من أن هذه الإجراءات المبنية على التفكير السريع لا تؤدي إلى عواقب لا رجعة فيها؟

تصنيف الإجراءات حسب إمكانية الرجوع. قد يؤدي التفكير السريع إلى تنفيذ إجراءات قابلة للعكس فقط؛ يجب تصفية العمليات التي لا رجعة فيها عن طريق التفكير البطيء. يجب عدم السماح للنموذج السريع بإجراء استدعاءات للأدوات تؤدي إلى عواقب لا رجعة فيها.

الفصل العاشر: التعاون متعدد الوكلاء

1. (★★) في التعاون متعدد الوكلاء مع سياق مشترك، يرث الوكلاء اللاحقون السياق الكامل للوكلاء السابقين. ومع ذلك، فإن "جمود التفكير" المتراكم لدى الوكيل السابق قد يؤثر على حكم الوكلاء اللاحقين - على سبيل المثال، "مراجع الكود" الذي يرث سياق "محلل المتطلبات" قد لا يزال يميل إلى التفكير من منظور المتطلبات بدلاً من منظور جودة الكود. كيف يمكن اكتشاف هذا التداخل بين الأدوار والقضاء عليه؟

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

2. (★★) في نمط المدير، يكون وكيل المدير مسؤولاً عن تحليل المهام وتكامل النتائج. لكن سقف قدرة المدير يحدد سقف قدرة النظام بأكمله - إذا لم يتمكن المدير من تحليل المهمة بشكل صحيح، فحتى أقوى الوكلاء الفرعيين يصبحون عديمي الفائدة. كيف يمكن التأكد من جودة تحليل المدير؟

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

3. (★★) يعتمد النمط اللامركزي على أفضل الممارسات من المنظمات البشرية. ومع ذلك، فإن المنظمات البشرية لديها أيضًا عدد كبير من أنماط الفشل - ضعف التواصل، وتمرير الأموال، وتضارب الأهداف. ما هي "الأمراض التنظيمية" التي تعتقد أنه من المرجح أن تظهر في مجتمع الوكلاء؟ كيف يمكن الوقاية منها؟

مقابل فئات MAST الثلاث: واجهات غير واضحة ومسؤوليات متداخلة؛ الفهم غير المتسق للهدف والمعلومات التي يساء فهمها؛ الادعاء كذباً بـ "تم". وأيضًا: تضخيم الأخطاء المتتالية (لعبة الهاتف)، وعمليات التسليم الدورية بين الأدوار، والمحادثات الجماعية بين الوكلاء الذين يتباعدون دون أن يتقاربوا. الوقاية: واجهات تعاقدية ومغلف رسالة موحد، وأجهزة حالة المهمة مع التحقق من القبول، والتحقق المتبادل من منظور مستقل، واكتشاف تمرير المسؤولية بين الأدوار.

4. (★★★) في نمط المدير، عندما يتم تنفيذ عدة وكلاء فرعيين بالتوازي، فإن اكتشاف وكيل فرعي واحد قد يجعل عمل الوكلاء الفرعيين الآخرين بلا معنى (على سبيل المثال، في مهمة بحث، وجد وكيل واحد الإجابة بالفعل). صمم آلية إنهاء متتالية فعالة لتحقيق "نجاح واحد، توقف الجميع."

يرسل الوكيل الفرعي target_found إلى المدير، والذي يقوم بعد ذلك ببث terminate. يتحقق كل وكيل فرعي بشكل دوري من إشارة الإنهاء عند النقاط الآمنة في حلقة ReAct ويخرج بعد التنظيف السلس (إغلاق جلسات المتصفح، وتحرير الأقفال، وإنهاء كتابة الملف).

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

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

6. (★★★) يقدم تعاون الوكيل القائم على آلية السوق (Pinchwork، RentAHuman) علاقات المعاملات: يدفع وكيل واحد وكيلًا آخر (أو إنسانًا) لإكمال المهمة. كيف يمكن لوكيل صاحب العمل قياس جودة النتائج التي يسلمها المنفذ بشكل تلقائي؟ إذا ادعى المنفذ الإنجاز ولكن صاحب العمل رأى أن الجودة دون المستوى، فمن الذي يحكم في النزاع؟ كيف يمكننا أن نمنع الأموال الرديئة من طرد الأموال الجيدة؟

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

7. (★★) تسمح RentAHuman للوكلاء بتوظيف البشر عبر العملات المشفرة، مما يعكس العلاقة التقليدية بين الإنسان والآلة. إذا انتشر هذا النموذج على نطاق واسع، ما هو الدور الذي سيلعبه البشر في اقتصاد الوكيل؟ هل سيؤدون فقط المهام المادية التي لا يستطيع الوكلاء إكمالها؟

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

8. (★★) يحتاج المجتمع البشري إلى تقسيم العمل لأن قدرات كل شخص محدودة - فقد لا يعرف مطور الواجهة الأمامية الواجهة الخلفية، وقد لا يعرف المصمم العمليات. ومع ذلك، فإن النماذج الكبيرة أقرب إلى "العامة". تظهر الأبحاث أنه في مهام التفكير المنطقي للنص الخالص، لا يتفوق النقاش متعدد الوكلاء على وكيل واحد يتمتع بحساب متساوٍ. إذن، أين تكمن الميزة الحقيقية لتعدد الوكلاء؟

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

9. (★★★) يتعامل هذا الفصل مع "السياق المشترك" مقابل "السياق غير المشترك" باعتباره أحد أبعاد التصميم الأساسية للأنظمة متعددة الوكلاء. يسمح السياق المشترك لجميع الوكلاء برؤية نفس المعلومات، مما يسهل التنسيق على ما يبدو. ومع ذلك، في مشكلة الأجسام الثلاثة، فإن عقول التريسولارانز شفافة تمامًا، ومع ذلك فإن تطورهم التكنولوجي راكد؛ تظهر تجربة مشبك الورق أيضًا أنه عندما تتقارب المجموعة على نفس الهدف، يتم فقدان التنوع. في نظام متعدد الوكلاء، كيف يمكننا تحقيق التوازن بين الكفاءة والتنوع؟

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

10. (★★★) قم بتعيين وكيل البرمجة بميزانية مكونة من 30 خطوة و300 خطوة. كيف ينبغي أن تختلف استراتيجية عملها؟ تظهر الأبحاث أن مجرد زيادة ميزانية الخطوة لا يضمن تحسين الأداء - قد "تشبع" الوكلاء قبل الأوان بعد عمليات بحث سطحية. صمم آلية "مراعية للميزانية" تسمح للوكيل بتحقيق الوظائف الأساسية بسرعة ضمن ميزانية صغيرة، وإضافة مراحل التخطيط والاختبار والمراجعة ضمن ميزانية كبيرة، مع الاستفادة الكاملة من الموارد الحسابية الإضافية.

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

11. (★★) يصنف هذا الفصل "الإنهاء المبكر" إلى ثلاثة أنواع: الاستسلام الكسول، والاستسلام المبكر، والنجاح الزائف. لماذا يجتمع علاج الثلاثة مع التحقق؟

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

12. (★★) يقوم الجدول 3-10 بتعيين الأنظمة متعددة الوكلاء على أنظمة التشغيل صفًا تلو الآخر. قم بتوسيع الجدول ببضعة صفوف أخرى: ما الذي تتوافق معه الذاكرة الافتراضية والترحيل وأذونات الملفات واكتشاف حالة التوقف التام وخوارزميات الجدولة في عالم الوكيل؟ وما هي مفاهيم أنظمة التشغيل التي ليس لها نظير في عالم الوكيل، ولماذا؟

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