تشغيل وكيل الذكاء الاصطناعي بمليون توكن: تحدي مراجعة لا إنجاز سرعة

أصبح نموذج Gemini 4 Argon متاحًا للعموم منذ 13 أكتوبر 2026، وهو يرفع الحد الأقصى لمخرجات Google من 64 ألف رمز (tokens) إلى نحو مليون رمز، مما يتيح للنموذج "توليد مئات الآلاف من الرموز في مسار واحد". ويوضح دليل مطوري Google كيفية عمل ذلك. لا يزال الطلب العادي يتوقف افتراضيًا عند 65,536 رمزًا من رموز المخرجات. ولكن عند ضبط max_output_tokens على قيمة أعلى عبر Interactions API مع تفعيل background: true، يواصل الخادم التوليد عبر قفزات تصل إلى 64 ألف رمز حتى يبلغ الحد الأقصى، أي ما يصل إلى 1,048,576 رمزًا مطروحًا منها رموز المدخلات الخاصة بك. وتحذر Google من أن المدخلات (prompts) المعقدة قد تستغرق عدة دقائق.

العبارة الجديرة بالقراءة المتأنية في منشور الإطلاق ليست ذلك الحد الأقصى نفسه، بل ما فعلته Google بمخرجات بهذا الحجم. تذكر Google أنها استخدمت Argon داخليًا في مشاريع ترحيل الشيفرة البرمجية من C/C++ إلى Rust، بدءًا من "عشرات الآلاف من الأسطر في مكتبات أساسية مثل re2 وlibgav1 وصولًا إلى أكثر من 800 ألف سطر لنواة Fuchsia Zircon"، وأن عمليات إعادة الكتابة هذه "تخضع لتدقيق آلي ويدوي صارم، واختبارات محاكاة، ومراجعة دقيقة قبل إطلاقها في بيئة الإنتاج". فالمختبر الذي درّب النموذج لا يزال يراجع الشيفرة قبل شحنها. وأي فريق تستطيع وكلاؤه (agents) الآن إرجاع نتائج تحت سقف أعلى بست عشرة مرة، يحتاج إلى خطة مراجعة قبل أن يحتاج إلى النموذج نفسه.

خلاصة سريعة (TL;DR)

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

ما الذي يتغير عندما تنتج عملية تشغيل واحدة هذا الكم الهائل؟

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

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

كما أن هذا السقف مشترك؛ إذ تشمل نافذة Argon البالغة 1,048,576 رمزًا كلاً من المدخلات والتفكير والمخرجات معًا. وبالتالي، فإن عملية التشغيل التي تقرأ 300 ألف رمز من الشيفرة يتبقى لها نحو 748 ألف رمز للتفكير والكتابة. ويظل هذا المقدار أكبر مما يمكن لأي شخص قراءته سطرًا بسطر في جلسة واحدة.

ثم هناك مسألة الجودة. فعند الإعلان، ذكرت بلومبرغ نقلًا عن موظفين مجهولين في Google أن أداء Argon لم يكن على قدر التوقعات في بعض مهام البرمجة والواجهات الأمامية مقارنة بنتائج اختبارات القياس (benchmarks) الخاصة به، واعتبرت Google ذلك غير دقيق. إلا أن جدول Google نفسه يوضح تأخر Argon في صفين من أصل أربعة صفوف مخصصة لمهام البرمجة الوكيلة (agentic coding) (تفصل مقارنتنا هذه الحالات). فاختبارات القياس ليست سوى ادعاء يستند إلى مجموعة بيانات اختبارية؛ أما فروق التعديلات (diff) فهي ادعاء يتعلق بقاعدة الشيفرة الفعلية لديك، ولا تُقبل إلا بناءً على الأدلة، أيًا كان النموذج الذي كتبها.

حدد نطاق المهمة، لا ميزانية الرموز

الوحدة التي تتحكم بها هي المهمة (Task)، وليست عدد الرموز. فإذا تركت سقف النموذج يحدد حجم العمل، فستحصل على أضخم نتيجة يمكنه إنتاجها؛ أما إذا حددته بنفسك، فستحصل على نتائج يستطيع المراجع البشري قبولها. وتتوافق إرشادات Google نفسها مع هذا المبدأ: التزم بالحد الافتراضي البالغ 65,536 للمهام القياسية، واستخدم الوضع في الخلفية عند 131,072 أو 262,144 رمزًا لمهام الاستدلال المعقدة والبرمجة، دون الوصول إلى الحد الأقصى.

حتى توصيف Google نفسه يجزئ العمل بالفعل بحسب المكتبة والنواة. قسّم عملية ترحيل الشيفرة بالأسلوب نفسه: مهمة واحدة لكل وحدة برمجية (module) يستطيع المراجع إنهاءها في جلسة واحدة. وفي Sharkly، يتم ذلك بإنشاء مهمة رئيسية تضم مهامًا فرعية لكل وحدة برمجية، إلى جانب روابط "يعطل / معطل بواسطة" (blocks / is blocked by) عندما يتعين إنجاز وحدة معينة أولًا. ويوثّق الهدف والنطاق ومعايير القبول في وصف المهمة، ليكون مرجعًا للوكيل (Agent) والمراجع على حد سواء:

SH-412  Port the tokenizer module to Rust
Parent: SH-400  Port the parser library to Rust
Blocked by: SH-411  Port the shared buffer types

Done when:
- the Rust module replaces src/tokenizer/ and nothing outside it changes
- the existing test suite passes against the Rust build without edits
- a differential run over the fixture corpus produces identical output
- the report lists every unsafe block and the reason for it
Out of scope: public API changes, performance work

يدعم هذا الأسلوب إعدادان في الوكيل (Agent): المهلة الزمنية لكل مهمة (per-Task timeout) التي تُحدد وفقًا لطبيعة المهمة لا لإمكانيات النموذج، بحيث تتجاوز أطول مدة تشغيل فعلية لوحدة برمجية واحدة، وتظل دون المدة التي قد تندم على دفع تكلفتها؛ والحد الأقصى للتزامن (Max concurrency للمهام المسندة) الذي يضع سقفًا لعدد الوحدات البرمجية قيد المعالجة في الوقت نفسه، لأن تشغيل أربعين مهمة فرعية بالتوازي سينتج عنه أربعون نتيجة تنتظر المراجع نفسه.

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

أرفق الأدلة داخل المهمة

إن النتيجة الضخمة الخالية من الأدلة لا تعد مراجعة، بل هي إعادة تشغيل بطيئة يجريها إنسان.

يقدم مثال libgav1 نموذجًا واضحًا لما تبدو عليه الأدلة الجيدة؛ حيث تذكر Google أن Argon استبدل 32 ألف سطر من شيفرة SIMD في مشروع ترحيل سابق إلى Rust، وكانت النتيجة "تعمل أسرع بمقدار 2.7 ضعف مقارنة بنسخة Rust، مع تطابق تام في مخرجات الفيديو". النصف الثاني من تلك العبارة هو ما يجعل مراجعة 32 ألف سطر أمرًا ممكنًا: فقد مرت المدخلات نفسها عبر الشيفرتين القديمة والجديدة وجاءت المخرجات متطابقة تمامًا. هذا هو الاختبار التفاضلي (differential testing)، وهو ما يحرر المراجع للتركيز على ما تعجز المقارنة الآلية عن رصده: الشيفرات غير الآمنة (unsafe code)، ومسارات معالجة الأخطاء، وما إذا كان تحسن الأداء سيصمد تحت أعباء العمل الفعلية.

يجب أن تعيد كل عملية تشغيل أربعة عناصر إلى المهمة:

هذا هو المسار الذي يصفه سير العمل في Sharkly: يقوم الوكيل (Agent) بتدقيق الأنواع وإجراء الاختبارات وعملية البناء، ثم يُرفق ملخص التغييرات ونتائج التحقق والقيود المعروفة؛ وبعدها يتولى شخص قبول التعديل، أو طلب تغييرات، أو تحديد خطوة الدمج والإصدار. يُحفظ الرد النهائي للوكيل داخل المهمة، بينما يُسجل سجل التنفيذ في تبويب Executions، وبذلك تعود الأدلة إلى المهمة مباشرة بدلًا من البقاء في موجه الأوامر (terminal). يوضح مقال المراجعة بالاعتماد على أدلة المهمة الترتيب الأمثل للقراءة، بينما توفر قوالب التسليم صياغة موحدة للتقرير.

اجتياز الفحوصات ليس قبولًا نهائيًا، وكذلك ليس دمج الشيفرة: ففي Sharkly، لا يؤدي دمج طلب السحب (pull request) المرتبط إلى تغيير حالة المهمة. الفحوصات الآلية تتحقق مما تملكه من قدرات، ويوضح مقال وكلاء مراجعة الشيفرة بالذكاء الاصطناعي حدود تلك القدرات. ويبقى القرار بيد الإنسان ليحدد ما إذا كان التغيير يحقق بالفعل ما طُلب في المهمة.

احسب سعة المراجعة قبل بدء التشغيل

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

بالاكتفاء بفحص الفروق فقط، تتطلب عملية الترحيل 80 ساعة مراجعة، أي نحو 27 يوم عمل. أما مع وجود أدلة موثقة لكل مهمة، فتنخفض التكلفة إلى 20 ساعة، أي نحو سبعة أيام. وسواء أكانت العملية تشغيلًا واحدًا ضخمًا أم أربعين تشغيلًا أصغر، فإن العبء الواقع على المراجع يبقى بالحجم نفسه.

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

ثم احسب التكاليف المالية. فعملية تشغيل تبلغ الحد الأقصى تنتج نحو مليون رمز من المخرجات: أي ما يقارب 10 دولارات بمعدل 10 دولارات لكل مليون رمز حتى 30 نوفمبر، ونحو 20 دولارًا بدءًا من 1 ديسمبر. وفي مشاريع المستوى الأول (Tier 1)، يبلغ حد الإنفاق المحدد من Google‏ 10 دولارات لكل نافذة زمنية متجددة مدتها 10 دقائق، مما يعني أن تشغيلًا واحدًا بالحد الأقصى يستنفد ميزانية النافذة بالكامل وفق المعدل الحالي، وضعف ذلك الحد بدءًا من 1 ديسمبر. لذا، احرص على إبقاء الحد الأقصى للتزامن (Max concurrency) منخفضًا لأي وكيل مسموح له بإجراء عمليات تشغيل بهذا الطول.

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

قائمة تحقق قبل أول تشغيل يصل إلى مليون رمز

• [ ] تقسيم العمل إلى مهام (Tasks) يستطيع المراجع إنهاءها في جلسة واحدة، مدعومة بمهام فرعية وروابط "معطل بواسطة" (blocked by).
• [ ] يوضح وصف كل مهمة معايير الاكتمال وما يقع خارج نطاق العمل بدقة.
• [ ] توافق المهلة الزمنية لكل مهمة طبيعة المهمة نفسها (فالطلبات الطويلة في الخلفية تستغرق دقائق)، لا الحد الأقصى لمخرجات النموذج.
• [ ] توافق عملية التشغيل القصوى حدود الإنفاق الخاصة بفئة واجهة برمجة التطبيقات (API tier) لديك.
• [ ] تناسب الحد الأقصى للتزامن (Max concurrency) لدى الوكيل للمهام المسندة مع ما يستطيع المراجعون إنجازه، لا ما يمكن للحاسوب تشغيله.
• [ ] إرجاع كل عملية تشغيل ملخصًا للتغييرات، ومخرجات الفحص، وتفاصيل ما تم التحقق منه، والقيود المعروفة.
• [ ] اشتمال الأعمال التي تهدف للحفاظ على السلوك البرمجي على فحص تفاضلي مقارنة بالشيفرة القديمة.
• [ ] تحديد مراجع مسمى لكل مهمة، وأن يكون قبول التعديل عبر تغيير الحالة بواسطة ذلك الشخص، وليس كأثر جانبي لعملية الدمج.

لا يعتمد أي من هذا على Argon بحد ذاته، إذ يمكن لأي مفتاح Gemini API مدفوع استدعاؤه الآن. وتبقى عبارة Google هي النموذج المرجعي: مخرجات ضخمة، تليها عمليات تدقيق واختبارات محاكاة ومراجعة دقيقة، ثم إطلاق في بيئة الإنتاج. وأيًا كان المختبر الذي سيطلق القفزة التالية في حجم المخرجات، فإن خطة العمل تُبنى على المهمة، لا داخل النموذج. Sharkly لا تختار النماذج بنفسها: فوفقًا لـ توثيق الوكلاء (Agents)، يتبع الوكيل النموذج الافتراضي لبيئة التشغيل الخاصة به (Runtime)، والتي يمكن تعديلها عبر وسائط مخصصة (Custom arguments) أو إعدادات الأداة. وعندما يتوفر نموذج أكبر لبيئة تشغيل تستخدمها، تتغير تلك القيمة وتبقى المهام والأدلة وبوابة المراجعة ثابتة في مكانها؛ ليظل السياق والتقدم والعوائق والنتائج والمراجعة البشرية واضحة للعيان من مرحلة الطلب وحتى مرحلة الإصدار.

إذا كنت تشغّل بالفعل عدة وكلاء، فإن Sharkly تمنحك مكانًا واحدًا لإدارة مهامهم ونتائجهم.