لایه پرداختی که عامل‌های هوش مصنوعی خودمختار از آن محروم بوده‌اند

تجارت عامل به عامل در عمل چگونه به نظر می‌رسد

هر شرکتی که عامل‌های AI را در تولید اجرا می‌کند، به همان دیوار برخورد کرده است. عامل‌ها می‌توانند تحقیق کنند، پیش‌نویس تهیه کنند، تحلیل کنند، مسیردهی کنند، برنامه‌ریزی کنند و ارتباط برقرار کنند. آن‌ها می‌توانند گردش کارهای چند مرحله‌ای را در ده‌ها سیستم ترکیب کرده و آن‌ها را سریع‌تر از هر تیم انسانی اجرا کنند. اما لحظه‌ای که آن عامل‌ها نیاز به پرداخت چیزی دارند — پرداخت به یک عامل طرف مقابل برای کار تکمیل شده، پرداخت به یک فروشنده داده برای یک فید بلادرنگ، پرداخت به یک سرویس تطبیق‌پذیری برای بررسی صلاحیت — کل معماری فرو می‌ریزد. یک انسان باید درگیر شود. حلقه خودمختار شکسته می‌شود. کارایی که در وهله اول استقرار عامل‌ها را توجیه می‌کرد، در مهم‌ترین لحظه از بین می‌رود.

این یک مشکل پیکربندی نیست. این یک مشکل مهندسی prompt نیست. این یک مشکل زیرساختی است، و تا آوریل 2026، هیچ کس آن را در سطح معماری تولیدی حل نکرده بود.

یک مقاله Systematization of Knowledge که این ماه منتشر شد (arXiv:2604.03733) زبان رسمی را برای آنچه اپراتورها سال‌ها به صورت تجربی تجربه کرده‌اند، ارائه داد. این مقاله آنچه را که "هزینه خودمختار واگذار شده" می‌نامد، به عنوان یک دسته ریسک جدید تعریف می‌کند — ریسکی که هر فرضیه سنتی را که صنعت پرداخت بر آن بنا شده است، می‌شکند: اینکه کسی روی دکمه‌ای کلیک کرده، کسی تراکنش را بررسی کرده، کسی مسئول تصمیم تطبیق‌پذیری بوده است. در تجارت عامل خودمختار، هیچ یک از این فرضیه‌ها برقرار نیست. این مقاله شکست را در یک چرخه حیات چهار مرحله‌ای ترسیم می‌کند. Discovery — چگونه عامل‌ها خدمات و طرف‌های مقابل را پیدا می‌کنند. Authorization — چگونه هزینه‌ها بدون حضور انسان در نقطه تصمیم‌گیری تأیید می‌شوند. Execution — چگونه پول جابجا می‌شود و چگونه تأیید پرداخت از تأیید تحویل جدا می‌شود. Accounting — چگونه سازمان تأیید می‌کند که آنچه پرداخت شده، واقعاً تحویل شده است، در هر مقیاسی، بدون نیاز به تیمی از حسابرسان.

زیرساخت پرداخت سنتی برای تراکنش‌های آغاز شده توسط انسان ساخته شده بود. آزمایش‌های تسویه حساب مبتنی بر بلاکچین به اجرای قابل برنامه‌ریزی می‌پردازند اما فاقد لایه سیاست‌گذاری مجوز، اسکن تطبیق‌پذیری قبل از تراکنش، و چارچوب تطبیق هستند. پرداخت مصرف‌کننده که برای خریدهای آغاز شده توسط عامل تطبیق داده شده است، تجارت عامل به انسان را حل می‌کند. اما برای تجارت عامل به عامل در سیستم‌های سازمانی — عامل‌های خودمختار که برای خدمات به یکدیگر پرداخت می‌کنند، تحت حاکمیت سیاست‌های قابل اجرا توسط ماشین، با اسکرو مشروط، اسکن تطبیق‌پذیری، و تطبیق خودکار — کاری انجام نمی‌دهد. این‌ها مشکلات متفاوتی هستند که به زیرساخت‌های متفاوتی نیاز دارند.

امروز TFSF Ventures پروتکل پرداخت REAP را منتشر می‌کند — یک مشخصات فنی در سطح تولید برای لایه پرداخت گم شده.

محیط عملیاتی که این زیرساخت به آن خدمت می‌کند

قبل از پرداختن به معماری، ارزش دارد محیط عملیاتی که این زیرساخت باید به آن خدمت کند را توضیح دهیم، زیرا این محیط بسیار پر تقاضاتر از آن چیزی است که اکثر طراحان سیستم‌های پرداخت با آن مواجه شده‌اند.

یک صندوق سرمایه‌گذاری خصوصی که عامل‌های AI را در 30 شرکت پرتفوی اجرا می‌کند، هفته‌ای چندین هزار تراکنش خودمختار تولید می‌کند. برخی از این تراکنش‌ها در داخل یک شرکت پرتفوی واحد اتفاق می‌افتند — یک عامل تحقیق که برای یک دسته تحلیل بازار به یک عامل داده پرداخت می‌کند. برخی در سراسر مرزهای سازمانی اتفاق می‌افتند — یک عامل تطبیق‌پذیری در سطح صندوق که به یک سرویس اطلاعات نظارتی شخص ثالث پرداخت می‌کند. برخی شامل تحویل مشروط هستند — یک عامل مهندسی که پرداخت به یک عامل پیمانکار را تنها پس از تأیید یک عامل بررسی کد مبنی بر مطابقت خروجی با مشخصات، مجاز می‌داند. برخی نیاز به تشدید انسانی دارند — هر تراکنش بالای یک آستانه دلاری پیکربندی شده نیاز به تأیید یک شریک قبل از اجرا دارد. برخی نیاز به اسکن نظارتی قبل از تراکنش دارند — یک پرداخت که از طریق حوزه‌های قضایی خاصی مسیریابی می‌شود، قبل از اعتبارسنجی تراکنش، بررسی‌های تطبیق‌پذیری GDPR، PSD2 یا CBUAE را آغاز می‌کند.

همه این‌ها به صورت مداوم، با سرعت ماشین، بدون اینکه انسان‌ها تراکنش‌های فردی را آغاز کنند، اتفاق می‌افتد. اعتبارسنجی، اجرا، و حسابداری همه باید در اولین بار، هر بار، به درستی کار کنند، با قابلیت حسابرسی کامل و تحمل صفر برای شرایط رقابتی که وقتی ده‌ها عامل به طور همزمان درخواست تراکنش در برابر pools بودجه مشترک را دارند، پدیدار می‌شوند.

این محیط عملیاتی است. زیرساخت پرداخت باید برای این محیط ساخته شود، نه اینکه از زیرساختی که برای چیز دیگری ساخته شده است، تطبیق داده شود.

مشکل مجوز سخت‌تر از آن چیزی است که به نظر می‌رسد

اولین غریزه هنگام تفکر در مورد کنترل‌های هزینه عامل خودمختار، اعمال سقف‌های بودجه ساده است. به هر عامل یک محدودیت ماهانه بدهید و قبل از اعتبارسنجی، موجودی را بررسی کنید. این در تولید به دلایلی که تنها زمانی که آن را در مقیاس اجرا می‌کنید آشکار می‌شود، شکست می‌خورد.

اولین حالت خرابی، concurrency (همزمانی) است. وقتی 15 عامل در یک سازمان به طور همزمان درخواست تراکنش در برابر بودجه ماهانه مشترک 10,000 دلاری را دارند، و هر عامل قبل از ارسال درخواست خود، کل هزینه فعلی را می‌خواند، دو عامل می‌توانند هر دو 9,800 دلار خرج شده را بخوانند، هر دو محاسبه کنند که درخواست 150 دلاری آن‌ها در محدوده قرار می‌گیرد، هر دو مجوز بگیرند، و هزینه واقعی به 10,100 دلار می‌رسد. شما بودجه خود را اعمال نکرده‌اید. شما یک race condition (شرط رقابت) ایجاد کرده‌اید. رفع این مشکل نیاز به قفل‌های مشورتی بر روی شناسه‌های عامل و سازمان دارد که درخواست‌های اعتبارسنجی را سریال‌سازی می‌کنند، به طوری که تنها یک اعتبارسنجی در هر زمان کل هزینه را می‌خواند و به‌روزرسانی می‌کند. این کار به محض اینکه از وجود حالت خرابی مطلع شوید، دشوار نیست، اما کشف آن در یک استقرار تولیدی با 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. یک کد دلیل یک ورودی log نیست. این یک سیگنال عملیاتی است که به سیستم بازخورد می‌دهد — یک رد شدن budget_exceeded در مقیاس، بررسی سیاست را آغاز می‌کند، یک رد شدن compliance_fail، حسابرسی صلاحیت را آغاز می‌کند، یک الگوی human_denied، بررسی کالیبراسیون آستانه تشدید را آغاز می‌کند.

یکی از ویژگی‌های خط لوله اعتبارسنجی که در سیستم‌های پرداخت انسانی معادل ندارد، policy snapshotting است. هنگامی که یک تصمیم اعتبارسنجی گرفته می‌شود، وضعیت دقیق سیاست هزینه‌کرد قابل اجرا — هر پارامتر، هر مقدار پیکربندی شده — در سابقه اعتبارسنجی ثبت می‌شود. اگر سیاست متعاقباً تغییر یابد، مسیر حسابرسی همچنان قوانین را که در زمان تصمیم‌گیری اعمال می‌شدند، منعکس می‌کند. این امر در محیط‌های نظارتی که نیاز به اثبات دارید که یک تراکنش در برابر مجموعه خاصی از کنترل‌ها مجاز شده است، نه فقط اینکه کنترل‌ها در آن زمان وجود داشته‌اند، اهمیت دارد.

جداسازی نهایی شدن پرداخت از تأیید تحویل

مشکل مرحله اجرا در درجه اول مربوط به جابجایی پول نیست. جابجایی پول یک مشکل حل شده است. مشکل حل نشده، تأیید این است که طرف مقابل واقعاً آنچه را که برای آن پرداخت شده بود تحویل داده است، و ساخت زیرساختی برای نگهداری مشروط وجوه تا زمانی که این تأیید امکان‌پذیر باشد.

در تجارت انسانی، یک قرارداد و یک سیستم حقوقی این عملکرد را به طور ناقص ارائه می‌دهند. در تجارت عامل، شما به چیزی نیاز دارید که با سرعت ماشین، بدون وکیل، عمل کند و نتایج قطعی تولید کند که به طور خودکار به لایه حسابداری بازگردانده شود.

این پروتکل این کار را از طریق اسکرو مشروط با یک ماشین حالت متناهی انجام می‌دهد. هنگامی که یک تراکنش برای تسویه حساب اسکرو علامت‌گذاری می‌شود — تراکنش‌های بین سازمانی، توافق‌نامه‌های خدمات با ارزش بالا، هر تراکنشی که در آن تأیید تحویل مورد نیاز است — وجوه در زمان اعتبارسنجی در اسکرو قفل می‌شوند. موجودی نگه‌داشته شده عامل درخواست‌کننده افزایش می‌یابد؛ موجودی در دسترس آن کاهش می‌یابد. وجوه نمی‌توانند برای تراکنش‌های دیگر استفاده شوند.

سپس اسکرو از پنج حالت تعریف شده عبور می‌کند: HELD، RELEASED، EXPIRED، DISPUTED، و REFUNDED. شش انتقال مجاز است. HELD به RELEASED تغییر می‌کند زمانی که یک عامل تأیید یا بازبین انسانی تحویل را تأیید می‌کند. HELD به EXPIRED تغییر می‌کند زمانی که دوره زمانی با عدم تأیید تحویل به پایان می‌رسد. EXPIRED به طور خودکار به REFUNDED تغییر می‌کند — نیازی به اقدام انسانی نیست، وجوه به درخواست‌کننده بازگردانده می‌شوند. HELD به DISPUTED تغییر می‌کند زمانی که هر یک از طرفین اختلافی را مطرح کند. DISPUTED بر اساس نتیجه فرآیند حل اختلاف به RELEASED یا REFUNDED تغییر می‌کند.

هیچ انتقال دیگری مجاز نیست. مسیری از RELEASED به DISPUTED وجود ندارد. مسیری از REFUNDED به RELEASED وجود ندارد. ماشین حالت انعطاف‌پذیر نیست — و این انعطاف‌ناپذیری نقطه اصلی است. در سیستمی که با سرعت ماشین در هزاران تراکنش عمل می‌کند، هر مسیر استثنایی که باز می‌گذارید به یک سطح حمله و یک کابوس حسابرسی تبدیل می‌شود.

ثابت نامتغیری که این کار را در مقیاس ممکن می‌سازد، یک معادله تعادلی است که باید در هر تغییر حالت برقرار باشد: موجودی در دسترس یک کیف پول به علاوه موجودی نگه‌داشته شده آن همیشه باید برابر با کل وجوه آن باشد. این امر در تراکنش‌های اتمی پایگاه داده در هر انتقال حالت اسکرو، با استفاده از دقت عددی صریح برای جلوگیری از رانش نقطه شناور که در توالی‌های تراکنش با حجم بالا جمع می‌شود، اعمال می‌شود. تست بار با پنجاه بازیگر همزمان، هفت race condition را در مرزهای حالت اسکرو شناسایی کرد که همه قبل از انتشار پروتکل رفع شدند.

پنج مرحله، مهلت‌های سخت، بدون بلاتکلیفی

اختلافات در سیستم‌های پرداخت سنتی به کندی، پرهزینه بودن و حل نشده بودن معروف هستند. فرآیند بازپرداخت که برای تراکنش‌های کارت اعتباری مصرف‌کننده طراحی شده است، هفته‌ها طول می‌کشد تا حل شود و در هر مرحله نیاز به دخالت انسانی دارد. در تجارت عامل، یک اختلاف که برای دو هفته حل نشده باقی می‌ماند، وجوهی را مسدود کرده است که باید عملیاتی باشند، یک مغایرت حسابداری ایجاد کرده است که از طریق تطبیق به صورت آبشاری ادامه می‌یابد و دو عامل را در وضعیت مبهمی قرار داده است که مانع از انجام تراکنش با یکدیگر می‌شود.

این پروتکل اختلافات را به عنوان یک گردش کار درجه یک با چرخه حیات پنج مرحله‌ای خود، جدا از وضعیت اسکرو، پیاده‌سازی می‌کند. هر مرحله دارای مهلت تعریف شده‌ای است. هر مهلت دارای یک عمل timeout است. هیچ اختلافی به طور نامحدود در بلاتکلیفی نمی‌ماند.

ثبت شکایت، اختلاف را با یک دسته دلیل ساختاریافته — خدمات تحویل داده نشده، کیفیت پایین‌تر از استاندارد، تراکنش غیرمجاز، مبلغ نادرست، شارژ تکراری، یا سایر موارد — و شواهد پشتیبان آغاز می‌کند. پاسخ طرف مقابل ظرف 24 ساعت برای طرف‌های عامل، 72 ساعت برای طرف‌های انسانی است. اگر طرف مقابل در بازه زمانی پاسخ ندهد، اختلاف به طور خودکار به نفع طرف ثبت‌کننده حل می‌شود. ارزیابی خودکار شواهد ارائه شده را در برابر سابقه پرداخت ارزیابی می‌کند و یا تصمیمی می‌گیرد یا به داوری انسانی ارجاع می‌دهد. داور 48 ساعت فرصت دارد، با ارجاع به مدیریت صندوق به عنوان پشتیبان. یک زمان‌بندی 7 روزه کل، بازپرداخت خودکار به طرف ثبت‌کننده را آغاز می‌کند. اجرای قطعنامه اتمی و برگشت‌ناپذیر است — سابقه اختلاف غیرقابل تغییر می‌شود، وجوه بر اساس تصمیم جابجا می‌شوند و هیچ یک از طرفین نمی‌توانند پرونده را دوباره باز کنند.

پیش‌فرض محافظه‌کارانه در هر timeout — بازگرداندن وجوه به طرفی که پرداخت کرده است — خودسرانه نیست. این استاندارد صنعتی در هر سیستم پرداختی است که از بررسی نظارتی در مقیاس جان سالم به در برده است. این امر انگیزه‌ها را به درستی تنظیم می‌کند: طرف مقابل که خدمات را ارائه می‌دهد، هر دلیلی برای تأیید فوری تحویل دارد و طرفی که برای خدمات پرداخت می‌کند، در برابر مسدود شدن نامحدود وجوه توسط یک طرف مقابل غیرپاسخگو محافظت می‌شود.

این پروتکل همچنین یک حلقه بازخورد را پیاده‌سازی می‌کند که سیستم‌های اختلاف سنتی فاقد آن هستند. عامل‌هایی که نرخ اختلاف آن‌ها از پنج درصد فراتر می‌رود، سیاست‌های هزینه‌کرد آن‌ها به طور خودکار سخت‌تر می‌شود — محدودیت‌های کمتر در هر تراکنش، طرف‌های مقابل که مکرراً با آن‌ها اختلاف وجود دارد به لیست مسدود شده اضافه می‌شوند، آستانه‌های تشدید انسانی کاهش می‌یابند. این تنبیهی نیست. این یک سیگنال عملیاتی است. نرخ اختلاف پنج درصد به این معنی است که چیزی در الگوهای تراکنش عامل به طور سیستماتیک اشتباه است و سیستم باید در مورد تأیید تراکنش‌های بیشتر محتاط باشد تا زمانی که مشکل اصلی شناسایی شود.

لایه حسابداری که مقیاس پذیری را ممکن می‌سازد

یک صندوق PE که هفته‌ای 4,500 تراکنش عامل خودمختار را پردازش می‌کند، نمی‌تواند به صورت دستی تأیید کند که هر پرداخت مربوط به یک سرویس تحویل‌شده مشروع است. لایه حسابداری باید به صورت خودمختار با همان سرعت لایه تراکنش عمل کند.

Reconciliation Auditor هر روز در ساعت 03:00 UTC به صورت خودکار اجرا می‌شود و می‌تواند بر اساس تقاضا از طریق API فعال شود. این سیستم هر پرداخت تسویه شده را با سابقه تحویل خدمات مربوطه cross-reference می‌کند و مغایرت‌ها را برای بررسی علامت‌گذاری می‌کند. هشت دسته ناهنجاری تعریف شده است. Phantom payments — وجوهی که بدون سابقه تحویل خدمات مطابقت‌یافته جابجا شده‌اند — شدت Critical دارند. Unpaid services — خدماتی که بدون پرداخت مربوطه تکمیل شده‌اند — شدت High دارند. Amount mismatches (عدم تطابق مبلغ) بالای انحراف ده درصد، شدت Medium دارند. Counterparty concentration (تمرکز طرف مقابل) بالای چهل درصد حجم به یک طرف مقابل، شدت Medium دارد — این الگو نشان‌دهنده ریسک وابستگی است که باید بررسی شود حتی زمانی که تراکنش‌های فردی مشروع هستند. Velocity anomalies (ناهنجاری‌های سرعت) بالای دو انحراف معیار از میانگین متحرک 30 روزه، شدت High دارند. Category drift (تغییر دسته) — دسته‌های تراکنش جدیدی که بدون به‌روزرسانی سیاست مربوطه ظاهر می‌شوند — شدت Low دارند. Cross-organizational patterns (الگوهای بین سازمانی) که نشان‌دهنده دور زدن هماهنگ سیاست هستند، شدت Critical دارند. Agent dispute rates (نرخ اختلافات عامل) بالای پنج درصد، شدت High دارند.

لایه تطبیق از الگوهای عملیاتی ناشناس در تمام استقرارها از طریق یک لایه هوش اختصاصی یاد می‌گیرد. هیچ اطلاعات شناسایی شخصی، داده‌های مالی، یا جزئیات خاص مشتری حفظ نمی‌شود. تنها الگوهای عملیاتی — تصمیمات مسیریابی، توزیع فراوانی، منحنی‌های هزینه، امضاهای استثنا — سیستم یادگیری را تغذیه می‌کنند. نتیجه، تشخیص ناهنجاری است که با حجم عملیاتی بهبود می‌یابد، نه یک مجموعه قوانین ثابت که با تکامل الگوهای تراکنش نیاز به تنظیم دستی دارد.

زیرساخت مدیریت استثنا که تولید واقعاً به آن نیاز دارد

هر سیستم پرداختی که فقط مسیر عادی را کنترل می‌کند، یک سیستم پرداخت نیست. آن یک نسخه نمایشی است. شکاف بین یک نمونه اولیه کارآمد و زیرساخت در سطح تولید، تقریباً به طور کامل با کامل بودن مدیریت استثنا اندازه‌گیری می‌شود — چه اتفاقی می‌افتد زمانی که یک تراکنش به طور جزئی اجرا می‌شود، زمانی که یک دسته از پرداخت‌های خرد باید به عنوان یک رویداد واحد تسویه شوند، زمانی که نرخ ارز در طول دوره اسکرو تغییر می‌کند، زمانی که یک عامل تراکنش‌هایی را جمع‌آوری می‌کند که به طور مکرر شکست می‌خورند و نیاز به قرنطینه برای بررسی دستی دارند.

این پروتکل دوازده قابلیت مدیریت استثنا را پیاده‌سازی می‌کند که در لایه اعتبارسنجی و تسویه حساب مشابهی ندارند اما برای عملیات تولید در هر مقیاس معنی‌داری ضروری هستند.

Partial capture به یک عامل اجازه می‌دهد تا حداکثر مبلغی را تأیید کند، ارزش جزئی را تحویل دهد، و تنها بخش تحویل داده شده را ضبط کند. مبلغ اعتبارسنجی تحویل داده نشده به طور خودکار به موجودی در دسترس درخواست‌کننده بازگردانده می‌شود. این امر در توافق‌نامه‌های خدماتی مهم است که دامنه در زمان اعتبارسنجی تعریف می‌شود اما تحویل واقعی در زمان تکمیل اندازه‌گیری می‌شود — یک عامل تحقیق که پانصد دلار برای تحلیل بازار تأیید می‌کند که در نهایت سه از پنج بخش درخواستی را پوشش می‌دهد، باید سیصد دلار پرداخت کند، نه پانصد دلار، و سیستم اعتبارسنجی باید این را بدون نیاز به چرخه بازپرداخت مدیریت کند.

Split settlement یک اعتبارسنجی واحد را به طور اتمی به چندین کیف پول طرف مقابل توزیع می‌کند. یک گردش کار که در آن یک پرداخت به سه عامل مشارکت‌کننده — یکی برای تحقیق، یکی برای تحلیل، یکی برای سنتز — باید یک اعتبارسنجی واحد از دیدگاه درخواست‌کننده و سه اعتبار همزمان از دیدگاه طرف‌های مقابل باشد. پیاده‌سازی این به عنوان سه تراکنش متوالی، سه نقطه شکست و سه اعتبارسنجی جداگانه در برابر سه تخصیص بودجه جداگانه ایجاد می‌کند.

Installment plans یک مبلغ کل را یک بار تأیید می‌کنند و تسویه حساب را در بخش‌های تعریف شده در یک برنامه اجرا می‌کنند. یک توافقنامه خدمات جاری که ماهانه بر اساس یک اعتبارسنجی سه ماهه پرداخت می‌شود، یک اعتبارسنجی، دوازده تسویه حساب، و یک مسیر حسابرسی تمیز است. بدون زیرساخت installment plan، این به دوازده چرخه اعتبارسنجی جداگانه، دوازده اسکن تطبیق‌پذیری جداگانه، و دوازده برابر سربار عملیاتی تبدیل می‌شود.

Batch settlement تراکنش‌های خرد را در رویدادهای تسویه حساب واحد جمع‌آوری می‌کند. یک عامل که پنجاه خرید داده کوچک از یک ارائه‌دهنده در یک روز انجام می‌دهد، نباید پنجاه سابقه تسویه حساب جداگانه، پنجاه اعلان webhook جداگانه، و پنجاه ورودی تطبیق جداگانه ایجاد کند. Batch settlement این را به یک تسویه حساب روزانه واحد، یک webhook واحد، و یک سابقه تطبیق واحد کاهش می‌دهد — بدون هیچ تغییری در رفتار اعتبارسنجی تراکنش‌های فردی.

موتور هزینه، کارمزد پلتفرم، پردازش، اسکرو، و کارمزدهای بین سازمانی را به طور اتمی در زمان تسویه حساب کسر می‌کند. محاسبات کارمزد در زمان اعتبارسنجی انجام می‌شود و کسر کارمزد در همان تراکنش اتمی به عنوان اعتبار طرف مقابل اجرا می‌شود. نتیجه یک دفتر کل تسویه حساب است که در آن هر اعتبار و هر بدهی در لحظه اجرا تطبیق داده می‌شود.

Multi-currency foreign exchange rate locking مشکلی را حل می‌کند که خاص تجارت عامل بین سازمانی و بین حوزه‌های قضایی است. هنگامی که یک تراکنش در اسکرو قرار می‌گیرد، طرف مقابل باید ارزش توافق شده را بدون در نظر گرفتن حرکت نرخ ارز در طول دوره اسکرو دریافت کند. قفل کردن نرخ در زمان ایجاد اسکرو به این معنی است که طرف مقابل می‌تواند به دریافت آنچه توافق شده بود اطمینان کند، و درخواست‌کننده می‌تواند به این اطمینان کند که هزینه کل همان چیزی است که تأیید شده بود.

dead letter queue تراکنش‌های ناموفق را با متادیتای عملیاتی، هشدارهای قدیمی شدن در سه روز، رها کردن خودکار در چهارده روز، و مسیرهای حل دستی برای مواردی که نیاز به قضاوت انسانی دارند، ضبط می‌کند. ردیابی SLA در dead letter queue تراکنش‌های ناموفق فردی را به تعهدات عملیاتی که عامل‌های درگیر را کنترل می‌کنند، متصل می‌کند، بنابراین یک شکست که به مهلت SLA خود نزدیک می‌شود، قبل از نقض به بازبین صحیح ظاهر می‌شود نه بعد از آن.

Client-supplied idempotency keys از شارژهای تکراری جلوگیری می‌کنند زمانی که تلاش‌های مجدد شبکه یا ارسال مجدد webhook باعث می‌شود همان تراکنش بیش از یک بار ارسال شود. در یک سیستم توزیع شده که عامل‌ها در چندین مرز شبکه عمل می‌کنند، idempotency یک زیرساخت اختیاری نیست.

Administrative payment holds امکان مسدود کردن اضطراری فعالیت پرداخت در سطح عامل، سازمان، یا صندوق را فراهم می‌کند. اسکروهای موجود زمانی که یک hold اعمال می‌شود به حل و فصل ادامه می‌دهند — hold تراکنش‌های در حال انجام را به صورت گذشته‌نگر معکوس نمی‌کند. تراکنش‌های جدید برای تمام طرفین مشمول hold مسدود می‌شوند.

Credit and debit memos تنظیمات پس از تسویه حساب را بدون نیاز به بازپرداخت کامل و چرخه اعتبارسنجی مجدد مدیریت می‌کنند. اعتبارات خدماتی، اصلاحات صورتحساب، تخفیف‌های حجمی که به صورت گذشته‌نگر اعمال می‌شوند، و مبالغ مورد اختلاف که به طور جزئی تسویه می‌شوند — همه این موقعیت‌ها تنظیمات پس از تسویه حساب را ایجاد می‌کنند که باید به طور دقیق در دفتر کل ظاهر شوند بدون اینکه سابقه تراکنش اصلی را مخدوش کنند.

تطبیق‌پذیری به عنوان زیرساخت، نه حسابرسی

اکثر سیستم‌های تطبیق‌پذیری گذشته‌نگر هستند. تراکنش‌ها اجرا می‌شوند، سوابق ایجاد می‌شوند و یک تابع تطبیق‌پذیری آن سوابق را به صورت دوره‌ای بررسی می‌کند تا نقض‌ها را شناسایی کند. مشکل تطبیق‌پذیری گذشته‌نگر در تجارت عامل خودمختار این است که تا زمانی که نقض شناسایی شود، صدها یا هزاران تراکنش بعدی ممکن است تحت همان شرایط نامعتبر اجرا شده باشند و اقدام اصلاحی شامل بازگرداندن تاریخچه تراکنش‌ها به جای جلوگیری از یک تراکنش بد واحد است.

این پروتکل اسکن تطبیق‌پذیری را در مرحله نهم خط لوله اعتبارسنجی، قبل از اتخاذ تصمیم اعتبارسنجی، تعبیه می‌کند. هیچ تراکنشی که مقررات قضایی پیکربندی شده را نقض کند، نمی‌تواند مجاز شود — نقض قبل از جابجایی وجوه مسدود می‌شود. غربالگری تطبیق‌پذیری قبل از تراکنش در تراکنش‌های SWIFT و بانکداری کارگزاری استاندارد است. این پروتکل همان فلسفه را به تراکنش‌های عامل خودمختار با سرعت ماشین، بدون بررسی انسانی، در چندین حوزه قضایی به طور همزمان می‌آورد.

حوزه‌های قضایی که در حال حاضر پوشش داده می‌شوند شامل مقررات فدرال و ایالتی ایالات متحده؛ دستورالعمل‌های اتحادیه اروپا از جمله GDPR، PSD2، MiCA و DORA؛ چارچوب‌های امارات متحده عربی از جمله CBUAE، DFSA و ADGM؛ و مقررات LATAM از جمله برزیل 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

این پروتکل تحت قوانین بین‌المللی ثبت اختراع با وضعیت در حال ثبت اختراع در یازده حوزه قضایی در آمریکای شمالی، اروپا، خاورمیانه، آسیا و اقیانوسیه، و آمریکای لاتین محافظت می‌شود.

معماری چند مستأجره که استقرار سازمانی را ممکن می‌سازد

یک سازمان واحد که عامل‌های AI را اجرا می‌کند، یک استقرار قابل مدیریت است. یک صندوق سرمایه‌گذاری خصوصی که عامل‌های AI را در سی شرکت پرتفوی اجرا می‌کند، یک مشکل کاملاً متفاوت است. هر شرکت پرتفوی به سیاست‌های هزینه‌کرد خاص خود، پیکربندی تطبیق‌پذیری خاص خود، مسیر حسابرسی خاص خود و تطبیق‌پذیری خاص خود نیاز دارد. اما صندوق همچنین به دید کلی در سراسر پرتفوی نیاز دارد — هزینه‌های تجمیعی، الگوهای بین پرتفوی، پیش‌فرض‌های سیاست در سطح صندوق که به هر شرکت بدون نیاز به پیکربندی همه چیز از ابتدا، آبشار می‌شود.

معماری چند مستأجره در پروتکل این را به عنوان یک سلسله مراتب سه سطحی پیاده‌سازی می‌کند: صندوق در بالا، شرکت‌های پرتفوی به عنوان فرزندان، عامل‌های فردی به عنوان برگ‌ها. سیاست‌های هزینه‌کرد به سمت پایین آبشار می‌شود — یک صندوق پیش‌فرض‌هایی را پیکربندی می‌کند که برای همه شرکت‌های پرتفوی اعمال می‌شود مگر اینکه یک شرکت پرتفوی آنها را لغو کند، و سیاست‌های شرکت پرتفوی برای همه عامل‌ها اعمال می‌شود مگر اینکه یک عامل پیکربندی خاص خود را داشته باشد. دقیق‌ترین سیاست قابل اجرا، هر تراکنش را کنترل می‌کند. یک قانون در سطح صندوق که تراکنش‌ها با یک طرف مقابل خاص را مسدود می‌کند، نمی‌تواند در سطح شرکت پرتفوی یا عامل لغو شود — سلسله مراتب حاکمیت را در هر دو جهت اجرا می‌کند.

امنیت سطح ردیف در سطح پایگاه داده، ایزولاسیون سازمانی را در هر جدول اعمال می‌کند. این کنترل دسترسی در سطح برنامه نیست که با یک کوئری نادرست پیکربندی شده قابل دور زدن باشد. این در لایه پایگاه داده اعمال می‌شود، به این معنی که یک عامل که در یک شرکت پرتفوی فعالیت می‌کند، نمی‌تواند سوابق متعلق به شرکت پرتفوی دیگر را بخواند یا تغییر دهد، صرف نظر از کلید API یا کد برنامه که درخواست را انجام می‌دهد. با سی شرکت پرتفوی که هر کدام ده تا پانزده عامل به صورت خودمختار تراکنش انجام می‌دهند، و هفته‌ای چندین هزار تراکنش، این ایزولاسیون یک ویژگی امنیتی برای پیکربندی نیست. این یک الزام پایه برای قانونی و عملیاتی بودن سیستم است.

تراکنش‌های بین سازمانی — یک عامل شرکت پرتفوی که به یک ارائه‌دهنده خدمات شخص ثالث پرداخت می‌کند، یا دو عامل شرکت پرتفوی که یک توافقنامه خدمات را تسویه می‌کنند — با ارزیابی سیاست مستقل پشتیبانی می‌شوند. سیاست‌های هزینه‌کرد هر دو طرف به طور مستقل بررسی می‌شوند. یک تراکنش که در محدوده سیاست درخواست‌کننده است اما محدودیت‌های سیاست طرف مقابل را نقض می‌کند، همچنان می‌تواند مسدود شود. هر دو طرف یک تراکنش حاکمیت دارند، نه فقط طرف آغازکننده.

برای سرمایه‌گذاران و اپراتورهایی که این را به عنوان یک سوال معماری استقرار می‌خوانند، مفهوم عملی این است که زیرساخت پرداخت به صورت افقی در پیچیدگی سازمانی مقیاس‌پذیر است. اضافه کردن یک شرکت پرتفوی جدید به صندوق نیازی به پیکربندی یک سیستم پرداخت از ابتدا ندارد. این نیاز به ارث بردن پیش‌فرض‌های سطح صندوق و پیکربندی لغوهای خاصی که برای آن شرکت اعمال می‌شود، دارد. اضافه کردن یک عامل جدید در یک شرکت پرتفوی نیازی به پیکربندی مجوزهای پرداخت ندارد. عامل سیاست شرکت پرتفوی را به ارث می‌برد و بلافاصله در آن محدودیت‌ها شروع به تراکنش می‌کند.

این نحوه کار تجارت عامل را تغییر می‌دهد

لحظه‌ای که عامل‌های هوش مصنوعی خودمختار می‌توانند با یکدیگر به طور ایمن تراکنش کنند — با سیاست‌های هزینه‌کردی که قضاوت انسانی را به قوانین قابل اجرا توسط ماشین تبدیل می‌کنند، با اسکرویی که پرداخت را از تحویل جدا می‌کند، با حل اختلافی که با سرعت ماشین عمل می‌کند، با تطبیق‌پذیری که در حالی که همه خواب هستند اجرا می‌شود — اقتصاد استقرار عامل‌ها برای همیشه تغییر می‌کند.

در حال حاضر، هر استقرار عاملی دارای یک سقف است. شما می‌توانید تحقیق، تحلیل، پیش‌نویس، مسیریابی، برنامه‌ریزی و اجرا را خودکار کنید. اما لحظه‌ای که یک عامل نیاز به تهیه چیزی، تسویه یک توافقنامه خدمات، یا پرداخت به یک طرف مقابل برای کار تکمیل شده دارد، شما دوباره به یک انسان در حلقه باز می‌گردید. این سقف یک ویژگی نیست. این محدودیت زیرساخت موجود تا کنون است.

ما این را ساختیم چون به آن نیاز داشتیم. پلتفرم Pulse AI 49 عامل تولیدی را در 21 صنعت عمودی اجرا می‌کند، و مشکل پرداخت واقعی بود — نه نظری، نه پیش‌بینی شده، واقعی. عامل‌ها نیاز به تراکنش داشتند. زیرساخت لازم برای انجام این کار به طور ایمن، مطابق با قوانین، و با سرعت ماشین وجود نداشت. بنابراین ما آن را ساختیم، آن را از طریق 284 آزمایش و تست بار 50 بازیگر همزمان تأیید کردیم، آن را در 19 مشخصات فنی مستند کردیم، و امروز آن را در دسترس قرار می‌دهیم.

ما واقعاً از آنچه در آینده اتفاق می‌افتد هیجان‌زده‌ایم. این پروتکل در سه ماهه جاری در پشته‌های مشتریان موجود مستقر می‌شود. محصول پرداخت سرمایه‌گذاری مشترک که بر روی این زیرساخت ساخته شده است، در 1 ژوئن منتشر می‌شود. پلتفرم Pulse AI همچنان در حال رشد است — 49 عامل امروز، هر ماه بیشتر، هر کدام زیرساخت پرداخت کامل را از روز اول به ارث می‌برند. هر صنعت عمودی جدیدی که وارد می‌شویم، هر مشتری جدیدی که جذب می‌کنیم، هر عامل جدیدی که مستقر می‌کنیم — لایه پرداخت از قبل وجود دارد، از قبل تأیید شده، از قبل در حال اجراست.

مشخصات عمومی در github.com/SFOSTER2030/a2a-payment-protocol است. مقاله سفید در a2a.tfsfventures.com است. نمایش زنده در a2ademo.tfsfventures.com اجرا می‌شود. مستندات معماری هر جزء را در سطح جزئیات لازم برای پیاده‌سازی، ادغام یا ارزیابی آن پوشش می‌دهد. مشخصات OpenAPI 3.1 تمام 50 مسیر API را مستند می‌کند. گزارش اعتبارسنجی یک سابقه عمومی از 284 آزمایش و هر اشکال یافت شده و رفع شده قبل از انتشار است. ما همه چیز را منتشر کردیم زیرا معتقدیم این زیرساخت باید به یک استاندارد تبدیل شود، و استانداردها به شفافیت نیاز دارند.

هر کسب‌وکاری که عامل‌های AI را با هرگونه اختیار هزینه‌کردی مستقر می‌کند، به این زیرساخت نیاز دارد. هر چه زودتر در تولید قرار گیرد، زودتر سقف برداشته می‌شود. ما آماده استقرار هستیم.

درباره TFSF Ventures

TFSF Ventures FZ-LLC (مجوز RAKEZ 47013955) یک شرکت استقرار عامل هوش مصنوعی است که در سه ستون فعالیت می‌کند: زیرساخت عامل، ریل پرداخت و موتور سرمایه‌گذاری. TFSF Ventures که توسط استیون فاستر با 27 سال تجربه در پرداخت‌ها و زیرساخت‌های نرم‌افزاری تأسیس شده است، سیستم‌های عامل هوش مصنوعی تولیدی را در 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/