Google Antigravity تطلق /swarm: شرح الأدوار الأربعة في البرمجة بالذكاء الاصطناعي مع انتقالها من تنفيذ وكيل واحد إلى تعاون فريق من الوكلاء المتعددين

ملاحظة المؤلف: يعتمد هذا المقال على المدونة الرسمية لـ Google Antigravity ووثائق استخدامه، ويشرح كيف يوزّع /swarm العمل بين عدة وكلاء (Agents)، وآلية تعاونهم، وطريقة عرضهم وإدارتهم بصريًا، وحدود استخدامه.

في 10 نوفمبر 2026 أُتيح Gemini 4 Carbon رسميًا. وفي اليوم نفسه أطلق فريق Google Antigravity ميزة التعاون بين عدة وكلاء /swarm (نسخة تجريبية Preview). يحوّل هذا الأمر محادثة واحدة إلى فريق هندسي من الذكاء الاصطناعي: وكيل يقسّم المهام، وآخر يكتب الشفرة، وثالث يراجعها، ورابع يرصد توقف التقدم.

للميزة سند علني. فقد نُشرت المدونة الرسمية لـ Antigravity ووثائق استخدام Swarm، وذكرت Google أن مهندسيها يستخدمونها داخليًا منذ نحو 5 أسابيع. والفكرة في /swarm ليست فتح عدة نوافذ دردشة في وقت واحد، بل بناء نظام تعاون يحاول تفكيك المهام ذاتيًا، وتنفيذها بالتوازي، ومشاركة التقدم، والتحقق المتبادل، ثم الإصلاح المستمر.

القيمة الأساسية: بعد قراءة هذا المقال ستفهم آلية التنفيذ في /swarm، وكيف تتعاون الأدوار المختلفة، وكيف يراقب المستخدم العمل ويتدخل فيه، وما القيود الفعلية على الحصة والصلاحيات.

Google Antigravity /swarm: المصطلحات الأساسية التي يجدر معرفتها

يقدّم /swarm عددًا من أسماء الأدوار. لنضبط هذه المفاهيم أولًا، لأن فهم الآليات التي تأتي بعدها سيصبح أسهل بكثير.

ما هو Google Antigravity /swarm: نظرة سريعة على المعلومات الأساسية

صدر /swarm بالتزامن مع الإتاحة الرسمية لـ Gemini 4 Carbon، لكنهما شيئان مختلفان. الأول ميزة تنسيق متعدد الوكلاء داخل Antigravity، أما الثاني فهو نموذج. يلخّص الجدول التالي ما أعلنته الجهة الرسمية حتى الآن.

لماذا يصعب على وكيل واحد تولّي مهام هندسية كبيرة

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

توزيع المهام عقبة أخرى. فالوكيل الواحد لا يعمل إلا تسلسليًا: ما دام تعديل الوحدة A لم ينتهِ، يبقى التحقيق في الوحدة B معلّقًا في الانتظار. وكثير من المهام الهندسية قابل في الأصل للتقسيم والتوازي، مثل إصلاح الاختبارات الفاشلة في حزم برمجية مختلفة كلٌّ على حدة، والتنفيذ التسلسلي في هذه الحالات مضيعة للوقت.

أما الجانب الأكثر عرضة للتجاهل فهو التحقق. فالوكيل الذي يكتب الشيفرة هو نفسه من يفحصها، فيسهل عليه أن يستند إلى افتراضاته السابقة وألا يكتشف انحرافًا في طريقة تفكيره. أسلوب فرق العمل البشرية هو أن يراجع شخص آخر الشيفرة (Code Review)، و/swarm ينقل هذا التقسيم للعمل إلى مسار البرمجة بالذكاء الاصطناعي.

كيف يطلق Google Antigravity ‏/swarm فريقًا من الوكلاء (Agents)

وفقًا لوثائق الاستخدام الرسمية، عند تشغيل /swarm <task> تسير الأمور بالترتيب التالي:

1. تحوّل المحادثة الحالية إلى Coordinator: يصبح الوكيل (Agent) الذي تتحدث معه الآن هو المنسّق، ويتولى فهم المهمة الكلية.
2. تقسيم العمل: يقسّم Coordinator المهمة إلى عدة مهام فرعية بحسب بنيتها.
3. إنشاء Worker مستقل لكل مهمة: يقابل كل عمل Worker واحد، ويحصل كل Worker على سياق مستقل ووصف علني للمهمة.
4. التنفيذ والتحقق: يعدّل Worker الشفرة أو يجري التحقيق المطلوب، بينما يفحص Verifier التعديلات ويشغّل الاختبارات، ثم يعيد الملاحظات إلى Worker المعني.
5. حلقة الإصلاح: يعدّل Worker الشفرة بناءً على الملاحظات، ثم تُفحص تعديلاته من جديد.
6. تقرير موجز: يجمع Coordinator نتائج جميع الأعضاء ويرفع تقريرًا إلى المستخدم.

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

/swarm تقسيم الأدوار: Coordinator وWorker وVerifier وMonitor

في الوثائق الرسمية، يتألف فريق Swarm عادةً من أربعة أنواع من الأدوار. ومن الضروري التنبيه إلى أن هذا هو التنظيم النموذجي كما تصفه الوثائق الرسمية، وليس هيكلًا ثابتًا يُطبَّق على كل المهام. فعدد الـ Worker المطلوب إنشاؤهم، والحاجة إلى أعضاء إضافيين من عدمها، يقررهما Coordinator بحسب طبيعة المهمة.

آلية Verifier وMonitor داخل /swarm

تصف مدونة Google الرسمية الـ Verifier بأنه «وكيل تحقّق تخاصمي» (adversarial verification agent). مهمته هي البحث عن المشكلات: فحص تعديلات الوكلاء الآخرين، تشغيل الاختبارات، والاعتراض على التغييرات غير السليمة. يستلم الـ Worker الملاحظات ويُصلح ما لديه، ثم يعيد الإرسال للفحص، فتتشكّل بذلك حلقة مغلقة من التنفيذ والتحقّق.

أما Monitor فيتعامل مع نوع مختلف من المخاطر. عند تعاون عدة وكلاء قد ينشأ موقف ينتظر فيه الجميع بعضهم بعضًا دون أن يدفع أحد العمل إلى الأمام. ينام Monitor في الأحوال العادية، لكنه بمجرد أن يلاحظ أن الفريق توقف بالكامل والمهمة لم تُنجَز، يستدعي الأعضاء المعنيين. بفضله، لا يضطر المستخدم إلى التدخّل يدويًا بالكامل عندما يتعطّل الفريق.

يمكن لأدوار /swarm المختلفة استخدام نماذج مختلفة

تقترح Google في مدونتها الرسمية توزيع النماذج وفقًا لخصائص كل دور، بدلًا من إلزام كل الوكلاء باستخدام النموذج الأغلى:

• استخدام Gemini 4 Carbon: تصميم البنية العامة، تنسيق المهام، مراجعة السلامة، تدقيق الشيفرة المعقّد
• استخدام نموذج أسرع وأخف: التنفيذ البرمجي الروتيني، التعديل المتوازي على الملفات
• استخدام وكيل تحقّق مخصّص: الاختبار والتحقّق الآلي

وفي أمثلة الوثائق الرسمية توجد أيضًا استخدامات تُوكل فيها مهمة تنفيذ الشيفرة والتحقّق المستقل إلى نماذج مختلفة. وهذه مقاربة توازن بين التكلفة والقدرة: الأحكام المعقّدة تُترك للنموذج القوي، وأعمال التنفيذ الكثيفة تُترك للنموذج السريع.

💡 توصية للاختيار: إذا كنت تريد في خط أنابيب متعدد الوكلاء من إنشائك أن ترتّب النماذج حسب الدور، يمكنك أولًا اختبار أداء نماذج مختلفة في مراحل التخطيط والتنفيذ والمراجعة عبر مفتاح API واحد من خلال APIYI على apiyi.com. وبعد أن تتأكد من المرشّح المناسب لكل دور، ثبّت الإعداد؛ ولن يلزمك عند التبديل سوى تغيير معامل model.

/swarm: كيف يتعاون عدة وكلاء (Agents) دون أن يعطّل بعضهم بعضًا

لوحة الرسائل المشتركة: التواصل العلني بين الوكلاء

يستخدم الوكلاء جميعًا لوحة رسائل مشتركة (Shared Message Board) تعمل بنظام الإضافة فقط، وتُسجَّل عليها مراحل التعاون وتقدّم المهام. الرسائل تُضاف ولا يُكتب فوقها، لذلك يبقى سجل التواصل في الفريق كاملًا ويمكن تتبّعه. يستطيع الوكيل أن ينام (Sleep) أثناء انتظار بقية الأعضاء، ثم يُوقَظ عند الحاجة إلى مدخلات جديدة. وتذكر Google أن الانتظار في وضع الخمول لا يستهلك أي رموز (Tokens).

هذا التصميم أكثر شفافية من أن يستدعي الوكلاء بعضهم بعضًا في الخفاء. فملاحظات المدقّق (Verifier) إلى العامل (Worker)، وقرارات المنسّق (Coordinator) في توزيع المهام، كلها معروضة أمام الجميع. وحين يراجع المستخدم ما جرى لاحقًا، يستطيع أن يرى في أي حلقة بالضبط وقعت المشكلة.

الفرق بين مساحة العمل المشتركة ونسخ العمل المستقلة

تختلف صياغة المدونة الرسمية عن صياغة وثائق الاستخدام في هذه النقطة، ولذلك يسهل الوقوع في الخطأ عند الكتابة عنها. تؤكد المدونة أن العمال المتوازين يمكنهم العمل داخل شجرات عمل Git معزولة (Git Worktree)، حتى لا يعدّلوا المجلد نفسه مباشرة. أما وثائق الاستخدام فتذكر قواعد أدق:

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

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

كيف تراقب فريق /swarm وتتحكم به في Antigravity

أكثر ما يُقلق عند عمل عدة وكلاء (Agents) بالتوازي أن لا يعرف المستخدم ما يجري في الداخل. لذلك يوفّر Antigravity ثلاثة عروض أساسية، ويقدّم في CLI اختصارات مقابلة لها.

لا تقتصر سيطرتك على الاطلاع على النتائج. من خلال هذه المداخل يمكنك متابعة مسار عمل كل وكيل، والدخول مباشرة إلى أي Worker للتدخل في عمله، وتعديل متطلبات المهام التي يضعها Coordinator. أما Alt + J وCtrl + K فيدلّان على أن الموافقة على استدعاء الأدوات تبقى بيد الإنسان، إذ يتوقف الوكيل عند أي عملية حساسة وينتظر تأكيدك.

ما المهام الهندسية المعقدة التي يستطيع /swarm حلها

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

أما الأمثلة الواردة في الوثائق الرسمية فهي أقرب إلى عمل التطوير اليومي:

• تعديل عدة معالجات API (Handler) كلٌّ على حدة، وإعداد اختبارات لكل معالج؛
• التحقيق بالتوازي في الأسباب الجذرية لبطء تشغيل CLI؛
• تجميع الاختبارات الفاشلة في مشروع كبير حسب الحزمة البرمجية، ثم توزيعها على وكلاء مختلفين لإصلاحها؛
• إسناد تنفيذ الشفرة إلى نموذج، والتحقق المستقل إلى نموذج آخر.

كما عرضت Google نموذجًا توضيحيًا رسميًا: فبفضل التعاون بين عدة وكلاء في Antigravity، عالج Carbon سبع ملفات PDF عامة للتخطيط العمراني، واستخرج 206 مناظر من الرسوم الهندسية، وأنتج في النهاية نموذجًا معماريًا تفاعليًا بـ Three.js يضم نحو 906,000 مثلث، وقد مرّت العملية بأكملها بعشر جولات تكرارية ليلية. هذه حالة رسمية من Google وليست تحققًا مستقلًا من طرف ثالث، لكنها تُظهر كيف تتوزع الأدوار بين الوكلاء في المهام الممتدة على مدى طويل.

تكلفة /swarm وصلاحياته وقيود نسخة Preview

استهلاك الحصة في بيئة الوكلاء المتعددين

الوكيل الذي ينتظر دون عمل لا يستهلك أي Token، لكن هذا لا يعني أن /swarm يوفّر عليك شيئًا. فكل Worker وكيل مستقل، وعندما يعمل عدة أعضاء في وقت واحد تُستهلك الحصة الإجمالية أسرع بكثير مما في محادثة واحدة. وقد نبّهت Google نفسها إلى هذه النقطة.

وهناك فخ آخر يقع فيه كثيرون: إذا استنفد أحد الـ Workers حصته فإنه يتوقف مؤقتًا، وحتى بعد أن تتجدد الحصة لن يستأنف العمل تلقائيًا، بل يجب أن تعيده إلى العمل يدويًا. لذلك من الأفضل قبل بدء أي مهمة كبيرة طويلة التشغيل أن تقدّر هل ستكفيها حصتك.

صلاحية ميزة Swarm ≠ صلاحية نموذج Carbon

هذه أكثر نقطة تسبب الالتباس. فكونك تستطيع استخدام /swarm لا يعني أنك تستطيع استخدام Carbon داخل Swarm.

بعبارة أخرى، يستطيع مستخدمو Pro تجربة آلية التعاون في Swarm، لكن النماذج التي يمكن للوكلاء استخدامها تظل خاضعة لصلاحيات النماذج في اشتراك كل مستخدم.

تحليل الأثر: كيف يدفع ‎/swarm‎ البرمجة بالذكاء الاصطناعي من «مساعد» إلى «فريق»

الأثر على المطوّرين

• تحوّل الدور: ينتقل المطوّر من «شخص يطرح أسئلة على النموذج» إلى «شخص ينظّم فريقًا من وكلاء الذكاء الاصطناعي»، وهو ما يجعل جودة تقسيم المهام ومعايير القبول عاملاً مباشرًا في النتيجة النهائية.
• التحقق أولاً: آلية Verifier تجعل الاختبار والمراجعة خطوةً افتراضية داخل سير العمل، لا إجراءً إنقاذيًا بعد انتهاء التوليد.
• إدارة التكلفة تصبح مهمة: تشغيل عدة Workers بالتوازي يعني الانتباه إلى الحصص المتاحة وتوزيع النماذج وحجم كل مهمة، لا الاكتفاء بالحكم على التجربة من خلال محادثة واحدة.

الأثر على القطاع

• التعاون بين نماذج متعددة يصبح خيار النشر: نموذج قوي يتولى التخطيط والمراجعة، ونموذج سريع يتولى التنفيذ بالجملة؛ وهذا التقسيم ستستعيره مزيد من أطر عمل الوكلاء (Agent) في المستقبل.
• مركز المنافسة ينتقل إلى تسليم المهام: المنافسة بين النماذج تتحرك من درجات جولة سؤال وجواب واحدة إلى القدرة على التخطيط والتنفيذ والتحقق والتسليم في مهام تمتد على مدى زمني طويل.

استنساخ فكرة /swarm متعددة الوكلاء عبر API: مثال مبسّط

إذا أردت تجربة فكرة «المنسّق يقسّم المهام والعمّال ينفّذونها» في مشروعك، يمكنك كتابة نموذج أولي بسيط باستخدام واجهة متوافقة مع OpenAI. الشفرة التالية توضّح بنية التعاون فقط، وليست تنفيذًا فعليًا لأمر /swarm في Antigravity. استبدل اسم النموذج بنموذج متاح في حسابك.

from openai import OpenAI

client = OpenAI(api_key="YOUR_API_KEY", base_url="https://api.apiyi.com/v1")

def ask(model, prompt):
    resp = client.chat.completions.create(
        model=model, messages=[{"role": "user", "content": prompt}]
    )
    return resp.choices[0].message.content

plan = ask("STRONG_MODEL", "把“修复 3 个 API Handler 的失败测试”拆成独立子任务，每行一个")
for task in [t for t in plan.splitlines() if t.strip()]:
    print(ask("FAST_MODEL", f"完成这个子任务并给出补丁：{task}"))

import concurrent.futures as cf
from openai import OpenAI

client = OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"  # واجهة APIYI المتوافقة مع OpenAI
)

COORDINATOR_MODEL = "STRONG_MODEL"   # التخطيط والتلخيص، استبدله بنموذج قوي في الاستدلال
WORKER_MODEL = "FAST_MODEL"          # التنفيذ الدفعي، استبدله بنموذج سريع وخفيف
VERIFIER_MODEL = "REVIEW_MODEL"      # مراجعة مستقلة، يُفضّل أن يختلف عن نموذج Worker
board = []                           # لوحة رسائل مشتركة تقبل الإضافة فقط

def ask(model, system, prompt):
    resp = client.chat.completions.create(
        model=model,
        messages=[{"role": "system", "content": system},
                  {"role": "user", "content": prompt}],
    )
    return resp.choices[0].message.content

def worker(task, max_rounds=3):
    patch = ask(WORKER_MODEL, "你是 Worker，只负责分配给你的子任务。", task)
    for i in range(max_rounds):
        review = ask(VERIFIER_MODEL,
                     "你是 Verifier，检查补丁问题。没有问题只回复 PASS。",
                     f"任务：{task}\n补丁：\n{patch}")
        board.append(f"[Verifier] {task[:20]}... 第{i+1}轮：{review[:60]}")
        if review.strip().startswith("PASS"):
            return patch
        patch = ask(WORKER_MODEL, "根据审查意见修复补丁。",
                    f"任务：{task}\n原补丁：{patch}\n意见：{review}")
    return patch + "\n# 未通过验证，需人工检查"

goal = "为 users、orders、payments 三个 API Handler 补充输入校验并修复失败测试"
plan = ask(COORDINATOR_MODEL, "你是 Coordinator，把目标拆成互不重叠的子任务，每行一个。", goal)
tasks = [t.strip() for t in plan.splitlines() if t.strip()]
board.append(f"[Coordinator] 拆分为 {len(tasks)} 个子任务")

with cf.ThreadPoolExecutor(max_workers=4) as pool:
    results = list(pool.map(worker, tasks))

summary = ask(COORDINATOR_MODEL, "汇总各 Worker 结果，列出完成情况与风险。",
              "\n\n".join(results))
print("\n".join(board))
print(summary)

🚀 بداية سريعة: عند بناء نماذج أولية متعددة الأدوار كهذه، يُنصح بالحصول على مفتاح API ورصيد تجريبي مجاني للمستخدمين الجدد عبر APIYI على apiyi.com. توفّر المنصة واجهة متوافقة مع OpenAI، فيمكنك استدعاء نماذج OpenAI وClaude وGemini وغيرها ضمن شفرة واحدة، وهذا يسهّل عليك التحقق مما إذا كان الجمع بين “نموذج قوي للتخطيط، ونموذج سريع للتنفيذ، ونموذج مختلف في بنيته للمراجعة” مناسبًا لمشروعك.

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

النقاط الرئيسية حول أمر /swarm في Google Antigravity (Key Takeaways)

• آلية التنفيذ: الأمر /swarm <task> يحوّل المحادثة الحالية إلى منسّق (Coordinator)، فيقسّم المهمة ويُنشئ عاملين (Workers) مستقلين
• توزيع الأدوار المعتاد: المنسّق (Coordinator)، والعامل (Worker)، والمدقّق (Verifier)، والمراقب (Monitor)، وغالبًا يُخصَّص مدقّق واحد لكل 2–4 عاملين
• أسلوب التعاون: لوحة رسائل مشتركة تُضاف إليها الرسائل ولا تُعدَّل، وتجري المراسلات فيها علنًا، والوكلاء (Agents) الذين ينتظرون في وضع الخمول لا يستهلكون أي Token
• قواعد مساحة العمل: مساحة عمل مشتركة افتراضيًا، وتُخصَّص نسخ عمل مستقلة عند الحاجة حين تتعدد التعديلات المتوازية
• التحكم المرئي: ثلاث واجهات هي Board وMembers وGraph، إضافةً إلى أوامر سطر الأوامر مثل /swarm board و/agents
• الحدود الواقعية: الميزة ما تزال في مرحلة المعاينة (Preview)، وتستهلك الحصة بسرعة عند تعدد العاملين، كما أن صلاحيات Swarm لا تساوي صلاحيات Carbon
• التطبيق الذاتي: يمكنك عبر APIYI على apiyi.com استخدام واجهة موحّدة لدمج عدة نماذج وبناء نموذج أولي خاص بك متعدد الأدوار

الخلاصة

أهم ما يجب تذكّره عن /swarm في Google Antigravity:

1. من التوازي إلى التعاون: قيمة /swarm لا تقتصر على التنفيذ المتوازي، بل تكمن في الحلقة الكاملة التي تجمع تقسيم المهام، وسياقًا مستقلًا لكل وكيل، والتحقق التنافسي (adversarial verification)، ومراقبة التقدّم.
2. عزل يُخصَّص حسب الحاجة: يمكن التبديل بين مساحة العمل المشتركة ونسخ العمل المستقلة بحسب طبيعة المهمة، وعلى المستخدم الانتباه إلى توقيت الدمج.
3. قدرة أكبر وتكلفة أعلى: تزيد الوكلاء المتعددون القدرة على معالجة المهام الهندسية المعقدة، لكنهم يستهلكون حصة أكبر ويجعلون إدارة الموارد أعقد، والميزة ما تزال في مرحلة المعاينة.

بالنسبة للمطوّرين، يعني /swarm تغيّرًا في طريقة العمل: لم يعد الأمر مجرد طرح أسئلة على نموذج، بل أصبح تنظيم فريق ذكاء اصطناعي يوزّع المهام وينفّذها ويتحقق منها ويسلّمها. وحتى لو لم تستخدم Antigravity الآن، فيمكنك الاستفادة من فكرة «توزيع النماذج حسب الأدوار وفصل التحقق عن التنفيذ» في أنظمة الوكلاء الخاصة بك. وننصح بتجربة تركيبات النماذج المتعددة بسرعة عبر APIYI على apiyi.com، إذ توفّر المنصة حصة اختبار مجانية وواجهة موحّدة لعدة نماذج.

📚 المراجع

1. الوثائق الرسمية لـ Google Antigravity Swarm: آلية تنفيذ ‎/swarm‎، وإعداد الأدوار، ونسخة العمل، وعمليات سطر الأوامر (CLI)
2. الرابط: antigravity.google/docs/swarm

3. الوصف: مادة أولية عن تفاصيل Coordinator وVerifier وMonitor، وعن عرض Board / Members / Graph

4. مدونة Google Antigravity الرسمية: Gemini 4 Carbon in Google Antigravity

5. الرابط: antigravity.google/blog/gemini-4-carbon-in-google-antigravity

6. الوصف: معلومات إصدار ‎/swarm‎، وبنية الوكلاء المتعددين، وتوصيات توزيع أدوار النماذج

7. إعلان Google الرسمي: Gemini 4 Carbon is now available

8. الرابط: blog.google/innovation-and-ai/models-and-research/gemini-models/gemini-4-carbon-now-available

9. الوصف: نطاق الإتاحة الرسمية لنموذج Carbon وخلفية الإصدار التجريبي لـ ‎/swarm‎

10. صفحة مزايا اشتراك Google AI: صلاحيات النماذج في AI Pro وUltra

11. الرابط: one.google.com/about/google-ai-plans

12. الوصف: التمييز بين مستويات الاشتراك وصلاحيات الوصول إلى نموذج Carbon

13. تقرير نشر من The Verge: Google releases Gemini 4 Carbon with agent swarm feature

14. الرابط: theverge.com/ai-artificial-intelligence/1030787/google-gemini-4-carbon-public-rollout
15. الوصف: خلفية الإصدار وقيود الوصول من زاوية إعلامية مستقلة

المؤلف: فريق APIYI التقني
للتواصل التقني: نرحّب بتواصلكم معنا عبر الصفحة الرئيسية لموقع APIYI (apiyi.com) لمناقشة تطبيقات الوكلاء المتعددين، ولمزيد من مواد التكامل يمكنكم زيارة مركز وثائق docs.apiyi.com

مقالات ذات صلة

• تحليل إطلاق Gemini 4 Carbon: يتفوق على Opus 5.5 بنتيجة 59 نقطة ويفوز في 15 من أصل 17 معيارًا، لكن يتعذر استدعاؤه: تصدّر Gemini 4 Carbon مؤشر الذكاء العام لدى Artificial Analysis بـ59 نقطة، وفاز في 15 من أصل 17 مقارنة رسمية، لكنه لا يملك معرّف نموذج API أو جدولًا زمنيًا للإتاحة؛ ويوضح المقال معايير النتيجة وسبب تعذر استدعائه حاليًا، وإمكانية استخدام المطورين في الصين لـgemini-4-argon مؤقتًا.