التفاعل: توسيع فضاء الملاحظة وفضاء الفعل

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

غير أن هذه التوسعات كلها جرت تحت المقدّمة نفسها: أن Agent والعالم يتناوبان الكلام. يُنهي المستخدم جملته، فيفكّر Agent برهة، ويستدعي بضع أدوات، ثم يردّ؛ وفي أثناء تفكيره يُفترض أن العالم ساكن. وهذه المقدّمة من الطبيعية بحيث نادرًا ما تُكتب أصلًا بوصفها افتراضًا.

وما يريد هذا الفصل رفعه هو هذه المقدّمة بعينها.

محوران: الوسيط والتوقيت

إذا بسطنا فضاء الملاحظة وفضاء الفعل، تبيّن أن لكلٍّ منهما اتجاهين قابلين للتوسيع.

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

كانت الفصول السابقة توسّع مضمون هذين الفضاءين؛ وهذا الفصل يوسّع وسيطهما وتوقيتهما:

تبادل الأدوار اتفاق تفاعلي بين النموذج وواجهته، وليس خاصية للبيئة. كانت واجهات استدعاء الأدوات المبكرة تنظّم الرسائل عادةً في جولات متزامنة: سؤال تتبعه إجابة، ثم تُستكمل نتائج الأدوات قبل متابعة الاستدلال. لكن البيئة الحقيقية لا تنتظر: يصل البريد أثناء التفكير، ويقاطع المستخدم الكلام، وتتغير الصفحة بين لقطتين، وينقلب الكوب بينما تمتد ذراع الروبوت نحوه. وهذا الاتفاق يتغير أيضاً: حتى سبتمبر 2026، أصبح GPT-6 Astra يدعم استدعاء الأدوات غير المتزامن أصلاً وإضافة تعليمات المستخدم أثناء الدور. لذلك يناقش الفصل الدعم الأصلي والتوافق مع الواجهات المتزامنة القائمة معاً.¹²

اللاتزامن والتوجّه بالأحداث: حين يأتي العالم إليك

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

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

لماذا نحتاج إلى اللاتزامن

لنوضح الحاجة إلى اللاتزامن بتشبيه أولًا. التزامن (Synchronous) يعني “لا تبدأ الأمر التالي حتى ينتهي السابق”، واللاتزامن (Asynchronous) يعني “يمكن أن تجري عدة أمور في آن واحد”. فبنية Agent المتزامنة التقليدية أشبه بشباك خدمة لا يُحسن إلا الطوابير: لا يخدم إلا زبونًا واحدًا في المرة، ولا ينادي التالي حتى يفرغ من سابقه؛ بينما المساعد الذكي حقًا أشبه بسكرتير مرن، على مكتبه عدة أمور معلّقة (بريد، ومكالمة، وزائر)، يقرر أيها يعالج أولًا بحسب درجة الإلحاح، وإن طرأ ما هو أعجل وهو في منتصف عمل استطاع أن يعلّقه وينتقل. وفي النمط المتزامن، إما أن ينتظر Agent اكتمال مهمة الخلفية ليحاور المستخدم، وإما أن ينتظر انتهاء الحوار ليعالج حدثًا جديدًا وصل — فيعجز عن عدة قدرات جوهرية يقتضيها سيناريو المساعد الحقيقي:

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

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

ولهذا نحتاج إلى بنية Agent غير المتزامنة الموجهة بالأحداث. وتقنيًا، يعني ذلك أن النظام لم يعد يفحص بنفسه مرارًا “هل وصلت رسالة جديدة؟” (وهو ما يسمى الاستقصاء، وهو منخفض الكفاءة)، بل يُطلق منطق المعالجة تلقائيًا حين تصل رسالة جديدة. وتُنمذَج المدخلات والمخرجات وعمليات التفكير والتفاعلات الخارجية كلها في هيئة تدفق أحداث موحّد — سجل أحداث مرتب تباعًا على خط زمني واحد. ويعرض الشكل 6-1 البنية الإجمالية لـ Agent غير المتزامن الموجه بالأحداث، مبينًا العلاقة بين مصادر الأحداث وطابور الأحداث ومسار معالجة Agent.

تطبيق آلية التوجيه بالأحداث في OpenClaw

يستقبل إطار العمل مفتوح المصدر OpenClaw الرسائل متعددة القنوات عبر مستوى التحكم Gateway ويوجّهها إلى بيئة تشغيل Agent. وهو يوفر ثلاث آليات مدمجة للتوجيه بالأحداث:

• Hooks (خطاطيف الأحداث): تستجيب لأحداث دورة حياة Agent، كإنشاء الجلسة وإعادة تعيينها، وهي شبيهة بمُطلِقات الأحداث في GitHub Actions
• Cron (المجدول الزمني): ينفّذ المهام الدورية بحسب تعبير cron (وهي صيغة مهام مؤقتة شائعة في أنظمة Unix، مثل 0 9 * * 5 بمعنى التاسعة صباح كل جمعة)
• Heartbeat (عفريت نبضات القلب): يوقظ Agent كل N دقيقة ليفحص إن كان ثمة ما يستحق الانتباه

وتمنح هذه الآليات الثلاث وكيل OpenClaw مظهر “الاستقلالية” — فحتى لو لم يكن المستخدم متصلًا، يستطيع Agent أن يولّد تقارير دورية، ويفحص حالة النظام، ويعالج الأمور الروتينية. وأما رسائل القنوات المدمجة (كالمراسلة الفورية وواجهة الويب) فتصل إلى Gateway بأسلوب الدفع: ما إن تصل الرسالة حتى تُوجَّه إلى Agent. ومن بين آليات الأتمتة الثلاث، لا يحرّك Agent “من تلقاء نفسه” في غياب رسائل المستخدم إلا Cron وHeartbeat، وكلاهما مدفوع بالزمن — فـ Heartbeat يفحص كل فترة ثابتة، وCron يُطلَق في وقت محدد سلفًا، أما مصدر أحداث Hooks فداخلي في إطار OpenClaw لا خارجي.

والنقص الحقيقي هو أن OpenClaw يفتقر إلى قناة وصل فورية لمصادر الأحداث الخارجية عن قنواته المدمجة — كوصول بريد جديد، أو دفع استدعاء من واجهة خارجية، أو إشعار عاجل يستلزم معالجة فورية — فلا يستطيع Agent الاستجابة فور وقوع الحدث، بل ينتظر دورة Cron أو Heartbeat التالية لعله يتنبه.

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

• التحقق الآني من الهوية: يطلب موظف الخدمة التحقق من هوية صاحب الحساب، فيحتاج Pine أن يزوّده المستخدم فورًا برمز الأمان أو رمز التحقق لمرة واحدة (OTP)
• تأكيد المكالمة الثلاثية: يطلب موظف الخدمة التحدث مباشرةً إلى صاحب الحساب، فيحتاج Pine أن يردّ المستخدم خلال ثوانٍ
• مزامنة التقدم وتأكيد القرار: يبلغ التفاوض نقطة حاسمة (كأن يعرض الطرف الآخر خطة تخفيض)، فيحتاج Pine تأكيد المستخدم بالقبول من عدمه

ولو اعتُمد على الاستقصاء الدوري لـ Heartbeat، لربما تأخر وصول الإخطار إلى المستخدم بينما ينتظر موظف الخدمة رمز التحقق، فيُغلق الخط وتفشل المكالمة.

وحلّ PineClaw هو إدخال آلية القنوات (Channel) — أي إقامة قناة أحداث آنية بين Gateway في OpenClaw وواجهة Pine. فحين تقع أحداث مفصلية كاتصال المكالمة، أو الحاجة إلى إدخال المستخدم، أو انتهاء المكالمة، تُدفع الرسالة فورًا إلى وكيل OpenClaw، فيعالجها ويخطر المستخدم على الفور.

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

أدوات إطلاق الأحداث

أدوات إطلاق الأحداث هي مدخل تحفيز الأحداث الخارجية لفعل Agent. فلولاها لما استطاع Agent إلا أن يفكر ويستدعي الأدوات في حلقة متصلة، ثم يُخرج نتيجة وينتظر إدخال المستخدم التالي. ولتحويل تغيرات العالم إلى أحداث يستطيع Agent معالجتها، ثمة ثلاث فئات شائعة من أدوات إطلاق الأحداث.

المؤقت (set_timer) يعالج الأحداث المعتمدة على الزمن الفيزيائي. فمثلًا: أُرسل بريد ولم يردّ الطرف الآخر، فينبغي بعد مدة إرسال بريد آخر للاستفسار عن المستجدات؛ أو أُجريت مكالمة والطرف الآخر خارج ساعات العمل، فيلزم إعادة المحاولة في وقت العمل التالي. ولذلك تدعم أدوات مثل OpenClaw وClaude Code أداة مؤقت توقظ Agent في وقت فيزيائي محدد. والمؤقت لمرة واحدة يُستخدم للمهام ذات النقطة الزمنية المحددة: كأن يطلب المستخدم “اتصل بقسم الرهن العقاري في المصرف للسؤال عن سير المعاملة”، واليوم سبت، فيضبط Agent “الاتصال بالمصرف الاثنين المقبل الساعة 10:00 صباحًا”، فيتصل تلقائيًا عند إطلاق المؤقت. والمؤقت الدوري يُستخدم للمهام الدورية: كفحص صحة الخادم كل ساعة. كما أن بعض الخدمات الخارجية لا تدعم دفع المستجدات، فلا سبيل إلا الاستعلام النشط عنها، وحينها يلزم المؤقت الدوري للاستعلام المتكرر. وHeartbeat في OpenClaw الذي عرضه القسم السابق هو بالضبط منهجة لهذه الآلية، وهو أصل قدرة OpenClaw على “الخدمة الاستباقية”.

مراقبة مهام الخلفية (monitor_shell) تعالج الأحداث الآتية من الأدوات أو مهام سطر الأوامر المنفَّذة لا تزامنيًا. فبعض مهام سطر الأوامر يحتاج وقتًا طويلًا في الخلفية، ويحتاج Agent إلى مراقبة تقدمها. فإن جعلنا Agent “يحدّق في الطرفية” باستمرار، أي يستدعي أداة الاستعلام عن التقدم مرارًا، أهدرنا رموزًا كثيرة؛ وإن انتظرنا اكتمال المهمة تمامًا ليبدأ Agent تفكيره وفعله، عجز عن اكتشاف المشكلات الخطيرة أثناء التنفيذ في حينها، بل عجز عن التدخل إن تجمّد سطر الأوامر فتعطلت المهمة برمّتها. وحلّ Claude Code لهذه المشكلة هو إدخال أداة monitor (المراقبة) التي تتيح لـ Agent مراقبة المخرجات الجديدة لسطر الأوامر أو المخرجات المتضمنة كلمات مفتاحية بعينها.

قناة الأحداث الخارجية (connect_channel) تدفع إلى Agent آنيًا أحداثًا خارجية كوصول بريد جديد، واستدعاءات الواجهات، ورسائل المراسلة الفورية؛ وآلية Channel في PineClaw التي عُرضت في القسم السابق تطبيق نموذجي لها.

وعلى صعيد التصميم، ينبغي لأدوات إطلاق الأحداث أن تحدد شروط إطلاق وقواعد ترشيح واضحة، تفاديًا لإيقاظ أحداث لا صلة لها بـ Agent فتهدر الطاقة الحاسوبية؛ وينبغي أن تتضمن حمولة الحدث (payload) سياقًا كافيًا، تقليلًا لعدد الاستعلامات الإضافية التي يحتاجها Agent بعد إيقاظه.

أدوات التواصل مع المستخدم

نشأت أدوات التواصل مع المستخدم في ظل تنامي تنوع قنوات التواصل بين Agent والمستخدم. فكثير من الوكلاء (مثل Claude Code وManus) يعتمد حلقة ReAct الأصيلة، حيث تُرسَل كل عبارة “يقولها” Agent (أي رسائل assistant) إلى المستخدم مباشرةً، ويتعين على المستخدم أن يفتح جلسة محددة في التطبيق ليحاوره. وغالبًا ما يرى المستخدم في الجلسة عملية استدعاء Agent للأدوات.

وقد كسر OpenClaw نموذج التواصل هذا بين الإنسان والآلة. فلا يحتاج المستخدم إلى إدراك وجود الجلسة أصلًا، ولا إلى الاهتمام بتفاصيل استدعاء Agent للأدوات؛ ويستطيع كلٌّ من المستخدم وAgent أن يرسل إلى الآخر رسالة في أي وقت، بدل أن يرسل المستخدم رسالة فيردّ Agent برسالة. ولهذا يصف كثيرون OpenClaw بأن له “إحساسًا بشريًا”، إذ يتواصل مع المستخدم لا تزامنيًا بالرسائل النصية كما يفعل السكرتير. وOpenClaw لا يُخرج رسائل assistant التي يولّدها النموذج إلى المستخدم مباشرةً، بل يستخدم أدوات مخصصة لإرسال الرسائل، ويمكن أن تُرفق بهذه الرسائل صور وملفات، وأن تُصحب بإشعارات دفع بحسب درجة الإلحاح.

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

التواصل متعدد القنوات واستعادة المستخدم.

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

وفي المهام طويلة التنفيذ، يحتاج Agent إلى إخطار المستخدم استباقيًا عند الاكتمال لاستعادة انتباهه. وفي المهام الدورية (كالملخص اليومي والتقرير الأسبوعي)، يساعد الإخطار المستخدم على تكوين عادة تفاعل ثابتة.

وقد حلّت أدوات التواصل مع المستخدم مسألة “كيف نصل إلى المستخدم”. لكن بأي هوية يظهر Agent على هذه القنوات، وفي أي بيئة ينفّذ العمليات نيابةً عن المستخدم — ذلك يحتاج طبقةً من البنية التحتية للهوية والبيئة، وهي موضوع القسم التالي.

الهوية الافتراضية وبيئة التنفيذ المعزولة

يفتتح الفصل الرابع بمثال Samantha في فيلم Her، موضحًا كيف يستخدم Agent الأدوات للتفاعل مع العالم الرقمي الحقيقي. ولتحقيق مساعد عام كهذا، يواجهنا ابتداءً خيار معماري حاسم: أينبغي لـ Agent أن يدير حسابات المستخدم الشخصية مباشرةً، أم أن تكون له هويته الافتراضية الخاصة؟ الإدارة المباشرة تبدو أيسر، لكن ما إن يخطئ Agent أو يُخترق حتى تنكشف هوية المستخدم الرقمية بأكملها. والحل الأحوط هو منح Agent مجموعة هوية افتراضية مستقلة — كما أن للسكرتير هاتف مكتبه وبريده الخاصين. وتشمل هذه الهوية حسابات تواصل ومساحة تخزين وبيئة حوسبة مخصصة، بما يمكّن Agent من العمل نيابةً عن المستخدم بهوية شفافة. ووضوح الهوية لم يُضعف الثقة، بل عزّز صدق التواصل.

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

وتجلب الهوية المستقلة تحديين واقعيين. الأول هو آليات مكافحة الروبوتات: إذ تحجب مواقع كثيرة الوصول الآلي بـ CAPTCHA وفحص سمعة عناوين IP، والبيئات الافتراضية ذات عناوين مراكز البيانات يسهل التعرف عليها، فيلزم عمليًا في الغالب تهيئة شبكة وكيل سكنية (تستخدم عناوين IP منزلية حقيقية) ليتم الوصول بشكل طبيعي. والثاني هو سيناريوهات الوصول إلى حساب المستخدم الحقيقي: فحين تستلزم المهمة تسجيل الدخول بهوية المستخدم نفسه، ينبغي اعتماد مصادقة بإشراك الإنسان في الحلقة — أي تمكين المستخدم من إتمام تسجيل الدخول بنفسه في بيئة مرئية عبر سطح مكتب بعيد (VNC/RDP)، فيرى الواجهة الكاملة التي يعمل عليها Agent ويفهم سبب الحاجة إلى المصادقة؛ ثم يُعاد استخدام رمز الجلسة بعد المصادقة ضمن مدة صلاحيته تفاديًا لمقاطعة المستخدم المتكررة، تحقيقًا للتوازن بين الاستقلالية والأمان.

ويجري تبادل البيانات بين Agent والبيئة الافتراضية عبر نظام ملفات مشترك: إذ يُوصل Agent والحاسوب الافتراضي والهاتف الافتراضي بأسلوب تركيب وحدة تخزين (مثل /workspace/shared)، وتُمرَّر البيانات بمرجع مسار الملف لا بنسخ المحتوى، تفاديًا لشغل نافذة السياق. ولنأخذ مهمة تحليل بيانات مثالًا: يرفع المستخدم ملف CSV إلى المجلد المشترك، فيقرؤه Agent داخل الحاسوب الافتراضي، وينفّذ التحليل، ويولّد رسمًا بيانيًا يحفظه في المجلد المشترك، ثم لا يحتاج إلا أن يعيد مسار ملف الرسم إلى المستخدم — فما يُمرَّر بين الأطراف على الدوام ليس إلا سلاسل مسارات خفيفة.

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

آلية معالجة الأحداث

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

وهيكل هذه الآلية هو حلقة الأحداث (event loop) المعروفة في البرمجة المتزامنة. ويمكن النظر إلى Agent غير المتزامن بوصفه حلقة تعمل مدةً طويلة: تأخذ في كل دورة عددًا من الأحداث من طابور الإدخال، وتلحقها بالمسار، وتستدعي LLM مرة، وتنفّذ ما قرره من أدوات، ثم تعود إلى رأس الحلقة لانتظار الدفعة التالية — وهي البنية نفسها التي تقرأ بها goroutine في Go الرسائلَ من channel وتعالجها دورةً دورةً داخل for { select { ... } }.

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

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

النمذجة الهيكلية للأحداث.

شرط المعالجة هو الفهم. فالمدخلات التي يواجهها Agent العام لا تأتي من المستخدم وحده — فالرسالة الواردة من طرف ثالث ليست موجّهة من المستخدم إلى Agent، ومع ذلك على Agent أن يفهمها ويقدّر أهميتها ويقرر كيفية التدخل. ويقتضي ذلك نمذجة كل إدخال في هيئة حدث هيكلي غني الدلالة:

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

وبأخذ رسالة بريد لطلب استرداد من عميل مثالًا، تكون الصيغة المحددة للحدث الهيكلي كالتالي:

{
  "source": {"type": "email", "sender": "client@example.com"},
  "channel": "gmail_webhook",
  "content": {"subject": "طلب استرداد", "body": "أرغب في استرداد قيمة الطلب رقم #12345..."},
  "context": {"priority": "high", "customer_tier": "vip", "related_orders": ["#12345"]}
}

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

ويتبيّن من منظومة المُطلِقات في منصات سير العمل مثل n8n أن كل نوع من المُطلِقات — Webhook، والمؤقتات، والبريد، وتغيرات قواعد البيانات، ومراقبة الملفات — هو “حاسّة” من حواس Agent التي يدرك بها العالم. وما إن تُنمذَج هذه الأحداث غير المتجانسة في صيغة هيكلية موحّدة حتى يستطيع Agent معالجة المنبهات الآتية من مصادر مختلفة بطريقة متسقة؛ ويقوم على هذه النمذجة الموحّدة كلٌّ من تقدير الإلحاح واستراتيجيات المعالجة المذكورة أدناه.

استراتيجية المعالجة الديناميكية القائمة على الإلحاح.

يتبع الإنسان عند معالجة عدة مهام استراتيجياتٍ مختلفة بحسب درجة الإلحاح. فأمام طارئ عاجل يتوقف فورًا عما بيده؛ وأمام أمر روتيني يضيفه إلى قائمة المهام ليعالجه لاحقًا. وينبغي لمعالجة Agent للأحداث أن تعكس هذا الذكاء نفسه.

المعالجة الإلغائية (Cancellation-Based) تُستخدم للأحداث العاجلة، وجوهرها اصطناع نقطة آمنة مبكرة للحدث العاجل: أي قطع الخطوة الجارية عمدًا وتحويل تلك اللحظة إلى حدٍّ يمكن عنده استهلاك الأحداث الجديدة. فحين يصل حدث عاجل (كأن ينقر المستخدم “إيقاف”، أو يرسل نظام إشرافي تعليمات عالية الأولوية): (1) يُوقَف العمل الجاري — فإن كان LLM يستدل، أُلغيت الاستجابة التدفقية فورًا؛ وإن كانت أداة متزامنة قيد التنفيذ، أُرسلت إشارة إلغاء؛ (2) يُفرَّغ طابور الانتظار وتُؤخذ الأحداث كلها؛ (3) تُلحَق أحداث الطابور مع الحدث العاجل بنهاية المسار؛ (4) يُستدعى LLM من جديد فورًا ليقيّم الموقف على أساس المسار الكامل المحدَّث. فمثلًا، إذا كتب المستخدم “قف! لقد أخطأت في الطلب” بينما ينفّذ Agent عملية قد تكون خاطئة، رأى Agent هذا الإدخال الجديد فورًا وأعاد فهم النية الحقيقية، فتفادى تنفيذ العملية الخاطئة.

المعالجة الطابورية (Queued) تُستخدم للأحداث الاعتيادية. فحين يصل حدث غير عاجل (كنتيجة أعادتها أداة غير متزامنة، أو معلومة تكميلية من المستخدم): (1) يُوضع الحدث في نهاية الطابور دون قطع العمل الجاري؛ (2) يُنتظر اكتمال العمل الجاري — بأن يُتمّ LLM استدلاله وتُتمّ الأداة المتزامنة تنفيذها؛ (3) وحين يكتمل أي استدعاء أداة ويعيد tool.result، يُفحص الطابور، فإن لم يكن فارغًا أُلحقت أحداثه كلها بالمسار دفعةً واحدة؛ (4) يعالج LLM المسار المحدَّث معالجةً مجمّعة. وبذلك تتحقق المعالجة الدفعية وترتفع الكفاءة — فمثلًا، بعد أن يستدعي Agent أداة بحث، يضيف المستخدم أثناء الانتظار “اقتصر على نتائج الشهر الأخير”، فتدخل هذه الإضافة الطابور، وحين تعود نتيجة البحث يُعرض الحدثان معًا على LLM، فتُتفادى ذهابات وإيابات لا لزوم لها.

المعالجة المتوازية (Parallel) تُستخدم للاستعلامات الخفيفة المستقلة. كأن يسأل المستخدم فجأةً “كيف الطقس اليوم؟” بينما Agent منهمك في تحليل كمية كبيرة من البيانات. ولهذا النوع من الاستعلامات ثلاث خصائص: لا صلة له بالمهمة الرئيسية، ويحتاج استجابة سريعة، وتكلفة تنفيذه منخفضة. فلا ينبغي معالجته إلغائيًا (إذ يقطع مهمة رئيسية مهمة)، ولا طابوريًا (إذ يُطيل انتظار المستخدم). فيحكم النظام أولًا على استقلالية الاستعلام ودرجة تعقيده، ثم ينفّذه مستقلًا في جلسة استدلال متوازية، ويستدعي ما يلزم من أدوات ليولّد الاستجابة ويعيدها فورًا. ويُلحَق الاستعلام والاستجابة بمسار المهمة الرئيسية موسومَين صراحةً بأنهما “نُفِّذا بالتوازي مع المهمة الرئيسية”، تفاديًا لخلط LLM بينهما.

تقدير درجة الإلحاح.

الأحداث العاجلة: مقاطعة المستخدم (user.interrupt)، وتعليمات الإشراف (supervisor.instruction)، والمقاطعة بين الوكلاء (agent.interrupt)، والمُطلِقات الخارجية الموسومة بالعجلة (كإنذارات النظام وفشل الدفع).

الأحداث غير العاجلة: إدخال المستخدم الاعتيادي (user.input)، وإدخال الوكلاء (agent.input)، ونتائج الأدوات (tool.result)، وإطلاق المؤقتات (timer.trigger)، والمُطلِقات الخارجية الاعتيادية.

وللقواعد المكتوبة يدويًا حدودها، فدلالة الحدث هي التي تحدد طريقة معالجته — فـ”توقف حالًا” تُعالَج إلغائيًا، و”كيف الطقس اليوم” تُعالَج بالتوازي، و”أرسل لي التقرير بالعربية” تُعالَج طابوريًا. ويُنصح باستخدام LLM تصنيفي خفيف بوصفه موجّهًا للأحداث، يحكم سريعًا عند وصول الحدث في أي استراتيجية ينبغي اعتمادها.

ويجب أن تكون نقطة الإلغاء موضعًا تستطيع عنده الأداة أو الاستدلال أن يُنهي عمله بأمان؛ وتُمثَّل نتائج الأدوات غير المكتملة بعنصر نائب صريح، ولا يجوز تزوير نجاحها.

وفيما يلي تجربةٌ لوكيل معالجة بريد موجّه بالأحداث، تُنزِل استراتيجيات معالجة الأحداث المذكورة إلى تطبيق قابل للتشغيل.

التجربة 6-1 ★★★: وكيل معالجة البريد الموجّه بالأحداث

تبني هذه التجربة أبسط وكيل موجّه بالأحداث: مساعد معالجة البريد التلقائي. يراقب Agent صندوق الوارد، وكلما وصل بريد جديد أطلق تلقائيًا مسار معالجة — تصنيف، وتلخيص، وصياغة رد، وإخطار المستخدم عند اللزوم. وهذا أوضح سيناريو تمهيدي للوكيل الموجّه بالأحداث: حدث خارجي واحد (وصول بريد جديد) يُطلق حلقة تفكير كاملة لـ Agent.

وهدف التجربة هو فهم المفهوم الجوهري للتوجيه بالأحداث: لم يعد Agent ينتظر إدخال المستخدم سلبيًا، بل صار قادرًا على الفعل الاستباقي استجابةً لأحداث خارجية. وسيتقن القارئ عبر هذه التجربة تسجيل مصادر الأحداث، وطابور الأحداث، والحلقة الأساسية “وصول الحدث ← معالجة Agent ← إخراج النتيجة”.

مصادر الأحداث وطابور الأحداث.

يدعم النظام وصلًا موحّدًا لمصادر أحداث متعددة:

• أحداث البريد (on_email_received): تُطلَق عند وصول بريد جديد، عبر الفحص الدوري لصندوق الوارد أو تلقي إشعار دفع
• رسائل المراسلة الفورية والرسائل القصيرة (on_im_message وon_sms_message): إطلاق برسائل المراسلة الفورية
• أحداث GitHub (on_github_pr_update وon_github_issue_update): ملاحظات مراجعة طلبات الدمج وتغيرات الحالة
• إطلاق المؤقتات (on_timer_expire): المهام المؤقتة (كالملخص اليومي وتوليد التقرير الأسبوعي)
• Webhook (on_webhook_received): استدعاء عام من نظام خارجي
• أحداث النظام (on_user_inactive وon_process_timeout وon_resource_alert): تغيرات الحالة الداخلية

وتدخل الأحداث كلها طابور أحداث موحّدًا تُعالَج فيه تباعًا بحسب ترتيب الوصول. ويُطلق كل حدث حلقة تفكير مستقلة لـ Agent: يقرأ محتوى الحدث، ويستدعي الأدوات ذات الصلة (كالاستعلام من قاعدة المعرفة، وقراءة المرفقات، والبحث في سجل البريد ذي الصلة)، ويولّد نتيجة المعالجة (وسم التصنيف، والملخص، ومسودة الرد)، ثم يخطر المستخدم عبر أداة إخطار أو ينفّذ العملية مباشرةً.

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

أظهرت التجربة 6-1 أبسط أنماط التوجيه بالأحداث — دخول الأحداث الطابور ومعالجة Agent لها تباعًا. لكن حين يحتاج Agent إلى الاستجابة لمقاطعة أثناء تنفيذ أداة طويلة، أو إلى إدارة عدة مهام متزامنة في آن، لا يعود طابور الأحداث البسيط كافيًا. وفيما يلي نناقش التحديات الهندسية الأعمق.

التوافق عند غياب الدعم الأصلي للاتزامن

تعالج التجربة 6-1 أحداثاً تسلسلية فقط: تدخل الطابور ويعالجها الوكيل واحداً تلو الآخر. إذا لم يدعم النموذج أو الواجهة المختاران اللاتزامن أصلاً، فلا بد من التعبير عن مقاطعة المستخدم قبل عودة الأداة ضمن الصيغة المتزامنة. نقدم هنا مساراً للتوافق، ثم نعرض الواجهة الأصلية لـ GPT-6 Astra.

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

تنفيذ غير متزامن متوافق مع الصيغة المتزامنة.

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

القاعدة 1: سجّل فوراً رسائل المساعد وعناصر استدعاء الأدوات التي أكملتها API. احتفظ بحالة الاستدلال التي يديرها الخادم وفق بروتوكول المتابعة لدى المزوّد، ولا تُركّب بنفسك نص التفكير غير المرئي.

القاعدة 2: لا تُسجَّل نتيجة الأداة إلا عند اكتمال استدعائها. وأثناء التنفيذ يكون المسار في حالة “اكتمال جزئي”.

القاعدة 3: المقاطعة أثناء تنفيذ الأداة تستلزم عنصرًا نائبًا. فيُولَّد للأداة غير المكتملة ردٌّ نائب (مثل “الأداة قيد التنفيذ في الخلفية، يُرجى إعطاء الأولوية للحدث الجديد”)، ثم يُلحَق حدث المقاطعة ويُستدعى LLM من جديد. ومن منظور LLM تبقى رسالة assistant مقترنة بنتيجة أداة.

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

القاعدة 5: الأحداث غير المقاطِعة تدخل الطابور بانتظار المعالجة الدفعية، ولا تُلحَق دفعةً واحدة إلا بعد اكتمال الدورة الحالية.

وبأخذ مثال مقاطعة المستخدم بسؤال عن الطقس بينما يصوغ Agent رسالة بريد، تعمل هذه القواعد الخمس على النحو التالي:

1. يستدعي Agent الأداة search_contacts للبحث عن معلومات جهة الاتصال، فتُكتب رسالة assistant في المسار فورًا (القاعدة 1).
2. وقبل أن تعيد أداة البحث نتيجتها، يرسل المستخدم “ابحث لي أولًا عن طقس الغد”. ولأن هذه مقاطعة من المستخدم، يولّد النظام نتيجة أداة نائبة لـ search_contacts غير المكتملة (“الأداة قيد التنفيذ في الخلفية، يُرجى إعطاء الأولوية للحدث الجديد”، القاعدة 3)، ثم يُلحق استعلام الطقس بالمسار ويستدعي LLM من جديد. وفي هذه اللحظة يكون المسار الذي يراه LLM مشروعًا تمامًا في صيغته — إذ تقترن رسالة assistant بنتيجة أداة اقترانًا سليمًا.
3. وبعد إتمام استعلام الطقس والرد على المستخدم، تصل نتيجة search_contacts الأصلية فتُلحَق بالمسار بوصفها حدثًا جديدًا (القاعدة 2)، فيقرأ Agent معلومات جهة الاتصال ويواصل صياغة الرسالة.

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

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

التعبير عن دلالات اللاتزامن بمعرّفات المهام.

سواء استُخدم بروتوكول غير متزامن أصلي أم لا، يمكن توضيح دلالات اللاتزامن في تصميم واجهة الأدوات. ومن الطرق المفيدة خصوصاً للواجهات المتزامنة جعل «بدء المهمة» استدعاءً كاملاً له قيمة إرجاع حقيقية.

فتصميم الأدوات التقليدي يتضمن ضمنًا دلالة “الاستدعاء يعني الاكتمال”. فاسم phone_call مثلًا يوحي بأن “الاستدعاء سيُجري المكالمة وينتظر انتهاءها ويعيد سجلها”. وفي النموذج غير المتزامن ينبغي فصل “الإطلاق” عن “الاكتمال”:

• initiate_phone_call: يطلق المكالمة ويعيد فورًا معرّف المهمة وحالتها الأولية (مثل “أُطلقت المكالمة، جارٍ الاتصال”)
• ويُبلَّغ بتقدم المكالمة عبر إخطارات الأحداث (phone_call_connected وphone_call_ended)

والمفتاح أن ينقل اسم الأداة ووصفها الدلالةَ غير المتزامنة بنفسيهما. فحين يرى النموذج initiate_phone_call يستنتج طبيعيًا أنه “إطلاق” لا “اكتمال”. وينبغي لوصف الأداة أن يعزز ذلك: “تطلق هذه الأداة مهمة مكالمة يعالجها وكيل فرعي. وتعيد معرّف المهمة فور نجاح الإطلاق، ويمكنك متابعة أمور أخرى. وستتلقى إخطارًا منفصلًا عند انتهاء المكالمة.”

مشكلة تشتت الانتباه في المعالجة الطابورية.

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

ويمكن التدخل على مستويين:

مستوى الموجّه: بإبلاغ النموذج “حين تتلقى عدة أحداث متتالية، تأكد من مراعاة جميع المعلومات مراعاةً شاملة”.

وسم شريط حالة Agent: بإضافة وسم صريح قبل كل حدث:

[حدث غير معالَج 1/4] نتيجة أداة من database_query: ...
[حدث غير معالَج 2/4] توضيح إضافي من المستخدم: اقتصر على بيانات منطقة بكين
[حدث غير معالَج 3/4] تنبيه النظام: بقي 30 دقيقة على موعد تسليم التقرير
[حدث غير معالَج 4/4] استفسار المستخدم: كيف يسير التقدم؟

مع إضافة خلاصة في النهاية: “أعلاه 4 أحداث غير معالَجة، تشمل نتيجة أداة واحدة، ورسالتي مستخدم، وتنبيه نظام واحدًا. تأكد من أن ردك يغطي جميع المعلومات.”

التجربة 6-2 ★★★: وكيل غير متزامن بقدرة التنفيذ المتوازي والمقاطعة

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

1. التنفيذ غير المتزامن للأدوات: دعم التنفيذ غير المتزامن للأدوات المستغرقة للوقت (3-5 ثوانٍ على الأقل)، بإعادة عنصر نائب فور الإطلاق. سيناريو التحقق: ينفّذ Agent أمر طرفية طويلًا، وأثناءه يسأل المستخدم “كم الساعة الآن؟”، فيردّ Agent فورًا، ثم يعرض نتيجة التحليل عند عودتها.

2. طابور الأحداث والمعالجة الدفعية: تراكم الأحداث غير العاجلة وإلحاقها بالمسار دفعةً واحدة. سيناريو التحقق: ينفّذ Agent مهمة طويلة، ويرسل المستخدم تباعًا “تذكّر أن ترد باليابانية” و”نسّقها في صفحة ويب”، فتُعالَج الأحداث كلها دفعةً واحدة عند اكتمال المهمة، فتُولَّد صفحة ويب باليابانية.

3. آلية المقاطعة: “توقف” من المستخدم تُنهي مسار التنفيذ فورًا وتلغي الأدوات غير المتزامنة. سيناريو التحقق: ينفّذ Agent مهمة طويلة، فيرسل المستخدم “إلغاء”، فيتوقف Agent فورًا، ويسجّل المسار حدث المقاطعة وعملية الإلغاء.

4. إلغاء الأدوات المتوازية والاستعلام عن حالتها: تُحقن النتيجة الحقيقية في الحوار عبر حدث جديد بعد اكتمال الأداة غير المتزامنة، مع دعم الإلغاء أو الاستعلام عن التقدم بمعرّف المهمة. سيناريو التحقق: يطلب المستخدم “شغّل لي هذه النصوص الثلاثة معًا، وأيها انتهى أولًا فانظر في تقدم الباقي، وإن لم يتجاوز 50% فألغِه”. وتحاكي النصوص الثلاثة عمليات تحليل تُخرج تقدمها باستمرار بسرعات 3% و2% و1% في الثانية. فيطلق Agent ثلاثة أوامر طرفية غير متزامنة معًا، وحين ينتهي النص ذو 3% في الثانية بعد نحو 33 ثانية، يستعلم عن حالة الطرفيتين الباقيتين، فيجد إحداهما عند نحو 66% والأخرى عند نحو 33%، فيلغي ما لم يتجاوز 50%. وبعد اكتمال الطرفيتين يدمج النتائج ويولّد تقريرًا كاملًا.

اللاتزامن الأصلي في النموذج: GPT-6 Astra

في مسار التوافق السابق، ترتّب بيئة التشغيل دخول الأحداث لكي يشارك نموذج ذو واجهة متزامنة في مهام غير متزامنة. وهناك مسار آخر يجعل النموذج يفهم هذا الإيقاع أصلاً: يعمل على أمور أخرى أثناء تشغيل الأداة، ويعدّل العمل اللاحق عندما يضيف المستخدم متطلبات أثناء المهمة. يدعم GPT-6 Astra بالفعل استدعاء الأدوات غير المتزامن (Async tool calling) والتوجيه أثناء الدور (Mid-turn steering)، وهو ما يجسّد هذا التغير (الشكل 6-5).¹²

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

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

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

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

من استقبال الرسائل غير المتزامنة إلى معالجة مهامها بموثوقية

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

1. انتماء النتيجة والحالة غير المكتملة: هل يربط النتيجة المتأخرة بالمهمة الصحيحة ويتجنب اختلاق البيانات عند غيابها؟
2. استئناف المهمة والتحكم في الأفعال: هل يعود إلى المهمة الأصلية بعد معالجة المتطلبات الجديدة ويميّز بين تعديل الخطة وإيقاف التنفيذ؟
3. دمج تحديثات متعددة: هل يلتزم معاً بقيود الميزانية وعدد الحاضرين بدلاً من تذكّر الرسالة الأخيرة فقط؟

يمكن تحسين النموذج بالتدريب في بيئات غير متزامنة، وتحسين النظام بوضوح حالة المهام ومصادر الأحداث والتغذية الراجعة من التنفيذ. يجب أن يغطي التقييم الطبقتين: هل فهم النموذج التغيير، وهل نفّذ النظام العمل وفقه؟

التجربة 6-3 ★★★: اللاتزامن الأصلي في النموذج والتوجيه أثناء الدور

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

استدعِ API الخاصة بـ GPT-6 Astra للمقارنة بين الأدوات المتزامنة والأدوات غير المتزامنة الأصلية والتوجيه أثناء الدور. راقب هل يعطل الانتظار أعمالاً أخرى، وهل تدخل المتطلبات الجديدة في الخطط اللاحقة، وهل تستأنف المهمة الأصلية عند وصول النتائج. واستخدم نموذجاً لا يدعم هذه القدرات أصلاً كحالة ضابطة لفهم ما تعالجه قدرات النموذج وما يعالجه تنسيق بيئة التشغيل.

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

الصوت: الواجهة الأكثر طبيعية بين الإنسان والآلة

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

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

توقيت التفاعل: من التسلسل إلى الازدواج الكامل

تصف مقدمة GPT-Live من OpenAI ثلاثة نماذج للتفاعل الصوتي: التسلسلي، والقائم على الأدوار، والازدواج الكامل³. ليست هذه مراحل تستبدل إحداها الأخرى ببساطة؛ فهي مقايضات مختلفة بين زمن الاستجابة والكلفة وقابلية المراقبة:

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

النموذج الأول · خط أنابيب تسلسلي

لا تزال معظم المساعدات الصوتية التجارية تستخدم خطًا تسلسليًا (الشكل 6-6): يقرر VAD انتهاء كلام المستخدم، ويحوّل ASR الصوت إلى نص، ويفهم LLM الطلب وينشئ الرد، ثم ينطقه TTS. تتيح الوحدات المستقلة تحسين كل جزء، لكن كل حدّ يضيف وقت انتظار.

في رد قصير لا يُفعَّل فيه الاستدلال، تتراكم أزمنة انتظار VAD وASR وLLM وTTS تراكمًا تسلسليًّا (الشكل 6-7). أما القيم الفعلية فتتوقف على طول الإدخال والنموذج والعتاد والشبكة والحمل.

ويزيد انتظارُ الطوابير في بيئة الإنتاج من تضخيم زمن الخمول (الشكل 6-8)، غير أن ذلك يندرج في تخطيط سعة الخدمة، ولا يبسط هذا الفصل الحديث في نماذج الطوابير.

التجربة 6-4 ★: بناء وكيل صوتي تقليدي

صِل الميكروفون وSilero VAD وWhisper المحلي ونموذجًا لغويًا متدفقًا وFish S1 TTS عبر WebSocket لبناء خط الأساس المتسلسل.

من التسلسل إلى الإدراك المتدفق

يصف الشكل 6-7 الحالة التسلسلية الكاملة لـVAD وASR وLLM وTTS، ولهذا الإدراك التسلسلي ثلاثة عيوب:

1. تراكم زمن الاستجابة: لا بدّ من انتظار مدة من الصمت لتأكيد أن المستخدم أنهى كلامه.
2. فقدان المعلومات: إشارة «صوت/لا صوت» الثنائية لا تعبّر عن التردد والعاطفة والردود القصيرة والصوت المحيط.
3. انقطاع السياق: قد تنقسم عناوين البريد وأسماء الأشخاص والأعلام بين المقاطع فتُعرَّف خطأً.

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

• ASR ينسخ أثناء الاستماع: ما إن يكتشف VAD بدء كلام المستخدم حتى يُستدعى نموذج ASR على فترات زمنية محددة ليولّد نسخًا مؤقتة متدفقة؛ فإذا اكتشف VAD انتهاء الكلام، أُكِّد النص النهائي.
• التنفيذ التخميني لـLLM: يُرسَل النص المؤقت إلى LLM فور توليده؛ فإن طابق النصُّ النهائي النسخةَ المؤقتة لم يُستدعَ LLM من جديد، وإلا أُلغي التفكير التخميني السابق واستُدعي LLM مرة أخرى.
• إخراج LLM مقطّعًا: يُسلَّم أول مقطع نصي صالح للنطق إلى TTS فور توليده، دون انتظار الرد كاملًا.
• التركيب التزايدي في TTS: تُعاد كتل صوتية على التوالي، فيتداخل ما يليها من توليد وتركيب وتشغيل.

ويحتاج ASR المتدفق حقًّا إلى دعم من النموذج نفسه. فمع أن فك الترميز في Whisper انحداري ذاتي، يتوقع مُرمّزه مقطعًا صوتيًا كاملًا، ولذلك لا يصح عدّه نموذجًا متدفقًا. أما النموذج السمعي المتدفق المبني على LLM فيستطيع إصدار النص وأحداث دلالية من الصوت المستمر، فيجمع «التعرف» وجزءًا من «الفهم» في نموذج واحد. وهو يحتفظ بالسياق من بداية المحادثة إلى اللحظة الراهنة، ويستطيع كذلك الاستعانة بمعرفته بالعالم في معالجة العلامات التجارية وأسماء الأشخاص والأعلام.

إذا كان المطلوب فقط تحديد ما إذا كان المستخدم قد أنهى كلامه، فيمكن دمج قرار نهاية الدور مباشرة في أداة التعرف المتدفقة: يحكم النموذج، بالجمع بين الدلالة والصمت، هل اكتملت الجملة معنويًا. ويجب ألا تستخدم تسميات تدريب نقطة النهاية إلا المعلومات المتاحة لحظة اتخاذ القرار؛ وإلا أنتجت معرفة ما بعد الحدث («منظور إلهي») حكمًا يتعذّر إعادة إنتاجه في الإنتاج الفعلي.

ولا يقتصر مخرَج النموذج على النص، بل يمكن أن يتضمن وسوم أحداث صوتية:

• speak_start/end وinterrupt: بداية الكلام ونهايته ونية المقاطعة؛
• emotion: العاطفة والتردد وما شابههما من حالات؛
• laugh وsigh وnoise: الأصوات غير اللفظية والبيئية.

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

التجربة 6-5 ★: محاكاة الإدراك الصوتي المتدفق باستخدام Qwen2-Audio

ليس Qwen2-Audio نموذجًا متدفقًا في ذاته. تحاكي التجربة الإدراك المستمر ببادئات صوتية متزايدة وتقارنه بـ 600ms VAD + Whisper.

النموذج الثاني · نماذج Omni متعددة الوسائط من طرف إلى طرف

حتى مع الإدراك المتدفق، تمرر السلسلة السماع والتفكير والكلام عبر واجهات منفصلة، وقد تضيع العاطفة والتنغيم والصوت المحيط عند تحويل الصوت إلى نص. أما حل Omni فيستمع إلى الصوت ويولد الرد وينطقه بنموذج واحد، فتُتاح له فرصة حفظ هذه المعلومات، لكن كلفة تدريبه أعلى (الشكل 6-9). وقياسًا بالحل التسلسلي في النموذج الأول، تظهر ميزة Omni أساسًا في زمن الاستجابة وفي فهم المعلومات غير النصية وتوليدها.

ففي جانب الفهم، يستطيع نموذج Omni أن يفهم الوقفات في الصوت. وفي جانب التوليد، يستطيع أن ينقل معلومات غير لفظية أغنى، كالغناء أو نطق جملة بتنغيم خاص.

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

التجربة 6-6 ★★: تشغيل MiniCPM-o 4.5 محليًا — من طرف إلى طرف مقابل التسلسل الذاتي

شغّل MiniCPM-o 4.5 محليًا مع تعطيل thinking mode، وقارن الإجابة المباشرة من الصوت بمسار ذاتي متسلسل ينسخ الصوت أولًا ثم يجيب بالنموذج نفسه. تقيس التجربة حفظ المعلومات الصوتية، لا «التفكير أثناء الكلام» الآتي لاحقًا.

النموذج الثالث · نماذج تفاعلية كاملة الازدواج

يقسم Omni المحادثة إلى «المستخدم يتكلم» و«النموذج يتكلم»، بينما تتطلب الترجمة الفورية تداخلًا. لذلك يستمع النموذج كامل الازدواج ويتكلم باستمرار، ويقرر مرارًا هل يواصل أو يتوقف أو يقاطع أو يستدعي أداة.

والسابقة البحثية هنا هي Moshi من Kyutai (2024). فهي تنمذج تدفقي الصوت للمستخدم وللنموذج على التوازي، ومن ثم يصير الكلام المتداخل والمقاطعة سلوكًا طبيعيًا للنموذج.

ويسمّي Thinking Machines Lab هذا المسار نموذج التفاعل (Interaction Model)⁴: إذ لم تعد التفاعلية تُركَّب عبر harness خارجي يعتمد VAD، بل صارت مدمجة في النموذج نفسه. وتتقدم آلية الجولات الصغيرة فيه باستمرار عبر كتل صوتية قصيرة، فيُحتفظ بالصمت والتداخل والمقاطعة بوصفها سياقًا متصلًا. ويستطيع نموذج التفاعل كذلك أن يفوّض الحوار الكامل إلى نموذج استدلال في الخلفية بينما يواصل هو إمساك خيط الحديث؛ وحين تعود النتيجة من الخلفية، تدمجها الواجهة الأمامية في اللحظة المناسبة.

أما GPT-Live من OpenAI فينقل مسار الازدواج الكامل إلى نطاق الإنتاج: يعالج النموذج المدخلات ويولّد المخرجات على نحو متصل، ويحسن انتظار المستخدم والمجاملة بالكلام وتقبّل المقاطعة، كما يتعامل مع الترجمة الفورية. وهو، شأن نموذج التفاعل، يفوّض المهام المعقدة إلى نموذج في الخلفية بينما تواصل الواجهة الأمامية إدارة الحوار.

التوقيت المعرفي: التفاعل الآني والتفكير العميق

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

الحل الأول: التفكير السريع للحشو، والتفكير البطيء للإجابة

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

الحل الثاني: التفكير السريع للتفاعل، والتفكير البطيء للتنبيه

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

الحل الثالث: توحيد التفكير والتعبير من طرف إلى طرف

يستبطن الحل الثالث قدرة التفكير داخل نموذج صوتي من طرف إلى طرف. وتحل Step-Audio R1 مشكلتين بآليتين متكاملتين: تقطير التفكير المرتكز على الوسيط (MGRD) يجعل النموذج يفكّر انطلاقًا من السمات الصوتية، وبنية الدماغين MPS تجعل التصوّر والتعبير متوازيين. فالأولى تضمن “صحة التفكير”، والثانية تعالج “الكلام في حينه”.

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

المفاضلة بين فصل التفكير السريع والبطيء والاستدلال من طرف إلى طرف

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

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

ولا يعني هذا الفصل بالضرورة التضحية بأداء المهمة. فحتى أغسطس 2026، احتل وكيل Pine AI الصوتي، الذي يستخدم بنية منفصلة للتفكير السريع والبطيء، المركز الأول في τ³-Voice Leaderboard، متقدمًا على أنظمة صوت آنية مثل Grok Voice وGPT-Realtime-2. ويبيّن هذا، في الحد الأدنى، أن البنية المفكّكة ليست أدنى بطبيعتها من النماذج الطرفية في المهام التي تختبر الاستدلال العميق والحوار الآني معًا.⁵

ينبغي هنا توضيح أن عبارة «نموذج من طرف إلى طرف» تُستخدم عادةً بمعنيين. الأول هو المسار الصوتي من طرف إلى طرف الذي ناقشه القسم السابق: يستقبل النموذج الصوت ويولّده مباشرةً، بدل وصل عدة نماذج عبر نص منفصل. ويُعد كل من Omni ونموذج التفاعل طرفيًا بهذا المعنى، لكن Omni يظل عادةً قائمًا على الأدوار، في حين يستطيع نموذج التفاعل الاستماع والكلام في الوقت نفسه؛ ولذلك تختلف بنيتاهما اختلافًا كبيرًا. والمعنى الثاني هو البنية المعرفية من طرف إلى طرف التي يناقشها هذا القسم: إما أن يشترك التفاعل الآني والتفكير العميق في الحالة ويُدرَّبا معًا داخل نموذج واحد، أو يُقسَّما بين نموذج سريع في الواجهة ونموذج بطيء في الخلفية. وهذان المحوران مستقلان؛ فقد يكون المسار الصوتي للنظام طرفيًا مع بقاء التفكير السريع والبطيء منفصلين في بنيته المعرفية. وتفويض Thinking Machines Lab المهام المعقدة إلى نموذج استدلال في الخلفية مثال على هذا الجمع.

تركيب كلام أكثر شبهًا بالبشر

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

يمكن لـLLM الرئيسي أن يصدّر علامات تحكم إضافة إلى النص، مثل THINKING وEMO:happy وSPEED:0.8x؛ ويحوّلها TTS إلى توقفات وتنغيم وسرعة نطق وضحك وتنهدات وغير ذلك من الصوت غير اللفظي. ويمكن أن يكون التنفيذ TTS مدرَّبًا على فهم علامات التحكم، أو استنساخًا للصوت مع مقاطع مرجعية لمشاعر وأساليب مختلفة.

التجربة 6-7 ★★: تركيب TTS بعلامات تحكم باستخدام Fish Audio

استخدم Fish Audio S1 لبناء مكتبة صوتية متعددة المراجع وقارن بين ثلاث إعدادات: بلا علامات تحكم، ومرجع واحد، ومراجع متعددة. تختار طبقة التنفيذ العاطفة وسرعة النطق والأسلوب المطابقين للعلامات.

استخدام الكمبيوتر: وكلاء أتمتة واجهة المستخدم الرسومية

دفع الصوتُ محورَ التوقيت إلى مستوى الميلي ثانية، لكن ملاحظته تظل تيارًا صوتيًّا أحاديَّ البعد. أما Computer Use فينقل المسألةَ نفسها إلى شاشة ثنائية البعد: تصير الملاحظةُ بكسلاتٍ متغيرةً على الدوام، ويصير الفعلُ نقرًا وإدخالًا عند إحداثيات. ففي مشهد الصوت يكون التشديد على «متى أتكلم»، وفي Computer Use يكون على «أين أنقر في الخطوة التالية»، وعلى مسألةٍ لا وجود لها في التفاعل الصوتي أصلًا: هل يظل الواقعُ بعد تنفيذ الفعل موافقًا للخطة؟

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

1. يأخذ الوكيل لقطة شاشة للشاشة الحالية.
2. يتلقى النموذج متعدد الوسائط لقطة الشاشة وتعليمات المهمة، ويخرج فكرة وإجراءًا محددًا.
3. تنفذ طبقة التنفيذ الإجراء في البيئة الحقيقية (تحريك الماوس، والنقر، وكتابة النص، وما إلى ذلك).
4. وينتظر استجابة الواجهة، ويأخذ لقطة شاشة أخرى، ويدخل في تكرار الحلقة التالية.

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

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

تصميم مساحة العمل

يقسم التطبيق المرجعي لـ Anthropic قدرة التفاعل الكاملة إلى ثلاثة أنواع من الأدوات (الشكل 6-12). وهذا تصميم واضح لمساحة العمل، لكنه ليس بروتوكولًا خاصًا يجب على موردي النماذج اتباعه: ما دام Harness يستطيع تحويل لقطات الشاشة وقيود الأفعال ونتائج التنفيذ نفسها إلى الرسائل والمخرجات المهيكلة التي يدعمها النموذج المستهدف، يمكن لـ Claude ونماذج الرؤية مفتوحة الأوزان ونقاط النهاية ذاتية الاستضافة تشغيل حلقة الإدراك والتفكير والفعل نفسها.

أداة تشغيل واجهة المستخدم الرسومية (أداة computer): تتضمن عمليات الماوس النقل (mouse_move)، والنقر باليسار/اليمين/الوسطى، والنقر المزدوج أو النقر الثلاثي، والسحب (left_click_drag)، وإجراءات الضغط/التحرير الأكثر دقة (left_mouse_down وleft_mouse_up). يدعم التمرير (scroll) أربعة اتجاهات ويمكن دمجه مع مفاتيح التعديل. تتضمن عمليات لوحة المفاتيح كتابة حرف بحرف (type، مع فاصل زمني قدره 12 مللي ثانية بين الأحرف لمحاكاة الكتابة الحقيقية)، ومجموعات المفاتيح (key، على سبيل المثال، Ctrl+C)، والإمساك بالمفتاح (hold_key). تتضمن إجراءات الإدراك التقاط لقطة شاشة واسترداد موضع المؤشر (cursor_position) والانتظار (wait).

أداة تنفيذ الأوامر (أداة bash): توفر جلسة طرفية bash مستمرة مع مهلة مدتها 120 ثانية. يستخدم سلسلة خافرة للكشف عن اكتمال الأمر ويحافظ على حالة البيئة عبر استدعاءات متعددة (على سبيل المثال، بعد cd إلى دليل، يبقى الاستدعاء التالي في هذا الدليل).

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

التجربة 6-8 ★: تشغيل Computer Use (مسار Anthropic المرجعي أو مسار النموذج المفتوح)

يستخدم المسار A عرض Anthropic Computer Use Demo. وتجمع الحاوية بيئة سطح مكتب Ubuntu كاملة، تشمل متصفحًا وطرفيةً وأدوات شائعة أخرى. تستقبل الواجهة الأمامية المهمة، بينما ترسل الواجهة الخلفية التعليمات ولقطات الشاشة إلى Claude، ثم تنفذ إجراءات الفأرة أو لوحة المفاتيح أو الطرفية أو التحرير التي يعيدها النموذج.

يستخدم المسار B مثال الشفرة في chapter6/computer-use-open-model. وبشكل افتراضي، يشغّل browser-use بالنموذج المفتوح الأوزان Qwen3-VL 32B Instruct عبر واجهة OpenRouter API المستضافة، أو عبر vLLM/SGLang مستضاف ذاتيًا وأنظمة مشابهة.

تحديد الموقع البصري (Visual Grounding)

في كل تكرار للحلقة، يحتاج النموذج إلى تحديد موقع العنصر المستهدف بدقة في لقطة الشاشة - “أين يوجد مربع البحث؟” “ما هي إحداثيات زر الإرسال؟” هذه هي مشكلة الإرساء البصري. يوجد حاليًا طريقتان رئيسيتان: أحدهما هو تحويل تحديد الموقع إلى مشكلة الاختيار من متعدد — أولاً قم بإضافة تعليقات توضيحية لعناصر الواجهة بالأرقام، ويحتاج النموذج فقط إلى تحديد عنصر واحد؛ والآخر هو التنبؤ بالإحداثيات النقية — السماح للنموذج “بالنظر” إلى لقطة الشاشة والإبلاغ عن الإحداثيات مباشرة، تمامًا مثل الإنسان. يتضمن نهج الاختيار المتعدد طريقتين للتنفيذ: تعليق توضيحي مرئي خالص (مجموعة العلامات الأصلية، باستخدام نموذج تجزئة لتقسيم المناطق المرشحة في الصورة) و فهرسة العناصر المنظمة (DOM/شجرة إمكانية الوصول، قراءة البنية المتأصلة للواجهة مباشرة). الميزة الشائعة لمنهج الاختيار المتعدد هي أنه يحول المشكلة المفتوحة المتمثلة في “العثور على الزر في لقطة الشاشة والتنبؤ بإحداثياته” إلى مشكلة مغلقة تتمثل في “اختر واحدًا من العناصر المشروحة بالفعل”. وتمامًا كما أن الإجابة على أسئلة الاختيار المتعدد أسهل بشكل صحيح من أسئلة ملء الفراغات في الاختبار، يحتاج النموذج فقط إلى قول “انقر فوق [123]” بدلاً من “انقر فوق الزر الموجود عند الموضع (350، 464) من الشاشة”. ويمثل إخراج الإحداثيات تحديًا صعبًا للنموذج على وجه الخصوص، إذ يتطلب تدريبًا كثيفًا ليكون دقيقًا، ومن السهل أن يخطئ فيه عند اختلاف دقة الشاشة.

مجموعة العلامات: طريقة التعليق التوضيحي المرئي.

تم اقتراح مجموعة العلامات الأصلية (SoM) بواسطة Microsoft Research في عام 2023، في البداية لفتح إمكانيات الإرساء البصري لـ GPT-4V. إنها طريقة مرئية بحتة: تستخدم نماذج تجزئة الصور (SAM، SEEM، وما إلى ذلك) لتقسيم المناطق المرشحة تلقائيًا في لقطة الشاشة، وتراكب علامة مرقمة في كل منطقة، ويرى النموذج صورة بها أرقام. يحتاج النموذج فقط إلى الإبلاغ عن الرقم، ويقوم النظام بتحويله إلى الإحداثيات المركزية للمنطقة المقابلة. لا تتطلب العملية برمتها DOM أو أي بنية واجهة داخلية، لذا فهي قابلة للتطبيق بشكل متساوٍ على برامج سطح المكتب الأصلية وواجهات الألعاب - طالما أن نموذج التجزئة يمكنه تحديد المناطق المرشحة.

فهرسة العناصر المنظمة: تنفيذ منظم لفكرة SoM على الويب.

عندما توفر الواجهة نفسها معلومات منظمة، يمكن أن تكون التعليقات التوضيحية أكثر دقة. قبل العرض، تحدد صفحات الويب الحديثة بنية عنصر كاملة (شجرة DOM) والأدوار الدلالية التي تحدد الأزرار وحقول الإدخال وعناصر التحكم الأخرى. توفر أشجار إمكانية الوصول معلومات مماثلة للعديد من تطبيقات سطح المكتب. تقوم أنظمة وكيل الويب مثل browser-use بهذا بالضبط: فهي تقوم بتعداد وترقيم العناصر التفاعلية من DOM. هذا تنفيذ منظم لفكرة SoM للويب (الشكل 6-13). تتكون العملية من أربع خطوات:

1. الحصول على التمثيل المنظم (شجرة DOM) ومعلومات إمكانية الوصول للصفحة من خلال واجهة تصحيح الأخطاء في المتصفح (CDP، بروتوكول Chrome DevTools)
2. اكتشاف العناصر التفاعلية تلقائيًا (الأزرار، ومربعات الإدخال، والروابط، وما إلى ذلك)
3. قم بتعليق كل عنصر تفاعلي بمعرف فريد وارسم المربعات المحيطة في لقطة الشاشة
4. قم بإنشاء قائمة نصية في نفس الوقت تصف العنصر المقابل لكل معرف

Screenshot: [Key elements in the image are annotated with IDs like [1], [2], [3], [4]]

Elements:
[1] <input type="text" placeholder="Search" aria-label="Search" />
[2] <button id="submit-btn" aria-label="Submit form" />
[3] <input type="text" placeholder="Enter your name" value="" />
[4] <a href="/docs" aria-label="Documentation" />

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

توقع الإحداثيات النقية.

يتخطى المسار الثالث التعليق التوضيحي ويطلب من النموذج إخراج الإحداثيات مباشرة. تعتمد أنظمة مثل SeeClick وClaude على نماذج الرؤية المدربة على مجموعات بيانات ضخمة من لقطات شاشة واجهة المستخدم الرسومية المقترنة بمواضع العناصر. تتعلم هذه النماذج كيفية تعيين أوصاف اللغة الطبيعية (على سبيل المثال، “انقر فوق زر الإرسال”) مباشرة إلى إحداثيات لقطة الشاشة الدقيقة، بالاعتماد على الإدراك البصري مثلما يفعل المستخدم البشري.

في مخططات التنبؤ بالإحداثيات، يعتمد فهم النموذج للإحداثيات بشكل كبير على الدقة المستخدمة أثناء التدريب (الشكل 6-14). تم تدريب Claude باستخدام XGA (1024×768)، WXGA (1280×800)، وFWXGA (1366×768). إذا لم تتطابق دقة لقطة الشاشة المدخلة، فستتغير الإحداثيات المتوقعة للنموذج بشكل منهجي - مثل قياس المسافة على خريطة صغيرة ثم تطبيقها مباشرة على خريطة كبيرة. لذلك، يجب تنفيذ آلية قياس إحداثيات ثنائية الاتجاه في طبقة الأداة، ويجب تحديد دقة الهدف بناءً على نسبة العرض إلى الارتفاع لتجنب التمدد غير المنتظم الذي يشوه الصورة وبالتالي يؤدي إلى تحيز الحكم المنسق. على سبيل المثال، إذا كانت دقة الشاشة الفعلية هي 2560×1440 (16:9)، فإن الهدف الأكثر ملاءمة بين الخيارات الثلاثة المدعومة لـ Claude هو FWXGA (1366×768)، الذي يتمتع بنسبة عرض إلى ارتفاع أقرب إلى 16:9. تم تغيير حجم لقطة الشاشة بشكل متناسب إلى 1366 × 768 وإدخالها في النموذج؛ بعد أن يقوم النموذج بإخراج إحداثيات النقر (683، 384)، يتم تعيينها عكسيًا للإحداثيات الحقيقية (683×2560/1366، 384×1440/768) ≈ (1280، 720). على العكس من ذلك، إذا تم تمديد صورة 16:9 بالقوة إلى 1024×768 4:3، فسيتم ضغط الصورة أفقيًا، مما يتسبب في تحول الإحداثيات المتوقعة للنموذج بشكل منهجي.

يمكن تلخيص الاختيار من بين المسارات الثلاثة على النحو التالي: عند توفر المعلومات المنظمة، قم بإعطاء الأولوية لفهرسة DOM/accessibility-tree للحصول على أدق تحديد للموقع وأكثره ثباتًا. عندما لا يكون متاحًا—في برامج سطح المكتب الأصلية مثل Photoshop أو الواجهات المعروضة على قماش/WebGL أو الألعاب —استخدم إما التعليقات التوضيحية المرئية (مسار SoM الأصلي) أو التنبؤ الإحداثي. يعمل التعليق التوضيحي المرئي على تحويل تحديد الموقع إلى مشكلة متعددة الاختيارات، مما يجعلها أكثر ملاءمة للنماذج ذات الأغراض العامة دون تدريب متخصص. يلغي التنبؤ الإحداثي خطوة التعليق التوضيحي ويكون أكثر مباشرة للنماذج المدربة خصيصًا على توطين واجهة المستخدم الرسومية. لا يزال كلا النهجين يواجهان صعوبة في التعامل مع العناصر الصغيرة والواجهات الكثيفة.

التجربة 6-9 ★: استخدام استخدام المتصفح لتنفيذ عمليات المتصفح الآلية

ادمج Playwright، وهو إطار لأتمتة المتصفح، مع نموذج متعدد الوسائط لتنفيذ عمليات متصفح تقودها اللغة الطبيعية. فعّل عرض SoM واحفظ قبل كل قرار لقطة شاشة ذات مربعات تحديد.

مهمة الاختبار «افتح Google وابحث عن طقس سان فرانسيسكو»: بعد البدء تعرض اللقطة صفحة البحث وعناصر التفاعل مرقمة. يختار النموذج مربع البحث، ويدخل “San Francisco weather today”، ويرسل البحث، ثم يستخرج الحرارة والحالة من صفحة النتائج.

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

حتى الآن يقوم إدراك Computer Use على افتراض ضمني: الشاشة ثابتة—لقطة، ثم تفكير في خطوة، ثم نقرة، ثم لقطة جديدة. لكن الشاشات الحقيقية تعرض فيديو وإشعارات عابرة وأصوات اجتماعات. ولا يستطيع Agent يفتح عينيه مرة كل 3–5 ثوانٍ ولا يملك أذنين أن يرى أو يسمع ما يحدث بين إطارين.

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

نماذج العالم في Computer Use

واجهة الرصد في القسم السابق تجيب عن سؤال «ماذا جرى في ما بين اللقطتين»: فبالإطارات المفتاحية ونسخ الكلام والنص الباقي، لم يعد الـ Agent يرى لقطتَي شاشة متباعدتين فحسب. لكن واجهة الرصد لا تُزيل زمن التخطيط. فالـ Agent ما زال يدور في حلقة متسلسلة «لقطة شاشة—تفكير—نقر»، وكلما نفّذ فعلاً أعاد الرصد وفكّر في الخطوة التالية. وتُظهر دراسة الكفاءة OSWorld-Human أنه حتى حين تنجح المهمة في النهاية، تظل خطوات الـ Agent وأزمنة انتظاره أكثر بوضوح من خطوات الإنسان وأزمنته؛ وبلوغُ الدقة مستوى الإنسان ليس مرادفاً لكونه صالحاً للاستعمال بما يكفي.

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

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

حالة سطح المكتب + click/type/scroll/wait ──> تمثيل الحالة التالية

وبهذا يستطيع الـ Agent أن يقارن عواقب الأفعال المرشحة قبل أن ينقر فعلاً، وأن يُعِدّ الخطوة التالية أثناء تحميل الصفحة، وأن يتعافى استناداً إلى فرق الحالة حين تمرّ نافذة منبثقة في لمحة. فلو كانت المهمة «أنشئ ملف Python جديداً في VS Code واكتب فيه hello world»، أمكن النموذج أن يتنبأ أولاً بالحالة المفتاحية لشجرة الملفات والمحرّر بعد النجاح، ثم يختار أفعال النقر والكتابة والحفظ؛ ولو كانت المهمة حذف ملف، أمكنه أن يتنبأ سلفاً داخل سطح مكتب افتراضي معزول هل سيظهر صندوق تأكيد لا رجعة فيه، وأن يطلب تأكيد المستخدم عند اللزوم. والمهم هنا ليس أن يولّد النموذج لقطة شاشة مستقبلية واقعية المظهر، بل أن يتنبأ بفروق الحالة القابلة للفحص التي يقتضيها إتمام المهمة.

وفي تموز/يوليو 2026 عرض Photon-1 الذي أعلنته Induction Labs تنفيذاً من تنفيذات هذا المسار، إذ أتمّ التدريب المسبق لنموذج عالم لـ computer use بثلاثين ألف ساعة فقط من زمن معالج H200. فهو يضغط كل إطار إلى رموز كامنة منفصلة، ويتنبأ انحدارياً ذاتياً بتمثيل الحالة التالية بعد الفعل، بدل توليد لقطات الشاشة بكسلاً بكسلاً في مرحلة التدريب المسبق؛ أما مولّد الصور الملحق به فلا يُستعمل إلا لإظهار التمثيلات الكامنة بصرياً، وليس مكوّناً لازماً للاستدلال. وإذا أُعطي لقطة شاشة بذرية والأفعال التالية لها، أمكنه أن «يتخيّل» حالات سطح المكتب على التوالي، ثم يتعلم عبر التدريب المتصل على الأجهزة الافتراضية أن يُخرج أفعال computer-use.⁷

الهاتف المحمول: حواجز النظام البيئي أصعب من التكنولوجيا

يمتد Computer Use إلى الهاتف المحمول أيضًا. وثمة فروق تقنية حقيقية بين المحمول وسطح المكتب: فمساحة الأفعال لم تعد عادةً «إحداثيات الفأرة + لوحة المفاتيح»، بل صارت تمر عبر واجهات خدمات الوصول في النظام (مثل AccessibilityService في أندرويد) لقراءة عناصر الواجهة وإرسال النقرات وإدخال النص؛ كما تحوّل أسلوب التفاعل من مؤشر الفأرة إلى إيماءات اللمس، فتغيّرت معه دلالة الإحداثيات — إذ تحتاج النقطة (x, y) نفسها إلى نوع إيماءة إضافي يحدد هل هي نقرة واحدة بالإصبع أم ضغطة مطوّلة أم نقطة بداية لإيماءة سحب. والمعايير المخصصة للهاتف المحمول مثل AndroidWorld، التي يعرضها الفصل السابع، تقيس على وجه الدقة قدرة الوكيل على إنجاز مهام حقيقية داخل التطبيقات ضمن مساحة الأفعال هذه.

لكن ما يعرقل المحمول فعليًا ليس هذه الفروق التقنية في الغالب، بل حواجز النظام البيئي. فقد حاول أحد مصنّعي الهواتف دمج مساعد ذكي في هواتف استهلاكية يشغّل تلقائيًا تطبيقات يومية مثل WeChat وTaobao وAlipay، لكنه اصطدم سريعًا بقيود المنصات.

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

ومعنى ذلك أن ما يواجهه Computer Use ليس مجرد مواجهة تقنية مع CAPTCHA (رمز التحقق) وأمثاله، بل تعارض مصالح بنيوي. وهو تناقض يصعب التوفيق بينه على المدى القصير، ويجعل تطبيق Computer Use في السياقات الاستهلاكية أمرًا أشد وعورة من المسائل التقنية الصرفة.

التحكم في الروبوت: ترتيب سطح المكتب باستخدام XLeRobot

كيف يُقرأ هذا القسم: نستخدم من أوله إلى آخره مهمة واحدة فقط——«ضع الكوب الأحمر في الصينية، وألقِ قصاصة الورق الصفراء في سلة المهملات، ثم انظر مرة أخرى في النهاية للتحقق من حالة سطح المكتب». التجربتان 6-10 و6-12 تجريان على جهاز XLeRobot حقيقي، وتحتاجان إلى ذراع وإلى معايرة وإلى مفتاح إيقاف طارئ وإلى مشرف حاضر في الموقع. أما التجارب 6-11 و6-13 و6-14 فهي نظائرها التي تعمل على وحدة معالجة رسوميات محلية. تُبلَّغ نتائج العتاد الحقيقي ونتائج المحاكاة كلٌّ على حدة، لكن هدف المهمة ومعنى الأفعال وشروط النجاح تبقى واحدة.

التحكم في الروبوت عمل أصعب بكثير من «النظر إلى صورة والإجابة عن سؤال». فالنموذج لا يكتفي بفهم المشهد، بل عليه أن يتصرف على نحو متصل في العالم الحقيقي، وكل فعل يغيّر أحوال اللحظة التالية. ويجعل XLeRobot هذا الفرق ملموساً جداً. فالذراع نفسها يمكن أن يتحكم فيها إنسان عن بُعد بلوحة مفاتيح أو ذراع ألعاب أو عتاد واقع افتراضي؛ ويمكن كذلك تسليم رصد الكاميرا ومجموعة محدودة من أدوات الفعل إلى Agent ليستدعيها بنفسه. لا يتغير العتاد ولا تتغير المهمة؛ الشيء الوحيد الذي يتغير هو من يتولى التشغيل——ففي الحالة الأولى يراقب الإنسان ويصحّح باستمرار، وفي الثانية على النموذج ونظام التحكم أن يُتمّا العمل نفسه إلى نهايته.

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

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

1. ما المهمة التي يريد الإنسان إنجازها؟
2. أي مهمة فرعية تأتي تالياً؟
3. ما الفعل المحدد الذي تُخرجه المهارة الحالية؟
4. بعد تنفيذ الفعل، هل ما زال الواقع مطابقاً للخطة الأصلية؟

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

تقسيم العمل بين العتاد والخوارزمية

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

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

يدعم XLeRobot عدة مداخل للتحكم عن بُعد: لوحة المفاتيح، وذراع تحكم Xbox، وJoy-Con من Switch، وعتاد الواقع الافتراضي. والمشغّل البشري يفعل بطبيعته أموراً كثيرة كان على الخوارزمية أن تنفذها صراحةً: يبطئ حين يقترب القابض من الكوب، ويصحّح نقطة الإمساك إذا انزلق الكوب، ويعيد النظر إذا لم ينجح في قرص الورقة من المرة الأولى، ويتأكد من النتيجة حين يدخل الجسم منطقة الهدف. لذلك فالتحكم عن بُعد ليس وسيلة لجمع بيانات العروض التوضيحية فحسب، بل هو أيضاً تجربة تشخيصية «تُثبّت العتاد وتغيّر المشغّل وحده».⁸

التجربة 6-10 ★: ترتيب سطح المكتب بالتحكم عن بُعد في XLeRobot حقيقي

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

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

التحكم عن بُعد على عتاد حقيقي هو أقنع ما يُبيّن الحدَّ الأعلى للمهمة، لكنه غير مناسب لتغيير عدد الأجسام ومواضعها على نطاق واسع. وللحصول على مقارنة قابلة للتكرار وللقياس إحصائياً، ننقل المشكلة نفسها——«إعادة الأجسام إلى أماكنها»——إلى محاكي سطح مكتب ثنائي الأبعاد، ونستعمل متحكماً مثالياً بديلاً عن مشغّل قوي لا يخطئ في الإدراك ولا يسيء اختيار الفعل.

التجربة 6-11 ★: قياس الحد الأعلى المثالي للتحكم في المهمة نفسها داخل المحاكي

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

انظر إلى معدل نجاح المهمة وعدد الخطوات وطول المسار؛ وغيّر أيضاً المواضع الابتدائية للأجسام ومقياس المهمة لترى هل يظل هذا الحد المثالي مستقراً. نستخدم شروط النجاح نفسها الواردة في التجربة 6-10، لكن ما يُقاس هنا محاكاة بلا مشغّلات: وهذا لا يعني أن XLeRobot الحقيقي تحرّك. وستكون التجربتان خطَّي أساس للتحكم الذاتي لاحقاً——فالتجربة 6-10 حلقة مغلقة بشرية على عتاد حقيقي، والتجربة 6-11 حلقة مغلقة مثالية في بيئة محاكاة.

البنية الأساسية للتحكم في الروبوت

يفصل النظام الروبوتي عادةً بين الأعمال ذات المقاييس الزمنية المختلفة.

هذا تقسيم عمل هندسي شائع، لا معمارية النموذج الوحيدة. فقد يتكفل VLA بجزء من الأحكام عالية المستوى، وقد يكون المخطِّط برنامجاً قائماً على القواعد أو VLM أو مُحسِّناً. وأياً كان التنفيذ المختار، يُستحسن فصل «ترتيب المهمة» عن «الفعل الآني»؛ وإلا فإن زمن استدلال النموذج عالي المستوى يجرّ التحكم منخفض المستوى إلى الوراء، ويُرغم التحكمُ عالي التردد في الأسفل النموذجَ الأعلى على معالجة كمّ كبير من التفاصيل غير ذات الصلة. وعلى XLeRobot ينبغي ألا يُخرج النموذج زوايا مفاصل عشوائية مباشرة: فهو يكتفي باختيار مهارات ذات حدود واضحة مثل pick وplace وverify_state وstop، ثم يتولى المنفِّذ المعايَر——المحدود السرعة وذو المهلة الزمنية——تحويلها إلى حركة حقيقية للذراع.

التخطيط طويل الأفق وتفكيك المهمة

حين يقول المستخدم «رتّب سطح المكتب»، لا يستطيع النظام تمرير هذه الجملة كما هي إلى نموذج الفعل. فالمخطِّط يُعدّد أولاً الأجسام والأهداف في المشهد، ويحدد الترتيب، ثم يكتب لكل خطوة شرط البدء وشرط الإنهاء وحدود المخاطرة. مثلاً:

معالجة الكوب الأحمر → إزالة الورقة الصفراء → فحص سطح المكتب

و«معالجة الكوب الأحمر» تتفكك بدورها إلى فعلين وتحقق واحد:

pick(red_cup) → place(red_cup, tray) → verify_state()

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

التجربة 6-12 ★★: دع Gemini Robotics-ER 1.5 يرتّب سطح المكتب ذاتياً بواسطة XLeRobot

أبقِ على XLeRobot الحقيقي وترتيب سطح المكتب ونصّ المهمة وشروط النجاح من التجربة 6-10؛ واستبدل المشغّل البشري وحده بـ Agent. وكِل الرصد والتخطيط إلى نموذج استدلال مجسّد مثل Gemini Robotics-ER 1.5، وافتح عبر حلقة وكيل على طريقة RoboCrew خمس أدوات فقط: observe_scene وpick وplace وverify_state وstop.⁹

يرصد النموذج سطح المكتب أولاً، ويحدد ترتيب المعالجة، ثم يستدعي أفعال الإمساك والوضع المعايَرة في XLeRobot. وكلما أتمّ مهارة وجب عليه أن يعيد الرصد ويتحقق من الشرط البعدي. وحين يفلت الإمساك لا يُسمح له إلا بإعادة محاولة المهارة الحالية؛ وعليه أن يستدعي stop إذا طلب المستخدم التوقف، أو خرج جسم عن حيّز العمل، أو تعذّر التحقق من الحالة. ولا يجوز للنموذج أن يُخرج زوايا مفاصل عشوائية مباشرة، ولا أن يتخطى التحقق الفعلي لمجرد أنه قال هو نفسه من قبل «انتهيت».

معيار القبول هو عينه في التجربة 6-10 تماماً: الكوب داخل الصينية، والورقة داخل سلة المهملات، والذراع عادت إلى وضعيتها الآمنة، ولا اصطدام ولا خروج عن الحيّز. والفرق أن معنى المهمة في التجربة الذاتية يجب أن يأتي من رصد النموذج نفسه، وأن تأتي الأفعال الحقيقية من استدعاءات الأدوات، وأن تُؤكَّد الحالة النهائية برصد جديد. وليس للإنسان إلا التشغيل والإيقاف الطارئ والإشراف على السلامة، ولا يجوز له أن يُتمّ الفعل نيابةً عن Agent في منتصف الطريق. عندئذ فقط تصلح التجربتان 6-10 و6-12 لمقارنة مباشرة: «بالعتاد نفسه والمهمة نفسها، ما الذي ينقص حلقة النموذج المغلقة قياساً بحلقة الإنسان».

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

التحكم عبر VLA

VLA اختصار لـ Vision-Language-Action، أي «نموذج الرؤية—اللغة—الفعل». يتلقى المشهدَ الحالي وتعليمةَ مهارة واحدة، ويُخرج الفعلَ الذي على الروبوت تنفيذه تالياً:

الرصد الحالي + تعليمة المهارة → فعل

في مثال XLeRobot، لا يقدّم المخطِّط عالي المستوى سوى pick(red_cup)؛ أما من أي اتجاه يقترب من الكوب، ومتى ينغلق القابض، وبأي مسار تُرفع الذراع، فأمر يقرره VLA أو سياسة المهارة انطلاقاً من المشهد الراهن. وحين تُتمّ طبقة التنفيذ هذه الحركة القصيرة، يُصوَّر سطح المكتب من جديد، ولا يُسمح للمخطِّط بتقديم place(red_cup, tray) إلا بعد تأكيد أن الكوب قد أُمسك فعلاً. أي أن استدعاء الأداة يعرّف تغيّر الحالة المطلوب، وVLA يعرّف كيف يتحقق هذا التغيّر بفعل متصل.

يقطّع RT-2 وOpenVLA الفعلَ المتصل إلى رموز (tokens) منفصلة ويُخرجانها واحداً تلو الآخر، تماماً كتوليد الجُمل. ويمثّل π₀ المسار الآخر: فهو يولّد مباشرةً مسارات فعل متصلة وسلسة. ولا أفضلية بسيطة لأحدهما على الآخر. فالرموز المنفصلة يسهل وصلها بنماذج اللغة؛ والمسارات المتصلة أنسب للتعبير عن الحركة السلسة. والمفاضلة الحقيقية هي كيف يُمثَّل الفعل، لا حجم النموذج وحده.¹⁰

عادةً لا يستطيع النموذج الكبير الاستدلال إلا 1—10 مرات في الثانية، بينما قد يتحدّث المتحكم التقليدي من عشرات إلى آلاف المرات في الثانية. ومن الممارسات الهندسية الشائعة «تقطيع الفعل» (action chunking): يولّد النموذج دفعةً واحدة مقطعاً قصيراً من الأفعال المستقبلية، وينفّذ خيط التحكم هذا المقطع بتردد عالٍ، بينما يُعِدّ النموذج المقطعَ التالي في الخلفية. وبذلك يُخبَّأ جزء من انتظار الاستدلال داخل زمن تنفيذ الأفعال. والثمن أن المقطع كلما طال ازدادت الحركة سلاسة، لكن قلّ ما يراه النموذج من مشاهد جديدة خلال تلك الفترة. فإذا مدّ XLeRobot ذراعه ليأخذ الكوب فاصطُدم بالكوب وانزاح في الأثناء، فقد يمضي في تنفيذ أفعال وُلّدت من صورة قديمة. إذن فتقطيع الفعل مقايضة بين السلاسة وسرعة الاستجابة، لا تسريع بلا ثمن.

حدود VLA

«التخطيط طويل الأفق + VLA» تصميم أساسي صالح للعمل، لكنه يترك مشكلات يسهل إغفالها.

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

إذن، كون نموذج اللغة يعرف كلمة «كوب» لا يعني أنه يعرف كيف يغيّر الاحتكاكُ والتلامسُ وتموّجُ السائل وكابلُ الطاقة الحالةَ المستقبلية. فـ VLA يجيب أساساً عن «ماذا ينبغي أن أفعل الآن»؛ أما الحكم على «ماذا قد يحدث بعد الفعل» فيحتاج إلى نوع آخر من النماذج.

نماذج العالم

يمكن فهم نموذج العالم بوصفه متنبئاً بعواقب الأفعال. وما يتعلمه هو: إذا اتُّخذ فعل ما في الحالة الراهنة، فكيف قد تتغير الحالة في اللحظة التالية.

الحالة الراهنة + فعل مرشّح
    → تنبّأ بالحالة التالية أو بمقطع من المستقبل
    → قارن نتائج المرشحين
    → اختر الفعل، أو أعد التخطيط، أو توقّف بأمان

ونموذج العالم الصالح للاستعمال في الروبوتات عليه أن يُحسن ثلاثة أمور على الأقل:

• أن يفهم الحالة الراهنة؛
• أن يتنبأ بالنتائج التي قد تجلبها الأفعال المختلفة؛
• أن يسلّم هذا التنبؤ إلى المخطِّط أو المتحكم ليعينه على الاختيار.

وأي VLM لا يُحسن إلا وصف الفيديو، أو نموذج لا يُحسن إلا توليد الصور، لا يصير تلقائياً نموذج عالم موثوقاً للروبوتات. بل عليه أن يعرف ما الفعل، وأن يقدر على التنبؤ بأثر هذا الفعل في الأجسام والبيئة. ويمثّل V-JEPA 2 مسار التنبؤ بالمستقبل في الحالة الداخلية، بينما يتعلم World-Action Model صراحةً علاقة «الفعل—الرصد المستقبلي». ويمكن استعمالهما جنباً إلى جنب مع VLA، ولا يلزم أن يحلا محله.¹¹

وفي أي نظام حقيقي، لنموذج العالم عادةً ثلاثة استعمالات:

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

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

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

التجربة 6-13 ★★: مقارنة ثلاث حلقات ذاتية لترتيب سطح المكتب في المحاكي

انقل مهمة التجربة 6-12 وحالاتها الهدف وشروط نجاحها وأدواتها الخمس كما هي إلى محاكي سطح المكتب، واستبدل مشغّلات XLeRobot الحقيقي وحدها بمنفِّذ محاكاة قابل للضبط، يُحدث في الإمساك بين الحين والآخر إخفاقاً عابراً قابلاً للتدارك. وبذلك يمكن مقارنة ثلاث استراتيجيات من دون تغيير المشكلة.

التنفيذ مفتوح الحلقة يولّد متتالية الأفعال كاملةً دفعة واحدة ولا يعيد الرصد في الطريق. والتحقق خطوة بخطوة يعيد قراءة الحالة عند كل pick وكل place، ولا يعيد عند الإخفاق إلا المهارة الحالية. والتنفيذ التنبؤي يضيف إلى ذلك نموذج عالم قصير المدى، فيقارن النتائج المتوقعة للمهارات المرشحة قبل اختيار الخطوة التالية. تقارن التجربة معدل نجاح المهمة وكلفة استدعاءات الأدوات والقدرة على التعافي من الإخفاق، وتفحص هل جميع حالات النجاح النهائية مؤكَّدة برصد جديد من verify_state.

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

من بيئة المحاكاة إلى الروبوت الحقيقي

استقرار التجربة 6-13 في المحاكي لا يعني أن XLeRobot الحقيقي في التجربة 6-12 سينجح بالقدر نفسه. فالانتقال من المحاكاة إلى الآلة الحقيقية ليس استبدال متحكم آخر، بل تحمّل الفرق بين بيئتين. يمكن للتدريب أن يستعمل بيانات التحكم عن بُعد وبيانات الفيديو وبيانات التفاعل المحاكى؛ لكن عند النشر الفعلي يظهر الكوب الأحمر نفسه والورقة الصفراء نفسها والصينية نفسها وسلة المهملات نفسها تحت خلفية مختلفة وإضاءة مختلفة وموضع كاميرا مختلف وعلاقات حجب مختلفة، وتلاقي الذراع فوق ذلك احتكاكاً آخر وضوضاء استشعار أخرى وتأخير مشغّلات آخر. وإذا كبرت هذه الفروق بما يكفي، فقد تكفّ الحركات المتعلَّمة في المحاكاة عن النفع في الواقع.

التجربة 6-14 ★★★: اختبار عابر لبيئات RGB على مهمة سطح المكتب نفسها

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

اختبر كل السياسات في البيئة الأصلية وفي البيئة الجديدة المعدَّلة، ثم قارن دقة قرار الفعل قبل تغيّر الظروف البصرية وبعده. وما تحاول هذه التجربة الإجابة عنه ليس «هل صار المحاكي مثل XLeRobot الحقيقي»، بل سؤالاً أضيق: هل يعين توسيعُ مدى تغيّر المشاهد عمداً أثناء التدريب مهمةَ الكوب—الصينية والورقة—سلة المهملات نفسها على التكيف مع بث كاميرا جديد؟ وحتى لو تحسنت النتيجة، يظل النشر على الآلة الحقيقية مقتضياً معايرة كاميرا فعلية واختبارات للمشغّلات وحلقة أمان مغلقة كاملة.¹³

ملخص الفصل

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

وتتشارك الأقسام الأربعة الهيكل التحكّمي نفسه:

إدراك متصل
  ← الحكم على الحالة الراهنة والتوقيت
  ← اختيار ردّ أو فعل
  ← إدخال المخرَج إلى البيئة
  ← ملاحظة التغذية الراجعة
  ← المتابعة أو التصحيح أو إعادة المحاولة أو التوقّف أو إعادة التخطيط

كما تتشارك البدائيات نفسها—الإيقاظ، والنقاط الآمنة، والإلغاء، والمقاطعة، والفصل بين السريع والبطيء.

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

أسئلة للتأمل

1. ★★ في بنية الوكيل غير المتزامنة، يجب تحديد إستراتيجية الأولوية لقائمة انتظار الأحداث في وقت التصميم. ولكن إذا كان حكم الأولوية نفسه يتطلب فهمًا دلاليًا (على سبيل المثال، تحديد ما إذا كانت الرسالة الجديدة أكثر إلحاحًا من المهمة الحالية)، فمن الذي يجب أن يصدر هذا الحكم - محرك القواعد أو استدعاء LLM آخر؟ ما هي تكاليف كل منهما؟
2. ★★ في معالجة الأحداث القائمة على قائمة الانتظار، تميل النماذج إلى التركيز فقط على الحدث الأخير. يخفف هذا الفصل من هذه المشكلة من خلال علامات شريط حالة الوكيل وتلخيصها. ولكن إذا كانت قائمة الانتظار تحتوي على 20 حدثًا متراكمًا (10 نتائج أدوات + 5 رسائل مستخدم + 5 تنبيهات للنظام)، فكيف يمكنك تنظيم ترتيب العرض التقديمي وتنسيق هذه الأحداث بحيث لا يفوت النموذج المعلومات الأساسية؟
3. ★★★ عندما يتفاعل الوكيل مع العالم الخارجي نيابة عن مستخدم، فإنه يواجه بشكل أساسي خيار الهوية: استخدام هوية افتراضية مستقلة (بريد إلكتروني ورقم هاتف مخصصين) للعمل كطرف ثالث، أو تشغيل الحسابات الشخصية للمستخدم مباشرة كمستخدم؟ الأول يسمح بتشغيل الخلفية بشكل مستقل، لكن الأطراف الثالثة قد لا تثق في هوية غير بشرية؛ يحتوي الأخير على سياق وأذونات أكثر اكتمالاً ولكنه يقدم مشكلات تتعلق بالترخيص والثقة والحدود الأمنية. في أي السيناريوهات تعتقد أنه يجب اختيار كل وضع؟
4. ★★ يدمج النموذج الشامل لوكلاء الصوت ASR-LLM-TTS في نموذج واحد، مما يقلل زمن الوصول ولكنه يفقد النمطية. إذا حدث خطأ في النموذج الشامل في مرحلة معينة (على سبيل المثال، التعرف على الكلام)، فإن تصحيح الأخطاء وإصلاحها يكون أصعب بكثير من خط أنابيب تسلسلي. كيف يمكنك تصميم نظام مراقبة لوكيل صوتي شامل؟
5. ★ يحقق Step-Audio R1 “التفكير أثناء التحدث” من خلال بنية MPS ثنائية الدماغ. ومع ذلك، فإن البشر، عندما “يفكرون أثناء التحدث”، غالبًا ما يقولون أشياء قبل أن يفكروا فيها بشكل كامل، أو يصححون أنفسهم، أو يستخدمون كلمات حشو. هل يجب على “تفكير الوكيل أثناء التحدث” أن يحاكي هذه الخصائص البشرية؟
6. ★★ تعمل SoM (مجموعة العلامات) ومتغيراتها المنظمة (فهرسة عناصر DOM) على تحويل تحديد الموقع البصري لاستخدام الكمبيوتر من توقع الإحداثيات المفتوحة إلى تحديد معرف المجموعة المغلقة، ولكنها جميعًا تتطلب اكتشاف عناصر واجهة المستخدم والتعليق عليها أولاً - سواء عبر نموذج التجزئة أو DOM. إذا كانت الواجهة تحتوي على عناصر تحكم غير قياسية أو عناصر متغيرة ديناميكيًا، فقد تكون التعليقات التوضيحية غير كاملة أو غير دقيقة. في مثل هذه الحالات، هل يجب أن نعود إلى تنسيق التنبؤ؟
7. ★★ منصات الروبوت التي تبلغ قيمتها بضع مئات من الدولارات مثل XLeRobot تجعل جمع بيانات التشغيل عن بعد غير مكلف. ومع ذلك، فإن جودة بيانات التشغيل عن بعد تعتمد بشكل كبير على مهارة المشغل. كيف ستؤثر البيانات منخفضة الجودة الواردة من مشغل غير ماهر على تدريب نموذج VLA؟ كيف يمكن تصفية البيانات منخفضة الجودة تلقائيًا أثناء مرحلة جمع البيانات؟
8. ★★★ يغطي هذا الفصل ثلاث طرق للتفاعل: الصوت، واستخدام الكمبيوتر، والروبوتات. الاتجاه الشائع عبر هذه الطرائق هو التطور من خطوط الأنابيب التسلسلية إلى النماذج الشاملة. إذا استمر هذا الاتجاه، كيف يمكن أن تبدو طبقة تفاعل الوكيل بعد خمس سنوات؟
9. ★★ تعمل فهرسة عناصر DOM/Accessibility Tree بشكل جيد على تطبيقات الويب القياسية، ولكن عددًا متزايدًا من واجهات البرامج (عرض Canvas/WebGL، وعناصر التحكم المرسومة حسب الطلب عبر الأنظمة الأساسية) لا توفر معلومات منظمة يمكن الوصول إليها، وتعتمد فقط على التعليقات التوضيحية المرئية أو توقع الإحداثيات. هل تعتقد أن استخدام الكمبيوتر يجب أن يراهن على نهج مرئي بحت، أو يحافظ على المسارات المنظمة والمرئية؟ ما هي تكاليف وفوائد الحفاظ على كلا المسارين؟
10. ★★ تستخدم نماذج VLA تقسيم الإجراء - كما هو مذكور في النص، فإن التكوين النموذجي لـ π₀ يولد 25-50 إجراءً مستقبليًا عند 50 هرتز - لإخفاء زمن الوصول للاستدلال خلال وقت التنفيذ. ومع ذلك، إذا تغيرت البيئة فجأة أثناء التنفيذ (على سبيل المثال، تم نقل كائن)، يصبح تسلسل الإجراء الذي تم إنشاؤه مسبقًا غير صالح. كيف يمكننا الموازنة بين ميزة الكفاءة في تقسيم العمل والحاجة إلى الاستجابة للتغيرات البيئية؟
11. ★★★ تواجه جميع السيناريوهات الثلاثة في هذا الفصل (الصوت، واستخدام الكمبيوتر، والروبوتات) مشكلة زمن الوصول لحلقة “الإدراك والتفكير والفعل” وتتطور نحو التفكير السريع والبطيء المتوازي. ويتجلى ذلك في الصوت على أنه “التصحيح بعد الخطأ في الكلام”. في استخدام الكمبيوتر، مثل “النقر أولاً، ثم البحث”؛ في علم الروبوتات، مثل “الخطوة ثم النظر”. كيف يمكننا التأكد من أن هذه الإجراءات المبنية على التفكير السريع لا تؤدي إلى عواقب لا رجعة فيها؟
12. ★★★ تتكرّر في هذا الفصل مجموعة الأوّليات نفسها (الإيقاظ، نقطة الأمان، الإلغاء، المزاحمة، فصل السريع عن البطيء) مطبَّقةً على مقاييس زمنية مختلفة. اختر واحدة منها وبيّن كيف يختلف تطبيقها بين المعالجة الموجّهة بالأحداث (ثوانٍ — أيام) وتجزئة فعل الروبوت (مللي ثانية). وما الذي يحدّد هذا الاختلاف أساسًا — سرعة تغيّر البيئة، أم قابلية الفعل للتراجع، أم كلفة الحصول على الملاحظة؟