البث في Claude API يسمح بعرض الاستجابة تدريجيًا عبر أحداث SSE عند تفعيل stream بقيمة true، لكنه لا يجعل أول مقطع نصي إجابة مكتملة. يحتاج التطبيق إلى تتبع الرسالة وكتل محتواها وحالة توقفها والأخطاء. هذا دليل للتحضير لعام 2027 وفق الوثائق المتاحة في 27 أكتوبر 2026، لا وصف لواجهة ثابتة مستقبلًا.
الرسالة والكتل لهما نهايتان مختلفتان
يبدأ المسار بحدث message_start يحمل رسالة ذات محتوى فارغ، ثم كتلة أو أكثر تبدأ بـ content_block_start وتتلقى content_block_delta وتغلق بـ content_block_stop. ويحمل index هوية موضع الكتلة حتى تجمع تحديثاتها في مكانها الصحيح.
بعد ذلك تأتي تحديثات message_delta على مستوى الرسالة، وينتهي البث بحدث message_stop. إغلاق كتلة محتوى واحدة لا يساوي انتهاء الرسالة كلها، ولا يصح دمج كل ما يصل في سلسلة نصية دون فحص نوع الحدث.
النص ومدخلات الأدوات
في النص، تضيف text_delta مقاطع text إلى كتلة النص المقابلة. أما كتلة tool_use فتتلقى input_json_delta مع partial_json، وقد تكون القطعة الواحدة سلسلة JSON غير مكتملة.
اجمع المقاطع ثم حللها عند اكتمال الكتلة، أو استخدم مساعدات SDK المناسبة. لا تعتبر القوس الأول أو أول مفتاح كامل تصريحًا بتنفيذ أداة ذات مدخلات لم تكتمل، ولا تخلط مقاطع كتلتين تختلفان في index.
الاكتمال وسبب التوقف
تتيح بعض أدوات SDK تجميع الرسالة النهائية دون التعامل مع كل حدث يدويًا، مثل get_final_message في Python و finalMessage في TypeScript. يفيد ذلك عندما تحتاج كائن Message كاملًا مع استخدام البث لتقليل مخاطر مهلة الاتصال الطويلة.
ومع ذلك افحص stop_reason:قد تكون الرسالة طلب أداة أو استجابة توقفت بحد الإخراج، لا جوابًا نهائيًا ناجحًا. كما أن عدادات usage في message_delta تراكمية؛ جمع كل تحديث كما لو كان كمية جديدة يضاعف الحساب خطأ.
النبضات والخطأ داخل البث
قد تظهر أحداث ping أثناء الاستجابة دون أن تكون نصًا للمستخدم. ويمكن أن يصل حدث error داخل البث، مثل overloaded_error، حتى بعد بدء الاتصال. لا تجعل نجاح بدء HTTP دليلًا على اكتمال التوليد.
صمم المعالج ليتعامل مع أنواع أحداث جديدة بصورة آمنة بدل الانهيار عند أي نوع غير معروف. وعند الانقطاع أو الخطأ، ميز المحتوى الجزئي من الرسالة المكتملة، ولا تعرض آخر جزء وصل بوصفه نتيجة مؤكدة دون فحص الحالة النهائية.
