من يشغل المشغلين؟
وكلاء الذكاء الاصطناعي بدأوا يتسببون في الحوادث التي بنوا أصلا لحلها. وهذه طريقة تشغيل الأسطول قبل أن يشغلك هو.
تسع ثوان
في 25 أبريل 2026، حذف وكيل برمجة يعمل بالذكاء الاصطناعي قاعدة بيانات الإنتاج لدى شركة كاملة، ومعها كل النسخ الاحتياطية، في تسع ثوان تقريبا.
الشركة هي PocketOS، وتبني برمجيات لشركات تأجير السيارات. والوكيل هو Cursor يشغل Claude Opus 4.6. كان يعمل داخل بيئة التجهيز، فاصطدم بعدم تطابق في بيانات الاعتماد، فقرر أن الحل هو حذف وحدة تخزين في Railway. وللوصول إلى ذلك بحث عن توكن لواجهة برمجية، فوجد واحدا في ملف لا علاقة له بالمهمة، واستخدمه لإطلاق أمر curl حذف به وحدة تخزين الإنتاج بدلا منها. لم تقف في طريقه أي خطوة تأكيد. وذهبت النسخ الاحتياطية معها، لأن Railway يحفظ النسخ الاحتياطية على مستوى وحدة التخزين داخل الوحدة نفسها. وقضى الموظفون عطلة الأسبوع في إعادة بناء حجوزات العملاء من سجلات مدفوعات Stripe ومن سجلات البريد.
نقلت الخبر The Register وFast Company وجهات أخرى.
خلاصة المهندس نفسه بعدها: "خالفت كل مبدأ أعطي لي".
أعد قراءة هذا السطر، فهو المشكلة كلها في ست كلمات. الوكيل كان يعرف القواعد. وقيل له ألا يلمس الإنتاج. ثم حذف الإنتاج على أي حال، بسرعة وبثقة، وببيانات اعتماد ما كان ينبغي أن تصل يده إليها أصلا. لم تكن هذه حالة نموذج غبي، بل نظام لا يوجد فيه أي حد فاصل بين نية الوكيل والفعل المدمر.
PocketOS شركة صغيرة، ولهذا صنعت عنوانا جيدا. لكن النمط ليس صغيرا. في يوليو 2025، حذف وكيل ذكاء اصطناعي داخل Replit قاعدة بيانات حية أثناء تجميد معلن للشيفرة، فأتلف 1,206 سجلات قيل له صراحة أن يتركها. وبين يناير ومايو 2026، وثقت إحدى شركات قابلية الرصد 73 حادثة إنتاج منفصلة سببها وكلاء منشورون. إن كنت تشغل وكلاء في الإنتاج ولم تمر بحادثة وشيكة خاصة بك بعد، فأنت مبكر لا آمن.
لماذا يتكرر هذا
الجزء المزعج أن أيا من هذه الحالات لم يكن فشلا غريبا. كانت أتمتة عادية تتصرف بناء على رؤية ناقصة للعالم، وهذا تحديدا ما تفعله النماذج اللغوية الكبيرة طوال الوقت.
وتظهر فجوتان بنيويتان في كل مرة. الأولى بيانات الاعتماد. وكيل PocketOS وصل إلى توكن إنتاج من مهمة تجري في بيئة التجهيز. وفي منصة سوق أساعد في تشغيلها، كانت نسخة مبكرة من أدوات الوكلاء لدينا ترى من البيئة أكثر بكثير مما تحتاجه أي مهمة منفردة، لسبب ممل: توصيل حساب خدمة واحد واسع الصلاحيات أسهل من تحديد نطاق ضيق لكل مهمة على حدة. وهذا الاختصار سليم إلى أن يرتجل الوكيل، والارتجال هو عمله.
والفجوة الثانية هي حد الموافقة. معظم الفرق تضع التغييرات الخطرة خلف مراجعة بشرية أصلا. ما يفوتها أن البوابة بنيت للبشر. فحين ينفذ شخص أمرا مدمرا، يوقع عليه مهندس ثان. وحين ينفذ وكيل الأمر نفسه عبر واجهة برمجية، لا تنطلق المراجعة أصلا، لأن الضمانة كتبت حول سير عمل بشري خرج منه الوكيل بهدوء. الضابط الذي كان سيمسك بإنسان غير موجود أمام الشيء الذي يؤدي العمل الآن.
وفي هذه الأثناء تغيرت اللغة تحت أقدام الجميع. خلال 2025 كانت العبارة السائدة "الاستجابة للحوادث بمساعدة الذكاء الاصطناعي"، أي إنسان خلف المقود ومساعد ذكي بجانبه. ومع منتصف 2026 صارت العبارة العملية في معظم فرق العمليات المؤسسية "الاستجابة الذاتية للحوادث"، حيث يفرز الوكيل الحادثة ويقترح إصلاحا، ولمجموعة متنامية من الأعطال المعروفة يطبقه دون انتظار. هذا تقدم حقيقي في جانب المعالجة. وهو يعني أيضا أن الصنف نفسه من البرمجيات الذي يحل الحوادث صار قادرا تماما على إشعالها.
الانقلاب الذي لم يخطط له أحد
لخمسة عشر عاما كانت قصة الموثوقية ثابتة. بنينا المراقبة لنرصد أنظمتنا، ثم بنينا AIOps ليراقب المراقبة، وظل الشيء الخاضع للرصد بنية تحتية دائما. خوادم وطوابير وقواعد بيانات وعمليات نشر. أشياء متوقعة تفشل بطرق يمكن وصفها.
والوكلاء يكسرون هذا الترتيب بطريقة محددة: هم برمجيات، فينتمون إلى النظام المرصود، لكنهم ينفذون أفعالا أيضا، فيتصرفون كمشغلين. وأسطول منهم هو جماعة من العاملين شبه المستقلين، لديهم وصول إلى الإنتاج، وسلوك غير حتمي، وبلا جدول مناوبات. فتنتهي إلى الحاجة إلى تشغيل المشغلين.
هذا هو التحول الذي تدور حوله هذه المقالة. التخصص الناضج لإبقاء البنية التحتية حية هو هندسة موثوقية المواقع (SRE)، وأحدث أشكاله هو هندسة الموثوقية بالوكلاء، حيث يدير وكيل حلقة الموثوقية بدلا عنك. وحجتي هنا أن عليك الآن توجيه الحلقة نفسها إلى وكلائك أنت، وأن أحدا تقريبا لم ينه بناء النصف الذي يقوم بذلك. أدوات مراقبة البنية التحتية شحنت بالفعل. أما أدوات مراقبة المراقبين فما زالت في معظمها نمط تصميم على الورق.
ملاحظة عن الأرقام في هذه المقالة. كل مزود في هذا المجال يعلن نسبة انخفاض في متوسط زمن الإصلاح (MTTR)، وقد استبعدت هذه الأرقام كلها تقريبا. لا أحد منهم يفصح عن منهجية ولا خط أساس ولا حجم عينة، فهي تسويق لا دليل. وحيثما أذكر رقما فهو إما تقرير حادثة من مصدر أول أو استطلاع منسوب بوضوح، وأنبه إلى ما يحتاج منها إلى تحفظ. وإذا بدا لك أن إحصائية هنا تحمل ثقل الحجة، فستجد لها رابطا.
الحلقة، مستعارة من SRE
الخبر الجيد أنك لست مضطرا لاختراع نموذج الاستجابة. مزودو هندسة الموثوقية بالوكلاء تقاربوا على الحلقة المغلقة نفسها، وهي تنطبق على الوكلاء بشكل نظيف. خمس مراحل:
| المرحلة | على البنية التحتية | على أسطول الوكلاء |
|---|---|---|
| الرصد | ينطلق تنبيه على معدل الأخطاء أو زمن الاستجابة. | ينحرف وكيل، أو يدور في حلقة، أو يستهلك التوكنات، أو يبدأ في الإخفاق في فحوص مخرجاته. |
| الفرز | اقرأ التنبيه واسحب المقاييس المتصلة به. | اسحب جلسات الوكيل الأخيرة، واستدعاءات أدواته، ومنحنى كلفته. |
| الربط | اربط الأعراض بعملية نشر أو باعتمادية. | اربط السلوك الشاذ بتغيير في التوجيه النصي (Prompt)، أو تبديل نموذج، أو رد سيئ من أداة. |
| المعالجة | التراجع، أو التوسيع، أو تنفيذ دليل تشغيل معروف. | إعادة التوجيه إلى نموذج آخر، أو التراجع عن نسخة الوكيل، أو إيقافه. |
| التصعيد | استدع إنسانا حين تنخفض الثقة. | سلم الأمر لإنسان حين يكون الإصلاح جديدا أو نطاق الأثر واسعا. |
ويستحق أن ترى بوضوح إلى أي مدى يعمل هذا فعلا على جانب البنية التحتية، لأنه يضبط سقفا واقعيا. أطلقت Datadog أداة Bits AI SRE للتوفر العام في 2 ديسمبر 2025، ووصفها الخاص أنها تصل إلى استنتاج السبب الجذري "قبل أن يسجل المناوبون دخولهم أصلا". ونشرت AWS شرحا عمليا لوكيل DevOps لديها وهو يعالج تنبيها حيا: ينطلق تنبيه CloudWatch على ارتفاع أخطاء 5xx، فيختبر الوكيل فرضياته بنفسه، ويحدد أن السبب تقييد الكتابة في DynamoDB ناتج عن عملية نشر حديثة، وينشر تحليلا كاملا للسبب الجذري خلال أربع دقائق دون أي تدخل بشري.
ثم يتوقف. يوصي بالتراجع أو بتغيير السعة عند الطلب، وينتظر أن يختار إنسان. وهذا الحد بالذات هو الجزء المثير للاهتمام. أكثر وكيل متقدم شحن في هذه الفئة ينفذ المراحل الثلاث الأولى ذاتيا، ويرفض عن قصد تنفيذ الرابعة بلا إنسان. احتفظ بهذه الفكرة، فهي التصميم الذي يمنع الحلقة من الانفلات عليك.
الحلقة مطبقة على وكيل
وهذه هي الحلقة نفسها تعمل ضد وكيل مضطرب بدل قاعدة بيانات. أحد وكلائك يبدأ في الدوران على استدعاء أداة فاشل، فيلتقطه مستوى التحكم، ويعيد تشغيل الجلسة ليجد السبب، ويفحص ثقته الخاصة، ثم يصعد الأمر إلى إنسان بدل أن يتصرف لأن الإصلاح غامض. بوابة الثقة تلك هي التصميم كله: ثقة عالية ونمط معروف، فتغلق الحلقة نفسها بنفسها؛ وأي شيء جديد، فتتوقف وتستدعيك. والبنية المتحركة بعد قليل تعرض الحادثة نفسها وهي تتدفق عبر الطبقات.
لا شيء من هذا خيال علمي. كل مرحلة هنا قدرة موجودة في أدوات قابلية الرصد المشحونة اليوم. النادر هو توصيلها في حلقة مسموح لها بالتصرف على وكلائك، وفي منتصفها بوابة تقرر متى يحق لها ذلك.
الجزء الصعب هو الرصد
كل مرحلة أعلاه تفترض أنك لاحظت المشكلة. ومع الوكلاء، هذه المرحلة الأولى أصعب بكثير مما تبدو، وأفضل دليل عليها يأتي من شركة تبني النماذج نفسها.
بين مطلع أغسطس ومطلع سبتمبر 2025، عاشت Anthropic ثلاثة أعطال متداخلة في بنيتها التحتية أضعفت مخرجات Claude بصمت: خطأ توجيه يرسل الطلبات إلى خوادم خاطئة، وإعداد خاطئ يحقن محارف شاردة داخل الردود، وعطل في المترجم (compiler) أفسد اختيار التوكنات. المستخدمون لاحظوا. والاعتراف اللافت في تقرير ما بعد العطل الخاص بهم: "الاختبارات التقييمية التي أجريناها ببساطة لم تلتقط التدهور الذي كان المستخدمون يبلغون عنه، ويعود ذلك جزئيا إلى أن Claude غالبا ما يتعافى جيدا من الأخطاء المعزولة". اختباراتهم المعيارية كانت تمر بنجاح بينما الجودة الحقيقية تنزلق، لأن العطل كان متقطعا والنظام كان يعوض الأخطاء المفردة فيخفي أثرها.
ثم ساء الأمر أكثر. ضوابط الخصوصية لديهم، وهي محقة، تمنع المهندسين من قراءة محادثات المستخدمين بحرية، ما يعني أنهم لم يستطيعوا بسهولة استخراج التفاعلات المعطوبة بعينها لإعادة إنتاج العطل. الشيء الذي تحتاجه أكثر من غيره أثناء حادثة وكيل، أي الجلسة نفسها، هو الشيء الذي تجعل قواعد حماية البيانات لديك الوصول إليه أصعب ما يكون. ولأن الأعطال الثلاثة تداخلت، فقد "أنتج كل منها أعراضا مختلفة على منصات مختلفة وبمعدلات مختلفة"، فتحول الربط إلى تخمين.
توقف عند هذا، فهذه شركة بأدوات من الطراز العالمي تصف بالضبط مشكلة الرصد التي ستواجهها مع وكلائك أنت، بحجم أصغر فقط. تدهور صامت وغير حتمي تخطئه الفحوص المعيارية. وإعادة تشغيل قد لا يسمح لك بقراءتها. وإشارات مختلطة من أسباب متداخلة. وعلاجهم هو العلاج الصحيح ويستحق النسخ: اختبارات تقييمية أكثر حساسية تفرق بين وكيل سليم ووكيل معطوب بشكل خفي، ومراقبة جودة مستمرة في الإنتاج بدل مجموعة اختبارات تعمل قبل النشر ثم تصمت.
البنية، طبقة طبقة
اجمع الرصد والحلقة والحد الفاصل معا فيظهر لك شكل واضح. أربع طبقات، والوكلاء يجلسون داخلها لا فوقها.
مستوى الإشارة هو الأساس، وهو الطبقة التي تتخطاها الفرق. لا يمكنك تشغيل ما لا تراه، والقياسات المفيدة للوكيل ليست المعالج والذاكرة. إنها تتبع كل قرار: أي نموذج أجاب، وأي أدوات استدعى وبأي وسائط، وماذا أعادت كل أداة، وكم توكنا استهلك، وكيف سجلت مخرجاته في فحوص الجودة لديك. سجل واحد قابل لإعادة التشغيل لكل قرار. وبدون هذا، تصبح كل طبقة تالية مجرد تخمين.
طبقة الاستدلال تنفذ المراحل الثلاث الأولى من الحلقة وتجيب عن سؤال واحد: هل هذا الوكيل معطوب فعلا، أم يمر بحالة سيئة عابرة. وهنا تنطبق عبرة Anthropic. العتبات الرخيصة تمسك بالأعطال الصاخبة، كحلقة جامحة أو قفزة في الكلفة، لكن انحراف الجودة الخفي يحتاج إلى اختبارات تقييمية حساسة، والانحراف الخفي هو ما يأكل ثقة المستخدمين قبل أن يفتح أحد تذكرة.
طبقة الفعل صغيرة ومحددة عن قصد. أمام الوكيل قائمة قصيرة من المعالجات الحقيقية: إرسال حركته إلى نموذج آخر، أو التراجع به إلى آخر نسخة معروفة السلامة، أو إيقافه وتحويل عمله إلى طابور بشري. ثلاثة أفعال، كل منها قابل للعكس. وقابلية العكس هي قيد التصميم الأهم هنا، لأن الطبقة التالية هي التي تقرر متى تسحب هذه الروافع دون أن تستأذن.
مستوى التحكم يغلف كل ما سبق، وهو الموضع الذي كان سيمنع فشل PocketOS. والتوافق الناشئ، كما يصفه المستثمرون وفرق الأمن على السواء، يتلخص في أربع قواعد. كل وكيل يعمل بهوية خاصة به بأقل امتياز ممكن، ولا يستعير أبدا بيانات اعتماد إنسان. والسياسة شيفرة تفرض في وقت التشغيل، لا صفحة في ويكي. والأدوات عقود: موقعة، ومحدودة المعدل، ومقيدة بموافقة، لا روابط مفتوحة يوجهها الوكيل حيث شاء. وكل استدعاء قابل للتتبع ولإعادة التشغيل ومحسوب الكلفة، ومنسوب إلى سير العمل الذي سببه. وكيل PocketOS خالف الأولى والثالثة في أمر واحد. ومستوى تحكم يفرضهما كان سيعطيه توكنا لا يرى الإنتاج، وأداة حذف ترفض العمل بلا موافقة موقعة.
الطبقات الأربع كشيفرة قابلة للتشغيل. شحنت تطبيقا مرجعيا مصغرا بلا اعتماديات لهذه الطبقات بالضبط، أي مستوى الإشارة وبوابة الثقة ومفتاح الإيقاف، كمكتبة مفتوحة المصدر: guardplane، وهي متاحة أيضا على npm. ليست إطار عمل، بل الهيكل الذي تلفه حول أي وكيل تشغله أصلا.
قاطع الدارة
والآن الجزء الذي يخطئ فيه الجميع في الاتجاه المعاكس. حالما تصبح المعالجة التلقائية ممكنة، يأتي الإغراء بترك الحلقة تغلق على كل شيء. وهكذا تحول حادثة صغيرة إلى حادثة كبيرة.
قدمت Cloudflare للإنترنت درسا نظيفا في 18 نوفمبر 2025. تغيير داخلي في الصلاحيات جعل استعلاما روتينيا يعيد صفوفا مكررة، فتضاعف حجم ملف إعداد يغذي نظام إدارة البوتات لديهم. تجاوز الملف حدا مثبتا في الشيفرة عند 200 خاصية، فانهار الوسيط الذي يعالجه صراحة: thread fl2_worker_thread panicked: called Result::unwrap() on an Err value. واستغرق التعافي الكامل نحو ست ساعات، عبر شريحة كبيرة من الويب. لم يكن هذا وكيل ذكاء اصطناعي. كانت أتمتة تتصرف بناء على حالة داخلية خاطئة، وهو بنيويا الشيء نفسه الذي يفعله الوكيل حين يرتجل فوق افتراض خاطئ.
وانظر إلى ما التزمت به Cloudflare بعدها، لأنه أشبه بمواصفة لتشغيل الوكلاء. مفاتيح إيقاف عامة أكثر، بحيث تعطل خاصية سيئة على مستوى الشبكة كلها دون نشر. ثم هذا السطر الذي كنت سأؤطره وأعلقه فوق أي منصة وكلاء: قالوا إنهم سيشددون استقبال ملفات الإعداد التي تولدها أنظمتهم داخليا "بالطريقة نفسها التي نعامل بها المدخلات القادمة من المستخدمين". عامل ما تنتجه أتمتتك أنت كمدخل غير موثوق. خطة الوكيل مدخل مولد داخليا. تحقق منها كأنها جاءت من غريب.
ونمط الفشل الذي يستحق الخوف ليس وكيلا لا يفعل شيئا. بل وكيل يعالج بثقة فيصل بك إلى حالة أسوأ. مقالة واسعة الانتشار كتبها ممارس في SRE في مايو 2026 أعطت المثال النموذجي: وكيل معالجة يرى ارتفاعا في زمن الاستجابة فيعيد تشغيل عنقود خدمة، غير أن مجمع الاتصالات المشترك عند 87 بالمئة أصلا، فتطلق إعادة التشغيل موجة طلبات متزامنة (thundering herd) تسقط الخدمة التي كان الوكيل يحاول إنقاذها. وهذا ليس تنظيرا في الهواء. انقطاع Google Cloud الحقيقي في يونيو 2025 كان له الشكل نفسه، حيث ضربت عمليات إعادة تشغيل آلية جماعية خلفية كانت تتعافى، بلا أي مهل تصاعدية.
والجواب هو بوابة الثقة الواردة في الشرح أعلاه، منفذة كقاطع الدارة حقيقي. تصف Resolve AI نموذج الثقة الذي تستقر عليه الفئة كلها، ويستحق أن يقال بوضوح: ابدأ كل وكيل في وضع استشاري تحتاج إصلاحاته إلى موافقة بشرية، ووسع استقلاليته فقط في الأعطال منخفضة المخاطر المفهومة جيدا التي بنى فيها سجلا، وأبق البشر داخل الحلقة بحزم في كل ما هو جديد أو عالي المخاطر. الاستقلالية امتياز يكسبه الوكيل لكل صنف عطل على حدة، لا مفتاح ترفعه مرة واحدة. وقاطع يسلم الحالات الغامضة إلى إنسان ليس ضعفا في التصميم. بل هو ما يجعل التصميم آمنا بما يكفي لتشغيله أصلا.
ما كنت سأبنيه أولا
لست بحاجة إلى المنصة الكاملة بطبقاتها الأربع لتبدأ، ولا ينبغي أن تحاول بناءها دفعة واحدة. لو كنت أضيف هذا إلى نظام اليوم، وقد دافعت عن هذا الترتيب بعينه على منصات أعمل عليها، لمشيت بهذا التسلسل، لأن كل خطوة مفيدة بمفردها وكل واحدة منها تكسب الحق في التي بعدها.
- امنح كل وكيل هوية خاصة به وبيانات اعتماد محدودة النطاق. هذا أعلى تغيير أثرا على الإطلاق، وهو عمل بنية تحتية بحت لا يحتاج أي ذكاء. الوكيل الذي لا يستطيع الوصول إلى الإنتاج من مهمة في بيئة التجهيز لا يستطيع حذفه. افعل هذا أولا حتى لو لم تفعل شيئا آخر.
- سجل سجلا واحدا قابلا لإعادة التشغيل لكل قرار. النموذج، والأدوات، والوسائط، والمخرجات، والتوكنات، ودرجة الجودة. أنت هنا تبني مستوى الإشارة، وستحتاجه أكثر ما تحتاجه يوم تقع حادثة ولا يكون لديك أي تتبع.
- أضف مفتاح إيقاف قبل أن تضيف الاستقلالية. ضابط واحد يوقف وكيلا أو صنفا كاملا من الوكلاء على مستوى الشبكة، دون نشر. عبرة Cloudflare: ابن مفتاح الإيقاف قبل أن تحتاجه، لا أثناء الانقطاع.
- اربط الرصد بالتنبيهات، وأبق المعالجة يدوية. دع الحلقة ترصد وتفرز وتوصي، عند النقطة نفسها التي يتوقف عندها وكيل AWS. تحصل على معظم القيمة وبلا أي خطر انفلات، بينما تتعلم ما الذي يخطئ فيه وكلاؤك فعلا.
- عندها فقط، عالج تلقائيا الأعطال التي تفهمها تمام الفهم. اختر عطلا أو عطلين مملين وقابلين للعكس ومتكررين، رأيت الحلقة تعالجهما بشكل صحيح مئة مرة، ودعها تغلق عليهما وحدهما. وكل ما عداهما يظل يصعد إليك.
ولاحظ أن الخطوات الثلاث الأولى لا تحتوي على أي ذكاء اصطناعي إطلاقا. أصعب أجزاء تشغيل أسطول وكلاء وأكثرها قيمة هي هندسة أنظمة تقليدية: الهوية، والتدقيق، ومفتاح الإيقاف. والحلقة الذاتية الذكية هي آخر ما تبنيه لا أوله.
إلى أين يتجه هذا فعلا
السوق يتحرك في هذا الاتجاه بسرعة تكفي للثقة بالاتجاه حتى مع عدم الثقة بالأرقام. أفادت Futurum Research في مارس 2025 أن 89 بالمئة من مدراء تقنية المعلومات المستطلعين يعتبرون الذكاء الاصطناعي الوكيلي أولوية استراتيجية، لكنهم لم ينشروا أي منهجية خلف الرقم، فاعتبره مؤشر توجه لا قياسا. وتقدر إحدى بيوت التحليل سوق AIOps الأوسع بـ 2.67 مليار دولار في 2026 لتصل إلى 11.8 مليار بحلول 2034، ولا أقتبس سوى هذا التقدير لأن التقديرات المنافسة للسوق نفسها تجاوزت 300 مليار، وهذا وحده يخبرك أن الفئة أحدث من أن تقاس بأمانة. وقبل شهر فقط، شحنت New Relic أداة Autopilot، وهي وكيل SRE جاهز يفرز الحوادث ويقترح المعالجات. جانب العرض حقيقي ويتسارع.
ما لم يشحن بعد هو الجزء الصادق. تطبيق هذه الحلقة على الوكلاء أنفسهم، لا على البنية التحتية، ما زال في معظمه نمطا موصوفا ومجموعة خرائط طريق من المزودين، لا مجموعة عمليات نشر إنتاجية مثبتة تستطيع نسخها. وأقوى دليل على الفكرة هو، بشكل غريب، حالات الفشل: عمليات الحذف في PocketOS وإعادة التشغيل التي أشعلت قطيعا هادرا هي ما يحدث حين تشغل وكلاء بلا حلقة ترصدهم. الغياب نفسه هو الحجة.
وهذا موضع جيد إن كنت ممن يبنون. جانب البنية التحتية من هندسة الموثوقية بالوكلاء ميدان مزدحم بمزودين كبار وادعاءات أكبر. أما الجانب الذي يشغل الوكلاء أنفسهم فمفتوح على مصراعيه، وأولى قطعه أعمال غير براقة تعرف كيف تنجزها أصلا: حدد نطاق بيانات اعتماد، وسجل قرارا، وركب مفتاح إيقاف. ابدأ من هناك. الجزء الذاتي يمكن أن ينتظر حتى يستقر الجزء الممل، والفرق التي تتقن الجزء الممل هي التي ستظل واقفة حين تمر على وكلائها ليلة سيئة.
علمنا الآلات أن تدير العمليات.
وصار علينا الآن أن ندير الآلات.
مصادر أولية: حذف قاعدة بيانات PocketOS، وتقرير Anthropic عن ثلاثة أعطال متتالية، وتقرير انقطاع Cloudflare في 18 نوفمبر 2025، والشرح العملي لوكيل AWS DevOps، ونموذج مستوى تحكم الوكلاء بركائزه الأربع.