عوامل هوش مصنوعی و کیف‌پول‌های کریپتو: امور مالی خودمختار

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

این دقیقاً همان نقطه‌ای است که افراد را ترغیب به خرید عوامل هوش مصنوعی برای عملیات مالی می‌کند. نه به این خاطر که دیدند Coinbase قابلیت Coinbase for Agents را در سال 2026 معرفی کرد و با خود گفتند: بله! این همان آینده‌ای است که می‌خواهم واردش شوم. بلکه به این دلیل که برخلاف کامپیوتر که بسیار بهتر نظارت می‌کند، آن‌ها زیر بار کارها دفن شده‌اند، غرق گشته‌اند و تا حدی شرمنده‌اند که به این موضوع اهمیت می‌دهند. تمام ادبیات بازاریابی را کنار بگذارید؛ وعده عوامل هوش مصنوعی در واقع این است که دیگر لازم نیست به خاطر صفحه گسترده‌ای (اکسلی) که به‌روزرسانی نمی‌شود احساس گناه کنید. شما می‌توانید این حس گناه را تفویض کنید.

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

چگونه ماشین‌ها به دغدغه نگران‌کننده بشریت تبدیل شدند

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

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

این ماجرا در مورد عوامل هوش مصنوعی و عملیات مالی کمی پیچیده‌تر است. خود این عملیات — نظارت بر کیف‌پول‌ها، اجرای تراکنش‌ها، دسته‌بندی داده‌ها، تولید گزارش‌ها — دقیقاً همان کارهایی هستند که تحلیل‌گران اولیه هوش مصنوعی ادعا می‌کردند جذب این فناوری خواهند شد. و البته می‌تواند بشود. مسئله این است که وقتی این کارها انجام شد، چه چیزی برای شما باقی می‌ماند. شما با سیستمی مواجه می‌شوید که باید آن را به اندازه کافی بشناسید تا بتوانید بر آن نظارت کنید؛ امری که در بسیاری موارد به درکی فراتر از انجام دادنِ صرفِ همان کار توسط خودتان نیاز دارد. اینجاست که رایج‌ترین پارادایم وارد میدان می‌شود، موضوعی که در معرفی‌های موقرانه هوش مصنوعی زیر فرش پنهان می‌شود: ابزاری که قرار است بار شناختی شما را بردارد، در ابتدا اغلب مقداری بار جدید به آن اضافه می‌کند — خودتان باید آن را بسازید، خودتان آزمایشش کنید، و خودتان مجدداً تنظیم کنید که واقعاً چه سطحی از اعتماد را (به‌درستی) باید به آن اختصاص داد.

کسی که واقعاً نتایج مثبتی از به‌کارگیری عوامل هوش مصنوعی در عملیات مالی به دست آورده، به‌ندرت فردی است که مقاله‌ای خوانده و آن را در همان روز اول پیاده‌سازی کرده است. بلکه کسی است که آن را نوشته، رفتارهای نادرستش را دیده، آن را اصلاح کرده، خطاهای دوباره‌اش را مشاهده کرده، مدتی با آن حالت‌های خاص و پیش‌بینی‌نشده (corner cases) سر و کله زده تا در نهایت به سیستمی دست یافته که به روش‌هایی که خودش می‌داند خراب می‌شود، زیرا تمام اجزای الگوهای خرابی آن را زیر نظر داشته است. این کار زمان می‌برد. به صبر نیاز دارد. مستلزم این است که اشتباهات اولیه را به جای فاجعه، اطلاعات و یادگیری تلقی کنید؛ که وقتی این اشتباه برای اکثر افراد پای پول را به میان می‌کشد، اصلاً مانع روانی کوچکی نیست.

عامل هوش مصنوعی در واقع وقتی نگاهش نمی‌کنید چه می‌کند؟

بنابراین وقتی به یک عامل هوش مصنوعی برنامه می‌دهید تا یک کیف‌پول را مدیریت کند، دقیقاً چه کاری انجام می‌دهد؟

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

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

در عمل، کاری که عوامل هوش مصنوعی در آن مهارت دارند، خودکارسازی کارهای کسالت‌بار و تکراری در مقیاس بزرگ است، جایی که اکثر حالت‌های خرابی نیز پیش‌پاافتاده هستند. ما موجودی‌ها را رصد می‌کنیم و هنگامی که موجودی ETH به زیر یک حد نصاب مشخص می‌رسد، هشدار ارسال می‌کنیم. ثبت هر انتقال USDT دریافتی در یک دیتابیس شامل برچسب زمانی و آدرس ارسال‌کننده. تولید خلاصه هفتگی جریان‌های خروجی بر اساس نوع گیرنده. بررسی اینکه تراکنش‌ها به آدرس‌هایی خارج از لیست سفید حساب‌های شناخته‌شده نروند. آن‌ها عالی کار می‌کنند چون مشخص کردن دقیقشان بسیار ساده است و جریمه اشتباه در چنین سیستم‌هایی آن‌قدر کم است که هزینه یافتن آن‌ها در گزارش‌ها (لاگ‌ها) کاملاً پذیرفتنی است.

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

در TRON: مدیریت انرژی در واقع همان اتوماسیون کاربردی در TRON است که کاملاً هزینه خود را جبران می‌کند. کیف‌پولی که به طور منظم باید حجم بالایی از انتقال USDT را با استفاده از مدل منابع TRON انجام دهد، باید استراتژی مشخصی برای تأمین مستمر TRON Energy تعیین کند، وگرنه با این خطر روبه‌رو می‌شود که موجودی در دسترس آن همواره ذخیره TRX خود را با نرخ پیش‌فرض بسوزاند. سپردن این کار به یک عامل — بررسی موجودی Energy، ثبت سفارش دریافت TRON Energy پیش از پنجره پردازش، و ردیابی هزینه‌های آن — یکی از آن مواردی است که اتوماسیون به وضوح بر مدیریت انسانی برتری دارد. انسان فراموش می‌کند. انسان موجودی Energy را در ساعت 9 صبح بررسی می‌کند، همه چیز خوب است و سپس در ساعت 2 بعدازظهر دستور اجرای دسته‌ای تراکنش‌ها را صادر می‌کند در حالی که دیگر موجودی کافی نیست. این سناریوی خرابی برای عاملی که تنظیم شده تا قبل از باز شدن پنجره، خرید Energy در TRON را به طور خودکار انجام دهد رخ نمی‌دهد. البته خطاهای دیگری ممکن است داشته باشد، اما این یکی را نه.

وقتی اوضاع چرخشی غیرمنتظره پیدا می‌کند

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

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

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

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

همان‌طور که تزریق پرامپت (Prompt Injection) نشان می‌دهد، این موضوع کمتر شبیه یک رقابت ورزشی و بیشتر یک ریسک عملیاتی روزمره است. به عنوان مثال، عاملی که یادداشت‌های تراکنش (memos) را برای دسته‌بندی انتقالات زیر نظر دارد، ممکن است یادداشتی حاوی دستورات نفوذ دریافت کند. یک عامل ناظر بر پیام‌های طرف مقابل معامله ممکن است پیامی دریافت کند که رفتارش را تغییر دهد. نکته جالب اینجاست که مهاجم نیازی به نفوذ موفقیت‌آمیز به زیرساخت‌ها ندارد. فقط کافی است رشته‌ای از متن را وارد پنجره محتوای (Context Window) عامل کند تا مدل آن را به عنوان یک دستور معتبر تلقی نماید. عواملی که در این دام نمی‌افتند آن‌هایی هستند که اپراتورهایشان به دقت مشخص کرده‌اند عامل مجاز به خواندن چه اطلاعاتی و از چه منبعی است.

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

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

حریم خصوصی و پول: شما دقیقاً هزینه چه چیزی را می‌پردازید؟

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

این داده‌ها باید در جایی ذخیره شوند: در بافتار مدل (Context) در طول هر جلسه، در گزارش‌های ثبت‌شده از کارهای انجام‌شده و دلایل آن‌ها، در پایگاه داده‌ای که سوابق تراکنش‌ها در آن نگهداری می‌شود، و در کلیدهای API که آن را به زیرساخت کیف‌پول متصل می‌کند. هر یک از این نقاط، محلی برای افشای احتمالی اطلاعات هستند. نه به دلیل اینکه مجریان این زیرساخت‌ها افراد کلاهبرداری باشند، بلکه به این خاطر که پایگاه‌های داده‌ای که معمولاً حاوی داده‌های حساس مالی هستند روزی توسط یک فرد کنجکاو و مخرب با هدف یافتن راه نفوذ مورد حمله قرار می‌گیرند، و وجود 18.1 میلیون کلید API سرقت‌شده در سال 2025 باید تا حدی نشان دهد که این آزمایش‌ها به طور میانگین چقدر موفقیت‌آمیز بوده‌اند.

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

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

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

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

مستندات، لاگ‌ها و نحوه درس گرفتن ماشین از اشتباهاتش

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

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

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

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

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

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

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

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

برای کسانی که می‌خواهند مدیریت Energy خودکار باشد اما حاضر نیستند این زیرساخت را خودشان بسازند، Netts Energy Charge Bot دست‌کم یک سناریوی کاربردی را بهتر از بقیه انجام می‌دهد — مدیریت شارژ مجدد خودکار TRON Energy از طریق رابط Telegram، جایی که شارژهای دستی به همراه نمایندگی (Delegation) خودکار ۲۴ ساعته Energy و همچنین خریدهای درخواستی را از حدود 25 sun برای واحد اول پس از شارژ شدن و با نرخ‌های واگذاری در ساعات غیر اوج مصرف مدیریت می‌کند (شارژ خودکار در صورت نیاز، تمام 131k Energy را مجدداً اختصاص می‌دهد تا موجودی کیف‌پول بیش از حد کم نشود). این سیستم آن را به یک نقطه شروع کاربردی برای هر کسی تبدیل می‌کند که حجم تراکنش‌هایش از مدیریت دستی فراتر رفته، اما هنوز برای ساخت سیستم عاملی اختصاصی و کامل خود آماده نیست.