طبقة الدفع التي كانت غائبة عن وكلاء الذكاء الاصطناعي المستقلين

كيف تبدو التجارة بين الوكلاء في الواقع على أرض الواقع

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

هذه ليست مشكلة تكوين. إنها ليست مشكلة هندسة سريعة. إنها مشكلة بنية تحتية، وحتى أبريل 2026، لم يحلها أحد على مستوى البنية التحتية الجاهزة للإنتاج.

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

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

تنشر TFSF Ventures اليوم بروتوكول الدفع REAP — مواصفات فنية جاهزة للإنتاج لطبقة الدفع المفقودة.

بيئة التشغيل التي تخدمها هذه البنية التحتية

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

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

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

هذه هي بيئة التشغيل. يجب بناء البنية التحتية للدفع لهذه البيئة، وليس تكييفها من بنية تحتية بنيت لشيء آخر.

مشكلة الترخيص أصعب مما تبدو عليه

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

وضع الفشل الأول هو التزامن. عندما يطلب 15 وكيلاً في نفس المنظمة معاملات متزامنة مقابل ميزانية شهرية مشتركة قدرها 10,000 دولار، ويقرأ كل وكيل إجمالي الإنفاق الحالي قبل تقديم طلبه، يمكن لوكيلين قراءة 9,800 دولار تم إنفاقها، وكلاهما يحسب أن طلبه البالغ 150 دولاراً يقع ضمن الحد، وكلاهما يحصل على ترخيص، وينتهي الإنفاق الفعلي عند 10,100 دولار. لم تفرض ميزانيتك. لقد أنشأت حالة سباق. يتطلب إصلاح هذا أقفالاً استشارية على معرفات الوكيل والمنظمة التي تسلسل طلبات الترخيص، بحيث يقرأ ترخيص واحد فقط إجمالي الإنفاق ويحدثه في كل مرة. ليس من الصعب تنفيذ هذا بمجرد معرفة وجود وضع الفشل، ولكن اكتشافه في نشر إنتاجي بقيمة 10,000 دولار لكل معاملة ليس أمراً جيداً.

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

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

ينتج كل رفض رمز سبب منظم. تم تعريف اثني عشر رمزًا: no_policy (لا توجد سياسة)، policy_exceeded (تجاوز السياسة)، budget_exceeded (تجاوز الميزانية)، counterparty_blocked (الطرف المقابل محظور)، counterparty_not_approved (الطرف المقابل غير معتمد)، category_restricted (الفئة مقيدة)، insufficient_balance (رصيد غير كاف)، compliance_fail (فشل الامتثال)، human_required (يتطلب تدخل بشري)، human_denied (تم الرفض من قبل بشري)، system_error (خطأ في النظام)، و payment_hold (تعليق دفع). رمز السبب ليس إدخال سجل. إنه إشارة تشغيلية تعود إلى النظام — رفض budget_exceeded على نطاق واسع يؤدي إلى مراجعة للسياسة، ورفض compliance_fail يؤدي إلى تدقيق قضائي، ونمط human_denied يؤدي إلى مراجعة لمعايرة عتبة التصعيد.

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

فصل نهائية الدفع عن تأكيد التسليم

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

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

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

ثم ينتقل الضمان عبر خمس حالات محددة: HELD (محتجز)، RELEASED (محرر)، EXPIRED (منتهي الصلاحية)، DISPUTED (متنازع عليه)، و REFUNDED (مسترد). يُسمح بستة انتقالات. ينتقل HELD إلى RELEASED عندما يؤكد وكيل التحقق أو المراجع البشري التسليم. ينتقل HELD إلى EXPIRED عندما تنقضي فترة المهلة دون تأكيد التسليم. ينتقل EXPIRED تلقائياً إلى REFUNDED — لا تتطلب أي إجراء بشري، تعود الأموال إلى الطالب. ينتقل HELD إلى DISPUTED عندما يثير أي من الطرفين نزاعاً. ينتقل DISPUTED إلى RELEASED أو REFUNDED بناءً على نتيجة عملية حل النزاع.

لا يُسمح بأي انتقالات أخرى. لا يوجد مسار من RELEASED إلى DISPUTED. لا يوجد مسار من REFUNDED إلى RELEASED. آلة الحالة ليست مرنة — وهذا عدم المرونة هو بيت القصيد. في نظام يعمل بسرعة آلية عبر آلاف المعاملات، يصبح كل مسار استثناء تتركه مفتوحاً سطح هجوم وكابوس تدقيق.

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

خمس مراحل، ومواعيد نهائية صارمة، ولا حالة تعليق

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

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

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

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

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

طبقة المحاسبة التي تجعل التوسع ممكناً

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

يعمل مدقق المصالحة على جدول يومي آلي في الساعة 03:00 بالتوقيت العالمي المنسق (UTC) ويمكن تشغيله عند الطلب عبر API. يقوم بمطابقة كل دفعة تمت تسويتها مع سجل تسليم الخدمة المقابل لها ويشير إلى التناقضات للمراجعة. تم تعريف ثماني فئات من الشذوذ. تعد المدفوعات الوهمية — الأموال التي تم تحويلها بدون سجل تسليم خدمة مطابق — ذات خطورة حرجة. تعد الخدمات غير المدفوعة — الخدمة المكتملة بدون دفعة مقابلة — عالية الخطورة. تعد اختلافات المبلغ التي تزيد عن انحراف عشرة بالمائة متوسطة الخطورة. تعد تركيز الطرف المقابل الذي يزيد عن أربعين بالمائة من الحجم على طرف مقابل واحد متوسطة الخطورة — يشير هذا النمط إلى مخاطر التبعية التي يجب مراجعتها حتى عندما تكون المعاملات الفردية مشروعة. تعد اختلالات السرعة التي تتجاوز انحرافين معياريين عن المتوسط المتحرك لمدة 30 يومًا عالية الخطورة. يعد انجراف الفئة — ظهور فئات معاملات جديدة بدون تحديثات سياسة مقابلة — منخفض الخطورة. تعد الأنماط عبر التنظيمية التي تشير إلى التحايل المنسق على السياسة حرجة الخطورة. تعد معدلات نزاعات الوكلاء التي تتجاوز خمسة بالمائة عالية الخطورة.

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

البنية التحتية لمعالجة الاستثناءات التي تتطلبها الإنتاج بالفعل

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

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

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

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

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

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

يقوم محرك الرسوم بخصم رسوم المنصة والمعالجة والضمان والرسوم عبر المؤسسية بشكل ذري عند التسوية. يتم إجراء حسابات الرسوم في وقت الترخيص ويتم تنفيذ خصومات الرسوم في نفس المعاملة الذرية مثل ائتمان الطرف المقابل. والنتيجة هي دفتر حسابات تسوية حيث يتطابق كل ائتمان وكل خصم في لحظة التنفيذ.

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

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

تمنع مفاتيح عدم التكرار التي يوفرها العميل الرسوم المكررة عندما تتسبب عمليات إعادة المحاولة عبر الشبكة أو عمليات إعادة إرسال webhook في إرسال نفس المعاملة أكثر من مرة. في نظام موزع حيث يعمل الوكلاء عبر حدود شبكة متعددة، فإن عدم التكرار ليس بنية تحتية اختيارية.

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

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

الامتثال كبنية تحتية، وليس تدقيقًا

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

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

تشمل الولايات القضائية المغطاة حاليًا اللوائح الفيدرالية ولوائح الولايات المتحدة؛ وتوجيهات الاتحاد الأوروبي بما في ذلك GDPR و PSD2 و MiCA و DORA؛ وأطر عمل الإمارات العربية المتحدة بما في ذلك CBUAE و DFSA و ADGM؛ ولوائح أمريكا اللاتينية بما في ذلك البرازيل LGPD و BCB والمكسيك CNBV. يمكن تكوين ولايات قضائية إضافية لكل منظمة دون تغييرات في الكود.

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

ما يفعله 49 وكيلًا في الواقع مع البنية التحتية للدفع

وكلاء الدفع السبعة المذكورون أعلاه — Transaction Authorizer، Settlement Executor، Reconciliation Auditor، Dispute Resolution Manager، Payment Exception Handler، Settlement Operations Manager، Compliance Reporter — ليسوا مستقلين. إنهم مكونات لمنصة Pulse AI، يعملون جنبًا إلى جنب مع 42 وكيل إنتاج آخر عبر وظائف تشمل الاستيعاب والتأهيل، وتوليد المقترحات، وإعداد العملاء، والمراقبة التشغيلية، والامتثال التنبئي، وتشخيصات وقت التشغيل، وعمليات المحتوى.

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

هذا الفصل بين الاهتمامات هو ما يجعل البنية قابلة للتوسيع. مع إضافة منصة Pulse AI لوكلاء — وهي تنمو لتتجاوز 49 — يرث كل وكيل جديد البنية التحتية الكاملة للدفع دون الحاجة إلى أي تكوين خاص بالدفع. يتم تكوين سياسات الإنفاق على المستوى التنظيمي وتتدرج نزولاً. يتم تكوين فحص الامتثال حسب الولاية القضائية ويطبق تلقائيًا على جميع الوكلاء العاملين في تلك الولاية القضائية. تعمل المصالحة يوميًا عبر جميع الوكلاء دون أي تكوين خاص بالوكيل.

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

النشر في بيئة الإنتاج

تم نشر مواصفات بروتوكول الدفع REAP اليوم على github.com/SFOSTER2030/a2a-payment-protocol بموجب ترخيص Apache 2.0. تتضمن المواصفات وثائق OpenAPI 3.1 لجميع 50 مسار API، ومخططات كاملة لجميع 22 نوع حدث webhook، ومراجع SDK في TypeScript و Python، ووثائق تقنية مفصلة عبر 19 وثيقة تغطي كل مكون من مكونات البنية.

التنفيذ خاص ويعمل داخل منصة Pulse AI. جميع نقاط النهاية تمر عبر Pulse API. المواصفات هي العقد — تحدد بالضبط ما يفعله النظام وكيفية التكامل معه. البنية التحتية وراءه هي ملكنا.

يتم نشر البروتوكول في مكدسات العملاء الحالية هذا الربع. تتلقى العديد من بيئات الإنتاج عبر قاعدة عملاء Pulse AI طبقة وكيل الدفع فورًا، وتدمجها مع مهام سير عمل الوكيل الحالية التي كانت تتطلب سابقًا معالجة دفع بشرية.

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

يتوفر عرض توضيحي مباشر للبروتوكول يعمل على قاعدة بيانات حقيقية — معالجة المعاملات، وتنفيذ السيناريوهات بما في ذلك التسوية السعيدة، والضمان المشروط، وتصعيد النزاعات، وخط أنابيب استرداد المبالغ، والمصالحة — على a2ademo.tfsfventures.com. https://youtu.be/GJe1J7SlFcs

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

البنية متعددة المستأجرين التي تجعل نشر المؤسسات ممكنًا

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

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

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

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

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

هذا يغير طريقة عمل تجارة الوكلاء

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

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

بنينا هذا لأننا كنا بحاجة إليه. تعمل منصة Pulse AI على 49 وكيل إنتاج عبر 21 قطاعًا صناعيًا، وكانت مشكلة الدفع حقيقية — ليست نظرية، وليست متوقعة، بل حقيقية. احتاج الوكلاء إلى إجراء المعاملات. البنية التحتية للقيام بذلك بأمان، وبما يتوافق مع الأنظمة، وبسرعة آلية لم تكن موجودة. لذلك بنيناها، وتحققنا منها من خلال 284 اختبارًا واختبار تحميل متزامن لخمسين ممثلًا، ووثقناها عبر 19 مواصفة فنية، واليوم نتيحها.

نحن متحمسون حقًا لما سيأتي بعد ذلك. يتم نشر البروتوكول في مكدسات العملاء الحالية هذا الربع. سيتم إطلاق منتج الدفع المشترك الذي تم بناؤه على هذه البنية التحتية في 1 يونيو. تستمر منصة Pulse AI في النمو — 49 وكيلًا اليوم، والمزيد كل شهر، وكل واحد منهم يرث البنية التحتية الكاملة للدفع من اليوم الأول. كل قطاع جديد ندخله، كل عميل جديد نستقبله، كل وكيل جديد ننشره — طبقة الدفع موجودة بالفعل، وتم التحقق منها بالفعل، وتعمل بالفعل.

المواصفات متاحة للجمهور على github.com/SFOSTER2030/a2a-payment-protocol. الورقة البيضاء متاحة على a2a.tfsfventures.com. العرض التوضيحي المباشر يعمل على a2ademo.tfsfventures.com. تغطي وثائق البنية كل مكون على مستوى التفاصيل المطلوب لتنفيذه أو دمجه أو تقييمه. توثق مواصفات OpenAPI 3.1 جميع مسارات API الـ 50. تقرير التحقق هو سجل عام لـ 284 اختبارًا وكل خطأ تم العثور عليه وإصلاحه قبل الإصدار. لقد نشرنا كل شيء لأننا نعتقد أن هذه البنية التحتية يجب أن تصبح معيارًا، وتتطلب المعايير الشفافية.

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

حول TFSF Ventures

TFSF Ventures FZ-LLC (ترخيص RAKEZ 47013955) هي شركة نشر وكلاء الذكاء الاصطناعي تعمل عبر ثلاثة محاور: البنية التحتية للوكلاء (Agentic Infrastructure)، وسكك الدفع (Payment Rails)، ومحرك المشاريع (Venture Engine). تأسست من قبل ستيفن فوستر بخبرة 27 عامًا في أنظمة الدفع والبنية التحتية للبرمجيات، تنشر TFSF Ventures أنظمة وكلاء الذكاء الاصطناعي الإنتاجية عبر 21 قطاعًا صناعيًا في 30 يومًا. تدير منصة Pulse AI 49 وكيل إنتاج، و93 موصلًا جاهزًا، وقوالب نشر مبنية لعمليات المؤسسات على نطاق واسع. تضمن Ghost Architecture أن تكون TFSF غير مرئية — تظل علامة العميل التجارية هي الواجهة للعملاء دائمًا. عمليات عالمية من رأس الخيمة، الإمارات العربية المتحدة.

قم بإجراء تقييم الذكاء التشغيلي المجاني. أجب عن بعض الأسئلة حول عملك واحصل على مخطط مخصص لنشر الذكاء الاصطناعي في غضون 24 إلى 48 ساعة — توصيات الوكلاء، والبنية، وخارطة طريق خاصة بعملياتك. لا توجد مكالمة مبيعات. لا التزام. مجرد بيانات. ابدأ من https://tfsfventures.com/assessment

نشرت في الأصل على https://tfsfventures.com/blog/the-payment-layer-autonomous-ai-agents-have-been-missing

بقلم TFSF Ventures Research

Originally published on LinkedIn: https://www.linkedin.com/pulse/payment-layer-autonomous-ai-agents-have-been-missing-steven-foster-olbae/