ترحيل Antigravity قبل 5 أكتوبر: دليل الوظائف المحلية
دليل عملي لترحيل وظائف Antigravity المحلية قبل 5 أكتوبر، يشرح معرّف الوكيل الجديد وتغييرات محوّل الأدوات والاختبارات اللازمة لتفادي توقف التشغيل.

أمام وظائف Antigravity API المبنية على وكيل مايو من Google مهلة لا تتجاوز 18 يومًا لإتمام ترحيل Antigravity. أطلقت Google الإصدار antigravity-preview-09-2026 في 17 سبتمبر 2026، ويحدد جدول الإيقاف موعد إيقاف antigravity-preview-05-2026 في 5 أكتوبر. إذا كانت وظيفتك تشغّل الأدوات محليًا أو تقرأ خطوات function_call، فالمطلوب هو تعديل محوّل الأدوات، لا مجرد تغيير رقم الإصدار في سطر واحد.
ما الذي يعنيه ترحيل Antigravity فعليًا؟
يتعلق هذا التغيير بـ وكيل Antigravity المُدار ضمن Gemini API، وليس بتحديث لبيئة Antigravity IDE التي تُثبَّت على الكمبيوتر.
يشترك المنتجان في أسس التشغيل، ومن هنا جاء تشابه الاسمين. أما التغيير هنا فيخص معرّف الوكيل الذي يرسله تطبيقك إلى Interactions API من Google، وكذلك — في بعض عمليات التكامل — استدعاءات الأدوات المضمنة التي يعالجها التطبيق. تحديث IDE لا يحدّث عقد API نيابةً عنك.
الوكيل الجديد هو antigravity-preview-09-2026، ونموذج الاستدلال الافتراضي فيه Gemini 3.8 Flash. ويوضح دليل Antigravity Agent كيف يمكن للتطبيق اختيار نموذج آخر مدعوم عبر agent_config. يشرح مقال Gemini Managed Agents السابق مساحة العمل المستضافة والوظائف التي تعمل في الخلفية وحلقة الأدوات. أما هذا الترحيل فيقع في طبقة أعمق: فهو يحدد ما إذا كانت تلك الوظائف ستتمكن من البدء، وما إذا كانت استدعاءات أدواتها ستستمر في التنفيذ.
قسّمت Google الترحيل إلى مسارين في ملاحظات إصدار 17 سبتمبر:
- الوظيفة التي تعمل في بيئة معزولة بعيدة ولا تقرأ سوى
output_textأوmodel_outputتحتاج إلى تغيير سلسلة معرّف الوكيل. - أما الوظيفة التي تستخدم
local_environmentأو تحلل خطواتfunction_call، فعليها أيضًا تحديث محوّل الأدوات.
هذا هو الفاصل الذي يحسم القرار كله. ومحوّل الأدوات هو الجزء الصغير من كود التطبيق الذي يستقبل اسم الأداة ومعاملاتها، ويتحقق منها، وينفذ الإجراء محليًا، ثم يعيد النتيجة.
عقد الأدوات المحلية تغيّر في خمس نقاط
كان الوكيل القديم يتعامل غالبًا مع الملفات من خلال عمليات قراءة وكتابة عامة. أما وكيل سبتمبر، فيمنح عمليات الملفات أسماء ومعاملات أكثر تحديدًا، ويحوّل كذلك أسماء المعاملات من snake_case إلى PascalCase.
تغيّرت خمس مجموعات من إمكانات الملفات والبحث، فيما بقيت الأداتان المدمجتان المذكورتان كما هما. لهذا قد يتعطل معالج عام مبني حول write_file حتى لو كان معرّف الوكيل الجديد صحيحًا.
كذلك أصبح عقد التعديل الجديد أكثر دقة. فبدلًا من إعادة إرسال ملف كامل لإجراء تغيير صغير، يحدد الوكيل نطاق الأسطر والنص المتوقع وجوده والنص البديل. ينبغي أن يرفض المحوّل الاستدعاء إذا لم يعد TargetContent مطابقًا للملف؛ وإلا فقد تكتب وظيفة متأخرة فوق تعديل أحدث أجراه أحد أعضاء الفريق.
أي الوظائف تحتاج إلى ترحيل فعلي؟

مؤسس منفرد لديه وظيفة تقارير بعيدة
لنفترض أن وظيفة ليلية تطلب من Antigravity جمع البيانات داخل بيئة Google المعزولة وحفظ تقرير وإعادة النص النهائي. يقرأ تطبيقك output_text ولا يفحص الخطوات الداخلية إطلاقًا.
هذا هو الترحيل البسيط. غيّر antigravity-preview-05-2026 إلى antigravity-preview-09-2026، وشغّل تقريرًا ممثلًا بالتوازي مع الوظيفة القديمة، وقارن المخرج النهائي، ثم انقل الجدول الزمني. لا داعي لإعادة بناء موزّع أدوات محلي غير موجود أصلًا.
فريق منصة يشغّل الأدوات على أجهزته
لنأخذ الآن عامل مستودع تُنفَّذ استدعاءات أدواته داخل مشغّل الفريق نفسه. فهو يقرأ الملفات، ويبحث في الكود، ويعدّل الإعدادات، ثم يعيد نتائج الأدوات إلى التفاعل.
هذا الفريق مسؤول عن مسار الترحيل الأكبر. يجب أن يتعرّف الموزّع إلى الأسماء الجديدة، ويتحقق من معاملات PascalCase، ويفرض سياسات المسارات والأوامر، ويطبّق تعديلات نطاقات الأسطر بأمان، ثم يعيد النتيجة بالتنسيق الذي يتوقعه التفاعل. والعائد هو استمرارية العمل: تظل مراجعات الكود وإنشاء التقارير ووظائف الصيانة قيد التشغيل بعد اختفاء نقطة نهاية مايو.
فريق مراقبة يستهلك كل خطوة
تُشغّل بعض التطبيقات كل شيء عن بُعد، لكنها تنسخ خطوات function_call إلى سجل تدقيق أو واجهة تقدم أو قائمة انتظار للموافقات أو لوحة تكاليف. هذه التطبيقات لا تُعد من مستهلكي المخرجات النهائية فقط.
حتى إن نفّذت Google إجراء نظام الملفات المضمن، فقد يظل المحلل لديك يفترض وجود write_file وpath وcontent. حدّث قائمة السماح وبيانات الاختبار، حتى لا تصنّف لوحة المتابعة تعديلًا حقيقيًا على أنه غير معروف، أو تسقط معاملاته، أو ترسله إلى سياسة الموافقة الخاطئة.
مسؤول عمليات لديه مشغّلات تعمل بلا إشراف
المشغّلات المجدولة هي الحالة الأعلى خطرًا، لأن أحدًا لن يكون حاضرًا عند إطلاق الاستدعاء. يربط المشغّل بين وكيل وبيئة وموجّه وجدول cron. وإذا ظل التفاعل المخزّن يشير إلى وكيل مايو، فقد يبدو الجدول سليمًا بينما يفشل التنفيذ الذي يقف خلفه بعد الإيقاف.
احصر معرّف الوكيل داخل تعريف كل مشغّل، وليس فقط في استدعاء SDK داخل تطبيقك الرئيسي. ثم نفّذ تشغيلًا موازيًا لوظيفة واحدة من كل نمط أدوات متميز. فوظيفة التقارير ووظيفة إصلاح المستودع لا تمثلان اختبار الترحيل نفسه لمجرد أن كلتيهما تستخدم Antigravity.
اختبار صغير لعقد تعديل الملفات
لا يحتاج الاختبار الأول الأكثر أمانًا إلى بيانات اعتماد الإنتاج. مرّر إلى المحوّل بيانات اختبار محفوظة تحاكي شكل الاستدعاء، وعدّل ملفًا مؤقتًا، ثم تحقّق من أن السطر المقصود وحده قد تغيّر.
شغّلت المثال التالي باستخدام Node وبالاسم replace_file_content وحقول PascalCase المنشورة من Google. هذا اختبار محلي للمحوّل، وليس استدعاءً مباشرًا إلى Gemini API.
import assert from "node:assert/strict";
import { mkdtempSync, readFileSync, writeFileSync } from "node:fs";
import { tmpdir } from "node:os";
import { join } from "node:path";
function applyReplaceFileContent(call) {
assert.equal(call.name, "replace_file_content");
const {
TargetFile,
StartLine,
EndLine,
TargetContent,
ReplacementContent,
} = call.arguments;
const lines = readFileSync(TargetFile, "utf8").split("\n");
const current = lines.slice(StartLine - 1, EndLine).join("\n");
assert.equal(current, TargetContent, "line window no longer matches");
lines.splice(
StartLine - 1,
EndLine - StartLine + 1,
...ReplacementContent.split("\n"),
);
writeFileSync(TargetFile, lines.join("\n"));
}
const dir = mkdtempSync(join(tmpdir(), "antigravity-adapter-"));
const file = join(dir, "scheduled-job.env");
writeFileSync(file, "owner=ops\nstatus=old\nmode=scheduled\n");
applyReplaceFileContent({
name: "replace_file_content",
arguments: {
TargetFile: file,
StartLine: 2,
EndLine: 2,
TargetContent: "status=old",
ReplacementContent: "status=ready",
},
});
assert.equal(
readFileSync(file, "utf8"),
"owner=ops\nstatus=ready\nmode=scheduled\n",
);
console.log("PASS: line 2 changed from status=old to status=ready");نجح الاختبار. والأهم أن تغيير TargetContent في بيانات الاختبار يجعله يتوقف بدلًا من تعديل محتوى قديم.
صنّف عملية التكامل
دوّن ما إذا كانت كل وظيفة تستهلك المخرجات فقط، أو تحلل الخطوات، أو تنفذ أدوات محلية، أو تجمع أكثر من حالة. نفّذ هذا التصنيف لكل عائلة وظائف، لا لكل مستودع.
احفظ بيانات اختبار واقعية
شغّل وكيل سبتمبر في مسار غير إنتاجي، واحفظ خطوات
function_callالممثلة لإنشاء الملفات وتعديلها وقراءتها وسردها والبحث فيها. تحقّق من ترقيم الأسطر الفعلي وغلاف النتيجة في تلك الاستدعاءات المحفوظة قبل نقل الاختبار المحلي إلى الإنتاج.اختبر مسار الرفض
غيّر
TargetContent، ووجّه استدعاءً إلى خارج مساحة العمل المسموح بها، وقدّم اسم أداة غير معروف. يجب أن تُرفض كل حالة افتراضيًا وأن تنشئ سجل تدقيق.شغّل وظيفة كاملة بالتوازي
استخدم معرّف الوكيل الجديد والمحوّل الجديد وبيئة مؤقتة. قارن المخرج النهائي وتتبع الأدوات والموافقات ووقت التشغيل واستهلاك الرموز بالوظيفة الحالية قبل نقل جدولها الزمني.
الحسبة التجارية: جهد الترحيل في مقابل العمل المفقود
لم تعلن Google سعرًا جديدًا لكل رمز مع ترحيل هذا الوكيل. بند الميزانية الذي تغيّر هو وقت الهندسة والعمليات.
استخدم معادلتين مباشرتين:
تكلفة الترحيل = وقت هندسة المحوّل + إنفاق API للتشغيل الموازي + وقت المراقبة
التعرض لخطر التوقف = عدد مرات التشغيل المجدولة الفائتة × قيمة كل تشغيل + جهد الإصلاح
بالنسبة إلى وظيفة بعيدة لا تستهلك سوى المخرجات، قد يقتصر الجهد الهندسي على تغيير سلسلة معرّف الوكيل وتشغيل موازٍ واحد. أما التكامل الذي يستخدم أدوات محلية، فضع في الميزانية خمس مجموعات إمكانات تغيّرت، وبيانات اختبار للمحلل، واختبارات أمان، وتشغيلًا كاملًا واحدًا لكل شكل مختلف من سير العمل.
لا تحوّل ذلك إلى تقدير ساعات عام ومصطنع. فمولّد التقارير محدود النطاق يختلف عن وكيل برمجة محلي في تغطية الأدوات ومنطق الموافقات وتكلفة الفشل. أدخل في المعادلتين تكلفة ساعة المهندس الشاملة لديك، والقيمة التجارية لكل تشغيل. هكذا يحصل فريق المالية على قرار حقيقي، لا قائمة مزايا من المورّد.
ما ينبغي قوله بصراحة
يثبت الاختبار المحلي أعلاه أن بيانات الاختبار والمحوّل متوافقان. لكنه لا يثبت ما سيصدره وكيل حي لكل موجّه. لم تتوفر بيانات اعتماد Gemini API في هذا التشغيل، لذلك لم أدّعِ تنفيذ الوكيل المستضاف. بوابتك الأخيرة هي استدعاء محفوظ لوكيل سبتمبر داخل بيئة مؤقتة.
كذلك لا يفرض هذا الحدث مقدار العمل نفسه على جميع مستخدمي Antigravity:
- تحرّك هذا الأسبوع إذا كانت وظيفة إنتاجية تشير إلى
antigravity-preview-05-2026، أو تستخدمlocal_environment، أو تحلل خطواتfunction_call، أو تعمل وفق جدول زمني من دون إشراف. - اسلك المسار البسيط إذا كانت الوظيفة تعمل في بيئة معزولة بعيدة ولا تستهلك سوى
output_textأوmodel_output. غيّر المعرّف وشغّلها بالتوازي. - ابدأ مباشرة بالمعرّف الجديد إذا كنت لا تزال تقيّم API وليس لديك وظائف إنتاجية تستخدم وكيل مايو.
- تجاهل هذا الترحيل إذا كنت تستخدم Antigravity IDE وحده ولا تستدعي الوكيل المُدار عبر Gemini API.
خطوتك يوم الاثنين
كلّف شخصًا واحدًا بمسؤولية الحصر. ابحث في إعدادات النشر وتعريفات المشغّلات ومتغيرات البيئة ولوحات المتابعة وبيانات الاختبار عن معرّف وكيل مايو وأسماء الأدوات القديمة. قسّم النتائج إلى قائمتين — مخرجات فقط، أو محوّل مطلوب — قبل أن يبدأ أحد بتغيير الكود.
بعد ذلك، رحّل وظيفة ممثلة من كل قائمة. أبقِ الجدول القديم متوقفًا مؤقتًا لكن متاحًا أثناء فحص تشغيل سبتمبر، ثم انقل بقية الوظائف بحسب عائلة سير العمل، وضع تنبيهًا لاستدعاءات الأدوات المجهولة حتى 5 أكتوبر. المطلوب تسليمه يوم الاثنين ليس عرضًا تقديميًا، بل حصر يحدد المسؤولين، وتشغيل موازٍ ناجح، وتاريخ لكل وظيفة متبقية.
لمزيد من الملاحظات التشغيلية المبسطة حول التغييرات التي قد تعطل سير العمل الفعلي، اشترك في النشرة البريدية.
- آخر تحديث
- 18 سبتمبر 2026
- التصنيف
- Explained







