أراهن بشركتي على الوكلاء الاستباقيين
Explore with AI
يستطيع الوكلاء فعل كل ما تطلبه منهم تقريبًا، وهذه هي المشكلة بالضبط: لا يزال عليك أن تطلب.
أسمع الناس باستمرار يصفون الوكلاء بأنهم “زملاء رقميون”. هذا التصور خاطئ. الزميل الذي يجلس صامتًا حتى تسلّمه مهمة محددة النطاق بإتقان، فينجزها، ثم يعود إلى الانتظار، ليس زميلًا. كل وكيل استخدمته في حياتك يعمل بهذه الطريقة بالضبط. صارت النماذج أذكى، والأطر أفضل، والجولات أطول، لكن الواجهة لم تتغيّر أبدًا: أنت تحضر العمل، والوكيل يحضر الجهد.
ومعظم الناس لم يلاحظوا، لأن صندوق الطلب صار بهدوء هو ما يكون الذكاء الاصطناعي في أذهاننا.
كل واجهة لا تزال صندوق طلب
صندوق الإدخال هو ما بدأت به هذه الحقبة كلها. وضعت ChatGPT صندوقًا فوق نموذج وصارت المنتج الأسرع نموًا في التاريخ، وقلّدناها جميعًا. وكل منتج ذكاء اصطناعي منذ ذلك الحين تنويع على التفاعل نفسه: يكتب الإنسان، وتجيب الآلة، وتنتظر الآلة.
كان Claude Code التطور التالي. انتقل الوكيل إلى طرفيتك، وأخذ ملفاتك وصدفتك وتاريخ git لديك، وبدأ يؤدي عملًا حقيقيًا بدلًا من الحديث عنه. غيّر ذلك ما يستطيع الوكلاء فعله، لكن ليس كيف يبدؤون: تكتب، فيعمل، ثم يتوقف، وينتظر أن تكتب مجددًا.
ثم انتقل الوكلاء إلى السحابة. Codex وDevin وClaude Code على الويب. يعملون لساعات بدلًا من دقائق، ويشغّلون وكلاء فرعيين لتوزيع العمل بالتوازي، ولا يموتون عندما تغلق حاسوبك المحمول. تسلّم أحدهم مهمة قبل الغداء وتعود إلى طلب pull request.
بل إن الطلب لم يعد شيئًا خاصًا بلوحة المفاتيح. يمكن أن يطلق تنبيه أو webhook وكلاء الخلفية، وتقدم معظم منصات الوكلاء الآن أتمتة: عندما يقع هذا الحدث، أو يدق هذا cron، شغّل وكيلًا بهذه التعليمات.
- When
- a Sentry alert fires
- Do
- investigate, open an incident if it's real
- Then
- post the findings to #incidents
لكن ما الأتمتة؟ هي طلب كتبته مسبقًا. توقعت نمط الفشل، واختررت الحدث، ودوّنت ما يجب فعله بشأنه. يطلق المشغّل الوكيل، لكن الحكم داخله حكمك، مجمّدًا في لحظة الإعداد. تلتقط الأتمتة بالضبط ما توقعته، ولا شيء غيره.
أنت المجدوِل
انزع الأدوات وستجد أن تقسيم العمل لم يتحرك في ثلاث سنوات. الوكيل يؤدي العمل. وتقرير ما هو العمل يبقى وظيفتك.
أنت تقرأ لوحات المعلومات، وتستمع إلى المستخدمين، وتستنتج ما يهم، وتضغط كل ما تعلمته في طلب، إما مباشرة على لوحة المفاتيح أو مسبقًا في مشغّل. ينفّذ الوكيل ببراعة، لكن كل قطعة حكم في النظام تنبع منك.
التطور التالي: وكلاء يجدون العمل
أراهن أن التطور التالي هو وكلاء يستنتجون العمل الذي يجب إنجازه. لا طلب، ولا مشغّل تعدّه، ولا تعليمات مكتوبة مسبقًا. تربط حزمتك التقنية، ويجد الوكيل العمل بنفسه: يراقب الإشارات نفسها التي تراقبها، ويلاحظ ما هو خاطئ، ويقرر إن كان يهم، ويبدأ العمل عليه بشكل مستقل.
هذا سهل القول، وصعب البناء بقسوة، لأن الاستباقية ثلاث مشكلات متراكبة فوق بعضها، وتجاوز أي واحدة منها يمنحك شيئًا أسوأ من الوكيل خلف صندوق الإدخال.
السياق. بداهةً، يحتاج الوكيل إلى نموذج حي للعالم الذي يعمل فيه، لا لقطة لصقتها في نافذة السياق لحظة الطلب. الوكيل التفاعلي بسياق سيئ يمنحك جوابًا سيئًا. والوكيل الاستباقي بسياق سيئ يحذف قاعدة بيانات الإنتاج لديك لأنه ظنها بيئة التجريب.
الحكم. هذا ما يصعّب عليّ الأمر أكثر من أي شيء. في أي لحظة، آلاف الأشياء في نظام الإنتاج خارجة قليلًا عن المألوف. الوكيل الذي يرصدها كلها آلة ضجيج، وآلات الضجيج تُسكَت، والوكلاء المُسكَتون وكلاء موتى. القيمة الكاملة للاستباقية تعيش في الفجوة بين “شيء تغيّر” و”شيء يهم”:
[
{
"signal": "memory up 3% on checkout-edge",
"verdict": "no anomaly",
"reasoning": "within the seasonal range for this hour on this worker"
},
{
"signal": "new error pattern, 2 minutes after deploy 9f3c2a1",
"verdict": "incident",
"reasoning": "error class never seen on this worker, tightly correlated with a deploy"
}
]
التصرف. الملاحظة من دون تصرف مجرد تنبيه أذكى، والتنبيهات هي الشيء الذي أحاول قتله. على الوكيل أن ينهي العمل، داخل حدود تجعل الاستقلالية آمنة: إجراءات قابلة للعكس، وإثباتات لكل شيء، وبوابة صارمة قبل أي شيء لا رجعة فيه.
لا تتضمن أي من هذه الثلاث أن يقرر الوكيل كيف يبدو الجيد. يقرر ما هو خاطئ، وإن كان يهم، وما يجب فعله بشأنه، وهذه القائمة كلها، لأن في الإنتاج لا أحد مضطر إلى تعريف الجيد: الأخطاء عند الصفر، وزمن الاستجابة عند خط الأساس، والطوابير مفرَّغة، والشهادات صالحة. تأتي الحالة المرغوبة مع المجال.
ما يعني أن التحول الحقيقي ليس من “أنت تطلب” إلى “الوكيل يطلب من نفسه”. بل من العمليات الأمرية إلى العمليات التصريحية. الأتمتة أمرية: تعدّد أنماط الفشل مسبقًا وتكتب استجابة لكل منها. والوكيل الاستباقي حلقة توفيق: يقابل النظام الذي لديك بالنظام الذي ينبغي أن يكون لديك، ويعمل على سد الفجوة. فعل Kubernetes ذلك للبنية التحتية قبل عقد، تكتب ثلاث نسخ متماثلة ويفعل المتحكم كل ما يلزم لإبقاء ثلاث نسخ حية. ولم يفعله أحد لتشغيل البرمجيات نفسها. وهنا لا يوجد حتى YAML تكتبه، لأن الحالة المرغوبة معروفة أصلًا. يعمل من دون إعداد.
بدأت بالعمليات
اطلب من وكيل استباقي أن يختار خارطة طريق منتجك وستحصل على متدرب صاحب آراء، لأن اتجاه المنتج مسألة ذوق. أما الإنتاج فلا. هو المجال الوحيد الذي تكون فيه المشكلات الثلاث كلها قابلة للحل اليوم.
يعلن العمل عن نفسه: ترتفع معدلات الأخطاء، وتنحرف عملية نشر، وتنتهي شهادة، ويتراكم طابور. العمل جالس أصلًا في بيانات القياس، ينتظر أن يلاحظه أحد. وعلى خلاف المجالات التي يقودها الذوق، توجد حقيقة أرضية: إما أن معدل الأخطاء قفز أو لم يقفز، وإما أن التراجع استعاد خط الأساس أو لم يستعده، فيقيّم النظام نفسه حكم الوكيل، باستمرار، من دون مجال للانطباعات.
وقبل كل شيء، نحن نوظّف بشرًا لهذه الوظيفة أصلًا. نسميها المناوبة: شخص ينام بجانب هاتف، ينتظر أن تقول آلة إن آلة أخرى غير راضية. قضيت سنوات في قابلية الملاحظة، وأسست شركة لقابلية الملاحظة واستحوذت عليها Cloudflare، وكتبت بيانًا كاملًا عن هيكلة بيانات القياس بحيث يكون الجواب على بعد استعلام واحد. وأطروحته هي سبب وجود هذه الشركة: لا ينبغي لأحد أن يكون في المناوبة عام 2026.
لأن الحقيقة غير المريحة عن العقد الأخير من قابلية الملاحظة هي أننا جعلنا الأنظمة أسهل للبشر في الاستجواب في الثالثة فجرًا، ثم أعلنّا النصر بينما لا يزال البشر هم من يُوقَظون. صارت لوحات المعلومات أجمل وبقي جهاز الاستدعاء على المنضدة بجانب السرير. قابلية الملاحظة من دون تصرف مجرد تخزين مكلف.
كيف يبدو الأمر
هذا ما تفعله Polylane. إليك يوم ثلاثاء ملموسًا:
لم يُعدّ أحد فحصًا لنمط الفشل هذا. لا قواعد تكتبها ولا عتبات تضبطها: يقيّم الوكلاء كل مورد مربوط على إيقاع مستمر، وتصبح لوحات معلوماتك واستعلاماتك المحفوظة قائمة تحققهم. والحكم هو حيث أكون أشد صرامة. الحكم الافتراضي هو لا شذوذ، لأن تفويت مشكلة حدّية أفضل بكثير من إيقاظ أحد بسبب ضجيج. “قد تُدخل عملية النشر خللًا” صحيحة عن كل عملية نشر وليست أبدًا سببًا لاستدعاء أحد.
وعندما يكون شيء حقيقيًا، يشغّل التحقيق عدة فرضيات متنافسة بالتوازي، ووظيفة كل وكيل دحض فرضيته لا تأكيدها، فلا يتنكر الارتباط أبدًا في هيئة سبب. وعندما يكون السبب الجذري المؤكد تغييرًا في الكود، يصل الإصلاح بصفته طلب pull request مع التحقيق مرفقًا:
Opened by Polylane · gated on review and CI
استباقي لا يعني من دون إشراف
الاستقلالية في الملاحظة، والفرز، والتنقيب في الثالثة فجرًا، والتخفيف. وكل ما يستعيد حالة معروفة بسلامتها يفعله الوكيل بنفسه: التراجع عن عملية النشر السيئة، وإعادة إطفاء العلامة. تلك الإجراءات قابلة للعكس بحكم بنائها، وهي التي تُسكت جهاز الاستدعاء فعلًا. وما يبقى خلف البوابة هو كل ما ينشئ حالة جديدة: يُطلق تغيير الكود عبر مراجعتك وCI الخاص بك، لا من حولهما أبدًا.
الخط ليس بين الإنسان والوكيل. بل بين القابل للعكس وغير القابل. ولهذا لست في المناوبة سرًا: أنهى التراجع الحادثة في 02:33، ست ساعات قبل أن تدمج طلب pull request. لم يكن طلب PR أبدًا ما أوقف النزيف. هو ما يمنع تكراره، وهذا يمكن أن ينتظر القهوة.
والبوابة لك أن تفوّضها. تقرأ وكلاء مراجعة الكود أصلًا كل طلب pull request في مستودعك. هناك عالم، ليس بعيدًا عن هذا، يقرأ فيه وكيل المراجعة لديك الإصلاح في 02:41، ويفحصه مقابل التحقيق، ويوافق عليه، وينشر CI الخاص بك إلى الإنتاج قبل أن تستيقظ. لا شيء في الحلقة يتغيّر سوى من يملك زر الموافقة. وهنا ينتهي الأمر: برمجيات تصلح نفسها، وأنت تكتب السياسة بدلًا من النقر على الدمج.
لاحظ ما هو مفقود من تلك الحلقة:
كان صندوق الطلب طريقة رائعة لنتعلم الثقة بهذه الأنظمة، وهو طريقة رديئة لتشغيل الإنتاج. رأى الوكيل كل عملية نشر، وكل سطر سجل، وكل مقياس عبر كل خدمة في وقت واحد. وإبقاؤه خلف طلب يعني أن أفضل عضو مطّلع في فريقك لا يتكلم إلا عندما يُكلَّم.
لا ينبغي لأحد أن يكون في المناوبة عام 2026.