بقلم: يوسف | محرر أدوات الذكاء الاصطناعي · صوت تحريري بإشراف بشري
حين يكون الخطأ كلفته باهظة — سفينة دورية تتحرك في الاتجاه الخاطئ، أو موارد شحيحة تُهدر، أو عناصر بشرية تُعرَّض للخطر — فإن الموثوقية تتحول من مزية إلى شرط وجود. هذا بالضبط ما واجهه فريق Skylight من Ai2 حين بنى Shippy، وكيل الذكاء الاصطناعي المخصص للوعي الميداني البحري الآني، ونشره على منصة تخدم أكثر من 300 شريك في 70 دولة (وفقاً لـ Ai2).
ما يميز تجربة Shippy عن معظم مشاريع بناء الوكلاء هو أن الفريق لم يبنِ نموذجاً، بل بنى منظومةً كاملة قابلة للاختبار والتحقق والتدقيق. وفيما يلي أبرز الدروس الهندسية التي خرج بها الفريق، موثّقةً بالتفاصيل التقنية الكاملة.
- فصل “الروح” عن “المهارات” عن “الإعداد” — يُعرّف الفريق البنية المعمارية لـ Shippy على أنها ثلاثة مكوّنات متمايزة: الروح (Soul) وهي system prompt يحدد شخصية الوكيل وحدوده السلوكية، والمهارات (Skills) وهي ملفات Markdown منظمة تصف كيفية معالجة أنواع معينة من الطلبات، والإعداد (Config) الذي يشمل كل شيء آخر. الروح والمهارات مُدمجتان في صورة Docker قابلة للإصدار والنشر، بينما يُحدد الإعداد أيّ harness يُستخدم — في حالة Shippy هو OpenClaw مفتوح المصدر — وأيّ LLM يُشغَّل، وحالياً هو Claude Opus 4.6. تبديل النموذج أو الـ harness هو تغيير في الإعداد فحسب، لا إعادة بناء للصورة كاملةً.
- المهارات كمواصفة agent-skills قياسية — تتبع مهارات Shippy المعيار نفسه الذي تستخدمه أدوات برمجية كـ Claude Code وCodex، وهو ملفات Markdown واضحة بـ frontmatter منظم. يمتلك Shippy حالياً مهارات لاستعلام API أحداث Skylight (السلوكيات التي ترصدها المنصة كالصيد أو نقل البضائع بين سفينتين)، والبحث في بيانات السفن، ورسم حدود المناطق الاقتصادية الخالصة (EEZ) والمناطق البحرية المحمية (MPA)، وتفسير بيانات مسار السفن، وتوليد روابط خريطة تفاعلية تقفز بالمحلل من الإجابة النصية مباشرةً إلى الموقع الدقيق على خريطة Skylight. سؤال واحد — مثل “هل هناك سفن تعمل قرب محمية Cordillera de Coiba؟” — يستدعي ثلاث مهارات في آنٍ واحد: استعلام Skylight، وقاعدة بيانات ProtectedSeas لحدود المحمية، ومهارة مسار السفن.
-
أدوات حتمية لوكيل غير حتمي — الوكلاء بطبيعتهم غير حتميين؛ لا يمكنك التحكم بما يقرر النموذج فعله، لكن يمكنك جعل الأدوات التي يصل إليها متوقعةً. في النماذج الأولى، كان Shippy يُنشئ استدعاءات API من الصفر — وقد أسفر ذلك عن تدفق مستمر من الأخطاء الدقيقة: pagination معطوب يُسقط نتائج بصمت، وأخطاء في تشفير الهندسة، واستعلامات صحيحة المظهر تُعيد بيانات خاطئة. الحل كان بناء CLI مخصص يُلخّص هذا التعقيد: يُصدر Shippy أمراً واحداً فقط —
skylight events searchبأعلام فلترة مكتوبة — ويتولى CLI المصادقة والـ pagination والمخرجات المنظمة. المخرجات تُكتب دائماً في ملف JSON محلي لا عبر الـ shell، لأن مجموعات النتائج الكبيرة كانت تتجاوز حدود buffer الأنابيب أو تُخل بأدوات المعالجة اللاحقة. - عزل الجلسات بـ Kubernetes ديناميكي — كل مستخدم يتحدث مع Shippy داخل جلسة مؤقتة معزولة تماماً. الفريق بنى Mothership، منصة استضافة وكلاء تُوفّر deployment مستقلاً في Kubernetes لكل جلسة مستخدم. عند فتح محادثة، يُشغّل النظام مجموعة pods تحتوي على runtime الوكيل ومهاراته وCLI Skylight، وتُحقن JWT الخاصة بالمستخدم عند التهيئة لضمان أن استدعاءات API تُعيد بياناته فقط. الملفات التي يكتبها الوكيل أثناء تحليل متعدد الخطوات لا توجد إلا داخل تلك الجلسة. على مستوى الشبكة، يُقيَّد sandbox بالخدمات الضرورية فقط.
- تقييم الوكيل كاملاً لا النموذج وحده — معظم benchmarks تقيّم الذكاء الاصطناعي العام على أسئلة ثابتة، ولا تعكس كيف يتصرف الوكيل حين يُوصَل بسير عمل حقيقية. بنى الفريق إطار تقييم خاصاً يُشغّل الوكيل كاملاً — النموذج والمهارات والـ sandbox معاً — مقابل بيانات حية. خبراء المجال يكتبون السيناريوهات والمعايير، ويُحددون الأوزان لكل مهمة. مثلاً، استعلام أحداث الصيد يُعطي الوزن الأكبر لدقة البيانات، ثم حل الحدود الجغرافية والإطار الزمني، ثم إسناد المصادر وأسلوب الإجابة بأوزان أخف. يُقيّم قاضٍ LLM كل معيار بقيمة من 0 إلى 1 مع تبرير مكتوب، والمجموع الموزون يُقارَن بحد اجتياز ثابت. المهام تُنفَّذ عبر Harbor إطار التقييم المفتوح، من خلال plugin خاص يُشغّل جلسة Shippy حقيقية على الإصدار المُختبَر مقابل بيانات حية. النتيجة: ملف نتائج بطابع زمني وتقرير بتغييرات الدرجات مقارنةً بالتشغيل السابق.
- الحدود صريحة في system prompt لا مضمّنة في fine-tuning — Shippy لن يُصدر أحكاماً قانونية بشأن انتهاك سفينة للقانون، ولن يُخمّن خارج نطاق ما تدعمه البيانات. هذه الحدود مُوثّقة صراحةً في الروح، لا مُشفَّرة في أوزان النموذج، مما يجعلها قابلة للتدقيق والتعديل بسهولة.
- الإخفاقات بوصلة للتحسين لا مجرد أرقام — في آخر تشغيل للتقييم، كشف الفريق عن ثلاثة أنماط واضحة: مهام تخطيط الدوريات حيث تجاوز Shippy دوره وأدلى بتوصيات تكتيكية بدلاً من دعم القرار، واستعلامات حساسة للهندسة الجغرافية حيث تبسيط الحدود أفضى إلى تفويت أحداث، وحالة واحدة أخترع فيها الوكيل أمر CLI غير موجود. كل إخفاق يُترجَم مباشرةً إلى تحسين محدد في جولة المهارات التالية.
ما يُقرأ بين السطور هنا أن هذا الفريق توصل إلى شيء يتجاهله كثير من بناة الوكلاء: الموثوقية لا تأتي من اختيار أقوى نموذج، بل من التصميم الدقيق لكل طبقة تحيط به. الـ CLI الحتمي يُضيّق ما يمكن للوكيل أن يُخطئ فيه. عزل Kubernetes يمنع التلوث بين الجلسات. التقييم المبني على بيانات حية يكتشف الإخفاقات التي لن تظهر أبداً في benchmark ثابتة.
الفريق يعمل الآن على ثلاثة محاور للمرحلة المقبلة: تحكم الوكيل في واجهة خريطة Skylight مباشرةً بدلاً من إعادة روابط فحسب، وتوجيه الاستعلامات البسيطة إلى نماذج أصغر وأسرع مع الاحتفاظ بالنموذج الكامل للتحقيقات المعقدة، وبناء ذاكرة عابرة للمحادثات تحمل حقائق ثابتة عن المحلل — كنطاق اختصاصه ومصادره المفضلة — حتى لا يضطر إلى إعادة تحديد منطقته الاقتصادية في كل استعلام. والأهم أن Mothership بُني ليكون منصة عامة، وقد بدأت دروس Shippy تُشكّل بالفعل كيف يبني الفريق وكلاء على منصتَي EarthRanger للحفاظ على الحياة البرية وOlmoEarth لأدوات رصد الأرض المفتوحة.
إن كنت تبني وكلاءً في بيئات عالية المخاطر، فالسؤال الحقيقي ليس “أيّ نموذج أختار؟” بل “كيف أجعل كل طبقة في النظام تُضيّق ما يمكن للطبقة التالية أن تُخطئ فيه؟”
