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 أو Gemini CLI أو Aider معيّن لدور محدد، ثم تربطها معًا. شغّل الفريق على تذكرة من الـ 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، Gemini 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 الثقيل، وGemini للـ frontend الرخيص. اخلط وطابق.

تسليم تلقائي

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

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

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

حواف شرطية

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

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

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

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

حدّ قابل للتكوين (افتراضي 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) أو ثبّتها في مشروع محدد (مرتبطة بالغرفة). نفس المحرر، نطاق مختلف.

قوالب فرق مدمجة

ثلاثة قوالب جاهزة تأتي مع التطبيق: Dev إلى QA، Dev إلى QA مع حلقة تغذية راجعة، وDev إلى Security إلى QA. كرّر، عدّل، شغّل. ابدأ في 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 يعتمد. التشغيل ينتهي بنجاح.

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

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

01

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

في عرض مشروعك، تعرض علامة تبويب Teams ثلاثة قوالب جاهزة (Dev إلى QA، Dev إلى QA مع حلقة تغذية راجعة، Dev إلى Security إلى QA) بالإضافة إلى أي فريق حفظته. كرّر قالبًا أو انقر على '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 لغة. فريق واحد، تذكرة واحدة، شحنة واحدة.

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

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

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

Claude subagentsTask toolCrewAIAutoGenLangGraphn8nMakePipedreamRetoolTemporalAirflowPrefectDagster

إذا كنت تبني أنظمة وكلاء في Python، استمر في استخدام CrewAI أو LangGraph لخطوط الإنتاج. إذا كنت تشحن كودًا مع Claude Code أو Codex CLI أو OpenCode أو Gemini CLI أو Aider، فإن 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 وGemini CLI وAider). كل عقدة فريق تختار مزوّدها ونموذجها. أدوات تنسيق الفريق المعتمدة على 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 وGemini وAider) وتدفع فقط مقابل التوكنز التي تستخدمها، كما هو الحال مع وكيل واحد. تشغيل فريق Dev إلى QA على تذكرة صغيرة يكلّف عادةً نفس تشغيل وكيل Fullstack منفرد، لأن Haiku/Sonnet على خطوة QA رخيص.

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

الفرق المرتبطة بالمشروع تعيش مع الغرفة، تُزامن إلى السحابة وتُخزّن مؤقتًا في {project}/.agentsroom/teams-cache.json (مُتجاهَل في gitignore). الفرق العامة تعيش في ~/.agentsroom/teams/{teamId}.json على جهازك، ملف واحد لكل فريق. تقرر أنت أي نطاق يناسب كل سير عمل.

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

تُحفظ حالة التشغيل على القرص في {workspace}/.agentsroom/team-runs/{runId}/ (state.json وNOTES.md وinbox/ وtimeline.jsonl). NOTES.md قابل للإلحاق فقط، وكل كتابة حالة ذرّية. يمكن للوكلاء إعادة قراءة كل شيء في أي وقت بـ team_read_notes أو team_get_context. يجري تعزيز طبقة التنسيق لإعادة تشغيل تشغيل مقاطَع بالكامل عند إعادة تشغيل التطبيق، لكن قصة القرص آمنة بالفعل ضد الأعطال.

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

نعم. كل تشغيل فريق مستقل ومُعرَّف بـ runId الخاص به. يمكن أن يكون لديك فريق Dev إلى QA يعمل على التذكرة A، وفريق Dev إلى Security إلى QA على التذكرة B، وفريق PM إلى Architect إلى Dev على التذكرة C، كلها مباشرة في نفس المشروع. داخل تشغيل واحد، التنفيذ تسلسلي (عقدة نشطة واحدة في كل مرة) لقابلية التنبؤ.

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

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

مجانيتحميل AgentsRoom

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

يعمل مع Claude و Codex و OpenCode و Gemini CLI و Aider

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

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

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