يعمل نموذجا Gemini 4 Carbon وHydrogen بأعلى كفاءة كثنائي متكامل: يتولى Carbon التخطيط، بينما يتولى Hydrogen التنفيذ البرمجي. كل ما عليك فعله هو إسناد المهمة (Task) إلى وكيل تخطيط (Planner Agent) يعمل بنموذج Carbon، ليتولى تقسيمها إلى مهام فرعية محددة بمعايير قبول واضحة، ثم تمريرها إلى وكلاء التنفيذ والتحقق (Worker and Verifier Agents) على نموذج Hydrogen، مع إعادة توجيه أي مهمة تفشل مرتين إلى وكيل التخطيط مجددًا. وبذلك، لن تدفع تسعيرة النماذج الرائدة فائقة التطور إلا في المراحل التي تتطلب تفكيرًا وقرارات متقدمة فقط.
لماذا نجمع أساسًا بين نسختي Carbon وHydrogen من Gemini 4؟
أطلقت Google نموذج Gemini 4 Hydrogen في 12 نوفمبر 2026، ووصفته بأنه "المحرك اليومي المعتمد لسير العمل القائم على الوكلاء الأذكياء". وقبل ذلك بيومين، وتحديدًا في 10 نوفمبر، أدرج سجل تغييرات Gemini API نموذج Gemini 4 Carbon كنموذج متاح للجميع عمومًا. وهكذا، أصبح بإمكانك للمرة الأولى هذا الشهر توظيف أقوى نموذج لدى Google مع نموذجها السريع المخصص للتنفيذ لإنجاز نفس المهمة.
ترتكز دعاية Google لنموذج Hydrogen بالأساس على هذا التكامل المشترك؛ إذ يوضح منشور الإطلاق أن Carbon بمقدوره القيام بدور المنسق، في حين يتولى Hydrogen تشغيل "وكلاء التنفيذ والتحقق لبناء التغييرات واختبارها بالتزامن عبر مساحات عمل معزولة". ويضع دليل Gemini API المسألة بعبارات أكثر بساطة ومباشرة: دع Carbon يخطط للواجهات البرمجية أو يحل العقبات المعقدة، ثم فوّض تعديلات الشيفرة ومهام الوكلاء الفرعيين المتزامنة وتشغيل الاختبارات إلى Hydrogen.
يمثل هذا النمط أسلوبًا في التنسيق والتنظيم (Orchestration Pattern) وليس مجرد ميزة في النموذج نفسه، ويمكنك تنفيذه وإدارته بنفسك اليوم. وإذا كنت ترغب في أن تدير منصتك هذا النمط بدلًا من الاعتماد على نص برمجي محلي على جهاز شخصي، فإن منصة Sharkly هي البيئة التي تعيش وتعمل فيها هذه المهام والوكلاء والمراجعات.
آلية عمل منسق Google في فقرة واحدة
يعد Orchestrator خيارًا للنماذج داخل Google Antigravity يقوم بالتبديل التلقائي بين نموذج تخطيط (سواء Carbon أو Argon) ونموذج Hydrogen ضمن المحادثة نفسها. ووفقًا لـ توثيق Antigravity، يبدأ نموذج التخطيط بمرحلة قراءة وفحص فقط، ثم يصيغ خطة متضمنة محفزات صريحة لإعادة التخطيط عند الحاجة، ويسلم بعد ذلك دفة التنفيذ إلى Hydrogen. ويعيد Hydrogen بدوره التحكم إلى المخطط بمجرد مواجهة أي صعوبة أو عائق.
يحدد التوثيق ثلاث إشارات للمشكلات تستحق الاستفادة منها وتطبيقها:
- فشل خطوة تحقق واختبار مرتين متتاليتين.
- سلوك واجهة برمجية يختلف عما كان متوقعًا في الخطة.
- مواجهة قرار تصميمي لم تحسمه الخطة المسبقة.
وتفيد تقارير Google بأنه في اختبار Terminal-Bench، حقق Orchestrator معدل نجاح في المهام يقارب نموذج Carbon، بينما استهلك حصة استخدام (Quota) أقل بنسبة 24% وأنجز العمل أسرع بنسبة 19% في المتوسط. ويُلاحظ وجود تباين بين منشوري Google حول إصدار الاختبار المعتمد (إذ يشير منشور الإطلاق إلى الإصدار 4.0، بينما يشير منشور Antigravity إلى 4.1)، لذا من الأفضل الإشارة إليه باسم Terminal-Bench حتى توضح Google ذلك التضارب.
يعتمد Orchestrator على إبقاء وكيل وحيد داخل محادثتك، ويعمل بإعدادات ثابتة دون تحكم في مستويات التفكير (Thinking Levels)، كما أن إصداره المعتمد على Carbon مقتصر حصريًا على اشتراك Google AI Ultra. في المقابل، تتيح منصات الفرق توزيع هذه المهام عبر عدة وكلاء أذكياء، بحيث تصبح الخطة ومراحل التسليم مرئية وواضحة للجميع.
مقارنة التكلفة: أسعار Gemini 4 Hydrogen مقابل Carbon
أسعار الرموز (Tokens) مأخوذة من صفحة تسعير Gemini API بتاريخ 13 نوفمبر 2026:
| النموذج | معرف النموذج في الواجهة البرمجية (API) | المدخلات / 1 مليون | المخرجات / 1 مليون | الفئة المجانية |
|---|---|---|---|---|
| Gemini 4 Carbon | gemini-4-carbon |
$2.00 حتى 30 نوفمبر، ثم $4.00 | $10.00 حتى 30 نوفمبر، ثم $20.00 | لا تتوفر |
| Gemini 4 Hydrogen | gemini-4-hydrogen |
$1.50 | $7.50 | نعم، بمعدل استخدام محدود |
تحقق من هذه التواريخ جيدًا قبل إعداد ميزانيتك على هذا الأساس. فحتى 30 نوفمبر، سيكون Hydrogen أرخص بنسبة 25% فقط لكل رمز مقارنة بـ Carbon. لكن بدءًا من 1 ديسمبر، يصبح أرخص بنسبة 62.5%. كلا الرقمين يعكسان حساباتنا الدقيقة بناءً على قائمة أسعار Google الرسمية.
ولتوضيح أثر ذلك عمليًا، إليك مثالًا محسوبًا لدورة عمل واحدة: لنفترض جولة عمل لوكيل يقرأ 200 ألف رمز ويكتب 40 ألف رمز (مع احتساب رموز التفكير ضمن المخرجات). باستخدام نموذج Carbon بعد 1 ديسمبر، ستكون التكلفة: 0.80$ + 0.80$ = 1.60$. أما باستخدام Hydrogen، فستكون: 0.30$ + 0.30$ = 0.60$. كرر هذه الدورة 30 مرة يوميًا طوال فترة دورة التطوير (Sprint)، ولن يصبح هذا الفارق مجرد كسور مهملة في الحسابات.
بل إن سعر الرمز الواحد لا يظهر الحجم الكامل للتوفير؛ فوفقًا لـ Google، "يستهلك نموذج Carbon رموز تفكير إضافية في كل جولة لاختبار الفرضيات والتحقق من الحالات الاستثنائية الحافة"، وتكلفة المخرجات تشمل بطبيعة الحال رموز التفكير. وبالتالي، فإن التعديل البرمجي نفسه على Carbon سيستهلك على الأرجح عددًا أكبر من رموز المخرجات بالإضافة إلى سعره الأعلى لكل رمز. ونظرًا لأن Google لم تنشر أرقامًا رسمية لتكلفة المهمة المنجزة بهذا الثنائي مجتمعًا، فمن الضروري قياس ذلك على مستودع الشيفرة الخاص بك قبل تقدير حجم التوفير الفعلي.
أما الجانب الآخر الحاسم فهو السرعة: تؤكد تقارير Google أن Hydrogen ينجز المهام أسرع بمقدار 2.5 مرة مقارنة بنموذج Gemini 3.8 Flash عند مستوى التفكير الافتراضي high.
توزيع العمل بين فريق وكلائك: مواءمة الأدوار مع النماذج
يمثل الفصل بين وكلاء التخطيط والتنفيذ تقسيمًا صريحًا للعمل: يتولى وكيل واحد مسؤولية التخطيط والقرارات البرمجية الصعبة، ويتولى وكلاء بتكلفة أقل مهام التنفيذ، بينما يقوم وكيل التحقق بمراجعة واختبار النتيجة قبل أن يطلع عليها المطور البشري. ويتم تعيين النموذج المناسب لكل دور بما يتوافق مع تكلفته والعمق المطلوب للمهمة.
| الدور | النموذج | مستوى التفكير | المسؤوليات |
|---|---|---|---|
| المخطط (Planner) | gemini-4-carbon |
الافتراضي medium، وhigh للمهام المعقدة |
قراءة قاعدة الشيفرة، صياغة المهام الفرعية بمعايير القبول، وإعادة التخطيط |
| المنفذ (Worker من 1 إلى n) | gemini-4-hydrogen |
high (افتراضي) |
التعديلات، تحديث الحزم البرمجية، الاختبارات، مهمة فرعية واحدة لكل وكيل |
| المتحقق (Verifier) | gemini-4-hydrogen |
high، وxhigh لتعديلات الفروق البرمجية الحساسة والخطرة |
تنفيذ الفحوصات والاختبارات مقارنة بمعايير القبول التي وضعها المخطط |
| المشرف البشري | غير متوفر | غير متوفر | اعتماد خطة المهام الكبيرة، وقبول النتيجة النهائية |
هناك تفصيلان من وثائق Google يحددان خيارات هذا الجدول: أولهما أن مستويات التفكير في Carbon وArgon تكون افتراضيًا medium وبحد أقصى high، في حين يبدأ Hydrogen افتراضيًا من high ويوفر مستوى xhigh إضافيًا. أما الثاني، فهو تحذير Google من أن مستوى xhigh يرفع من زمن الاستجابة واستهلاك الرموز و"قد يؤدي إلى إفراط في التفكير مع المدخلات البسيطة". لذا، يُفضل قصر مستوى xhigh لوكيل التحقق عند فحص التعديلات التي تمس نظم التوثيق والتحقق من الهوية (Auth)، أو المدفوعات، أو ترحيل البيانات الحساسة.
ما الذي ينبغي لوكيل التخطيط كتابته؟
تعد مخرجات وكيل التخطيط بمثابة العقد الملزم لجميع الوكلاء اللاحقين. وتتضمن الخطة المحكمة تحديد مهمة فرعية واحدة لكل تعديل مستقل، ونطاق الملفات المعنية بكل منها، وأمر التشغيل الذي يثبت سلامة عملها، بالإضافة إلى الشرط الذي يوجب إرجاعها إلى المخطط. وإذا عجز الوكيل المنفذ عن معرفة ما إذا كانت مهمته قد اكتملت بنجاح، فهذا يعني أن الخطة لم تكتمل بعد.
متى يعود العمل إلى وكيل التخطيط؟
اعتمد قائمة الشروط التنبيهية التي وضعتها Google واجعلها واضحة ومحددة. يُرجع الوكيل المنفذ المهمة الفرعية في الحالات التالية: إذا فشل فحص التحقق مرتين متتاليتين، أو إذا لم يتطابق سلوك الواجهة البرمجية مع الخطة، أو إذا احتاج إلى قرار تصميمي غير محسوم. وتتم الإعادة مرفقة بسجل الأخطاء، وفروق التعديلات المنجزة حتى تلك اللحظة، والاستفسار المطلوب. ولا ينبغي له أبدًا تكرار المحاولة في الخفاء باستخدام نموذج أكبر وأعلى تكلفة؛ لأن ذلك يخفي التكلفة الحقيقية للفئة الاقتصادية داخل فاتورة الفئة المتقدمة.
طريقة الإعداد في منصة Sharkly
في Sharkly، يمثل الوكيل (Agent) زميل عمل ذكيًا يعمل عبر بيئة تشغيل (Runtime) على جهاز كمبيوتر متصل، بينما يمثل الطاقم (Crew) مجموعة من الوكلاء والأشخاص ينسق أعمالهم وكيل قائد. يتطابق هذا المفهوم مباشرة مع أسلوب توزيع المهام بين المخطط والمنفذ دون الحاجة إلى كتابة أي شيفرات ربط وسيطة؛ إذ يصبح المخطط هو قائد الطاقم، بينما يمثل المنفذون والمتحقق أعضاء ذلك الطاقم.
يمتلك كل وكيل بيئة تشغيله الخاصة ونموذجه الافتراضي، كما هو موضح في اللوحة أعلاه (والتي تعمل بأداة Claude Code). لإتمام هذا الإعداد، امنح كل وكيل بيئة تشغيل قادرة على الاتصال بـ Gemini API، مثل Gemini CLI، ثم عيّن النموذج المخصص لكل وكيل: نموذج Carbon لوكيل التخطيط، ونموذج Hydrogen للوكلاء الآخرين. وإذا لم تظهر المعرفات الجديدة في قائمة النماذج بعد، يمكنك تحديد النموذج يدويًا داخل إعدادات بيئة التشغيل نفسها. كما يقرأ Gemini CLI متغير البيئة GEMINI_MODEL وفقًا لما ورد في مرجع الإعدادات الخاص به، مع دعم الوكلاء لتعيين متغيرات بيئة خاصة بكل وكيل على حدة.
بعد ذلك، اكتب قواعد التنسيق والتكامل داخل تعليمات الطاقم (Crew instructions):
CREW: carbon-plans-hydrogen-builds
Leader: planner (gemini-4-carbon)
1. Read the Task and recent comments. Explore read-only first.
2. Post a plan as a comment: one sub-task per independent change,
file scope, the check command, and the re-plan trigger.
3. If the Task touches more than 3 modules, wait for a person to
approve the plan before mentioning any worker.
4. Mention one worker per sub-task. Mention the verifier last.
Workers: worker-a, worker-b (gemini-4-hydrogen, high)
- Do one sub-task. Run its check. Report the diff and the result.
- If the check fails twice, stop. Report the log and the question
to the leader. Do not widen scope.
Verifier: verifier (gemini-4-hydrogen, high; xhigh for auth/payments)
- Re-run every check from the plan. Pass or fail each one, with output.
A person accepts the result. Nobody merges on an Agent's word.
أسند المهمة (Task) إلى الطاقم. تبدأ آلية التنفيذ بقيادة الوكيل القائد أولًا، وفقًا لما هو موضح في توثيق ميزة Crews: يقرأ القائد المهمة وتعليمات الطاقم، ثم يشير (Mentions) إلى الأعضاء لتكليفهم بمساهمات محددة، لتعود نتائجهم مباشرة إلى نفس مساحة المهمة. استخدم أدلة عمل مؤقتة بحيث يحصل كل عامل على مساحة عمل مستقلة (Worktree) خاصة به. ولا تفعل دليل المهمة المشترك للطاقم إلا عندما تتطلب المهام الفرعية البناء تدريجيًا وبالترتيب على التغييرات المحلية التي أجراها كل عضو.
تظل المهام المعطلة واضحة دومًا: فعمليات التشغيل التي تفشل أو تواجه عوائق تظهر مباشرة في صندوق الوارد (Inbox)، وأي وكيل ينتظر مراجعة بشرية سيظهر في محادثات المهام بالشريط الجانبي؛ وتلك هي النقطة التي يشير إليها السهم المتقطع عندما يتعذر على المخطط معالجة الخطة بمفرده.
تقنيات متقدمة
استخدام ميزة تبديل النماذج في واجهة برمجة التطبيقات لمهمة طويلة واحدة. توضح وثائق Google أنه يمكنك توجيه جولات التخطيط إلى gemini-4-carbon وجولات التنفيذ إلى gemini-4-hydrogen في جلسة واحدة متعددة المراحل باستخدام previous_interaction_id، ودون أي تغييرات في هيكلية البيانات (Schema). تتيح لك هذه الطريقة تطبيق نفس فكرة Orchestrator بمرونة داخل شيفرتك البرمجية المخصصة وفي مسار عمل وكيل منفرد.
الانتباه لحجم الاستجابة في الجولة الواحدة (Hop Sizes). يُرجع Hydrogen ما يصل إلى 65,536 رمزًا في كل جولة عادية غير متدفقة (Non-streaming)، بينما يقتصر Carbon وArgon على 32,768 رمزًا لكل جولة REST غير متدفقة. لذا، احتفظ بعمليات التوليد المطولة—مثل مجموعات الاختبارات الشاملة وتوصيفات عمليات الترحيل—لدى وكيل التنفيذ.
الاستغناء عن التخزين المؤقت الصريح مع Hydrogen. لا يدعم Hydrogen التخزين المؤقت الصريح للسياق (Explicit Context Caching). في المقابل، يعمل التخزين المؤقت الضمني تلقائيًا مع المطالبات التي لا تقل عن 4,096 رمزًا ويمنح تخفيضًا بنسبة 95% على المدخلات المخزنة مؤقتًا، لذا احرص دائمًا على وضع سياق المستودع المشترك في بداية كل مطالبة موجهة لوكلاء التنفيذ.
بدائل الفصل بين التخطيط والتنفيذ
- الاعتماد على Hydrogen بمفرده. تنصح وثائق Google باستخدامه وحده في ترقيات الحزم البرمجية، وإزالة التكرار، وتوليد الهياكل الأولية (Scaffolding)، واختبارات الوحدات للوظائف البرمجية واضحة المعالم، وكتابة التوثيق؛ دون حاجة لوكيل تخطيط.
- الاعتماد على Carbon بمفرده. مناسب لتصميم الأنظمة الموزعة، أو معالجة حالات التسابق (Race Conditions)، أو ترحيل البيانات عبر مستودعات متعددة، حيث تتطلب كل خطوة تفكيرًا عميقًا وتحليلًا وافيًا.
- استخدام Orchestrator في Antigravity. تجربة متكاملة لشخص واحد ومحادثة واحدة مع تسليم آلي للمهام، ومتاحة عبر الخطط التي تدعم هذه الميزة.
- الموجّه الثابت (Static Router). تصنيف المهمة مسبقًا وتوجيهها بالكامل إلى نموذج واحد. وتؤكد Google أن هذا الخيار يتعثر في المهام الطويلة والمعقدة، حيث تتباين درجة الصعوبة أثناء سير العمل. وقد ناقشنا هذا النموذج المسبق بالتفصيل في مقالنا حول توجيه مهام الوكلاء باستخدام Gemini Decisions API.
حالات استخدام عملية من الواقع
فرز ومعالجة البلاغات والمشكلات البرمجية بأعداد كبيرة. يجمع العرض التجريبي لحزمة تطوير Antigravity SDK من Google بين وكلاء Hydrogen لتصنيف المشكلات وكتابة التعديلات مع وكيل Carbon لإعادة هيكلة الشيفرة البرمجية (Refactoring)، وتطوير الميزات الجديدة، وإجراء الفحوصات الأمنية. وعند تطبيق ذلك على منصة العمل، يوضع وكيل Hydrogen لإدارة طابور الاستقبال المباشر، ويتولى وكيل Carbon القيادة لأي مهمة مصنفة كإعادة هيكلة أو فحص أمني.
تقسيم ميزة برمجية إلى مهام فرعية متوازية. يقوم وكيل التخطيط بتقسيم تعديل في واجهة برمجية (API) إلى تحديثات منفصلة للهيكل البرمجي (Schema)، ومعالجات الطلبات (Handlers)، وتطبيقات العميل؛ ليتولى ثلاثة وكلاء تنفيذها في مساحات عمل مستقلة ومتزامنة، بينما يجري وكيل التحقق اختبارات مطابقة العقود البرمجية.
خاتمة
يتولى Carbon التخطيط، وHydrogen البناء والتنفيذ، في حين يرجع القرار النهائي بالقبول إلى المطور البشري. إن هيكل التسعير الجديد يجعل هذا التوزيع استثمارًا مجديًا للغاية بدءًا من 1 ديسمبر، وتضمن مؤشرات الأعطال منع تحول الأخطاء البسيطة غير المكلفة إلى محاولات إعادة باهظة الثمن، فضلاً عن أن منصة العمل تحفظ جميع تفاصيل التسليمات أمام أعين الفريق بأكمله. للاطلاع بتوسع على هذا النمط، يمكنك مراجعة مقالنا حول مفهوم تنسيق الوكلاء الأذكياء وقراءة قواعد توجيه النماذج لفرق العمل الذكية.
خطوتك التالية: اربط جهازًا بمنصة Sharkly، وأنشئ وكيل تخطيط يعمل بنموذج Carbon مع وكيل تنفيذ بنموذج Hydrogen، وضمهما إلى طاقم عمل بالتعليمات الموضحة أعلاه، ثم أسند إليهما مهمة برمجية تستغرق عادةً نصف يوم عمل من مطور بشري. تتيح Sharkly خطة مجانية بالكامل، ولن تتكلف في هذه التجربة سوى رموز استخدام Gemini فقط.
الأسئلة الشائعة
ما الفرق بين Gemini 4 Carbon وHydrogen؟
يمثل Carbon أقوى النماذج الرائدة المتقدمة لدى Google، وقد صُمم خصيصًا لمهام التفكير المنطقي بعيدة المدى، والأعمال المعمارية المعقدة، وتصحيح الأخطاء البرمجية الصعبة، والفحوصات الأمنية. أما Hydrogen فهو النموذج السريع عالي الكفاءة ضمن عائلة Gemini 4، المخصص للمهام البرمجية اليومية وتنفيذ مهام الوكلاء الأذكياء. يضبط Carbon مستوى التفكير افتراضيًا على medium بحد أقصى يصل إلى high، بينما يضبط Hydrogen المستوى افتراضيًا على high مع توفير مستوى xhigh إضافي.
هل نموذج Gemini 4 Hydrogen أقل تكلفة من Carbon؟
نعم. تبلغ تكلفة Hydrogen نحو 1.50 دولار لكل مليون رمز للمدخلات و7.50 دولار لكل مليون رمز للمخرجات. أما Carbon فتبلغ تكلفته 2 دولار و10 دولارات على التوالي حتى 30 نوفمبر 2026، ثم ترتفع إلى 4 دولارات و20 دولارًا بدءًا من 1 ديسمبر. إضافة إلى ذلك، يوفر Hydrogen فئة مجانية بمعدل استخدام محدود عبر Gemini API، وهو ما لا يوفره Carbon.
هل ينبغي تشغيل وكيل التحقق بنموذج Carbon بدلًا من Hydrogen؟
ليس بالضرورة. تقدم Google نموذج Hydrogen كخيار مثالي لكل من وكلاء التنفيذ والتحقق المتزامنين. يمكنك تفعيل مستوى التفكير xhigh لوكيل التحقق عند مراجعة التعديلات الحساسة والخطرة، مع قصر تصعيد المهمة إلى وكيل التخطيط (Carbon) فقط في حال فشل الفحص مرتين متتاليتين.
هل تختار منصة Sharkly النموذج تلقائيًا لكل مهمة؟
لا؛ بل تقوم أنت باختيار النموذج وتحديده لكل وكيل عبر بيئة التشغيل الخاصة به، وتحدد تعليمات الطاقم أي الوكلاء يتولى كل جزء من المهمة. ويقتصر دور Sharkly على احتضان وإدارة مسار المهمة، وعمليات التشغيل، ومراحل التسليم، والمراجعة النهائية.
