صخب عشوائي حول مكاننا مع وكلاء الذكاء الاصطناعي:

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

بدأ المزيد من الوكلاء الديناميكيين / المستقلين في العمل ومفيدين للبحث (خاصة إذا كان على شبكة الإنترنت) والترميز. أقل موثوقية بمجرد البدء في إضافة المزيد من مصادر البيانات (مثل واجهات برمجة التطبيقات). يشعر وكلاء القراءة فقط بالأمان وسهولة الاختبار ، لكن السماح للوكلاء المستقلين باتخاذ إجراء (كتابة) أمر مخيف. (فكرة عشوائية حول هذا: سيكون رائعا إذا سمحت لك أدوات مثل CRM ب "تفرع" مرآة التطوير وتشغيل تجارب الأتمتة التي يمكنك التراجع عنها أو دمجها مرة أخرى.)

يعمل الوكلاء الديناميكيون بشكل جيد عندما يتمكنون من (1) إنشاء خطة جيدة وتتبعها و (2) تنفيذ المهام بشكل صحيح ، بينما (3) إيجاد السياق الصحيح لتغذية كل خطوة (كل من التخطيط وكل مهمة). أخيرا ، يحتاج إلى (4) التفكير على طول الطريق (إما مع أو بدون مدخلات بشرية) حتى يتمكن من تعديل الخطة بشكل مناسب ، وكذلك تحسين الطريقة التي ينفذ بها المهام الفاشلة أو ضعيفة الأداء.

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

تنفيذ المهام: عادة ما تكون المهام عبارة عن استدعاءات واجهة برمجة تطبيقات (تتطلب المصادقة وفهم كيفية استخدام واجهة برمجة التطبيقات ، وبنية البيانات الأساسية - والتي يمكن أن تكون فريدة كما هو الحال في CRM أو DB مع جداول / أعمدة مخصصة) ، ومنطق LLM (مثل التلخيص) ، ومجموعة ، وحتى وكلاء سير العمل *. وكيل البحث هو في الحقيقة مجرد بحث على الويب والتلخيص في حلقة. وكلاء الترميز هم CRUD على قاعدة التعليمات البرمجية الخاصة بك ، وربما البحث على الويب عن واجهات برمجة تطبيقات التعلم. يبدو أن الوصول إلى واجهة برمجة التطبيقات المصادقة والأساسي قد تم حلهما (MCPs مناسبة هنا) ، لكنني أود أن أرى المزيد حول السياق الخاص بالأداة (اسأل المستخدم ، ولكن أيضا قم بالتحليل عند الاتصال الأولي ، والبحث في البيانات الموجودة لفهم كيفية استخدام الأداة ، وكيفية تنظيم البيانات ، وما هي السيناريوهات / المشاريع التي نستخدم الأداة من أجلها.) ، يجب أن تتحول الأخطاء / التفكير / التعليقات إلى دروس منظمة يتم إدخالها مرة أخرى في السياق عند الاقتضاء. يمكن استخدام نفس الأدوات لأغراض مختلفة وبطرق مختلفة بين المنظمات ونحتاج إلى التقاط / توثيق ذلك بطريقة ما لتنفيذ المهام بشكل جيد.

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

التفكير: لدينا أدوات مراقبة الوكيل التي تغطي تكاليف LLM / API ، والملاحظة ، ولكن تعيين النجاح / الفشل يمثل تحديا - أحد المجالات التي يكون فيها وكلاء الترميز لديهم ساق على الآخرين هو طريقة حتمية لملاحظة الإخفاقات (من خلال اختبار الكود). بالنسبة للعديد من المهام الوكالية الأخرى ، ما زلنا نكتشف الطريقة الصحيحة لجمع المدخلات البشرية لتحسين المخرجات المستقبلية. Afaik ، التفكير اليوم هو الإنسان في الحلقة ، حيث يتم تغذية التعليقات إلى حد كبير إلى المطورين البشريين لتحسين الوكيل ، ولكن الفتح يأتي عندما نكتشف كيفية تحويل التفكير إلى تحسين ذاتي - حيث يأخذ الوكيل رؤى من الإخفاقات في إنشاء قائمة المهام وتنفيذ المهام للقيام بعمل أفضل في المرة القادمة. في الأساس ، يجب أن يتحول التفكير إلى سياق جيد التنظيم يمكن سحبه إلى مطالبات عند وفقط عند الاقتضاء. يتطور هذا إلى أجزاء دقيقة من الوكيل ، ثم بيئات RL الوكالية - لا يزال يبدو مبكرا جدا هنا

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

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

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

ما الذي أفتقده أيضا؟