شغّلت تنسيقاً من خمسة وكلاء فرعيين لإعادة هيكلة وحدة مصادقة. كلّفني 11 دولاراً، استغرق اثنتي عشرة دقيقة، وأنتج نتيجة أسوأ من القيام بالأمر في خيط واحد. الوكلاء الفرعيون مبالَغ في تقديرهم للمطورين المستقلين، وعروض Twitter التي تُظهر أسراب وكلاء جميلة لا تحكي لك الجزء الذي يصبح فيه الأمر مكلفاً وغريباً.
لا تُساء فهمي. الوكلاء الفرعيون ميزة حقيقية لها استخدامات حقيقية. لكن النصيحة الافتراضية — «قسّم كل شيء إلى وكلاء متخصصين» — خاطئة بالنسبة لمن يبني منتجاً واحداً بمفرده. في معظم الأوقات تريد وكيلاً مسطحاً أحادي الخيط يؤدي العمل ببساطة. دعني أوضح السبب.
ما يكلفه الوكيل الفرعي فعلاً
حين تشغّل وكيلاً فرعياً، لا تُفوّض مهمة فحسب. أنت تبدأ سياقاً جديداً لا يعرف شيئاً عن خيطك الرئيسي. لذا يجب أن تُبلّغه. كل وكيل فرعي يحتاج الملفات ذات الصلة، والاتفاقيات، والهدف، مُشرحة من الصفر. هذا التبليغ هو tokens. عمل الوكيل الفرعي هو tokens. ثم يُقدّم تقريره، وتوليف تقريره في الخيط الرئيسي هو tokens أيضاً.
لمهمة متوازية ذات حدود واضحة، هذه التكلفة الإضافية تستحق. لمهمة متشابكة الأجزاء — وهذا يصف معظم البرمجة الحقيقية — تدفع ضريبة التبليغ مراراً وتكراراً، والوكلاء الفرعيون يتعثّر بعضها ببعض لأن لا أحد منها يرى الصورة الكاملة.
النسخة أحادية الخيط... تمتلك السياق بالفعل. قرأت الملفات مرة واحدة. تتذكر ما فعلته قبل ثلاث خطوات. لا تبليغ، لا توليف، لا تكلفة تنسيق إضافية. وفي الغالب تكون أرخص وأفضل معاً.
مشكلة تشتت السياق
هذه هي النقطة الدقيقة. السبب الكامل وراء تميّز الوكلاء في البرمجة هو السياق المشترك — النموذج يحمل المشكلة والملفات وقراراته السابقة في مكان واحد ويستدل عبرها جميعاً. الوكلاء الفرعيون يُحطّمون ذلك. كل واحد يرى شريحة فقط.
فالوكيل الفرعي أ يُصلح معالجة الأخطاء بطريقته. الوكيل الفرعي ب، المُبلَّغ بشكل منفصل، يُصلح التحقق بطريقة مختلفة. لا أحد يعرف ما فعله الآخر. أنت في الخيط الرئيسي تحتاج الآن إلى التوفيق بين تغييرين منطقيَّين محلياً لكنهما لا يتناسبان. أمضيت وقتاً أطول في التوفيق بين مخرجات الوكلاء الفرعيين مما وفّروه. هذا هو الفخ.
بالنسبة للمطور المستقل، ميزتك هي أن أنت تحمل الصورة الكاملة في رأسك والوكيل يحملها في السياق. تشتيت ذلك لتبدو كفريق هو تمثيل دور منظمة لا تمتلكها.
متى تستحق الوكلاء الفرعية فعلاً
لا أقول لا تستخدمها أبداً. إليك أين ألجأ إليها فعلاً:
- عمل متوازٍ مستقل حقاً. «شغّل مجموعة الاختبارات بينما تفحص قاعدة الكود أيضاً.» لا حالة مشتركة، لا توفيق. توسع نظيف.
- عزل السياق عمداً. حين قد تُغرق مهمة فرعية سياقي الرئيسي بضوضاء لا أريدها في الخيط الرئيسي — مثل قراءة 40 ملفاً للإجابة على سؤال واحد. الوكيل الفرعي يقرأ الـ 40، ويُعيد الإجابة الواحدة، سياقي الرئيسي يبقى نظيفاً. هذا استخدام رائع.
- بحث محدود. «اذهب واكتشف كيف تعمل مصادقة هذه المكتبة وأبلّغ.» الاستكشاف فوضوي؛ أريد الخلاصة فقط.
لاحظ النمط: الوكلاء الفرعية تكسب مكانها حين تكون المهمة الفرعية مستقلة وقابلة للتلخيص. حين تكمن القيمة في إبقاء الفوضى خارج الخيط الرئيسي، لا في التظاهر بأنك فريق.
وهم التنسيق
هناك نوع من المحتوى يبيع حلم الوكلاء المتعددة — وكيل مُخطّط، وكيل مُبرمج، وكيل مُراجع، وكيل مُختبِر، كلهم يتنسّقون كشركة صغيرة. يبدو رائعاً في المخطط. للمطور المستقل هو في الغالب طريقة لتحويل مهمة بـ 0.50 دولار إلى مهمة بـ 6 دولارات.
المُخطّط يُعيد شرح المهمة للمُبرمج. المُبرمج ينتج العمل. المُراجع، بسياقه الجديد الخاص، يُعيد قراءة كل شيء لمراجعته. المُختبِر يُعيد قراءته مجدداً. كل تسليم يُعيد معالجة نفس الكود. لقد أعدت إنشاء عدم كفاءة فريق كبير — كل تكلفة التواصل — دون الفائدة، لأنك لا تزال أنت والنموذج فقط.
وكيل واحد قادر في خيط واحد يُخطّط ويُبرمج ويُراجع نفسه بنفسه وهو يحمل كل شيء في السياق. أنت تقرأ الفرق في النهاية. هذا هو المُراجع الخاص بك. أنت الهيكل التنظيمي.
قاعدتي
افتراضياً إلى البنية المسطحة. خيط واحد، وكيل واحد، سياق كامل. ألجأ إلى وكيل فرعي فقط حين أستطيع الإجابة بنعم على: هل هذه المهمة الفرعية مستقلة، وهل أريد فقط الملخص في المقابل؟
# السؤال الذي أطرحه قبل تشغيل وكيل فرعي:
# - مستقل عن العمل الرئيسي؟ (لا حالة مشتركة للتوفيق)
# - قابل للتلخيص؟ (أريد خلاصة، لا مخرجات خام)
# كلاهما نعم -> وكيل فرعي. وإلا -> أبقِ المسطح.
كل شيء آخر يبقى في الخيط الرئيسي، حيث السياق كامل والفاتورة صغيرة.
سرب الوكلاء يبدو كالمستقبل. لشخص واحد يشحن منتجاً واحداً، هو في الغالب زي مُقنَّع. انزعه وأنجز العمل في خيط واحد. ستشكرك ميزانية tokens، وكذلك الكود.