العنوان الأصلي: ما الذي يجب تعلمه، وبناؤه، وتجاوزه في وكلاء الذكاء الاصطناعي (2026)
الكاتب الأصلي: Rohit
الترجمة: Peggy، BlockBeats

ملاحظة المحرر: مجال وكلاء الذكاء الاصطناعي يدخل الآن مرحلة انفجار الأدوات، وقلة التوافق.

يظهر كل أسبوع إطار عمل جديد، ونموذج جديد، ومعيار جديد، ومنتج «عشرة أضعاف الكفاءة» جديد، لكن السؤال الحقيقي لم يعد «كيف أتابع كل التغييرات»، بل «أي من هذه التغييرات تستحق الاستثمار الحقيقي».

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

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

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

وفيما يلي النص الأصلي:

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

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

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

على مدى العامين الماضيين، كنت أطور منتجات في هذا المجال، وحصلت على عروض عمل بأكثر من 250 ألف دولار سنويًا، وأعمل الآن في شركة سرية مسؤولة عن التقنية. إذا سألني أحد «ماذا يجب أن أركز عليه الآن؟»، فهذه هي الإجابة التي أرسلها له.

هذه ليست خارطة طريق. مجال الوكلاء لم يحدد بعد وجهته بوضوح. المختبرات الكبرى تكرر بشكل علني، وتعيد طرح المشكلات، وتكتب تحليلات، وتصلح عبر الإنترنت. إذا استطاع فريق Claude Code إصدار نسخة تسببت في تراجع الأداء بنسبة 47%، وادرك المستخدمون المشكلة بعد اكتشافها، فإن فكرة «خريطة مستقرة تحتها» هي خرافة. الجميع لا زال يتخبط. الشركات الناشئة لديها فرصة لأنها، في النهاية، لا تعرف الإجابة أيضًا. الأشخاص الذين لا يكتبون رمزًا يعملون مع الوكلاء، ويقدمون أشياء في يوم الجمعة كانت تعتبر مستحيلة في يوم الثلاثاء، وفقًا لخبراء التعلم الآلي.

وأهم شيء في هذه اللحظة هو أنها غيرت فهمنا لـ«الخبرة». المسار التقليدي يركز على الخبرة: الشهادات، الوظائف المبتدئة، الوظائف العليا، الوظائف ذات الخبرة، والرتب التي تتراكم ببطء. هذا منطقي عندما لا تتغير المجالات بشكل جذري. لكن الآن، الأرض التي يقفون عليها تتغير بسرعة مماثلة. الفرق بين شاب يبلغ من العمر 22 عامًا ويعرض نموذج وكيل علني، ومهندس مخضرم يبلغ من العمر 35 عامًا، لم يعد فقط في سنوات الخبرة في التكديس التقني. كلاهما يواجه لوحة فارغة. بالنسبة لهم، النمو الذي يحقق الفائدة المركبة هو الاستمرار في التسليم، والقدرة على الاعتماد على قدرات أساسية لا تتغير خلال ربع سنة.

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

المرشح الحقيقي للفلترة الفعالة

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

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

هل لا تزال مهمًا بعد عامين؟
إذا كان مجرد غلاف لنموذج متقدم، أو معلمة CLI، أو «نسخة Devin»، فالإجابة غالبًا لا. إذا كان أصلاً من أساسيات مثل البروتوكول، أو نمط الذاكرة، أو طريقة الصندوق الرملي، فالإجابة أكثر احتمالًا نعم. المنتجات المغلفة لها عمر نصف قصير، بينما عمر النصف للموارد الأساسية يمكن أن يُحسب بالسنوات.

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

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

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

هل يمكنك قياس مدى تحسين وكيلك حقًا؟
إذا لم تستطع، فأنت تتخمن. الفرق بين فريق بدون تقييم وفريق يستخدم التقييم هو أن الفريق الأول يعتمد على الشعور، بينما الثاني يمكنه الاعتماد على البيانات: هل GPT-5.5 أفضل، أم Opus 4.7، في عبء العمل المحدد لهذا الأسبوع.

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

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

ما الذي يجب تعلمه

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

هندسة السياق

أهم تغيير في العامين الماضيين هو أن «هندسة الطلبات» أصبحت تسمى «هندسة السياق». هذا التغيير حقيقي، وليس مجرد تسمية جديدة.

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

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

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

إذا قرأت مقالًا واحدًا عن هذا الموضوع، فاقرأ «Effective Context Engineering for AI Agents» من Anthropic. ثم اطلع على مراجعتهم لنظام البحث متعدد الوكلاء، حيث يوضح الأرقام مدى أهمية عزل السياق مع توسع النظام.

تصميم الأدوات

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

خمس إلى عشرة أدوات ذات أسماء جيدة، تفوق عشرين أداة عادية. يجب أن يكون اسم الأداة عبارة عن فعل في اللغة الإنجليزية، ويجب أن يكون الوصف واضحًا حول متى تستخدمها ومتى لا. رسائل الخطأ يجب أن تكون رد فعل يمكن للنموذج أن يتصرف بناءً عليه. «تجاوز حد 500 رمز، يرجى التلخيص قبل المحاولة» أفضل من «Error: 400 Bad Request». فريق بحثي واحد أبلغ أن إعادة كتابة رسائل الخطأ أدت إلى تقليل حلقات إعادة المحاولة بنسبة 40%.

مقال «Writing tools for agents» من Anthropic هو نقطة انطلاق جيدة. بعد قراءته، أضف ملاحظاتك على أدواتك، وراقب أنماط الاستخدام الحقيقي. غالبًا، يكون التحسين الأكبر في موثوقية الوكيل من جانب الأدوات. كثيرون يضبطون الطلبات، لكنهم يتجاهلون المكان الذي يمكن أن يحقق أكبر تأثير.

نمط المنسق-الوكيل الفرعي

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

نظام أبحاث Anthropic يعمل بهذه الطريقة. وكلاء Claude Code الفرعيون أيضًا. Spring AI وأغلب الأطر الإنتاجية الآن تتبنى هذا النمط. الوكيل الفرعي يمتلك سياقًا صغيرًا ومركزًا، ولا يملك صلاحية تعديل الحالة المشتركة. التعديلات تتم بواسطة المنسق.

مراجعة «Don’t Build Multi-Agents» من Cognition و«How we built our multi-agent research system» من Anthropic، تبدو كوجهات نظر متعارضة، لكنها في الحقيقة تتحدث عن نفس المفهوم باستخدام مصطلحات مختلفة. كلاهما يستحق القراءة.

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

التقييمات وبيانات الذهب

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

أفضل الممارسات: جمع سجل تتبع من بيئة الإنتاج، وتصنيف حالات الفشل، واستخدامها كمجموعة استرجاع. عند ظهور فشل جديد، أضفه. الجزء الذاتي يستخدم نموذج لغة كقاضٍ، والباقي يستخدم مطابقة دقيقة أو فحوصات برمجية. قبل أي تغيير في الطلب أو النموذج أو الأداة، اختبر باستخدام مجموعة الاختبار. تقرير Spotify يقول إن طبقة القاضي تمنع حوالي 25% من مخرجات الوكيل قبل أن تصل للمستخدم. بدونها، واحد من كل أربعة نتائج سيئة تصل إلى المستخدم.

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

إطارات التقييم، مثل Braintrust، Langfuse evals، وLangSmith، جيدة، لكنها ليست العقبة الحقيقية. العقبة الحقيقية هي وجود مجموعة بيانات موسومة. من اليوم الأول، ابدأ بجمعها. 50 عينة موسومة يدويًا في نصف يوم كافية للبدء. لا يوجد عذر لعدم وجودها.

استخدام نظام ملفات كمصدر للحالة، ودورة «فكر-تصرف-راقب»

بالنسبة لأي وكيل ينفذ مهام متعددة الخطوات، فإن البنية المستدامة هي: التفكير، العمل، المراقبة، التكرار. نظام الملفات أو التخزين الهيكلي هو مصدر الحقيقة. كل إجراء يُسجل ويمكن إعادة تشغيله. أدوات مثل Claude Code، Cursor، Devin، Aider، OpenHands، goose، كلها تتوافق مع هذا المفهوم، وليس بدون سبب.

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

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

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

فهم مفهوم MCP بشكل مبسط

لا تكتفِ بمعرفة كيفية استدعاء خادم MCP. تعلم كيف يعمل النموذج الخاص به. هو يربط بين قدرات الوكيل، والأدوات، والموارد، ويقدم آليات توثيق ونقل قابلة للتوسع. بمجرد فهم ذلك، ستجد أن جميع «إطارات تكامل الوكيل» الأخرى هي نسخ مخففة من MCP، وستوفر عليك وقت التقييم.

مؤسسة Linux تتولى الآن إدارة MCP. جميع مزودي النماذج الرئيسيين يدعمونه. يمكن مقارنته بـ«USB-C للذكاء الاصطناعي»، وهو الآن أقرب إلى الحقيقة من أن يكون مجرد سخرية.

الصندوق الرملي هو أصل أساسي

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

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

ماذا تستخدم لبنائه

إليك الاختيارات حتى أبريل 2026. ستتغير، لكن ليس بسرعة كبيرة. في هذا المستوى، اختر دائمًا «الأشياء المملة ولكن المستقرة».

طبقة التنسيق

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

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

إذا كنت تفضل Pydantic وترغب في أن تكون نوعية الأمان أولوية، فإن Pydantic AI هو خيار جيد للمشروع الجديد. أطلق الإصدار 1.0 في نهاية 2025، ويظهر زخمًا.

بالنسبة لمزودي الخدمات، مثل استخدام الحاسوب، أو الصوت، أو التفاعل في الوقت الحقيقي، يمكن استخدام Claude Agent SDK أو OpenAI Agents SDK داخل عقدة LangGraph. لا تحاول أن تجعلها منسقًا متعدد الأنظمة، فهي مصممة لتحسين أداء سيناريوهات محددة.

طبقة البروتوكول

MCP، لا شيء غيره.

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

طبقة الذاكرة

عند اختيار نظام الذاكرة، لا تعتمد على الشعبية، بل على مدى استقلالية الوكيل.

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

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

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

Langfuse هو الخيار المفتوح الافتراضي. يمكن استضافته ذاتيًا، ويغطي تتبع الأداء، وإدارة إصدارات الطلب، والتقييم باستخدام نموذج لغة كقاضٍ. إذا كنت تستخدم LangChain، فإن تكامل LangSmith سيكون أكثر تكاملًا. Braintrust مناسب لعمليات التقييم البحثية، خاصة في المقارنات الدقيقة. OpenLLMetry / Traceloop يدعم أدوات قياس متعددة اللغات باستخدام OpenTelemetry.

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

بيئة التشغيل والصندوق الرملي

E2B مناسب لتنفيذ الشيفرة داخل صندوق رملي عام. Browserbase مع Stagehand مناسب لأتمتة المتصفح. Anthropic Computer Use مناسب للمهام التي تتطلب تحكمًا كاملًا في نظام التشغيل. Modal مناسب للمهام المفاجئة قصيرة المدى.

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

النموذج

ملاحقة المعايير مرهقة، وغالبًا غير مجدية. حتى أبريل 2026، نرى أن:

·Claude Opus 4.7 و Sonnet 4.6 مناسبان للموارد التي تتطلب موثوقية عالية، وتعدد خطوات، واستعادة أنيقة للفشل. بالنسبة لمعظم الأحمال، Sonnet هو الخيار الأمثل من حيث التكلفة والأداء.

·GPT-5.4 و GPT-5.5 مناسبان للمهام التي تتطلب أقصى قدر من قدرات CLI / الطرفية، أو التي تعتمد على بنية OpenAI بشكل أساسي.

·Gemini 2.5 و 3 مناسبان للمهام ذات سياق طويل، أو متعددة الوسائط.

·عندما يكون التكلفة أكثر أهمية من الأداء، خاصة في المهام ذات الحدود الواضحة والتعريف الضيق، يمكن النظر في DeepSeek-V3.2 أو Qwen 3.6.

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

ما الذي يمكن تجاوزه

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

AutoGen و AG2، لا تستخدمها في الإنتاج.
إطار عمل Microsoft هذا تحول إلى المجتمع، وتوقف عن التحديث، والطريقة التي يُبنى بها غير ملائمة للاحتياجات الحقيقية للفريق الإنتاجي. يمكن استخدامها للأبحاث، لكن لا تعتمد عليها في المنتج.

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

Microsoft Semantic Kernel، إلا إذا كنت ملتزمًا تمامًا بتقنية Microsoft، واهتمام المشتريين بها.
هو ليس الاتجاه الذي يسير فيه النظام البيئي.

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

استخدام وكيل كتابة الكود بشكل مستقل كخيار معماري.
Code-as-action هو مجال بحث مثير، لكنه ليس الوضع الافتراضي في الإنتاج بعد. ستواجه العديد من مشكلات الأدوات والأمان، وقد لا يتعامل منافسوك مع هذه التحديات.

الدعاية لـ «وكيل مستقل ذاتي»
AutoGPT و BabyAGI، انتهت صلاحية هذا الاتجاه في المنتج. النهج الحقيقي هو «الهندسة الوكيلة الموجهة»، مع إشراف، وحدود، وتقييم. من يبيع «نشر دون إدارة» في 2026، هو في الواقع يبيع منتجات 2023.

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

كن حذرًا عند اختيار منصات «بناء أي وكيل» للشركات، مثل Google Agentspace، AWS Bedrock Agents، أو Microsoft Copilot Studio. قد تكون مفيدة لاحقًا، لكنها الآن غير واضحة، والإصدارات بطيئة، والميزانية بين الشراء والبناء تميل إلى بناء وكيل ضيق، أو شراء واحد متخصص. استثناءً، Salesforce Agentforce و ServiceNow Now Assist، لأنها مدمجة في أنظمة سير العمل التي تستخدمها.

لا تتبع تصنيفات مثل SWE-bench أو تصنيفات OSWorld.
في 2025، سجل باحثو Berkeley أن معظم المعايير المفتوحة يمكن التلاعب بها، دون حل فعلي للمهمة الأساسية. الآن، يستخدم الفرق نتائج اختبار Terminal-Bench 2.0 وتقييماتهم الداخلية كمؤشرات أكثر موثوقية. الشك في المعايير الرقمية فقط هو السائد.

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

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

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

كيفية التقدم بشكل فعال

إذا لم تكن فقط تريد «مواكبة الوكلاء»، بل تريد اعتمادهم بشكل حقيقي، فهذه الخطوات فعالة. قد تبدو مملة، لكنها مجدية.

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

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

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

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

ابدأ بدورة واحدة لوكيل واحد. اختر LangGraph أو Pydantic AI. النموذج: Claude، Sonnet 4.6، أو GPT-5. أعطِ الوكيل ثلاثة إلى سبعة أدوات مصممة جيدًا. دعّه يستخدم نظام ملفات أو قاعدة بيانات للحالة. أطلقه لمجموعة صغيرة من المستخدمين، وراقب التتبع.

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

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

اختر البنية التحتية المملة. أدوات MCP، الصندوق الرملي E2B أو Browserbase، الحالة في Postgres أو أي نظام تخزين تستخدمه. المصادقة والمراقبة، استمر في استخدام أنظمتك الحالية. البنى غير التقليدية نادراً ما تكون العامل الحاسم، الانضباط هو العامل الحقيقي.

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

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

كيف تعرف أن الاتجاه صحيح

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

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

عادة أسبوعية مفيدة: خصص 30 دقيقة يوم الجمعة لقراءة هذا المجال. اقرأ ثلاثة أشياء: مدونة أنثروبك، ملاحظات Simon Willison، Latent Space. إذا كانت هناك مراجعة بعد الوفاة، اقرأ واحدة أو اثنتين إضافيتين. الباقي يمكن تجاوزه. لن تفوت الأشياء المهمة حقًا.

ماذا تراقب في المستقبل

الربعان القادمان، ليس لأنها ستفوز دائمًا، بل لأن السؤال «هل هو إشارة حقيقية؟» لم يُحل بعد تمامًا.

نموذج التكرار المتوازي لـ Replit Agent 4.
هذه واحدة من أولى المحاولات الجادة لـ«تشغيل عدة وكلاء بشكل متوازي»، دون أن تتعثر بسبب الحالة المشتركة. إذا نجح بعد التوسع، قد يتغير النمط الافتراضي للمنسق-الوكيل الفرعي.

نضج التسعير المبني على النتائج.
مسار دخل Sierra و Harvey، أثبت فعاليته في مجالات ضيقة ومتخصصة. السؤال هو: هل يمكن تعميمه على مجالات أخرى، أم يظل محدودًا بالمجالات الرأسية فقط؟

القدرات كطبقة تغليف للمهارات.
زيادة ملفات AGENTS.md و directories الخاصة بالمهارات على GitHub، تشير إلى ظهور طريقة جديدة لتغليف قدرات الوكيل. هل ستصبح مثل معايير MCP، وتوحد القدرات؟ هذا سؤال مفتوح.

مراجعة جودة Claude Code في أبريل 2026، وتحليلها.
أصدر أحد الرواد في المجال نسخة تسببت في تراجع الأداء بنسبة 47%، واكتشف المستخدمون المشكلة، ثم قاموا بالتحليل الداخلي. هذا يوضح أن حتى في الشركات الرائدة، ممارسات تقييم الوكيل في الإنتاج لا تزال غير ناضجة. إذا أدى ذلك إلى استثمار أكبر في التقييم عبر الإنترنت، فهذه خطوة صحية.

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

استمرار تقليل فجوة قدرات النماذج المفتوحة المصدر.
DeepSeek-V3.2 يدعم التفكير في استخدام الأدوات، وQwen 3.6، والنظام البيئي الأوسع للنماذج المفتوحة، كلها تستحق المتابعة. تكاليف المهام الضيقة تتغير، والهيمنة الحالية للنماذج المغلقة لن تدوم للأبد.

كل واحدة من هذه الأمور يمكن أن ترتبط بسؤال واضح: «بعد ستة أشهر، ماذا أحتاج أن أراه لأصدق أنها مهمة حقًا؟» هذا هو الاختبار. تتبع الإجابة، وليس الإعلانات.

الرهانات غير التقليدية

كل إطار لم تعتمد عليه، هو فرصة