تعمل هندسة الوكيل أولاً على تشديد السياق وأجهزة الاستشعار

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

كلما كانت نافذة السياق أكبر، كلما كان الاهتمام أكثر استقرارًا.

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

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

لا يقوم المستشعر بتغذية السجل مرة أخرى

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

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

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

مسؤولية الحزام هي تقطيع العالم إلى قطع يمكن تغذيتها للعارضة

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

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

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