أضافت Anthropic حقل `line` إلى Models API في 1 أكتوبر 2026. تستطيع `GET /v1/models` و`GET /v1/models/{model_id}` الآن تحديد العائلة التي ينتمي إليها النموذج—مثل `opus`—من دون أن يحلل التطبيق اسم النموذج. يفيد ذلك في Model Pickers وعرض المخزون وتكوين مرشحي التوجيه، لكنه تصنيف فقط. لا يثبت أن النموذج يدعم أداة، أو يناسب سياسة مخاطر، أو يستحق Production Traffic. استخدم `line` للتجميع، واستعمل حقول القدرات وحدود Tokens الصريحة مع سياسة النماذج المعتمدة لاتخاذ القرار.
تعطي ملاحظات الإصدار الرسمية تاريخ الحدث في 1 أكتوبر. وتذكر مرجعية List Models أن `line` قد تكون null، وتحذر من استنتاج العائلة من `id`، وتوضح أن قيمًا جديدة قد تضاف. المعمارية أدناه توصية هندسية مشتقة من هذه العقود الموثقة، وليست وصفًا لنظام Anthropic الداخلي.
ما الذي تغيّر وما الذي لم يتغيّر؟
قبل هذا الحقل قد يقسم تطبيق اسمًا مثل `claude-opus-...` لتجميع النماذج في عائلات. يحول ذلك اصطلاح التسمية بصمت إلى عقد API. وقد تكسر عائلة جديدة أوصيغة Alias أوIdentifier خاص بمزود ما الفلاتر والتحليلات والصلاحيات، مع أن النموذج نفسه صالح.
يجعل الحقل الجديد الانتماء إلى العائلة مقروءًا آليًا. تعرف مرجعية API حاليًا قيمًا منها `haiku` و`sonnet` و`opus` و`fable` و`mythos`، مع الاحتفاظ بحق إضافة قيم أخرى. ويعيد النموذج الذي لا ينتمي إلى Line قيمة null. لذلك يتعامل Client الصحيح مع القيمة كنص مفتوح أوnull، لا كـEnum مغلقة داخل Business Logic.
لا تحدد `line` أحدث Release، ولا ما إذا كانت Alias تتحرك، ولا موعد Retirement، ولا الميزات المفعلة. يعرض Response نفسه حقولًا مستقلة مثل `id` و`display_name` و`created_at` و`max_input_tokens` و`max_tokens` وكائن `capabilities`. حافظ على استقلال هذه المعاني.
العائلة والقدرات والاعتماد تجيب عن أسئلة مختلفة
تجيب عائلة النموذج: أي Product Line تجمع هذه الإصدارات؟ وتجيب Capability Metadata: هل يقبل النموذج PDF أويشغّل Code Execution أويُخرج Structured Output أويدعم وضع Thinking؟ وتجيب حدود Tokens: هل يتسع الطلب؟ أما سياسة تطبيقك فتجيب: هل جرى تقييم هذا النموذج المحدد واعتماده لهذا العميل والمنطقة ونوع المهمة ومستوى المخاطر؟
لا تستبدل بعدًا بآخر. قد يختلف نموذجان ضمن Line واحدة في Context Limits أوإصدارات الأدوات أوLatency أوالسعر أوالتوفر أوسلوكيات كاسرة. وقد يحقق نموذجان من Line مختلفة متطلب القدرة نفسه. يقطع Router الآمن كل القيود ثم يختار من Allowlist صريحة.
تعامل مع Aliases وSnapshots بقرار واعٍ. Alias مناسبة عندما تريد مسار ترقية يديره المزود؛ وSnapshot محددة أنسب عندما تحتاج Reproducibility وRollback. قد يخبرك Discovery بما هو موجود، لكن Policy الإنتاج تقرر هل يدخل النموذج الظاهر حديثًا Shadow Testing أوCanary أولا يأخذ أي Traffic.
ابنِ كتالوجًا موحدًا بدل الاكتشاف داخل كل طلب
اجلب Models API في Background Control-plane Job، واتبع Pagination حتى الاكتمال، وتحقق من Response، ثم اكتب كتالوجًا موحدًا. احتفظ بسجل المزود ووقت رصده. ارفض السجلات المشوهة فقط، وضع الحقول أوقيم Line غير المعروفة في Quarantine للمراجعة بدل إسقاط Refresh كلها. احتفظ بآخر كتالوج سليم عند فشل التحديث.
{
"provider": "anthropic",
"model_id": "approved-model-id",
"line": "opus",
"capabilities": {"structured_outputs": true},
"max_input_tokens": 1000000,
"observed_at": "2026-10-06T04:00:00Z",
"policy_state": "evaluated"
}هذه Application Schema وليست Response حرفية من Anthropic. تفصل عمدًا Metadata المرصودة عن حالة السياسة الداخلية. لا تستبدل آخر Record معروف لأن Response مؤقتًا أسقط حقلًا؛ قارن المراجعات، ونبّه إلى التغييرات المؤثرة، واطلب اعتمادًا قبل أن يغير أي فرق التوجيه.
ضع Cache للاكتشاف مع TTL محدودة وJitter. يتغير مخزون النماذج أبطأ بكثير من Inference Traffic، لذا فإن استدعاء `/v1/models` في كل طلب مستخدم يضيف Latency واعتماد فشل جديدًا من دون رفع الأمان. حدّث دوريًا واسمح Refresh يدويًا بعد Launch أوDeprecation موثقة.
وجّه عبر بوابات صريحة
ابدأ بمتطلبات المهمة: أنواع المدخلات، عقد المخرجات، Context Budget، فئات الأدوات المطلوبة، سياسة البيانات، هدف Latency، وأقصى كلفة مقبولة. رشح الكتالوج عبر القدرات والحدود الصريحة. طبق سياسة العميل والمنطقة والامتثال. ثم احصر المرشحين في نماذج اجتازت Evaluation Bundle الحالية. يمكن للعائلة توجيه الترتيب—مثل تفضيل نموذج معتمد من Line معينة لفئة عمل—لكنها لا تتجاوز البوابات.
حوّل المرشح إلى ID محددة قبل Inference Call، وسجّلها مع Catalog Revision وRoute-policy Version وسبب Fallback في Trace. يجعل ذلك الحادث قابلًا للتفسير حتى لو أشارت Alias لاحقًا إلى نموذج آخر. لا تسجل Prompts حساسة فقط لتحصل على Observability؛ تكفي غالبًا فئة المهمة والأعداد وقرار السياسة وModel ID والنتيجة المتحققة.
عندما لا يحقق أي نموذج البوابات، استخدم Fail Closed في الإجراءات عالية المخاطر أوانقل العمل إلى مسار بشري موثق. وفي Drafting منخفض المخاطر لا يُسمح بـFallback إلا إذا اجتازت فحوص القدرة والسياسة نفسها مستقلًا. قاعدة `same line` ليست Fallback كافية.
تعامل بأمان مع null والقيم المستقبلية
قيمة null صحيحة. أبقِ النموذج ظاهرًا في مجموعة عرض `unclassified`، لكن لا تخترع عائلة من ID. والقيمة غير المعروفة وغير الفارغة صحيحة أيضًا بموجب تحذير Forward Compatibility. اعرض الاسم المقروء من المزود، وخزن Raw Line كما هي، ودع السياسة تقرر بقاء النموذج غير متاح حتى مراجعته.
تجنب Exhaustive Switches التي ترمي Error عند أول قيمة جديدة. يمكن لألوان UI وترتيبها استخدام Default Style. وتحافظ Metrics على قيمة موحدة منخفضة Cardinality بينما تبقي Raw Value في Catalog مضبوط. لا تجعل Authorization تعتمد على اسم عائلة لطيف فقط.
تستحق تغييرات Schema اختبارات عقد. خزّن Fixtures لقيمة null، وقيم معروفة ومجهولة، وحقول اختيارية غائبة، وPagination، وIDs مكررة، وCapability لا يعرفها Client الحالي. تحقق من Idempotency في Refresh ومن بقاء الكتالوج السابق عند أعطال الشبكة والمصادقة والتحقق.
أفضل الاستخدامات والأنماط المضادة
يفيد الحقل أكثر في تجميع Model Picker، وتلخيص المخزون، وتعريف Evaluation Cohorts واسعة، والتعبير عن Preference بعد تحقيق المتطلبات الصلبة. كما يزيل Regular Expressions الهشة من Dashboards وأدوات الإعداد. تستطيع الفرق التي تشغل إصدارات متعددة مقارنة النتائج حسب العائلة من دون تطبيع IDs بنفسها.
لا تستخدمه لاستنتاج السعر أوالذكاء أوترتيب الإصدارات أومستوى الأمان أودعم الأدوات أوRetirement. لا تعتمد تلقائيًا كل نموذج يظهر تحت Line معتمدة. لا تعِد كتابة نموذج إنتاج مثبت بصمت عندما يرى Discovery نموذجًا شقيقًا أحدث. ولا تجعل Request Path تنتظر Live Catalog Refresh.
قد يكون Search أوStatic Configuration أفضل من Dynamic Discovery عندما يدعم التطبيق نموذجًا واحدًا مثبتًا بعناية ولا يتغير إلا عبر Releases. ويستحق Database-backed Catalog تعقيده عندما تحتاج منتجات أوعملاء متعددون Approved Sets مختلفة أوModel Pickers أوEvaluations مجدولة أوعمل Deprecation منسق.
الإطلاق والتقييم
ابدأ باستبدال ID Parsing داخل Shadow Catalog وقارن تجميعه بالتنفيذ القديم. الاختلافات دليل يجب فحصه، وليست قيمًا تُصحح تلقائيًا. ثم أضف Capability Filters وPolicy State مع إبقاء توجيه الإنتاج دون تغيير. شغّل Contract Tests على API Fixtures محفوظة وعلى Live Refresh مضبوط.
قيّم كل مرشح على مهام تشبه الإنتاج. قِس Accepted Outcome Rate والأخطاء الحرجة وLatency Percentiles وTokens وأخطاء الأدوات ومعدل Fallback وكلفة النتيجة المقبولة. نفّذ Canary لسياسة التوجيه—لا للنموذج وحده—خلف Cohort ثابت للعميل أوالطلب. حدد حدود Rollback مسبقًا واحتفظ بمراجعة الكتالوج السابقة وRoute Bundle قابلة للنشر.
نبّه عندما يختفي نموذج موجّه، أوتتغير Capability، أوينخفض Token Limit، أوتتغير Line، أوتظهر Line مجهولة، أويقترب نموذج من Retirement Date موثقة. وظيفة Discovery هي كشف التغييرات مبكرًا، لا تحويل Metadata المزود مباشرة إلى Release إنتاجي.
قرار الإنتاج
اعتمد `line` في كل موضع يحلل Anthropic Model IDs بهدف التجميع. حافظ على null والقيم المستقبلية، وخزّن كتالوجًا جرى التحقق منه، وافصل Discovery عن Request Path. استخدم Capabilities وحدود Tokens للتوافق التقني، واستعمل Allowlist مقيمة لاعتماد المنتج والمخاطر.
التحديث صغير، لكن درس التصميم مستمر: Identifier يعرّف، وTaxonomy تجمع، وCapabilities تصف، وPolicy تعتمد. فصل هذه العقود الأربعة يجعل Model Routing أكثر أمانًا مع إضافة المزودين عائلات وإصدارات وميزات. اربط الكتالوج الأوسع مع دليل ترحيل Claude Sonnet 5.5 وعقد تقييم AI القابل للنقل.
المراجع الرسمية
تدعم هذه المراجع سلوك الأدوات المذكورة. الأمثلة وقرارات التصميم توضيحية، ويجب تكييفها مع متطلبات المشروع وإصداراته.
إعداد: Noor Yasser
تعمل على تحدٍ تقني مشابه؟
أساعد الفرق على تحويل القرار المعماري إلى نطاق واضح وتنفيذ يمكن تشغيله ومراجعته بثقة.
