سلاسل رسائل Claude: متى تقلّل زمن استجابة الوكلاء ومتى لا تفعل

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

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

ما الذي تغيّره سلاسل الرسائل في حلقة وكيل Claude

من دون سلسلة، تُرفَع المحادثة كلها مجددًا في كل دورة، وتتحقق الواجهة منها وتحوّلها إلى رموز بالكامل من جديد، كما توضح الوثائق الرسمية لسلاسل الرسائل.

وفي أحمال عمل الوكلاء يتراكم هذا العبء. فقد يُجري وكيل برمجة مئات الطلبات في جلسة واحدة، ويعيد كل طلب إرسال كل الرسائل ونتائج الأدوات السابقة.

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

أُطلقت سلاسل الرسائل في مرحلة تجريبية عامة على Messages API في 2 نوفمبر 2026، تحت ترويسة النسخة التجريبية message-threads-2026-08-12، وفقًا لـملاحظات إصدار Claude Platform. ولاحظ أن التاريخ المضمّن في اسم الترويسة ليس تاريخ الإطلاق.

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

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

الاشتراك

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

انتهاء الصلاحية

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

التخزين والحذف

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

الإشارة الغائبة

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

ما الذي يصبح أسرع وما الذي يبقى كما هو

يفيد إعلان الإطلاق من Anthropic، كما غطّاه موقع The New Stack، بأنه مع تفعيل سلاسل الرسائل افتراضيًا لمعظم مستخدمي Claude Code، شهدت الطلبات التي تتراوح بين 500k و1M رمز انخفاضًا في الوسيط لزمن الوصول إلى أول رمز بنحو 35%. ويعرّف The New Stack زمن الوصول إلى أول رمز (TTFT) بأنه الوقت الذي يستغرقه Claude ليبدأ توليد الاستجابة.

ويظهر النمط نفسه في حجم الطلب: إذ يفيد AlphaSignal بأن الوسيط لحمولة الطلب في جلسات Claude Code الطويلة انكمش من نحو 800 KB إلى 1.8 KB. وقراءتنا لهذه الفجوة، وهي قراءتنا الخاصة لا شيء منشور، أن كل ما يرسله العميل غير المعتمد على السلاسل تقريبًا في المراحل المتأخرة من جلسة طويلة هو سجل سبق للواجهة أن عالجته.

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

غير أن الحمولات الأصغر لا تعني فاتورة أصغر. فاستهلاك الرموز يبقى كما هو مع السلاسل، لأن مدخلات النموذج لم تتغير. وقد وصف موقع The Next Web الميزة بأنها توفّر الوقت مع إبقاء الإنفاق على حاله، وتقول Anthropic إن الأسعار وحدود المعدل لم تتغير. وأي تقليل في عمل الشبكة أو التسلسل من جانبك أمر يجب قياسه لا افتراضه.

أين لا تنطبق السلاسل: الاستثناءات وحالات عدم التوافق

ليست كل أجزاء المنصة متوافقة مع السلاسل. وتلخّص تغطية Unite.AI أبرز الاستثناءات: لا تدعم السلاسل Message Batches، ولا عدّ الرموز، ولا الضغط عند الطلب، ولا معظم أشكال تحرير السياق، كما أنها غير متاحة للمؤسسات التي فعّلت Inference hooks. وقيود المرحلة التجريبية تتغير، لذا تحقق من كل بند مقابل الوثائق الرسمية لسلاسل الرسائل، فهي القائمة المرجعية المعتمدة.

وإذا كنت تتعامل مع بيانات خاضعة للتنظيم، فالقائمة الرسمية ليست الشيء الوحيد الذي ينبغي التحقق منه. إذ ينصح تعليق أحد المطورين على DEV Community بتجنب السلاسل حين تفصل بين الدورات أكثر من 5 دقائق أو حين تنطبق قواعد ZDR أو HIPAA. وهذه نصيحة ممارس، لا بيان أهلية من Anthropic، لذا تأكد من وضع مؤسستك في الوثائق الرسمية ومع Anthropic مباشرة.

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

أما البند الأخير فيقع خارج منصة Anthropic. إذا كانت حركة مرورك تمر عبر بوابة أو وكيل وسيط (proxy)، فتأكد من أنه يمرّر ترويسة النسخة التجريبية وشكل طلب المتابعة المختصر دون تعديل، وأن منطق إعادة المحاولة والمسار البديل فيه لا يفترض أن كل طلب يحمل السجل كاملًا. ويغطي دليلنا لتشغيل Vercel AI Gateway في بيئة الإنتاج أسئلة التوجيه والتحكم في المزوّدين التي تظهر عادة هنا.

قائمة القرار: هل ينبغي لوكيلك استخدام سلاسل رسائل Claude؟

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

فحص الجاهزية لنهج «الترابط القائم على السجل أولًا»

مرّر كل وكيل مرشّح عبر هذه الأسئلة:

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

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

دليل التنفيذ: اعتماد نهج «الترابط القائم على السجل أولًا»

وفق نهج «الترابط القائم على السجل أولًا»، يملك العميل المحادثة، وتكون سلسلة الخادم مسرّعًا مؤقتًا. ويطرح The Next Web النقطة نفسها من الاتجاه المعاكس: لأن السلاسل تنتهي صلاحيتها بعد خمس دقائق من آخر طلب، يجب على المطورين الاحتفاظ بنسختهم الخاصة من كل محادثة.

الخطوة 1: احتفظ بسجل محلي كامل

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

الخطوة 2: أرسل طلبات متابعة مختصرة

بمجرد وجود سلسلة، أرسل الدورة الجديدة فقط مع معرّف الرسالة السابقة. واترك الشيفرة التي تبني الطلب الكامل في مكانها وأبقها مغطاة بالاختبارات، لأن مسار إعادة الإرسال يعتمد عليها.

الخطوة 3: افترض أن أي طلب متابعة قد يفشل

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

الخطوة 4: تتبّع زمن الخمول بين الدورات

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

الخطوة 5: دقّق التخزين المؤقت للموجّهات

احصِ نقاط توقف cache_control لديك، بما فيها نقطة المستوى الأعلى، وتأكد من أن الطلبات المرتبطة بالسلاسل تبقى ضمن حد 4. فاكتشاف التجاوز في المراجعة أفضل بكثير من اكتشافه في طلب إنتاج مرفوض.

الخطوة 6: قِس على حمل عملك الخاص

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

أخطاء شائعة عند طرح سلاسل الرسائل

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

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

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

تحفظات وأسئلة مفتوحة

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

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