كلود فابل 5.1 التفكير المحفوظ: إصلاح مشكلة الكتلة مرتبطة بمحادثة مختلفة

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

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

زر

الخطأ

messages.5.content.0: Invalid `signature` in `thinking` block. The block is bound to a different conversation. Remove the block, or set `thinking.block_binding.prefix_mismatch_behavior` to "drop_block". That setting requires the `thinking-binding-controls-2026-08-01` value in the `anthropic-beta` header.

إنه خطأ 400 invalid_request_error، يتم تحديده قبل أي إخراج. إعادة محاولة نفس النص الأساسي تفشل بنفس الطريقة. يشير المسار (messages.5.content.0) إلى كتلة التفكير الأولى التي لم تعد متطابقة، ويمكن أن تنتهي الرسالة بجملة أخرى تحدد الرسالة الأولى التي تغيرت، وهو التشخيص الذي تريده. يقوم نقطة نهاية عد الرموز المميزة بتشغيل نفس التحقق.

فشل مختلف يبدو مشابهاً ولكنه ليس هذا: نفس الجملة الافتتاحية بدون عبارة "مرتبطة بمحادثة مختلفة" تعني أن التوقيع نفسه قد تم العبث به أو أنه غير قابل للفك، ولا ينطبق prefix_mismatch_behavior.

ما يفعله التحقق

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

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

من ينطبق عليه

مفروضة افتراضياً: الحسابات التي تم إنشاؤها في أو بعد 31 أغسطس 2026. يشمل ذلك مؤسسات Claude API، وحسابات Amazon Bedrock، ومشاريع Google Cloud، وموارد Microsoft Foundry.

مسجلة ولكن غير مفروضة: الحسابات التي تم إنشاؤها سابقاً. تلاحظ واجهة برمجة التطبيقات عدم التطابق ولكنها لا تتصرف بناءً عليه إلا عندما يقوم الطلب بتعيين thinking.block_binding.prefix_mismatch_behavior إلى أي قيمة، بما في ذلك "error". تقول Anthropic إن النماذج المستقبلية ستفرضها على الجميع.

غير متأثرة: Claude Code، claude.ai، وكلاء Claude المُدارة، وSDK وكيل Claude، والتي تحافظ على البادئة سليمة لك. Claude Mythos 5.1 لا يجري هذا التحقق على الإطلاق، على الرغم من أن تعديلات السجل لا تزال تعيد تشغيل ذاكرة التخزين المؤقت الخاصة به.

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

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

ما الذي يبطل كل كتلة تفكير لاحقة

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

ما الذي يحافظ عليها صالحة

سجلات الإضافة فقط، بما في ذلك رسائل role: "system" الملحقة والرسائل ذات النطاق الدور التي تم مسحها والتي تُركت في مكانها.
إزالة سلسلة رائدة من كتل التفكير، الأقدم أولاً.
تغيير أي معلمة خارج system و tools و messages: max_tokens، output_config بما في ذلك effort، tool_choice، metadata.
إضافة أو نقل أو إزالة علامات cache_control.
ضغط من جانب الخادم وتحرير السياق، بما في ذلك مسح كتل التفكير. لا تُعتبر هذه تعديلات لأن التحقق يقارن المحادثة كما أرسلتها، وليس النسخة المحررة من الخادم. بعد الضغط، تبدأ البادئة التي تم التحقق منها من كتلة الضغط.

طريقة التجاوز: drop_block

أرسل رأس البيتا thinking-binding-controls-2026-08-01 وقم بتعيين الحقل صراحةً:

response = client.beta.messages.create(
    model="claude-fable-5-1",
    max_tokens=16000,
    thinking={"type": "adaptive", "block_binding": {"prefix_mismatch_behavior": "drop_block"}},
    betas=["thinking-binding-controls-2026-08-01"],
    messages=history,
)
for t in response.input_transformations or []:
    print(t.type, t.path, t.reason)

مع "drop_block"، تقوم واجهة برمجة التطبيقات بحذف الكتلة غير المتطابقة الأولى وكل كتلة تفكير بعدها، وتتابع الطلب، وتبلغ عن كل حذف في مصفوفة input_transformations على المستوى الأعلى:

"input_transformations": [
  {"type": "thinking_dropped", "path": "messages.1.content.0", "reason": "prefix_binding_mismatch"}
]

ثلاثة أشياء يجب معرفتها عن هذا الحقل. ينطبق هذا على هذا الطلب فقط، لذا استمر في إرساله لبقية الجلسة. تختلف الإعدادات الافتراضية حسب الواجهة: بدون الرأس، يتعطل الحساب المفروض؛ إرسال الرأس وحده يحول إلى الإعداد الافتراضي الخاص بالبيتا، وهو drop_block؛ لذا قم بتعيينه صراحةً ولا تعتمد أبداً على أي من الإعدادات الافتراضية. وإرسال block_binding بدون الرأس يؤدي إلى خطأ 400 ينتهي بـ block_binding: Extra inputs are not permitted.

يميز حقل reason حالتين. prefix_binding_mismatch يعني أن سجل محادثتك قد تغير. model_binding_mismatch يعني أن المحادثة تحولت إلى نماذج أخرى (جهاز توجيه، إعادة محاولة، تراجع بسبب رفض) ولم يتمكن الهدف من قراءة كتلة Fable 5.1. الحالة الثانية ليست خطأً في تعليماتك البرمجية. مع الرأس، يحمل كل رد المصفوفة، فارغة عندما لا يتم حذف أي شيء.

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

الاستعادة بدون بيتا

على منصة بدون عناصر التحكم (لم تقدم Microsoft Foundry هذه العناصر عند الإطلاق؛ وكانت Bedrock و Google Cloud تضيفها لكل نموذج)، قم بإزالة كل كتلة thinking و redacted_thinking من السجل، واحتفظ بكتل text و tool_use لكل دور، ثم أعد المحاولة مرة واحدة. يجيب النموذج على هذا الدور بدون التفكير الذي حملته تلك الكتل. هذه استعادة لمرة واحدة، وليست نمطاً.

التدقيق ثلاثي الخطوات

قم بتشغيل هذا قبل تحويل حركة المرور، وليس بعدها.

التقط نصوص الطلبات الدقيقة التي يرسلها نظامك على مدار بضعة أدوار عادية، بما في ذلك عملية ضغط أو تغيير أداة إذا كان منتجك يتضمنها. لكل زوج من الطلبات المتتالية، قارن موجه system، ومصفوفة tools، والبادئة المشتركة لـ messages. يجب أن تكون متطابقة بالبايت حتى الأدوار الملحقة حديثاً.
قم بتشغيل جلسة عادية متعددة الأدوار مقابل claude-fable-5-1 مع رأس البيتا و prefix_mismatch_behavior: "drop_block"، وقم بتسجيل input_transformations في كل استجابة. تعني المصفوفة الفارغة في كل دور أن السجل سليم. يعني إدخال prefix_binding_mismatch أن شيئاً ما قبل الكتلة في path قد تغير. يعمل هذا من أي حساب، لأن تعيين الحقل يضم الطلب إلى التنفيذ. في CI، قم بتعيين "error" بدلاً من ذلك بحيث يفشل أي تعديل التشغيل.
اختر إعداد إنتاجي وقم بتعيينه صراحةً تحت الرأس: "error" إذا كان عدم التطابق يعني فقط خطأً، أو "drop_block" للتدهور بدلاً من الفشل. راقب أخطاء 400 أو إدخالات input_transformations في كلتا الحالتين. لا تترك الحقل غير معين في حساب أقدم، لأنه في هذه الحالة يسجل التحقق من جانب الخادم فقط ولن تحصل على أي شيء للمراقبة.

في Apidog، الخطوة 2 هي اختبار بطلبين: أرسل دوراً، عدّل موجه النظام، أرسل الدور التالي مع تعيين الرأس، وتحقق من input_transformations. احتفظ به في المجموعة بحيث يتم إعادة تشغيله مع كل تغيير في نظام الوكيل. قم بتنزيل Apidog لإنشائه.

جعل نظام الوكيل للإضافة فقط

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

ما كنت تفعله	افعل هذا بدلاً من ذلك
تعديل موجه النظام في منتصف الجلسة (تاريخ جديد، وضع جديد)	جمّد `system` عند بدء الجلسة. ألحق `{"role": "system", "content": "The current date is 2026-09-14."}` في النقطة التي يصبح فيها التغيير صحيحاً (رسائل نظام منتصف المحادثة). لا يوجد رأس بيتا؛ فهو يحصل على صلاحية موجه النظام ويصبح جزءاً من البادئة التي ترتبط بها الكتل اللاحقة.
تعديل مصفوفة `tools` في منتصف الجلسة	أعلن عن المجموعة الكاملة عند بدء الجلسة (`defer_loading: true` للعناصر التي تبدأ مخفية). أرسل كتل `tool_addition` و `tool_removal` في رسالة `role: "system"` (بيتا `mid-conversation-tool-changes-2026-07-01`).
حقن تذكير لكل دور وحذفه في الطلب التالي	أرسله كرسالة نظام ذات نطاق دور: `{"role": "system", "clear_at": "next_user_message", "content": "..."}` (بيتا `mid-conversation-system-clear-at-2026-08-21`) بعد رسالة نتيجة الأداة، واترك كل نسخة سابقة في مكانها. النسخ المحذوفة لا تعرض شيئاً ولا تكلف شيئاً. بدون البيتا، ضع التذكير في كتلة نصية بعد كتل `tool_result` في نفس رسالة المستخدم، مع الاحتفاظ بالنسخ السابقة.
حذف نتائج الأدوات القديمة من جانب العميل	تحرير السياق من جانب الخادم مع مسح نتائج الأدوات.
الضغط من جانب العميل	فضل الضغط من جانب الخادم (بيتا `compact-2026-01-12`؛ يأخذ معلمه `instructions` موجه التلخيص الخاص بك). إذا بقيت على جانب العميل، استخدم ضغطاً بسيطاً: استبدل السجل بأكمله برسالة تلخيص واحدة بالإضافة إلى دور المستخدم الجديد ولا تعيد تشغيل أي شيء آخر.
الإشارة إلى صورة أو مستند بواسطة URL عبر الأدوار	حمّل مرة واحدة إلى Files API وأرسل `file_id`، أو أرسل بصيغة base64.

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

اعتبار آخر للتكلفة: نظراً لأن قراءات ذاكرة التخزين المؤقت أصبحت الآن 0.25 دولار لكل مليون، فإن الضغط المبكر لتوفير المال قد لا يكون المقايضة الصحيحة بعد الآن في Fable 5.1. تقترح Anthropic التجريب بنقاط ضغط لاحقة.

لماذا هذه أيضاً قصة ذاكرة التخزين المؤقت

كل شيء في الجدول أعلاه هو أيضاً قائمة الأشياء التي تعيد تشغيل ذاكرة التخزين المؤقت للمطالبة. جعل Fable 5.1 نجاحات ذاكرة التخزين المؤقت أرخص بأربع مرات من Fable 5 وجعل الإخفاقات أكثر إيلاماً بشكل متناسب، لذا فإن نظام الوكيل الذي يعتمد على الإضافة فقط يحصل على فائدتين: التفكير يبقى، وكل دور يقرأ البادئة بسعر 0.25 دولار بدلاً من إعادة كتابتها بسعر 12.50 دولاراً. يحتوي تفصيل الأسعار على الأرقام؛ يعرض شرح واجهة برمجة التطبيقات أشكال الطلبات ذات النطاق الدور والمجهود لكل رسالة في سياقها، ويغطي دليل المطالبة التعليمات لكل دور التي تستحق الإرسال بهذه الطريقة، ويشرح دليل Claude Code لماذا لا يرى مستخدمو Claude Code هذا الخطأ أبداً.

الأسئلة الشائعة

ماذا تعني عبارة "الكتلة مرتبطة بمحادثة مختلفة"؟ تم إعادة تشغيل كتلة تفكير لـ Claude Fable 5.1 بعد تغيير شيء قبلها: موجه النظام، أو مصفوفة الأدوات، أو رسالة سابقة. ترفض واجهة برمجة التطبيقات الطلب بخطأ 400 على الحسابات المفروضة.
ما هي الحسابات التي تفرض التحقق من سجل Fable 5.1؟ الحسابات التي تم إنشاؤها في أو بعد 31 أغسطس 2026، على جميع المنصات. تفرضها الحسابات الأقدم فقط عندما يقوم الطلب بتعيين thinking.block_binding.prefix_mismatch_behavior. تخطط Anthropic لفرضها على الجميع في النماذج المستقبلية.
كيف أجعل الخطأ يختفي بسرعة؟ أرسل رأس البيتا thinking-binding-controls-2026-08-01 مع prefix_mismatch_behavior: "drop_block". تقوم واجهة برمجة التطبيقات بحذف الكتل المتأثرة وتستمر. ثم قم بإصلاح تعديل السجل، لأن حذف الكتل في كل دور يكلف التفكير ويعيد تشغيل ذاكرة التخزين المؤقت الخاصة بك.
هل يؤدي تغيير effort أو max_tokens إلى إبطال كتل التفكير؟ لا. يمكن تغيير أي معلمة خارج system و tools و messages بحرية، وكذلك علامات cache_control.
هل يؤدي الضغط من جانب الخادم إلى كسر التحقق؟ لا. يحدث الضغط وتحرير السياق بعد التحقق، والذي يقارن المحادثة كما أرسلتها. الضغط من جانب العميل الذي يحافظ على الأدوار الأخيرة حرفياً يكسره.
هل لدى Claude Mythos 5.1 نفس التحقق؟ لا. لا يقوم Mythos 5.1 بإجراء التحقق من المحادثة، على الرغم من أنه لا يزال يربط كتل التفكير بالنموذج المنتج ولا تزال تعديلات السجل تعيد تشغيل ذاكرة التخزين المؤقت الخاصة به.