00:00:00شكرًا لـ HubSpot على رعاية هذا الفيديو.
00:00:03في الواقع، حدث شيء كبير حقًا في ديسمبر 2025.
00:00:07ولم يدرك معظم الناس ذلك حتى.
00:00:09غرد أندرو كوبسي حول هذا الأمر الأسبوع الماضي.
00:00:10"من الصعب جدًا شرح مدى تغير البرمجة بسبب الذكاء الاصطناعي في الشهرين الماضيين،
00:00:15تحديدًا منذ ديسمبر الماضي."
00:00:17كما تحدث جريج من OpenAI عن هذا الأمر أيضًا.
00:00:20منذ ديسمبر، حدثت قفزات نوعية في قدرات النماذج والأدوات.
00:00:24وقد أخبره بعض المهندسين أن وظائفهم قد تغيرت بشكل جذري منذ ديسمبر
00:00:282025.
00:00:29إذًا، ما الذي حدث فعليًا في ديسمبر 2025؟
00:00:32باختصار، أحدث نموذج تم تقديمه حينها أصبح جاهزًا أخيرًا
00:00:37للمهام المستقلة طويلة الأمد.
00:00:38الحلم الأسمى للذكاء الاصطناعي كان دائمًا أنه بينما ننام،
00:00:43يمكن للذكاء الاصطناعي العمل على المهام باستقلالية تامة، على مدار الساعة.
00:00:46حتى في عام 2023، كان المشروع الأكثر شهرة، إذا كنتم تتذكرون، يسمى AutoGPT.
00:00:50كانت تلك هي المرة الأولى التي يتم فيها تقديم أنظمة الوكلاء المستقلة بالكامل.
00:00:54وكانت تعتمد على بنية أساسية وبسيطة تستخدم GPT-4 كنموذج
00:00:59لتقسيم قائمة المهام تلقائيًا بناءً على هدف المستخدم، مع ذاكرة تخزين بسيطة
00:01:03لحفظ النتائج.
00:01:04وكان الناس يقومون بأشياء جنونية مثل إعطاء هدف "اربح 100 ألف دولار"
00:01:08وتركه يدور في حلقة مهام لا نهائية حتى يكتمل.
00:01:11في ذلك الوقت، كان النظام يتوقف ويفشل فشلاً ذريعًا لأن النموذج لم يكن جاهزًا ببساطة.
00:01:15لكن منذ ديسمبر من العام الماضي، تغير هذا الأمر حقًا.
00:01:18أصبحت النماذج ذات جودة أعلى بكثير، وتمتلك ترابطًا طويل الأمد،
00:01:22ويمكنها إنجاز مهام أكبر وأطول بكثير.
00:01:24وقد رأينا أنواعًا مختلفة من التجارب تظهر في هذا القطاع.
00:01:28أولاً، منذ يناير، ظهر هذا المفهوم الساخن المسمى "الحلقة الخام" (rough loop)،
00:01:33وهي أبسط حلقة تكرار للوكيل لإجبار النموذج على العمل لفترة أطول
00:01:37حتى يتمكن من تولي مهام أكثر تعقيدًا.
00:01:38لقد جعلنا النموذج يعمل في حلقة كاملة مع بعض فحوصات الشروط البسيطة،
00:01:42لكننا بدأنا بالفعل نرى الفرق.
00:01:43وبعد أسبوع واحد، أطلقت Cursor تجربتها حيث استخدموا GPT-5.2
00:01:49لبناء متصفح بشكل مستقل من الصفر بـ 3 ملايين سطر من الأكواد.
00:01:52كما نشرت Anthropic هذه التجربة التي أجروها حيث استعانوا بفريق من وكلاء البرمجة
00:01:57للعمل بشكل مستقل على بناء مترجم لغة C من الصفر لمدة أسبوعين.
00:02:01وفي النهاية، قدم الوكلاء نسخة تعمل بكفاءة دون أي تدخل برمجي بشري.
00:02:05بل ويمكن تشغيل لعبة Doom داخل هذا المترجم أيضًا.
00:02:08وفي الوقت نفسه، بدأ مشروع OpenClaw في جذب الانتباه وحقق نموًا انفجاريًا
00:02:13لم نشهده من قبل.
00:02:14وكان من الصعب فهم ما يحدث مع OpenClaw لأنه من الخارج،
00:02:18من السهل تصنيفه كمجرد برنامج آخر يعيش داخل جهاز الكمبيوتر الخاص بك
00:02:23ويمكن الوصول إليه أيضًا عبر تليجرام.
00:02:27والسؤال هو: لماذا يحظى بكل هذه الشعبية؟
00:02:29فقط بعد أن استخدمته بعمق، أدركت أن الفرق الحقيقي هو أن OpenClaw يمثل
00:02:35هذا النوع من الوكلاء الذين يعملون دائمًا، ولفترات طويلة، وباستقلالية تامة،
00:02:40وهو ما يختلف تمامًا عن جميع أنظمة الوكلاء الأخرى التي استخدمناها سابقًا
00:02:45حيث يكون الإنسان هو المحرك الرئيسي لتوجيه الإجراء التالي.
00:02:46أما OpenClaw فهو يعمل دائمًا وبشكل استباقي.
00:02:49وهذا الشعور بالاستقلالية ناتج عن بنية بسيطة إلى حد ما
00:02:53تتضمن طبقة سياق للذاكرة مع محفزات ومهام مجدولة (cron jobs) لاتخاذ الإجراءات تلقائيًا،
00:02:58مع وصول كامل إلى جهاز الكمبيوتر، وهي بيئة قوية يمكنه العمل فيها.
00:03:02وأعتقد أن OpenClaw هو أول مشروع أحدث بالفعل التحول الجذري الأكبر
00:03:06في عام 2026، حيث ننتقل من أنظمة "المساعد الطيار" البسيطة القائمة على المهام
00:03:13إلى هؤلاء الوكلاء المستقلين تمامًا الذين يعملون لفترات طويلة.
00:03:15شيء يعمل دائمًا، وجاهز باستمرار، ويقدم أعمالاً منسقة وفائقة التعقيد.
00:03:20هذا تحول جوهري يجب عليك فهمه.
00:03:22النماذج اليوم هي في الواقع أقوى بكثير مما تعتقد،
00:03:27طالما أنك تصمم النظام الصحيح لإطلاق إمكانياتها.
00:03:28وهذا هو صلب ما أريد التحدث عنه اليوم.
00:03:30هندسة الربط (Harness Engineering) لتمكين الأنظمة المستقلة طويلة الأمد.
00:03:34إذا كانت هذه هي المرة الأولى التي تسمع فيها عن هندسة الربط، فهي بمثابة تطور
00:03:38لما تحدثنا عنه سابقًا وهو هندسة السياق أو هندسة الأوامر (Prompt Engineering).
00:03:41سابقًا، ركزنا حقًا على كيفية تحسين الأوامر ضمن نافذة السياق الفعالة
00:03:46للحصول على أفضل أداء للنموذج في جلسة عمل واحدة للوكيل.
00:03:49لكن هندسة الربط تركز حقًا على تلك المهام طويلة الأمد،
00:03:53مما يعني: كيف تصمم نظامًا يمكنه العمل عبر جلسات مختلفة ووكلاء متعددين؟
00:03:57وكيف تصمم سير العمل الصحيح لضمان استرجاع السياق ذي الصلة
00:04:01لكل جلسة واستخدام مجموعة الأدوات المناسبة لاستخراج أقصى ما في النماذج.
00:04:05هذا مفهوم جديد تمامًا، لكن الخبر السار هو أن الصناعة قد اتفقت بالفعل
00:04:09على بعض أفضل الممارسات التي يمكنك استخدامها من Anthropic و Vercel و LangChain وغيرهم.
00:04:14سأستعرض كل واحدة منها تلو الأخرى لترى الأنماط المتبعة.
00:04:16ولكن قبل أن نتعمق في هذا، ومع هذا التحول نحو الوكلاء المستقلين تمامًا،
00:04:21فإن إحدى أكبر الفرص في الأشهر الستة إلى الاثني عشر القادمة هي بناء OpenClaw لقطاع محدد.
00:04:25مما يعني أن تبحث بعمق وتفهم سير العمل الشامل لقطاع معين،
00:04:29ثم تبني وكيلاً مستقلاً بالبيئة والأدوات الصحيحة لتمكين العملية بالكامل.
00:04:34لهذا السبب أريد أن أعرفكم على هذا البحث الرائع الذي أجرته HubSpot
00:04:39حول تقرير تبني الذكاء الاصطناعي في التسويق عبر البريد الإلكتروني.
00:04:40إنه تقرير مذهل لتفهم كيف يستخدم الناس الذكاء الاصطناعي اليوم
00:04:44في قطاع مثل التسويق بالبريد الإلكتروني، وما هي الثغرات الموجودة.
00:04:47لأن هذا التقرير يعرض مسارات عمل وفرصًا واضحة في التسويق عبر البريد الإلكتروني
00:04:51يمكنك أتمتتها بالكامل.
00:04:52لقد استطلعوا آراء المئات من المسوقين عبر البريد الإلكتروني في كبرى الشركات
00:04:57لفهم كيف يعيد الذكاء الاصطناعي تشكيل مسارات عملهم بالضبط.
00:04:58يتحدثون عن سبب استمرار المسوقين في القيام بالكثير من عمليات التحرير الثقيلة،
00:05:03وما هي الأسباب وراء ذلك، بالإضافة إلى أكبر التحديات التي يواجهونها اليوم
00:05:06عند تطبيق الذكاء الاصطناعي في التسويق عبر البريد الإلكتروني.
00:05:07وكل واحدة من هذه النقاط تمثل فرصة كبيرة لك لبناء وكيل مستقل تمامًا.
00:05:11كما أنهم يغوصون في مؤشرات الأداء الرئيسية (KPIs) المحددة التي يهتمون بها أكثر،
00:05:15والتي أظهر فيها الذكاء الاصطناعي نتائج مثبتة.
00:05:16بالإضافة إلى ما يريده المسوقون عبر البريد الإلكتروني بالضبط من الذكاء الاصطناعي.
00:05:20لذا، إذا كنت مطورًا يفكر في منتج الوكيل الكبير القادم لبنائه،
00:05:24أوصيك بشدة بالاطلاع على هذا المصدر الرائع.
00:05:27لقد وضعت الرابط في الوصف أدناه لتتمكن من تحميله مجانًا.
00:05:30وشكرًا لـ HubSpot على رعاية هذا الفيديو.
00:05:32والآن لنعد إلى هندسة الربط لأنظمة الوكلاء طويلة الأمد.
00:05:36على مستوى عالٍ، هناك ثلاثة دروس تعلمتها من تلك الأنظمة.
00:05:39الأول هو أنه بالنسبة لوكلاء المهام طويلة الأمد، فإن الجزء الحاسم في تصميم النظام
00:05:44هو خلق هذه "البيئة المفهومة" حيث يمكن لكل وكيل فرعي أو جلسة عمل
00:05:49أن يفهموا حقًا أين وصلت الأمور.
00:05:50على الأرجح، هناك بعض مسارات العمل التي يمكن تنفيذها لفرض وضوح البيئة.
00:05:54وسأشرح المزيد حول ذلك.
00:05:56الثاني هو أن التحقق أمر بالغ الأهمية.
00:05:58يمكنك تحسين مخرجات النظام بشكل كبير من خلال السماح له بالتحقق من عمله
00:06:03بفعالية مع وجود حلقة تغذية راجعة أسرع.
00:06:04والثالث هو أننا بحاجة إلى الثقة في النموذج أكثر بدلاً من بناء أدوات متخصصة
00:06:08تغلف الكثير من التفكير والمنطق بشكل سابق لأوانه.
00:06:11يجب أن نعطي النموذج أقصى قدر من السياق مع أدوات عامة يفهمها بشكل طبيعي
00:06:16ونتركه يستكشف مثل البشر.
00:06:17سأقوم بتفكيك هذه الأشياء الثلاثة واحدًا تلو الآخر بينما نستعرض كل قسم هنا.
00:06:20أولاً، مدونة Anthropic حول "الربط الفعال للوكلاء الذين يعملون لفترات طويلة".
00:06:24لقد قاموا بتجربة استخدام Cloud Code SDK لبناء وكيل متخصص للمهام
00:06:29الطويلة جدًا مثل بناء نسخة من موقع cloud.ai.
00:06:32أولى حالات الفشل التي لاحظوها هي أن الوكلاء يميلون إلى فعل الكثير في وقت واحد.
00:06:37بشكل أساسي، سيحاول الوكيل دائمًا بناء التطبيق بالكامل من محاولة واحدة.
00:06:40وأدى ذلك إلى نفاد سياق النموذج في منتصف تنفيذه،
00:06:45تاركًا الجلسة التالية لتبدأ بميزة نصف مكتملة أو غير موثقة.
00:06:49بعد ذلك، سيضطر الوكيل إلى التخمين عما حدث فعليًا وقضاء وقت طويلاً
00:06:52في محاولة جعل التطبيق الأساسي يعمل مرة أخرى.
00:06:55والفشل الثاني الذي لاحظوه هو أن الوكلاء يميلون إلى إعلان اكتمال المهمة قبل الأوان.
00:07:00ربما واجهت هذا بنفسك عدة مرات أيضًا.
00:07:02حيث يدعي Cloud Code أو Cursor أن المشروع أو الميزة قد اكتملت،
00:07:05ولكن بمجرد اختبارها، تكتشف أنها لا تعمل في الواقع.
00:07:07لذا، كان نهجهم لحل سلوك الفشل الافتراضي للنموذج هو أولاً إعداد
00:07:12بيئة أولية تضع الأساس لجميع الميزات التي يتطلبها الأمر المعطى،
00:07:16مما يهيئ الوكيل للعمل خطوة بخطوة وميزة بميزة.
00:07:20هذا يشبه إلى حد ما نهج "الخطة" أو "وثيقة متطلبات المنتج" (PRD) التي نتبعها عادةً.
00:07:23الأمر الثاني هو البدء في توجيه كل وكيل لإحراز تقدم تدريجي نحو هدفه
00:07:27مع ترك البيئة في حالة نظيفة في نهاية كل جلسة.
00:07:32ما فعلوه هو البدء في تصميم هذا الحل المكون من جزأين.
00:07:35سيكون لديهم "وكيل تهيئة" (initializer agent) يستخدم أمرًا متخصصًا ليطلب من النموذج
00:07:40إعداد البيئة الأولية باستخدام نص برمجي init.sh، والذي سيقوم مثلاً بإعداد خادم تطوير،
00:07:45بحيث لا يحتاج النموذج التالي للقلق بشأن تلك الأمور.
00:07:48وأيضًا ملف cloud progress.txt الذي يحتفظ بسجلات لما قام به الوكيل
00:07:53بالإضافة إلى أول التزام (commit) في Git يوضح الملفات التي تمت إضافتها.
00:07:55ثم "وكيل برمجة" لكل جلسة لاحقة ليطلب من النموذج إحراز تقدم تدريجي،
00:08:01ثم ترك تحديثات منظمة.
00:08:02وكل هذه الجهود تهدف حقًا لخدمة غرض واحد وهو: كيف يمكنهم تعريف
00:08:07بيئة يمكن للوكلاء فيها فهم حالة العمل بسرعة عند البدء
00:08:11بنافذة سياق جديدة.
00:08:13لذا، فإن سير العمل هو أن يحاول وكيل التهيئة أولاً إعداد بيئة أو
00:08:17ما يمكن تسميته نظام توثيق لتتبع الخطة العامة والحفاظ عليها.
00:08:21والبيئة التي صمموها هنا تتضمن أولاً وثائق لقائمة الميزات
00:08:25لمنع الوكيل من محاولة بناء التطبيق دفعة واحدة أو اعتبار المشروع مكتملاً قبل الأوان.
00:08:30وسوف يجعلون وكيل التهيئة يقسم المشروع إلى أكثر من 200 ميزة
00:08:34ويسجلها في ملف JSON محلي يبدو كالتالي، حيث يكون لكل مهمة مواصفات مفصلة
00:08:39بالإضافة إلى حالة النجاح أو الفشل.
00:08:41افتراضيًا، سيتم وضع علامة "فشل" على جميع المهام.
00:08:43لذا، يُجبر النموذج دائمًا على النظر إلى هدف المشروع العام والتقدم المحرز
00:08:49واختيار المهمة ذات الأولوية القصوى والقيام بالشيء التالي.
00:08:50ولكن لكي ينجح سير العمل هذا، يحتاجون أيضًا إلى طريقة لإجبار النموذج على ترك البيئة
00:08:55في حالة نظيفة بعد إجراء تغيير الكود. وفي تجاربهم، وجدوا أن أفضل طريقة
00:08:59هي أن يطلبوا من النموذج تسجيل التقدم في Git مع رسالة تعليق وصفية
00:09:05وكتابة ملخص لتقدمه في ملف التقدم، ولكن مجرد التوثيق وبيئة السياق
00:09:08ليسا كافيين وحدهما لأن النموذج لديه هذا الميل الطبيعي لاعتبار شيء ما
00:09:13مكتملاً دون اختبار مناسب. في البداية، كانوا يطلبون من Cloud Code
00:09:17إجراء الاختبارات دائمًا بعد تغيير الكود من خلال اختبارات الوحدات (unit tests) أو اختبارات API
00:09:22لخادم التطوير.
00:09:23لكن كل تلك الأشياء كانت تفشل غالبًا في إدراك أن الميزة لا تعمل بشكل متكامل.
00:09:27بدأت الأمور تتغير حقًا عندما أعطوا النموذج الأدوات المناسبة للقيام بالاختبار
00:09:30الشامل (end-to-end) بنفسه، مثل Puppeteer MCP أو Chrome DevTools، حيث تمكن الوكيل
00:09:35من تحديد وإصلاح الأخطاء التي لم تكن واضحة بشكل مباشر من الكود نفسه.
00:09:39لذا، فهم يقومون أساسًا بإعداد الهيكل حيث يكون لديهم وكيل التهيئة لتقسيم
00:09:43هدف المستخدم إلى قائمة ميزات إلى جانب ملف init.sh ليتمكن من تشغيل خادم
00:09:47التطوير وملفات التقدم.
00:09:49بهذه الطريقة، يمكن لوكيل البرمجة التالي ببساطة قراءة قائمة الميزات للحصول على فهم
00:09:53لخطة المشروع العامة واختيار المهام عالية الأولوية وملف التقدم والسجلات لفهم
00:09:57أين وصلت الأمور.
00:09:59ثم تشغيل init.sh لبدء خادم التطوير فورًا وإجراء اختبار شامل للتحقق من أن البيئة
00:10:04نظيفة ليتمكن من الحصول على صورة كاملة وحلقة تغذية راجعة أسرع بينما تبدأ كل جلسة
00:10:09ونافذة سياق جديدة.
00:10:10في مدونة OpenAI، يتحدثون عن أشياء مشابهة جدًا.
00:10:13يجب عليك التأكد من أن بيئة التطبيق الخاصة بك واضحة ومفهومة.
00:10:16لقد جعلوا المستودع بالكامل هو نظام المعرفة أو السجل المرجعي.
00:10:19في البداية، وضعوا ملف agents.md عملاقًا وفشل بطرق متوقعة لأنه
00:10:23كان يمثل سياقًا أكبر من أن يستطيع أي وكيل إدارته وصيانته.
00:10:27لذا ما فعلوه هو تصميم هيكل بيئة وثائق مناسب وعاملوا ملف agents.md
00:10:32كجدول محتويات.
00:10:33حيث أعدوا نظام التوثيق هذا ليشمل التصميمات المعمارية، ووثائق التصميم، وخطة
00:10:37التنفيذ، ومخطط قاعدة البيانات، ومواصفات المنتج، وخطة واجهة المستخدم، والأمان، وغيرها الكثير،
00:10:42ووضعوا جدول المحتويات هذا في ملف agents.md ليتمكن الوكيل من استعادة
00:10:47معلومات عشوائية عند الحاجة.
00:10:49وهذا يتيح الكشف التدريجي عن المعلومات، بل إن OpenAI تذهب إلى أبعد من ذلك.
00:10:53يحاولون دفع ليس فقط معرفة الكود، بل وأيضًا مستندات Google ورسائل Slack وكل تلك
00:10:58المعلومات المتناثرة الأخرى، وتغذية هذه البيانات في المستودع كنسخة محلية
00:11:03من المستندات.
00:11:04ليتمكن الوكيل أيضًا من استرجاعها؛ لأنه من وجهة نظر الوكيل، إذا كان هناك شيء لا يمكن الوصول إليه
00:11:09في البيئة، فهو عمليًا غير موجود.
00:11:11ولكن مرة أخرى، التوثيق وحده لا يحافظ على ترابط قاعدة الكود التي ينشئها الوكيل بالكامل.
00:11:16لقد أدخلوا أيضًا مسارات عمل برمجية معينة لفرض الثوابت.
00:11:20على سبيل المثال، قاموا بتقسيم هندسة النطاقات بحدود واضحة ومتقاطعة،
00:11:25مما سمح لهم بفرض تلك القواعد من خلال فحوصات مخصصة، وأدوات تحليل الكود (linters)، واختبارات هيكلية،
00:11:29والتي يمكن تفعيلها وحقنها تلقائيًا مع كل عملية Git pre-commit.
00:11:33وهذا النوع من الهندسة المعمارية عادةً ما يتم تأجيله حتى يكون لديك مئات المهندسين
00:11:37في شركة برمجيات تقليدية، ولكن مع وكيل البرمجة، يعد ذلك شرطًا أساسيًا مبكرًا.
00:11:41ضمن تلك الحدود، تمنح الفرق والوكلاء حرية كبيرة في كيفية صياغة الحلول
00:11:46دون الحاجة إلى إدارة تفصيلية أو الخوف من انحراف الهندسة المعمارية.
00:11:49وفي الوقت نفسه، قاموا بتحسين قاعدة الكود بشكل كبير.
00:11:52على سبيل المثال، جعلوا التطبيق قابلاً للتشغيل لكل Git worktree، بحيث يمكن للوكلاء تشغيل
00:11:55وإدارة العديد من الحالات المختلفة.
00:11:57كما قاموا بربط بروتوكول Chrome DevTools في بيئة تشغيل الوكيل بحيث يمكن للوكيل
00:12:01إعادة إنتاج الأخطاء والتحقق من الإصلاح عبر لقطات DOM ولقطات الشاشة والتنقل.
00:12:05ومع إعداد كل من البيئة وسير العمل، تجاوز المستودع أخيرًا الحد الأدنى
00:12:09الذي يسمح للوكلاء بقيادة ميزة جديدة من البداية إلى النهاية.
00:12:13لذا، في كل مرة يتلقى فيها الوكيل أمرًا واحدًا، سيبدأ بالتحقق من
00:12:17الحالة الحالية لقاعدة الكود، وإعادة إنتاج الخطأ المبلغ عنه، وتسجيل فيديو لإثبات
00:12:21الفشل، ثم تنفيذ الإصلاح، والتحقق من الإصلاح عن طريق تشغيل التطبيق، وتسجيل فيديو ثانٍ
00:12:25يوضح الحل، وفي النهاية دمج التغيير.
00:12:29تستعرض هاتان المدونتان دروسًا جيدة جدًا وأنظمة الربط الضرورية التي تحتاج لوضعها
00:12:32لإنشاء نظام مستقل بالكامل.
00:12:34وفي الوقت نفسه، هناك أيضًا دروس معينة.
00:12:36غالبًا عندما نبني وكلاء، خاصة الوكلاء المتخصصين في مجالات معينة، يكون ميلنا هو
00:12:40بناء أدوات متخصصة للقيام بمهام محددة في ذلك المجال.
00:12:43لكن الدرس المستفاد هو أن نماذج اللغة الكبيرة تعمل دائمًا بشكل أفضل مع الأدوات العامة
00:12:47التي تفهمها بشكل طبيعي.
00:12:49نشرت Vercel هذا المقال الرائع حول كيفية إعادة تصميم وكلاء تحويل المهام إلى SQL.
00:12:53لقد أمضوا شهورًا في بناء وكيل داخلي متطور لتحويل النص إلى SQL باستخدام
00:12:58هندسة أوامر ثقيلة بالأدوات المتخصصة وإدارة دقيقة للسياق.
00:13:02ولكن كما جرب الكثير منا من قبل، فإن هذا النوع من الأنظمة يعمل نوعًا ما ولكنه هش للغاية،
00:13:06وبطيء، ويتطلب صيانة مستمرة.
00:13:09لأنه مع كل حالة استثنائية جديدة تحدث، ستحتاج إلى حقن أمر جديد للوكيل.
00:13:12ولكن لاحقًا جربوا شيئًا واحدًا غير المسار تمامًا.
00:13:15لقد حذفوا معظم الأدوات المتخصصة من الوكيل واكتفوا بأداة واحدة لتنفيذ الأوامر المجمعة (batch command tool).
00:13:20ومع هذه البنية الأبسط بكثير، أصبح أداء الوكيل أسرع بـ 3.5 مرة في الواقع
00:13:25مع استخدام رموز (tokens) أقل بنسبة 37% وزيادة معدل النجاح من 80% إلى 100%.
00:13:30تمت مشاركة دروس مماثلة من فريق Anthropic أيضًا حيث تحدثوا عن أنه بدلاً
00:13:34من امتلاك أدوات متخصصة للبحث والتنفيذ، لديهم أداة مجمعة واحدة فقط حيث
00:13:38يمكنهم تشغيل grep و tail و npm و npm run lint.
00:13:41وفي الأساس، أعتقد أن هذا يرجع أيضًا إلى أن نموذج اللغة الكبير أكثر ألفة
00:13:45بتلك الأدوات البرمجية الأصلية التي تمتلك مليارات من رموز التدريب مقابل استدعاء أدوات
00:13:49مخصصة بتنسيق JSON يحتاج النموذج لإنشائها.
00:13:51وقد تحدثت عن هذا في فيديو استدعاء الأدوات البرمجية الذي نشرته الأسبوع الماضي.
00:13:55وأعتقد أن هناك مبادئ أساسية مماثلة هنا، لكن أساس تلك البنى البسيطة
00:13:59هو مرة أخرى السياق الجيد وبيئة التوثيق حيث يمكن للنموذج استخدام أدوات عامة
00:14:05لاسترجاع السياق تدريجيًا.
00:14:06وهذا هو الحال نفسه مع OpenClaw.
00:14:09أحد الأسباب التي تجعل OpenClaw مثيرًا للاهتمام هو امتلاكه لبيئة سياق
00:14:13بسيطة بشكل مدهش ولكنها فعالة.
00:14:15لديهم قائمة من الوثائق لتخزين المعلومات الأساسية. ومع هذا الأساس،
00:14:18يمتلكون فقط الأدوات الأكثر بدائية مثل قراءة وكتابة وتعديل الملفات، وتشغيل أوامر الدفعة
00:14:23وإرسال الرسائل.
00:14:24كل القوة تأتي من منح الوكيل بيئة لاسترجاع السياق ذي الصلة بالإضافة إلى مكتبة
00:14:29مهارات كبيرة لتوسيع القدرات.
00:14:31إذًا، هذه هي الدروس العملية الثلاثة حول كيفية إجراء هندسة الربط للوكلاء
00:14:35المعقدين الذين يعملون لفترات طويلة.
00:14:36من خلال إعداد بيئة سياق واضحة لتمكين كل جلسة من جلب السياق بفعالية،
00:14:41ووضع سير العمل والأدوات الصحيحة لكي يتمكن النموذج من التحقق من عمله بفعالية، مما يسرع
00:14:46حلقة التغذية الراجعة والثقة بالوكيل باستخدام أدوات عامة يفهمها بشكل طبيعي.
00:14:50إذا كنت مهتمًا، سأشارك المزيد من التفاصيل حول كيف أقوم بتحويل هذه الدروس
00:14:54إلى عملية دورة حياة تطوير.
00:14:58في AI Builder Club، لدينا دورات وتدريبات حول البرمجة الحدسية (vibe coding) وبناء
00:15:02وكلاء جاهزين للإنتاج.
00:15:03وفي كل أسبوع، أشارك أنا وخبراء الصناعة أحدث الدروس العملية.
00:15:08لذا، إذا كنت مهتمًا بتعلم ما أتعلمه كل يوم، يمكنك النقر على الرابط
00:15:12أدناه للانضمام إلى المجتمع.
00:15:13أتمنى أن تكونوا قد استمتعتم بهذا الفيديو.
00:15:14شكراً لكم، وأراكم في المرة القادمة.