المدفوعات الوكيلية تحت سياسة بشرية

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

ولهذا لم يكن السؤال المهم يوماً هو هل ستنفق الوكلاء المال، فهي قادرة على ذلك الآن. السؤال هو من يضع القواعد التي تنفق بموجبها، وهل تفرض المنصة هذه القواعد أم يكتفي الوكيل بالتعهد بها.

نمط الفشل واضح، وهذا هو المقصود

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

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

السياسة هي المنتج، لا الموجِّه

نموذج الاحتواء هو سياسة تفرضها المنصة قبل تحريك المال، لا بعد أن يقرر الوكيل. يحصل كل وكيل على سقف لكل معاملة وحد يومي، هما €150.00 للدفعة و€500.00 لليوم في سياسة العرض التجريبي، وفوقهما سقف شهري قدره €6,000.00. هذه جدران صلبة تتحقق منها المنصة، لا وعود يلتزم بها الوكيل. وحين حاول وكيل السفر في العرض استئجار رحلة بمبلغ €640.00، رُفضت الدفعة فوراً لتجاوز السقف، قبل أن يتحرك سنت واحد. فوكيل يتصرف بشكل مثالي كل يوم لا يستطيع مع ذلك أن يتجاوز ما يسمح به الشهر.

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

السؤال ليس هل سينفق وكيل الذكاء الاصطناعي المال، بل من كتب القواعد التي ينفق بموجبها، ويجب أن يكون الجواب دائماً إنساناً، مسبقاً، وكتابةً.

إنسان فوق الخط

بعض القرارات أكبر من أن تُترك لصندوق. لذلك تتضمن السياسة عتبة: مبلغاً محدداً يجب أن يوافق إنسان فوقه قبل تنفيذ الدفعة. في العرض التجريبي يقع الخط عند €100.00. وحين أشار Ops Agent إلى الفاتورة #088 من Nord Logistics بمبلغ €120.00، وهي ضمن ميزانيته اليومية البالغة €500.00 لكنها فوق خط الموافقة، لم يدفع. توقف، وعرض المقترح على شخص، وانتظر. ردّ من سطر واحد أجازها، وتمت تسوية الدفعة بالمرجع 9F21-0716 وسُجلت في سجل التدقيق عند 09:41. تحت الخط يتحرك الوكيل وحده، وفوقه يجيب شخص أولاً.

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

مفتاح إيقاف وسجل لا يُعدَّل خفية

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

ثانيًا، سجل تدقيق للإضافة فقط (append-only). كل قرار مسجَّل: ما حاوله الوكيل، وأي فحص للسياسة نجح أو فشل، ومن وافق على ماذا، وصولًا إلى تدوير المفاتيح. سجل واحد يعيد بناء عملية دفع كاملة — القرار DEC-4471 يعرض الطلب، وكل فحص للسياسة مع نتيجته (قائمة السماح: ناجح، الحد الأقصى: ناجح، العتبة: تصعيد)، والتوقيع البشري، والمبلغ المسوّى مع قناته ومرجعه. يحمل كل إدخال تجزئته الخاصة وتجزئة الإدخال السابق وموضعه في السلسلة — #4,471 في العرض التجريبي — لذا فتعديل أي حقل يكسر كل سجل يليه. يُصدَّر السجل بصيغة JSON مع التجزئة: هو لك لتسلّمه إلى المدقق، لا لنا لنحتفظ به.

أبقِ التسوية مملّة، وأبقِ الابتكار في التفويض

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

هذا الفصل مقصود. القنوات المملّة يمكن التنبؤ بسلوكها، وقابلة للاسترداد حيث تسمح المنظومة، ومفهومة لدى كل خزينة ومدقق ستتعامل معهم. وضع الجِدّة في السياسة وإبقاء الدفعة على قناة مستقرة يعني أن الجزء المحفوف بالمخاطر وسريع التغيّر هو الجزء الذي تتحكم فيه بالكامل، وأن الجزء الذي يلامس بنوك الآخرين لا يحتاج أحد إلى إعادة تعلّمه. ينفق الوكلاء من النواة نفسها التي تعمل عليها بقية عائلة المدفوعات — الموصوفة في /products/pay — لا من عالم موازٍ بُني للروبوتات.

مشهد البروتوكولات لم يستقر بعد — ابنِ على هذا الأساس

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

عمليًا يعني ذلك سطح تكامل صغيرًا ومملًّا. يتصل الوكلاء عبر MCP على mcp.protocore.io/agents؛ وأي إطار يتحدث هذا البروتوكول يمكنه حمل محفظة. الواجهة ضيقة عن قصد — اقتراح دفعة، واستلام قرار — لأن المنطق المهم يقع في المنصة لا في الـ prompt. وحين تستقر الصناعة على كيفية إثبات الوكلاء لأنفسهم أمام التجار، تتغير الواجهة الأمامية وتبقى الجدران خلفها حيث كانت تمامًا.

أين يقف هذا

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