تصميم سير عمل الذكاء الاصطناعي: خمسة أنماط لعمليات الوكلاء متعددة الخطوات

النقاط الرئيسية

• بلغت استدعاءات أدوات MCP عبر OpenAI 98 ضعف مستوى يناير بحلول أغسطس 2026، وتضاعفت أكثر من مرة في أغسطس وحده (AAIF) — طلب مستخدم واحد يطلق الآن سير عمل من استدعاءات عديدة، مما يجعل تصميم سير العمل، لا تصميم الأوامر، هو الانضباط الإنتاجي.
• يتوقع Gartner أن ترتفع تكاليف الاستدلال لكل سير عمل وكيلي بأكثر من خمسة أضعاف حتى 2028 — أسعار التوكن تنخفض بينما ترتفع التكاليف لكل سير عمل، لأن سير العمل الوكيلي يستهلك توكنات بأعداد أضعاف ما تستهلكه المحادثة.
• أعادت خارطة طريق MCP صياغة Tasks بوصفها امتداداً رسمياً (SEP-2663) وأضافت Multi Round-Trip Requests (SEP-2322) لتصمد التدفقات متعددة الخطوات على خوادم عديمة الحالة — البروتوكول يفترض الآن أن العمل يسير طويلاً ويمتد عبر جولات متعددة.
• تصرح OpenAI بأن مراقبات اختلال المواءمة لديها قد توقف مؤقتاً «المهام التي يعمل فيها الوكيل لفترة ممتدة»، ومهام API تتوقف بدل أن تُستأنف — سير العمل الإنتاجي يجب أن يكون قابلاً للاستئناف من حالة دائمة، لا من عملية حية.
• وحدة RFQ بأدوات 38 تشغّل كل هذه الأنماط في الشيفرة — انتقالات حالة تفرضها الحراس (guards)، إطلاق idempotent للحجوزات بمهلة 15 دقيقة، ولقطات FX مجمّدة عند التسعير.

بلغت استدعاءات أدوات MCP لدى مستخدمي ChatGPT 98 ضعف مستوى يناير في أغسطس 2026، وفق تحليل الاستخدام من Agentic AI Foundation — وتضاعفت الاستدعاءات أكثر من مرة خلال أغسطس وحده. ويحكي حركة MCP لدى Resend القصة ذاتها من جهة المزود: 106,719 استدعاءً في أبريل، و1,062,650 في أغسطس. ويسوق صيانة البروتوكول أنفسهم الاستنتاج التشغيلي في خارطة طريق MCP الجديدة: «أحمال العمل الوكيلية الحديثة لم تعد تتسع لنمط الطلب والاستجابة القياسي. يمكن أن تسير الحلقات مدة أطول، ويمكن للخوادم دفع نتائج متدفقة، وهناك حاجة واضحة لتوجيه العمل في منتصف الطيران.»

لم تكن المحادثة يوماً الجزء الصعب. سير العمل هو ذلك: مروحة استعلامات الكتالوجات خلف طلب عرض أسعار واحد، والموافقة التي يجب أن تصل قبل الكتابة في نظام تخطيط الموارد، وAPI المورد الذي تنتهي مهلته منتصف التسعير، وسعر الصرف الذي يجب ألا ينحرف بين التسعير والحجز. يتوقع Gartner أن ترتفع تكاليف الاستدلال لكل سير عمل بأكثر من خمسة أضعاف حتى 2028 حتى مع انخفاض أسعار التوكن، لأن سير العمل الوكيلي يفوض ويتفاوض ويعيد مساءلة نفسه عبر استدعاءات عديدة. تحدد هذه المقالة الأنماط الخمسة على مستوى سير العمل التي تحدد ما إذا كانت عملية الوكيل متعددة الخطوات ستصمد تحت ذلك الحمل — التفريخ، ونقاط الفحص، والتعويض، والحالة الدائمة، والتفرع المقيس — وترسي كل نمط منها في تنفيذ RFQ عامل يسجل 38 أداة MCP أمام واجهة خلفية GraphQL.

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

النمط 1: فحص القراءات بالتوازي، وتسلسل الكتابات

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

سلسلة الكتابة في سير عمل التسعير مرتبة بدقة لسبب تجاري لا تقني: الطلب مؤكد → العرض منشأ → التوفر محجوز → الأقساط مجدولة. يفرض محرك RFQ لدينا ذلك بحراس عمليات في الشيفرة — يرفض RequestOperationGuard إنشاء عروض من طلب غير مؤكد، ويرفض QuoteOperationGuard تعديل البنود بعد تجاوز العرض نافذته القابلة للتحرير. نمط سير العمل نفسه في كل الأنظمة: قراءات متوازية خلف محمّل دفعات، عمود متسلسل ضيق للكتابات التي تغيّر الحالة، والحراس في الشيفرة لا في الأمر. الوكيل الذي «يقرر» الترتيب في كل تشغيل هو سير عمل بلا قواعد ثابتة.

النمط 2: نقاط الفحص البشرية حالات وليست أوامر

يحكم النمط الثاني موضع الإنسان. في تصميم قائم على الأوامر وحدها، «اسأل المستخدم قبل الإرسال» اقتراح قد يتبعه النموذج أو لا يتبعه. في تصميم سير العمل، نقطة الفحص حالة دائمة: يتوقف البرنامج في حالة مسماة، ويخزّن كل ما يلزم للمتابعة، وإنما يدفعه إلى الأمام فعل بشري. صار هذا التمييز ملحاً تشغيلياً في 1 سبتمبر، حين كشفت OpenAI أن مراقبات اختلال المواءمة الإنتاجية لديها يمكنها أن توقف تلقائياً نشاطاً محتملاً غير مصرح به — وأشارت بصدق إلى الكلفة: الضمانات «قد تشير أحياناً إلى نشاط مشروع بوصفه سوء استخدام سيبرانياً محتملاً… قد يشمل ذلك عملاً لا يبدو مرتبطاً مباشرة بالأمن السيبراني أو مهاماً يعمل فيها الوكيل لفترة ممتدة». في ChatGPT وCodex يُطلب من المستخدمين مراجعة المهمة المتوقفة؛ وعلى API تتوقف المهمة.

يعامل سير العمل المبني لتلك الحقيقة التوقف بوصفه حالة مصممة لا استثناءً: سجل التشغيل يبيّن ما اكتمل، وما هو معلّق، وما مسار الاستئناف. أداة الراحة في محرك RFQ لدينا — confirm_request_and_create_quotes وconfirm_quote_and_create_installments — توجدان لأن البوابة البشرية تقع بينهما: يؤكد إنسان، ثم يجري العمل الميكانيكي متعدد الخطوات بوصفه نداءً واحداً مدققاً. وجدت استطلاع Camunda لـ 1,150 من قيادات تقنية المعلومات الكبار أن 71% من المؤسسات تستخدم وكلاء ذكاء اصطناعي لكن 11% فقط من حالات الاستخدام تصل إلى الإنتاج؛ سير العمل الذي يعبر تلك الهوة هو الذي تكون فيه الموافقة حالة يمكن للنظام أن يقبع فيها ساعات، لا جملة في أمر نظام. ميكانيكية فرض نقاط الفحص في طبقة وقت التشغيل تعيش في هندسة الحلقة: لماذا وقت تشغيل الوكيل هو الوسيط البرمجي الجديد؛ ونمط سير العمل هو أن تقرر، قبل أن يُشحن أي شيء، أي الخطوات تتوقف أمام إنسان ومن أي حالة يُستأنف البرنامج.

النمط 3: كل خطوة أمامية تحتاج مسار تعويض

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

يُظهر تنفيذ التسعير تشريح ذلك. تنتهي حجوزات التوفر بمهلة 15 دقيقة، وسطح الفشل مُعدَّد كأخطاء محددة النوع — HOLD_NOT_FOUND وHOLD_ALREADY_EXPIRED وAVAILABILITY_INSUFFICIENT — يُقابل كل منها استرداداً مختلفاً: إعادة فحص، أو إعادة حيازة، أو تصعيد إلى إنسان. إطلاق الحجز idempotent، فلا يستطيع إعادة المحاولة بعد انقسام الشبكة أن يُطلق مرتين، ولا يخصم تأكيد الحجز مرتين قط. تُغلَّف استدعاءات الأدوات بمُزخرف إعادة محاولة بتراجع أسي، وتصل حالة كل استدعاء ومدته وحمولته (تُفرَّغ إلى تخزين كائني فوق 400KB) إلى سجل تدقيق. ذلك هو النمط المعمم: خطوات التقدم تقتنص موارد؛ خطوات التعويض تطلقها؛ وكل تعويض آمن التنفيذ مرتين. إن كان سير عملك لا يستطيع أن يسمي ما يتراجع عن كل خطوة، فليس لديه سير عمل — لديه عرض توضيحي لم يقابل بعد عطلاً لدى مورد.

النمط 4: بروتوكول بلا حالة، سير عمل بحالة

يحل النمط الرابع تناقضاً ظاهرياً في مواصفة MCP بتاريخ 2026-07-28. أزالت المواصفة الجلسات على مستوى البروتوكول ومصافحة التهيئة (SEP-2575، SEP-2567) لتتوسع الخوادم أفقياً دون احتفاظ بالحالة، وأعادت خارطة الطريق صياغة Tasks بوصفها امتداداً رسمياً (SEP-2663) بينما حلّت Multi Round-Trip Requests (SEP-2322) محل الطلبات المبدوغة من الخادم فبقيت تدفقات الاستيضاح تعمل في منتصف المهمة. البروتوكول بلا حالة؛ وسير العمل هو ما يحمل الحالة. وعملياً: يجب أن يصل كل طلب مكتفياً بذاته، وتعيش حالة سير العمل في سجلات دائمة قابلة للتفتيش — لا في ذاكرة خادم.

خيار البنية هذا هو ما يجعل النمط السابق قابلاً للبقاء. في محرك RFQ لدينا، يجلس hold_token وhold_expires_at للحجز مباشرة على بند العرض، ويُجمَّد سعر الصرف بطابع زمني fx_rate_locked_at عند التسعير — لقطات لا مراجع حية. أي نسخة خادم تستطيع أن تستلم الطلب التالي؛ والعملية المعاد تشغيلها تستأنف من السجل لا من الذاكرة. وتجعل تحذير Astra الاستئنافية مطلب تفاعل مع المنصة لا مجرد تسامح مع الانهيار: إن علّقت ضمانة نموذج حدودي تشغيلك غير المراقب لمدة 38 ساعة، فسير العمل الذي ينجو هو الذي أبقى حالته خارج العملية. تغطي آليات نشر المواصفة عديمة الحالة في بروتوكول MCP عديم الحالة: ما الذي يتغير في النشرات B2B؛ وعلى مستوى سير العمل القاعدة بسيطة — صمّم وكأن أي خطوة قد تكون الأخيرة قبل توقف، واجعل الخطوة التالية قابلة لإعادة البناء من أثر التدقيق.

النمط 5: تفرع على بيانات مقيسة لا على تقدير النموذج

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

في محرك RFQ، يحمل كل بند عرض guardrail_price_per_uom وslow_move_item محمّلين من سجل الدفعة — فتقرأ تفريعة «التسعير بسعر القائمة» مقابل «الوسم لمراجعة الهامش» حقلين بدل أن نطلب من النموذج تقدير الهامش. وتتركب قواعد الخصم من أربعة نطاقات هرمية (عام، شريحة، صنف، صنف مزود) بوصفها بيانات لا خطوات استدلال. وهنا أيضاً يلتقي تصميم سير العمل بالتكلفة: تحليل الاستدلال من Gartner يحذر من أن «توجيه مهمة إلى نموذج استدلال وكيلي يزيد تكاليف الاستدلال للمزود خمسة أضعاف على الأقل» مقابل تفاعل أساسي، ويوصي بـ«تقسيم طبقي وتوجيهاً وتنسيقاً عاليَي التحسين للاستدلال». سير العمل الذي يتفرع على وسوم مخزنة يحتفظ باستدلال النموذج للخطوات التي تحتاجه — حكم التسعير، وتفسير الاستثناءات، وصياغة التفاوض — ويترك للبيانات المحددة النوع أن تقرر الباقي. تنطبق الانضباط ذاته على منصات البيانات، حيث تعامل أعمال سياق التنسيق من Dagster أحداث التجسيد بوصفها السياق التشغيلي الذي يستهلكه سير العمل بدل أن يعيد اشتقاقه.

الأنماط الخمسة، كل نمط في سطر

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

بناء تمثيلي

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

قراءات ذات صلة

• معمارية وكلاء الذكاء الاصطناعي: خمسة قرارات تحدد ما إذا كان وكيلك سيصل — القرارات البنيوية (عدد الوكلاء، ملكية الحلقة، توجيه النماذج، الحدود، التنسيق الناشئ) التي تؤطر أنماط سير العمل التي تحتاجها
• هندسة الحلقة: لماذا وقت تشغيل الوكيل هو الوسيط البرمجي الجديد — ميكانيكية وقت التشغيل خلف النمطين 2 و5: موافقات وإعادة محاولة وتحقق بمقياس تقدير تُفرض في الحلقة
• أنماط الوكلاء طويلي الأمد: إبقاء الوكلاء أحياء عبر ساعات وأيام — تفاصيل الاستمرارية ونقاط الفحص خلف النمط 4، بما فيها خطر التوقف بالضمانات الجديد للأشغال الممتدة

---

الفريق الذي يقدر أن يرسم سير عمله — التفريخ والبوابات والتعويضات والحالة — يعرف مسبقاً ما سيبنيه. والفريق الذي لا يستطيع سيكتشف التصميم عطلاً لدى مورد يتبع عطلاً.

اطلب بناءً بنطاق محدد. استكشاف من أسبوع واحد. تحصل على جرد أنظمة وخريطة سير عمل ونطاق ثابت — سواء بنيتم معنا أم لا.