پرداخت‌های عاملی تحت سیاست انسانی
پرداخت‌های عاملی پرداخت‌هایی هستند که نرم‌افزار آغاز می‌کند، نه یک فرد پشت صفحه پرداخت. یک عامل هوش مصنوعی اعتبارنامه دارد، تصمیم می‌گیرد خریدی باید انجام شود و خودش پول را جابه‌جا می‌کند: فاکتوری را می‌پردازد، اشتراکی را تمدید می‌کند، پروازی چارتر می‌کند، بی‌آنکه انسانی دکمه آخر را بزند. وجه تمایز، آغازگر است. وقتی شخصی روی خرید می‌زند، یک پرداخت کارتی معمولی است که جلویش یک چت‌بات گذاشته‌اند؛ در پرداخت عاملی، نرم‌افزار در لحظه جابه‌جایی واقعی پول تصمیم می‌گیرد، مجوز می‌دهد و تسویه می‌کند. هر چیز دشواری در این حوزه از همین یک ویژگی می‌آید: آنچه خرج می‌کند انسان نیست و مثل انسان پیش از حواله پول به یک غریبه خسته، بدگمان یا نگران نمی‌شود.
برای همین، پرسش جالب هرگز این نبود که آیا عامل‌ها پول خرج خواهند کرد، چون همین حالا می‌توانند. پرسش این است که چه کسی قواعدی را که تحت آن‌ها خرج می‌کنند تعیین می‌کند و آیا این قواعد را پلتفرم اجرا می‌کند یا عامل فقط قولش را می‌دهد.
حالت شکست آشکار است، و نکته همین است
به عاملی اعتبارنامه پرداخت زنده بدهید و هیچ سقفی نگذارید؛ یک حادثه کلاهبرداری بانکی ساخته‌اید که هنوز رخ نداده است. راه خراب شدن آن عجیب نیست. تزریق پرامپت در یک صفحه وب به عامل می‌گوید به یک مهاجم پرداخت کند. توضیح ابزار مخدوش یک خرید معتبر را به گیرنده اشتباه می‌فرستد. یک حلقه تکرار همان پرداخت را هزار بار امتحان می‌کند، چون سیگنال موفقیت هرگز برنگشته است. هیچ‌کدام مهاجم زیرکی نمی‌خواهند. این‌ها باگ‌های معمولی نرم‌افزار خودمختارند، با این تفاوت که خروجی پولی است که از حساب شما خارج می‌شود.
راه‌حل وسوسه‌برانگیز این است که عامل را محتاط‌تر کنند: پرامپت سیستمی بهتر، دستور محکم‌تر، مدلی که درباره خرج کردن بیشتر استدلال کند. این کار کنترل را در نامطمئن‌ترین جای سیستم می‌گذارد، یعنی استدلال خود عامل، همان چیزی که می‌شود قانعش کرد. بودجه‌ای که عامل بتواند از آن عبور کند بودجه نیست. کنترل باید جایی باشد که عامل به آن دسترسی ندارد، یعنی کاملاً بیرون از عامل.
محصول، سیاست است، نه پرامپت
مدل مهار، سیاستی است که پلتفرم پیش از جابه‌جایی پول اعمال می‌کند، نه بعد از آنکه عامل تصمیم گرفته. هر عامل سقف هر تراکنش و محدودیت روزانه دارد، در سیاست دموی ما 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 درخواست، هر بررسی سیاست با نتیجه‌اش (allowlist قبول، سقف قبول، آستانه ارجاع)، امضای انسانی و مبلغ تسویه‌شده را همراه با ریل و شناسه مرجع نشان می‌دهد. هر ورودی هش خودش، هش ورودی قبلی و جایگاهش در زنجیره را دارد (در دمو #4,471)، پس تغییر هر فیلد همهٔ رکوردهای بعدی را می‌شکند. لاگ همراه با هش در قالب JSON خروجی می‌گیرد: برای تحویل به حسابرس است و نزد ما نمی‌ماند.
تسویه را کسل‌کننده نگه دارید؛ نوآوری را در احراز مجوز بگذارید
وسوسه‌انگیز است که پرداخت عاملی را از پایه تا سقف تازه کنیم: ریل تازه، ابزار پرداخت تازه، مسیر تازه برای جابه‌جایی پول. مقاومت کنید. بخش واقعاً تازه، احراز مجوز است: اینکه عامل چطور ثابت می‌کند اجازهٔ پرداخت دارد، طبق سیاست چه کسی و با چه تأییدی. پرداختی که از این دروازه گذشت باید روی ریل‌هایی تسویه شود که سال‌هاست کسل‌کننده‌اند. در دمو، پیشنهاد تأییدشدهٔ €120.00 به یک انتقال اعتباری معمولی SEPA تبدیل می‌شود که چند دقیقه پس از تأیید با SEPA Instant تسویه می‌شود و در ادامهٔ مسیر از پرداخت یک انسان قابل تشخیص نیست. بانک نمی‌داند و برایش مهم نیست که عاملی آن را آغاز کرده است.
این تفکیک عمدی است. ریل‌های کسل‌کننده قابل‌پیش‌بینی‌اند، تا جایی که قواعد شبکه اجازه دهد برگشت‌پذیرند، و هر خزانه‌دار و حسابرسی که با او سروکار پیدا کنید آن‌ها را می‌شناسد. وقتی نوآوری در سیاست‌ها باشد و پرداخت روی ریل تسویه‌شده، بخش پرریسک و سریع‌التغییر کاملاً در کنترل شماست و بخشی که به بانک‌های دیگران می‌رسد چیزی نیست که کسی مجبور به یادگیری دوبارهٔ آن شود. عامل‌ها از همان هسته‌ای خرج می‌کنند که بقیهٔ خانوادهٔ پرداخت روی آن اجرا می‌شود (توضیح در /products/pay)، نه از دنیایی موازی که برای ربات‌ها ساخته شده است.
چشم‌انداز پروتکل‌ها هنوز تثبیت نشده است؛ برای همین طراحی کنید
اینکه عامل چگونه هویت و مجوز خود را به پذیرنده ارائه کند، هنوز پرسشی باز است. چند پیشنهاد رقیب وجود دارد دربارهٔ اینکه عامل چطور ثابت کند کیست، اجازهٔ خرید چه چیزی را دارد و پذیرنده پیش از پذیرفتن پول چطور این را بررسی کند. هیچ‌کدام برنده نشده و امروز روی یکی از آن‌ها همه‌چیز را گرو گذاشتن زودهنگام است. رویکرد دفاعی این است که پروتکل احراز مجوز را قابل‌تعویض بگیرید و هر چه پشت آن است ثابت بماند: موتور سیاست‌ها، مدل حسابرسی و ریل تسویه با تغییر قالب ارتباطی در جلو تغییر نمی‌کنند.
در عمل یعنی یک سطح یکپارچه‌سازی کوچک و کسل‌کننده. عامل‌ها از طریق MCP به mcp.protocore.io/agents وصل می‌شوند و هر فریم‌ورکی که این پروتکل را بفهمد می‌تواند کیف پول داشته باشد. رابط عمداً باریک است: پیشنهاد پرداخت بده، تصمیم دریافت کن. چون منطق جالب روی پلتفرم است، نه در پرامپت. وقتی صنعت بر سر نحوهٔ اثبات هویت عامل‌ها به پذیرندگان به توافق برسد، جلوی کار عوض می‌شود و دیوارهای پشت آن دقیقاً سر جای خود می‌مانند.
جایگاه این موضوع
پرداخت عاملی شرط‌بندی روی این نیست که نرم‌افزار خودمختار بی‌حد و حصر خرج کند. درست برعکس است: شرط‌بندی روی این است که نرم‌افزار خرج خواهد کرد، پس بهتر است محدودیت‌ها واقعی، بیرونی و خوانا باشند. بودجه‌ها و allowlistها جعبه را می‌کشند، آستانه‌ها تصمیم‌های بزرگ را به یک انسان می‌سپارند، کلید توقف اضطراری همه‌چیز را متوقف می‌کند و لاگ فقط‌افزودنی یعنی هر پرداخت را بعداً می‌شود بازسازی کرد. صفحهٔ محصول در /products/agents کل این چرخه را روی همین داده‌های دمو نشان می‌دهد: ساخت عامل، تنظیم سیاست، تماشای ارجاع و تسویهٔ یک پرداخت. و /products/pay هستهٔ اجرای این پرداخت‌هاست. خودمختاری واقعی است؛ افسار هم واقعی است و دست یک انسان است.
سیستمی برای ساختن دارید؟
مسئله را بگویید. با یک معماری و یک برنامه برمی‌گردیم.