هندسة التسخير (Harness Engineering): الدليل الشامل لبناء وكلاء ذكاء اصطناعي لا ينهارون

معظم الناس يحاولون تحسين وكلاء الذكاء الاصطناعي في الطبقة الخاطئة.

عندما يفشل الوكيل، يعيدون كتابة التعليمات.

وعندما يفشل مرة أخرى، يضيفون المزيد من الإرشادات.

قبل أن نبدأ:

تابع نشرتي على Substack للحصول على أحدث معلومات AI، وسير عمل الوكلاء، وأدلة خطوة بخطوة قبل نشرها على X: [https://substack.com/@lunarresearcher

ثم يغيرون النماذج، ويضيفون المزيد من الأدوات، ويزيدون نافذة السياق، ويأملون أن يكون التشغيل التالي مختلفًا.

لكن العديد من إخفاقات الوكلاء ليست إخفاقات في الاستدلال.

إنها إخفاقات في البيئة.

لم يعرف الوكيل أي الملفات مهمة.

استخدم الأداة الصحيحة في المكان الخطأ.

فقد القرارات التي اتخذها في الجلسة السابقة.

ادعى النجاح دون تشغيل الفحوصات.

كرر إجراءً بعد فشل جزئي.

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

النموذج لم يكن بالضرورة هو المشكلة. النظام المحيط بالنموذج كان غير مكتمل.

هذا النظام هو الحزام (Harness).

وتصميمه أصبح تخصصًا هندسيًا بحد ذاته.

هندسة الحزام (Harness Engineering) هي ممارسة بناء البيئة التي تحول ذكاء النموذج إلى عمل موثوق.

التعليمات تغير محاولة واحدة.

الحزام يغير كل محاولة.

يشرح هذا الدليل كيفية بناء واحد.

1. النموذج ليس الوكيل

يمكن للنموذج التفكير والتوليد والمقارنة والاختيار.

لكن الوكيل يجب أن يتفاعل أيضًا مع بيئة حقيقية.

يحتاج إلى:

• فهم المهمة
• العثور على السياق ذي الصلة
• اختيار الأدوات واستخدامها
• الحفاظ على الحالة
• احترام الأذونات
• فحص النتيجة
• التعافي من الفشل
• إثبات أن العمل مكتمل

النموذج هو محرك الاستدلال داخل ذلك النظام.

الحزام هو كل ما يجعل الاستدلال قابلاً للتطبيق.

1طلب المستخدم
2     |
3     v
4+-----------------------------+
5|           الحزام            |
6| العقد | السياق | السياسة    |
7| الأدوات | الحالة | الفحوصات |
8| التتبعات | التعافي          |
9+-----------------------------+
10     |
11     v
12    النموذج
13     |
14     v
15البيئة الحقيقية

نموذج قوي داخل حزام ضعيف لا يزال وكيلاً ضعيفًا.

قد ينتج استجابات فردية مبهرة، لكنه سيتصرف بشكل غير متسق عبر المهام الطويلة والبيئات المتغيرة والإخفاقات الجزئية.

الهدف من هندسة الحزام ليس إزالة عدم اليقين من النموذج.

إنه احتواء هذا عدم اليقين داخل نظام يمكنه المراقبة والتحقق والتعافي.

2. ابدأ بعقد مهمة

معظم مهام الوكيل تبدأ كنوايا غامضة:

حسّن تدفق الإعداد (onboarding flow).

هذه الجملة قد تكون كافية لمحادثة.

إنها ليست كافية للتنفيذ المستقل.

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

العقد المفيد يجيب على خمسة أسئلة:

1. ما النتيجة التي يجب أن توجد؟
2. ما هو داخل النطاق؟
3. ما الذي يجب ألا يتغير؟
4. ما الدليل الذي يثبت الإكمال؟
5. ما الإجراءات التي تتطلب موافقة بشرية؟

1الهدف: تقليل التسرب في عملية الإعداد
2
3النطاق:
4  - تدفق التسجيل
5  - تحليلات الإعداد
6
7القيود:
8  - لا تغير المصادقة
9  - حافظ على سلوك الهاتف المحمول الحالي
10
11القبول:
12  - اجتياز الاختبارات
13  - إصدار حدث تحليلي
14  - تغطية لقطات الشاشة لسطح المكتب والهاتف المحمول
15
16الموافقة المطلوبة:
17  - النشر في الإنتاج
18  - ترحيل قاعدة البيانات

هذا يغير سؤال الوكيل من:

ماذا يجب أن أفعل بعد ذلك؟

إلى:

ما الإجراء الذي يحرك البيئة نحو النتيجة المتعاقد عليها؟

بدون عقد، يحسن الوكيل أداءه لنشاط معقول.

مع عقد، يمكنه التحسين من أجل إكمال تم التحقق منه.

3. أعط الوكيل خريطة، وليس دليلاً

إلقاء المستودع بأكمله، ومجموعة التوثيق، وسجل المحادثة في السياق ليس هندسة سياق جيدة.

إنه إغراق بالسياق.

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

1خريطة المشروع
2
3قواعد المنتج     -> docs/product/
4الهندسة المعمارية -> docs/architecture.md
5الواجهة الأمامية  -> apps/web/
6الخدمة الخلفية   -> services/api/
7الاختبارات       -> tests/
8الأوامر          -> docs/commands.md
9قواعد الإصدار    -> docs/release.md

هذا هو الكشف التدريجي:

1المهمة
2  -> خريطة المشروع
3      -> النظام الفرعي ذو الصلة
4          -> الملفات الدقيقة
5              -> التعليمات المحلية

يجب أن يتوسع السياق لأن المهمة تتطلب ذلك، وليس لأن المعلومات موجودة.

مترجم السياق الجيد يقرر:

• ما هو مطلوب دائمًا
• ما يمكن استرداده لاحقًا
• ما أصبح قديمًا
• ما يمكن تلخيصه
• ما يجب أن يبقى حرفيًا

الهدف ليس أقصى سياق.

إنه أقصى إشارة لكل رمز (token).

4. ابنِ بوابة أدوات، وليس كومة أدوات

إعطاء الوكيل عشرين أداة لا يجعله قادرًا.

إنه يعطي الوكيل عشرين طريقة لارتكاب خطأ.

يجب أن يكون لكل أداة عقد واضح:

1الأداة: edit_file
2
3المدخلات:
4  المسار
5  التصحيح
6
7الشروط المسبقة:
8  المسار موجود
9  المسار داخل مساحة العمل المسموح بها
10
11دليل النجاح:
12  تم تطبيق التصحيح
13  إرجاع الفرق الناتج
14
15سلوك الفشل:
16  لا كتابة فوقية جزئية
17  إرجاع خطأ منظم
18
19فئة المخاطرة:
20  قابل للعكس

يجب أن يتحكم الحزام في كيفية عرض الأدوات واستخدامها.

يمكنه:

• إخفاء الأدوات غير ذات الصلة
• التحقق من صحة الوسائط
• تقييد المسارات والمجالات
• إرفاق مهلات زمنية
• جعل إعادة المحاولة غير مؤثرة (idempotent)
• تطبيع المخرجات
• طلب تأكيد للإجراءات المحفوفة بالمخاطر
• إرجاع دليل، وليس مجرد "نجاح"

هذا يخلق فصلًا مهمًا:

1النموذج يقرر النية
2البوابة تتحقق من صحة الإجراء
3الأداة تغير البيئة
4المستشعر يلاحظ النتيجة

يمكن للنموذج اقتراح إجراء.

تقرر بوابة الأدوات ما إذا كان هذا الإجراء صالحًا بما يكفي للتنفيذ.

5. افصل العقل واليدين والتاريخ

العديد من الوكلاء الهشّين يخلطون كل شيء في نص واحد متزايد.

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

النظام الأقوى يفصل ثلاث مسؤوليات:

1العقل (BRAIN)
2يخطط، يستدل، يختار
3
4اليدين (HANDS)
5تنفذ الأدوات داخل بيئة خاضعة للرقابة
6
7التاريخ (HISTORY)
8يخزن الحقائق الثابتة والقرارات وحالة التشغيل

النموذج لا يحتاج كل حدث خام في السياق النشط.

يحتاج الحالة الحالية الصحيحة.

صندوق الحماية (sandbox) لا يحتاج إلى فهم الهدف بأكمله.

يحتاج إلى تنفيذ إجراء محدود بأمان.

سجل الجلسة لا يحتاج إلى التفكير.

يحتاج إلى الحفاظ على ما حدث بعد اختفاء السياق الحالي.

هذا الفصل يجعل الوكلاء طويلي الأمد أسهل في الاستئناف والفحص والإصلاح.

كما يتيح لك استبدال جزء واحد دون إعادة بناء النظام بأكمله.

6. الذاكرة يجب أن تصبح حالة دائمة

سجل المحادثة ليس ذاكرة موثوقة.

إنه تيار من الأحداث.

يجب تحويل الذاكرة المفيدة إلى حالة صريحة.

على الأقل، حافظ على أربع فئات:

1الحقائق (FACTS)
2معلومات مستقرة تم اكتشافها عن البيئة
3
4القرارات (DECISIONS)
5الخيارات المتخذة والسبب وراءها
6
7التقدم (PROGRESS)
8العمل المكتمل والنشط والمحظور والمتبقي
9
10الدروس (LESSONS)
11الإخفاقات التي يجب أن تغير السلوك المستقبلي

على سبيل المثال:

1الحقائق:
2  - التحقق من صحة الدفع موجود في services/orders
3
4القرارات:
5  - إعادة استخدام خط أنابيب التحقق الحالي
6  - السبب: تجنب مصدر ثانٍ للحقيقة
7
8التقدم:
9  المكتمل:
10    - إضافة قاعدة من جانب الخادم
11  المتبقي:
12    - تحديث اختبار التكامل
13
14الدروس:
15  - أمر الاختبار المحلي يتطلب TEST_DB_URL

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

قم بتخزين التاريخ الخام لقابلية المراجعة.

قم بتجميع الحالة الدائمة للتنفيذ.

7. الإكمال يتطلب دليلاً

قول الوكيل "تم" ليس دليلاً على أن المهمة قد اكتملت.

إنه مجرد مخرج آخر للنموذج.

يجب تحديد الإكمال من خلال التغييرات القابلة للملاحظة في البيئة.

1الادعاء                         الدليل
2--------------------------------------------------
3"الخطأ قد أُصلح"                الاختبار الفاشل ينجح الآن
4"الصفحة تعمل"                   تم إكمال تدفق المتصفح
5"الترحيل آمن"                   التشغيل الجاف والتراجع ينجحان
6"التقرير صحيح"                  القيم تطابق بيانات المصدر
7"المهمة مكتملة"                 كل فحص قبول ينجح

يجب على الحزام تشغيل أرخص الفحوصات الحتمية أولاً.

1بناء الجملة (syntax)
2  -> الأنواع (types)
3      -> الاختبارات المركزة
4          -> اختبارات التكامل
5              -> المراجعة البصرية أو الدلالية
6                  -> الموافقة البشرية

لا تستخدم نموذجًا آخر حيث يمكن للمترجم (compiler) أو المخطط (schema) أو المجموع الاختباري (checksum) أو الاستعلام (query) أو الاختبار الإجابة على السؤال.

استخدم النماذج للغموض.

استخدم الكود للسباكة (plumbing).

يمكن للنموذج أن يقترح أن المهمة قد اكتملت.

فقط البيئة يمكنها إثبات ذلك.

8. التحقق يجب أن يهاجم النتيجة

يجب ألا يشارك العمال والمقيمون نفس الهدف.

يحاول العامل إنشاء أقوى حل.

يحاول المقيم إيجاد سبب رفضه.

1العامل
2  -> ينتج مرشحًا
3
4المدقق (verifier)
5  -> يتحقق من العقد
6  -> يبحث عن الحالات المفقودة
7  -> يختبر الادعاءات غير المدعومة
8  -> يحاول كسر النتيجة
9
10ينجو
11  -> قبول
12
13يفشل
14  -> إرجاع دليل مستهدف

هذا التباين مهم.

إذا طلبت من نفس الوكيل، في نفس السياق، أن "يتحقق من عمله"، فإنه غالبًا ما يحافظ على الافتراضات التي خلقت الخطأ.

يجب أن تحتوي مرحلة التحقق المفيدة على:

• معايير رفض صريحة
• الوصول إلى الأداة المنتجة
• الوصول إلى عقد القبول
• أدوات مستقلة أو سياق جديد عند الحاجة
• الإذن بالرفض دون إصلاح

التحقق ليس رأيًا ثانيًا.

إنها محاولة دحض.

9. النموذج يقترح، السياسة تأذن

بعض القواعد يجب ألا تعتمد أبدًا على ما إذا كان النموذج يتذكرها.

1لا تنشر أبدًا بدون موافقة
2لا تكشف سرًا أبدًا
3لا تكتب خارج مساحة العمل أبدًا
4لا تتجاوز سقف الإنفاق أبدًا
5لا تضع علامة نجاح على الاختبارات ما لم يتم تشغيلها

هذه ليست اقتراحات تعليمات.

إنها سياسة.

التصميم الأكثر أمانًا يبقي السياسة خارج حلقة الاستدلال.

1مخاطرة منخفضة (LOW RISK)
2قراءة الملفات، البحث، الفحص
3-> تلقائي
4
5تغيير قابل للعكس (REVERSIBLE CHANGE)
6تعديل مساحة العمل، تشغيل الاختبارات
7-> تلقائي مع تتبع
8
9تأثير خارجي (EXTERNAL EFFECT)
10إرسال رسالة، نشر، شراء
11-> موافقة صريحة
12
13لا رجعة فيه أو حساس (IRREVERSIBLE OR SENSITIVE)
14حذف البيانات، تدوير بيانات الاعتماد، النشر عالميًا
15-> بوابة صلبة أو محظور

كلما كانت العاقبة أقوى، كانت البوابة أصعب.

الاستقلالية ليست غياب السيطرة.

إنها القدرة على العمل بحرية داخل حدود مفروضة بوضوح.

10. التعافي يجب أن يستهدف فئة الفشل

استراتيجية التعافي الأكثر شيوعًا هي:

حدث خطأ ما. حاول مرة أخرى.

هذا ليس تعافيًا.

إنه تكرار.

يجب على الحزام تصنيف الفشل قبل اختيار الإجراء التالي.

1مهلة الأداة
2-> إعادة المحاولة مع التراجع (backoff)
3
4وسائط غير صالحة
5-> إصلاح استدعاء الأداة
6
7سياق مفقود
8-> استرداد المصدر المحدد
9
10اختبار فاشل
11-> فحص السلوك الفاشل
12
13رفض الإذن
14-> طلب الموافقة أو اختيار مسار آمن
15
16متطلبات متناقضة
17-> التصعيد إلى الإنسان
18
19فشل متكرر دون تغيير
20-> إيقاف الحلقة

يجب أن تغير إعادة المحاولة شرطًا واحدًا ذا صلة على الأقل.

وإلا فإن النظام يدفع لإعادة إنتاج نفس الفشل.

حلقة الوكيل المحددة تبدو هكذا:

1لاحظ (observe)
2  -> قرر (decide)
3      -> تصرف (act)
4          -> قس (measure)
5              -> اقبل (accept)
6              -> أصلح (repair)
7              -> صعّد (escalate)
8              -> توقف (stop)

كل حلقة تحتاج إلى ميزانية:

• الحد الأقصى لعدد المحاولات
• الحد الأقصى للوقت
• الحد الأقصى للإنفاق
• الحد الأقصى للنطاق التدميري
• شرط التصعيد

الوكلاء الموثوقون يعرفون كيفية الاستمرار.

كما يعرفون متى لم يعد الاستمرار عقلانيًا.

11. التعليمات يجب أن تصبح بنية تحتية

تعليمات الوكيل مفيدة عندما تشرح الواقع المحلي.

لكن التعليمات وحدها هي إنفاذ ضعيف.

إذا كانت القاعدة مهمة بشكل متكرر، انقلها إلى أسفل المكدس (stack).

1"استخدم أداة التنسيق"
2-> تشغيل أداة التنسيق تلقائيًا
3
4"لا تستورد عبر الطبقات"
5-> إضافة اختبار معماري
6
7"قم بتضمين تراجع الترحيل"
8-> طلب ملف تراجع في CI
9
10"لا تعدل الملفات المُنشأة"
11-> حظر الكتابة إلى المسارات المُنشأة
12
13"استشهد بكل ادعاء خارجي"
14-> التحقق من تغطية الاستشهادات

هذا يخلق سلمًا تعليميًا:

1شرح (explanation)
2  -> قائمة مرجعية (checklist)
3      -> قالب (template)
4          -> فحص آلي (automated check)
5              -> سياسة مفروضة (enforced policy)

انقل المعرفة المهمة إلى أسفل هذا السلم بقدر ما هو عملي.

يجب أن تشرح التعليمات الحكم.

يجب أن يفرض الحزام الثوابت (invariants).

12. لاحظ التشغيل، وليس فقط الإجابة النهائية

يمكن لمنتج نهائي نظيف أن يخفي عملية سيئة.

قد يكون الوكيل قد:

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

أنت بحاجة إلى تتبعات تجعل التشغيل قابلاً لإعادة البناء.

109:14  تم إنشاء العقد
209:15  تم تحميل مصدر السياق: architecture.md
309:17  تم تعديل الملف: checkout.ts
409:18  فشل الاختبار المركز: قسيمة مكررة
509:21  تم إصلاح التنفيذ
609:22  نجح الاختبار المركز
709:24  نجح اختبار التكامل
809:25  تم حظر النشر الخارجي: الموافقة مطلوبة

يسجل التتبع المفيد:

• انتقالات الحالة
• مصادر السياق
• مدخلات ومخرجات الأداة
• تغييرات البيئة
• نتائج التحقق
• أسباب إعادة المحاولة
• قرارات الموافقة
• التكلفة وزمن الوصول

الهدف ليس المراقبة.

الهدف هو الإصلاح المحلي.

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

13. كل تشغيل يحتاج إلى إيصال تغيير

من الصعب مراجعة نصوص الوكيل الطويلة.

في نهاية التشغيل، يجب على الحزام تجميع إيصال تغيير صغير.

1الهدف
2إصلاح تطبيق القسيمة المكررة أثناء الدفع.
3
4ما تغير
5- منطق التحقق من صحة الدفع
6- اختبار الانحدار المركز
7
8تم التحقق منه
9- اجتياز فحص lint
10- اجتياز اختبارات الوحدة
11- اجتياز اختبار تكامل الدفع
12
13لم يتم التحقق منه
14- مزود الدفع في الإنتاج
15
16القرارات
17- الحفاظ على ترتيب أولوية القسيمة الحالي
18
19المخاطر
20- عميل الهاتف المحمول القديم لم يكن متاحًا محليًا
21
22الموافقة المطلوبة
23- النشر في بيئة الاختبار (staging)

الإيصال ليس ملخصًا لما قاله النموذج.

إنه ملخص لما يمكن للنظام إثباته.

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

أفضل تسليم ليس "هذه هي المحادثة."

إنه "هذه هي الحالة، والدليل، والمخاطر غير المحلولة."

14. كل فشل يجب أن يطور الحزام

أضعف الفرق تصلح المخرجات الفاشلة.

أقوى الفرق تصلح أيضًا النظام الذي سمح بذلك.

بعد الفشل، اسأل:

1هل كان عقد المهمة غامضًا؟
2هل كان السياق المهم غير مرئي؟
3هل تم عرض الأداة الخاطئة؟
4هل كان هناك شرط مسبق مفقود؟
5هل كانت النتيجة غير قابلة للتحقق؟
6هل تركت السياسة داخل التعليمات؟
7هل كان التعافي واسعًا جدًا؟
8هل كان التتبع غير كافٍ؟

ثم حول الدرس إلى تحسين قابل لإعادة الاستخدام.

1فشل
2  -> تشخيص
3      -> مستشعر جديد، قاعدة، خريطة، اختبار، أو عقد أداة
4          -> تتحسن التشغيلات المستقبلية تلقائيًا

هذه هي دولاب الموازنة للحزام.

يصبح النظام أكثر موثوقية لأن الإخفاقات تترك بنية تحتية وراءها.

الإجابة المصححة تساعد في تشغيل واحد.

الحزام المصحح يساعد في كل تشغيل مستقبلي.

15. الأحزمة تتدهور أيضًا

المزيد من الحزام ليس دائمًا أفضل.

النماذج تتحسن. الأدوات تتحسن. المهام تتغير. يمكن أن تصبح الضمانات القديمة احتكاكًا غير ضروري.

قد يمنع الحل البديل الذي تم إنشاؤه لنموذج الأمس النموذج الحالي من استخدام استراتيجية أفضل.

هذا يخلق تدهورًا في الحزام:

1قيد النموذج القديم
2  -> حل بديل للحزام
3      -> النموذج يتحسن
4          -> الحل البديل يبقى
5              -> يصبح النظام أبطأ أو أقل قدرة

تعامل مع مكونات الحزام مثل كود الإنتاج.

قس ما إذا كانت لا تزال توفر رفعًا (lift).

لكل موجه (router)، ومقيم (evaluator)، وطبقة ذاكرة (memory layer)، وقاعدة إعادة محاولة (retry rule)، اسأل:

• أي فشل يمنع هذا؟
• كم مرة يحدث هذا الفشل الآن؟
• ما زمن الوصول والتعقيد الذي يضيفه هذا؟
• هل يمكن تحقيق نفس النتيجة الآن بشكل أبسط؟
• ماذا يحدث إذا أزلناه؟

أفضل حزام ليس أكبرها.

إنه أصغر نظام يغلق الفجوة بين النية والدليل بشكل موثوق.

ابنِ للحذف.

16. الحد الأدنى من الحزام القابل للتطبيق

لا تحتاج إلى منصة تنسيق للبدء.

ابنِ الحزام في طبقات.

المستوى 1: مهمة محددة

• الهدف
• النطاق
• القيود
• فحوصات القبول

المستوى 2: بيئة مقروءة

• خريطة المشروع
• الأوامر
• التعليمات المحلية
• التبعيات المعروفة

المستوى 3: إجراءات خاضعة للرقابة

• أدوات مكتوبة
• التحقق من صحة الوسائط
• حدود المسار والإذن
• نتائج منظمة

المستوى 4: تنفيذ دائم

• حالة تشغيل صريحة
• نقاط تفتيش
• قرارات
• دروس

المستوى 5: دليل

• فحوصات حتمية
• تحقق عدائي
• إيصال تغيير

المستوى 6: التعافي والتعلم

• تصنيف الفشل
• إعادة محاولة محدودة
• تصعيد
• تحديثات الحزام من الإخفاقات المتكررة

ابنِ أصغر طبقة تزيل الفشل الذي لديك بالفعل.

لا تبدأ بهندسة متعددة الوكلاء لأن تعليمات واحدة تحتاج أحيانًا إلى توضيح.

يجب أن يكون التعقيد مكتسبًا من خلال الفشل الملحوظ.

17. مواصفات حزام قابلة لإعادة الاستخدام

قبل إعطاء الوكيل استقلالية ذات معنى، حدد هذا:

1مواصفات حزام الوكيل
2
31. العقد
4   الهدف:
5   النطاق:
6   القيود:
7   دليل القبول:
8
92. السياق
10   الخريطة المحملة دائمًا:
11   مصادر الاسترداد:
12   التعليمات المحلية:
13   قواعد الحداثة:
14
153. الأدوات
16   الأدوات المسموح بها:
17   الشروط المسبقة:
18   الآثار الجانبية:
19   دليل النجاح:
20   سياسة المهلة وإعادة المحاولة:
21
224. الحالة
23   الحقائق:
24   القرارات:
25   التقدم:
26   الدروس:
27   تنسيق نقطة التفتيش:
28
295. السياسة
30   الإجراءات التلقائية:
31   الإجراءات التي تتطلب موافقة:
32   الإجراءات المحظورة:
33   حدود الميزانية:
34
356. التحقق
36   الفحوصات الحتمية:
37   الفحوصات العدائية:
38   قاعدة القبول:
39
407. التعافي
41   فئات الفشل:
42   حدود إعادة المحاولة:
43   شروط التصعيد:
44   التراجع الآمن:
45
468. قابلية المراقبة
47   أحداث التتبع:
48   المقاييس:
49   إيصال التغيير النهائي:

إذا كانت هذه الحقول غير محددة، فإن الوكيل ليس مستقلاً.

إنه يرتجل.

18. قس النظام على المستوى الصحيح

عدد الرموز (token count) ليس المقياس النهائي.

ولا هو عدد المهام التي تمت محاولتها.

الوحدة المفيدة هي العمل المقبول.

المقياس العملي هو:

1المخرجات المقبولة
2------------------------------
3دقائق المراجعة البشرية + تكلفة التشغيل

تتبع أيضًا:

• معدل القبول من المحاولة الأولى
• معدل التعافي بعد فشل الأداة
• معدل الفشل المتكرر
• التدخلات البشرية لكل مهمة
• ادعاءات الإكمال غير المدعومة
• الوقت من الطلب إلى النتيجة التي تم التحقق منها
• الحمل الزائد للحزام حسب المكون

هذا يمنع وهمًا شائعًا:

يمكن للوكيل أن يبدو منتجًا للغاية بينما يخلق عمل مراجعة مكلفًا.

الهدف ليس نشاط وكيل أكثر.

إنه نتائج أكثر موثوقية لكل وحدة من الاهتمام البشري.

19. عندما لا تحتاج إلى حزام ثقيل

ليس كل استدعاء نموذج يحتاج إلى نظام تشغيل.

استخدم تعليمات بسيطة عندما:

• المهمة قصيرة
• المخرجات سهلة الفحص
• الفشل رخيص
• لا يحدث أي تأثير جانبي خارجي
• يبقى المستخدم في الحلقة

أضف حزامًا عندما:

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

الغرض من الحزام ليس جعل العرض التجريبي يبدو متطورًا.

إنه جعل العمل الحقيقي موثوقًا.

التحول الحقيقي

الجيل الأول من منتجات AI تم بناؤه حول التعليمات.

الجيل القادم يتم بناؤه حول البيئات.

السؤال لم يعد فقط:

كيف نجعل إجابة النموذج أفضل؟

بل أصبح:

كيف نبني نظامًا تكون فيه الإجراءات الجيدة سهلة، والإجراءات الخطيرة خاضعة للرقابة، والإخفاقات مرئية، والإكمال قابل للإثبات؟

هذا هو التحول من هندسة التعليمات إلى هندسة الحزام.

النموذج يوفر الذكاء.

الحزام يوفر الهيكل.

معًا ينتجان تنفيذًا موثوقًا.

إذا كان وكيلك ينهار باستمرار، توقف عن إضافة الصفات إلى التعليمات.

ابنِ البيئة التي يحتاجها للنجاح.

إذا وصلت إلى هنا

احفظ هذا الدليل كمرجع.

تابع @LunarResearcher على X

اشترك في نشرتي على Substack

أرسل هذه المقالة لشخص لا يزال يحاول إصلاح كل فشل وكيل بتعليمات أطول.