تخيل مهمة توضيحية في المتصفح تتألف من مئة خطوة. افترض أن كل خطوة تنجح بنسبة 99%، مستقلة عن غيرها. احتمال نجاح كل الخطوات هو 0.99^100، أي نحو 36.6%.
تبدو نسبة 99% ممتازة. أما 36% فلا تبدو كذلك.
تستخدم مناقشة العمل المعاملاتي في المتصفح هذا الحساب لتوضيح فكرة محددة: لا يحصل العميل على القيمة إلا حين تكتمل المهمة، بينما تتراكم التكلفة واحتمالات الإخفاق عند كل خطوة. إنه حساب قائم على افتراض، وليس معدل نجاح منشوراً لأي وكيل متصفح أو مزامنة في Tajo. وقد ترتبط الأخطاء الفعلية بعضها ببعض؛ فانتهاء صلاحية تسجيل دخول واحد قد يعطل عدة إجراءات لاحقة دفعة واحدة.
لذلك ليس السؤال المفيد: «ما مدى دقة نقرة النموذج الأخيرة؟» بل: «هل تحققت الحالة التي طلبها المستخدم؟»
المعاملة الكاملة هي وحدة القياس
تخيل وكيلاً يفتح بوابة تأمين، ويعثر على مستند وينزله، ثم يتأكد من أنه يخص الحساب الصحيح. قد يتنقل بين 99 شاشة على نحو صحيح، ثم ينزل الملف الخطأ في الشاشة المئة. سجل مليء بالنقرات الناجحة لا يصلح النتيجة.
وينطبق الفرق نفسه على التكامل. يستطيع الوكيل اكتشاف واجهة API، واقتراح ربط بين الحقول، وحفظ مسودة. لا يعني أي من ذلك أن جهة الاتصال في النظام الوجهة أصبحت تحمل حالة الموافقة المقصودة. لا يكتمل العمل إلا بعد تنفيذ العملية المعتمدة والتحقق من شرطها النهائي ذي الصلة.
هذا هو الفرق بين النشاط والإنجاز. يسهل عد النشاط، لكن الإنجاز يحتاج إلى تعريف.
في تنزيل ملف، قد يكون الدليل مستنداً يطابق رقم حسابه الطلب. وفي مزامنة جهة اتصال، قد يكون سجلاً في الوجهة يحمل المعرف والحقول الصحيحين وحالة المراسلة المسموح بها. يجب أن يفحص التحقق الشيء الذي يهم المستخدم. فالاستجابة الناجحة من الاستدعاء السابق دليل على عودة الاستدعاء، لكنها ليست بالضرورة دليلاً على أن الوجهة تغيرت كما ينبغي.
يبدأ دليل Tajo لربط أدوات العمل بسير العمل ومصدر الحقيقة لكل كائن بيانات. بهذه القرارات يكتسب التحقق الأخير معناه. إذا ادعى نظامان امتلاك الحقل نفسه، فقد ينتج عن عملية كتابة منفذة بإتقان وضع خاطئ على المدى الطويل.
تكلفة قرار إضافي
بموجب افتراض النجاح نفسه، أي 99% لكل قرار مستقل، تبلغ فرصة نجاح السلسلة كاملة نحو 90.4% لعشرة قرارات، و60.5% لخمسين قراراً، و36.6% لمئة قرار.
احتمال نجاح السلسلة كاملة (%)
عدد الخطوات المستقلة
- نجاح مفترض بنسبة 99% لكل خطوة
اقرأ القيم المحسوبة
| الخطوات | نجاح السلسلة كاملة (%) |
|---|---|
| 0 | 100.0 |
| 10 | 90.4 |
| 25 | 77.8 |
| 50 | 60.5 |
| 75 | 47.1 |
| 100 | 36.6 |
ينحدر المنحنى بسرعة لأن الضرب لا يجامل المتوسط الجيد. ينبغي أن تبرر كل خطوة قرار إضافية وجودها.
لا يعني ذلك جمع كل استدعاءات API في عملية واحدة ضخمة. بعض الاستدعاءات حتمية: جلب صفحة بمؤشر معروف، أو مقارنة معرف، أو كتابة حقل وفق ربط معتمد. لا يحتاج النموذج إلى إعادة اتخاذ القرار لكل سجل. في المقابل، تنطوي حالات أخرى على غموض حقيقي: حقل جديد لدى مزود الخدمة، أو رسالة خطأ متغيرة، أو طلب لا يُعرف صاحبه. وقد تحتاج هذه الحالات إلى حكم.
التقسيم العملي هو أن يصمم الحكم قاعدة أو يصلحها، ثم يطبقها الكود المعتاد ما دامت مستقرة. يقدم عكس ETL مثالاً على نقل البيانات المتكرر: ينبغي أن ينفذ خط المعالجة العمليات الروتينية لكل صف، لا محادثة جديدة. ومع ذلك يمكن للوكيل المساعدة في تقرير ما يجب أن يفعله الخط.
هذا حد عمل، وليس شعاراً. إذا غيّر مزود الخدمة معنى حقل، فقد تكرر القاعدة الحتمية الإجراء الخاطئ بإتقان. يحتاج النظام إلى طريقة تكشف تغير افتراضاته وتعيد الحالة للمراجعة.
لماذا ليست أداة واحدة كبيرة هي الحل
قد يعترض أحدهم بحق: «إذا كانت السلاسل الطويلة تتعطل، فلنضع المهمة كلها خلف استدعاء أداة واحد». يساعد ذلك حين تكون الأداة معاملة محددة جيداً ويمكن التحقق من نتيجتها. أما إذا أخفت عملية طويلة وغير يقينية فحسب، فلا تحل المشكلة.
افترض أن syncCustomer() يعيد success: true بعدما يرسل تحديثاً. إذا كانت الوجهة تعالج التحديثات لاحقاً، فلا يستطيع الاستدعاء في هذه اللحظة إثبات الحالة النهائية لجهة الاتصال. انخفض عدد الخطوات الظاهرة، لكن عدم اليقين لم ينخفض.
الواجهة الأفضل تعرض الحالة المهمة: مقبول، أو مطبق، أو متحقق منه، أو فاشل. وينبغي أن يقابل كل لفظ دليل. قد يكفي قبول الكتابة لمعاينة قليلة الأثر. أما تغيير جمهور حملة أو حالة موافقة فيستحق فحص الوجهة قبل اعتباره منجزاً.
في عرض Tajo المقترح، يختلف قبول الطلب وتطبيق التحديث عن التحقق من حالة الوجهة. الفحص الأخير ما زال معلقًا. لذلك فالخطوة التالية محددة: افحص ما خزنته الوجهة. احتساب استدعاء ناجح آخر لا يجيب عن السؤال الأصلي.
حتى الكتابة المكتملة تحتاج إلى دليل
هل انتهت مزامنة العملاء؟
طُبقت الكتابة. التحقق معلّق.
لم تُفحص حالة الوجهة بعد.
نشاط المزامنة
- قُبل الطلب
- طُبق التحديث
- فحص الوجهة معلّق
تشغيل توضيحي · 14:32 UTC
ما نعرفه
- رد المزوّد
- مقبول
- نتيجة الكتابة
- مطبّق
- قراءة حالة الوجهة
- معلّق
نجاح الاستدعاء لا يثبت الحالة النهائية.
تصميم مقترح يستند إلى سجل النشاط في Tajo. يضيف هذا الرسم حالة تحقق، ولا يدّعي أن قراءة الوجهة بعد الكتابة مطبّقة بالفعل.
وهذا يغير ما نقيسه أيضاً. سجل عدد المحاولات إذا ساعد على تشخيص التكلفة، والأخطاء الوسيطة إذا دلت على خطوة معطلة. لكن احكم على سير العمل بعدد المعاملات المنجزة والمتحقق منها، مع توضيح طريقة التحقق بجانب الرقم. تقرير يقول «نجح 99% من الاستدعاءات» لا يجيب عما إذا أنجز العملاء عملهم.
يوضح شرح خادم MCP كيف تتيح الأدوات للمساعد استدعاء نظام آخر. الوصول إلى الأداة ليس إلا البداية؛ والعبرة بالحالة التي تتركها وراءها.
قد لا تترك مئة نقرة صحيحة أي نتيجة. احسب ما تحقق فعلاً.
الأسئلة المتكررة
لماذا يفشل سير عمل طويل رغم أن خطواته صحيحة عادة؟
إذا نجحت كل خطوة مستقلة باحتمال p، فإن احتمال نجاح سلسلة من n خطوات هو p مرفوعاً إلى n. وبافتراض 99% لكل خطوة، تكتمل سلسلة من مئة خطوة بنسبة تقارب 36.6%. وقد ترتبط الإخفاقات الحقيقية، لذا فهذا مثال لا معدل نجاح مقاس لوكيل.
هل يضمن تقليل استدعاءات الأدوات موثوقية أعلى؟
لا. يفيد تقليلها فقط إذا أبقت العملية المجمعة نقاط التحقق والتعافي المناسبة. وقد يخفي استدعاء واحد مبهم كتابة فاشلة كما قد تضيع سلسلة طويلة موضعها.
ماذا ينبغي أن يقيس الفريق في سير عمل الوكيل؟
قس إنجاز معاملة المستخدم بعد التحقق، لا نجاح استدعاءات النموذج فقط. حدد المستند أو حالة الوجهة التي تثبت انتهاء العمل، ثم سجل معدل ظهورها بعد سير العمل كله.