عودة
E-022 / مقالة

المعاينة التقنية الأولى لـa2

الإصدار 0.1.0a1: أعمال بيانات قابلة للفحص، ومهارات قابلة لإعادة الاستخدام، وحدود المعاينة التقنية المعلنة.

ملاحظة إصدار — 0.1.0a1

عندما نكرر العمل نفسه غداً، ماذا نستطيع الاحتفاظ به من الحل السابق؟

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

نشرت أول معاينة تقنية لـa2، بالإصدار 0.1.0a1، على GitHub. أصبح الكود المصدري وحزم التثبيت وسجلات العرض القابلة للفحص متاحة.

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

ما أريد إظهاره خصوصاً في هذا الإصدار هو كيفية إنجاز العمل.

أي خطة نُفذت؟ أي مهارة استُخدمت؟ أي إصدار من كودها اختير؟ هل فُحص شكل النتيجة فقط، أم قورنت أيضاً بإجابة متوقعة أُعدت بصورة مستقلة؟

يمكن فحص إجابات هذه الأسئلة إلى جانب المخرج.

اللقاء الأول: تسوية ملفين

يتناول العرض قائمتين للعملاء أُعدتا كأنهما صادرتان من نظامي CRM وERP.

يُفترض أن رموز العملاء في النظامين تعبّر عن الهويات نفسها. لكن القائمتين لا تحتويان على السجلات نفسها. لبعض العملاء مقابل، وبعضهم يحتاج إلى مراجعة.

يستخدم العرض بيانات اصطناعية ليومين. في اليوم الأول تتطابق أربعة سجلات من أصل ستة في CRM، ويُبلّغ عن اثنين منفصلين. وفي الثاني تتطابق خمسة من سبعة، ويُفصل اثنان للمراجعة أيضاً.

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

لا يحتاج هذا التنفيذ إلى مفتاح API ولا يستدعي نموذجاً. مهارات العرض مكتوبة بشرياً.

ما يُعرض هو إعادة تشغيل حل أُعد بقواعد محددة على مدخلات جديدة بالإصدار نفسه.

نطاق المعاينة التقنية

أرى هذا الإصدار نقطة بداية قابلة للمشاركة لتجربة النهج.

لا يستخدم العرض بيانات عملاء حقيقية، ولا ينشئ اتصالاً حياً بنظام CRM أو ERP. ولا يطابق الأسماء تقريبياً أو يحل هويات العملاء المختلفة تلقائياً.

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

اكتمل تشغيل GitHub CI الخاص بالتزام هذا الإصدار بنجاح. هذه نتيجة فحوص البرمجيات المسجلة، وليست بديلاً عن تجربة مع مستخدمين حقيقيين أو تقييم التعلم والكفاءة.

ما أريد مواجهته بعد المعاينة الأولى هو قواعد مهمة حقيقية.

ما مقدار جهد الإعداد والفحص؟ ما التدخلات التي تبقى عند إعادة التشغيل؟ هل نستطيع التقاط المطابقات الخاطئة؟ وإذا تغير الملف، هل يظل الحل نفسه مناسباً؟

أشارك a2 في مرحلة يمكن فيها طرح هذه الأسئلة على عمل ملموس.


ملاحظة المصادر — 18 أكتوبر 2026: يعتمد النص على وثائق إصدار 0.1.0a1 وسجلات العرض الموجودة. بيانات العرض اصطناعية والمهارات مكتوبة بشرياً. لم يُنفذ عرض أو استدعاء نموذج أو تقييم جديد من أجل المقال.

الكود المصدري · الإصدار والتنزيلات · دليل العرض · تنزيل تقرير HTML · تنزيل أدلة العرض · GitHub CI

روابط: a2 · تحول الفكرة إلى أداة تعمل · متى ينبغي أن يتوقف الوكيل؟ · العمل نفسه، وملف آخر في اليوم التالي · لماذا ترفض خطة أن تعمل؟

يرتبط بـ

يستكشفa2

يتناول المعاينة التقنية 0.1.0a1 لـa2 والأدلة المحدودة في حزمة إصدارها.

يشير إلىتحول الفكرة إلى أداة تعمل

يربط مقال الانتقال من الفكرة إلى الأداة بالمعاينة التقنية المنشورة.

يشير إلىمتى ينبغي أن يتوقف الوكيل؟

يربط قراءة حدود المعاينة بشروط توقف الوكيل.

يوسعالعمل نفسه، وملف آخر في اليوم التالي

يجسد فكرة إعادة الاستخدام في الإعلان بسجلات عرض يومين.