Architecting Autonomy: From Prompt Engineering to Goal-Oriented Agents

كل فريق يقوم بإطلاق أداة مدعومة بنماذج اللغات الكبيرة (LLM) يصطدم بنفس العقبة. العرض التوضيحي (الدمو) يعمل بنجاح، لكن أول ضغط عمل حقيقي يفشل. المشكلة ليست في النموذج بحد ذاته، بل في البنية الهندسية.

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

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

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

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

من السلاسل إلى الحلقات التكرارية

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

السلسلة عبارة عن أنبوب عديم الحالة (stateless). يعالج البيانات لمرة واحدة ثم ينتقل لما بعدها. لا يعرف ماذا فعل قبل خطوتين، ولا يمكنه تغيير مساره عند حدوث فشل ما، ويتعامل مع كل طلب كما لو كان يرى العالم للمرة الأولى.

أما العميل الموجه بالأهداف فهو نظام ذو حالة (stateful) يحفظ البيانات. فهو يتتبع ما قام به، وما المتبقي، وما الذي تغير على طول الطريق. عندما تفشل خطوة ما، فإنه يتكيف مع الوضع. وعندما تظهر معلومات جديدة، يقوم بمراجعة الخطة.

يظهر الفرق في ثلاثة مجالات:

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

كيفية تخزين المعلومات. تحتفظ السلاسل بكل شيء داخل أمر التشغيل (prompt)؛ وبمجرد امتلاء نافذة السياق، تُفقد المعلومات. بينما يقوم العملاء الموجهون بالأهداف بكتابة النتائج في وحدة تخزين خارجية واسترجاع ما هو مطلوب فقط.

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

الفكرة الهندسية الأساسية هي حلقة التفكير التكرارية. فبدلاً من افتراض أن النموذج يمكنه التفكير في المشكلة بأكملها في تمريرة واحدة، فإنك تصمم النظام من أجل التكرار:

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

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

تخطيط ← تنفيذ ← ملاحظة ← تحديث — الحلقة التكرارية التي تتيح للعملاء ميزة التصحيح الذاتي بدلاً من الالتزام بتمريرة واحدة.

الطبقات الأربع التي تتقارب عندها وكلاء الإنتاج

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

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

1. التخطيط — فصل النية عن العمل

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

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

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

يقوم المخطط بإنشاء قائمة مهام، ولكنها قابلة للتعديل؛ فعندما تفشل الخطوة 3 أو تكشف عن معلومات جديدة، يتم إعادة كتابة الخطوات من 4 إلى 6 تلقائياً.

2. التفويض — إسناد الأعمال المتخصصة لعملاء متخصصين

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

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

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

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

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

3. الاستمرارية — ذاكرة تتجاوز حدود نافذة السياق

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

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

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

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

4. التركيب — دمج النتائج في منتج تسليمي واحد

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

هذا هو التركيب: دمج النتائج الفرعية المتوازية في منتج تسليمي واحد. وهو يعمل على مرحلتين:

التوزيع (Map). يكمل كل عميل فرعي مهمته المحددة بشكل مستقل - مثل البحث عن الحسابات، أو تطبيق السياسات، أو صياغة الحلول. وتعمل هذه المهام بالتوازي أو بشكل معزول، مما ينتج عنه مخرجات فردية.

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

نمط