مصادقة Claude API: المفتاح وBedrock وVertex وFoundry

مسارات مصادقة Claude API الأربعة

تعتمد مصادقة Claude API على قرار واحد: ما بيانات الاعتماد التي يضعها عميلك في الطلب. هناك أربع إجابات، وليست تنويعات لآلية واحدة. يرسل Anthropic API المباشر مفتاحاً ثابتاً في ترويسة x-api-key. يوقّع Amazon Bedrock كل طلب باستخدام بيانات اعتماد AWS، ولا يوجد أي مفتاح Anthropic في هذا الإعداد. ترسل Google Cloud رمز وصول قصير الأجل من Google. ويستخدم Microsoft Foundry مفتاحاً صادراً من Azure أو رمز Microsoft Entra.

هذا الدليل مخصص لربط SDK (حزمة تطوير البرامج) بخدمة تعمل على خادم Linux. إذا كنت تضبط أداة سطر الأوامر Claude Code بدلاً من ذلك، فالمتغيرات وتسلسل العمل مختلفان: راجع توجيه Claude Code إلى Bedrock أو Vertex. إذا لم تكن الخدمة موجودة بعد، فأنشئها أولاً باتباع إنشاء أول تطبيق Claude API على VPS، ثم عُد إلى هنا لإعداد بيانات الاعتماد.

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

المسار 1: مفتاح Anthropic API

هذا هو المسار المباشر، وهو المسار الوحيد الذي تُصدر فيه Anthropic السر. تُرسل الطلبات إلى نقطة Messages النهائية على مضيف API الخاص بـAnthropic، ويحمل كل طلب ثلاثة رؤوس.

curl https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"model": "MODEL_ID", "max_tokens": 64, "messages": [{"role": "user", "content": "Hello"}]}'

استبدل MODEL_ID بمعرّف حالي من نظرة عامة على النماذج لدى Anthropic. تكون الاستجابة السليمة بتنسيق JSON، وتحتوي على مصفوفة content وكائن usage. يعيد المفتاح الخاطئ أو المنتهي الصلاحية HTTP 401 مع authentication_error. ويؤدي غياب الرأس anthropic-version إلى فشل منفصل، لأن هذا الرأس مطلوب في كل طلب؛ وتضبطه SDKs نيابةً عنك.

يُعد إنشاء العميل الأقصر بين المسارات الأربعة، لأنه لا يوجد شيء تحتاج إلى إنشائه. يقرأ كل SDK رسمي ANTHROPIC_API_KEY من البيئة تلقائياً.

import os
from anthropic import Anthropic

client = Anthropic()  # reads ANTHROPIC_API_KEY from the environment

message = client.messages.create(
    model=os.environ["CLAUDE_MODEL"],
    max_tokens=64,
    messages=[{"role": "user", "content": "Hello"}],
)
print(message.usage)

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

تُنشأ المفاتيح في Console، حيث تختار مدة الصلاحية وقت الإنشاء: خيارات مسبقة مدتها 3 ساعات أو 1 يوم أو 7 أيام أو 30 يوماً، أو مدة مخصصة، أو Never. تُحدَّد مدة الصلاحية وقت الإنشاء ولا يمكن تغييرها لاحقاً. ترسل Anthropic رسالة بريد إلكتروني إلى منشئ المفتاح قبل انتهاء صلاحية المفتاح طويل الأجل، لكن المفتاح ذي العمر القصير ينتهي من دون إرسال أي رسالة تحذير. يعيد المفتاح المنتهي الصلاحية 401 ولا يمكن إعادة تفعيله، لذلك يكون الحل دائماً إنشاء مفتاح جديد.

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

يوجد خيار إضافي هنا، لأنه يلغي السر الثابت بالكامل. تتيح Workload Identity Federation لحِمل العمل استبدال رمز OpenID Connect (OIDC) من موفّر هوية تثق به مسبقاً برمز Anthropic قصير الأجل في POST /v1/oauth/token، ويجدّد SDK ذلك الرمز قبل انتهاء صلاحيته. ولا يتم إنشاء سلسلة sk-ant-api... أو نسخها في أي مكان. يناسب ذلك Kubernetes وGitHub Actions والأجهزة الافتراضية السحابية، التي تحمل هوية منصة مسبقاً. أما VPS عادي فعادةً فلا يملك جهة إصدار كهذه، لذلك يكون مفتاح API في ملف هو الحل الصريح على ذلك الخادم، وهذا ما يتبناه باقي هذا الدليل.

المسار 2: بيانات اعتماد AWS على Amazon Bedrock

على Bedrock لا تحتاج إلى أي مفتاح Anthropic. يوقّع SDK كل طلب HTTP باستخدام AWS Signature Version 4 (SigV4) عبر بيانات اعتماد AWS العادية، وتحدد AWS ما إذا كان بإمكان تلك الهوية استدعاء النموذج.

pip install -U "anthropic[bedrock]"
aws sts get-caller-identity

يطبع aws sts get-caller-identity رقم الحساب وARN (Amazon Resource Name) للهوية التي تُحل إليها بيانات اعتمادك. شغّله قبل أي شيء آخر. إذا فشل، فسيفشل استدعاء Claude أيضاً، لأن SDK يتبع السلسلة نفسها: معاملات المُنشئ أولاً، ثم متغيرات البيئة AWS_ACCESS_KEY_ID وAWS_SECRET_ACCESS_KEY وAWS_SESSION_TOKEN وAWS_REGION، ثم ملف إعداد AWS وبقية السلسلة القياسية، مثل SSO والأدوار المفترضة ودور مهمة ECS وخدمة بيانات تعريف المثيل.

ما يتغير في إنشاء العميل هو الفئة ومعامل واحد.

from anthropic import AnthropicBedrock

client = AnthropicBedrock(aws_region="us-east-1")

لا يعود الإقليم مجرد قيمة شكلية هنا. تكون نقاط نهاية Bedrock خاصة بكل إقليم، ويُمنح الوصول إلى النموذج لكل إقليم في وحدة تحكم AWS، كما أن الإقليم جزء من توقيع SigV4؛ لذلك يرفض إقليم آخر توقيعاً حُسب لإقليم مختلف. عيّن AWS_REGION صراحةً في بيئة الخدمة. توثّق Anthropic أن عميل AnthropicBedrock يقرأ AWS_REGION ويستخدم us-east-1 كقيمة بديلة عند عدم تعيينه، وأنه لا يقرأ ~/.aws/config لتحديد الإقليم. لذلك يمكن لـAWS CLI عرض نماذج Claude بنجاح على الخادم نفسه الذي تفشل فيه عملية Python: فقد قرأ CLI ملف الإعداد، بينما لم يقرأه العميل.

على مثيل EC2، تربط دور IAM (إدارة الهوية والوصول) بالمثيل، ولا تُخزَّن أي أسرار على القرص، لأن خدمة بيانات تعريف المثيل تمنح SDK بيانات اعتماد مؤقتة. أما VPS خارج AWS فلا يملك دور مثيل ولا خدمة بيانات تعريف. عندها تختار بين زوج مفاتيح وصول طويل الأمد لمستخدم IAM مخزّن على الخادم، وهو من الفئة نفسها من الأسرار التي ينتمي إليها مفتاح Anthropic، وبين federation: صادق عبر موفر هويتك، واستدعِ AWS STS (خدمة الرموز الأمنية)، واستخدم بيانات الاعتماد المؤقتة التي يعيدها. يقبل Bedrock أيضاً bearer token عبر AWS_BEARER_TOKEN_BEDROCK، مع حد أقصى موثق قدره 12 ساعة، وتصفه AWS بأنه الخيار الأقل تفضيلاً.

تُحمَّل التكلفة على حساب AWS الخاص بك بدلاً من Anthropic، وهذا هو السبب المعتاد لاختيار هذا المسار. تفرض نقاط النهاية الإقليمية تكلفة إضافية قدرها 10% مقارنةً بنقطة النهاية العالمية، وفقاً للتوثيق الصادر في August 2026. هناك خطأ من Bedrock يستحق التعرّف إليه لأنه يبدو كأنه مشكلة صلاحيات، لكنه ليس كذلك: Invocation of model ID ... with on-demand throughput isn't supported. Retry your request with the ID or ARN of an inference profile that contains this model. هذا خطأ في توجيه النموذج، ولن يعالجه تغيير بيانات الاعتماد.

المسار 3: بيانات اعتماد Google على Vertex AI

تستخدم Google Cloud بيانات اعتماد التطبيق الافتراضية (ADC)، وهي ترتيب بحث ثابت تتبعه مكتبات مصادقة Google للعثور على بيانات اعتماد من دون أن تحددها بنفسك. تتحقق ADC من GOOGLE_APPLICATION_CREDENTIALS أولاً، ثم من الملف الذي ينشئه gcloud auth application-default login، ثم من حساب الخدمة المرتبط عبر خادم البيانات الوصفية.

pip install -U "anthropic[vertex]"
gcloud auth application-default login

على محطة العمل، ينشئ تسجيل الدخول $HOME/.config/gcloud/application_default_credentials.json، وتكون قد انتهيت. أما على الخادم، فهذه الأداة غير مناسبة، لأن بيانات الاعتماد التي تخزنها تعود إلى مستخدم بشري وتنتهي صلاحيتها بانتهاء حساب ذلك المستخدم. لا يوجد خادم بيانات وصفية خارج Google Cloud أيضاً، لذلك تنتقل ADC إلى GOOGLE_APPLICATION_CREDENTIALS الذي يشير إلى ملف مفتاح حساب خدمة. ملف JSON هذا سر طويل الأمد، ويحتاج إلى المعالجة الموضحة تحديداً لاحقاً في هذا الدليل. داخل Google Cloud، اربط حساب خدمة بالآلة الافتراضية، ولن يكون هناك ملف يحتاج إلى الحماية.

from anthropic import AnthropicVertex

client = AnthropicVertex(project_id="my-project", region="global")

يتغير أمران عند الانتقال من SDK إلى HTTP الخام. ينتقل معرّف النموذج من نص الطلب إلى مسار URL، وينتقل anthropic_version من الترويسة إلى نص الطلب، حيث يجب أن تكون قيمته vertex-2023-10-16. بيانات الاعتماد هي رمز وصول عادي من Google.

curl https://aiplatform.googleapis.com/v1/projects/${PROJECT_ID}/locations/global/publishers/anthropic/models/${MODEL_ID}:rawPredict \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  -H "Content-Type: application/json" \
  -d '{"anthropic_version": "vertex-2023-10-16", "max_tokens": 64, "messages": [{"role": "user", "content": "Hello"}]}'

المنطقة وسيط أساسي في الطلب. يوجّه global الطلبات ديناميكياً وفق التوافر، بينما يشير us وeu إلى معرّفات متعددة المناطق، ويثبّت اسم مثل us-east5 الطلبات في منطقة واحدة. تكلّف نقاط النهاية متعددة المناطق والإقليمية 10% أكثر من النقاط العامة، وفقاً للوثائق في August 2026. تتم الفوترة من خلال مشروع Google Cloud، لذلك تكون الحصة والفواتير تابعة لـGoogle.

المسار 4: Microsoft Foundry هو المسار الخاص بـAzure

إذا كنت تبحث عن Claude على Azure، فهذا هو القسم الذي تحتاج إليه، ويوجد مسار مدعوم فعلاً. يعمل Claude في Microsoft Foundry (المعروف سابقاً باسم Azure AI Foundry)، وتتم محاسبته عبر Azure Marketplace بوحدات استهلاك Claude. تنشئ مورداً في Foundry، وتنشر نموذج Claude داخله، ثم تستدعي نقطة نهاية مستضافة على Azure في https://{resource}.services.ai.azure.com/anthropic/v1/*.

تعمل بيانات اعتماد اثنتين. الأولى مفتاح صادر عن Azure من علامة التبويب Details الخاصة بالنشر في بوابة Foundry، وترسله في رأس api-key أو x-api-key. والثانية رمز Microsoft Entra، وهو الخيار الأفضل على الخادم لأن Azure role-based access control يتولى عندئذٍ تحديد من يمكنه استدعاء نقطة النهاية.

ACCESS_TOKEN=$(az account get-access-token --resource https://ai.azure.com --query accessToken -o tsv)

curl https://${RESOURCE}.services.ai.azure.com/anthropic/v1/messages \
  -H "content-type: application/json" \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  -H "anthropic-version: 2023-06-01" \
  -d '{"model": "DEPLOYMENT_NAME", "max_tokens": 64, "messages": [{"role": "user", "content": "Hello"}]}'

يحمل الحقل model اسم النشر، وليس معرّف النموذج. يتطابق الاسمان افتراضياً، لكنهما لا يعودان متطابقين فور تسمية النشر يدوياً. وهذا هو السبب المعتاد لخطأ Deployment not found في طلب صحيح من النواحي الأخرى. يقرأ Python وTypeScript SDKs القيمتين ANTHROPIC_FOUNDRY_API_KEY وANTHROPIC_FOUNDRY_RESOURCE من البيئة. لا يتوفر دعم Foundry في كل SDK: ووفقاً للتوثيق في August 2026، يشمل الدعم C# وJava وPHP وPython وTypeScript، بينما يحتاج Go وRuby SDKs إلى العميل العام مع توجيهه إلى عنوان Foundry الأساسي.

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

ما مدة صلاحية بيانات الاعتماد على خادمك؟

[
  {
    "label": "Anthropic key, 30-day preset",
    "max_lifetime_hours": 720
  },
  {
    "label": "Anthropic key, 7-day preset",
    "max_lifetime_hours": 168
  },
  {
    "label": "AWS STS assumed role",
    "max_lifetime_hours": 12
  },
  {
    "label": "Bedrock bearer token",
    "max_lifetime_hours": 12
  },
  {
    "label": "Entra ID access token",
    "max_lifetime_hours": 1
  },
  {
    "label": "Federated Anthropic token",
    "max_lifetime_hours": 1
  }
]

هذه حدود قصوى وقيم افتراضية ينشرها كل موفّر، وقد قُرئت في August 2026، وليست قياسات فعلية. وتهم لسبب واحد: فهي توضح لك المدة التي تظل فيها بيانات الاعتماد المسرّبة صالحة للعمل بينما لا تزال تكتشف تسرّبها. تدوم الرموز قصيرة الأجل في أسفل المخطط مدة 1 ساعة لكل منها، ويجدّدها SDK، لذلك لا تفرض قِصر مدة صلاحيتها أي تكلفة تشغيلية عليك. تستمر صلاحية الدور المفترض مدة 12 ساعة. أما المفتاح الذي أُنشئ باستخدام الإعداد المسبق لمدة 30 يوماً، فتظل صلاحيته 720 ساعة، وهو بيانات الاعتماد التي تبقى في ملف على خادمك مدة شهر.

مكان وجود بيانات الاعتماد على VPS

ضع السر في ملف لا يستطيع قراءته إلا root، ودَع systemd يمرّره إلى العملية. يظل هذا الأسلوب صالحاً مع جميع إصدارات SDK، لذلك يستحق التنفيذ مرة واحدة وبطريقة صحيحة.

sudo useradd --system --home /opt/claude-app --shell /usr/sbin/nologin claudeapp
sudo install -d -m 700 -o root -g root /etc/claude-app
sudo install -m 600 -o root -g root /dev/null /etc/claude-app/env
sudoedit /etc/claude-app/env

يحتوي الملف على أسطر KEY=value عادية. لا تستخدم export أو علامات اقتباس أو صياغة shell، لأن systemd يحلّل الملف بنفسه بدلاً من تمريره إلى shell.

ANTHROPIC_API_KEY=sk-ant-api03-REPLACE-ME
CLAUDE_MODEL=REPLACE-ME

[Unit]
Description=Claude API service
After=network-online.target

[Service]
User=claudeapp
EnvironmentFile=/etc/claude-app/env
ExecStart=/opt/claude-app/venv/bin/python -m claude_app
Restart=on-failure

[Install]
WantedBy=multi-user.target

يقرأ systemd ملف EnvironmentFile= بصفته root، قبل أن ينتقل إلى User=claudeapp، لذلك لا يحتاج حساب الخدمة إلى صلاحية قراءة الملف. تكفي الصلاحيات 600 مع امتلاك root للملف، ولهذا يضبط الأمر install أعلاه هذه الصلاحيات. شغّل الخدمة باستخدام sudo systemctl enable --now claude-app، ثم تحقّق باستخدام systemctl status claude-app من أن الوحدة وصلت إلى الحالة active (running) بدلاً من إعادة التشغيل في حلقة.

تجنّب الأمور الأربعة التالية. لكل منها سبب يمكنك التحقق منه بنفسك:

• لا تكتب المفتاح باستخدام Environment= داخل ملف الوحدة. تكون الوحدة الموجودة ضمن /etc/systemd/system قابلة للقراءة من جميع المستخدمين، لذلك يعرض systemctl cat claude-app السر لأي مستخدم محلي.
• لا تضعه في المستودع. يمنع .gitignore إضافة ملف جديد إلى commit، لكنه لا يفعل شيئاً تجاه ملف أُضيف مسبقاً إلى commit، لأن سجل git يحتفظ بكل ما أُدخل إليه.
• لا تضعه داخل صورة حاوية. تُسجَّل أسطر ENV وقيم --build-arg في طبقات الصورة، ويعرض docker history --no-trunc هذه القيم. حذف الملف في طبقة لاحقة لا يزيله من الطبقة السابقة. مرّر الأسرار وقت التشغيل باستخدام --env-file أو باستخدام ملف مركّب بدلاً من ذلك.
• لا تعتبر بيئة العملية خاصة بالنسبة إلى root. يعرض sudo tr '\\0' '\\n' < /proc/$(pgrep -u claudeapp -f claude_app | head -1)/environ المفتاح. الهدف هو إبقاء السر بعيداً عن كل حساب آخر على الخادم، وليس بعيداً عن root، إذ يستطيع root قراءته مهما فعلت.

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

كيف أدوّر المفتاح من دون توقف الخدمة؟

نفّذ التدوير إلى الأمام، ثم ألغِ المفتاح السابق.

1. أنشئ المفتاح الجديد في Console، ضمن مساحة العمل نفسها التي يوجد فيها المفتاح القديم.
2. اكتب المفتاح في /etc/claude-app/env باستخدام sudoedit.
3. شغّل sudo systemctl restart claude-app.
4. تأكد من أن الخدمة تستجيب للطلبات، ثم ألغِ المفتاح القديم في Console.

تُقرأ قيمة EnvironmentFile عند بدء الوحدة، لذلك تحتفظ العملية قيد التشغيل بالقيمة التي مُنحت لها عند التشغيل. أما systemctl daemon-reload فيعيد قراءة ملفات الوحدات ولا يغيّر بيئة عملية قيد التشغيل، لذلك لا تلتقط العملية المفتاح الجديد إلا بعد إعادة التشغيل. إذا ألغيت المفتاح في الخطوة 1 بدلاً من الخطوة 4، فستتسبب في انقطاع يستمر حتى الخطوة 3.

تُدوّر المسارات الثلاثة الأخرى المفاتيح لدى موفّر الخدمة. يدعم مستخدم IAM مفتاحي وصول نشطين في الوقت نفسه، لذلك أنشئ المفتاح الثاني، وانشره، ثم احذف الأول. ويُدوَّر مفتاح حساب خدمة Google بالطريقة نفسها. يُعاد إنشاء مفتاح Foundry في البوابة، ما يلغي المفتاح القديم فوراً، لذلك اكتب القيمة الجديدة قبل النقر. لا تحتاج رموز Entra والرموز الموحدة الخاصة بـ Anthropic إلى أي تدوير، وهذا أقوى سبب لاستخدامها حيثما أمكن.

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

لماذا يعيد العميل 401 أو 403؟

401 مع authentication_error عند استخدام API المباشر. المفتاح غير صحيح، أو أُلغي، أو تجاوز تاريخ انتهاء صلاحيته. غالباً ما يُغفل المستخدمون انتهاء الصلاحية، لأن الرمز لم يتغير وكان الطلب يعمل في اليوم السابق. تحقق من عمود انتهاء صلاحية المفتاح في Console، أو اقرأ expires_at من Admin API، حيث تكون القيمة null للمفاتيح التي لا تملك تاريخ انتهاء صلاحية.

يتجاهل SDK إعداد federation ويستخدم مفتاحاً بدلاً منه. يأتي ANTHROPIC_API_KEY وANTHROPIC_AUTH_TOKEN قبل federation في ترتيب أولوية بيانات الاعتماد، لذلك يتغلب أي منهما عليها. انتبه إلى الحالة التالية: يظل المتغير المصدَّر كسلسلة فارغة مشغولاً بموضعه، لذلك يجعل ANTHROPIC_API_KEY="" SDK يصادق باستخدام مفتاح فارغ بدلاً من الانتقال إلى الخيار التالي. استخدم unset ANTHROPIC_API_KEY.

401 مع الرسالة المجردة Authentication failed عند استخدام federation. تتطابق هذه الرسالة عمداً مع جميع الأسباب المحتملة، حتى لا يتمكن مستدعي الخدمة من استنتاج إعدادات القواعد من نص الخطأ. يُسجَّل السبب الفعلي في صفحة سجل المصادقة في Console. ابدأ من هناك بدلاً من التخمين بشأن JWT.

403 في Foundry. تمت مصادقة الرمز، لكن حساب Azure الخاص بك لا يملك دوراً يسمح بإجراء الاستدعاء. عيّن دوراً من أدوار Azure RBAC، مثل Foundry User (المعروف سابقاً باسم Azure AI User) أو Cognitive Services User، إلى الهوية التي تنفذ الطلب.

أي خطأ في Bedrock. شغّل aws sts get-caller-identity أولاً باسم مستخدم الخدمة. يوضح الأمر ما إذا كان الخادم يملك بيانات اعتماد AWS صالحة للاستخدام، وبذلك يميّز مشكلة بيانات الاعتماد عن مشكلة الوصول إلى النموذج أو عدم تطابق المنطقة. يُمنح الوصول إلى النموذج لكل منطقة على حدة في وحدة تحكم AWS، ومن السهل تفعيله في منطقة واحدة ثم استدعاء النموذج من منطقة أخرى.

FAQ

هل أحتاج إلى مفتاح Anthropic API لاستخدام Claude على Bedrock أو Vertex؟

لا. في Amazon Bedrock، يوقّع SDK كل طلب باستخدام بيانات اعتماد AWS عبر SigV4. وفي Google Cloud، يرسل رمز وصول من Google يحصل عليه عبر Application Default Credentials. لا يوجد سر صادر عن Anthropic في أي من الإعدادين. وتُحتسب التكلفة على حساب السحابة، لا على Anthropic. ولهذا أيضاً يشكّل ترك مفتاح Anthropic في ANTHROPIC_API_KEY خطراً على تلك المضيفات: إذ سيرسل عميل عام موجّه إلى نقطة نهاية سحابية هذا المفتاح إليها دون تردد.

هل يتوفر Claude على Azure؟

نعم، من خلال Microsoft Foundry، الذي كان يُعرف سابقاً باسم Azure AI Foundry. تنشئ مورداً في Foundry، وتنشر نموذج Claude فيه، ثم تستدعي https://{resource}.services.ai.azure.com/anthropic/v1/messages باستخدام مفتاح صادر عن Azure في ترويسة api-key أو باستخدام رمز bearer مميز من Microsoft Entra. تُحتسب التكلفة عبر Azure Marketplace بوحدات Claude Consumption Units. يجب أن يحمل الحقل model في نص الطلب اسم النشر. ولا يطابق هذا الاسم معرّف النموذج إلا إلى أن تعيد تسمية النشر.

أين ينبغي أن أخزّن مفتاح Claude API على خادم Linux؟

في ملف يملكه root وبصلاحيات 600، ويُحمّل عبر EnvironmentFile= في وحدة systemd. يقرأ systemd هذا الملف بصفته root قبل أن ينتقل إلى User= الخاص بالوحدة، لذلك لا يحتاج حساب الخدمة إلى الوصول إليه. أبقِ المفتاح خارج المستودع، وخارج ملف الوحدة نفسه، لأن هذا الملف قابل للقراءة عالمياً وتطبعه systemctl cat، وخارج طبقات صور الحاويات، لأن docker history --no-trunc يطبع أي قيمة تُضبط باستخدام ENV أو --build-arg.

لماذا بدأ طلب Claude API بإرجاع 401 رغم عدم تغيير أي شيء؟

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