GitHub Agent HQ: ما هو، ولمن هو موجه، وما الذي يقع خارج نطاقه

تصف ميزة، وتُسندها إلى وكيل برمجي، ثم تنصرف بينما يفتح لك طلب سحب (pull request). ثم تفعل الأمر ذاته مع وكيل ثانٍ، وثالث. وسرعان ما تصبح المشكلة الحقيقية ليست إنشاء الوكلاء، بل تتبّعهم. GitHub Agent HQ هو ردّ GitHub على هذه الفوضى: مركز تحكّم يجمع الوكلاء البرمجيين من عدة جهات في مركز قيادة واحد داخل GitHub. إنها فكرة قوية حقًا، ويغطي هذا الدليل ما هي، ولمن تناسب، والخط الفاصل الذي تتجاهله معظم المقالات: Agent HQ ينسّق العمل الذي يعيش داخل منظومة GitHub، وليس الأدوات التي تعيش خارجها.

يظهر هذا الحدّ الفاصل لحظة ألا يكون فريقك ملتزمًا بالكامل بنظام GitHub. إذا كان نظام تتبّع المهام لديك هو Jira، ومستودعاتك على GitLab، أو نصف وكلائك يعملون على حواسيب وطرفيات لا تلامس سحابة GitHub أبدًا، فأنت تحتاج طبقة تعلو فوق كل أداة، لا أن تكون داخل إحداها. تلك الطبقة هي Sharkly، منصة شاملة لقيادة الوكلاء وإدارتهم. يستعرض هذا المقال أين يتألق Agent HQ، وأين تقع حدوده بالضبط، وكيف تُبقي الطبقة المحايدة أسطولًا مختلطًا مرئيًا من الطلب حتى الإصدار.

سنفترض أفضل نسخة من Agent HQ طوال المقال، لأنه يستحق ذلك. ثم سنرسم الحدود بوضوح، حتى تستطيع أن تحكم في نحو دقيقتين إن كان Agent HQ كافيًا بمفرده أم أنك تجاوزت بالفعل مركزًا أحادي المنظومة.

باختصار (TL;DR)

GitHub Agent HQ هو مستوى تحكّم داخل GitHub، يحمل العلامة Mission Control، لإسناد الوكلاء البرمجيين من عدة جهات (Claude، Codex، Google، Cognition، xAI) وقيادتهم وتتبّعهم كجزء من اشتراك مدفوع في GitHub Copilot. إنه محايد تجاه الوكيل فيما يخص النماذج، وممتاز عندما يعيش عملك أصلًا في مستودعات GitHub وطلبات السحب وActions. حدّه هو المنظومة، لا جهة الوكيل: فهو ينسّق الوكلاء العاملين داخل GitHub، لذا لا يدير ما يجري على GitLab أو لوحة Jira أو Bitbucket، ولا الوكلاء الذين يعملون محليًا على Computers خارج سحابة GitHub. استخدم Agent HQ عندما تكون مؤسسة ملتزمة بالكامل بـ GitHub. واستخدم طبقة محايدة مثل Sharkly عندما يمزج فريقك بين أنظمة التتبّع والمضيفين وبيئات التشغيل ويحتاج سجلًا مشتركًا واحدًا مع مراجعة بشرية عبر جميعها.

ما هو GitHub Agent HQ في الحقيقة

GitHub Agent HQ هو مركز قيادة داخل GitHub لإسناد الوكلاء البرمجيين من عدة جهات وقيادتهم وتتبّعهم، يُقدَّم عبر اشتراك مدفوع في GitHub Copilot. هذه الجملة الواحدة تحمل الفكرة كاملة. فبدلًا من أن يعيش كل وكيل في أداته الخاصة بواجهة تشغيل خاصة به، يجمعهم Agent HQ في مكان واحد تسميه GitHub Mission Control، ويمكن الوصول إليه من GitHub نفسه، ومن VS Code، وتطبيق الجوال، وسطر الأوامر.

النقطة الجوهرية الجديرة بالذكر أن Agent HQ ليس وكيل جهة واحدة. فقد فتحته GitHub للوكلاء البرمجيين من Anthropic وOpenAI وGoogle وCognition وxAI، بحيث يمكنك اختيار Claude لخطوة وCodex لأخرى دون مغادرة المركز. تُسند مهمة إلى وكيل، فيعمل على فرع (branch) داخل بيئة GitHub، ويجري فحوصاتك، ثم يعيد طلب سحب تراجعه بالطريقة ذاتها التي تراجع بها الكود. Mission Control هو المكان الذي تراقب فيه عدة عمليات تشغيل من هذه في آن واحد، وميزات مثل Plan Mode تساعدك على تشكيل العمل قبل أن يبدأ الوكيل.

الغاية من المركز هي التنسيق. فلن تتنقل بين خمس أدوات وكلاء منفصلة محاولًا تذكّر أيها يفعل ماذا. وإذا كنت قد قرأت شرحنا عن ما يعنيه تنسيق الوكلاء الذكيين، فإن Agent HQ هو التنسيق في صورته أحادية المنظومة: جهات وكلاء كثيرة، ومنصة واحدة، وتلك المنصة هي GitHub.

ما يبرع فيه Agent HQ

خُذ الميزة في أفضل صورها، لأن أفضل نسخة منها قوية. وإليك أين يستحق Agent HQ مكانه.

اختيار محايد لجهة الوكيل. تُقيّدك معظم مراكز الوكلاء بمصنّع نماذج واحد. أما Agent HQ فلا. يمكنك تشغيل Claude وCodex وغيرهما جنبًا إلى جنب والانتقال من الفكرة إلى التنفيذ باستخدام وكلاء مختلفين لخطوات مختلفة دون تبديل الأدوات أو فقدان السياق. وهذا ردّ حقيقي على الاحتكار في اختيار النموذج، وهو الميزة التي تصدّرها الإطلاق لسبب وجيه.

مركز قيادة واحد عبر جميع الواجهات. يمنحك Mission Control رؤية موحدة لنشاط الوكلاء من GitHub وVS Code والجوال وواجهة سطر الأوامر (CLI). تُسند وتوجّه وتتبّع من حيث كنت أصلًا. وبالنسبة لفريق كان يتولّى إدارة عمليات التشغيل المتوازية يدويًا، يوضّح دليلنا عن تشغيل عدة وكلاء Claude Code بالتوازي مدى تعقيد النسخة التي تُبنى يدويًا. ويزيل Agent HQ هذا العناء داخل GitHub.

عمل يصل إلى حيث تجري المراجعة بالفعل. يعمل الوكلاء على فروع ويعيدون طلبات سحب. وتدخل المخرجات مباشرة في مسار المراجعة في GitHub الذي يثق به فريقك، مع مراجعة الكود والفحوصات وقواعد الدمج ذاتها التي تطبّقها بالفعل. دون مكان جديد تبحث فيه عن الفروقات.

متجذّر في المنصة التي يعيش فيها الفريق أصلًا. إذا كانت GitHub موطنك، فإن Agent HQ ليس إضافة لاحقة. فهو يشارك هويتك وأذوناتك وActions ومستودعاتك. وتقع تعليمات الوكلاء المخصّصة وأدوات التحكم بجانب الكود الذي تعمل عليه، فيكون الإعداد قريبًا من العمل بدل أن يكون معزولًا في وحدة تحكم منفصلة.

بالنسبة لفريق موحّد على GitHub من أعلى إلى أسفل، فهذه حلقة أنيقة وقوية. صِف العمل، اختر وكيلًا، راجع طلب السحب، ثم ادمج. إن كنت كذلك، فقد يكون Agent HQ كل التنسيق الذي تحتاجه، ويمكنك التوقف عن القراءة هنا بضمير مرتاح.

لمن صُمِّم Agent HQ

صُمِّم Agent HQ للمؤسسة الملتزمة بالكامل بـ GitHub، ويخدمها جيدًا. وأوضح توافق يبدو هكذا: الكود المصدري لديك في مستودعات GitHub، والتكامل المستمر (CI) يعمل على GitHub Actions، وفريقك يراجع ويدمج عبر طلبات السحب في GitHub، ولديك اشتراك مدفوع في Copilot. كل ما يحتاجه الوكيل ليقرأ ويغيّر ويختبر ويطلق موجود بالفعل داخل منصة واحدة، لذا يكون للمركز داخل تلك المنصة وصول كامل إلى العمل.

وتتراكم القيمة لهذا الفريق مع استمرار الإطلاق خلال 2026. فكل جهة وكيل جديدة وكل ميزة جديدة في Mission Control تحلّ في المكان الذي يوجد فيه عملك بالفعل. أنت لا تدمج أي شيء. بل تُفعّل المزيد من منصة تديرها بالفعل. وبالنسبة لمؤسسة هندسية محورية على GitHub، فهذا أقصر مسار من مهمة موصوفة إلى تغيير مُراجَع ومدمج.

السؤال ليس ما إذا كان Agent HQ بارعًا في هذا. بل هل يتّسع واقع فريقك داخل GitHub، كله؟ وهنا يأتي الحد الفاصل.

الحد الفاصل بصدق: إنه ينسّق منظومة GitHub، لا أدواتك الأخرى

إليك الخط الذي نادرًا ما ترسمه الإعلانات لك، وهو ليس الخط الذي يتوقعه الناس. الحدّ ليس جهة الوكيل. فـ Agent HQ منفتح هناك بشكل منعش. الحد هو المنظومة. ينسّق Agent HQ الوكلاء الذين يعملون داخل GitHub: مستودعات GitHub وطلبات السحب وActions وهوية GitHub، في إطار اشتراك GitHub Copilot. وكل جزء من ذلك هو جزء من GitHub. وهذا ليس عيبًا. بل هو التصميم. لكنه يضع حدًا صارمًا في اليوم الذي يتوقف فيه عمل فريقك عن العيش بالكامل داخل GitHub.

لا يدير Agent HQ العمل على GitLab أو Bitbucket. وإذا كان بعض مستودعاتك أو خطوط أنابيبك (pipelines) خارج GitHub، فلن تصل إليها الوكلاء الذين ينسّقهم Agent HQ. تلك العمليات تعيش في عالم منفصل دون خط زمني مشترك.

Agent HQ ليس نظام تتبّع مشاريعك. فهو ينسّق الوكلاء مقابل الكود وطلبات السحب. وإذا كان فريقك يخطّط ويسند العمل في Jira أو Linear، فسؤال من يملك المهمة وما تعتمد عليه وما هو معطّل يعيش في نظام لا يديره Agent HQ. فطلب السحب سطح مراجعة، لا طبقة إسناد وسياق.

لا ينسّق Agent HQ الوكلاء الذين يعملون خارج سحابته. فإذا شغّل أحد أعضاء الفريق Claude Code في طرفية محلية (terminal)، أو Codex على Computer الخاص به، أو وكيلًا على بيئة تشغيل تستضيفها بنفسك، فلن يظهر ذلك العمل في Mission Control. فالمركز يرى الوكلاء الذين يطلقهم داخل GitHub، لا الذين يشغّلهم فريقك في مكان آخر.

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

ثنائية القرار: مؤسسة ملتزمة بالكامل بـ GitHub أم فريق بأدوات مختلطة

الخيار ليس «مركز جيد مقابل مركز سيئ». بل «أي شكل من التنسيق يناسب فريقك». وإليك ثنائية القرار بصدق.

استخدم GitHub Agent HQ عندما تكون مؤسسة ملتزمة بالكامل بـ GitHub. مستودعات وActions وطلبات سحب واشتراكات Copilot، دون عمل ذي شأن خارج تلك المنظومة. في ذلك العالم، يكون Agent HQ أقصر مسار من مهمة إلى فرع مُراجَع، وإضافة طبقة أخرى ستكون عبئًا لا تحتاجه. فللمركز وصول كامل لأن للعمل موطنًا واحدًا.

استخدم طبقة محايدة عندما يمزج فريقك بين أنظمة التتبّع والمضيفين وبيئات التشغيل. فبمجرد أن يتضمن واقعك لوحة Jira أو مستودع GitLab أو وكلاء يعملون على Computers تتحكم بها خارج سحابة GitHub، فإن ما ينقصك ليس المزيد من الوكلاء. بل سجل مشترك. تحتاج إلى Task واحد يحمل الهدف والفروقات والنقاش والمراجعة البشرية، أيًا كان المضيف أو نظام التتبّع أو بيئة التشغيل التي أنجزت العمل. وهذه مهمة لطبقة تعلو فوق كل أداة، لا أن تكون داخل إحداها.

هذا هو التفريع ذاته الذي يصطدم به المطورون مع أي مركز من جهة واحدة، وقد تناولناه في حالة المحرر في شرح وكلاء الخلفية في Cursor، وفي اللوحات المحلية في دليل بديل Vibe Kanban. إن التنسيق أحادي المنظومة مريح تمامًا إلى أن تصبح المنظومة لم تعد القصة كاملة.

أين يندرج Sharkly: الطبقة المحايدة حول كل بيئة تشغيل ونظام تتبّع

Sharkly ليس بديلًا عن GitHub أو Copilot أو Claude Code أو Codex أو غيرها من أدوات التنفيذ. بل يضيف طبقة Task وComputer والسياق والتحكم والمراجعة المشتركة حول الأدوات التي يستخدمها فريقك بالفعل. هذه الجملة هي العلاقة بأكملها، فاقرأها مرتين. تبقي على GitHub. تبقي على Agent HQ حيث يندرج. وSharkly هو ما ينسّق الأسطول عندما يكون الأسطول أكبر من منظومة واحدة.

تقسيم العمل واضح. تتولّى GitHub وCopilot وClaude Code وCodex والأدوات المشابهة التنفيذ. ويدير Sharkly الإسناد على مستوى الفريق، وComputers المتصلة، وسياق Task، والتقدّم، والعوائق، والنتائج، والمراجعة البشرية عبر تلك الأدوات. يبحث الوكلاء وينفّذون ويختبرون ويقدّمون التقارير. ويضع الناس التوجّه، ويمنحون الصلاحية، ويقبلون النتيجة. وتتوقف الأتمتة حيث يُطلب حكم الفريق.

عمليًا، Task في Sharkly هو الوحدة الأساسية للعمل، ويحمل كل شيء عن قطعة عمل في مكان واحد. تُسنده إلى Agent يعمل على Computer تتحكم به، مع Runtime تختاره. وتعود عمليات التنفيذ والعوائق والنتائج والنقاش اللاحق إلى الجدول الزمني لـ Task، بدلًا من التشتّت عبر سحابة منصة واحدة ونظام تتبّع منفصل وحفنة من الطرفيات الخاصة. يبقى الهدف والفروقات والنقاش والمراجعة لكل عملية تشغيل معًا، سواء جرت تلك العملية عبر Agent HQ داخل GitHub، أو عبر Claude Code على Computer أحد أعضاء الفريق، أو عبر شيء تعتمده العام القادم.

ولا يطلب منك إعادة بناء أي شيء. حافظ على المشاريع والمهام والحالات وسير العمل التي يفهمها فريقك بالفعل، واربط Sharkly بأنظمة التتبّع والمضيفين الذين تديرهم بالفعل، وابدأ بتوجيه العمل دون إعادة بناء العملية التي يستخدمها فريقك. يستمر استخدام النماذج عبر الاشتراكات أو مفاتيح API المهيّأة في تلك الأدوات، فتجلب اشتراكك الخاص ويضيف Sharkly التنسيق فوقه. وإذا كنت جديدًا على المنصة، فإن تعرّف على Sharkly يستعرض الأفكار الأساسية، وجولة المهمة الأولى تعرض أصغر نسخة مفيدة من البداية إلى النهاية. يمكنك تنزيل Sharkly وتوصيل Computer واحد لتجربته على عمل حقيقي.

أخطاء شائعة يجب تجنّبها

• افتراض أن «محايد تجاه الجهة» يعني «محايد تجاه الأداة». فـ Agent HQ منفتح على أي وكيل ينفّذ العمل، وهذه قوة حقيقية. لكنه ليس منفتحًا على مكان وجود العمل. فالوكلاء ما زالوا يعملون داخل GitHub. اقرأ الحدّ على أنه منظومة، لا مصنّع نماذج.
• تبنّي مركز منظومة واحدة وكأنه استراتيجيتك بأكملها. إذا وحّدت على Agent HQ اليوم وأبقيت مستودع GitLab أو لوحة Jira حيّة الربع القادم، فأنت قد قسّمت سطح تنسيقك بهدوء. قرّر مبكرًا هل أنت ملتزم فعليًا بالكامل بـ GitHub أم فريق بأدوات مختلطة.
• التعامل مع طلبات السحب كطبقة التنسيق. فطلبات السحب سطح مراجعة، لا طبقة إسناد وسياق. فمن يملك Task، وما يعتمد عليه، ولماذا هو معطّل، لا تتناسب مع الفروقات.
• نسيان الوكلاء الذين لا يلامسون المركز أبدًا. فأي عملية تشغيل تبدأ خارج GitHub، في طرفية محلية أو على Computer تستضيفه، لن تظهر في Mission Control. أحصِ تلك العمليات قبل أن تسمّي مركزًا واحدًا مصدر الحقيقة الوحيد لديك.

GitHub Agent HQ مقابل طبقة تنسيق محايدة

اقرأ هذا كتقسيم للعمل، لا كلوحة نتائج.

لا يوجد عمود «خاطئ». إذا وقعت إجابتك صفًا بصف في العمود الأيسر غالبًا، فإن Agent HQ يناسبك. وإذا انحرفت نحو اليمين، خصوصًا في صفوف أين يعيش العمل ونظام التتبّع والسجل المشترك، فأنت قد تجاوزت التنسيق أحادي المنظومة.

النقاط الرئيسية

• GitHub Agent HQ هو مستوى تحكّم داخل GitHub، يحمل العلامة Mission Control، لإسناد الوكلاء البرمجيين من عدة جهات وقيادتهم وتتبّعهم كجزء من اشتراك مدفوع في Copilot.
• وهو يبرع في ذلك: اختيار محايد لجهة الوكيل، ومركز قيادة واحد عبر GitHub وVS Code والجوال وCLI، وعمل يصل إلى مسار مراجعة طلبات السحب الذي تثق به بالفعل.
• حدّه هو المنظومة، لا جهة الوكيل: فهو ينسّق الوكلاء العاملين داخل GitHub، لذا تقع مستودعات GitLab ولوحات Jira والوكلاء العاملون خارج سحابة GitHub خارجه.
• استخدم Agent HQ عندما تكون مؤسسة ملتزمة بالكامل بـ GitHub. واستخدم طبقة محايدة عندما يمزج فريقك بين المضيفين وأنظمة التتبّع وبيئات التشغيل ويحتاج سجلًا مشتركًا واحدًا مع مراجعة عبر جميعها.
• يعمل Sharkly جنبًا إلى جنب مع GitHub، لا بدلًا منه: حافظ على أدواتك، وجلب اشتراكك الخاص، ودع كل عملية تشغيل تعود إلى Task واحد من الطلب حتى الإصدار.

الخطوة التالية صغيرة عن قصد. وصّل Computer واحدًا، وأنشئ Agent واحدًا، وأسند إليه شيئًا مملًا. وتغطي الوثائق كل مفهوم بمزيد من العمق على docs.sharkly.ai.

الأسئلة الشائعة

ما هو GitHub Agent HQ في جملة واحدة؟ هو مركز قيادة داخل GitHub، يحمل العلامة Mission Control، يُسند الوكلاء البرمجيين من عدة جهات ويقودهم ويتتبّعهم كجزء من اشتراك مدفوع في GitHub Copilot، حيث يعمل الوكلاء على فروع ويعيدون طلبات سحب.

أي وكلاء يمكنهم العمل في Agent HQ؟ فتحته GitHub للوكلاء البرمجيين من Anthropic وOpenAI وGoogle وCognition وxAI، بحيث يمكنك اختيار Claude لخطوة وCodex لأخرى دون مغادرة المركز. وتنمو القائمة الدقيقة مع استمرار الإطلاق خلال 2026.

هل GitHub Agent HQ مجاني؟ لا. يُقدَّم عبر اشتراك مدفوع في GitHub Copilot، ويتوقف توفّره على خطط مثل Copilot Pro+ وCopilot Enterprise. راجع صفحات GitHub نفسها لتفاصيل الخطط الحالية، لأنها تتغيّر مع طرحه.

هل يعمل Agent HQ مع GitLab أو Jira؟ ينسّق Agent HQ الوكلاء العاملين داخل منظومة GitHub: مستودعات GitHub وActions وطلبات السحب. أما العمل على GitLab أو Bitbucket، والتخطيط في Jira أو Linear، فيقع خارجه. والطبقة المحايدة فوق كل أداة هي ما يربط تلك العناصر. راجع شرح وكلاء الخلفية في Cursor للنسخة المرتبطة بالمحرر من الحدّ ذاته.

هل عليّ استبدال GitHub لاستخدام Sharkly؟ لا. Sharkly ليس بديلًا عن GitHub أو أي أداة تنفيذ. بل يضيف طبقة Task والسياق والمراجعة المشتركة حول الأدوات التي تستخدمها بالفعل، فيبقى GitHub وCopilot وAgent HQ يعملون تمامًا كما كانوا.

متى يجب ألا أضيف طبقة تنسيق فوق Agent HQ؟ إذا كانت حزمتك بالكامل هي GitHub، والمستودعات وActions وطلبات السحب وCopilot، دون عمل ذي شأن في مكان آخر، فقد يكون Agent HQ كل التنسيق الذي تحتاجه. أضف طبقة محايدة فقط عندما تدير عدة مضيفين أو أنظمة تتبّع أو بيئات تشغيل وتحتاج سجلًا مشتركًا واحدًا عبرها.

هل يغيّر Sharkly طريقة دفعي مقابل النماذج؟ لا. أنت تجلب اشتراكك الخاص. يستمر استخدام النماذج عبر الاشتراكات أو مفاتيح API المهيّأة في أدواتك المتصلة، وتعتمد حصة النماذج على الخطط وحسابات API التي يوصّلها فريقك.

كيف أجرّب نهج الطبقة المحايدة دون ترحيل كبير؟ ابدأ بأصغر سير عمل مفيد: وصّل Computer واحدًا، وأنشئ Agent واحدًا، وأسند Task واحدًا منخفض المخاطر. وتغطيه جولة المهمة الأولى خطوة بخطوة، كما يوضّح تشغيل عدة وكلاء Claude Code بالتوازي الجانب المتعلّق بالأسطول.