وحدة تحكم واحدة للبرمجة وتطبيقات الذكاء الاصطناعي: ما الذي تغير وكيفية التعامل معها

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

أبرز النقاط

• أصبح وضع مساعد البرمجة ووضع تطبيقات الذكاء الاصطناعي موجودين الآن داخل TokenLab Console؛ حيث تم دمج نقطتي الدخول القديمتين فيه.
• لا تزال الروابط الحالية تعمل، والمحادثات السابقة لا تزال موجودة. لا يوجد شيء يحتاج إلى ترحيل يدوياً.
• يتم بث الردود أثناء قيام النموذج بإنشائها بدلاً من ظهورها في النهاية فقط. تعرض الواجهة توقيت الرمز الأول (first-token timing).
• زمن انتقال الرمز الأول هو إشارة طلب مسجلة (ttft_ms في سجل الطلبات)، وليس مجرد عنصر تجميلي في الواجهة.
• عندما ينخفض الرصيد في منتصف المحادثة، يظهر خيار شحن الرصيد بجوار المحادثة بدلاً من وجوده في صفحة فواتير منفصلة.
• يتبع اختيار النموذج في Console الكتالوج العام؛ تحقق من دليل النماذج لمعرفة الخيارات المتاحة حالياً. تشمل أمثلة الكتالوج الحالية Claude Sonnet 5 و DeepSeek V4 Pro.

ما الذي تغير في TokenLab Console وما الذي لم يتغير

تم طرح التغيير من خلال إدخالين في سجل التغييرات. دمج وحدة التحكم (2026-08-04) نقل نقطتي الدخول القديمتين إلى Console واحدة. إضافة بث محادثة وحدة التحكم (2026-08-18) أضافت ميزة البث إلى الدردشة. وصل التغييران بفارق شهر واحد، لذا فإن الفرق التي فاتها الإدخال الأول تحصل على الثاني مجاناً.

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

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

إذا كان لدى فريقك كتيبات تشغيل (runbooks) تشير إلى نقاط الدخول القديمة، قم بتحديث التسميات عندما تستطيع. لا تزال الروابط القديمة تعمل، لذا لن تتعطل كتيبات التشغيل. Console هي المكان الذي يجب وضع إشارة مرجعية عليه للعمل الجديد. عندما تختار نموذجاً في أي من الوضعين، يتبع الاختيار الكتالوج العام، لذا تحقق من دليل النماذج. تشمل أمثلة الكتالوج الحالية Claude Sonnet 5 و DeepSeek V4 Pro.

البث في TokenLab Console يغير طريقة قراءتك للجلسة

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

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

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

مثال عملي لقراءة إشارة الرمز الأول:

# سجل طلبات Console يعرض `ttft_ms` كعمود اختياري.
# 1. قم بتصفية سجل الطلبات للطلب الذي تتحقق منه.
# 2. اقرأ `ttft_ms`.
# 3. قارن `ttft_ms` بإجمالي زمن انتقال الطلب في نفس الصف.

للحصول على شكل طلب البث الدقيق، استخدم وثائق TokenLab API الحالية. سيكون مثال الطلب المنسوخ الذي يحتوي على حقول مخترعة أقل فائدة من صفحة الوثائق التي تمتلك تلك الأسماء.

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

كيفية التحقق من جلسة بطيئة دون تخمين

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

سجل الطلب محصور في مؤسستك. وهو يتضمن المسار الذي خدم الطلب، وحالة الفواتير، وحالة التخزين المؤقت، وسياق النموذج والمفتاح. هذه الحقول موجودة معاً، لذا يمكنك قراءة الجلسة كحدث واحد بدلاً من تجميع صفحات منفصلة. نفس سجل الطلب متاح في لوحة التحكم، مما يساعد عند مقارنة عرض Console ببيانات مستوى الحساب. يشرح دليل Request Console أين توجد تلك الأدلة.

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

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

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

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

القيود

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

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

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

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

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

هل لا تزال روابط Console القديمة الخاصة بي تعمل؟

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

ما الذي يقيسه توقيت الرمز الأول فعلياً؟

إنه يقيس متى يصل الرمز الأول في رد البث، وتعرضه Console في الواجهة وتسجله كـ ttft_ms، وهو عمود اختياري في سجل الطلبات. إنه لا يقيس إجمالي زمن الانتقال أو الإنتاجية.

أين أقوم بشحن الرصيد عندما تنفد المحادثة من الرصيد؟

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

هل يمكنني مقارنة توقيت الرمز الأول عبر نماذج مختلفة؟

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

أنشئ مفتاح API وقم بتشغيل جلسة واحدة في Console الجديدة على لوحة التحكم.