داخل وكيل برمجة CLI: الحلقات والسياق والصلاحيات

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

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

حلقة استدعاء الأدوات نظام موزّع

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

لنتأمل ما يجب أن تتعامل معه الحلقة فعلاً. تفشل تنفيذات الأدوات: يعطي المترجم أخطاء، أو تتعلق مجموعة الاختبارات، أو لا يوجد الملف في ذلك المسار لأن النموذج اختلقه. يُصدر النموذج JSON غير صالح في وسائط أدواته. يستغرق استدعاء أداة أربعين ثانية فيضغط المستخدم Escape في منتصف التشغيل. يصل استدعاءان للأدوات في دورة واحدة، ويجب ألا يُنفَّذ أحدهما إذا فشل الآخر. تمتلئ نافذة السياق في منتصف المهمة فلا بد أن يُتنازل عن شيء. كل ذلك مشكلة تزامن وفشل، لا مشكلة ذكاء. سبق أن قلت إن وكلاء LLM ليسوا سوى أنظمة موزعة، وأداة البرمجة عبر سطر الأوامر هي المثال الأنقى على ذلك: لديك مكوّن بعيد غير موثوق وغير حتمي (النموذج) ينسّق مع مكونات محلية ذات آثار جانبية (الشل، ونظام الملفات، وLSP)، والحلقة هي بروتوكول التوافق بينهما.

لهذا السبب يهم أن OpenCode 2.0 أعاد بناء حلقته حول Effect، وهو إطار عمل TypeScript للتزامن المنظم والأخطاء المُنمّطة. هذا الاختيار يشير إلى أن الفريق توقف عن النظر إلى الحلقة على أنها «حلقة while فيها fetch»، وبدأ يعاملها كما هي فعلاً: نظام من تأثيرات قابلة للمقاطعة والتركيب وإعادة المحاولة، مع قنوات أخطاء صريحة. عندما تملك حلقة الوكيل دلالات إلغاء حقيقية، يصبح «ضغط المستخدم على Escape» حدثاً من الدرجة الأولى بدلاً من أن يُفسد الحالة. وعندما تكون نتائج الأدوات مُنمّطة، يمكنك التحقق من مخرجات النموذج قبل تنفيذها، وهذا يتناسب بشكل جميل مع تقنيات مثل فك الترميز المقيّد، حيث تقيّد فضاء مخرجات النموذج فيصبح استدعاء الأدوات المشوه مستحيلاً بدلاً من أن يُكتشف فقط.

العميل/الخادم هو الميزة التي لا يسوّق لها أحد

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

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

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

إدارة السياق هي حيث تعيش الجودة

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

تتعامل البنية الجيدة مع السياق كميزانية لها سياسة تخصيص، لا كأنبوب. عملياً، هذا يعني عدة أشياء تعمل معاً:

• اقتطاع مخرجات الأدوات مع منافذ للاسترجاع. يجب أن يدخل سجل اختبار من 5000 سطر إلى السياق بأربعين سطراً فاشلة فقط، مع ملاحظة بأن السجل الكامل موجود في مسار يستطيع النموذج إعادة قراءته. البنية تحدد ما هو بارز، والنموذج يقرر متى يحتاج المزيد.
• الجلسات الفرعية والوكلاء الفرعيون. طلب مثل «استكشف كيف تعمل المصادقة في هذا المستودع وأخبرني» يجب أن يعمل في سياق معزول يعيد ملخصاً، لا نص الاستكشاف الكامل. تحسين التواصل بين الجلسات الفرعية في OpenCode 2.0 هو تماماً هذه الفكرة.
• ضغط يحافظ على النية. عندما تمتلئ النافذة، لا بد من تلخيص المحادثة حتى الآن. البنية التي تلخص بسذاجة تفقد قيود المستخدم («لا تلمس وحدة الفوترة») مع الضوضاء. الضغط الجيد يحفظ القرارات والقيود حرفياً، ويضغط السرد فقط.
• الإعدادات والمهارات كسياق، لا كشيفرة. تعليمات المشروع، والأدوات المعرّفة عبر الإضافات، وملفات المهارات، كلها تستهلك النافذة. إعادة تحميلها أثناء التشغيل، وهو إصلاح آخر في 2.0، مهم لأن تعديل سياق وكيلك دون إعادة تشغيل جلسته هو الطريقة التي تكرر بها تحسين سلوك الوكيل نفسه.

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

نماذج الصلاحيات: الميزة المملة التي تحسم التبني

هذا سؤال من نقاش Hacker News أعدّه أهم سؤال منتجي في هذا المجال: هل يوجد شيء بين «وافق على كل أمر» و«وضع yolo»؟ الموافقة التلقائية الكاملة خطيرة فعلاً، فوكيل برمجة يملك وصولاً للشل يمكنه تنفيذ rm -rf وgit push --force وتسريب متغيرات البيئة كلها في دورة واحدة. والموافقة اليدوية الكاملة غير عملية فعلاً، فالموافقة على ثمانين أمراً في الساعة يعني أنك لا تشرف على الوكيل، بل تصبح لوحة مفاتيح بشرية بطيئة تقاطع العملية. الأداة التي تصيب الحل الوسط تكسب البراغماتيين.

الحل الوسط هو نموذج صلاحيات متدرّج، ومساحة تصميمه مفهومة أفضل مما يظن الناس:

• قراءة فقط مقابل كتابة مقابل تنفيذ. القراءة شبه مجانية، والكتابة يجب أن تكون محصورة في شجرة المشروع، والتنفيذ هو المكان الذي تكون فيه السياسة الأهم.
• قوائم سماح واعية بالمعاملات. git status يُوافَق عليه تلقائياً، وgit push يطلب التأكيد. الأدوات الساذجة تطابق اسم الملف التنفيذي، أما الجيدة فتطابق الفعل والأعلام، لأن npm test وnpm publish هما الملف التنفيذي نفسه لكن بأنصاف أقطار تأثير مختلفة تماماً.
• منح محصورة بالجلسة. «السماح دائماً بهذا الأمر في هذه الجلسة» هي أعلى ميزة صلاحيات قيمة على الإطلاق. إنها تحوّل سبعين طلباً إلى طلب واحد.
• الاحتواء لما لا يمكن التراجع عنه. الوصول إلى الشبكة، وأي شيء خارج مجلد المشروع، وأي شيء يلمس بيانات الاعتماد، يجب أن يكون مقيّداً بنيوياً، لا مجرد سؤال يُطرح.

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

الإضافات ومشكلة النماذج المستضافة ذاتياً

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

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

متى ينهار الادعاء المخالف

قلت إن النموذج هو الجزء السهل. حان وقت الإقرار بالحدود. الادعاء صحيح بالنسبة لـتصميم البنية، أي الحلقات والسياق والصلاحيات، لكن هناك مواضع يكون فيها النموذج عنق الزجاجة فعلاً. موثوقية استخدام الأدوات نفسها تُدرَّب في النماذج، فالنموذج الذي لا يستطيع إصدار استدعاءات دوال صالحة باستمرار يجعل كل بنية تبدو معطلة، ولا يصلح أي قدر من التزامن المنظم القائم على Effect نموذجاً «يجادل» مخطط بياناته. والتخطيط متعدد الخطوات عبر الأفق الطويل لا يزال يفصل فئات النماذج بطرق تشعر بها داخل جلسة واحدة. وإطار «البنية مقابل النموذج» له عمر محدود: فمع امتصاص النماذج للسلوك الوكيلي في التدريب (استخدام أدوات أصيل، وتخطيط أصيل لأفق طويل)، تنتقل القدرات من البنية إلى الأوزان، وتصبح ميزة البنية الذكية اليوم جهداً مهدوراً غداً. على فرق بناء البنى أن تفترض أنها تبني سقالات ستجعلها النماذج يوماً ما عديمة الجدوى، وهذا بصراحة حجة لصالح البنى مفتوحة المصدر ذات الأنظمة البيئية للإضافات، لأنها تعيش بفضل المجتمع لا بفضل فجوة قدرات مؤقتة.

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

النموذج يكتب الشيفرة، لكن البنية تقرر إن كنت تثق به بما يكفي لتتركه يعمل.

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