هندسة التسخير: طبقة التنفيذ التي يحتاجها وكلاء الذكاء الاصطناعي بالفعل

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

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

ما هي هندسة التسخير؟

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

لفهم سبب أهميتها، فكر في ثلاث طبقات لتطوير وكيل الذكاء الاصطناعي:

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

تعملهندسة التسخير على تحسين جودة المحادثة الواحدة - الصياغة والهيكل والأمثلة. محادثة واحدة ومخرج واحد

تديرهندسة السياق مقدار المعلومات التي يمكن للنموذج أن يراها في آن واحد - أي المستندات التي يجب استرجاعها، وكيفية ضغط السجل، وما الذي يتناسب مع نافذة السياق وما الذي يتم إسقاطه.

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

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

تشكل الطبقتان الأوليان جودة الدور الواحد. أما الثالثة فتشكل ما إذا كان بإمكان الوكيل أن يعمل لساعات دون أن تراقبه.

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

كيف استخدمت OpenAI هندسة التسخير لبناء قاعدة برمجيات مكونة من مليون سطر والدروس التي تعلموها

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

الجزء المثير للاهتمام ليس الناتج. بل في المشاكل الأربع التي واجهوها وحلول طبقة التسخير التي قاموا ببنائها.

المشكلة 1: عدم وجود فهم مشترك لقاعدة البرمجة

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

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

الحل: تقليص AGENTS.md إلى 100 سطر. لا قواعد - خريطة. يشير إلى دليل منظم docs/ يحتوي على قرارات التصميم وخطط التنفيذ ومواصفات المنتج والمستندات المرجعية. تتحقق اللينترز و CI من أن الروابط المتقاطعة تبقى سليمة. ينتقل الوكيل إلى ما يحتاجه بالضبط.

المبدأ الأساسي: إذا لم يكن هناك شيء ما في السياق في وقت التشغيل، فهو غير موجود بالنسبة للوكيل.

المشكلة 2: لم يتمكن ضمان الجودة البشري من مواكبة مخرجات الوكيل

قام الفريق بتوصيل بروتوكول Chrome DevTools في Codex. يمكن للوكيل تصوير مسارات واجهة المستخدم ومراقبة أحداث وقت التشغيل والاستعلام عن السجلات باستخدام LogQL والمقاييس باستخدام PromQL. وضعوا عتبة محددة: كان يجب أن تبدأ الخدمة في أقل من 800 ميلي ثانية قبل اعتبار المهمة مكتملة. كانت مهام Codex تعمل لأكثر من ست ساعات متواصلة - عادةً أثناء نوم المهندسين.

المشكلة 3: الانجراف المعماري بدون قيود

بدون حواجز حماية، كان الوكيل يعيد إنتاج أي أنماط يجدها في الريبو - بما في ذلك الأنماط السيئة.

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

بنية صارمة متعددة الطبقات مع التحقق من صحة التبعية في اتجاه واحد: الأنواع في القاعدة، وواجهة المستخدم في الأعلى، والمصنفات المخصصة تفرض القواعد مع اقتراحات الإصلاح المضمنة

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

المشكلة 4: الديون التقنية الصامتة

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

لماذا لا يمكن لوكلاء الذكاء الاصطناعي تقييم عملهم الخاص بهم

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

تظهر المشكلة في شكلين.

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

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

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

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

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

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

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

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

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

مشكلة الاسترجاع داخل كل تسخير عامل

يشترك كلا النمطين - نظام docs/ الهيكلي ودورة سباق المولد/المقيّم - في تبعية صامتة: يجب على الوكيل أن يجد المعلومات الصحيحة من قاعدة معرفية حية ومتطورة عندما يحتاج إليها.

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

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

ثانيًا، استعلام المطابقة التامة: ما هي المستندات التي تشير إلى الدالة validateToken ؟ اسم الدالة هو سلسلة اعتباطية بدون معنى دلالي. لا يمكن للاسترجاع القائم على التضمين العثور عليها بشكل موثوق. فقط مطابقة الكلمات الرئيسية تعمل.

يحدث هذان الاستعلامان في وقت واحد. لا يمكن فصلهما إلى خطوات متسلسلة.

يفشل البحث المتجه البحت في المطابقة التامة. يفشل BM25 التقليدي في الاستعلامات الدلالية ولا يمكنه التنبؤ بالمفردات التي سيستخدمها المستند. قبل الإصدار Milvus 2.5، كان الخيار الوحيد هو نظاما استرجاع متوازيان - فهرس متجه وفهرس نص كامل - يعملان بشكل متزامن في وقت الاستعلام مع منطق دمج النتائج المخصص. بالنسبة لمستودع مباشر docs/ مع تحديثات مستمرة، كان يجب أن يظل كلا الفهرسين متزامنين: كل تغيير في المستند يؤدي إلى إعادة الفهرسة في مكانين، مع وجود خطر مستمر من عدم الاتساق.

كيف يحل برنامج Milvus 2.6 مشكلة استرجاع العميل باستخدام خط أنابيب هجين واحد

Milvus هي قاعدة بيانات متجهة مفتوحة المصدر مصممة لأعباء عمل الذكاء الاصطناعي. يعمل Sparse-BM25 الخاص ب Milvus 2.6 على حل مشكلة الاسترجاع ثنائي الأنابيب في نظام واحد.

عند الاستيعاب، ينشئ Milvus تمثيلين في وقت واحد: تضمين كثيف للاسترجاع الدلالي ومتجه متناثر مشفر بترميز TF لتسجيل BM25. يتم تحديث إحصائيات IDF العالمية تلقائيًا عند إضافة المستندات أو إزالتها - لا توجد عمليات إعادة فهرسة يدوية. في وقت الاستعلام، يُنشئ إدخال اللغة الطبيعية كلا نوعي متجه الاستعلام داخليًا. تدمج عملية دمج الرتب المتبادلة (RRF) النتائج المصنفة، ويتلقى المتصل مجموعة نتائج واحدة موحدة.

قبل وبعد: نظامان منفصلان مع المزامنة اليدوية والنتائج المجزأة ومنطق الدمج المخصص مقابل خط أنابيب Milvus 2.6 الفردي مع التضمين الكثيف وBM25 المتفرّق ودمج RRF والصيانة التلقائية لـ IDF لإنتاج نتائج موحدة

واجهة واحدة. فهرس واحد للصيانة.

في معيار BEIR - وهو مجموعة تقييم قياسية تغطي 18 مجموعة بيانات استرجاع غير متجانسة - يحقق Milvus إنتاجية أعلى من Elasticsearch بمعدل 3-4 أضعاف من Elasticsearch عند الاستدعاء المكافئ، مع تحسين يصل إلى 7 أضعاف في الثانية في أعباء عمل محددة. بالنسبة لسيناريو السباق، يعثر استعلام واحد على كل من مبدأ تصميم الجلسة (المسار الدلالي) وكل مستند يذكر validateToken (المسار الدقيق). يتم تحديث مستودع docs/ بشكل مستمر؛ وتعني صيانة BM25 IDF أن المستند المكتوب حديثًا يشارك في تسجيل الاستعلام التالي دون أي إعادة بناء دفعة واحدة.

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

أفضل مكونات التسخير مصممة ليتم حذفها

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

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

هندسة التسخير ليست بنية ثابتة. إنه نظام تتم إعادة معايرته مع كل إصدار نموذج جديد. السؤال الأول بعد أي ترقية رئيسية ليس "ما الذي يمكنني إضافته؟ بل "ما الذي يمكنني إزالته؟

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

كل مكوّن في بنية تحتية جيدة البناء ينتظر أن يتم الاستغناء عنه بواسطة نموذج أكثر ذكاءً. هذه ليست مشكلة. هذا هو الهدف.

ابدأ مع ميلفوس

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

• اقرأ ملاحظات الإصدار Milvus 2.6 للحصول على التفاصيل الكاملة حول Sparse-BM25، والصيانة التلقائية لـ IDF، ومعايير الأداء.
• انضم إلى مجتمع Milvus لطرح الأسئلة ومشاركة ما تقوم ببنائه.
• احجز جلسة مجانية في ساعات عمل Milvus المكتبية للتعرف على حالة استخدامك مع خبير في قاعدة بيانات المتجهات.
• إذا كنت تفضل تخطي إعداد البنية التحتية، فإن Zilliz Cloud (Milvus المدارة بالكامل) تقدم مستوى مجاني للبدء مع أرصدة مجانية بقيمة 100 دولار عند التسجيل بالبريد الإلكتروني للعمل.
• ضع نجمة لنا على GitHub: milvus-io/milvus - أكثر من 43 ألف نجمة وتتزايد.

الأسئلة المتداولة

ما هي هندسة التسخير وكيف تختلف عن الهندسة السريعة؟

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

لماذا يحتاج وكلاء الذكاء الاصطناعي إلى كل من البحث الموجه و BM25 في نفس الوقت؟

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

كيف يعمل نظام Milvus Sparse-BM25 لاسترجاع معرفة الوكيل؟

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

متى يجب إضافة وكيل مقيِّم إلى مجموعة العوامل الخاصة بي؟

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