باختصار: agency-agents هي أكبر مجموعة منسقة من شخصيات وكلاء الذكاء الاصطناعي على GitHub، حيث بلغ عدد نجومها 149,312 نجمة اعتبارًا من 1 سبتمبر 2026. يشحن المشروع أكثر من 300 ملف تعريف وكيل عبر حوالي 20 مجلدًا تصنيفيًا ويقوم بتثبيتها في Claude Code، Cursor، Codex، Gemini CLI، OpenCode، Windsurf، Aider، وعشرات الأدوات الأخرى بأمر واحد. ما تحصل عليه هو إطار عمل، وليس قدرة. تغير الشخصيات طريقة تعامل وكيلك مع المهمة؛ إنها لا تمنحه حقائق لا يملكها، ولا تبقى بعد انتهاء الجلسة.
هذا هو تعمق في أداة واحدة من مجموعتنا التي تضم خمس أدوات وكلاء ذكاء اصطناعي مفتوحة المصدر تستحق التثبيت في عام 2026.
يمتلك وكيل البرمجة الخاص بك شخصية واحدة: خبير عام متعاون. اطلب منه مراجعة تدفق المصادقة وستحصل على نصيحة معقولة ولكنها لا تُنسى. اطلب من مراجع أمني مزود بنموذج تهديد وقائمة تحقق، وستحصل على نتائج.
هذه الفجوة هي ما يملؤه agency-agents. بدأ الأمر كمنشور على Reddit حول تخصص الوكلاء وتطور ليصبح قائمة كبيرة بما يكفي لتسبب تثبيت كل منها في تعطيل أحد بيئات تشغيل الوكلاء الشهيرة على الأقل. هذا ما يوجد بالداخل بالفعل، وكيفية تثبيت الأجزاء التي تريدها، والشيئان اللذان لا يمكن لمكتبة الشخصيات فعلهما لك.
ما تقوم بتثبيته بالفعل
كل وكيل هو ملف ماركداون. ليس موجه نظام من سطر واحد، وليس مكونًا إضافيًا مع رمز. يحتوي الملف على هوية وشخصية، ومهمة أساسية، وعملية عمل، ومخرجات تقنية مع أمثلة، ومقاييس نجاح.
بإحصاء ملفات الماركداون في شجرة المستودع في 1 سبتمبر 2026، هناك 312 ملفًا عبر 20 مجلدًا تصنيفيًا على المستوى الأعلى، أو 306 ملفات بعد استبعاد دليل examples/. التوزيع منحاز نحو بناء الأشياء:
| القسم | ملفات الوكلاء |
|---|---|
| هندسة برمجيات | 59 |
| متخصص | 58 |
| تسويق | 36 |
| تطوير الألعاب | 21 |
| تكاملات | 18 |
| استراتيجية | 16 |
| نظم المعلومات الجغرافية | 13 |
| أمان | 12 |
| تصميم | 10 |
| مبيعات | 9 |
| اختبار | 9 |
| إعلام مدفوع | 7 |
| إدارة المشاريع | 7 |
| أكاديمي | 6 |
| الحوسبة المكانية | 6 |
| دعم فني | 6 |
| مالية | 5 |
| منتج | 5 |
| رعاية صحية | 3 |
تجدر الإشارة إلى أن ملف README للمستودع لا يزال يعلن عن "أكثر من 230 وكيل". هذا السطر قديم. نمت الشجرة لتتجاوز 300 وكيل.
قسم الهندسة هو المكان الذي سيبدأ فيه معظم المطورين، ومستوى التحديد أعلى مما تتوقعه من مجموعة موجهات. بجانب إدخالات "مطور الواجهة الأمامية" و"مهندس معماري للواجهة الخلفية" الواضحة، يوجد مهندس شبكات مخصص لـ Cisco IOS-XE و Juniper Junos و Palo Alto PAN-OS، ومهندس برمجيات مدمجة لـ ESP32 و STM32 و Nordic targets، وقائد استجابة للحوادث لإجراء تحقيقات ما بعد الحوادث والاستعداد للمكالمات الطارئة، ومهندس تأهيل قاعدة بيانات مكتوب لاستكشاف مستودع للقراءة فقط وذكر حقائق حوله بدلاً من اقتراح تغييرات.
هذا الأخير مثال جيد على أن النمط يعمل. شخصية للقراءة فقط مع تفويض صريح بعدم التعديل هي أداة مختلفة حقًا عن وكيلك الافتراضي، ولا تكلف شيئًا سوى ملف.
التثبيت دون إفساد إعداداتك
يشحن المستودع نصوص تحويل وتثبيت. يكتشف المسار التفاعلي ما قمت بتثبيته ويسألك عما تريده:
git clone https://github.com/msitarzewski/agency-agents.git
cd agency-agents
./scripts/install.sh
استهداف أداة معينة ومجموعة فرعية من الأقسام هو الافتراضي الأكثر صحة:
# كل شيء، في Claude Code
./scripts/install.sh --tool claude-code
# قسمان فقط
./scripts/install.sh --tool claude-code --division engineering,security
# وكلاء مسمون فقط
./scripts/install.sh --tool cursor --agent frontend-developer,ui-designer
# شاهد ما هو موجود قبل الالتزام
./scripts/install.sh --list teams
./scripts/install.sh --tool opencode --division engineering --dry-run
تشمل الأهداف المدعومة Claude Code، Cursor، Codex، Gemini CLI، OpenCode، GitHub Copilot، Windsurf، Aider، Kimi Code، Hermes، Antigravity، Osaurus، و Mistral Vibe. يوجد أيضًا تطبيق سطح مكتب أصلي على agencyagents.app لأنظمة macOS و Linux و Windows يتصفح القائمة، ويثبت بنقرة واحدة، ويحدث تلقائيًا، بالإضافة إلى Homebrew cask.
اقرأ هذا قبل تثبيت كل شيء. بيئة تشغيل OpenCode حاليًا تسجل حوالي 119 وكيلًا فقط وتتجاهل الباقي بصمت، وهو ما يوثقه المستودع مقابل خطأ في الإصدار الأعلى. تثبيت مجموعة فرعية باستخدام --division يبقيك تحت الحد، ويحذرك المثبت عندما يتجاوز التحديد هذا الحد. الاقتطاع الصامت هو أسوأ وضع فشل على الإطلاق، لأن الوكيل الذي أردته يكون مفقودًا ولا يخبرك أي شيء.
حتى خارج هذا الخطأ المحدد، فإن تثبيت 300 شخصية فكرة سيئة. القائمة التي لا تستطيع تذكرها هي قائمة لن تستخدمها. قم بتثبيت القسمين الذين تعمل فيهما، واقرأ أربعة أو خمسة من الملفات، واحذف تلك التي لا تتطابق مع طريقة عمل فريقك بالفعل.
ما تغيره الشخصية، وما لا تغيره
الشخصية هي إطار عمل. تحدد ما يبحث عنه الوكيل، والشكل الذي ينتجه، وما يعتبره منتهيًا. هذا أكثر قيمة مما يبدو، لأن جزءًا كبيرًا من مخرجات الوكيل السيئة ليس خطأ النموذج، بل هو أن النموذج يحسن للشكل الخاطئ للإجابة.
ما لا تستطيع الشخصية فعله هو توفير معلومات لا يملكها النموذج. هذا هو الحد الذي يكتشفه الناس بعد أسبوع، ويظهر بوضوح أكبر حول واجهات برمجة التطبيقات.
قم بتحميل "مهندس الواجهة الخلفية" واطلب منه كتابة عميل لخدمة الفوترة الداخلية الخاصة بك. سينتج رمزًا نظيفًا ومعتادًا مقابل شكل استجابة ابتكره. ليس لديه طريقة لمعرفة أن خدمتك ترجع رمز 409 مع مظروف خطأ مختلف عندما يتكرر مفتاح الاستمرارية، أو أن مؤشر الترقيم غير شفاف بدلاً من أن يكون إزاحة. لقد جعلت الشخصية الرمز أكثر تنظيمًا. لم تجعله صحيحًا.
ينطبق نفس الحد على قسم الاختبار. تكتب شخصية ضمان الجودة اختبارات شاملة ضد نموذجها الذهني الخاص بواجهة برمجة التطبيقات، لذا فإن الاختبارات تمر ولا تثبت شيئًا. لقد تناولنا لماذا هذه الحلقة المحددة خطيرة في اختبار وكلاء الذكاء الاصطناعي غير الحتميين، وما الذي يتعطل عندما تتغير الواجهة الحقيقية في ما يحدث عندما تؤدي تغييرات واجهة برمجة التطبيقات إلى تعطيل وكلاء الذكاء الاصطناعي.
الحل هو إعطاء الوكيل العقد بدلاً من الأمل في أن تعوضه الشخصية. إذا كانت واجهة برمجة التطبيقات الخاصة بك مصممة في Apidog، فإن مواصفات OpenAPI هي مصدر الحقيقة: مخططات حقيقية، رموز حالة حقيقية، مظاريف أخطاء حقيقية. يقرأها الوكيل بدلاً من إعادة بنائها من مواقع الاستدعاء. يتم إنشاء المحاكيات من نفس المواصفات، بما في ذلك فروع الأخطاء التي لن تفكر الشخصية أبدًا في تزويرها، ويفشل جناح الاختبار بصوت عالٍ في CI عندما يختلف الواقع والمواصفات.
هذا الاقتران هو النموذج العقلي المفيد. الشخصية تقرر كيف يعمل الوكيل. المواصفات تقرر ما هو صحيح. قراءة ذات صلة: استخدام مواصفات OpenAPI كأدوات للوكيل و تصميم مخططات أدوات API للوكلاء. إذا كنت ترغب في ربط مواصفات حية بسياق وكيلك، قم بتنزيل Apidog ووجهه إلى مشروعك الحالي.
الحد الثاني: الشخصية ليست فريقًا
إليك الشيء الذي يعد به استعارة القائمة ولا يقدمه.
الفكرة هي وكالة كاملة في متناول يدك. عمليًا، تقوم بتنشيط شخصية واحدة في جلسة واحدة، وتقوم بمهمة، وتنتهي الجلسة. غدًا، تكتب التنشيط مرة أخرى. لا يوجد فريق، لأنه لا يوجد شيء مستمر: لا يوجد تعيين، ولا سجل لما وجده المراجع الأمني يوم الثلاثاء الماضي، ولا طريقة لزميل لرؤية أي من ذلك. تسعة من الأقسام في هذا المستودع تصف أدوارًا لا معنى لها إلا داخل منظمة، والأداة التي تقوم بتثبيتها لا تملك مفهومًا للمنظمة.
إذا كنت تريد أن تستمر فكرة القائمة بعد جلسة طرفية واحدة، فإن الطبقة المفقودة هي إدارة العمل. تم بناء Sharkly لهذا الغرض بالضبط، والربط مع agency-agents قريب بما يكفي ليتم توضيحه.
- الوكيل في Sharkly هو تكوين محفوظ، وليس موجهًا تعيد كتابته. يحتوي على التعليمات، وقت التشغيل، المهارات، المستودعات، والبيئة. يتم إعادة استخدام الشخصية التي قمت بضبطها مرة واحدة، وهي النسخة الدائمة لما يسعى إليه ملف
.mdفي~/.claude/agents/. - الطاقم (Crew) هو وكيل قائد بالإضافة إلى وكلاء وأشخاص آخرين. هذا هو مفهوم القسم بآليات فعلية. تعمل الطواقم بقيادة القائد أولاً: يقرأ القائد سياق المهمة، ويقرر الأعضاء الذين يجب إشراكهم، ويجمع نتائجهم في مكان واحد، بدلاً من أن يبدأ كل متخصص في وقت واحد ويتسابق.
- يتم تعيين العمل، وليس استدعاؤه. تعطي مهمة لوكيل كما تعطيها لزميل في الفريق. تعيش في مساحة، مشروع، وعجلة عمل، مع مزامنة Jira إذا كان فريقك يعمل هناك بالفعل بالفعل.
- التنفيذ يتم بواسطة "أحضر ما تملكه". تقوم بتوصيل جهاز كمبيوتر (Computer)، والذي يمكن أن يكون جهاز الكمبيوتر المحمول الخاص بك، خادمًا، أو حاوية، ويستخدم Sharkly بيئة التشغيل المثبتة عليه بالفعل. يقوم اشتراكك في Claude Code أو Codex بالعمل؛ لا يوجد من يعيد بيعك الرموز المميزة.
- الناتج قابل للمراجعة. يتم بث التقدم، استدعاءات الأدوات، والنتائج مرة أخرى إلى المهمة، ويهبط إخراج الوكيل كتعليقات يمكنك الرد عليها. لا تبدأ مهمة في قائمة المهام (Backlog) تشغيلًا، لذا يمكنك إعداد العمل قبل تنفيذ أي شيء.
ببساطة: يمنحك agency-agents الوصف الوظيفي، ويمنحك Sharkly المكان الذي يتم فيه تعيين هذه الوظائف وتشغيلها ومراجعتها. استخدم المستودع كمكتبة لتعريفات الأدوار لتغذية الوكلاء الحقيقيين بدلاً من كونه مجلدًا تقوم بتثبيته وتنساه.
كتابة شخصيتك الخاصة، باستخدام قالبهم
الشيء الأكثر ديمومة الذي يمنحك إياه هذا المستودع هو التنسيق. بمجرد قراءة عدد قليل من الملفات، يستغرق كتابة شخصية لمجموعتك الخاصة حوالي خمس عشرة دقيقة، ونسخة خاصة بالشركة تتفوق على النسخة العامة في كل مرة.
الهيكل الذي يتكرر عبر الملفات الجيدة:
- الهوية والصوت. من هو هذا الوكيل وكيف يتحدث. يبدو تجميليًا، وهو الجزء الذي يمنع الوكيل من العودة إلى وضع المساعد العام في منتصف مهمة طويلة.
- المهمة الأساسية. جملة واحدة حول معنى النجاح. ملف "مهندس تأهيل قاعدة البيانات" هو مثال واضح: استكشف للقراءة فقط، وتتبع مسارات الكود، واذكر حقائق حول الهيكل والسلوك، ولا تقترح أي شيء.
- عملية العمل. خطوات مرتبة يتبعها الوكيل. هذا هو القسم الذي يستحق السرقة. شخصية مراجعة ذات عملية من سبع خطوات تنتج مخرجات متسقة عبر الجلسات؛ شخصية بدونها تنتج ما يشعر به النموذج في ذلك اليوم.
- المخرجات. القطع الأثرية الملموسة، مع التنسيق. قل "جدول ماركداون للنتائج مع الخطورة، مسار الملف، ورقم السطر" بدلاً من "تقرير".
- مقاييس النجاح. كيف يعرف الوكيل أنه انتهى، وهو ما يعمل أيضًا كشيء تتحقق منه مقابل عمله.
نسخة داخلية لعمل API قد تبدو هكذا:
# مراجع عقود API
## المهمة
التحقق من أن نقاط النهاية الجديدة أو المتغيرة تتطابق مع مواصفات OpenAPI في هذا
المستودع قبل أن تصل إلى المراجعة. الإبلاغ عن عدم التطابق. عدم تحرير الكود.
## العملية
1. قراءة المواصفات لكل نقطة نهاية تم لمسها بواسطة التغيير الحالي (diff).
2. لكل منها، مقارنة المعالج بالمواصفات: رموز الحالة،
مخطط الاستجابة، مغلف الخطأ، الرؤوس المطلوبة، نمط الترقيم.
3. تشغيل اختبارات العقد. تسجيل الفشل حرفيًا.
4. التحقق من إضافة نقاط النهاية الجديدة إلى المواصفات، وليس فقط إلى الموجه.
5. الإشارة إلى أي حقل استجابة موجود في الكود وغير موجود في المواصفات.
## المخرجات
جدول: نقطة النهاية، الطريقة، نوع عدم التطابق، سطر المواصفات، سطر الكود، الخطورة.
لا يوجد ملخص نصي. لا يوجد إصلاحات مقترحة إلا إذا طُلب ذلك.
## الانتهاء عند
ظهور كل نقطة نهاية في التغيير (diff) في الجدول مع حكم، و
تضمين مخرجات اختبار العقد كدليل.
هذا الملف قصير، ويفعل الكثير لفريق الواجهة الخلفية أكثر من أي من الشخصيات الهندسية الـ 59 المشحونة في المستودع، لأنه يسمي مواصفاتك، واختباراتك، وتعريفك للانتهاء. الخطوة الثالثة هي الجزء المهم: يتم توجيه الشخصية لإنتاج دليل بدلاً من رأي، وهذا هو الفرق بين مراجعة يمكنك التصرف بناءً عليها وفقرة طمأنة.
نفس الحيلة تعمل للاستجابة للحوادث، أعمال الترحيل، ترقيات التبعيات، والتأهيل. خذ هيكل الملف، وحافظ على انضباط العملية، واستبدل المحتوى العام بمحتواك الخاص. عندما يجب أن يستمر إخراج الوكيل بعد التسليم إلى إنسان أو وكيل آخر، يقوم عقد التنسيق بمعظم العمل، وهي النقطة التي أوضحناها في تسليم الوكيل وتمرير السياق.
هل أعداد النجوم ذات مغزى هنا؟
149,312 نجمة عدد كبير، وتستحق تحذيرًا. تجمع مستودعات الشخصيات النجوم أسرع من أي فئة أخرى تقريبًا لأنها سهلة الفهم، وسهلة المشاركة، ولا تكلف شيئًا لتجربتها. تعني النجمة أن شخصًا ما اعتقد أن هذه فكرة جيدة، وليس أنه لا يزال يستخدمها.
ما يجعل هذا المستودع ذا مصداقية هو شكل العمل بدلاً من العدد. لديه تاريخ مساهمات حقيقي منذ أكتوبر 2025، وهو مرخص برخصة MIT، ويوثق حدوده الخاصة بما في ذلك سقف تسجيل OpenCode، وتحمل ملفات الوكلاء محتوى نطاقيًا محددًا بدلاً من محتوى دوري عام. قارن ذلك بالعديد من مستودعات "أفضل الموجهات" التي بلغت ذروتها وتوقفت.
احكم عليه بفتح ثلاثة ملفات في قسم تعرفه جيدًا. إذا كان ملف "مطور الواجهة الأمامية" يقول أشياء قد يقولها مطور واجهة أمامية جيد، فمن المحتمل أن يكون الباقي على ما يرام. إذا بدا وكأنه إعلان وظيفي، فتخط المستودع.
كيفية الحصول على قيمة حقيقية منه
سير عمل ثابت وموثوق:
- قم بتثبيت قسم واحد. اختر القسم الذي يتناسب مع عملك اليومي. الهندسة لمعظم القراء.
- اقرأ الملفات. أربعة أو خمسة، من البداية إلى النهاية. أنت تبحث عن أقسام العملية، وهي الجزء الذي يستحق الاحتفاظ به.
- عدلها. أضف مكدسك، اتفاقياتك، تعريفك للانتهاء. الشخصية التي تصف متجر React عام أقل قيمة من نفس الملف الذي يحتوي على قواعد الاختبار الخاصة بك.
- أعط الشخصيات المعدلة مدخلات حقيقية. المراجع الأمني مع مواصفات OpenAPI الخاصة بك يجد مشاكل في العقد. نفس المراجع بدونها ينتج قائمة تحقق.
- روّج للشخصيات التي تستمر. أي شخصية تلجأ إليها مرتين في الأسبوع يجب أن تصبح وكيلًا محفوظًا في نظام إدارة العمل بدلاً من أن تكون ملفًا تنسخه بين الأجهزة.
هذه الخطوة الأخيرة هي حيث تقوم الفرق إما بتوسيع هذا أو التخلي عنه بهدوء.
الأسئلة الشائعة
هل يعمل agency-agents مع Cursor و Codex، أم فقط Claude Code؟ مع كل هذه الأدوات. يقوم النص البرمجي convert.sh بإنشاء ملفات تكامل لكل أداة و install.sh --tool يستهدف أداة معينة. يتم دعم Claude Code، Cursor، Codex، Gemini CLI، OpenCode، Copilot، Windsurf، Aider، Kimi Code، والعديد من الأدوات الأخرى. إذا كنت تقارن عملاء الوكلاء لعمل API، انظر نظرتنا على عملاء API في Cursor و Copilot.
هل يجب أن أثبت جميع الوكلاء الـ 300؟ لا. في OpenCode لا يمكنك ذلك، لأن بيئة التشغيل تسجل حوالي 119 وكيلًا فقط وتتجاهل الباقي بصمت. في الأدوات الأخرى يمكنك تقنيًا، ولن تستخدم معظمها أبدًا. ثبّت حسب القسم.
هل تجعل الشخصيات الوكيل أذكى؟ تجعله موجهًا بشكل أفضل. الدقة في مسائل الحقائق، بما في ذلك ما ترجعه واجهة برمجة التطبيقات الخاصة بك، لا تتغير. يتطلب ذلك مواصفات حقيقية، وهذا هو الحجة في هل ما زلت بحاجة إلى أداة API في عصر وكلاء الذكاء الاصطناعي.
هل من الآمن تشغيل نص التثبيت البرمجي؟ يقوم بكتابة ملفات تعريف الوكيل في أدلة تكوين أداتك. هذا هو غرضه. إنه مرخص برخصة MIT مع توفر المصدر الكامل، و --dry-run يوضح لك ما سيفعله قبل أن يفعله. قم بتشغيل التجربة الجافة أولاً. المبدأ العام لما تسمح للوكلاء بلمسه موجود في حواجز أمان وكلاء الذكاء الاصطناعي.
ما الفرق بين هذا وإطار عمل الوكيل؟ إذا كنت تريد تشغيل الشخصيات عدة مرات في نفس الوقت بدلاً من واحدة لكل جلسة، فهذا هو Orca. يمنحك إطار عمل مثل Strands أو AgentKit تنسيق وقت التشغيل في الكود. يمنحك agency-agents ملفات ماركداون تغير سلوك وكيل موجود. طبقة مختلفة، لا يوجد تداخل.
خاتمة
agency-agents هو أفضل إصدار لفكرة محددة: يعمل وكيلك بشكل أفضل عندما يعرف الدور الذي يلعبه. قم بتثبيت قسم، واقرأ الملفات، وعدلها لتتناسب مع فريقك، وستحصل على قيمة حقيقية في حوالي عشرين دقيقة من الإعداد.
ثم كن صريحًا بشأن الشيئين اللذين لا يحلهما. لا تعرف الشخصيات ما ترجعه واجهة برمجة التطبيقات الخاصة بك، وهذا هو الغرض من Apidog، ولا تستمر في أي شيء يمكن للفريق رؤيته أو مراجعته، وهذا هو الغرض من Sharkly. القائمة بداية جيدة. إنها ليست منظمة، وليست مصدرًا للحقيقة.