وكلاء الذكاء الاصطناعي: حل تكاليف الانتظار عبر التنفيذ الدائم

مقدمة تحليلية

في مؤتمر مهندسي الذكاء الاصطناعي لعام 2026، كشف حمزة طاهر من ZenML عن مشكلة اقتصادية دقيقة: "معظم حياة الوكيل تُقضى في الانتظار – أداة، إنسان، الخطوة التالية – وكل هذا الوقت يُشغل عملية حية ويتم محاسبتك عليها". هذه الجملة تحدد المشكلة الاقتصادية التي لا تظهر في عروض الوكلاء، والتي تقرر بقاء شركاتهم في مواجهة المدير المالي. الأرقام الأولية صادمة. دراسة "تأثير هيرنس" (The Harness Effect)، التي نُشرت في يوليو 2026، كشفت أن:

• استدلال النموذج يمثل حوالي 20% فقط من إجمالي تكلفة الوكيل. البنية التحتية، الأوركسترا، الأدوات، والحوكمة تستهلك 80% المتبقية.
• تغيير طبقات الأوركسترا (مع نفس النموذج) خفض التكلفة لكل مهمة بنسبة 41%، من 0.21 دولار إلى 0.12 دولار.
• طبقة الأوركسترا أثرت على التكلفة لكل مهمة أكثر من التبديل بين النموذج الأرخص والأغلى.
• جودة الدولار الواحد ارتفعت بنسبة 82% (من 3.71 إلى 6.75). إنجازات المهام لكل مليون توكن زادت بنسبة 68%.

تدعم هذه البيانات استنتاجات فريق هندسة CockroachDB، حيث أكدت أبحاث مختبر ستانفورد للاقتصاد الرقمي أن سياق إعادة الإرسال وحده – المحفزات، تعريفات الأدوات، وسجل الحالة المرسلة بشكل متكرر – يمثل 62% من إجمالي فواتير استدلال الوكلاء. مع توقعات Goldman Sachs بزيادة استهلاك التوكن بمقدار 24 ضعفاً بحلول عام 2030، تتفاقم هذه الكفاءات، ولا تتقلص.

التحليل التقني

تتوزع فترات خمول الوكلاء عبر أربع فئات رئيسية تحدد مواطن هدر الموارد:

1. كمون استدعاء الأدوات

كل استدعاء لأداة خارجية يتضمن رحلة ذهاب وعودة عبر الشبكة. تحليل تقني عميق لميزانيات وقت وكلاء كشف عن أربع ساعات غير متزامنة تعمل بالتوازي خلال استدعاء أداة واحدة:

• ساعة وحدة تحكم الوكيل (تبدأ عند إرسال الطلب)
• ساعة النموذج (تبدأ عند وصول أول توكن)
• ساعة عميل الأداة (تقيس من لحظة إصدار استدعاء الأداة)
• ساعة خادم الأداة (تُفعّل عند الاستلام الفعلي للطلب)

تتراكم فترات الكمون الخفية قبل بدء تنفيذ الأداة، بما في ذلك تأخيرات TTFT، قفزات مسارات البث، حمل موجه MCP الزائد، وتراكم قائمة انتظار عمال الأدوات. أداة بميزانية 8 ثوانٍ قد لا يتبقى لها سوى 6.6 ثوانٍ من منظور الوكيل بعد 1.4 ثانية من حمل النقل الزائد. تتجاوز حالات الفشل مجرد الكمون، وتشمل نتائج ناجحة يتيمة (أنهت الأداة عملها بعد استسلام الوكيل)، واستدعاءات أدوات مكررة من منطق إعادة المحاولة، ووكلاء يعيدون التخطيط رغم وصول استجابات صحيحة متأخرة قليلاً.

2. بوابات الموافقة البشرية

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

3. تأخيرات إعادة المحاولة وحدود المعدل

عندما تُرجع أداة خطأ 429 أو خطأً عابراً، يكون النمط القياسي هو التأخير الأسي: الانتظار 1 ثانية، ثم 2 ثانية، ثم 4 ثوانٍ، ثم 8 ثوانٍ. خلال كل فترة انتظار، تكون العملية حية ويتم قياس استهلاكها. تشير تقارير ممارسين على Reddit إلى أن وكلاء الذكاء الاصطناعي الذين يدخلون في حلقات إعادة محاولة بسبب مخرجات أدوات سيئة يستهلكون بهدوء 5-10 أضعاف ميزانية التوكن المتوقعة لكل مهمة قبل أن يلاحظها بشر.

4. حلقات الاستقصاء وانتظار الأحداث

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

الحل ليس "جعل الوكلاء أسرع"، بل "وقف الفوترة على الانتظار". التنفيذ الدائم – النمط المطبق بواسطة Temporal وInngest وRivet Actors والآن Cloudflare Workflows – يتعامل مع الانتظار كتواصل بدلاً من حلقة:

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

تتوقف العملية. تنخفض موارد الحوسبة إلى الصفر. لا تدفع شيئًا.

عند وصول الإشارة (استجابة أداة، ويبهوك موافقة، انتهاء مؤقت)، تستعيد وحدة التحكم الوكيل من اللقطة في أجزاء من الثانية.

يستأنف التنفيذ من النقطة التي توقف عندها تمامًا، كما لو لم يمر وقت.

تشير بيانات Inngest إلى أن أنماط التعليق والاستئناف للموافقات البشرية تقلل تكلفة الانتظار الخامل بنسبة 60-80%. إطار عمل Microsoft Agent، الذي أعلن عنه في BUILD 2026، بنى هذا المبدأ منذ البداية: الوكلاء يتكيفون إلى الصفر، ولا يدفعون شيئًا أثناء الخمول، ويتوسعون مرة أخرى عند الطلب التالي – مع استمرار الملفات وحالة القرص وهوية الجلسة عبر هذا الحد. نمط CodeAct الخاص بهم يذهب أبعد من ذلك: بدلًا من اختيار أداة، الانتظار، اختيار التالية، يكتب النموذج برنامج بايثون واحدًا يستدعي الأدوات عبر call_tool()، ينفذه مرة واحدة في بيئة منعزلة، ويعيد نتيجة موحدة. رحلة ذهاب وعودة واحدة بدلاً من عشرة.

السياق وتأثير السوق

فئة التنفيذ الدائم للوكلاء ليست نظرية، بل هي قيد الشحن. المشهد الحالي يتضمن:

• Temporal – اللاعب الأبرز: جولتهم التمويلية Series D بقيمة 300 مليون دولار بتقييم 5 مليارات دولار في فبراير 2026 (بقيادة a16z) وإصدار Replay 2026 – Workflow Streams لمخرجات LLM، وServerless Workers، وتكامل OpenAI Agents SDK المتاح منذ مارس – يشير إلى أن الشركة تعيد تموضعها بقوة حول الوكلاء. تبرز قوتها في دعم سبع لغات برمجية وسجلها الإنتاجي العميق ودلالات إعادة تشغيل تاريخ الأحداث. لكن التعقيد التشغيلي يمثل نقطة ضعف، حيث يتطلب تشغيل الكلاستر الخاص بك أو دفع تكاليف Temporal Cloud، وتصعب عملية إصدارات Workflow بشكل ملحوظ.
• Inngest – تجربة المطور: خطط عمل مدفوعة بالأحداث بدون بنية خلفية ذات حالة لإدارتها. إطار عملهم AgentKit متعدد الوكلاء مدعوم بجولة Series A بقيمة 21 مليون دولار (Altimeter، سبتمبر 2025). تكمن قوتها في غياب البنية التحتية للإدارة ونموذج خطوة العمل الذي يتوافق بوضوح مع مسارات عمل الوكلاء والمحفزات الحدثية المدمجة. لكنها توفر مرونة أقل من Temporal للأوركسترا المعقدة، وهي أحدث وأقل اختبارًا على نطاقات واسعة.
• Rivet Actors – التنفيذ الدائم كأصل: الخيار الأقل مستوى: أوليات عبء العمل ذات الحالة المصممة خصيصًا لوكلاء الذكاء الاصطناعي والتطبيقات التعاونية والتنفيذ الدائم. مفتوح المصدر تحت Apache 2.0، مما يمنحك ملكية كاملة للبنية التحتية. مشروعه المصاحب AgentOS يشغل وكلاء البرمجة داخل أجهزة افتراضية Linux معزولة بنواة نظام تشغيل داخل العملية. تكمن قوتها في أقصى قدر من التحكم، غياب الاعتماد على بائع معين، وكونها مصممة خصيصًا لحالة استخدام الوكيل. لكنها تتطلب منك بناء المزيد بنفسك، ولديها بيئة أقل نضجًا من Temporal.

لا يمكن تحسين ما لا يمكن رؤيته. هنا يأتي دور SigNoz الذي تحول إلى المراقبة الأصلية للوكلاء – عروض متتالية لكل استدعاء نموذج، واستدعاء أداة، وخطوة استدلال. تكامل Claude Agent SDK عبر OpenTelemetry يوفر لك زمن استجابة P99 على استدعاءات الأدوات، وميزانيات التوكن لكل جلسة، وتنبيهات على الحلقات التي تتجاوز حدود التكلفة. هذا هو القياس عن بعد المفقود: أي استدعاءات الأدوات بطيئة، أي بوابات الموافقة هي عنق الزجاجة، أين تحدث عواصف إعادة المحاولة، وكم يكلف كل فترة خمول بالفعل.

لنجعل هذا ملموسًا. وكيل برمجة إنتاجي: ينفذ 40 مهمة يوميًا، كل مهمة تتضمن حوالي 12 استدعاء أداة، متوسط وقت استجابة الأداة 3 ثوانٍ، مهمتان يوميًا تصلان إلى بوابة موافقة بشرية (متوسط 15 دقيقة)، وثلاث مهام تصل إلى حدود المعدل (متوسط تأخير: 12 ثانية لكل إعادة محاولة، 3 إعادة محاولات).

• بدون التنفيذ الدائم: وقت انتظار الأدوات: 40 مهمة × 12 استدعاء × 3 ثوانٍ = 24 دقيقة/يوم من الانتظار الخالص. بوابات الموافقة: 2 × 15 دقيقة = 30 دقيقة/يوم. تأخيرات حدود المعدل: 3 مهام × 3 إعادة محاولات × 12 ثانية = 108 ثوانٍ. إجمالي الحوسبة الخاملة يوميًا: حوالي 56 دقيقة – كلها تُحاسب بأسعار العمليات النشطة. عند توسيع ذلك إلى 20 وكيلًا، يصبح لديك 18.7 ساعة من وقت الخمول المدفوع يوميًا.
• مع التنفيذ الدائم: انتظارات الأدوات التي تقل عن 5 ثوانٍ: تتم معالجتها داخليًا (لا تستحق تكلفة النقطة المرجعية). بوابات الموافقة: يتم تعليقها إلى صفر حوسبة. استئناف عند الويبهوك. التكلفة: 0 دولار. تأخيرات حدود المعدل التي تزيد عن 5 ثوانٍ: يتم تعليقها. استئناف عند المؤقت. التكلفة: 0 دولار. وقت الحوسبة الخامل الملغي: حوالي 32 دقيقة/يوم لكل وكيل (بوابة الموافقة + إعادة المحاولات الطويلة).

عند التسعير السحابي النموذجي، هذا هو الفرق بين "الوكلاء باهظون جدًا لأي شيء عدا العروض التوضيحية" و"الوكلاء يدفعون ثمن أنفسهم". النقاشات في Hacker News حول "تحسين 15 نموذج LLM للبرمجة في فترة ما بعد الظهيرة – تغيرت الوحدة فقط" بلورت الإجماع: يشكل النموذج ووحدة التحكم الخاصة به "نظامًا سيبرنيًا كاملًا من حلقات التغذية الراجعة" حيث "يمكن لوحدة التحكم أن تحدث فرقًا كبيرًا، إن لم يكن أكبر، عند تحسينها، مثل التحسينات على النموذج نفسه". بينما ركزت نقاشات أخرى على متطلبات الوكلاء طويلي الأمد وأهمية بقاء حالة التنسيق خارج أي بيئة معزولة. وقد لخص Naval على X هذا التقارب بالقول: "وحدة تحكم وكيل تلعب الألعاب، وتكتب الكود، وتفكر كفيزيائي، وتشبع معيار ARC-AGI-3" – مما يؤكد أن وحدة التحكم هي الآن السطح المنتج، وليست النموذج بداخلها. ومع ذلك، هناك رأي معاكس: التنفيذ الدائم يضيف تعقيدًا تشغيليًا حقيقيًا – إصدارات سير العمل، دلالات إعادة التشغيل، تسلسل الحالة، تطور المخطط. بالنسبة للفرق التي تدير أقل من حوالي 50 وكيلًا متزامنًا، قد تكلف النفقات الهندسية لـ Temporal أكثر في ساعات المطور من الحوسبة الخاملة التي توفرها. نقطة التعادل ليست صفرًا.

رؤية Glitch4Techs

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