بنيت نظامًا يكتشف ويتحقق ويطبق تلقائيًا المتطلبات ذات الصلة من التفاعلات السابقة دون سؤال المستخدم من أين جاءت.

الدرس الأساسي: مجرد استدعاء السجل السابق لا يكافئ معرفة ما لا يزال دقيقًا فعليًا. إعداد بحث أساسي لم يلتقط سوى 57% من المتطلبات التي يحتاجها وكيل البرمجة. إضافة طبقة تحقق رفعت ذلك إلى 100%.

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

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

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

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