چگونه عاملهای هوش مصنوعی در کریپتو کار میکنند: خواندن دادههای مبتنی بر ابزار به علاوه اجرای حساب هوشمند
عاملان هوش مصنوعی در ارزهای دیجیتال با اجرای یک حلقه عامل کار میکنند که درخواستها را به پرسشهای دادهای ساختاریافته در زنجیره تبدیل میکند و سپس هر اقدام پیشنهادی را از طریق قوانین کیف پول برنامهپذیر هدایت میکند قبل از اینکه یک تراکنش اجرا شود. بخش مفید این است که «ربات معامله میکند» نیست، بلکه مرز مجوز بین هوش فقط خواندنی و اجرای زنجیرهای است.
نکات کلیدی
- عاملان ارزهای دیجیتال زمانی قابل استفاده میشوند که «هوش» از «اجرا» جدا شود: تماسهای ابزار تحلیلی ساختاریافته در یک طرف، مجوز حساب هوشمند در طرف دیگر.
- سرور MCP داین ۱۲ ابزار را از طریق یک نقطه پایانی ارائه میدهد تا یک عامل بتواند جداول را کشف کند، DuneSQL تولید کند، پرسشها را اجرا کند و نتایج قابل مصرف ماشین را در بیش از ۱۰۰ بلاکچین بازگرداند.
- حسابهای هوشمند ایمن، EOAs با کلید واحد را با مالکان به علاوه یک آستانه جایگزین میکنند و میتوانند با ماژولها و محافظهای امنیتی بحرانی که همچنین میتوانند به روشهای زشت شکست بخورند، گسترش یابند.
- پشتیبانی زنجیرهای یکنواخت نیست، بنابراین یک پشته عامل که فرض میکند یک ماژول یا ویژگی خاص ایمن میتواند در یک شبکه کار کند و در شبکه دیگر در دسترس نباشد.
چگونه عاملان هوش مصنوعی در ارزهای دیجیتال جا میگیرند
در یک صفحه نمایش، «عاملان در ارزهای دیجیتال» معمولاً شبیه یک جعبه چت به نظر میرسند که میتواند یک نمودار را بالا بکشد، جریانها را خلاصه کند و گاهی یک تراکنش را در صف قرار دهد. در زیر سطح، مدل ذهنی تمیز یک خط لوله دو کلیدی است: یک مغز فقط خواندنی که میتواند تماسهای ابزار تحلیلی ساختاریافته را فراخوانی کند و مجموعهای از «دستها» که تنها زمانی میتوانند حرکت کنند که قوانین یک حساب هوشمند اجازه دهد.
این چارچوب به سوالی که پشت عاملان هوش مصنوعی در ارزهای دیجیتال وجود دارد پاسخ میدهد بدون اینکه وانمود کند عامل یک کیف پول جادویی با نظرات است.
مکانیسمی که بیشتر تیمها به آن نزدیک میشوند، حلقه عامل درک-تصمیم-عمل است، زیرا به طور مرتب به تقسیم داده و اجرا در ارزهای دیجیتال میخورد. درک به معنای «نظارت بر زنجیره» به معنای انسانی نیست. این تماسهای ابزاری است که خروجیهای ساختاریافته را بازمیگرداند. تصمیم مرحله استنتاج مدل بر روی آن خروجیها به علاوه هر سیاستی است که شما کدگذاری میکنید. عمل یا یک پیشنهاد تراکنش است یا یک اجرای واقعی در زنجیره، بسته به اینکه مرز مجوز چگونه طراحی شده است.
این مرز جایی است که ارزهای دیجیتال از اتوماسیون عمومی متفاوت میشوند. یک عامل SaaS معمولی میتواند یک «کلید API» و محدودیتهای نرخ دریافت کند. یک عامل هوش مصنوعی ارز دیجیتال که میتواند امضا کند، یک درخواست بد دور از تبدیل شدن به یک رویداد زیان است.
بنابراین معماری که پایدار است این است: (۱) به عامل خوانشهای قابل اعتماد و قابل فراخوانی ماشین بدهید و (۲) اجرای محدود را از طریق یک حساب هوشمند که تأییدهای صریح، محدودیتها یا هر دو را مجبور میکند، فراهم کنید.این همچنین جایی است که «جریان کاری عاملی» دیگر یک کلمه کلیدی نیست. جریان کاری یک زنجیره قابل تولید از تماسهای ابزار، خروجیها و نیتهای تراکنش است، با یک نقطه واضح که یک آستانه یا محافظ ایمن میتواند بگوید «نه».دسترسی ابزار به دادههای زنجیرهای
سرور MCP داین یک مثال عینی از چگونگی کارکرد عاملان هوش مصنوعی زمانی که آنها داشبوردها را خراش نمیدهند، است. این ۱۲ ابزار را از طریق یک نقطه پایانی واحد ارائه میدهد تا یک عامل سازگار با MCP بتواند جداول را کشف کند، DuneSQL بنویسد، پرسشها را اجرا کند، نتایج را بازیابی کند و تجسمهایی را در برابر انبار داین در بیش از ۱۰۰ بلاکچین ایندکس شده تولید کند. این مهم است زیرا عامل دیگر نامهای جدول را حدس نمیزند یا به اسکرینشاتها تکیه نمیکند. این تماسهای توابعی است که نتایج ساختاریافته را بازمیگرداند.
ترتیب ساده است و این بخشی است که بیشتر توضیحات «عاملان دادهها را میخوانند و معامله میکنند» از آن صرف نظر میکنند:
۱. عامل در کاتالوگ داین به دنبال مجموعههای داده مرتبط و جداول قرارداد رمزگشایی شده میگردد. ۲. از درخواست DuneSQL تولید میکند، سپس پرسش را از طریق رابط ابزار اجرا میکند. ۳. نتایج را در یک فرمت قابل مصرف ماشین بازیابی میکند و میتواند در صورت نیاز یک تجسم ارائه دهد.
CLI داین همان ایده را به اتوماسیون بومی ترمینال منتقل میکند. CLI برای جریانهای کاری عامل ساخته شده است و شامل کشف مجموعههای داده، نوشتن و اجرای DuneSQL، مدیریت پرسشها، جستجوی مستندات و پیگیری استفاده است. هر دستور JSON را برای مصرف ماشین خروجی میدهد و با یک فایل Skills.md که استاندارد مهارتهای عامل را دنبال میکند، ارسال میشود تا یک عامل بتواند قابلیتها و مدیریت خطا را بدون ادغام خاص یاد بگیرد.
این واقعیت «معماری عامل هوش مصنوعی ارز دیجیتال» است: چارچوب عامل تنها به اندازه ابزارهایی که میتواند فراخوانی کند خوب است. اگر لایه ابزار خروجیهای SQL و JSON قابل تولید را بازگرداند، عامل میتواند مورد حسابرسی و دوباره اجرا قرار گیرد. اگر لایه ابزار یک داشبورد و یک حس باشد، عامل فقط در حال بداههپردازی است.
حسابهای هوشمند به عنوان لایه اجرای عامل
اجرا جایی است که عاملان ارز دیجیتال یا به اندازه کافی ایمن میشوند که استفاده شوند یا به اندازه کافی خطرناک میشوند که از آنها اجتناب شود. اشتباه رایج این است که اتوماسیون را به یک EOA بدهید. EOAs توسط یک «کلید خصوصی» واحد کنترل میشوند و اگر کسی آن کلید را به دست آورد، کنترل کامل را به دست میآورد. این یک مدل امنیتی تمیز برای یک انسان با یک «کیف پول سختافزاری» است. این یک مدل شکننده برای نرمافزاری است که بدون نظارت اجرا میشود.
حسابهای هوشمند مدل مجوز را تغییر میدهند. آنها میتوانند وجوه دریافت کنند و مانند EOAs تراکنش انجام دهند، اما نمیتوانند آنها را آغاز کنند. منطق تأیید و اجرای آنها توسط کد «قرارداد هوشمند» تعریف میشود نه یک کلید خصوصی واحد. آن جزئیات است که چرا حسابهای هوشمند لایه «کیف پول عامل» طبیعی هستند. خود حساب به یک موتور سیاست تبدیل میشود.
حساب هوشمند ایمن بهترین پیادهسازی شناخته شده از آن ایده است. این یک حساب هوشمند با چند امضایی در هستهاش است: مجموعهای از مالکان و یک آستانه تأییدات مورد نیاز قبل از اجرا. مالکان میتوانند EOAs، حسابهای قرارداد هوشمند دیگر یا حتی یک کلید عبور باشند.
برای یک عامل، این به این معنی است که وضعیت پیشفرض میتواند «عامل آماده میشود، یک انسان امضا میکند» باشد و سیستم هنوز از همان «آدرس» زنجیرهای و حسابداری استفاده میکند.معماری ایمن همچنین برای استقرار و عملیات مهم است. حسابهای هوشمند ایمن با استفاده از الگوی پروکسی مستقر میشوند که یک پروکسی ایمن تماسها را به یک قرارداد ایمن تکی اختصاص میدهد که هزینه استقرار را کاهش میدهد. کارخانه پروکسی ایمن میتواند یک پروکسی ایجاد کند و راهاندازی را در یک تراکنش اجرا کند. هیچیک از اینها «هوش مصنوعی» نیست، اما لولهکشی است که اتوماسیون کنترلشده را ممکن میسازد.کنترلهای برنامهپذیر برای اتوماسیون ایمنترسطوح کنترلی که واقعاً اتوماسیون را کار میکنند در داخل ایمن قرار دارند، نه در داخل مدل. آستانه چند امضایی ایمن ابزار خشن است. ماژولها و محافظها چاقوهای جراحی هستند و ایمن آنها را به عنوان امنیتی بحرانی علامتگذاری میکند.ماژولها آنچه را که یک ایمن میتواند انجام دهد با فعال کردن الگوهای دسترسی جایگزین و مجوزهای دقیق گسترش میدهند. مستندات ایمن مثالهایی مانند محدودیتهای مجوز و جریانهای بازیابی را ذکر میکند و به وضوح بیان میکند که یک ایمن پایه به هیچ ماژولی نیاز ندارد. افزودن یا حذف یک ماژول نیاز به تأیید توسط آستانه مالک دارد و ماژولها باید به اندازه بقیه قراردادهای ایمن ایمن باشند زیرا میتوانند آنچه را که قابل اجرا است گسترش دهند.
محافظها اهرم متفاوتی هستند. یک محافظ میتواند تراکنشها را بر اساس منطق محافظ بپذیرد یا رد کند. ایمن همچنین هشدار میدهد که محافظها امنیتی بحرانی هستند و یک محافظ مخرب میتواند از اجرای تراکنشها جلوگیری کند و دسترسی به وجوه ذخیره شده در ایمن را مسدود کند. این حالت شکست است که مردم زمانی که محافظها را مانند «ایمنی اضافی» در نظر میگیرند، از دست میدهند. یک محافظ یک قرارداد دروازهبان است.
اگر اشتباه یا خصمانه باشد، ایمن میتواند به طور عملی خراب شود.ایمن همچنین از تراکنشهای حمایتشده و پرداختهای مبتنی بر توکن «گاز» از طریق یک سرویس رله که توکنهای ERC20 پشتیبانیشده را میپذیرد و تراکنشها را در حالی که گاز را در «ETH» پرداخت میکند، پشتیبانی میکند. همان مسیر رله میتواند برای جریانهای بدون اتر استفاده شود که در آن یک شخص ثالث هزینهها را به نمایندگی از یک ایمن پرداخت میکند. برای سیستمهای عامل، این کمتر به راحتی و بیشتر به طراحی عملیاتی مربوط میشود. اگر انتظار میرود که عامل هرگونه تراکنش را ارسال کند، فرضیات گاز و رله بخشی از مرز مجوز هستند.این جایی است که «حلقه عامل ارز دیجیتال» به صورت عینی تبدیل میشود: درک و استنتاج میتواند سریع و ارزان باشد، اما عمل یک تراکنش است که باید از بررسیهای آستانه، مجوزهای ماژول و منطق محافظ عبور کند قبل از اینکه به زنجیره برسد.
ملاحظات استقرار و پشتیبانی شبکهبسیاری از طراحیهای عامل به دلیل یک دلیل خستهکننده شکست میخورند: فرض میشود که پشته در زنجیرهها یکنواخت است. ایمن یک لیست شبکههای پشتیبانیشده منتشر میکند که نسخههای حساب هوشمند و در دسترس بودن ویژگی یا ماژول را در هر زنجیره نشان میدهد، از جمله ماژولهایی مانند Safe 4337، Safe Passkey و Safe Recovery. این صفحه به طور مؤثری یک ماتریس سازگاری است و مهم است زیرا «ما فقط از ماژول X استفاده خواهیم کرد» یک برنامه نیست اگر زنجیره هدف از آن پشتیبانی نکند.حتی در داخل اکوسیستم ایمن، نسخهها بر اساس شبکه متفاوت هستند. لیست شبکههای پشتیبانیشده نسخههای مختلف حساب هوشمند را نشان میدهد (به عنوان مثال v1.5.0، v1.4.1، v1.3.0 و قدیمیتر) و سپس نشان میدهد که کدام خدمات و ماژولها در هر زنجیره در دسترس هستند. این نوع جزئیات است که تصمیم میگیرد آیا یک جریان کاری عاملی میتواند به صورت طراحی شده مستقر شود یا نیاز به وضعیت اجرایی متفاوتی دارد.
این همچنین جایی است که دو نیمه خط لوله باید به طور جداگانه بررسی شوند. پست MCP داین دسترسی در بیش از ۱۰۰ بلاکچین را توصیف میکند، در حالی که پست CLI بومی عامل داین دسترسی در بیش از ۱۳۰ زنجیره را توصیف میکند. این اختلاف به خودی خود یک مشکل نیست، اما یادآوری است که «پوشش زنجیره» را به عنوان یک مورد تأیید در نظر بگیرید، نه کپی بازاریابی.
یک چکلیست عملیاتی حداقلی ظاهر میشود:
۱. تأیید کنید که لایه داده زنجیره هدف و جداول پروتکل خاص مورد نیاز برای مرحله درک عامل را پوشش میدهد. ۲. تأیید کنید که لایه اجرا از نسخه ایمن و ماژولها یا ویژگیهای خاصی که سیاست به آن وابسته است، پشتیبانی میکند. ۳. تنها در این صورت پل بین آنها را طراحی کنید، زیرا پل جایی است که مجوزها و حالتهای شکست زندگی میکنند.
محدودیتها و ریسکهای باز برای نظارت
منابع بلوکهای ساختاری قدرتمندی را توصیف میکنند، اما آنها یک معماری مرجع کامل برای یک عامل خودمختار که هم تحلیل میکند و هم اجرا میکند، ارائه نمیدهند. این شکاف مهم است زیرا خودمختاری یک کلید نیست. این یک طیف است و نقطه ایمن در آن طیف به این بستگی دارد که لایه اجرایی چقدر اختیار میدهد.
دو محدودیت بلافاصله نمایان میشوند. اول، دسترسی به ابزار تنها به اندازه ساختار آن خوب است. MCP و CLI دونه به گونهای طراحی شدهاند که خروجیهای قابل مصرف برای ماشین را برگردانند، که در مسیر درستی است، اما منابع قابلیت اطمینان، نرخ خطا یا اینکه چقدر اوقات عوامل درخواستهای نادرست تولید میکنند که هنوز نتایج قابل قبولی به نظر میرسند را کمیت نمیکنند. دوم، نقاط گسترش Safe بهطور صریح بحرانی از نظر امنیتی هستند.
ماژولها میتوانند مجوزهای اجرایی را گسترش دهند و نگهبانان میتوانند اجرای کامل را مسدود کنند. اینها ریسکهای انتزاعی نیستند.
اینها محدودیتهای طراحی هستند.همچنین یک محدودیت حاکمیتی و عملیاتی وجود دارد که در چرخههای هیجان نادیده گرفته میشود. اگر یک عامل به یک ماژول، نگهبان یا مسیر رله خاصی وابسته باشد، تغییرات سیاست، بهروزرسانیها یا شکافهای پشتیبانی خاص زنجیره بخشی از سطح ریسک عامل میشود. ماتریس شبکههای پشتیبانی شده Safe وجود دارد زیرا در دسترس بودن ویژگیها یکنواخت نیست.در نهایت، بحث «TEE» تمایل دارد به عنوان یک درمان همهجانبه مطرح شود.
یک tee میتواند به جداسازی اسرار و تأیید اجرای کد کمک کند، اما نیاز به یک مرز مجوز حساب هوشمند را جایگزین نمیکند. حتی با نگهداری کلید قویتر، اشتباه پرهزینه هنوز هم دادن یک نقطه شکست واحد و اختیارات نامحدود به نرمافزار است.عوامل کریپتو واقعی میشوند زیرا زیرساخت واقعی میشود. بخش سخت هنوز همان است: جدا کردن هوش از اجرا، سپس محدود کردن پل بهگونهای که سیستم بتواند با سرمایه اعتماد شود.نتیجهگیری
من دیدهام که تیمها بر انتخاب مدل وسواس دارند و بخشی را که واقعاً تصمیم میگیرد آیا یک عامل قابل استفاده است نادیده میگیرند: مرز مجوز. به محض اینکه یک عامل بتواند از یک EOA با کلید واحد پیشنهاد دهد و اجرا کند، کل سیستم بدترین مدل امنیتی ممکن برای اتوماسیون را به ارث میبرد. یک کلید نشت کرده، یک میزبان آسیبدیده، یک ادغام بد و همه چیز تمام است.
آنچه که من دیدهام که پابرجا مانده، رفتار با ابزارهای ساختاری به سبک دونه به عنوان مغز فقط خواندنی است، سپس مجبور کردن اجرا از طریق آستانه Safe تا زمانی که جریان کار خود را ثابت کند. ماژولها و نگهبانان جایی هستند که اتوماسیون واقعی میشود و Safe بهطور صریح بیان میکند که آنها بحرانی از نظر امنیتی هستند. این رویکرد باعث میشود که «عوامل در کریپتو» به یک رابط fancy برای امضای اشتباهات تبدیل نشوند.
منابع
دونه
دونه
مستندات Safe
مستندات Safe
پرسشهای متداول
حلقه عامل در عوامل کریپتو چیست؟
بیشتر سیستمها از یک حلقه درک-تصمیم-عمل پیروی میکنند: عامل دادههای ساختاریافته زنجیرهای را جمعآوری میکند، استنتاج انجام میدهد تا یک قصد شکل بگیرد، سپس یک تراکنش پیشنهاد یا ارسال میکند. انتخاب طراحی کلیدی این است که آیا مرحله "عمل" توسط آستانه حساب هوشمند محدود شده است یا اجازه دارد به طور خودکار اجرا شود.
چگونه عوامل هوش مصنوعی بدون کلیک بر روی داشبوردها دادههای زنجیرهای را دریافت میکنند؟
آنها از رابطهای ابزاری ساختاریافته استفاده میکنند که میتوانند مجموعه دادهها را جستجو کنند، پرسشها را تولید کنند، آنها را اجرا کنند و نتایج را در فرمتهای قابل خواندن توسط ماشین بازگردانند. سرور MCP داین و CLI داین نمونههایی هستند که به عوامل اجازه میدهند جداول را کشف کرده و DuneSQL را اجرا کنند و خروجیها را به عنوان داده به جای اسکرینشاتها بازگردانند.
چرا فقط به یک عامل هوش مصنوعی یک کیف پول EOA ندهیم؟
یک EOA توسط یک کلید خصوصی واحد کنترل میشود که به یک نقطه شکست واحد برای نرمافزار بدون نظارت تبدیل میشود. حسابهای هوشمند مجوز را به منطق قرارداد هوشمند منتقل میکنند، بنابراین اجرا میتواند به چندین مالک، آستانهها و بررسیهای اضافی نیاز داشته باشد.
ماژولها و محافظتهای Safe واقعاً چه کاری برای یک عامل انجام میدهند؟
ماژولها میتوانند الگوهای دسترسی جایگزین و مجوزهای دقیق، مانند محدودیتهای مجوز یا جریانهای بازیابی را فعال کنند و برای اضافه یا حذف نیاز به تأیید آستانه مالک دارند. محافظتها میتوانند تراکنشها را بر اساس منطق محافظت قبول یا رد کنند و Safe هشدار میدهد که یک محافظ مخرب میتواند تراکنشها را مسدود کرده و دسترسی به وجوه را قفل کند.
آیا ویژگیهای حساب هوشمند در هر زنجیرهای به یک شکل کار میکنند؟
خیر. Safe فهرست شبکههای پشتیبانیشدهای را منتشر میکند که نسخههای حساب هوشمند و ماژولها یا خدمات موجود در هر زنجیره را نشان میدهد، از جمله نمونههایی مانند Safe 4337، Safe Passkey و Safe Recovery. طراحیهای عامل که فرض میکنند یک ماژول خاص وجود دارد، باید ابتدا پشتیبانی زنجیره را تأیید کنند.
