يصف منشور إطلاق نموذج Muse Wonder من شركة Meta سلوكًا يُطلق عليه اسم «التركيز النشط» (Active Focus)؛ إذ يواصل النموذج العمل لتحقيق أهداف معقدة، ويجرب أساليب بديلة، ويتجاوز العقبات، كما يطلب التوضيح عند الحاجة ويتحقق من الخطوات قبل الإقدام على إجراءات مهمة، وفقًا لتعبير Meta. وتوصي Meta أيضًا بالحصول على تأكيد بشري قبل اتخاذ أي إجراءات ذات تبعات مؤثرة، كما يُرفق دليل وكلاء البرمجة (coding-agents guide) الخاص بها أداة Muse Code مزودةً بنظام الموافقات وبيئة معزولة (sandbox) قيد التشغيل منذ أول تشغيل لها.
هذا هو التصميم الأمثل بالفعل. غير أنه يثير تساؤلًا تدركه مسبقًا جميع الفرق التي تشغّل الوكلاء بالتوازي: عندما يتوقف النموذج ليسأل، مَن سيتولى الرد عليه، وبأي سرعة، وما السياق المتاح أمامه؟ إن طلب التحقق الذي يظهر على نافذة طرفية لا يراقبها أحد يعني تشغيلًا متوقفًا. أما طلب التحقق الذي يصل إلى صندوق وارد (Inbox) مشترك، ملحقًا بالمهمة (Task) التي نشأ عنها، فهو خطوة مراجعة حقيقية. ويتناول هذا المقال كيفية بناء هذا النوع الثاني.
ما ينتجه التركيز النشط
درّبت Meta النموذج على ثلاثة سلوكيات، وتقيسها عبر معيار تقييم داخلي تطلق عليه FocusBench؛ حيث يتصدر النموذج الكامل Muse Wonder Full بنسبة 54.2%، بينما يحقق نموذج Wonder المتاح عبر واجهة برمجة التطبيقات نسبة 44.9% متأخرًا عن GPT-6 Astra وClaude Opus 5.5. وبمعزل عن هذه الأرقام، فإن هذه السلوكيات هي ما يهم حقًا عند إدارة لوحة المهام:
- المثابرة (Persistence): يستمر النموذج في المحاولة رغم مواجهة الإخفاقات؛ ففي اختبار SWE-Marathon المخصص للبرمجة طويلة الأمد، حقق Wonder نتيجة 53.1 مقابل 46.3 لنموذج Opus 5.5. ويعني هذا تشغيلات أطول، ومحاولات أكثر، ومحتوى أوسع يتطلب المراجعة.
- طلب التوضيح (Clarification): يسأل النموذج عند غموض المهمة بدلًا من التخمين؛ ويظهر ذلك على لوحة المهام في صورة تعليق عليها، بينما يظهر في الطرفية كمطالبة تنتظر ضغطة زر.
- طلبات التحقق (Check-ins): يتوقف النموذج مؤقتًا قبل أي إجراء يراه مهمًا. وتنصح Meta نفسها بجعل هذا التوقف تأكيدًا بشريًا لكل ما له تبعات مؤثرة.
يُغيّر كل سلوك من هذه السلوكيات شكل قائمة انتظار المراجعة؛ فالمثابرة تزيد من حجم العمل المطلوب مراجعته في كل مهمة، وطلب التوضيح يُضيف مقاطعات لمسار العمل، أما طلبات التحقق فتضيف قرارات تُعطّل التشغيل حتى يبتّ فيها أحد.
أين تستقر طلبات التحقق؟
في أداة Muse Code، تظهر مطالبة الموافقة في نافذة الطرفية الخاصة بالمشترك ويتوقف التشغيل في انتظار الرد. أما في عمليات التشغيل دون واجهة تفاعلية (muse exec)، فلا توجد مطالبة تفاعلية، ولذلك تذكر وثائق Meta أنه يجب إما اختيار سياسة تتيح إكمال العمل دون إشراف، أو توقع بقاء الإجراءات المعلقة دون حل. تلك هي المقايضة الصريحة: إما أن يكون هناك شخص أمام لوحة المفاتيح، أو يعمل النموذج مع تعطيل الموافقات، أو يظل الإجراء معلقًا إلى الأبد.
أما على لوحة Sharkly، فإن عملية التشغيل تكون عبارة عن مهمة (Task) مسندة إلى وكيل (Agent) يعمل على جهاز حاسوب (Computer). وعندما يتوقف الوكيل ليسأل، يعود السؤال إلى المهمة كتعليق، ويُوجَّه مباشرة إلى صندوق الوارد (Inbox). وتحتفظ المهمة بالسياق كاملًا: ما طُلب تنفيذه، وما أنجزه الوكيل حتى تلك اللحظة، وسجل تنفيذ استدعاءات الأدوات وأحداث بيئة التشغيل (Runtime). ومن ثم، يستطيع أي شخص يتولى متابعتها أن يرد عبر المهمة نفسها، مما يمنح عملية التشغيل نقطة انطلاق واضحة للاستئناف. وهكذا يبقى التحقق قرارًا بشريًا، ولكنه قرار موثق بسجل وقائمة انتظار، ويمكن لأكثر من شخص اتخاذه.
هذا هو الفارق الحقيقي بين وجود إجراء وقائي وبين تعطل العمل كليًا. فسلوك النموذج متطابق في الحالتين، لكن النظام المحيط به هو الذي يحدد ما إذا كان طلب التحقق سيستغرق دقيقة واحدة أم يومًا كاملًا.
صياغة تعليمات الوكيل لجعل طلبات التحقق مجدية
ترتبط جودة طلب التحقق دائمًا بجودة السؤال نفسه. لذا، ضع معيار السؤال الجيد ضمن تعليمات الوكيل:
Stop and ask before anything destructive, anything that sends data outside the
attached repositories, any payment or external account action, and any change
to CI, deploy or access configuration.
When you ask, state in one comment: what you are about to do, why the Task needs
it, what you considered instead, and what happens if the answer is no.
Do not ask about reversible edits inside the repository. Make them, test them,
and report.
If you have waited for an answer and the Task has a deadline, say so in a second
comment rather than proceeding.
ترسم القاعدة الأولى الحد الفاصل؛ فنموذج Meta يقرر بمفرده ما يعتبره مهمًا، بينما توضح له هذه التعليمة ما يراه الفريق مهمًا بالفعل. وتجعل القاعدة الثانية التعليق قابلًا للرد عليه في ثلاثين ثانية من قِبل شخص لم يتابع مجريات التشغيل منذ البداية. وتمنع القاعدة الثالثة النموذج من السؤال عن كل صغيرة وكبيرة، وهو نمط الإخفاق الذي يحول الوكيل الحريص إلى وكيل مزعج. ويتناول مقال ضوابط الحماية لنموذج Opus 5.5 الحدود ذاتها من زاوية حقن التعليمات البرمجية (prompt injection): فبوابة المراجعة هي وسيلة التحكم الحقيقية، بغض النظر عما يعد به النموذج.
تقدير حجم قائمة الانتظار
المثابرة تعني مزيدًا من المراجعة لكل مهمة، وليس العكس؛ فخطط للأمر على هذا الأساس.
| المسار (Lane) | مسار التشغيل النموذجي | ما يصل إلى قائمة الانتظار |
|---|---|---|
| Muse Wonder في مهمة طويلة | خطوات كثيرة، ومحاولات متعددة تم التراجع عنها | فروقات برمجية (diff) أطول، وسجل أطول، وما بين صفر إلى ثلاثة طلبات تحقق |
| Opus 5.5 في المهمة ذاتها | خطوات أقل، وقرارات أكثر حسمًا | فروقات برمجية (diff) أقصر، أو مهمة مُعادة غير مكتملة |
| أي نموذج يعمل ليلًا دون إشراف | كل ما سمحت به السياسة المتبعة | إما إجراءات معلقة، أو إجراءات لم يؤكدها أحد |
توجد ثلاث ممارسات تضمن استمرار حركة قائمة الانتظار بسلاسة: أولًا، وجّه طلبات التحقق إلى مراجع محدد بالاسم لكل مسار بدلًا من توجيهها للجميع، حتى لا يظل السؤال معلقًا في انتظار رد جماعي. ثانيًا، حدد مهلة زمنية (timeout) لكل مهمة ينفذها الوكيل، بحيث تظهر عملية التشغيل المعلقة بسبب طلب تحقق كعملية متعثرة بشكل واضح بدلًا من أن تظل في حالة تشغيل لساعات. ثالثًا، اقرأ السجل ولا تكتفِ بمراجعة الفروقات البرمجية (diff) في تشغيلات Wonder؛ فالمسار المليء بثلاث محاولات فاشلة هو ما يضيفه النموذج المثابر، وهو الموضع الذي تختبئ فيه الأخطاء الدقيقة. ويتناول مقال وكلاء البرمجة أثناء غيابك حالة التشغيل طوال الليل، بينما يوضح مقال المراجعة البشرية هي عنق الزجاجة لماذا لا تصبح هذه العملية أقل تكلفة حتى مع وجود نماذج أفضل.
كيف يبدو طلب التحقق الجيد على لوحة المهام؟
إليك الشكل الذي تنتجه التعليمات السابقة، في هيئة تعليق على المهمة يمكن للمراجع اتخاذ إجراء بشأنه من هاتفه مباشرة:
Check-in before action.
About to: drop the legacy `orders_v1` table in the migration.
Why: the Task says remove v1 read paths; the table is the last reference.
Considered: keeping the table and removing only the code. Rejected because
the nightly job still writes to it and would fail silently.
If no: I will leave the table, remove the code paths, and note the job in
the report for a follow-up Task.
أربعة أسطر، وقرار واحد، وكلا المسارين مخطط لهما مسبقًا. يكتب المراجع كلمة «نعم» أو «لا، احتفظ به» في تعليق على المهمة، فيُستأنف التشغيل، ويوثق السجل هوية صاحب القرار. قارن ذلك بمطالبة تظهر على الطرفية بنص Allow? [y/N] لشخص لم يشاهد الخطوات الأربعين السابقة.
وهناك تحسينان يمكن تطبيقهما بعد تشغيل المسار لمدة أسبوع: إذا كان هناك مراجع واحد يتولى الرد على معظم طلبات التحقق، فعيّن لوكيل ذلك المسار مراجعًا ثانيًا بالاسم حتى لا يتسبب اجتماع بعد الظهر في تعطيل كل عمليات التشغيل الطويلة. وإذا كان الوكيل يسأل باستمرار عن الفئة ذاتها من الإجراءات، فينبغي تضمين تلك الفئة في التعليمات كموافقة دائمة أو رفض دائم، بدلًا من شغل قائمة الانتظار بها.
حالة استخدام الحاسوب (Computer-Use)
تُدرج Meta ميزة استخدام الحاسوب ضمن قدرات نموذج Wonder؛ بما في ذلك التعامل مع المتصفحات وتطبيقات الأجهزة المكتبية والمحمولة. وتبرز هنا أهمية طلبات التحقق بدرجة قصوى، كما تصبح مطالبات الطرفية غير مناسبة على الإطلاق، لأن الإجراء يتمثل في نقرة على شاشة لا يستطيع المراجع رؤيتها. وتنطبق هنا نفس القواعد الموضحة في مقال استخدام الحاسوب لنموذج Astra: إذ يعمل الوكيل على جهاز حاسوب (Computer) يختاره الفريق، ويحدد طلب التحقق اسم الشاشة والإجراء المطلوب، كما يستطيع الشخص الذي يؤكد العملية مراجعة سجل المهمة قبل الموافقة. فالنموذج الذي يطلب إذنًا للضغط على زر الإرسال لا يكون آمنًا إلا إذا تمكن شخص ما من معرفة ما يفعله هذا الزر بالتحديد.
ما لا تعنيه هذه الميزة
إن ميزة التركيز النشط سلوك للنموذج، وسلوكيات النماذج لا تُعد ضمانات قاطعة. فبطاقة النموذج الصادرة عن Meta نفسها تشير إلى إمكانية وقوع أخطاء في المهام المتعددة الخطوات غير المألوفة، كما أن تقرير الأمان الكامل الخاص بها لم يصدر بعد. إن طلب التحقق ميزة ترتقي بنظام المراجعة الجيد، لكنها لا تغني عنه بحال. وأي فريق يفهم عبارة «يتحقق قبل اتخاذ الإجراءات المهمة» على أنها إذن بالتشغيل التلقائي دون مراقبة قد أساء فهمها؛ أما الفريق الذي يربط كل طلب تحقق بمهمة ومراجع ومهلة زمنية محددة، فهو من يبني الآلية الحقيقية التي صُممت هذه الميزة لأجلها.
لا يُحمّل أي من هذا على فاتورة Sharkly؛ إذ يُحتسب استخدام النموذج عبر مفتاح Meta المكوّن على جهاز الحاسوب (Computer). لقد تغير النموذج في 12 أكتوبر، وظل السياق، ومستوى التقدم، والعقبات، والنتائج، والمراجعة البشرية واضحة للعيان بدءًا من مرحلة الطلب وحتى الإطلاق. يمكنك بناء هذا المسار يدويًا باستخدام بيئات العمل المنفصلة (worktrees)، أو الاستعانة بمنصة Sharkly لإدارة سير العمل بالكامل.
