عندما تستخدمون وكيل برمجة، ترون إجاباته وعمله في الطرفية. ويمكننا أيضًا فحص الرسائل التي يرسلها الـ harness إلى النموذج. سنشغّل برنامجًا صغيرًا يُسمّى reverse proxy، وننظر داخل طلب ملتقَط، ونجد الـ system prompt الذي يضيفه الـ harness.
تعرض الطرفية إجابات الوكيل وتُبيّن ما يفعله بأدواته. وخلف هذا العرض، يتبادل الـ harness الرسائل مع خدمة النموذج. لكن الإجابة وحدها لا تكشف لنا كل ما احتواه الطلب.
يتضمّن الطلب المحادثة، والتعليمات التي يضيفها الـ harness، وأوصاف الأدوات المتاحة. نريد أن نرى هذه الرسائل مباشرةً. فهذا يسمح لنا بفحص ما يدخل إلى النموذج بدلًا من محاولة استنتاجه من الإجابة.
الـ reverse proxy برنامج يستقبل طلبًا نيابةً عن خادم آخر ثم يمرّره إليه. نضع الـ proxy الخاص بنا بين الـ harness وخدمة النموذج. يرسل الـ harness طلبه إلى الـ proxy، ثم يمرّره الـ proxy إلى الخدمة.
ويعود ردّ خدمة النموذج عبر الـ proxy، الذي يسلّمه إلى الـ harness. ويستطيع الوكيل مواصلة عمله مع هذه الخطوة الإضافية في الاتصال.
كتبنا هذا الـ proxy على شكل سكربت Python صغير، proxy.py، وهو مرفق بهذا الفيديو. يمرّر السكربت كل رسالة دون أن يغيّرها، ويطبع الطلبات والردود أثناء مرورها. وهذا كل ما نحتاج إلى فهمه عن طريقة بنائه هنا. فهو يتيح لنا رؤية التبادل بينما يواصل الوكيل عمله، ويمكننا لاحقًا بناء طريقة أسهل لفحص حركة المرور نفسها.
نزّلوا سكربت Python المرفق وشغّلوه في طرفية أولى مع خيار المنفذ الظاهر هنا. يعمل السكربت بـ Python 3 ولا يحتاج إلى حزم إضافية. السكربت الآن ينتظر الطلبات على حاسوبكم.
وفي طرفية أخرى، شغّلوا Claude Code بعد ضبط عنوان URL الأساسي على العنوان المحلي للـ proxy. متغيّر البيئة هذا يوجّه طلبات Claude Code إلى النموذج عبر الـ proxy.
أرسلوا رسالة قصيرة إلى الوكيل. في المثال الذي سجّلناه، سألنا عمّا يفعله الـ reverse proxy. وبينما يعالج Claude Code رسالتنا، تطبع الطرفية الأولى حركة المرور التي تمرّ عبر الـ proxy. لننظر إلى الطلب الذي يحمل سؤالنا.
ها هو سؤالنا داخل الطلب الملتقَط. وضعه الـ harness داخل كمّ أكبر بكثير من المعلومات، نحو 90 كيلوبايت لسؤال من سطر واحد. يُظهر المقتطف موضع رسالتنا، لكن معظم ما أرسله الـ harness يقع خارج هذا الجزء الصغير.
الحقل messages يحمل المحادثة. والحقل system يحتوي على تعليمات النظام، والحقل tools يصف الأدوات المتاحة للنموذج. يتيح لنا الـ proxy فحص هذه الأجزاء من الطلب الفعلي.
كتبنا سؤالًا قصيرًا واحدًا، لكن الـ harness أضاف أكثر من ذلك بكثير. لنفتح تعليمات النظام ونرى جزءًا صغيرًا ممّا أضافه.
هذا جزء من الـ system prompt في ذلك الطلب. يصف وكيلًا يساعد في هندسة البرمجيات، ويخبره أين يظهر نصّه، ويطلب منه أن يطابق أسلوب الكود المحيط.
لم نكتب هذه التعليمات بأنفسنا. بل أضافها الـ harness إلى جانب رسالتنا. والـ proxy يتيح لنا قراءة هذا النص، فنرى التعليمات مباشرةً. وسنفحص الـ system prompt بتفصيل أكبر لاحقًا في هذا الأسبوع. أُرسل الـ prompt في هذا الطلب الملتقَط إلى Haiku. تجدون تحت هذا الفيديو صفحة من طلب ملتقَط لاحقًا. تضع prompt نموذج Haiku بجانب ما يرسله الـ harness نفسه إلى Fable، مع تمييز الاختلافات كلمةً كلمة. يحصل Fable، النموذج الأكثر تقدّمًا، على system prompt أقصر بكثير، أي أقل من نصف الطول.
السكربت نفسه يعمل أيضًا مع Codex. لدى Codex إعداد لعنوان URL الأساسي لخدمة النموذج التي يستخدمها. وجّهوه إلى الـ proxy المحلي، وأخبروا الـ proxy بالخدمة التي يمرّر إليها الطلبات. صيغة الطلب مختلفة، لكن الفكرة نفسها.
تتضمّن تعليمات الإعداد المرفقة الأوامر الكاملة لكلا الوكيلين، بما فيها Codex عبر حساب ChatGPT. وتعمل هذه الطريقة أيضًا مع السكربت المرفق.
طباعة حركة المرور تكفي لكشف ما يرسله الـ harness، لكن قراءة محادثة تطول في الطرفية تصبح مرهقة بسرعة. نريد عرضًا نستخدمه بينما يعمل الوكيل، نفتح فيه أي طلب ونجد الأجزاء التي تهمّنا.
في المختبر، ستنطلقون من سكربت Python هذا لبناء أداة أنفع تراقب حركة المرور أولًا بأول. ستبنون واجهة لفحص التبادل، فيها عروض لعناصر مثل تعليمات النظام واستدعاءات الأدوات ونتائجها. الاتصال يوفّره الـ proxy بالفعل. وبرنامجكم سيجعل استكشاف حركة المرور أسهل من تتبّع سيل من النص المطبوع.
نستطيع الآن وضع proxy بين الـ harness وخدمة النموذج وفحص الرسائل التي تمرّ عبره. وجدنا سؤالنا، وتعريفات الأدوات، والتعليمات التي يضيفها الـ harness. وبهذا صارت لدينا طريقة ملموسة للنظر داخل التبادل، ونقطة انطلاق لبناء أداة مراقبة نستخدمها بأنفسنا.