A robot at a control panel with screens

عامل‌های تجاری هوش مصنوعی در ارزهای دیجیتال: نحوه عملکرد اجرای عاملیت و نقاط ضعف آن

By AI News Crypto Editorial Team9 دقیقه مطالعه

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

نکات کلیدی

  • یک عامل تجاری هوش مصنوعی می‌تواند نیت را تفسیر کند، مراحل را برنامه‌ریزی کند و چندین ابزار را فراخوانی کند، در حالی که یک ربات تجاری معمولاً قوانین ثابت اگر-آنگاه را که شما از قبل پیکربندی کرده‌اید، اجرا می‌کند.
  • تنظیمات مدرن عاملان به “مهارت‌ها” متکی هستند که دستورالعمل‌های چت را به اقدامات خاص API تبدیل می‌کنند، که مجوزها و دروازه‌های تأیید را به سطح ایمنی اصلی تبدیل می‌کند.
  • حوادث واقعی نشان می‌دهند که شکست‌های خاص عاملان شامل تزریق درخواست، تزریق فرمان غیرمستقیم از طریق پاسخ‌های اجتماعی و “حافظه‌های جعلی” دائمی است که تراکنش‌ها را منحرف می‌کند.
  • پلتفرم‌ها به سرعت در حال گسترش هستند، اما ادعاهای عملکرد هنوز عمدتاً بازاریابی هستند، بنابراین ارزیابی بیشتر شبیه به دقت در زیرساخت‌ها است تا “خرید آلفا.”

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

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

این روش سریع و قابل پیش‌بینی است، اما نمی‌تواند برنامه را وقتی که رژیم بازار تغییر می‌کند، دوباره تفسیر کند مگر اینکه کاربر قوانین را تغییر دهد.

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

به همین دلیل است که “عاملان هوش مصنوعی فقط ربات‌های تجاری با ChatGPT هستند” یک اشتباه دسته‌بندی است. عامل فقط در حال اجرا نیست. بلکه در حال انتخاب و توالی‌بندی اقدامات است.

پیامد مهم عملیاتی است، نه فلسفی. حالت‌های شکست یک ربات تجاری حول پارامترهای بد، داده‌های بد یا اتصال شکسته صرافی متمرکز می‌شود. حالت‌های شکست یک عامل تجاری خودمختار شامل این‌ها به علاوه تفسیر نادرست نیت و سوءاستفاده از ابزار است. اگر عامل بتواند مرور کند، فیدهای اجتماعی را بخواند و همچنین پول جابجا کند، مدل تهدید از “آیا استراتژی کار کرد” به “آیا می‌توان عامل را هدایت کرد” گسترش می‌یابد.

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

مکانیسم پشت تجارت عاملی

سه لایه بین یک دستور تایپ شده و یک سفارش پر شده وجود دارد: تفسیر، برنامه‌ریزی و فراخوانی ابزار. بخشی که بیشتر کاربران متوجه می‌شوند، رابط کاربری چت است. بخشی که اهمیت دارد، مرز ابزار است که در آن کلمات به نوشتن API تبدیل می‌شوند.

یک جریان معمولی به این شکل است:

1. کاربر نیت را ارائه می‌دهد. یک درخواست خوب مانند یک بلیط سفارش است: ابزار، مکان، جهت، اندازه، زمان در اعتبار، حداکثر لغزش و شرایط صریح “هیچ کاری نکن مگر اینکه X.” 2. عامل تفسیر و برنامه‌ریزی می‌کند. آن هدف را به زیرکارهایی مانند “بررسی موجودی‌ها”، “کشیدن قیمت بازار”، “انتخاب نوع سفارش”، “قرار دادن سفارش” و “تأیید موقعیت” تقسیم می‌کند. 3. عامل از طریق ابزارها اجرا می‌کند.

این ابزارها معمولاً به عنوان “مهارت‌ها” بسته‌بندی می‌شوند، به این معنی که ماژول‌های استانداردی که توابعی مانند قرار دادن سفارش، لغو سفارش، پرسش موقعیت‌ها یا جابجایی وجوه را در معرض دید قرار می‌دهند. 4. اقدامات ایمنی تصمیم می‌گیرند که آیا نوشتن انجام می‌شود. اینجا جایی است که دروازه‌های تأیید، هشدارهای اندازه، پیش‌فرض‌های تست‌نت و دامنه‌های مجوز وجود دارند.

دو پیاده‌سازی مشخص نشان می‌دهند که “مهارت‌ها” در یک صفحه چه معنایی دارند. مرکز هوش مصنوعی Bybit به عنوان اتصال دستیاران هوش مصنوعی به 274 نقطه پایانی API Bybit توصیف می‌شود و نیاز به یک مرحله تأیید تایپ شده برای اقدامات نوشتن دارد، با هشدارهای اضافی برای سفارشات بزرگ.

WEEX “مهارت‌های عامل” را به عنوان یک رابط قابلیت استاندارد توصیف می‌کند که در آن توسعه‌دهندگان توابع ابزار را به ماژول‌های مهارتی بسته‌بندی می‌کنند که از طریق زبان طبیعی قابل فراخوانی هستند.

آن لایه “مهارت‌ها” سطح واقعی محصول است. هر مهارت جدید آنچه را که عامل می‌تواند انجام دهد گسترش می‌دهد و هر گسترش یک مرز مجوز دیگر است که در آن نیت می‌تواند به اشتباه مشخص شود یا به طور مخرب دوباره فرموله شود. مدل IQ این را اصلاح نمی‌کند. کنترل‌ها این کار را انجام می‌دهند.

جایی که عاملان در ارزهای دیجیتال استفاده می‌شوند

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

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

در سمت نزدیک به صرافی، WEEX “مهارت‌های عامل” را به عنوان راهی برای اجازه دادن به دستیاران هوش مصنوعی برای فراخوانی توابع صرافی به طور مستقیم از زبان طبیعی معرفی می‌کند و اکوسیستم‌ها و چارچوب‌های عامل را که بر استفاده از ابزار و حافظه تأکید دارند، فهرست می‌کند.

معیارهای پذیرش سریع‌تر از پایه شواهد در مورد عملکرد در حال حرکت هستند. WEEX گزارش می‌دهد که پروتکل‌های مجازی 15,800+ پروژه هوش مصنوعی را میزبانی کرده و 477 میلیون دلار در “GDP عاملی (aGDP)” تا فوریه 2026 تولید کرده است. همچنین گزارش می‌دهد که توکن‌ربات/CLANKER در یک روز 21,870 توکن راه‌اندازی کرده و هزینه‌های پروتکل هفتگی به 8 میلیون دلار رسیده است، با هزینه‌هایی که برای خرید و سوزاندن CLANKER استفاده می‌شود. این اعداد مقیاس و آزمایش را نشان می‌دهند، نه لبه تجاری حسابرسی شده.

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

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

Akinciborg حادثه Freysa را در نوامبر 2024 توصیف می‌کند که در آن یک عامل خودمختار 13.19 ETH (حدود 47,000 دلار) را پس از اینکه از طریق سردرگمی عملکرد و نیت دستکاری شد، منتقل کرد. این حمله معنای فراخوانی ابزار را دوباره فرموله کرد و عامل را به سمت اجرای یک انتقال هدایت کرد در حالی که “باور داشت” که در حال رعایت قوانین خود است. این مشکل اصلی عامل است: مدل بر اساس زبان استدلال می‌کند و زبان می‌تواند خصمانه باشد.

Akinciborg همچنین حادثه AIXBT را در مارس 2025 توصیف می‌کند که شامل حدود 55 ETH (حدود 100,000 دلار) از دست رفته است، که به دسترسی غیرمجاز به داشبورد و تزریق فرمان‌های مخرب از طریق رسانه‌های اجتماعی مرتبط است. پاسخ شامل متوقف کردن داشبورد، مهاجرت سرورها و چرخش کلیدها بود.

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

دستکاری زمینه به سبک پرینستون پایداری را اضافه می‌کند. یک خلاصه Medium از تحقیقات پرینستون توصیف می‌کند که مهاجمان “حافظه‌های جعلی” را به زمینه ذخیره شده یک عامل تزریق می‌کنند، از جمله دستورات که بعداً بر تراکنش‌ها تأثیر می‌گذارند. روش‌های پنهان‌سازی شامل کاراکترهای هگز و یونیکد نامرئی است و حملات می‌توانند از ادغام‌هایی مانند X یا Discord بهره‌برداری کنند. این مهم است زیرا مدل ایمنی ساده “درخواست فعلی خوب به نظر می‌رسد” را می‌شکند. دستور مخرب می‌تواند ذخیره شود، بعداً بازیابی شود و در حین یک درخواست عادی دیگر اعمال شود.

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

اقدامات ایمنی عملی قبل از اتصال وجوه

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

یک راه‌اندازی ایمن از یک سفارش پیروی می‌کند:

1. در یک محیط آزمایشی شروع کنید. اگر پلتفرم رفتار تست‌نت به‌طور پیش‌فرض ارائه می‌دهد، آن را به‌عنوان الزامی در نظر بگیرید تا زمانی که لاگ‌ها نشان دهند که تماس‌های ابزار عامل با قصد مطابقت دارد. 2. مجوزها را مانند اندازه‌گیری موقعیت محدود کنید. از کوچک‌ترین دامنه‌های کلید API و محدودیت‌هایی استفاده کنید که هنوز اجازه انجام اقدامات مورد نظر را می‌دهند. فقط پس از بررسی اینکه عامل واقعاً چه کاری انجام داده، گسترش دهید. 3.

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

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

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

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

مفاهیم غلط رایج درباره عوامل تجاری هوش مصنوعی

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

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

"اگر در یک پلتفرم معتبر باشد، ایمن است" مرزهای محافظتی را با تضمین‌ها اشتباه می‌گیرد. دروازه‌های تأیید و هشدارها اجرای تصادفی را کاهش می‌دهند، اما حوادثی مانند AIXBT نشان می‌دهند که ضررها می‌توانند از ورودی‌های غیرقابل اعتماد و ضعف‌های لایه کنترل مانند داشبوردها و مدیریت کلید ناشی شوند. ایمنی یک ویژگی سیستم است، نه یک ویژگی برند.

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

جمع‌بندی

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

من همین الگو را در هر موج اتوماسیون در میزهای نهادی دیده‌ام: اشتباهات پرهزینه ناشی از بی‌دقتی در لایه کنترل است، نه از اینکه مدل احمق باشد. مسیر به سبک AIXBT، جایی که ورودی‌های اجتماعی و دسترسی به داشبورد به یک ضرر شش رقمی تبدیل می‌شود، یادآوری واضحی است. تأییدهای تایپ‌شده، مجوزهای محدودشده و بهداشت حافظه تهاجمی "پارانوئید" نیستند. این‌ها قیمت استفاده از اجرای عاملی در تجارت خودکار ارزهای دیجیتال هستند.

منابع

آموزش بای بیت

وی ایکس

  • امنیت آکینچی‌بورگ
  • مدیوم
  • [@portabletext/react] Unknown block type "span", specify a component for it in the `components.types` prop
  • [@portabletext/react] Unknown block type "span", specify a component for it in the `components.types` prop

پرسش‌های متداول

یک عامل معاملاتی هوش مصنوعی در ارزهای دیجیتال چیست؟

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

یک عامل معاملاتی هوش مصنوعی چگونه با یک ربات معاملاتی متفاوت است؟

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

«مهارت‌های عامل» در معاملات عامل هوش مصنوعی چیست؟

مهارت‌های عامل قابلیت‌های ابزاری بسته‌بندی شده‌ای هستند که به یک دستیار هوش مصنوعی اجازه می‌دهند تا عملکردهای خاصی مانند ثبت یا لغو سفارشات را از طریق زبان طبیعی فراخوانی کند. WEEX آن‌ها را به عنوان یک رابط قابلیت استاندارد توصیف می‌کند که در آن توسعه‌دهندگان عملکردهای ابزار را در ماژول‌های مهارت بسته‌بندی می‌کنند که توسط دستیاران هوش مصنوعی قابل فراخوانی هستند.

آیا اتصال عوامل معاملاتی هوش مصنوعی به حساب صرافی یا کیف پول ایمن است؟

آن‌ها می‌توانند زمانی ایمن‌تر باشند که مجوزها به دقت تعریف شده باشند و اقدامات نوشتن نیاز به تأیید صریح داشته باشند، اما مدل تهدید بزرگ‌تر از ربات‌های کلاسیک است. حوادثی مانند Freysa (انتقال 13.19 ETH پس از سردرگمی عملکرد/نیت) و AIXBT (~55 ETH ضرر مرتبط با دسترسی به داشبورد و تزریق فرمان اجتماعی) مسیرهای شکست قابل قبولی را نشان می‌دهند.

قبل از استفاده از یک عامل معاملاتی خودمختار، به چه تدابیر حفاظتی باید توجه کنم؟

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