بعد أن يتولى الوكيل المهمة، أول شيء يجب تشديده هو وحدة العمل.

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

يجب أن تكون وحدة العمل قابلة للقبول أولاً

في الأيام القليلة الماضية، بعد تجميع ملاحظات مارتن فاولر المجزأة والعديد من المناقشات في Thoughtworks Future of Software Development Retreat، كان الشعور الأكثر وضوحًا هو أن المحادثة في الاجتماع كانت متناثرة ظاهريًا، ولكن تحتها كانت تدور في الواقع حول شيء واحد فقط - تسليم جزء كبير من العمل إلى العميل.

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

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

الاستضافة الذاتية ترفع سطح التحكم

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

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

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

لا يمكن الاستعانة بمصادر خارجية للقبول والأهداف

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

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

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

لا تزال الخبرة ومهارات القراءة في تحسن

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

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

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