التحكم بتكلفة وكيل ذكاء اصطناعي دائم التشغيل على VPS

كيف تمنع وكيل ذكاء اصطناعي دائم التشغيل من تراكم الفاتورة

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

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

لماذا يكون شكل تكلفة الوكيل غير المراقب مختلفًا

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

التكرار هو المضاعف الذي يغفل عنه الناس. مهمة بجدول زمني كل خمس دقائق تعمل 288 مرة في اليوم وحوالي 8,640 مرة في الشهر. مهما كانت تكلفة التشغيل الواحد، فهذا هو الرقم الذي تضاعفه. العديد من الوكلاء "دائمي التشغيل" لا يحتاجون أن يكونوا في حالة تشغيل دائم. هم يحتاجون للرد خلال عدد معين من الدقائق، وهذا يعني جدولاً زمنياً.

يدفع الوكيل أيضًا مقابل أشياء لا تدفع مقابلها نافذة المحادثة.

• تعريفات الأدوات تُرفق مع كل طلب. موجه نظام استخدام الأدوات يكلف 290 رمزًا على Claude Opus 4.8 مع tool_choice من auto أو none، و 410 مع any أو tool. أداة bash تضيف 325 رمزًا إضافيًا. كل خادم MCP تقوم بإرفاقه يضيف مخططاته إلى ذلك الوزن، MCP هو بروتوكول سياق النموذج.
• نتائج الأدوات هي رموز إدخال. أمر يطبع 8,000 سطر يضع 8,000 سطر في الطلب التالي، وفي كل طلب بعده في ذلك الدور.
• الصفحات المُستجلبة هي رموز إدخال. صفحة ويب متوسطة بحجم 10 كيلوبايت تساوي تقريبًا 2,500 رمز وملف PDF بحثي بحجم 500 كيلوبايت يساوي تقريبًا 125,000 رمز. max_content_tokens يقتطع النصوص منها فقط، لأنه "يُطبق على المحتوى النصي، وليس على المحتوى الثنائي مثل ملفات PDF". قم بتقييد ملف PDF باستخدام max_uses و allowed_domains بدلاً من ذلك.
• البحث على الويب يُسعّر لكل بحث، بسعر 10 دولارات لكل 1,000 بحث، بغض النظر عن عدد النتائج العائدة. البحث الذي يحدث فيه خطأ لا يتم إصدار فاتورة به.

لا شيء من هذا مكلف لو حدث مرة واحدة. كله مكلف لو حدث 8,640 مرة.

السقوف الصلبة والسقوف الناعمة تحل مشكلات مختلفة

max_tokens يُفرض. هو حد أقصى صلب على الناتج الكلي لطلب واحد، يشمل نص التفكير والاستجابة معاً. لا يتجاوزه كلود أبداً، ولا يستطيع النموذج رؤية الرقم. بلوغه يعطي stop_reason: "max_tokens" وإجابة مبتورة. المأزق للوكلاء: كل طلب في حلقة استخدام الأدوات يحمل max_tokens الخاص به، لذا فهو يحد استجابة واحدة لا المهمة كلها. عشر استدعاءات أداة بـ 4,000 تعطي سقف 40,000 رمز للدورة.

ميزانية المهمة استشارية. task_budget تقع داخل output_config وتخبر النموذج كم رمزاً لديه للحلقة الوكيلية بأكملها، شاملة التفكير واستدعاءات الأدوات ونتائج الأدوات والناتج.

resp = client.beta.messages.create(
    model="claude-opus-4-8",
    max_tokens=4096,
    betas=["task-budgets-2026-03-13"],
    output_config={"task_budget": {"type": "tokens", "total": 64000}},
    messages=messages,
)

"ميزانيات المهام تلميح ناعم، لا حد أقصى صلب." قد يتجاوزها كلود في منتصف الإجراء، والحد المفروض على الناتج يبقى max_tokens. "العد التنازلي مرئي للنموذج فقط"، والاستجابات لا تحمل حقلاً للرصيد المتبقي. الحد الأدنى المقبول لـ task_budget.total هو 20,000 رمز، والأقل يعيد خطأ 400. الميزانية الأصغر من العمل تنتج سلوكاً شبيهاً بالرفض، فيقلص النموذج نطاق المهمة أو يتوقف مبكراً.

تفصيل واحد يكلف مالاً بدل أن يوفره. إذا أنقص عميلك task_budget.remaining في كل طلب متابعة، فإن القيمة المتغيرة تبطل أي بادئة مخزنة تحتويها. عيّنها مرة واحدة، في الطلب الأول.

ميزانيات المهام في طور بيتا على Claude Fable 5 و Claude Opus 4.8 و Claude Opus 4.7. Claude Sonnet 5 و Claude Haiku 4.5 مدرجان كـ Not supported، وميزانيات المهام لا تنطبق على Claude Code، لذا تعتمد جلسة Claude Code المفصولة في tmux على نظافة الجلسة بدلاً من ذلك.

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

اختيار النموذج لكل مهمة، وما يغيره مستوى الجهد فعليًا

اختيار النموذج هو قرار يُتخذ لكل مهمة على حدة. اعتبارًا من يوليو 2026، لكل مليون رمز، للإدخال ثم الإخراج: Claude Fable 5 بسعر 10$ و50$، وClaude Opus 4.8 وOpus 4.7 بسعر 5$ و25$، وClaude Sonnet 5 بسعر 3$ و15$، وClaude Haiku 4.5 بسعر 1$ و5$. سعر Sonnet 5 أقل من سعره الرسمي حاليًا، لأن "التسعير التمهيدي البالغ 2$/10$ لكل مليون رمز إدخال/إخراج سارٍ حتى 31 أغسطس 2026". المهمة التي تقتصر على تصنيف سجلات الأحداث لا تحتاج إلى Opus.

مستوى الجهد هو أداة التحكم الثانية. output_config.effort يقبل low وmedium وhigh وxhigh وmax، والقيمة الافتراضية هي high. لذا، تعيين high صراحةً يعادل حذفه. الجهد المنخفض يقلل أكثر من مجرد طول التفكير: تنص الوثائق على أنه يجعل Claude يُجري استدعاءات أدوات أقل ويدمج العمليات في عملية واحدة. في الوكيل، هذا هو التوفير الأكبر، لأن استدعاء الأداة الذي يتم تجنبه هو طلب كامل لا يحدث أصلًا.

المأزق هو أن الجهد يتعارض مع الذاكرة المؤقتة. تغيير القيمة بين الطلبات يُبطل التخزين المؤقت للموجه. في المثال الموثق، أبلغ الطلب 2 عن cache_read_input_tokens: 3546؛ أما الطلب 3، بعد تغيير الجهد من عالٍ إلى متوسط، فقد أبلغ عن cache_creation_input_tokens بقيمة 3546 وcache_read_input_tokens بقيمة 0. لذا، نوّع مستوى الجهد عبر أعباء العمل المختلفة، وليس داخل محادثة واحدة مخزنة مؤقتًا. لتوجيه العمق دون كسر الذاكرة المؤقتة، افعل ذلك في الموجه: سطر مثل "أجب مباشرة دون تداول." في أحدث رسالة مستخدم يُبقي نقاط التوقف السابقة سليمة.

رموز التفكير تُفوتر بأسعار الإخراج وتُحتسب ضمن max_tokens، وهذا هو سبب أن الإجابة المقتطعة تعني غالبًا أن التفكير استنفد الميزانية. اقرأ usage.output_tokens_details.thinking_tokens لمعرفة الرقم. ما الذي يملأ فاتورة رموز Claude فعليًا يشرح العداد بالتفصيل.

خزّن البادئة المستقرة، وتوقّف عن كسرها دون قصد

تكلّف عملية الكتابة في الذاكرة المؤقتة 1.25 ضعف سعر الإدخال الأساسي لذاكرة الخمس دقائق، وضعفين لذاكرة الساعة الواحدة. وتكلّف عملية القراءة 0.1 ضعف، لذا "يؤتي التخزين المؤقت ثماره بعد قراءة واحدة فقط لمدة 5 دقائق (كتابة بـ 1.25x)، أو بعد قراءتين لمدة ساعة واحدة (كتابة بـ 2x)".

يشرح سطر واحد لماذا يناسب هذا وكيلاً يعمل دائماً: "تُحدّث الذاكرة المؤقتة دون تكلفة إضافية في كل مرة يُستخدم فيها المحتوى المخزّن". مهمة تعمل كل دقيقتين مقابل ذاكرة الخمس دقائق تبقي بادئتها دافئة طوال اليوم مقابل كتابة واحدة.

ثلاث طرق لتفقد الذاكرة المؤقتة دون أن تنتبه.

بادئة تتغير. "تُنشأ بادئات الذاكرة المؤقتة بالترتيب التالي: tools، ثم system، ثم messages." أي تغيير في أي بايت سابق في هذا الترتيب يُبطل كل ما يليه، وتعديل تعريفات الأداة يُبطل الذاكرة المؤقتة بأكملها. الخطأ الكلاسيكي الذي يرتكبه المستخدم بنفسه هو طابع زمني أو معرّف تشغيل في موجه النظام: عندها تحمل كل طلبية بادئة مختلفة، وتكتب إدخالاً جديداً بتكلفة 1.25x، ولا تقرأ شيئاً. العلامة الدالة هي usage.cache_read_input_tokens بقيمة 0 عبر استدعاءات تبدو متطابقة. انقل النص المتغير إلى أحدث رسالة مستخدم.

بادئة قصيرة جداً. لكل نموذج حد أدنى للطول القابل للتخزين المؤقت، ودونه تُعالج الطلبية دون تخزين مؤقت و"لا يُعاد أي خطأ". تشمل الأرقام 1,024 رمزاً على Claude Opus 4.8 و Claude Sonnet 5، و 4,096 على Claude Haiku 4.5، لذا نقل مهمة من Sonnet إلى Haiku يمكن أن يُوقف التخزين المؤقت بصمت.

محادثة تتجاوز نافذة الرجوع. "نافذة الرجوع هي 20 كتلة." يفحص النظام 20 موضعاً كحد أقصى لكل نقطة توقف، ثم يتوقف. في المثال الموثق، دور يحمل 35 كتلة مع نقطة توقف على الكتلة 35 يفحص الكتل من 35 نزولاً إلى 16، ويقع إدخال الدور السابق عند الكتلة 15 خارج النافذة، فلا تحدث إصابة. وكيل يضيف عدة كتل استخدام أداة ونتيجة أداة في كل دور يتجاوز 20 في دورين أو ثلاثة. تحصل على أربع نقاط توقف لكل طلبية، لذا أنفق واحدة على الرسائل الحديثة.

أرسل أي شيء يمكنه الانتظار إلى واجهة Batches

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

استطلع حالة processing_status حتى تظهر القيمة ended. الطلبات التي تُرجع errored أو canceled أو expired لا يتم إصدار فاتورة بها. ثمة تحذير واحد إذا كنت تعتمد على سقف إنفاق: "قد تتجاوز الدفعات حد الإنفاق المُعد في مساحة العمل الخاصة بك بشكل طفيف."

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

سجّل حقول الاستخدام لكل استجابة في مخزنك الخاص

لا يمكنك إسناد إنفاق لم تسجّله قط. كل استجابة تخبرك كم كلّفت.

u = resp.usage
row = {
    "job": job_name,
    "model": resp.model,
    "uncached_input": u.input_tokens,
    "cache_write": u.cache_creation_input_tokens,
    "cache_read": u.cache_read_input_tokens,
    "output": u.output_tokens,
    "stop_reason": resp.stop_reason,
}

أضف صفًا واحدًا لكل استدعاء API إلى ملف JSON-lines، موسومًا باسم مهمتك. بعد أسبوع يمكنك أن تحدد أي مهمة تنفق وأيها بدت مشغولة فقط. راقب cache_read: عمود من الأصفار هو أشهر خطأ في التكلفة لدى وكيل مستضاف ذاتيًا.

حقل واحد يسهل إساءة قراءته. input_tokens يحسب فقط الرموز التي تلي آخر نقطة توقف للذاكرة المؤقتة، لذا حجم الموجه الحقيقي هو total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens. وكيل يبلغ input_tokens: 400 على موجه كبير ليس رخيصًا: الباقي جاء من الذاكرة المؤقتة.

احسب قبل أن ترسل. عدّ الرموز مجاني وحدود معدله منفصلة عن إنشاء الرسائل، لذا استخدم count_tokens لرفض مرفق كبير الحجم بدل أن تدفع لتكتشف ذلك. النتيجة تقديرية، لذا أعد القياس لكل نموذج ولا تعِد استخدام عدد من مجزئ رموز بائع آخر. Claude Opus 4.7 ونماذج Opus اللاحقة، وClaude Fable 5 وClaude Sonnet 5 تستخدم مجزئ رموز أحدث "ينتج حوالي 30% رموزًا أكثر للنص نفسه". Claude Sonnet 4.6 وما قبله، ومنها Claude Haiku 4.5، تستخدم المجزئ السابق.

للاطلاع الرسمي، تبلغ واجهة Admin API عن الاستخدام عند https://api.anthropic.com/v1/organizations/usage_report/messages وعن التكلفة عند https://api.anthropic.com/v1/organizations/cost_report. كلاهما يأخذ مفتاح admin (sk-ant-admin01-...) كـ x-api-key: $ANTHROPIC_ADMIN_KEY مع anthropic-version: 2023-06-01، ويقبل bucket_width=1d وgroup_by[]=model وapi_key_ids[]=. قيد واحد: "واجهة Admin API غير متاحة للحسابات الفردية."

ذلك المعامل الأخير حيلة إسناد رخيصة: أعطِ كل مهمة مفتاح API خاصًا بها، وفلتر باستخدام api_key_ids[]، وقسّم التقرير لكل مفتاح باستخدام group_by[]=api_key_id. الفلتر بصيغة الجمع، وبُعد التجميع بصيغة المفرد. احفظ المفاتيح في البيئة لا في الكود، بالطريقة التي يعالجها أول تطبيق Claude API على خادم افتراضي خاص.

قيّد الحلقة، فلا شيء آخر سيفعل ذلك

عدد مرات التكرار المحدد ليس اختيارياً هنا. الحلقة ملكك، لذا العداد ملكك أيضاً:

for step in range(MAX_STEPS):          # MAX_STEPS = 12, never "while True"
    resp = client.messages.create(...)
    if resp.stop_reason != "tool_use":
        break
else:
    log.warning("job %s hit MAX_STEPS=%d, giving up", job_name, MAX_STEPS)

لا يقوم أي من السقفين أعلاه بذلك نيابةً عنك: max_tokens يحد استجابة واحدة، ويتم إعلام النموذج فقط بميزانية المهمة.

ضع مكبحاً ثانياً خارج العملية. شغّل المهمة من مؤقت systemd بدلاً من عملية دائمة، وعيّن RuntimeMaxSec= على وحدة الخدمة الخاصة بها. باستخدام RuntimeMaxSec=600, يتم إنهاء عملية تنفيذ عالقة بعد عشر دقائق بدلاً من أن تدور حتى تلاحظ ذلك. تشغيل برنامج كخدمة ومؤقت systemd يغطي ملفات الوحدة نفسها. اقرأ ما فعلته عملية التنفيذ باستخدام journalctl -u triage-agent.service --since "1 hour ago".

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

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

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

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

FAQ

كم تبلغ تكلفة تشغيل وكيل ذكاء اصطناعي دائم التشغيل على خادم افتراضي خاص؟

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

ما الفرق بين max_tokens وميزانية المهمة؟

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

لماذا تكون قيمة cache_read_input_tokens دائماً صفراً لوكيلي؟

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

كيف أوقف وكيل ذكاء اصطناعي من التكرار اللانهائي؟

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

هل يمكنني تعيين حد للإنفاق على مفتاح واجهة برمجة تطبيقات Claude واحد؟

حد الإنفاق الموثق هو لكل مساحة عمل وليس لكل مفتاح، لذا امنح الوكيل مساحة عمل خاصة به وحدّد إنفاقه الشهري هناك. "لا يمكنك تعيين حدود على مساحة العمل الافتراضية". أضف إشعارات إنفاق بحيث ينبهك حد معين أولاً. للإسناد، أصدر لكل مهمة مفتاحها الخاص، ثم جمّع تقرير الاستخدام باستخدام group_by[]=api_key_id.