Install
pipx install awesome-okfلمن يناسب
- المطوّرون أو مستخدمو الوكيل الذين يريدون أن يستعلم AI agent مباشرة من كتالوج موارد OKF (Open Knowledge Format): يضم الكتالوج أدوات وإضافات وskills ومقترحات ووثائق مرتبطة بـ OKF.
- من يستخدم أصلًا عميلًا يدعم MCP ويريد بحثًا برمجيًا بأدوات مثل
search_catalogوget_catalog_entry. - من يريد تحويل محتواه إلى كتالوج OKF (ملفات Markdown + YAML frontmatter) والتحقق منه بـ
myokf validate.
متى لا يناسب:
- الحالات التي لا تحتاج اكتشاف موارد OKF أو تحويلها وتريد فقط الاستعلام عن بيانات مجالات أخرى.
- من يحرّر README مباشرة — النص الرسمي يقول إن README*.md ناتج توليدي ولا يُعدَّل يدويًا، ويجب تغيير
data/catalog.yamlثم إعادة التوليد. - ما لم يشرحه النص الرسمي (قائمة العملاء المدعومين، نطاق لغات إدخال التحويل، متطلبات النظام المحددة) لا يُخمَّن في هذه الصفحة، ويُعلَّم بأنه غير مؤكد.
أول تجربة في 3 دقائق
الشرط: بيئة Python محلية مع pipx مثبّت (طريقة التثبيت الرسمية). هذه CLI + MCP meta-server مكتوبة ببايثون.
-
التثبيت: نفّذ في الطرفية
pipx install awesome-okf -
وصل الوكيل: سجّل MCP server في عميل MCP لديك بالأمر
awesome-okf-server(الصيغة الرسمية "Connect it to your MCP client"؛ مسارات التسجيل لكل عميل غير واردة في الأدلة، فاتبع وثائق عميلك). -
شغّل مهمة قراءة فقط منخفضة المخاطر: قل للوكيل «استخدم search_catalog للبحث عن أدوات OKF في الكتالوج وأرجع أول بضع مدخلات». تقبل الأداة query/kind/limit، وهي استعلام كتالوج ولا تكتب.
إشارة النجاح: يعيد الوكيل مدخلات الكتالوج (اعتمادًا على بيانات get_catalog_entry / list_catalog) أو إحصاءات catalog_stats — أي أن meta-server متصل.
تنبيه: التجربة الأولى للاستعلام فقط. convert_to_okf وscripts/convert-to-okf.py ينشئان ملفات كتالوج OKF ويكتبان على القرص. نفّذهما بعد تأكيد مسار الوجهة ومعرفة أنهما سيولّدان ملفات Markdown + YAML frontmatter.
حالات الاستخدام
الحالة 1: اطلب من الوكيل إيجاد موارد OKF. السيناريو: تريد معرفة الأدوات أو المهارات المتاحة في منظومة OKF. اطلب من الوكيل المتصل: «استخدم search_catalog، ضع الكلمات في query، صفِّ حسب kind إن شئت، وتحكم بالعدد عبر limit». يستدعي الوكيل أداة بحث meta-server ويعيد الأدوات/الإضافات/skills/المقترحات/الوثائق المطابقة؛ للإحصاء استخدم catalog_stats. هذا استعلام صرف والنتيجة هي مدخلات الكتالوج نفسها.
الحالة 2: حوّل محتوى جاهزًا إلى كتالوج OKF. السيناريو: لديك نص منظم (قوائم، JSON، أزواج مفتاح-قيمة، قوائم URL) وتريد صيغة معرفة ملائمة للوكيل. استخدم scripts/convert-to-okf.py؛ وضع --format anything يجرّب سلسلة التحليل (list → JSON → key-value → URLs → line-per-row) حتى ينجح محلل. النتيجة القابلة للتأكيد: كتالوج ملفات Markdown مع YAML frontmatter يمكن التحقق منه لاحقًا بـ myokf validate. أثر جانبي: هذه الخطوة تكتب ملفات على القرص والتحويل يتم بمحرك محلي. أكّد أولًا موضع مجلد الإخراج. ما لا تغطيه الأدلة: هل استدعاء أداة MCP المسماة convert_to_okf ينجز التحويل نفسه، وسلوك الخطأ المحدد عند الفشل.
حدود الاستخدام
- لا تحرّر README*.md مباشرة: هي ناتج توليدي. لتغيير المدخلات حرّر
data/catalog.yamlثم أعد التوليد؛ يشترط النص الرسمي أن تمر المدخلات بـawesome-okf validateوpytest قبل الإرسال. - وصول الشبكة/الملفات: التحويل يستخدم محركًا محليًا (extraction done by local engines only) ولا يجلب من الخارج. سلوك شبكة meta-server نفسه غير موصوف رسميًا؛ يُعلَّم بأنه مجهول.
- نقطة التأكيد: أي فعل يكتب ملفات (تحويل، توليد) يجب أن يؤكد مسار الوجهة أولًا. أدوات الاستعلام (search_catalog, list_catalog, get_catalog_entry, catalog_stats) تقرأ الكتالوج، لكن الأدلة لا تكفي لاستنتاج أمان مطلق «لا يكتب ملفات ولا ينفّذ أوامر»، وهذه الصفحة لا تجزم بذلك.
- بيئة التشغيل: CLI وMCP meta-server مكتوبتان ببايثون وتُثبَّتان عبر pipx؛ يلزم عميل يدعم MCP. النص الرسمي لا يعدد أي عملاء MCP مدعومون.
- غير مؤكد: نطاق اللغات الطبيعية المدعومة، وتفاصيل تسجيل كل عميل MCP، وإصدارات اعتماديات النظام غير واردة في النص الرسمي. راجع أحدث وثائق المستودع قبل الاستخدام.