Multi-Agent Workflow • Handoff • Feedback Loop

Agent Teams.
فريق تقني حقيقي، مكتوب مسبقًا.

تربط AgentsRoom Teams وكلاء البرمجة بالذكاء الاصطناعي لديك مثل فريق هندسي حقيقي. وكيل Fullstack Dev يُسلّم الميزة، ووكيل QA Engineer يتحقق منها، ومدير المنتج (PM) يعتمدها. كل دور مكتوب مسبقًا، وسير العمل مرئي، وكل تسليم يحمل ملخص الميزة والـ diff والمخاطر وتلميحات الاختبار. لا مزيد من وكيل واحد يحاول فعل كل شيء بشكل سيئ.

ابنِ فريق تطوير الذكاء الاصطناعي الذي تحلم به على لوحة مرئية، تماماً مثل سير عمل n8n. روابط شرطية، حلقات تغذية راجعة، فروع مراجعة متوازية، بوابات جودة يتحقق منها الجهاز، حد أقصى للدورات. احفظه مرة، شغّله على كل تذكرة، وشاهد وكلاءك يتناقلون العصا كالمحترفين.

AgentsRoom Teams: محرر سير عمل مرئي متعدد الوكلاء، تسليم تلقائي بين وكلاء Claude Code، حلقة تغذية راجعة Dev إلى QA، تواصل بين الوكلاء عبر MCP.

Agent Teams هي إجابة AgentsRoom على حقيقة قاسية حول وكلاء البرمجة بالذكاء الاصطناعي: الوكيل الواحد الذي يحاول فعل كل شيء ينتهي به الأمر بفعل كل شيء بشكل سيئ. وكيل Fullstack الذي يبرمج ويختبر ويراجع وينشر ويكتب المواصفات في الوقت نفسه ينسى نصف تعليماته في المنتصف. الإجابة الصحيحة، تلك التي يستخدمها كل فريق برمجيات جاد في العالم، هي تقسيم العمل إلى أدوار. مطوّر يبرمج. مهندس QA يتحقق. مدير منتج يعتمد. مراجع أمني يدقّق. لكل دور سياقه الخاص، وتركيزه الخاص، وأدواته الخاصة.

هذا بالضبط ما تجلبه Agent Teams إلى AgentsRoom. تضع عقدًا على لوحة لانهائية (مبنية على React Flow، نفس المحرك الذي تستخدمه n8n وMake وRetool وPipedream)، كل عقدة هي وكيل Claude Code أو Codex أو OpenCode أو Antigravity CLI أو Aider أو Grok Build أو Mistral Vibe أو Kimi Code معيّن لدور محدد، ثم تربطها معًا. شغّل الفريق على تذكرة من الـ backlog، أو اربطه بأي وكيل جديد. ينسّق AgentsRoom السلسلة: يُطلق الوكيل الأول، ينتظر التسليم، يلخّص العمل، يُطلق الوكيل التالي مع هذا الملخص كسياق وارد، ويكرر العملية حتى يصل الفريق إلى عقدة النهاية.

تحاول أدوات أخرى فعل ذلك بوكيل خارق واحد ومطالبات ذكية. جرّبنا ذلك، لا يعمل بعد ثلاث خطوات. الأدوار تنحرف، السياق يضيع، الوكيل ينسى ما كان يُفترض به التحقق منه. تتعامل Agent Teams مع الوكلاء كزملاء فعليين: كل واحد يحصل على جلسة نظيفة، وموجّه نظام مركّز، وحمولة تسليم منظمة، وملاحظة مشتركة للتحدث مع الآخرين. هذا هو سير عمل فريق هندسة الذكاء الاصطناعي الذي تريده فعلًا.

محرر سير العمل المرئي لـ AgentsRoom Agent Teams: عقد لأدوار Dev وQA وPM وSecurity وDevOps متصلة على لوحة لانهائية مع حواف شرطية وحلقات تغذية راجعة

محرر AgentsRoom Teams: ضع عقدًا لكل دور، اربطها، أضف شروطًا، احفظ الفريق، شغّله على أي تذكرة.

تنسيق متعدد الوكلاء يتوسّع فعلًا

كل عقدة على اللوحة هي وكيل. تختار دوره (Fullstack، Frontend، Backend، QA، Security، DevOps، PM، Architect، Mobile، Marketing، Git، SEO، Localization، أو أي دور مخصص أنشأته)، ونموذجه (Opus، Sonnet، Haiku، GPT-5، o3، Antigravity Pro، إلخ)، وطريقة التسليم (تلقائي عبر Stop hook، أو يدوي عبر زر) وبضعة أسطر من تعليمات الخطوة. هذا كل شيء. لا حفلات هندسة موجّهات، ولا ملف YAML لكتابته.

الحواف تربط العقد. الحافة البسيطة تعني: عند انتهاء الوكيل الأول من خطوته، سلِّم إلى التالي. الحافة الشرطية تحمل فحص علم، مثلًا qaPassed تساوي true. وكيل QA يضبط هذا العلم في حمولة التسليم، ويختار المشغّل الحافة المطابقة. هكذا تبني حلقات التغذية الراجعة: ينتهي QA، qaPassed تساوي false، الحافة تعيد إلى Dev مع تلميحات الاختبار والمخاطر. يصلح Dev ويسلّم مرة أخرى. يستمر في الحلقة حتى ينجح QA أو حتى يتدخل حدّ الدورات الأقصى.

التواصل بين الوكلاء قوي بطبيعته. يأتي AgentsRoom بخادم MCP مخصص (agentsroom-team) يمنح كل وكيل في التشغيل مجموعة أدوات: قراءة سياق الفريق، قراءة الملاحظات المشتركة NOTES.md، نشر ملاحظة لزملاء الفريق، إرسال سؤال إلى دور آخر، قراءة صندوق الوارد، قراءة الجدول الزمني، قراءة git diff مقابل خط الأساس للتشغيل، وإكمال الخطوة بحمولة منظمة. تُعاد حقن هذه الأدوات في جلسة Claude في كل دورة، فتنجو من ضغط السياق. حتى بعد /compact أو /clear، لا يزال الوكيل يرى أدوات فريقه.

فوق ذلك، يذكّر hook من نوع UserPromptSubmit الوكيل بأي ملاحظات جديدة من الزملاء قبل كل رسالة مستخدم. ملف NOTES.md في مساحة العمل قابل للإلحاق فقط وينجو من الأعطال وإعادة التشغيل وإعادة تشغيل Mac. مخطط حمولة تسليم مُتحقق منه على الخادم يمنع الوكلاء من التسليم بحمولات فارغة أو غير صالحة. هذا هو الجزء الذي تتجاوزه معظم عروض الوكلاء المتعددين بصمت، والسبب وراء انهيار معظمها في الدورة الثالثة.

كل ما تحتاجه لإدارة فريق هندسي بالذكاء الاصطناعي

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

لوحة سير عمل مرئية

لوحة لانهائية قابلة للتكبير مدعومة بـ React Flow، نفس المحرك خلف n8n وRetool وPipedream وMake. ضع عقدًا، اربطها، احفظ الفريق. لا برمجة، لا YAML.

14 دورًا جاهزًا للوكلاء

Fullstack وFrontend وBackend وDevOps وQA وSecurity وPM وArchitect وMobile وMarketing وGit Expert وSEO وi18n. بالإضافة إلى أي دور مخصص حفظته على مشروعك.

نموذج وموجّه لكل عقدة

كل عقدة تختار مزوّدها ونموذجها وتعليمات خطوتها. استخدم Opus لـ Architect، وHaiku لـ QA، وCodex للـ backend الثقيل، وAntigravity للـ frontend الرخيص. اخلط وطابق.

تسليم تلقائي

عندما يستدعي وكيل team_complete_step، يبني AgentsRoom حمولة التسليم (ملخص الميزة، الملفات المتغيرة، المخاطر، تلميحات الاختبار، الأعلام) ويُطلق العقدة التالية بهذه الحمولة كسياق ابتدائي.

خيار التسليم اليدوي

تفضّل التحقق من كل خطوة؟ بدّل العقدة إلى الوضع اليدوي. ينتظر الوكيل، وتنقر على 'Hand off' عندما تكون راضيًا عن النتيجة. أفضل ما في العالمين.

حواف شرطية

كل حافة يمكن أن تحمل فحص علم (مثل qaPassed تساوي true). ابنِ تفرعات: إذا نجح QA انتقل إلى PM، وإلا أعِد إلى Dev. منطق سير عمل حقيقي، بدون برمجة.

حلقات تغذية راجعة

Dev إلى QA إلى Dev إلى QA. عندما يعيد QA التذكرة، يُعاد استخدام وكيل Dev الأصلي بذاكرة كاملة للدورة السابقة، فيصلح الانحدار فعلًا بدلًا من البدء من الصفر.

بوابات جودة يتحقق منها الجهاز

ثبّت أمر فحص على أي عقدة (npm test أو lint أو build). ينفذه المشغّل عندما يعلن الوكيل انتهاءه: رمز الخروج 0 يجعل علامة التوجيه true، وأي رمز آخر يجعلها false. النتيجة المقاسة تتجاوز تصريح الوكيل دائماً.

فروع مراجعة متوازية

ارسم رابطين بلا شرط من عقدة واحدة فيعمل الهدفان معاً: يراجع QA و Security نفس الـ diff جنباً إلى جنب، ثم تدمج عقدة الالتقاء تقريريهما. فرع أحمر واحد يكفي لإبقاء البوابة مغلقة.

مهارات مثبتة لكل خطوة

اربط مدخلات من Skills Library بعقدة. يحمّلها الوكيل قبل بدء الخطوة: قائمة المراجعة أو دليل النشر لديك يطبَّق في كل تشغيل، لا فقط عندما يتذكره الوكيل.

حدّ أقصى للدورات

حدّ قابل للتكوين (افتراضي 3). يتجنب حلقات لانهائية ترفض فيها QA عمل Dev. عند الوصول إلى الحدّ، يتوقف التشغيل عند awaiting-finalization وتقرر أنت ما يجب فعله.

التشغيلات تنجو من إعادة التشغيل

أغلق التطبيق في منتصف تشغيل ثم افتحه: يعود التشغيل إلى الخطوة التي كان عندها. الحالة والملاحظات والخط الزمني تعيش على القرص؛ يستأنف المنسق العمل بدل ترك شبح خلفه.

مكتبة الفرق على حسابك

الفرق العامة تتزامن مع حسابك وتتبعك من جهاز لآخر؛ فرق المشروع تسافر مع الغرفة. كلاهما يحتفظ بذاكرة تخزين دون اتصال، والتعديلات دون اتصال تُعاد عند الاتصال.

ملاحظات مشتركة NOTES.md

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

صندوق وارد بين الأدوار

تحتاج QA أن يطرح سؤالًا على Architect أثناء التشغيل؟ team_ask يرسل رسالة إلى صندوق وارد الدور. الوكيل التالي على هذا الدور يقرأها ويردّ. محادثة حقيقية بين الوكلاء.

تواصل بين الوكلاء عبر MCP

تُكشف كل أدوات الفريق عبر خادم MCP. الأدوات تنجو من ضغط سياق Claude (تعيد Anthropic إرسالها في كل دورة). صامدة أمام /clear و/compact والحلقات الطويلة.

ملخص تسليم بقوة Haiku

إذا لم يكتب وكيل ملخص الميزة الخاص به، يُولّد استدعاء Haiku صغير واحدًا من git diff. رخيص وسريع، والوكيل التالي يصل دائمًا بسياق.

نشر Browser MCP

عقدة فريق مع verifyInBrowser تُحوّل وكيلها تلقائيًا إلى وضع الوصول للمتصفح. تصل عقدة QA بكامل أدوات المتصفح (navigate وclick وtype وscreenshot وget logs).

وكلاء عابرون لكل تشغيل

كل تشغيل فريق يُطلق وكلاء جددًا ويدمرهم عند الإلغاء. قائمة وكلاء مشروعك تبقى نظيفة. الفريق هو سير العمل، والوكلاء هم وقت التشغيل.

فرق عامة وفرق مشاريع

احفظ فرقًا قابلة لإعادة الاستخدام في مكتبتك العامة (~/.agentsroom/teams) أو ثبّتها في مشروع محدد (مرتبطة بالغرفة). نفس المحرر، نطاق مختلف.

أربعة قوالب فرق مضمنة

ابنِ ثم تحقق، حدد ثم ابنِ ثم تحقق، مطاردة الخلل (أعد الإنتاج، أصلح، أثبت)، ودرع الإصدار مع QA و Security بالتوازي. انسخ، عدّل، شغّل. جاهز في 30 ثانية.

واجهة جدول زمني للتشغيل

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

شغّل على أي تذكرة backlog

اسقط تذكرة على فريق وتبدأ السلسلة على هذه التذكرة. الوكيل الأول يقرأ عنوان وجسم التذكرة، وبقية الفريق تلتقطها من هناك.

14 دورًا متخصصًا، جاهزة للربط

كل دور لديه موجّه نظام خاص به ومجالات تركيز ومهام أمثلة. اخلطها وطابقها على اللوحة. أضف أدوارًا مخصصة في أي وقت.

Fullstack
End-to-end implementation
Frontend
UI, components, design tokens
Backend
API, database, performance
DevOps
CI/CD, infra, deployment
QA
Tests, edge cases, regression
Security
Audit, OWASP, secrets, auth
Architect
System design, refactor
PM
Specs, priorities, scope
Mobile
iOS, Android, React Native
Marketing
Copy, landing, SEO
Git Expert
Branches, rebase, history
SEO
Rankings, structured data
Localization
i18n, l10n, 14 languages
Custom
Bring your own role

لماذا يتفوّق فريق حقيقي على وكيل خارق واحد

تنسيق متعدد الوكلاء يبدو مصطلحًا تسويقيًا. إليك الفرق العملي، على ميزة قد تشحنها فعلًا.

السيناريو: إضافة تدفّق دفع Stripe إلى موقع تجارة إلكترونية

وكيل خارق منفرد

  • يقرأ التذكرة. يكتب 600 سطر عبر API ونموذج React وwebhook والـ migration والاختبارات.
  • ينسى مفتاح idempotency على webhook. ينسى اختبار مسار الفشل. ينسى متغير بيئة staging.
  • يقول 'تم'. تقضي ساعتين تطارد الأخطاء في الإنتاج.

Agent Team (Dev إلى Security إلى QA)

  • وكيل Fullstack يشحن التنفيذ، يلتزم، يسلّم بملخص وقائمة مخاطر تشير إلى تغيير المصادقة.
  • وكيل Security يقرأ الـ diff، يدقّق فحص توقيع webhook، يكتب تلميحات اختبار لـ QA في حمولة التسليم.
  • وكيل QA يشغّل تلميحات الاختبار في المتصفح المدمج، يصطدم بخطأ idempotency، يضبط qaPassed تساوي false، ويعيد التذكرة إلى Dev مع إعادة الإنتاج الدقيقة.
  • Dev يصلح، ويسلّم مرة أخرى. QA ينجح. PM يعتمد. التشغيل ينتهي بنجاح.

نفس التذكرة، نفس النماذج، نفس المشروع. شكل مختلف للعمل. منهج الفريق يلتقط ما يفوّته الوكيل المنفرد، لأن كل دور لديه إحاطة مركّزة وتسليم منظم.

الثقة تُقاس ولا تُعلَن

الوكيل الذي يصحح واجبه بنفسه سينجّح نفسه عاجلاً أم آجلاً. يبقي Agent Teams خط الإنتاج صادقاً بآليتين.

رمز الخروج هو من يقرر

يمكن لأي عقدة أن تعلن أمر فحص: npm test أو lint أو build، أي شيء يعيد رمز خروج. عندما يستدعي الوكيل team_complete_step ينفذ المشغّل الأمر في مساحة العمل ويكتب النتيجة المقاسة في علامة التوجيه. أخضر: يتقدم التشغيل. أحمر: يهبط خرج الفشل في أعلى سياق الوكيل التالي مع stderr الحقيقي. الوكيل الذي يدعي نجاح كل الاختبارات بينما المجموعة حمراء يوجَّه بالمجموعة الحمراء، لا بادعائه.

أربع أعين في الوقت نفسه

افرد عقدة إلى فروع متوازية: يمر QA على المسارات بينما يدقق Security في الـ diff، كل في وكيله الخاص، أعمى عن استنتاجات الآخر. تنتظر عقدة الالتقاء كل الفروع، تدمج الملخصات والمخاطر والعلامات، ثم توجّه على أساس النتيجة المجمعة. تُحسم التعارضات المنطقية إلى false عمداً: مراجع واحد راسب يكفي لحجز الإصدار.

Dev → [ QA ∥ Security ] → Release gate

كيف يعمل تشغيل الفريق

01

افتح علامة تبويب Teams

في عرض المشروع، تسرد تبويبة Teams أربعة قوالب مضمنة (ابنِ ثم تحقق، حدد ثم ابنِ ثم تحقق، مطاردة الخلل، درع الإصدار) إضافة إلى الفرق التي حفظتها. انسخ قالباً أو اضغط 'New team'.

02

ابنِ سير العمل على اللوحة

ضع عقد وكلاء على لوحة React Flow. لكل عقدة، اختر الدور (Fullstack، QA، Security، PM، إلخ)، والمزوّد، والنموذج، وبضعة أسطر من تعليمات الخطوة. اربطها بحواف. أضف شروطًا على الحواف إذا احتجت تفرعًا.

Dev → QA → PM
03

اضبط وضع التسليم لكل عقدة

تسليم تلقائي: يستدعي الوكيل team_complete_step عندما ينتهي عمله، فيتولى المشغّل. تسليم يدوي: ينتظر الوكيل أن تنقر على 'Hand off'. اخلط الاثنين حسب الحاجة.

04

شغّل الفريق

من تذكرة backlog، انقر 'Run with team'. من خانة وكيل فارغة، انقر 'Create as team'. تنطلق العقدة الأولى كوكيل عابر في مساحة عمل المشروع.

05

شاهد التسليم يحدث

عندما ينتهي الوكيل N يبني AgentsRoom حمولة التسليم (ملخص عبر الوكيل أو عبر Haiku، و git diff، ومخاطر، وتلميحات اختبار، وعلامات)، ويضيف ملاحظة إلى NOTES.md، ويختار الرابط الخارج الصحيح وفق العلامات، ويسلّم إلى الوكيل N+1 بهذه الحمولة سياقاً للدخول. إذا أعلنت العقدة أمر فحص فينفذه المشغّل أولاً: رمز الخروج المقاس، لا ادعاء الوكيل، هو من يضبط علامة التوجيه.

06

حلقة، نهاية، اعتماد

تعيد حلقات التغذية الراجعة دخول الوكيل الأصلي (الذاكرة الكاملة محفوظة). عقدة النهاية تُحدث awaiting-finalization. تنقر على 'Finish run'. أغلق الشريط لتدمير الوكلاء وتحرير PTYs.

تواصل بين الوكلاء ينجو من أي شيء

التفصيل الذي تتجاوزه معظم عروض الوكلاء المتعددين. إليك ما يجعل Agent Teams تصمد عبر تشغيلات طويلة ودورات كثيرة.

وكلاء Claude Code لديهم نافذة سياق ويضغطونها. الخطأ الكلاسيكي لأنظمة الوكلاء المتعددين هو وضع تنسيق الفريق في موجّه النظام فقط. بعد دورتين من /compact، لا يكون لدى الوكيل أي فكرة أنه في فريق. AgentsRoom لا يفعل ذلك.

كل تنسيق الفريق يعيش في ثلاثة أماكن تنجو من الضغط. أولًا، خادم MCP (agentsroom-team) يكشف أدوات (team_get_context وteam_read_notes وteam_post_note وteam_read_inbox وteam_ask وteam_read_timeline وteam_read_diff وteam_complete_step). أدوات MCP يُعاد إرسالها إلى Claude في كل دورة بواسطة الـ CLI، فهي محصّنة ضد ضغط السياق.

ثانيًا، يعمل hook من نوع UserPromptSubmit قبل كل رسالة مستخدم ويُلصق تذكيرًا صغيرًا إذا كانت هناك ملاحظات جديدة أو رسائل صندوق وارد جديدة لهذا الدور. رخيص عندما لا يحدث شيء، حاسم عندما يحدث.

ثالثًا، NOTES.md وstate.json يعيشان على القرص في مساحة العمل. يمكن للوكيل إعادة قراءتهما في أي لحظة بـ Read بسيط أو بـ team_read_notes. ينجوان من الأعطال وإعادة التشغيل و/clear و/compact وإعادة تشغيل Mac. موجّه النظام ليس مصدر الحقيقة، القرص وأدوات MCP هما المصدر.

ماذا يبني الناس بـ Agent Teams

خط Dev إلى QA

الكلاسيكي. Fullstack يشحن الميزة. QA يتحقق منها في المتصفح المدمج، يشغّل تلميحات الاختبار، يعتمد. فريق من عقدتين، يعمل على كل تذكرة من الـ backlog.

Dev إلى QA مع حلقة تغذية راجعة

نفس ما سبق، لكن مع حافة شرطية: qaPassed تساوي false تعيد التذكرة إلى Dev مع تلميحات الاختبار. أقصى 3 دورات. يلتقط الانحدارات قبل أن تصل إلى مراجع بشري.

Dev إلى Security إلى QA

للميزات التي تمسّ المصادقة أو المدفوعات أو PII. وكيل Security يراجع الـ diff، يحدد المخاطر، يكتب تلميحات اختبار لـ QA. تستخدمه فرق تشحن fintech وhealthtech وB2B SaaS.

PM إلى Architect إلى Dev

سير عمل بالمواصفات أولًا. وكيل PM يحوّل التذكرة إلى مواصفات منظمة. Architect يختار النهج. Dev ينفّذ. ثلاثة أدوار، فصل نظيف، قرارات قابلة للتتبع.

Frontend وBackend وDevOps موزّعين

تقسيم تسلسلي للميزات الكاملة. Frontend يشحن واجهة المستخدم. Backend يشحن API. DevOps يضيف تكوين البنية التحتية. كل دور يعمل في مجاله، ويسلّم بـ diff نظيف.

Marketing إلى SEO إلى i18n

نعم، AgentsRoom Teams ليست للكود فقط. Marketing يكتب نسخة الـ landing. SEO يحقن الكلمات المفتاحية. Localization يترجم إلى 14 لغة. فريق واحد، تذكرة واحدة، شحنة واحدة.

درع الإصدار: QA و Security بالتوازي

تنقسم عقدة dev إلى QA و Security يعملان جنباً إلى جنب، ثم تدمج بوابة الإصدار التقريرين. يأتي مع التطبيق كقالب. يعود الدرع كله إلى Dev إذا أبلغ أي فرع عن مشكلة.

مطاردة الخلل: أعد الإنتاج قبل الإصلاح

وكيل QA يعيد إنتاج الخلل ويدوّن الخطوات الدقيقة. مطوّر يصلح السبب الجذري. وكيل QA ثانٍ يعيد الخطوات نفسها ليثبت الإصلاح. انتهى زمن 'يعمل على جهازي'.

كيف تقارن بمناهج الوكلاء المتعددين الأخرى

تنسيق الوكلاء المتعددين مصطلح تسويقي مزدحم. إليك ما يُشحن فعلًا، وأين يتموضع AgentsRoom Teams.

تتيح Anthropic Subagents (أداة Task، .claude/agents) لجلسة Claude واحدة تفويض المهام إلى وكلاء مساعدين متخصصين. رائعة للتفويض المضمّن، لكن جلسة الأب تبقى المنسّق وسياقًا واحدًا. AgentsRoom Teams مستوى أعلى: كل عقدة فريق هي جلسة Claude مستقلة على المستوى الأعلى، بنافذتها وحالتها وسجلها الخاص. CrewAI وAutoGen وLangGraph أُطر Python ممتازة لتدفقات الوكلاء المتعددين، لكنها تعيش خارج بيئة التطوير لديك ولا تشغّل Claude Code أو Codex أو Antigravity CLI الفعلي من البداية إلى النهاية على مستودعك المحلي. n8n وMake وPipedream وRetool تشحن نفس نوع محرر اللوحة الذي نستخدمه، لكنها منصات أتمتة عامة، غير مبنية لوكلاء البرمجة بالذكاء الاصطناعي. AgentsRoom Teams هو محرر سير العمل متعدد الوكلاء بأسلوب اللوحة، لكنه موصول تحديدًا بوكلاء CLI لديك ومشروعك وgit وطرفياتك ومتصفحك.

Claude subagentsTask toolCrewAIAutoGenLangGraphn8nMakePipedreamRetoolTemporalAirflowPrefectDagster

إذا كنت تبني أنظمة وكلاء في Python، استمر في استخدام CrewAI أو LangGraph لخطوط الإنتاج. إذا كنت تشحن كودًا مع Claude Code أو Codex CLI أو OpenCode أو Antigravity CLI أو Aider أو Grok Build أو Mistral Vibe أو Kimi Code، فإن Agent Teams هو سير عمل الفريق الذي يعمل حيث تبرمج فعلًا.

FAQ

كيف يختلف هذا عن Claude Code subagents (أداة Task، .claude/agents)؟

Claude subagents هي تفويضات مضمّنة من جلسة Claude واحدة. الجلسة الأب تقرر متى تستدعي subagent، يعمل subagent في نافذة سياق معزولة، يعيد نتيجة، وتستمر الجلسة الأب. AgentsRoom Teams مستوى أعلى: كل عقدة هي جلسة Claude Code على المستوى الأعلى بطرفيتها وحالتها وسجلها الخاص. ترى كل وكيل يعمل مباشرة في علامة تبويبه، يمكنك التحدث إلى أي منهم في أي لحظة، يمكنك إيقاف الفريق، تغيير سير العمل ثم المتابعة. ليست بديلًا عن Claude subagents، يمكنك استخدام كليهما تمامًا. عقدة فريق يمكن أن تستخدم subagents داخليًا.

هل يعمل هذا فقط مع Claude Code؟

يعمل مع كل مزوّد يدعمه AgentsRoom (Claude Code وCodex CLI وOpenCode وAntigravity CLI وAider وGrok Build وMistral Vibe وKimi Code). كل عقدة فريق تختار مزوّدها ونموذجها. أدوات تنسيق الفريق المعتمدة على MCP تعمل بشكل متطابق عبر المزوّدين لأنها مكشوفة عبر Model Context Protocol القياسي. يمكنك تشغيل فريق مع Codex على عقدة backend الثقيلة وHaiku على عقدة QA إذا كان ذلك يناسب ميزانيتك وزمن استجابتك.

ما هي حمولة التسليم؟

كائن منظم ينتقل من وكيل إلى التالي. الحقول: featureSummary (وصف قصير لما تم شحنه)، changedFiles (git diff name-status)، touchedAreas (UI وAPI وDB وconfig)، risks (أي شيء يجب أن يقلق منه الوكيل التالي)، testHints (أولويات لـ QA)، flags (قيم بوليانية مثل qaPassed، تستخدمها الحواف الشرطية). يستدعي الوكيل team_complete_step بهذه الحمولة، يتحقق منها المشغّل على الخادم، ويستقبلها الوكيل التالي كسياق ابتدائي.

هل يمكن للوكلاء فعلًا الذهاب والإياب (Dev إلى QA إلى Dev)؟

نعم. عند إعادة دخول عقدة (دورة أكبر من 1)، لا يُطلق AgentsRoom وكيلًا جديدًا. يُعيد استخدام وكيل الدورة الأصلية الأول، يكتب حمولة التسليم الجديدة مباشرة في طرفيته الموجودة، ويحتفظ الوكيل بكامل ذاكرة جلسة Claude للدورات السابقة. هذا حاسم: وكيل Dev يعرف فعلًا ما حدده QA المرة الماضية يصلح الخطأ. وكيل Dev جديد بدون ذاكرة سيكرر الخطأ نفسه فقط.

ماذا يحدث إذا استمر QA في رفض Dev إلى الأبد؟

تكوين الفريق لديه حدّ أقصى للدورات، افتراضي 3. عند الوصول إلى الحدّ، يتوقف التشغيل بحالة 'blocked' وينتظرك. يمكنك اعتماد التشغيل، أو التسليم يدويًا مرة أخرى، أو إلغاء كل شيء. لا حلقات لانهائية، ولا فواتير ليلية مفاجئة.

هل يشترك جميع وكلاء الفريق في نفس مساحة عمل git؟

نعم. يعمل الفريق في مساحة عمل واحدة وفرع واحد (أو worktree إذا استخدمت ميزة AgentsRoom Worktrees). يرى كل وكيل عمل السابق عبر git. تتضمن حمولة التسليم git diff مقابل خط أساس التشغيل ليعرف الوكيل التالي بالضبط ما هو جديد.

هل يتطلب هذا اشتراكًا إضافيًا؟

لا. Teams جزء من AgentsRoom. تحضر مفاتيح المزوّد الخاصة بك (Claude وCodex وOpenCode وAntigravity وAider وGrok Build وMistral Vibe وKimi Code) وتدفع فقط مقابل التوكنز التي تستخدمها، كما هو الحال مع وكيل واحد. تشغيل فريق Dev إلى QA على تذكرة صغيرة يكلّف عادةً نفس تشغيل وكيل Fullstack منفرد، لأن Haiku/Sonnet على خطوة QA رخيص.

أين تُخزّن الفرق؟ هل تُلتزم في git؟

فرق المشروع تعيش مع الغرفة، متزامنة مع حسابك ومخزنة في {project}/.agentsroom/teams-cache.json (ضمن gitignore). الفرق العامة متزامنة مع حسابك أيضاً: مكتبتك تتبعك من جهاز لآخر، مع ~/.agentsroom/teams/ ذاكرة تخزين دون اتصال. القوالب المضمنة تبقى محلية: كل جهاز يثبتها بلغته.

ماذا لو تعطّل وكيل أو أُعيد تشغيل التطبيق أثناء التشغيل؟

تُحفظ حالة التشغيل على القرص في {workspace}/.agentsroom/team-runs/{runId}/ (state.json و NOTES.md و inbox/ و timeline.jsonl)، بكتابات ذرّية وملاحظات بالإلحاق فقط. يُستأنف التشغيل المقطوع عند إعادة تشغيل التطبيق: يدخل المنسق الخطوة النشطة من جديد، يعيد فتح الطرفية، ويستعيد الوكيل سياقه من الملاحظات وأدوات الفريق. التشغيل الذي حُذف فريقه يُغلق تلقائياً بدل أن يبقى معلقاً إلى الأبد.

هل يمكنني تشغيل عدة فرق بالتوازي على تذاكر مختلفة؟

نعم. كل تشغيل مستقل ويعرَّف بـ runId. يمكنك تشغيل ثلاثة فرق مختلفة على ثلاث تذاكر في المشروع نفسه. داخل التشغيل الواحد يتبع التنفيذ مخططك: تسلسلي افتراضياً، متوازٍ حيث ترسم فروعاً متوازية (مثل QA و Security يراجعان معاً)، ودائماً بالتقاء حتمي.

هل يمكن فعلاً لوكيلين أن يعملا في الوقت نفسه؟

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

كيف تعمل بوابات الجودة بالضبط؟

تكتب أمر shell على العقدة، مثلاً npm test، واختيارياً اسم علامة (checkPassed افتراضياً). عندما يعلن الوكيل انتهاء خطوته ينفذ AgentsRoom الأمر في مساحة العمل بسقف خمس دقائق. رمز الخروج 0 يكتب true في العلامة، وأي رمز آخر يكتب false متجاوزاً ما صرّح به الوكيل عن نفسه. عند الفشل تنتقل آخر كيلوبايتات من الخرج إلى الوكيل التالي: تهبط العودة ومعها تتبع المكدس الحقيقي، وتظهر النتيجة في الخط الزمني للتشغيل.

هل يمكن لخطوة أن تحمّل إجراءاتي من Skills Library؟

نعم. يمكن لكل عقدة تثبيت مهارات من Skills Library لديك، للمشروع أو عامة. يُطلب من الوكيل تحميل كل منها قبل بدء الخطوة: قائمة مراجعة أو دليل نشر أو إجراء اختبار يطبَّق في كل تشغيل، بدل الاعتماد على ذاكرة الوكيل.

ابنِ فريق تطوير الذكاء الاصطناعي الذي تحلم به

أربعة قوالب تأتي مع التطبيق. افتح AgentsRoom، ضع العقد، ارسم الروابط، شغّل على أي تذكرة. فريقك الهندسي بالذكاء الاصطناعي على بعد نقرة واحدة.

مجانيتحميل AgentsRoom

التطبيق المرافق: تابع وكلاءك أينما كنت

استخدم Claude أو Codex أو Antigravity CLI أو أي مزود AI آخر.

تثبيت الملحق
Chrome Web Store

أرسل الأخطاء والطلبات مباشرة إلى قائمة المهام العامة.

لمحة عن AgentsRoom أثناء العمل.

مشاريع متعددة
متعدد المزوّدين
وكلاء متعددون
حالة مباشرة
فرق الملفات والإيداع
تطبيق الهاتف
معاينة مباشرة
فرق الوكلاء
أتمتة المتصفح
تطوير موجّه بالـ backlog
مكتبة البرومبت
مكتبة المهارات
عرض جميع الميزات