MuseAI-Skills o‘qish qo‘llanmasi: Muse AI ko‘nikmalari, ruxsatlar va Agent ish jarayonlarini tahlil qilish

Loyiha nima

MuseAI-Skills — muse.ai bilan bog‘liq Muse / Hatch shaxsiy AI Agent muhiti snapshot nusxasi. Repozitoriyda mahsulot tavsiflari, skill ta’riflari, konnektor ruxsatlari ro‘yxati, xatti-harakatlarni baholash ssenariylari, Linux ishga tushirish skriptlari hamda paket tarkibidagi ayrim dasturlar va bog‘liqliklar saqlangan.

Muhim chegara: bu to‘liq manba kodi repozitoriysi ham, bir bosishda o‘rnatiladigan paket ham emas. Asosiy dasturlar asosan Linux x86-64 ELF ikkilik fayllari ko‘rinishida taqdim etilgan, qurilish manba kodi, to‘liq host konfiguratsiyasi, rootfs va ayrim ishga tushirish resurslari esa kiritilmagan.

Shu sababli ushbu repozitoriydan statik o‘rganish, Agent workflow’larini tadqiq qilish, ruxsatlar modelini tahlil qilish va ko‘rsatmalar dizayni uchun ma’lumotnoma sifatida foydalanish eng ma’qul; u Muse AI xizmatini to‘g‘ridan-to‘g‘ri o‘rnatish uchun mo‘ljallanmagan. Repozitoriy materiallarida Muse, Hatch va Jarvis kabi nomlar ishlatilgan, biroq arxivning o‘zi rasmiy nashr, tasdiq yoki manba autentifikatsiyasini anglatmaydi.

Repozitoriydan nimalarni o‘rganish mumkin

Skill workflow’larining to‘liq tuzilishi

Repozitoriyda 72 ta SKILL.md yo‘li mavjud: ulardan 68 tasi mustaqil skill fayli, 4 tasi esa symbolic link taxallusidir. Skill’lar Agent workflow’lari, hujjat mahsulotlari, sayohat bronlari, ofis vositalari, ijtimoiy platformalar, sog‘liq ma’lumotlari, media yaratish, qurilmalarni boshqarish va Muse mahsulotlari bilan ishlash kabi sohalarni qamrab oladi.

Ushbu skill hujjatlari odatda quyidagi savollarni o‘rganishga yordam beradi:

• Qaysi foydalanuvchi so‘rovi skill’ni ishga tushirishi kerak.
• Vazifani koordinator, worker yoki tashqi konnektor bajarishi kerakmi.
• Bajarishdan oldin qaysi hisob ulanishlari, OAuth scope’lari yoki foydalanuvchi ruxsatlari kerak.
• Vosita ishlamasa, kirish ma’lumotlari to‘liq bo‘lmasa yoki ruxsat yetarli bo‘lmasa, qanday zaxira yo‘lga o‘tiladi.
• Natija formatini qanday belgilash va yakuniy mahsulotni qanday tekshirish kerak.

Ruxsatlar va baholash materiallari

Repozitoriyda yana 40 ta manifest yo‘li va 12 ta eval YAML fayli mavjud. manifest.yaml konnektor metama’lumotlari, standart ruxsatlar, scope talablari va buyruqlar mosligini tushunish uchun ishlatiladi; eval/scenarios.yaml esa xatti-harakatlarni baholash ssenariylari, foydalanuvchi maqsadlari va kutilgan xatti-harakatlarni qayd etadi.

Eslatma: manifest mavjudligi hisob allaqachon ulanganini, baholash ssenariysi mavjudligi esa baholash bajarilgan yoki muvaffaqiyatli o‘tganini anglatmaydi.

Ishlash muhitining statik belgilari

opt/hatch/runtime-cell/ ichidagi skriptlar ish muhitining ayrim lifecycle bosqichlarini ko‘rsatadi: rootfs yo‘lini aniqlash, ishga tushirishdan oldingi tayyorgarlik, kernel modullarini tekshirish, systemd-nspawn konteynerini ishga tushirish hamda skill va ikkilik fayl overlay’larini yig‘ish. Biroq to‘liq host unit’lari, nspawn konfiguratsiyasi va haqiqiy rootfs repozitoriyda mavjud emas.

目录结构概览

• README.md: xitoycha kirish sahifasi, skill katalogi va chegaralar tavsifi.
• README.en.md: inglizcha kirish sahifasi.
• PROJECT_ANALYSIS.md: arxitektura xulosalari, yetishmayotgan komponentlar, xavflar va dalillar indeksi.
• SHA256SUMS: oddiy fayllar uchun kontent checksum ro‘yxati, ammo manba imzosi emas.
• home/hatch/docs/: mahsulot, konnektor, maxfiylik, rejalashtirish, fayl, qurilma va media tavsiflari.
• home/hatch/config/: Agent va skill holatiga oid konfiguratsiyalar.
• opt/hatch/skills/: skill kirish fayllari, ruxsat manifestlari, baholash ssenariylari va ma’lumotnomalar.
• opt/hatch/runtime-cell/: ish muhitining lifecycle skriptlari va konfiguratsiya shablonlari.
• opt/hatch/bin/: Hatch bilan bog‘liq dasturlar.
• opt/hatch-image/: image tomonidagi vositalar, npm, Bun va paket tarkibidagi boshqa komponentlar.

Repozitoriy ildiz katalogi faqat arxiv ildizidir, ishlayotgan Linux ildiz katalogi emas. Arxivdagi home/hatch/ asl muhitdagi /home/hatch ga mos keladi, hujjatlardagi /run, /var/lib va /etc esa odatda mavjud bo‘lmagan runtime fayl tizimiga ishora qiladi.

Repozitoriyni olish va tayyorlash

Birinchi variant: faqat skill va hujjatlarni o‘rganish

Maqsad Markdown, YAML va Shell skriptlarini tahlil qilish bo‘lsa, hajmi katta Git LFS ikkilik fayllarini olishni o‘tkazib yuborish mumkin. Bu o‘rganish uchun eng tavsiya etiladigan usuldir.

GIT_LFS_SKIP_SMUDGE=1 git clone https://github.com/win4r/MuseAI-Skills.git
cd MuseAI-Skills

Bu usul paket tarkibidagi dasturlarni bajarishni talab qilmaydi. Repozitoriyga kirgach, avval PROJECT_ANALYSIS.md va opt/hatch/skills/ ni oching.

Ikkinchi variant: to‘liq arxiv obyektlarini ko‘rish

Faqat LFS ichidagi ELF dasturlari yoki boshqa katta fayllarni tekshirish zarur bo‘lgandagina Git LFS’ni o‘rnatib, tegishli obyektlarni olish kerak. Ikkilik fayllarni yuklab olish yetishmayotgan manba kodi, rootfs, credential yoki host konfiguratsiyasini to‘ldirmaydi va repozitoriyni deploy qilinadigan tizimga aylantirmaydi.

git clone https://github.com/win4r/MuseAI-Skills.git
cd MuseAI-Skills
git lfs pull

Manbasi mustaqil tasdiqlanmagan ikkilik fayllar uchun avval offline statik tekshiruv o‘tkazing; ularni ishlab chiqarish mashinasida yoki maxfiy credential’lar mavjud muhitda bevosita ishga tushirmang.

Oddiy fayllarni tekshirish

Tegishli fayllar to‘liq olingach, kontent yaxlitligini tekshirish uchun repozitoriy taqdim etgan SHA256SUMS dan foydalanish mumkin:

sha256sum -c SHA256SUMS

Checksum ro‘yxati ro‘yxat faylining o‘zini va symbolic link’larni qamrab olmaydi; u nashriyotchi shaxsi yoki manba haqiqiyligining kriptografik imzosi ham emas. U faqat mahalliy oddiy fayllar ro‘yxatda qayd etilgan digest’lar bilan mos kelishini aniqlashga yordam beradi.

Asosiy foydalanish: skill o‘qish jarayonini tuzish

Birinchi qadam: skill kirish faylini tanlash

Dastlabki o‘rganishni quyidagi skill’lardan boshlash mumkin:

• wide-research: tadqiqot koordinatori, worker, yagona chiqish shartnomasi va xatolarni qamrab olishni o‘rganish.
• skill-creator: skill’ni ishga tushirish tavsifi, katalogni ajratish va ma’lumotnomalarni talabga ko‘ra yuklash.
• artifacts/testing: “muvaffaqiyatli yaratildi” va “mahsulotdan foydalanish mumkin” tushunchalarini farqlash.
• goals: maqsadni birinchi marta belgilash va keyingi kuzatuvni farqlash.
• forget: nusxalar, hosilaviy holat va qayta yozilishi mumkin bo‘lgan ma’lumotlarni boshqarish.
• travel-planning: marshrutni o‘rganish, real vaqtdagi qidiruv va tranzaksiyani bajarishni ajratish.
• gmail: skill matni, metod darajasidagi ruxsatlar va baholash ssenariylari asosida konnektorni tahlil qilish.

Masalan, Gmail skill kirish faylini ko‘rish:

sed -n '1,240p' opt/hatch/skills/gmail/SKILL.md

Ikkinchi qadam: trigger shartlari va chegaralarni ajratib olish

SKILL.md ni o‘qiyotganda faqat “u nima qila oladi” degan savol bilan cheklanmay, quyidagi savollarga ketma-ket javob bering:

1. Qaysi so‘rovlar ushbu skill’ni ishga tushirishi kerak?
2. Qaysi o‘xshash so‘rovlar uni ishga tushirmasligi kerak?
3. Faqat o‘qish va yozish amallari qanday farqlanadi?
4. Yuborish, o‘chirish, xarid qilish yoki bronlash kabi yuqori ta’sirli amallar tasdiqni talab qiladimi?
5. Ruxsat yetarli bo‘lmasa, maqsad noaniq bo‘lsa yoki vosita ishlamasa, qanday yo‘l tutiladi?
6. Yakuniy natijada qaysi maydonlar yoki dalillar qaytarilishi kerak?

Ushbu mazmunni “trigger, kirish, avtorizatsiya, bajarish, xato, qabul qilish” nomli oltita qismga ajrating. Bu uni o‘z Agent dizayningizga ko‘chirishni osonlashtiradi.

Uchinchi qadam: ruxsat manifesti bilan taqqoslash

Konnektor skill’lari uchun shu katalogdagi manifest.yaml faylini ham o‘qing:

sed -n '1,260p' opt/hatch/skills/gmail/manifest.yaml

Skill matnida aytilgan amallarni manifest’da ko‘rsatilgan metod ruxsatlari, guruh standartlari, scope’lar va buyruqlar mosligi bilan solishtirishga e’tibor qarating. Metod darajasidagi sozlamalar guruh standartlarini bekor qilishi mumkin, shuning uchun faqat yuqori darajadagi ruxsat tavsifini ko‘rish yetarli emas.

SKILL.md faylini boshqa Agent muhitiga nusxalash Gmail, Google Drive, Notion yoki boshqa xizmatlarga kirish huquqini avtomatik bermaydi. Amalda bajarish tegishli CLI yoki MCP, hisob ulanishi, OAuth scope’lari va runtime avtorizatsiyasiga bog‘liq.

To‘rtinchi qadam: baholash ssenariylarini o‘qish

Agar skill tarkibida eval/scenarios.yaml bo‘lsa, qoidalar test qilinadigan xatti-harakatlarga qanday aylantirilganini ko‘rishingiz mumkin:

sed -n '1,260p' opt/hatch/skills/gmail/eval/scenarios.yaml

Baholash ssenariylari quyidagi xatti-harakatlarni tekshirish uchun mos:

• Agent to‘g‘ri skill’ni tanladimi.
• O‘qish, draft yaratish, yuborish va o‘chirish kabi turli xavf darajalarini farqladimi.
• Ma’lumot yetarli bo‘lmaganda qabul qiluvchi yoki amal maqsadini taxmin qilish o‘rniga avval aniqlik kiritdimi.
• Zarur bo‘lganda avtorizatsiya yoki tasdiq so‘radimi.
• Xatodan so‘ng bajarilmagan ishlarni halol xabar qildimi.

Ssenariy faylini testdan o‘tganlik hisoboti deb qabul qilmang. Avvalgi muammolarni aniqlash uchun opt/hatch/skills/flightaware/eval/findings.md kabi topilmalar qaydlarini ham ko‘rish mumkin, bunda ularning versiyasi va test muhiti hisobga olinishi kerak.

Beshinchi qadam: qo‘shimcha ma’lumotnomalarni tekshirish

Ayrim skill’lar batafsil qoidalarni references/, guide/, creation/ yoki guides/ kataloglariga ajratadi. Bu muhim dizayn tamoyilini ko‘rsatadi: asosiy skill fayli ixcham saqlanadi va aniqroq ma’lumotnomalar faqat vazifa talab qilganda yuklanadi.

Masalan, skill yozish usullarini quyidagi fayldan boshlash mumkin:

sed -n '1,260p' opt/hatch/skills/skill-creator/references/authoring_guide.md

Amaliy misol: Gmail skill’ini tahlil qilish

Gmail skill dizaynini amalda pochta qutisini ulmasdan yoki undan foydalanmasdan qayd etish uchun quyidagi shablondan foydalanish mumkin:

Skill kirish fayli: opt/hatch/skills/gmail/SKILL.md
Ruxsat ta’rifi: opt/hatch/skills/gmail/manifest.yaml
Baholash ssenariysi: opt/hatch/skills/gmail/eval/scenarios.yaml

Tahlil yo‘nalishlari:
1. Elektron xatlarni qidirish va o‘qish trigger shartlari
2. Draft yaratish, yuborish va javob berish chegaralari
3. Yorliqlar va obunani bekor qilish jarayoni
4. Metod darajasidagi ruxsatlar va OAuth scope’lari
5. Qabul qiluvchi, xat tarmog‘i yoki amal maqsadi noaniq bo‘lganda ko‘riladigan choralar
6. Vosita ishlamagandan keyingi hisobot usuli
7. Foydalanuvchi yakunda olishi kerak bo‘lgan natija va tekshiruv ma’lumotlari

Yakunlangach, natijani o‘z Agent spetsifikatsiyangizga aylantirishingiz mumkin:

• Trigger qoidalari: qaysi til naqshlari pochta skill’iga olib kirishini aniq belgilang.
• Faqat o‘qishga ustuvorlik: qidirish va o‘qishni yuborish, o‘chirish kabi o‘zgartiruvchi amallardan alohida bajaring.
• Avtorizatsiya chegarasi: tasdiqlash va OAuth qoidalarini maqsadli ish muhitiga moslab qayta belgilang.
• Chiqish shartnomasi: muvaffaqiyat, qisman muvaffaqiyat va xato holatlarida nimalar qaytarilishini belgilang.
• Qabul qilish ssenariylari: odatiy so‘rov, noaniq so‘rov, ruxsat yetishmasligi va konnektor nosozligi testlarini qo‘shing.

Mahsulot va tizim arxitekturasini o‘rganish

Mahsulot shartnomasini tez tushunish

Quyidagi tartibda o‘qish tavsiya etiladi:

1. home/hatch/docs/muse.md: mahsulot haqida umumiy ma’lumot.
2. home/hatch/docs/goals.md: maqsadlar, jarayon va fon vazifalarining chegaralari.
3. home/hatch/docs/scheduling-and-watching.md: so‘rov yuborish, rejalashtirish, ishga tushirish tarixi va bildirishnomalar.
4. home/hatch/docs/self_improvement.md: fon xotirasi, tadqiqot, ko‘rib chiqish va dalillarni kuzatish.
5. home/hatch/docs/connectors.md: ulanish holati, OAuth, metod ruxsatlari va xatolarni qayta ishlash.
6. home/hatch/docs/privacy-and-credentials.md: hisob ma’lumotlariga havolalar, Vault, eksport va o‘chirish qoidalari.

Bu fayllarda snapshotdagi mahsulot shartnomalari tasvirlangan. Hisobga xos imkoniyatlar va tarixiy mavjudlik haqidagi ma’lumotlarni barcha Muse hisoblarida hozir mavjud bo‘lgan fakt sifatida qabul qilmaslik kerak.

Tadqiqot ishga tushirish zanjiri

Agar Linux izolyatsiya muhitiga qiziqsangiz, quyidagi skriptlar asosida chaqiruvlar bog‘lanishini tuzishingiz mumkin:

opt/hatch/runtime-cell/pre-start.sh
opt/hatch/runtime-cell/ensure-rootfs.sh
opt/hatch/runtime-cell/resolve-rootfs-path.sh
opt/hatch/runtime-cell/require-modules.sh
opt/hatch/runtime-cell/launch-daemon.sh
opt/hatch/runtime-cell/post-start.sh

resolve-rootfs-path.sh qaytaradigan /var/lib/hatch-runtime/rootfs asl ishga tushirish muhitidagi yo‘l bo‘lib, repository tarkibidagi katalog emas. launch-daemon.sh systemd-nspawn konteynerini ishga tushiradi va overlay’ni yig‘adi; u yetishmayotgan host konfiguratsiyasi va rootfs’dan mustaqil holda ishga tushirish bo‘yicha to‘liq qo‘llanma bo‘la olmaydi.

Ilg‘or tahlil usullari

Ko‘nikmalar, taxalluslar va resurs kataloglarini farqlash

Repositoryda 4 ta ramziy havola taxallusi mavjud: facebook facebook-cliga, meta-threads threadsga, podcast generate_podcastga, voice-calls esa voice-selectorga yo‘naltirilgan.

Takroriy hisoblashning oldini olish uchun havolalarning haqiqiy manzilini tekshiring:

find opt/hatch/skills -type l -name SKILL.md -print -exec readlink {} \;

Ayniqsa, voice-calls nomiga qarab unda Agent nomidan telefon qo‘ng‘iroqlarini amalga oshirish imkoniyati bor, degan xulosaga kelmaslik kerak; bu kirish nuqtasi aslida statik ovoz katalogiga yo‘naltirilgan. spaces ishga tushirish muhiti hujjatlari va shablonlarini o‘z ichiga oladi, ammo yuqori darajada joylashgan SKILL.md fayliga ega emas. Shu sababli uni alohida ko‘nikma sifatida hisoblamaslik kerak.

Bayonotlar, ruxsatlar va bajariladigan bog‘liqliklarni birgalikda tekshirish

Biror ko‘nikmani tahlil qilishda uch bosqichli tekshiruv usulidan foydalanish mumkin:

1. Xulq-atvor darajasi: SKILL.mdda ko‘rsatilgan ishga tushirish shartlari, chegaralar va chiqish natijalarini tekshirish.
2. Ruxsatlar darajasi: manifestdagi metodlar, scope’lar va standart ruxsatlarni tekshirish.
3. Bajarilish darajasi: zarur CLI, MCP, yordamchi dasturlar, hisob ulanishlari va ishga tushirish muhiti resurslari mavjudligini tasdiqlash.

Repositoryda ayrim muhim bog‘liqliklar, jumladan Artifacts tekshiruv skriptlari, skill-creator ulanishlagichi karkasi, Magic Moment’ning mm bajariladigan dasturi, shuningdek Spaces talab qiladigan ayrim SDK va qurish resurslari aniq yetishmasligi ko‘rsatilgan. Shuning uchun “hujjatni o‘qish mumkin” degani “bajarilish zanjiri to‘liq” degani emas.

Artefakt yaratish va artefaktni qabul qilishni ajratish

artifacts/testing umumiy Agent modeli sifatida o‘rganishga arziydi. U fayl yaratilgandan keyin artefakt turiga ko‘ra tekshirish, qayta renderlash, vizual qabul qilish va placeholderlarni skanerlash zarurligini ta’kidlaydi. Buni o‘z tizimingizga ko‘chirishda jarayonni quyidagicha ajratish mumkin:

1. Hujjat, jadval, PDF yoki taqdimot yaratish.
2. Yaratilgan natijani qayta ochish yoki renderlash.
3. Tuzilma, joylashuv, formulalar, havolalar va yetishmayotgan resurslarni tekshirish.
4. Almashtirilmagan placeholderlar va vaqtinchalik matnlarni qidirish.
5. Faylni faqat qabul tekshiruvidan o‘tgandan keyin topshirishga tayyor deb belgilash.

Ko‘p Agentli hamkorlikni o‘rganish

wide-research bir nechta kirish ma’lumotlari bilan parallel tadqiqotdagi muhim cheklovlarni ko‘rsatadi: koordinator va worker vazifalarini cheklash, chiqish maydonlarini birxillashtirish, qamrovni hisobot qilish va muvaffaqiyatsiz bandlarni saqlab qolish. Ko‘chirishda vosita nomlari va ish maydoni yo‘llarini o‘z orkestratsiya freymvorkingizga moslang, shu bilan birga yagona chiqish shartnomasi va xatolar ko‘rinib turishini saqlang.

Ma’lumotlar bazasini izlash o‘rniga uning tavsifini tekshirish

opt/hatch/skills/muse_db/references/schema.md cheklangan SQL qoidalari, identifikatorlar va bir nechta schema’dagi munosabatlarni tasvirlaydi. Undan ma’lumotlar modelini va jadvallararo kuzatish usullarini tushunish uchun foydalanish mumkin. Bu haqiqiy ma’lumotlar bazasi ham, migratsiya manba kodi ham emas; shu asosda to‘liq xizmatni tiklab bo‘lmaydi.

Manba, litsenziya va dalillar chegarasini saqlash

Ish jarayonlarini boshqa loyihalarga ko‘chirishda manba atributsiyasini saqlash va amaldagi litsenziyalarni tekshirish kerak. Ichki tahlil qaydlarida quyidagilarni ajratish tavsiya etiladi:

• Repository fayllarida bevosita bayon qilingan faktlar.
• Kataloglar, skriptlar yoki manifest asosida chiqarilgan texnik xulosalar.
• Hali tasdiqlanmagan mahsulot bayonotlari.
• Ishga tushirish muhiti yetishmagani sababli tasdiqlab bo‘lmaydigan xatti-harakatlar.

“Arxivda ko‘rinadi” degani “rasmiy manba tomonidan tasdiqlangan”, “mustaqil ishlay oladi” yoki “istalgancha qayta litsenziyalash mumkin” degani emas.

Tavsiya etiladigan o‘rganish yo‘li

1. Repositoryni klonlashda LFS’ni chetlab o‘ting, keraksiz ikkilik fayllarni yuklab olishdan saqlaning.
2. Arxitektura xulosalari va yetishmayotgan qismlarni tushunish uchun PROJECT_ANALYSIS.mdni o‘qing.
3. Ish jarayoni tuzilmasini o‘rganish uchun skill-creator yoki wide-researchni tanlang.
4. Ko‘nikma matni, manifest va eval’ni birgalikda tahlil qilish uchun gmailni tanlang.
5. Topshiriladigan materiallarni qabul qilish yondashuvini shakllantirish uchun artifacts/testingni o‘qing.
6. Ko‘nikma qoidalarini mahsulot shartnomalaridan ajratish uchun mahsulot hujjatlarini o‘qing.
7. Va nihoyat, ishga tushirish muhiti izlari va yetishmayotgan bog‘liqliklarni tushunish uchun runtime-cell skriptlarini tekshiring.

Xulosa

MuseAI-Skills’ning asosiy qiymati uni bevosita joriy etishda emas, balki shaxsiy AI Agent ko‘nikmalarni ishga tushirish, vazifalarni taqsimlash, ulanishlagich ruxsatlari, xatolarni qayta ishlash va natijalarni qabul qilishni qanday tashkil etishini ko‘rsatishidadir. SKILL.md, manifest.yaml, baholash ssenariylari va ishga tushirish bog‘liqliklarini birgalikda o‘qib, o‘z Agent tizimingizga mos dizayn namunalarini ajratib olishingiz mumkin. Shu bilan birga snapshotni to‘liq manba kodi yoki bajariladigan mahsulot deb xato qabul qilishdan saqlanasiz.