یک یادداشت طراحی منتشر شده توسط بنیاد سوئی (Sui Foundation) بر ضرورت ایجاد محدودیت‌های هزینه‌ای قابل اجرا برای عوامل هوش مصنوعی تمرکز دارد. این رویکرد به دنبال تضمین این است که عوامل مالی، در عین برخورداری از اختیار کافی برای انجام وظایف، از حدود تعیین شده فراتر نروند، حتی در صورت بروز اشتباه در تفسیر دستورالعمل‌ها یا مواجهه با اطلاعات گمراه‌کننده.
این یادداشت که در تاریخ ۲۸ اکتبر منتشر شده، چارچوبی برای ساخت جریان‌های کاری امن‌تر ارائه می‌دهد و صرفاً یک اعلامیه مبنی بر قابل اعتماد شدن تمام عوامل هوش مصنوعی در شبکه سوئی نیست. هدف اصلی، ایجاد تعادل بین اختیار عامل و داشتن محدودیت‌های مؤثر است.
تمایز دستورالعمل‌ها و مجوزها
بنیاد سوئی استدلال می‌کند که مرزهای عملیاتی باید توسط سیستم‌هایی که عامل از آن‌ها استفاده می‌کند، اعمال شوند، نه اینکه صرفاً به عنوان دستورالعمل‌هایی باشند که عامل انتظار می‌رود به خاطر بسپارد. این یادداشت همچنین بر اصطلاحات مشترک و سوابق قابل تأیید در مواقعی که چندین سازمان مشارکت دارند، تأکید می‌کند.
این تمایز در مثال پرداخت کاملاً واضح است. تعیین یک سقف هزینه برای نرم‌افزار، یک رویکرد کنترلی است. اما اعطای اعتبارنامه‌هایی که امکان انجام پرداختی بالاتر از آن سقف را نمی‌دهند، رویکرد کنترلی دیگری است. روش اول به تفسیر و پیروی عامل از قانون بستگی دارد، در حالی که روش دوم حتی در صورت اشتباه عامل نیز می‌تواند مانع عمل شود. پیاده‌سازی مؤثر نیازمند هر دو مورد: یک هدف منطقی و مکانیزمی برای محدود کردن اجرا.
تراکنش‌های اتمی برای کاهش نتایج ناقص
مستندات تراکنش‌های قابل برنامه‌ریزی سوئی شرح می‌دهد که چگونه چندین فرمان را می‌توان گروه‌بندی کرد تا تغییرات حالت آن‌ها به صورت یکپارچه اعمال شود. اگر یک فرمان شکست بخورد، گروه باعث نیمه‌کاره ماندن تغییرات دارایی مورد نظر نمی‌شود، اگرچه هزینه تراکنش همچنان باید در نظر گرفته شود.
برای یک گردش کار خودکار، این قابلیت زمانی مفید است که چندین مرحله در زنجیره به یکدیگر وابسته باشند. خرید یک دارایی و انتقال بعدی آن می‌تواند به عنوان یک تراکنش ترکیبی ارزیابی شود، نه به عنوان عملیات نامرتبط. با این حال، این مزیت محدودیت‌هایی دارد. اجرای اتمی صحت قیمت، مناسب بودن گیرنده یا تحویل سرویس خارجی را تضمین نمی‌کند؛ بلکه نحوه تکمیل مجموعه‌ای از عملیات را کنترل می‌کند، نه اینکه قضاوت تجاری اساسی درست بوده باشد.
تفویض اختیار باید مرز اصلی را حفظ کند
یک عامل پیچیده‌تر ممکن است خدمات دیگری را فراخوانی کند یا بخشی از وظیفه را تفویض کند. این امر سوالی را در مورد اختیار ایجاد می‌کند: آیا شرکت‌کننده بعدی فقط می‌تواند همان کاری را انجام دهد که کاربر اصلی مجاز کرده بود، یا تفویض اختیار به طور تصادفی دامنه را گسترش می‌دهد؟
یک طراحی قوی باید پاسخ این سوال را قابل مشاهده کند. مجوزها می‌توانند بودجه، هدف تأیید شده، تاریخ انقضا و مجموعه‌ای محدود از طرف‌های مقابل را مشخص کنند. سپس سیستم در نقطه مجاز شدن یک عمل، این شرایط را بررسی می‌کند. این یک اصل طراحی تحلیلی است، نه ادعایی مبنی بر اینکه یک بلاک‌چین به طور خودکار تمام کنترل‌های لازم را فراهم می‌کند. توسعه‌دهندگان همچنان باید قوانین را به درستی پیاده‌سازی کنند و اقدامات خارج از زنجیره را در نظر بگیرند.
سوابق قابل تأیید به شفاف‌سازی وقایع کمک می‌کنند
هنگامی که چندین کسب‌وکار از طریق عوامل نرم‌افزاری با یکدیگر تعامل دارند، یک سابقه مشترک می‌تواند به تعیین اینکه کدام اقدام مجاز بوده و کدام تراکنش رخ داده است، کمک کند. این امر برای تطبیق و تحقیقات، به ویژه زمانی که هر شرکت‌کننده سیستم‌های داخلی خود را نگه می‌دارد، مفید است.
این سابقه همچنان به زمینه نیاز دارد. یک تراکنش موفق اثبات نمی‌کند که مشتری یک کالای فیزیکی دریافت کرده، صورتحساب واقعی بوده یا ورودی خارج از زنجیره دقیق بوده است. این حقایق نیازمند شواهد و فرآیندهای حل اختلاف خاص خود هستند. بنابراین، قوی‌ترین برداشت از یادداشت طراحی سوئی عملی است: با اختیاری که به طور محدود تعریف شده شروع کنید، آن را در مرز سیستم اعمال کنید و اقدامات تکمیل شده را قابل بازرسی سازید. دامنه را تنها زمانی گسترش دهید که کنترل‌ها و شواهد عملیاتی آن را توجیه کنند.
زیرساخت بلاک‌چین می‌تواند قوانین تراکنش و سوابق را به این طراحی کمک کند. کیفیت عامل حاصله به برنامه کامل، از جمله مجوزها، منابع اطلاعاتی و پاسخ آن در هنگام وقوع مشکلی خارج از گردش کار مورد انتظار، بستگی دارد.
