ما نوع الأدوات الأساسية التي يحتاجها الوكيل

رأى الجميع يتحدث عن مجموعة أدوات الوكيل——هل يكفي فقط توفير قشرة شل ليتم كل شيء؟ بعد عمل holon اكتشفت أن الأمر ليس بهذه البساطة.
اقرأ: لماذا تخلينا عن Read/Glob، واتجهنا بالكامل نحو الشل
طورت مجموعة أدوات holon عدة إصدارات، وفي النهاية تخلت عن أدوات مخصصة مثل Read (لقراءة الملفات) و Glob (للبحث عن أنماط)، التي كانت تقدمها Claude Code، واعتمدت على تنفيذ كل عمليات القراءة والبحث عبر الشل. وهذا يتوافق مع مسار Codex——أمر ExecCommand واحد، قراءة الملفات باستخدام cat، البحث عن الكود باستخدام rg، دون الحاجة لتعريف أداة منفصلة لكل نوع من عمليات "القراءة".
السبب وراء ذلك بسيط جدًا: الشل هو "لغة برمجة" أكثر ألفة لنموذج اللغة الكبير (LLM). بدلاً من أن يتعلم النموذج معاني وسائط أدوات Read التي تعرفها، من الأفضل أن يكتب أوامر شل مدربة على مئات المليارات من العمليات. كل أداة مخصصة إضافية تزيد من عبء الإدراك على النموذج؛ بينما واجهة الشل، النموذج متمرس فيها بالفعل.
لكن الاعتماد الكامل على الشل له تكلفة: تقطيع المخرجات. لمنع الشل من إرجاع نتائج طويلة جدًا تملأ السياق، يتم تحديد حد أقصى لكل أمر. إذا استخدم الوكيل cat لقراءة ملف كبير، قد يحصل على الجزء الأول فقط، والباقي يكون في ملف artifact، ويحتاج إلى cat مرة أخرى أو أكثر لقراءته بالكامل. أدوات Read في Claude Code لديها عتبة ضغط أعلى بكثير من الشل العام، وتقرأ ملفًا كبيرًا دفعة واحدة، مما يقلل من التنقلات. في الجوهر، هو توازن بين تقليل تعريف الأدوات لتخفيف عبء الإدراك، وفعالية الأدوات المخصصة في الحالات الحدودية.
كتابة: من sed إلى ApplyPatch، وتحديات أداة القواعد الحرة
لكن عمليات الكتابة لا يمكن إنجازها بالكامل باستخدام الشل.
إذا جعلنا الوكيل يستخدم sed فقط للتحرير، سنواجه صعوبة في التعامل مع أنماط متعددة السطور المعقدة——الانتقالات، الهروب، التباعد، أي مشكلة في أي من هذه الطبقات ستؤدي إلى فشل التحرير. لذلك توفر العديد من الأنظمة أدوات تحرير مثل استبدال النصوص، حيث يمرر الوكيل سلسلة قديمة من النصوص (old_string) لمطابقتها بدقة واستبدالها بـ new_string. رغم أنها غير فعالة، إلا أنها أكثر استقرارًا من sed.
أما Codex فذهب أبعد من ذلك، وابتكر أداة ApplyPatch الخاصة به، التي تسمح للوكيل بإنشاء التصحيحات (patches) مباشرة، مما يتيح تحرير دفعة واحدة. وholon استلهم هذا النهج.
لكن عند التنفيذ، واجهت مشكلة: يستخدم Codex صيغة تصحيح مبسطة خاصة به، ويعتمد على آلية أداة القواعد الحرة (free grammar tool) لحل مشكلة تمرير التنسيق.
لماذا نحتاج إلى آلية جديدة خاصة؟ لأن تعريف أدوات LLM القياسي هو tool(args) بصيغة JSON. إذا مررت التصحيح كوسيط نصي JSON، ستواجه الكثير من الهروب والتنسيق—الانتقالات يجب أن تتغير، علامات الاقتباس يجب أن تُهرب، والتباعد يجب أن يُعالج بعناية. كتابة التصحيح في الوكيل يكون عرضة للأخطاء، وإضافة طبقة من التشفير JSON يزيد من احتمالية الخطأ. فكرة أداة القواعد الحرة هي أن النص الأصلي للتصحيح يُمرر مباشرة كمدخل للأداة، دون ترميز JSON، بحيث يكون ما يكتبه النموذج هو ما هو. هذا يقلل بشكل كبير من أخطاء النموذج عند توليد التصحيحات.
هذه الآلية حاليًا مدعومة فقط من قبل واجهة Codex الخاصة بـ OpenAI. وholon يسعى ليكون متوافقًا مع مزودي نماذج متعددة، لذلك لا يمكن الاعتماد فقط على هذه الطريقة.
لذا، فإن نهج holon هو: حقن تعريفات مختلفة لـ ApplyPatch حسب النموذج. للنماذج التي تدعم القواعد الحرة، يتم استخدام صيغة التصحيح الأصلية؛ ولنماذج أخرى، يتم استقبال صيغة diff الخاصة بـ git. أعتقد أن نماذج LLM المدربة على مئات المليارات من عمليات diff على GitHub يجب أن تكون متمرسة جدًا في صيغة diff. التجربة أظهرت أن الأداء جيد—رغم أن الأخطاء لا تزال تحدث، إلا أن غالبية التعديلات تكون صحيحة، ومع تراكم البيانات التدريبية، ستتحسن هذه القدرة أكثر. ومع ذلك، أنصح جميع مطوري النماذج بدعم أداة القواعد الحرة، فهي ضرورية حقًا في سيناريوهات كتابة الكود بواسطة الوكيل.
الجدولة: أوامر طويلة الأمد وتجريد المهام
المشكلة الثالثة أن أوامر الشل التي ينفذها الوكيل قد لا تنتهي بسرعة—تشغيل خادم التطوير، إجراء الاختبارات، بناء المشروع، كلها قد تستغرق وقتًا طويلًا، أو حتى لا تنتهي أبدًا. في البداية، كانت أطر عمل الوكيل تتعامل مع الأمر بشكل بسيط جدًا: إما أن تكون عملية متزامنة وتوقف الوكيل، أو أن تضع جميع الأوامر في الخلفية، مما أدى إلى تكرار تنفيذ نفس الأمر مرات عديدة.
الآن، يتفق المجتمع تدريجيًا على مبدأ أساسي: عدم السماح للوكيل بقرار "الواجهة الأمامية/الخلفية" بنفسه—فهو غير موثوق في ذلك. الطريقة الأفضل هي تحديد حد زمني، وإذا تجاوز الأمر الوقت المحدد، يتم نقله تلقائيًا إلى الخلفية، ويكون ذلك شفافًا تمامًا للوكيل. الوكيل لا يحتاج إلى التنبؤ مسبقًا إذا كان الأمر يجب أن يُنقل للخلفية أم لا، فالتنفيذ يتم تلقائيًا.
لكن التحويل التلقائي إلى الخلفية هو الخطوة الأولى فقط. بعد نقله للخلفية، تظهر مشاكل هندسية حقيقية—وهذه المشاكل لا تزال بلا حل موحد حتى الآن.
أولاً، كيف نقرأ المخرجات؟ قد تكون المهمة لا تزال جارية، أو انتهت، والمخرجات قد تكون ضخمة. لكن واجهات برمجة التطبيقات (APIs) تختلف في المعنى—بعضها يستخدم الاستطلاع (polling)، والبعض الآخر يستخدم دفع الأحداث (event push).
ثانيًا، كيف نوقف المهمة؟ كل شركة لديها آلية إلغاء، لكن هل يكون الإلغاء قتلًا فوريًا أم خروجًا أنيقًا، وهل نحتفظ بالمخرجات التي تم إنتاجها؟
ثالثًا، من الذي يوقظ الوكيل؟ بعد أن يرسل المهمة إلى الخلفية ويضعها في حالة سكون، من الذي يوقظه عند الانتهاء؟ هذا يتطلب ارتباطًا عميقًا بين إدارة الوقت والتشغيل، وليس شيئًا يمكن حله بواسطة أدوات مستقلة فقط.
هذه الثلاثة—قراءة المخرجات، إيقاف المهمة، إيقاظ الوكيل—تشكل دورة حياة إدارة المهام الخلفية بشكل كامل. كل الشركات تدعم "تشغيل في الخلفية"، لكن لا توجد بعد معايير موحدة لإدارة الحالة، وهذا قد يكون النقطة الحاسمة لتطور أدوات الوكيل في المرحلة القادمة.
ليس بعد الوقت لاستخدام نمط جاهز بشكل أعمى
إذن، العودة إلى السؤال في البداية: هل يمكن للشل أن يحل 80% من المشكلات، لكن الـ20% المتبقية—دقة التحرير، توافق صيغة التصحيح مع قدرات النموذج، جدولة المهام الطويلة—هي التي تحدد ما إذا كان الوكيل سينتقل من مجرد نموذج تجريبي إلى نظام عملي حقيقي.
اختيار أدوات المجموعة ليس مجرد "تغليف شل"، وهو أبعد من أن يكون نمطًا جاهزًا يمكن تطبيقه بدون تفكير. ولهذا السبب، قدمت كل من Codex وClaude Code إجابات مختلفة على هذه القضايا الأساسية، وholon اتخذت قرارات مختلفة وفقًا لسيناريوهاتها. هناك الكثير من النقاط التي يمكن استكشافها وتحسينها في هذا المجال.