تنتقل المهام (Tasks) باستمرار بين أيدٍ متعددة في الفِرق التي تدير عدة وكلاء برمجة (Coding Agents) في الوقت نفسه؛ إذ قد يتولى وكيل Sonnet كتابة التعديل، بينما يقوم وكيل Opus بمراجعته وتدقيقه، أو قد يتعثر وكيل Claude Code فتتحول المهمة مباشرة إلى وكيل Codex. ومع إطلاق نموذج Claude Sonnet 5.5 في 28 سبتمبر، تأكدت رسميًا حقيقة كانت واضحة جزئيًا من قبل: منطق تفكير النموذج (Model's reasoning) لا ينتقل مع مخرجات العمل. فقد ورد في صفحة ما الجديد في Sonnet 5.5 من Anthropic أن كل كتلة تفكير (thinking block) "تسجل النموذج الذي أنتجها"، ولا يمكن لأي نموذج آخر قراءة كتل التفكير الخاصة بنموذج Sonnet 5.5.
المشكلة الحقيقية تكمن في الهدوء الذي يتم به هذا الأمر؛ فعندما يتضمن الطلب كتلة تفكير لا يستطيع النموذج قراءتها، تتجاهلها واجهة برمجة التطبيقات (API) وتحذفها قبل أن تصل إلى النموذج أصلًا. يكتمل الطلب بنجاح، ولا يُحاسب المستخدم ماليًا على الكتل المحذوفة، ويكون الأثر الوحيد هو حقل input_transformations، والذي لا يظهر إلا إذا أرسلت الترويسة التجريبية thinking-binding-controls-2026-08-01. ونتيجة لذلك، يستلم الوكيل المراجع فرق التعديلات (diff) مجردًا تمامًا من أسبابها وسياقها ودون أن يظهر أي خطأ برمجي، فيبدو تدقيقه للمهمة مبنيًا على إحاطة شاملة، على عكس واقعه تمامًا.
خلاصة القول (TL;DR)
عند تسليم سياق المهمة بين النماذج المختلفة، تحكم المسألة قاعدة ذهبية واحدة: السياق الوحيد الذي ينجو من عملية التسليم (Handoff) هو ما دُوّن صراحةً في سجل المهمة (Task). كتل التفكير مقيدة بثلاثة قيود: النموذج الذي أنتجها، والمحادثة نفسها بدقة، وبالنسبة لـ Sonnet 5.5 فهي مقيدة بالحساب أيضًا. احرص على أن يختتم كل وكيل عمله بتعليق تسليم مفصل يوضح: القرارات وأسبابها، والافتراضات، والمسارات التي جُرّبت ولم تنجح، والأسئلة المعلقة، والملفات المعدلة، والاختبارات المنفذة. وإذا كنت تبني منصتك الخاصة (Harness)، فاجعل سجل الأحداث تراكميًا دون تعديل (append-only).
كتلة التفكير مقيدة بثلاث طرق
كتلة التفكير هي مسار الاستدلال والمنطق الذي أنتجه النموذج لدورة محادثة واحدة (Turn)، وتُعاد مصحوبة بتوقيع رقمي تتحقق منه واجهة التطبيقات البرمجية قبل السماح لأي طلب لاحق باستخدامها. تشرح وثائق الاحتفاظ بالتفكير (preserved thinking) ثلاثة قيود ارتباط، وكل منها يطابق نوعًا من إجراءات التسليم التي يمارسها فريقك بالفعل.
الارتباط بالنموذج (Model): يستطيع Sonnet 5.5 قراءة الكتل الصادرة عن Sonnet 5 وOpus 4.8 وHaiku 4.5 والنماذج الأقدم، لكنه يعجز عن قراءة كتل Opus 5 أو Opus 5.5 أو Fable أو Mythos. كما أن اتجاه التبديل له دور حاسم؛ فوفقًا لملاحظات Anthropic حول تبديل النماذج أثناء المحادثة، فإن الانتقال من Sonnet 5 إلى Sonnet 5.5 يحافظ على التفكير السابق، في حين أن التحول من Sonnet 5.5 إلى أي نموذج آخر يجعل الدورات اللاحقة تعمل دونه تمامًا. وينطبق ذلك أيضًا على ميزة الرجوع التلقائي على الخادم من Anthropic، والتي تعيد محاولة تنفيذ بعض طلبات Sonnet 5.5 المرفوضة عبر Sonnet 5.
الارتباط بالمحادثة (Conversation): لا يمكن استخدام كتلة التفكير إلا إذا وردت بعد نفس رسالة النظام التوجيهية (System prompt) والأدوات (Tools) وتسلسل الرسائل الأصلي تمامًا. وتوضح الأسئلة الشائعة في الوثائق نتيجة ذلك: لا يمكن ترحيل منطق التفكير إلى محادثة أخرى؛ لذا يجب بدء المحادثة الجديدة بملخص شامل لحالة المهمة (الهدف، والقرارات المتخذة، والملفات والنتائج المحققة حتى الآن، والخطوة التالية). وعندما تنتقل المهمة إلى وكيل مختلف، تبدأ بيئة التشغيل (Runtime) جلسة جديدة تُعد محادثة منفصلة كليًا حتى لو كانت على النموذج نفسه. والسبب نفسه يفسر لماذا تبدأ أي جلسة جديدة لأي أداة من نقطة الصفر، كما هو مفصل في مقال الحفاظ على السياق عبر جلسات الذكاء الاصطناعي.
الارتباط بالحساب (Account): لا تعمل كتل التفكير الخاصة بنموذج Sonnet 5.5 إلا داخل الحساب الذي أنشأها أو حساب مرتبط به. وتشير تدوينة إطلاق Sonnet 5.5 من Anthropic إلى أحد المواضع التي يظهر فيها هذا القيد: التبديل بين الحسابات في منتصف الجلسة داخل Claude Code.
والمحصلة باختصار: منطق التفكير لم يكن ينتقل أصلًا بين الوكلاء؛ وكل ما فعله Sonnet 5.5 هو توثيق هذه الحقيقة رسميًا كجزء من بنود واجهة برمجة التطبيقات.
ثلاث عمليات تسليم تسقط التفكير بصمت
| عملية التسليم | ما ينتقل بنجاح | ما يُفقد تمامًا | كيف تعرف بحدوث ذلك |
|---|---|---|---|
| من وكيل التنفيذ Sonnet 5.5 إلى وكيل المراجعة Opus 5.5 | ملف الفروقات (diff)، والمستودع البرمجي، ووصف المهمة وتعليقاتها | تفكير Sonnet 5.5؛ فلا يستطيع أي نموذج آخر قراءته، فضلًا عن أن جلسة المراجعة تمثل محادثة جديدة على أي حال | لا شيء يظهر عبر الوكلاء. أما داخل محادثة API واحدة، فيظهر إدخال model_binding_mismatch عند استخدام الترويسة التجريبية |
| من وكيل Claude Code إلى وكيل Codex | ملف الفروقات، والفرع البرمجي (branch)، وسجل المهمة، وملف القواعد المشتركة للمستودع | كل تفكير Claude وحالة جلسة Claude Code بالكامل؛ حيث يبدأ Codex محادثته المستقلة الخاصة | لا شيء إطلاقًا |
| النموذج نفسه بحساب مختلف (تبديل الحساب في منتصف الجلسة في Claude Code، أو إعادة تشغيل جلسة محفوظة باستخدام بيانات اعتماد حساب آخر) | السجل النصي المرئي: الرسائل، واستدعاءات الأدوات (tool calls)، والنتائج | كل كتل تفكير Sonnet 5.5 التي تم إنشاؤها تحت الحساب الأول | إدخال organization_binding_mismatch عند تفعيل الترويسة التجريبية عبر واجهة Claude API وGoogle Cloud؛ ودون ذلك لا يظهر أي تنبيه |
يكمن الخطر الأكبر في العمود الأخير؛ فالعمليات الثلاث تكتمل بنجاح ظاهري، ويجيب الوكيل المتلقي بثقة تامة مستندًا إلى معلومات أقل بكثير مما كان متاحًا لسابقه. وقد يعتمد المراجع على نموذج آخر تعديلًا كان لدى الوكيل المنفذ شكوك قوية حوله، ببساطة لأن تلك الشكوك بقيت حبيسة كتل التفكير التي لم يرها المراجع قط.
أشرنا سابقًا إلى أن التبديل بين وكلاء البرمجة "يحافظ على الكود البرمجي ويُسقط منطق التفكير". وهذا الواقع بات ينطبق الآن على مستوى واجهة برمجة التطبيقات أيضًا، وهو أمر بالغ الأهمية للفرق التي تعتمد على تشغيل Claude Code وCodex معًا على قاعدة كود واحدة، وكذلك لقواعد التوجيه التي تصعّد المهام تلقائيًا. فإذا كانت المهام المعقدة تُحال من وكيل Sonnet 5.5 إلى Opus 5.5 كما ناقشنا في مقال Sonnet 5.5 أم Opus 5.5: أي وكيل تسند إليه المهمة؟، فإن كل تصعيد من هذا النوع يُعد تسليمًا مطابقًا للسطر الأول من الجدول أعلاه.
ما يجب أن تحتويه مذكرة التسليم عند تعذر انتقال التفكير
تؤدي مذكرة تسليم وكيل البرمجة وظيفة واحدة محددة: صياغة مسار التفكير المهم كتابةً في موضع يستطيع العامل التالي قراءته. توسع الحقول الموضحة أدناه شكل الملخص المقترح من Anthropic بإضافة أمرين أساسيين كانت كتل التفكير تحتفظ بهما ولا تظهرهما فروق الأكواد أبدًا: سبب اختيار مسار بعينه، وما هي المسارات التي استُبعدت بالفعل. يمكنك تضمين هذا النموذج في التعليمات التوجيهية لأي وكيل لديه صلاحية تمرير المهام:
Before you finish, post one comment on the Task that starts with "Handoff".
Write it for a reader who has this Task and the diff, and nothing else.
Decisions: each choice you made and the reason for it, one line each
Assumptions: what you took as true without verifying it
Tried, failed: approaches you ruled out and why, so nobody retries them
Open questions: what a person or the next Agent has to decide
Files touched: paths changed, and which ones are unfinished
Checks run: exact commands and their results; name any check you skipped
Next step: the one action you would take next
ثمة ثلاث تفاصيل أساسية تضمن دقة هذه العملية وفاعليتها:
اطلب القرارات، لا التفكير الداخلي المجرد. يُعد Sonnet 5.5 أول طراز من Sonnet يضم مصنفات أمان مدمجة لمنع استخراج التفكير (reasoning extraction)؛ إذ تمنع فئة الرفض reasoning_extraction الطلبات التي تسعى إلى إعادة إنتاج الاستدلال الداخلي حرفيًا ضمن نص الاستجابة. فطلب مثل "الصق تفكيرك في التعليق" يقع تحت طائلة هذا المنع، أما توجيه "سرد كل قرار مع سببه" فهو تقرير عمل اعتيادي مقبول.
بند "ما جُرّب وفشل" يوفر معظم الوقت. المسار المسدود لا يترك أثرًا في ملف الفروقات؛ وبغياب هذه الملاحظة، يسهل على الوكيل التالي الوقوع في المأزق نفسه وإضاعة الوقت في إعادة تجربة النهج الفاشل ذاته.
الفحوصات تعني الأوامر ونتائجها الفعلية. عبارة "اجتازت الاختبارات بنجاح" تظل مجرد ادعاء غير مثبت؛ بينما يُعد الأمر البرمجي المنفذ مقرونًا بإحصائيات نتائجه دليلًا ملموسًا يمكن للمراجع إعادة تشغيله والتحقق منه.
معيار القرار هنا واضح: يمكنك تجاوز كتابة المذكرة إذا كان الوكيل نفسه يتولى المهمة من البداية حتى المراجعة في جلسة عمل واحدة، وكان الشخص المسؤول عن الاعتماد سيراجع الفروقات بنفسه في كل الأحوال. لكن اجعلها إلزامية فور تغيير المسؤول عن المهمة، أو تبديل النموذج، أو إحالتها إلى وكيل مراجعة مستقل. تعالج قوالب تسليم وكلاء البرمجة نقاط الاتصال بين الإنسان والوكيل، بينما تركز هذه المذكرة على نقطة الاتصال الحساسة بين وكيلين آليين.
إذا كنت تبني منصتك الخاصة، فإن تعديل السجل بات ينتج خطأً برمجيًا
يمكن لمعظم القراء تجاوز هذا القسم؛ إذ توضح وثائق التفكير المحفوظ أن شيئًا لن يتغير إذا كانت طلباتك تُبنى تلقائيًا عبر Claude Code، أو claude.ai، أو Claude Managed Agents، أو حزمة تطوير وكلاء Claude (SDK). لكن الأمر يكتسب أهمية بالغة إذا كان كودك الخاص يستدعي Messages API مباشرة.
فبالنسبة للحسابات المنشأة في أو بعد 31 أغسطس 2026، الساعة 00:00 بالتوقيت العالمي المنسق عبر Claude API وAmazon Bedrock وGoogle Cloud، فإن إعادة تشغيل كتلة تفكير لـ Sonnet 5.5 بعد إجراء أي تعديل على ما يسبقها (سواء موجه النظام، أو الأدوات، أو أي رسالة سابقة) سيعيد رمز الخطأ 400. أما الحسابات الأقدم فلا تخضع لهذا الفحص إلا إذا فُعّل يدويًا في الطلب، وهو ما يضعك في فخ محكم: يعمل مفتاحك البرمجي الخاص بنجاح، بينما يواجه المستخدم الذي يشغل أداتك بمفتاح حساب أحدث الخطأ 400 فورًا. والحل الوحيد هو: جعل سجل المحادثة تراكميًا فقط دون أي تعديل رجعي (append-only).
- ثبّت موجه النظام والأدوات فور بدء الجلسة؛ وإذا أردت تعديل التعليمات، فأضف رسالة نظام جديدة في منتصف المحادثة عبر الإلحاق، وهي ميزة يدعمها Sonnet 5.5 بينما يفتقر إليها Sonnet 5.
- أعد إرسال كل دورة مساعد (Assistant turn) كما وردت تمامًا، بما في ذلك كتل التفكير الفارغة.
- قم بضغط السياق (Compact) عبر واجهة برمجة التطبيقات، وليس عن طريق إعادة صياغة الأدوار القديمة. يتيح الضغط عند الطلب (الميزة التجريبية
compact-2026-09-04) كتلة ملخص موقعة رقميًا ترسلها بدلًا من الرسائل التي تختصرها. كما أن التلخيص البسيط الموصى به في الوثائق يرسل رسالة ملخص واحدة متبوعة بالتعليمات التالية، مما يضمن عدم إعادة إرسال أي تفكير قديم.
{ "role": "system", "content": "Review found a race in the retry path. Do not change the public API." }
باستخدام الترويسة التجريبية، يقوم الإعداد prefix_mismatch_behavior: "drop_block" بحذف الكتل غير المتطابقة بدلًا من إظهار رسالة خطأ. وتشير الوثائق صراحةً إلى أن هذا الخيار يخفي حقيقة التعديل بدلًا من معالجته جذريًا.
لاحظ جيدًا بنية الضغط الموصى بها من Anthropic؛ فعندما يتعذر إعادة تشغيل منطق التفكير، يأتي الحل من Anthropic في هيئة ملخص مكتوب، وهو في جوهره مذكرة تسليم بمسمى آخر.
أين تستقر عملية التسليم داخل Sharkly؟
تمثل المهمة (Task) السجل المشترك للجميع، ومذكرة التسليم مكانها الطبيعي داخل المهمة لأنه لا يوجد شيء آخر يدوم بعد انتهاء الجلسة. تحتوي المهمة على المحادثة الكاملة (حوار مبني على التعليقات)، والخط الزمني للنشاط الذي يوثق التعليقات والتغييرات، وسجل عمليات التنفيذ (Executions) لكل تشغيل. وتُحفظ نصوص الوكيل الموجهة للفريق كتعليق مرتبط بدورة التشغيل الخاصة به؛ وعندما يحتاج الوكيل إلى استفسار، يعود سؤاله إلى المهمة في هيئة تعليق، وتتحول حالة المهمة إلى "بانتظار رد بشري"، ليصل التنبيه مباشرة إلى صندوق الوارد (Inbox) الخاص بالشخص المسؤول.
وهنا تحديدًا تتجلى الفائدة العظمى عند إعادة إسناد المهام؛ فعند تغيير المكلف بالمهمة من وكيل Sonnet 5.5 إلى مراجع Opus 5.5 أو وكيل Codex، تنطلق دورة التشغيل التالية بالاعتماد على بيانات المهمة المسجلة، لا من واقع نص المحادثة السابق. توضح وثائق Sharkly ما يمكن أن تحتويه دورة العمل المستندة إلى المهمة: العنوان والوصف، وأحدث التعليقات، والتعليق الذي أطلق عملية التشغيل، وتعليمات الوكيل، والمستودعات البرمجية المرتبطة به. ويأتي تعليق التسليم ضمن هذه القائمة حتمًا، في حين يغيب التفكير الداخلي للوكيل السابق، وهو ما كانت واجهة التطبيقات ستسقطه على أي حال عند تغيير النموذج.
ويقودنا هذا إلى ممارستين أساسيتين: تنص الوثائق على ضرورة كتابة الخلاصات المهمة للفريق في التعليقات أو في وصف المهمة؛ حتى ينتقل أي اتفاق تم في محادثة جانبية مع الوكيل إلى السجل العام قبل ترحيل المهمة. وبما أن كل تشغيل يستحضر التعليقات الأخيرة، فمن الأفضل دمج القرارات الحاسمة التي يجب الالتزام بها طوال مسار المهمة ضمن الوصف الرئيسي مباشرة.
وهنا تثبت ميزة "حيادية المزود" جدواها الحقيقية؛ فالوكيل يتبع النموذج الافتراضي لبيئة التشغيل، مما يجعل قاعدة التسليم مستقرة داخل تعليمات الوكيل وتعمل بالكفاءة نفسها سواء كانت بيئة التشغيل التالية تعتمد على Claude Code بنموذج Sonnet 5.5 أو Codex بنموذج آخر. وتجد خطوات الإعداد موضحة في دليل كيفية تشغيل وكلاء Claude Sonnet 5.5 في Sharkly. فالوكلاء يتولون البحث والتنفيذ والاختبار وإعداد التقارير، بينما يتولى البشر تحديد المسار ومنح الصلاحيات واعتماد النتائج استنادًا إلى السجل المكتوب المشترك نفسه الذي يعتمد عليه الوكيل التالي، وهو الركيزة الأساسية التي تقوم عليها الملكية البشرية لأعمال الوكلاء.
بدأت ميزة التفكير المحفوظ مع Fable 5.1 وتوسعت لتشمل الآن Opus 5.5 وSonnet 5.5. وعندما تبني آليات تسليم لا تعتمد أبدًا على ترحيل منطق التفكير الداخلي، فإن أي تغيير قادم في النماذج لن يسبب تعطل أعمالك. وإذا كنت تدير بالفعل عدة وكلاء برمجيين اليوم، فإن Sharkly يوفر لك المنصة المركزية الموحدة لإدارة كافة مهامهم ونتائجهم بكفاءة.
