العناصر الخمسة اللازمة لبناء “مصدر طاقة الشركة”

كيف تبني مولد شركة؟

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

• ‍يعيش في الأماكن التي يعمل فيها الناس بالفعل (بالنسبة لنا هذا هو Slack)
• يعرف من يطلب، ويقوم بتقديم الخدمات لذلك الشخص بطريقة مختلفة، بينما يظهر هو نفسه كجهة مستقلة للآخرين
• لديه ذاكرة، محددة على مستوى العالم أو على مستوى المستخدم
• يُنفَّذ الكود في سجن خاص ويمكنه إصدار طلبات إلى الخدمات التي تتطلب المصادقة
• نسبة كبيرة من العمليات تُعتبر مخططة بدلاً من أن يتم استدعاؤها بشكل صريح من قبل شخص ما (الوكلاء المحيطون!!)

شكرًا لـ@caspar_br على المساعدة في هذا البوست

الوكلاء الداخليون في LangChain

لتأسيس هذا النقاش، قارن بإيجاز بالنسبة للعوامل الثلاثة الرئيسية التي لدينا في LangChain:

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

OpenSWE: وكيل الهندسة لدينا، يمكنه العمل على تقديم طلبات التغييرات وكتابتها، كما يقوم بمراجعة الكود لجميع الطلبات.

استوديو المحتوى: وكيل التسويق لدينا، يمكنه إعداد الموارد (المدونات، الصور، ملفات PowerPoint، الفيديوهات) بأسلوبنا ومع معرفة بالموقع التسويقي لنا

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

المشكلة: تجربة المستخدم

جميع وكلاءنا يعيشون في الأماكن التي يعمل فيها الناس، وهو ما يُعنى لنا بشبكة Slack. لكل منهم مكان عمله الخاص. تطبيقات Slackويمكن إرسالها عبر DM أو تسميتها في القناة. من الفوائد التي تأتي من العمل مع هؤلاء الوكلاء في القنوات أن الآخرين يمكنهم رؤية كيف يستخدم الناسها.

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

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

المشكلة: الهوية

كانت المشكلة الأكثر تعقيدًا وصعوبة التي تواجهنا هي هوية الشخص، وتحديدًا: عندما يقوم هؤلاء الوكلاء بأفعال، فمن الذي يمثلونه في تنفيذ تلك الأفعال؟

هناك طريقتان رئيسيتان يتم التعامل بهما في الصناعة:

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

هكذا تعاملنا مع كل وكيل (الدليل: إضافة الهوية إلى الوكيلات العميقة المُدارة، إدارة الاتصالات):

OpenSWE:

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

وحدة GTM:

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

استوديو المحتوى:

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

المشكلة: الذاكرة

لدى جميع الوكلاء طبقتان من الذاكرة:

• الذاكرة العالمية: ذاكرة تُطبق على جميع المستخدمين
• ذاكرة المستخدم: ذاكرة تنطبق فقط على المستخدم المحدد

يقرر العملاء أي حقائق يريدون تذكرها لكل مستوى من مستويات الذاكرة.

ربما هذه هي المنطقة الأقل استكشافًا حتى الآن – لدينا الكثير من العمل الذي نريد القيام به هنا!

المشكلة: تنفيذ الكود

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

المشكلة: التشغيلات المخطط لها

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

بعض هذه الأشياء يتم تهيئتها من قبل مطور الخادم. على سبيل المثال: OpenSWE يستمع إلى الطلبات والإصلاحات، وعند إنشاء طلب جديد، يقوم بمراجعته.

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

تم بناء كل شيء على الوكالات العميقة المُدارة

جميع هذه الوكلاء مبني على العملاء العميق المُدار، والذي يقع فوق منصة العملاء العميق المفتوحة المصدر. يوفر هذا النظام البنية التحتية اللازمة لحل جميع هذه المشكلات (القنوات، الكرونات، الصناديق الرملية، الذاكرة، الهوية)، مع توفير مرونة كافية لتخصيص سلوك الوكيل حسب الحاجة. جربه اليوم باستخدام البدء السريع!