الوكلاء الفرعيون خطأ ببساطة

كان وكيل الإصلاح التلقائي في Polylane مبنيًا في الأصل كمسار عمل يضم عدة وكلاء فرعيين، كل واحد مسؤول عن مهمة واحدة:

• وكيل فرز يفرز آلاف التنبيهات والإشارات
• وكيل منسّق يدير الوكلاء الفرعيين
• ما يصل إلى خمسة عشر وكيلًا فرعيًا للتحقق من كل الفرضيات الممكنة للمشكلة
• ووكيل برمجة يقدّم في النهاية طلب pull request

يمكن أن تؤدي مشكلة مؤكدة إلى ما يصل إلى 18 وكيلًا ووكيلًا فرعيًا للتحقيق والإصلاح. أما اليوم، فينجز الوكيل نفس العمل وكيل واحد.

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

ما هي المشكلة؟

يفحص Polylane السجلات والمقاييس والتتبعات من كل مورد سحابي (دالة Lambda، عامل Cloudflare Worker، مشروع Vercel، وما إلى ذلك) على كل مزود متصل. لكل مورد، نخزّن خطوط أساس عبر آفاق زمنية متعددة، بحيث نتمكن من رصد الموسمية في البيانات. ثم نقيّم الحالة الراهنة للمورد السحابي ونقارنها بالبيانات التاريخية. تُسجَّل القيم التي تخرق خط الأساس كمشكلات.

يمكن أيضًا إنشاء المشكلات من خلال التنبيهات التي نتلقاها من حلول قابلية الملاحظة وتتبع الأخطاء.

كيف نحل المشكلات؟

لحل مشكلة، نحتاج إلى:

1. الفرز: جمع البيانات لتأكيد المشكلة أو رفضها.
2. التحقيق: تقييم فرضيات متعددة وتحديد السبب الجذري.
3. فتح طلب pull request أو التصعيد. إما كتابة طلب pull request لحل المشكلة، أو التصعيد إلى مهندس إذا لم يكن الإصلاح تغييرًا في الكود، أو كتابة تقرير يوضّح النتائج ثم التوقف.

تنتهي الغالبية العظمى من الجولات قبل الوصول إلى طلب pull request أو تصعيد، عندما يخلص Polylane إلى أن المشكلة إما إيجابية زائفة أو غير ضارة.

معمارية الوكلاء الفرعيين

كانت معماريتنا الأولية مبنية على عدة وكلاء فرعيين.

استخدمنا وكيلًا منسّقًا لتنسيق العمل بين وكلاء فرعيين متعددين. كانت الوكلاء الفرعيون يُنشَؤون للتحقق من الفرضيات، محاولين إثبات أو دحض كل فرضية بنقاط انطلاق مختلفة (على سبيل المثال البدء بالنظر إلى السجلات، أو البدء بقاعدة الكود، وما إلى ذلك).

كانت نتائج الوكلاء الفرعيين تُصوَّت عليها بحساب بسيط ثم تُلخَّص من قبل وكيل آخر قبل رفعها إلى الوكيل المنسّق.

كان حكم كل فرضية عبارة عن تصويت مرجّح بالثقة عبر جولاتها.

const CONFIDENCE_RANK = { definitive: 4, strong: 3, moderate: 2, weak: 1, speculative: 0 };

function aggregatePassVerdicts(passes: PassResult[]): Verdict {
  const weights: Record<string, number> = {};
  const counts: Record<string, number> = {};
  for (const p of passes) {
    weights[p.verdict] = (weights[p.verdict] ?? 0) + CONFIDENCE_RANK[p.confidence];
    counts[p.verdict] = (counts[p.verdict] ?? 0) + 1;
  }
  const totalWeight = Object.values(weights).reduce((a, b) => a + b, 0);
  const [winner, winnerWeight] = Object.entries(weights).sort((a, b) => b[1] - a[1])[0];

  const countMajority = counts[winner] > passes.length / 2;
  const weightMajority = winnerWeight > totalWeight / 2;
  if (!countMajority && !weightMajority) {
    return { verdict: "inconclusive", confidence: "weak", summary: `No consensus across ${passes.length} passes.` };
  }

  const majority = passes.filter((p) => p.verdict === winner);
  const confidence = majority.reduce((min, p) => (CONFIDENCE_RANK[p.confidence] < CONFIDENCE_RANK[min] ? p.confidence : min), majority[0].confidence);
  const lead = majority.reduce((best, p) => (CONFIDENCE_RANK[p.confidence] > CONFIDENCE_RANK[best.confidence] ? p : best));
  return { verdict: winner, confidence, summary: lead.summary };
}

بعد التحقق من كل الفرضيات، إذا تم تحديد سبب جذري، كان المنسّق إما يصعّد إلى مهندس أو يكتب خطة للإصلاح. كانت هذه الخطة تُسلَّم إلى وكيل برمجة فرعي لتنفيذ الإصلاح وتقديم طلب pull request.

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

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

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

أصبح البناء على هذا الأساس أصعب باطراد للأسباب التالية:

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

كررنا العمل على هذه المعمارية لأشهر، محسّنين كل وكيل على حدة ومعدّلين المطالبات وعمليات التسليم، لكن النتائج لم تضاهِ الجهد المبذول أبدًا. كانت مكلفة، وصعبة التصحيح، ولم تكن طلبات pull request جيدة بما يكفي.

وكيل واحد

في 3 سبتمبر، استبدلنا مسار عمل الوكلاء الفرعيين بوكيل واحد ينجز كل شيء من الفرز إلى طلب pull request. يقوم الوكيل نفسه بجمع الأدلة، والتحقق من كل الفرضيات، وتقديم طلب pull request.

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

والأهم من ذلك، تحسّنت جودة طلبات pull request، وانهار الوقت الفاصل بين اكتشاف مشكلة وفتح طلب pull request الذي يحلّها. خلال الشهر المحيط بنقطة التحول، انخفض الوسيط من 2.2 ساعة إلى 35 دقيقة، وانخفضت النسبة المئوية التسعون من تسعة أيام إلى أقل من ساعتين. في ظل خط الأنابيب، كانت النتيجة عادةً تبقى راكدة لساعات عديدة في سلسلة من مسارات العمل، كل واحد ينتظر السابق. أما في ظل الوكيل الواحد، فيُفتح طلب pull request بعد دقائق فقط من اكتشاف المشكلة.

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

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

لا تبنِ وكلاء فرعيين

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