تطوير وكلاء الذكاء الاصطناعي: كيف نبني فعلياً

تحديد النطاق: جرد الأدوات وتحديد ضوابط الحماية

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

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

قرارات البنية

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

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

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

البناء: التكامل، تصميم التعليمات، والاختبار

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

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

النشر: المراقبة، التسجيل، والتراجع

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

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

ما تحصلون عليه فعلياً عند التسليم

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

كيف نحدد التكلفة فعلياً

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

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