تسعير وكلاء الذكاء الاصطناعي: كم تتقاضى من عملائك؟

جدول المحتويات

نُشر في أغسطس 2026.

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

[منظور المشغّل] أُشغّل أكثر من 30 وكيل ذكاء اصطناعي في الإنتاج بين علامة استشارية و Pickleland، وهي منشأة بيكلبول في بفلوغرفيل، تكساس، وقد سعّرت أعمال بناء الوكلاء للعملاء بناءً على هذه التجربة. الخطأ الأكثر شيوعاً الذي أراه — من المستقلين ومن الوكالات على حد سواء — هو معاملة وكيل الذكاء الاصطناعي كموقع إلكتروني: تسعير، بناء، تسليم، وفاتورة مدفوعة بالكامل. الوكلاء ليسوا مواقع إلكترونية. إنها أنظمة تحتاج باستمرار إلى اهتمام لأن ما تحتها (نموذج، أو واجهة برمجة تطبيقات، أو سير عمل عميل) يستمر في التغيّر. سعّر لهذا الواقع وإلا ستتحمّل تكلفته بنفسك.

لماذا تفشل الفوترة بالساعة في عمل الوكلاء

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

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

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

البنية ذات الجزأين: رسوم البناء + اشتراك الصيانة

1. رسوم البناء — سعر ثابت لمرة واحدة لتصميم الوكيل وبنائه واختباره ونشره. تُدفع مرة واحدة، عادةً على قسطين (دفعة مقدّمة عند البدء، والرصيد عند التسليم).

2. اشتراك الصيانة — رسوم شهرية متكررة تبدأ في الشهر التالي للإطلاق. يغطي المراقبة، وإصلاحات التوجيهات عند تغيّر النموذج أو واجهة برمجة تطبيقات مرتبطة به، والتعديلات الصغيرة التي لا تتجاوز النطاق.

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

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

تحديد حجم رسوم البناء

حدّد حجم رسوم البناء حسب فئة النطاق، وليس بتخمين عدد الساعات. ثلاث فئات تغطي معظم أعمال العملاء:

تفترض هذه النطاقات وجود جدار نطاق محدد، بنفس الانضباط الموصوف في كيفية بناء خدمة مُنتَجة: قائمة مكتوبة بما هو مشمول، وقائمة مكتوبة بما هو غير مشمول، وعدد ثابت من سير العمل أو تكاملات الأدوات. العميل الذي يطلب “وكيل ذكاء اصطناعي لعملي” دون سير عمل محدد ليس جاهزاً لشراء بناء — إنه جاهز لمكالمة تحديد نطاق، وهي مُنتَج تسليم منفصل وأصغر (أنا أُسعّر مكالمتي كتدقيق ثابت بين 500–1,000 دولار ينتج وثيقة النطاق التي تُسعَّر رسوم البناء بناءً عليها).

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

تحديد حجم اشتراك الصيانة

أُحدد الاشتراك كنسبة مئوية من رسوم البناء، وليس كرقم ثابت، لأن تكلفة الصيانة تتناسب مع تعقيد النظام بنفس الطريقة التي تتناسب بها تكلفة البناء.

maintenance_retainer_per_month = build_fee × monthly_rate

monthly_rate:
  stable integrations, low API-change risk        → 3–5%
  volatile APIs (social platforms, scraped data)   → 6–10%
  multi-agent systems, custom eval suite to keep up → 8–12%

بالنسبة لبناء متعدد الخطوات بقيمة 6,000 دولار على بنية مستقرة نسبياً، هذا يعادل تقريباً 250–400 دولار شهرياً. يجب أن يبدو هذا الرقم قريباً جداً من ضريبة الصيانة التي أطبّقها على أتمتتي الخاصة — نسبة ثابتة قدرها 20% من تكلفة البناء سنوياً، والتي تعادل نفس نطاق 3–5% الشهري عند الحد الأدنى. الاشتراك الموجّه للعميل يقع في نفس مرتبة الحجم لأن محرّك التكلفة الأساسي — انحراف التوجيهات، وتغيّرات واجهة برمجة التطبيقات، والحالات الاستثنائية التي تظهر بعد الإطلاق — لا يتغيّر لمجرد أن شخصاً آخر يدفع ثمنه.

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

اربط السعر بما يستبدله، لا بما يكلّفه بناؤه

يجب ألا تُبرَّر رسوم البناء للعميل من خلال ساعاتك — بل من خلال التكلفة اليدوية التي تُزيلها. قبل تقديم عرض السعر، أجرِ نفس حساب التكلفة اليدوية من إطار عائد الاستثمار على جانب العميل:

manual_cost_per_year = time_per_instance × hourly_rate × frequency_per_year
                      + error_cost_per_year

إذا كان فريق العميل يقضي 5 ساعات أسبوعياً في مهمة يستطيع الوكيل القيام بها، بمعدل ساعة كامل قدره 40 دولاراً، فتلك 10,400 دولار سنوياً كتكلفة يدوية. رسوم بناء بقيمة 6,000 دولار مع اشتراك 300 دولار شهرياً (3,600 دولار سنوياً) تسترد تكلفتها في أقل من عام وتستمر في تحقيق العائد كل عام بعد ذلك. تلك المقارنة — التكلفة اليدوية مقابل تكلفة البناء زائد الاشتراك — هي العرض الفعلي. ابدأ بها في كل اقتراح. السعر بلا نقطة مقارنة مجرد رقم؛ أما السعر بجانب ما يستبدله فهو حجة.

هذا أيضاً يضع سقفاً طبيعياً: إذا كانت التكلفة اليدوية المُستبدَلة صغيرة، فلا ينبغي للعميل شراء نظام متعدد الوكلاء بقيمة 15,000 دولار، ولا ينبغي لك بيعه له. تحديد حجم الفئة بدقة مقابل التكلفة الفعلية المُزاحة هو ما يبقي التسعير صادقاً في الاتجاهين.

بنود العقد التي تمنع توسع النطاق

أربعة بنود تدخل في كل عقد بناء وكيل أكتبه، إضافة إلى السعر:

1. تعريف مكتوب لـ”الانتهاء”. حالات اختبار محددة يجب أن يجتازها الوكيل قبل استحقاق الدفعة النهائية — ليس “يعمل بشكل جيد”، بل قائمة: “يصنّف بشكل صحيح 9 من 10 عملاء محتملين عينة من مجموعة البيانات المُقدَّمة”، “ينشر بنجاح على صفحة فيسبوك المرتبطة دون تدخل يدوي”. معايير القبول الغامضة هي أكبر مصدر منفرد لعمل إضافي غير مدفوع.
2. شروط الملكية، مذكورة بوضوح. يملك العميل منطق سير العمل وأي بيانات خاصة به. تحتفظ أنت بالبنية التحتية القابلة لإعادة الاستخدام، وقوالب التوجيهات، ومجموعات التقييم غير الخاصة بعمله — نفس نقطة إعادة استخدام الملكية الفكرية المُغطّاة في أنظمة تسليم الخدمة المُنتَجة. قل هذا مسبقاً؛ فهذا يتجنب محادثة محرجة لاحقاً.
3. مسار تسليم محدد لإلغاء الاشتراك. إذا ألغى العميل الصيانة، وضّح بدقة ما سيحدث: يستمر الوكيل بالعمل كما هو دون إصلاحات إضافية، أو يُعطَّل بعد فترة إشعار. ترك هذا غير محدد يعني أنك مسؤول عن نظام لا يدفع لك أحد لمراقبته.
4. طلبات التغيير مُسعَّرة بشكل منفصل، كتابياً، قبل بدء العمل. ليس “سنتفاهم على ذلك” — بل سعر أو حد أدنى لكل طلب، مذكور في العقد، بحيث لا يتحول طلب العميل لتغيير في النطاق إلى مفاوضة في كل مرة.

التعامل مع الاعتراضين اللذين يظهران دائماً

“لماذا تكلّف صيانة شيء يعمل بالفعل تكلفة إضافية؟” لأن “يعمل” لحظة، وليست حالة دائمة. مزوّد النموذج يمكن أن يُهمل أو يغيّر سلوك النموذج، والمنصة التي ينشر عليها الوكيل يمكن أن تغيّر واجهة برمجة تطبيقاتها، وعمل العميل نفسه يمكن أن يغيّر سير العمل الذي بُني الوكيل حوله. لا شيء من ذلك عيب فيما سلّمته — إنه معدل التدهور الطبيعي لأي نظام متصل بأجزاء خارجية متحركة. أُؤطّر الاشتراك صراحةً كتأمين ضد ذلك التدهور، وليس كـ”دعم” مستمر — فالدعم يوحي بأن شيئاً ما مكسور؛ الاشتراك يعني أن أحداً يراقب قبل أن يُكسَر.

“ألا يمكنني فقط استخدام أداة بلا كود وتخطي رسوم البناء بالكامل؟” أحياناً، نعم — وأقول ذلك صراحةً. إذا كان سير العمل بسيطاً حقاً (مُحفّز واحد، إجراء واحد، بلا منطق مخصص)، فمنصة أتمتة بلا كود هي الإجابة الصادقة، وسأوجّه العميل إليها بدلاً من تقديم عرض بناء. رسوم البناء مُبرَّرة عندما يكون هناك منطق حقيقي، أو عمل تكامل، أو حكم لا تستطيع أداة السحب والإفلات التعبير عنه. رفض المهمة غير المناسبة هو ما يجعل المهام التي تقبلها موثوقة.

الأدوات التي أستخدمها لإدارة هذا العمل

Notion — وثيقة النطاق تعيش هنا: ما هو مشمول، وما هو غير مشمول، وقائمة اختبار القبول، وشروط الملكية، تُشارَك مع العميل قبل تحصيل أي دفعة مقدّمة.

Airtable — صف واحد لكل عمل نشط، يتتبع حالة البناء، وتاريخ فوترة الاشتراك، وآخر مرة تم فيها فحص مخرجات كل وكيل عشوائياً.

Claude هو ما أبني عليه معظم هذه الوكلاء — تسعير الاشتراك أعلاه يفترض بنية نموذج بتسعير وسلوك مستقرَّين نسبياً، وهو ما يغيّر افتراض التقلب في صيغة المعدل الشهري إذا كنت تستخدم مزوّداً أقل استقراراً.

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

هل يجب أن تكون الدفعة المقدّمة 50% أو نسبة أخرى؟

50% عند البدء، و50% عند التسليم مقابل معايير القبول المكتوبة هي الأبسط والتي أستخدمها افتراضياً. بالنسبة لعمليات بناء الأنظمة متعددة الوكلاء الأكبر (فئة 15,000+ دولار)، أقسّمها إلى ثلاثة: دفعة مقدّمة، ودفعة عند مرحلة نموذج أولي يعمل، والرصيد عند التسليم — بشكل أساسي لتجنّب هبوط فاتورة نهائية كبيرة على عميل توقف عن التواصل منتصف المشروع.

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

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

كيف أعرف إذا كان افتراض معدلي الشهري (3–12%) منخفضاً جداً؟

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

هل أحتاج إلى عقد منفصل لمكالمة تحديد النطاق؟

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

الخطوات التالية: دورة AI Agents for Beginners الخاصة بي تغطي بناء الوكلاء التي يفترض إطار التسعير هذا أنك قادر بالفعل على تسليمها. برنامج cowork مخصص للمشغّلين الذين يريدون بيئة منظمة لبناء هذا النوع من العمل وتسعيره. إذا كنت تفضّل الحصول على التدقيق ووثيقة النطاق مبنيَين لك أولاً، احجز جلسة مدتها 30 دقيقة.