الدين ليس حيث تبحث أدوات الفحص
تتراكم الديون في البرمجيات التقليدية في أماكن سيشكو منها المُصرِّف في النهاية: منطق مكرر، واجهات قديمة، ثوابت غير موثقة. أما أنظمة الوكلاء فتتراكم ديونها في أماكن لا يشكو منها شيء. الـ prompt مجرد نص. مخطط الأداة مستند JSON. والعُرف الذي يحدد أي وكيل يملك أي قرار يعيش في مستند تصميم لا يقرأه أحد بعد الـ sprint الثاني.
هذه ليست مشكلة أسلوبية. إنها مشكلة بنيوية. عندما يكون الأثر الذي يحدد سلوك النظام نصًا غير مُصنَّف وغير مُصدَّر بإصدارات، يصبح كل تغيير تغييرًا صامتًا. لا يفشل أي بناء. يستمر النظام في العمل. لكنه يعمل بشكل مختلف، ويُكتشف الفرق بعد أسابيع عندما يبدأ وكيل لاحق في إنتاج مخرجات تبدو معقولة لكنها خاطئة بطريقة محددة وقابلة للتكرار.
أجزاء الـ prompt المكررة عبر الوكلاء مع تباين صامت
نمط شائع: تعليمة مشتركة مثل "اذكر دائمًا المستند المصدر" تُنسخ في أربعة prompts لوكلاء. بعد ستة أسابيع، عُدِّل ثلاثة منها. أحدها يقول الآن "اذكر المصدر عند توفره". وآخر يقول "اذكر المستند المصدر إذا نجح الـ retrieval". والرابع لم يتغير. لا يفشل أي اختبار. الوكلاء الذين يذكرون المصدر بشكل مشروط والوكيل الذي يذكره بشكل غير مشروط ينتجون مسارات تدقيق مختلفة، ولا يظهر الفرق إلا عندما يحاول أحدهم التوفيق بين المخرجات عبر الـ pipeline.
الدين ليس التكرار نفسه. التكرار رخيص. الدين هو غياب آلية تكتشف التباين. جزء prompt مشترك يُستورد وقت البناء يجعل التباين diff. أما جزء منسوخ ولصق فيجعله غير مرئي.
مخططات أدوات لم تعد تطابق الخدمة التي تغلفها
مخطط الأداة عقد. عندما تتغير الخدمة الأساسية — يُعاد تسمية حقل، يصبح حقل قابل للقيمة الفارغة مطلوبًا، يُعاد خطأ كـ 200 مع حقل حالة — لا يُحدِّث المخطط نفسه. يستمر الوكيل في استدعاء الأداة بالشكل القديم. إما ترفض الخدمة الاستدعاء، فيعيد الوكيل المحاولة ويحرق tokens، أو تقبله وتعيد شيئًا يسيء الوكيل تفسيره.
الحالة الثانية أسوأ. الأداة التي تفشل بصوت عالٍ هي أداة تُصلَح. الأداة التي تفشل بهدوء تنتج مخرجات واثقة وخاطئة. هذا هو المكافئ في أنظمة الوكلاء لدالة تُعيد null بدلًا من أن ترمي استثناءً.
أعراف غير موثقة حول أي وكيل يملك أي قرار
تُطوِّر الأنظمة متعددة الوكلاء ملكية ضمنية. وكيل يقرر متى يُصعِّد. وآخر يقرر متى يعيد المحاولة. وثالث يقرر متى يلخِّص. نادرًا ما تُكتب هذه القرارات في مكان واحد. تنشأ من الـ prompts وكود الـ orchestration وترتيب إضافة الوكلاء.
عند إدخال وكيل جديد، لا يرث أيًّا من هذا. يتخذ قراراته الخاصة، وأحيانًا بما يتعارض مع وكيل موجود. التعارض ليس خطأً في أي من الوكيلين. إنه مواصفة مفقودة. أصبح للنظام الآن مالكَان لقرار واحد، والحل يعتمد على ترتيب التنفيذ.
هذه هي فئة الدين الأصعب رؤيةً لأنها ليست في أي أثر منفرد. إنها في الفجوات بين الآثار.
جعله مرئيًا
العلاج ليس كتابة prompts أفضل. بل إخضاع الـ prompts والمخططات والأعراف لنفس الانضباط الذي يخضع له الكود.
تعامل مع الـ prompts كآثار مُصدَّرة بإصدارات لها مالكون وسجلات تغييرات
يجب أن يعيش الـ prompt في مستودع، لا في صف قاعدة بيانات يُحرَّر عبر لوحة إدارة. يجب أن يكون له مالك — فريق أو دور، لا فرد — وسجل تغييرات يسجل ما تغير ولماذا. سجل التغييرات أهم من رقم الإصدار. diff الـ prompt بدون مبرر هو diff سيُلغيه الشخص التالي الذي لا يفهمه.
التصدير بإصدارات يمكّن أيضًا من التراجع. عندما يُدهور تغيير في الـ prompt جودة المخرجات، فإن القدرة على العودة إلى إصدار معروف بجودته هي الفرق بين إصلاح في خمس عشرة دقيقة وتحقيق يستغرق أيامًا.
اختبارات العقود التي تختبر مخططات الأدوات مقابل نقاط نهاية حية
يجب اختبار مخطط الأداة كما يُختبر عميل API: باستدعاء نقطة النهاية الحقيقية والتأكد من أن الاستجابة تتوافق مع المخطط. هذا ليس اختبار وحدة مع mock. الـ mocks تُرمِّز المخطط كما كان مفهومًا وقت كتابتها، وهذا بالضبط الافتراض الذي يحتاج إلى دحض.
اختبار العقد لمخطط أداة يؤكد ثلاثة أمور: أن نقطة النهاية تقبل الشكل الذي يعلنه المخطط، وأن الاستجابة تحتوي على الحقول التي يعد بها المخطط، وأن شروط الخطأ تُكشف بطريقة يستطيع الوكيل التصرف بناءً عليها. التأكيد الثالث هو الأكثر إغفالًا والأكثر أهمية، لأن وكيلًا لا يستطيع التمييز بين خطأ عابر وخطأ دائم سيعيد محاولة الخطأ الدائم حتى يستنفد ميزانيته.
سجل يربط كل وكيل بأدواته ونطاقات ذاكرته ومسار تصعيده
السجل هو المصدر الوحيد للحقيقة بشأن الملكية. لكل وكيل يسجل: الأدوات التي يجوز له استدعاؤها، ونطاقات الذاكرة التي يجوز له قراءتها والكتابة فيها، والشروط التي يُصعِّد بموجبها. السجل ليس توثيقًا. إنه إعدادات تقرأها طبقة الـ orchestration، بحيث لا يستطيع وكيل استدعاء أداة لا يملكها أو الكتابة في نطاق ذاكرة لا يحمله.
هذا يحوِّل عُرفًا ضمنيًا إلى عُرف مُفروض. المقايضة حقيقية: السجل يضيف طبقة إعادة توجيه وعبء صيانة. كل أداة جديدة تتطلب مدخلًا في السجل، وكل مدخل في السجل نقطة فشل محتملة إذا انحرف عن الكود. البديل — ترك الملكية ضمنية — أرخص حتى أول قرار متعارض، وعندها تتجاوز تكلفة التشخيص تكلفة السجل بهامش واسع.
قاعدة إعادة الهيكلة
إذا كان سلوك ما مهمًا، فهو ينتمي إلى الكود أو مخطط، لا إلى نثر داخل prompt.
هذه هي القاعدة كاملة. سهلة القول وصعبة الاتباع، لأن الـ prompts هي طريق المقاومة الأقل. إضافة جملة إلى prompt أسرع من إضافة حقل إلى مخطط. الجملة تعمل فورًا. المخطط يتطلب migration واختبارًا ومراجعة.
القاعدة ليست حظرًا للنثر. تحتاج الـ prompts إلى النثر للنبرة والتأطير ونوع الإرشاد الذي يقاوم الصياغة الرسمية. القاعدة حد: النثر للأشياء التي يمكن أن تتغير دون كسر النظام. المخططات والكود للأشياء التي لا يمكن أن تتغير.
اختبار مفيد: إذا كان السلوك شيئًا كنت ستكتب له اختبارًا، فهو لا ينتمي إلى prompt. وإذا لم تكن ستكتب له اختبارًا، فقد ينتمي إلى prompt. الاختبار هو الخط الفاصل.
ما تكلفته
المقايضة الصادقة هي أن هذا الانضباط يبطئ الإصدار الأول. prompt مُصدَّر بإصدار مع مالك وسجل تغييرات يستغرق وقتًا أطول للإطلاق من نص يُحرَّر في لوحة. اختبار عقد يستغرق وقتًا أطول للكتابة من mock. سجل يستغرق وقتًا أطول للإعداد من عُرف.
العائد ليس في الإصدار الأول. إنه في الخامس. أنظمة الوكلاء الرخيصة في التغيير هي أنظمة يكون فيها التغيير مقروءًا. المقروئية تأتي من آثار يمكن عمل diff لها واختبارها وامتلاكها. الـ prompts التي تعيش في لوحات رخيصة في الكتابة ومكلفة في التغيير. والـ prompts التي تعيش في مستودعات مكلفة في الكتابة ورخيصة في التغيير. الخيار هو أي تكلفة تدفع، ومتى.
بالنسبة للفرق التي تشغِّل أنظمة وكلاء في الإنتاج، السؤال ذو الصلة ليس ما إذا كان الدين موجودًا. إنه موجود. السؤال هو ما إذا كان مرئيًا. جزء prompt انحرف بصمت هو دين غير مرئي. جزء prompt له إصدار ومالك وسجل تغييرات هو دين مرئي، وهو النوع الوحيد الذي يمكن سداده.
الملخص
قواعد كود أنظمة الوكلاء تتآكل بشكل مختلف. لا يفحص المُصرِّف الـ prompts ولا مخططات الأدوات ولا أعراف الملكية، فيتراكم الدين دون إشارة. جعله مرئيًا يتطلب التعامل مع الـ prompts كآثار مُصدَّرة بإصدارات، واختبار مخططات الأدوات مقابل نقاط نهاية حية، والحفاظ على سجل لقدرات الوكلاء ومسارات التصعيد. قاعدة إعادة الهيكلة بسيطة: إذا كان سلوك ما مهمًا، فهو ينتمي إلى الكود أو مخطط، لا إلى نثر داخل prompt. تُدفع التكلفة مقدمًا؛ ويُدفع العائد عند كل تغيير لاحق.