وكلاء الذكاء الاصطناعي ومحافظ الكريبتو: التمويل الذاتي

أنت لا تقرأ هذا لأنك قرأت مقالاً فكرياً جذاباً حول مستقبل التمويل. بل تفعل ذلك لأن محفظتك شهدت حوالي 4000 معاملة هذا الشهر، وقمت بفحصها يدوياً حتى اقتربت من نهاية الأسبوع الثالث ثم توقفت تماماً عن النظر إليها لأنها جعلتك تشعر بالإحباط. ثم أصبحت الأمور تسير بعشوائية، وفي مرحلة ما كنت تقنع نفسك بأنك ستعوض هذا التراكم يوم الأحد. والآن مرّت ثلاثة أيام أحد متتالية دون تقليص القوائم. والفواتير لا تزال كما هي. ولم يقم أحد بفحص دقيق لتلك التحويلات الصغيرة التي رأيتها قبل أسبوعين. أنت تدير عمليات كريبتو ولا تجرؤ حتى على النظر إليها.

هذا هو السبب وراء شراء الناس لوكلاء الذكاء الاصطناعي للعمليات المالية. ليس لأنهم رأوا إعلان Coinbase عن Coinbase for Agents في عام 2026 وقالوا لأنفسهم: نعم! هذا هو المستقبل الذي أريد الانخراط فيه. بل لأنهم، على عكس الكمبيوتر الذي يبرع تماماً في المراقبة، غارقون ومحاصرون ويشعرون ببعض الخجل من اهتمامهم بهذا الأمر. تخلَّ عن كل لغة التسويق، ووعد وكلاء الذكاء الاصطناعي في جوهره هو ببساطة وعد بأنه لم يعد عليك الشعور بالذنب حيال جدول البيانات الذي لم يتم تحديثه. يمكنك الآن تفويض الشعور بالذنب.

ما لا يخبرك به أحد هو أن نقل المسؤولية لا يعني القضاء على المخاطر. بل هو أسوأ في بعض النواحي. على الأقل كنت تراقب محفظتك المسكينة حتى لو كانت مراقبة سيئة. كان القلق بمثابة إشارة تنبيه. والآن أصبحت الآلة هي التي تراقب، والآلة لا تشعر بالقلق — مما يعني فقدان تلك الإشارة. ستتعامل الآلة مع الأمر إذا حدث خطأ ما، وستفعل كل ما برمجت للقيام به، والبرمجة تكون جيدة فقط بقدر جودة المبرمج، وذلك المبرمج كان أنت في فترة بعد ظهر يوم الثلاثاء عندما كان ذهنك شاردًا.

كيف أصبحت الآلات بصمة القلق للبشرية

هذا خيال بشري قديم يسبق الثورة الصناعية: الآلة التي تنجز كل الأعمال الشاقة، تاركة لك الحرية للقيام بما هو ممتع. عمال النسيج الذين تحولوا إلى حركة اللوديين في عقد 1810 لم يكونوا جهلاء غير قادرين على استشراف المستقبل. لقد تصوروا بدقة جزءاً كبيراً من المستقبل. ورغم أنهم جنوا بعض الفوائد، إلا أن كل هذا حل أيضاً محل عملهم: وكان ذلك أيضاً أثراً للنول الآلي. الحرية التي وعد بها — الراحة، والارتقاء بالعمل، والوقت لحياة بشرية أكثر وأفضل — ذهبت في الغالب إلى أصحاب المصانع، وليس إلى العمال الذين تم استبدال عملهم الماهر. إن جزءاً كبيراً من تاريخ الأتمتة هو تاريخ تتدفق فيه الفوائد إلى الأعلى بينما تتجه الاضطرابات إلى الأسفل.

هذا لا يعني أن: الأتمتة أمر سيئ. بل يعني أن الرواية حول الأتمتة تكون دائماً وردية بشكل متوقع ومضللة في الكشف عن التوزيع الحقيقي للتكاليف والمكاسب. وبمجرد أن أصبحت نماذج الذكاء الاصطناعي جيدة بما يكفي لتكون مفيدة — في وقت ما حوالي عام 2022، وتصاعدت بشكل حاد بعد ذلك — كانت الرواية المتفائلة تدور بالكامل حول التعزيز البشري. انتهى الضحك والنكات حول الذكاء الاصطناعي في الوقت نفسه تقريباً الذي بدأت فيه المخاوف بشأن الوظائف. توقعوا السخرية أولاً، ثم القلق، لكن الفارق الزمني بين هاتين الاستجابتين كان أقصر مما حلم به أي شخص.

الأمر أكثر تعقيداً بعض الشيء في حالة وكلاء الذكاء الاصطناعي والعمليات المالية. العمليات نفسها — مراقبة المحافظ، وتنفيذ المعاملات، وتصنيف البيانات، وإنشاء التقارير — هي بالضبط نوع العمل الذي ادعى المعلقون الأوائل على الذكاء الاصطناعي أنه سيتم استيعابه بواسطة التكنولوجيا. ويمكنه ذلك بالفعل. السؤال هو ماذا يتبقى لديك عندما يحدث ذلك. ينتهي بك الأمر بنظام يجب أن تفهمه جيداً بما يكفي للإشراف عليه، وهو ما يتطلب في كثير من الحالات فهماً أكثر مما كان سيتطلبه إنجاز الأمر بنفسك. وهنا يظهر النموذج الأكثر شيوعاً الذي يتم إخفاؤه في المقدمات الأكثر لطفاً لوكلاء الذكاء الاصطناعي: الأداة المصممة لتخفيف عبئك المعرفي غالباً ما تضيف جزءاً منه مجدداً في البداية — حيث تقوم ببنائها، واختبارها، وإعادة معايرة مستوى الثقة الذي ينبغي (بحق) منحه لها.

الشخص الذي حقق بالفعل نتائج إيجابية من استخدام وكلاء الذكاء الاصطناعي في العمليات المالية نادراً ما يكون هو الشخص الذي قرأ مقالاً وطبقه في اليوم الأول. بل هو الشخص الذي كتبه، ورآه يسيء التصرف، وأصلحه، ورآه يسيء التصرف مرة أخرى، ثم تعامل مع تلك الحالات الخاصة لفترة حتى انتهى به الأمر بنظام يتعطل بطرق يعرفها لأنه راقب كل جانب من جوانب أنماط الفشل. هذا يستغرق وقتاً. ويتطلب صبراً. ويتطلب منك اعتبار الأخطاء المبكرة بمثابة معلومات بدلاً من كونها كوارث، وهي ليست عقبة نفسية صغيرة عندما ينطوي الخطأ بالنسبة لمعظم الناس على أموال.

ما يفعله الوكيل فعلياً بينما أنت لا تنظر

إذن، ماذا يفعل وكيل الذكاء الاصطناعي عندما تجدوله لإدارة محفظة؟

إنه يعمل تماماً كما أخبرته. باتساق مذهل ودون أي اعتبار لما إذا كان الشيء الذي أمرته بفعله هو الشيء الصحيح على الإطلاق. فإذا وجهته لرفع تنبيه لأي عملية تتجاوز خمسمائة دولار، فإنه سيرفع تنبيهاً لكل معاملة تتجاوز خمسمائة دولار دون أن يدرك أبداً أن نصفها هو كشف رواتبك الخاص الذي قمت بجدولته كتحويلات متكررة وأنت على دراية به بالفعل. على سبيل المثال، إذا طلبت منه معالجة التحويلات الصادرة بمجرد وجود عشرة تحويلات أو أكثر في قائمة الانتظار، فسوف ينطلق لمعالجة طوابير من عشرة عناصر، بما في ذلك تلك التي تشكلت في الساعة الثالثة صباحاً يوم السبت لأن شخصاً ما أخطأ في إعداد شيء ما وتسبب في حلقة مفرغة. الوكيل لا ينام، ولكن الأهم من ذلك أن الوكيل لا يتردد. التردد هو شكل من أشكال تصحيح الأخطاء لمبادئنا الخاطئة، لكن الوكيل لا يملك أي تردد.

هذا أمر جيد يجب معرفته بالفعل قبل إطلاق وكيل على أي شيء حقيقي. الوكيل ليس موظفاً مبتدئاً لديه مساحة تصرف محدودة وشعور فطري بالبقاء. إنه أشبه بالأتمتة التي تدير إشارات المرور: شديد الثبات ويمكن التنبؤ به؛ غير قادر على إدراك السياق؛ يعتمد تماماً على قيام من كتب النظام بالتفكير في كل حالة استثنائية محتملة مسبقاً. مع إشارات المرور، تكون المدخلات تافهة ويسهل حصر أنماط الفشل. أما عمليات المحافظ فهي أكثر تعقيداً بعض الشيء.

من الناحية العملية، ما يبرع فيه وكلاء الذكاء الاصطناعي هو أتمتة العمل الروتيني المتكرر على نطاق واسع، حيث تكون معظم أنماط الفشل عادية وغير معقدة. كأن نراقب الأرصدة وعندما ينخفض رصيد ETH عن حد معين نرسل تنبيهاً. أو تسجيل كل تحويل USDT مستلم في قاعدة بيانات متضمناً طابعاً زمنياً وعنوان الإرسال. أو إصدار ملخص أسبوعي للتدفقات الخارجة حسب نوع المستلم. أو التحقق من أن المعاملات لا تذهب إلى عناوين خارج القائمة البيضاء للحسابات المعروفة. هذه الأمور تنجح لسهولة تحديدها بدقة، ولأن عواقب الأخطاء في هذا النوع من الأنظمة منخفضة بما يكفي لجعل تكلفة رصدها في السجلات مقبولة.

القدرات المثيرة للاهتمام — تلك التي تظهر في إعلانات المنتجات — تعمل في العروض التوضيحية، ولكن العروض التوضيحية تكون محكومة بدقة شديدة. إذا كانت الحالات الشاذة هي نفسها التي تم تدريب الوكيل عليها، فإنه يبدو بارعاً للغاية في التعرف على أنماط المعاملات الشاذة وتصعيدها للمراجعة. ولكن عندما تقع الحالة الشاذة في نطاق لم يخطر ببال الشخص الذي يكتب التعليمات، يصبح أداؤه أقل جودة بكثير، لأنه إما يتجاهلها تماماً أو ينبه إليها على أحسن تقدير بنفس مستوى الإلحاح الذي ينبه به إلى أمر مبرمج في أنظمته الدفاعية. وإلى أن يحدث خطأ ما، لن تعرف النتيجة التي ستحصل عليها.

TRON: إدارة Energy هي الأتمتة العملية على TRON والتي تعوض تكلفتها فعلياً. المحفظة التي تحتاج بانتظام للتعامل مع حجم تحويلات USDT كبير باستخدام نموذج موارد TRON يجب أن تضع استراتيجية للتزويد المستمر بـ TRON Energy أو تخاطر بجعل رصيدها المتاح يحرق باستمرار مخزونها من TRX بالسعر الافتراضي. إن تكليف وكيل بذلك — لفحص رصيد Energy، وتنفيذ أمر get TRON Energy قبل نافذة المعالجة، وتتبع تكلفة ذلك — يندرج تحت تلك الحالات التي تكون فيها الأتمتة متفوقة بوضوح على الإدارة البشرية. فالإنسان ينسى. قد يتحقق الإنسان من رصيد Energy في الساعة 9 صباحاً عندما يكون كل شيء على ما يرام، ثم في الساعة 2 ظهراً، يقوم بتنفيذ دفعة التحويلات عندما لا يكون الرصيد كافياً. لا يحدث هذا الخطأ مع وكيل تم إعداده للقيام بعملية TRON buy Energy تلقائياً قبل فتح النافذة. لديه أنماط فشل أخرى، ولكن ليس هذا النمط.

عندما تأخذ اللحظة منعطفاً غير متوقع

هناك تجربة نفسية محددة يتحدث عنها جميع من يعملون مع وكلاء الذكاء الاصطناعي بشكل عام (بغض النظر عن الغرض من استخدام الوكيل). تلك اللحظة التي يفعل فيها الوكيل شيئاً لم تخبره به تحديداً ويكون محقاً في ذلك. لا يكون هذا هلوسة. ولا خطأ. بل استنتاج حقيقي — حيث يحدد الوكيل شيئاً في البيانات لم يحدده المشغل كمعيار أبداً، ويعبر عنه بشكل صحيح.

هذه التجربة مربكة للغاية. فالشخص يدرك، على الأقل بطريقة مجردة، أن النموذج يتم تدريبه للبحث عن أنماط داخل بيانات التدريب وإخراج نتائج محتملة إحصائياً. لكن التجربة المحسوسة هي أن هناك شيئاً يراقب بدقة تفوق مراقبته هو. كيان يرى أكثر مما يمكنه رؤيته. وهذا من شأنه أن يربك الكثيرين عن حق — بطرق قد لا تبدو منطقية تماماً لكنها ليست خاطئة كلياً. وبطريقة أكثر موثوقية بكثير من فحص إنسان لنفس البيانات بشكل متقطع، يختلف انتباه الوكيل عن انتباه البشر — فهو ليس انتقائياً بنفس الطريقة، ولا يمل من مدخلات معينة كما نفعل نحن، وليس لديه مصلحة شخصية في تجاهل معلومات قد يكون من غير المريح معرفتها.

أما النقيض لهذه التجربة فهو ما يليها مباشرة، عادة في غضون أسبوع. حيث يرتكب الوكيل خطأ بثقة في غير محلها. يسيء فهم أمر، أو تطرأ حالة استثنائية جديدة لم تتناولها الأوامر فيتعامل معها وفقاً للقاعدة الأقرب مطابقة بدلاً مما كان يقصده المشغل بوضوح. كان هذا حقيقياً جزئياً، وجزئياً هلوسة مر بها الوكيل (والهلوسة خطيرة للغاية خاصة عندما نتحدث عن أنظمة مثل التداول عالي التردد التي تنفذ معاملات مالية).

في نوفمبر 2024، سلطت تجربة Freysa العامة الضوء على هذه الديناميكية بشكل واضح. تم مؤخراً منح وكيل ذكاء اصطناعي مجمع جوائز بقيمة 47000 دولار تقريباً وأمراً واحداً فقط: لا ترسل الأموال مهما حدث. وكانت المسابقة تهدف إلى إجباره على إرسالها. وفي غضون ساعات، تمكن شخص ما من ذلك — ليس باختراق النموذج، ولكن بصياغة موجه معقد بما يكفي ليقنع الوكيل نفسه بأنه يتبع التعليمات بينما كان يخالفها تقنياً. كان هناك رد فعل مزدوج في نفس الوقت من الأشخاص الذين تابعوا هذا الحدث. الأول: أمر مثير للإعجاب حقاً، لقد اكتشف إنسان هذه الحالة الاستثنائية. والثاني: أمر مرعب، هناك أشخاص يبحثون بنشاط عن الحالات الاستثنائية في الأنظمة الحقيقية.

هذا ليس مجرد تحدٍ تنافسي، بل خطر تشغيلي يومي، كما يوضح حقن التوجيه (prompt injection). على سبيل المثال، قد يتلقى الوكيل الذي يراقب ملاحظات المعاملات المستخدمة لتصنيف التحويلات ملاحظة تحتوي على تعليمات خبيثة. وقد يتلقى وكيل المراقبة الذي يتعامل مع اتصالات الأطراف المقابلة الخاضعة للمراقبة رسالة تغير سلوكه. الجزء المثير للاهتمام هو أن المهاجم لا يحتاج إلى النجاح في اختراق البنية التحتية. كل ما عليه فعله هو فرض نص في نافذة سياق الوكيل ليعتبره النموذج تعليمات موثوقة. والوكلاء المحصنون ضد ذلك هم أولئك الذين درس مشغلوهم بعناية ما هي المعلومات المسموح للوكيل بقراءتها ومن أي مصدر.

هناك أيضاً الانهيارات المحبطة التي لا علاقة لها بالهجمات العدائية. مثل ذلك الوكيل الذي يعتبر أي معاملة من عنوان لم يسبق له القيام بأي نشاط مشبوهة — وهو تصرف يبدو صحيحاً حتى تدرك أنه يضع علامة على ثلاثين بالمائة من جميع المعاملات، وبالتالي تفقد التنبيهات قيمتها. أو الوكيل الذي ينشئ تقريراً مفصلاً من اثنتي عشرة صفحة كل صباح عندما طلبت ملخصاً، ولا يمكنك العثور على أي موضع طلبت فيه اثنتي عشرة صفحة. أو الوكيل الذي يعمل بسلاسة لثلاثة أسابيع — ثم، عندما يتم تحديث مكتبة برمجية يعتمد عليها بطريقة ما، يتوقف عن العمل دون تسجيل أي أخطاء، متوقفاً ببساطة عن النشاط الذي كان يمارسه، فلا تدرك أن خطأ ما قد حدث إلا بعد مرور أسبوعين دون تلقي أي تنبيه.

الفشل الصامت، وهو نمط الفشل الأخير، هو أكثر ما ينبغي أن يقلق المرء. فالأخطاء الصاخبة تعلن عن نفسها؛ ففي غضون ثوانٍ، يتسبب الوكيل الذي يرسل إلى العنوان الخطأ، أو يخصم المبلغ الخطأ، أو ينفذ تحويلاً في الوقت الخطأ في عواقب واضحة للعيان. أما الوكيل الذي يتوقف ببساطة عن المتابعة، ويتوقف عن إرسال التنبيهات، ويتوقف عن التسجيل دون ترك أي أثر، تاركاً إياك غير مدرك لتوقفه عن أي من تلك الأشياء، فهو نمط الفشل الذي يعميك تماماً.

الخصوصية والمال: ما الذي تدفع ثمنه تحديداً

في مرحلة ما، عند إعداد وكيل ذكاء اصطناعي لإدارة محافظك، تدرك على الفور حجم ما أنت على وشك مشاركته. يجب أن يعرف الوكيل أرصدة محفظتك. ويجب أن يكون على علم بمعاملاتك السابقة. ويجب أن يفهم منطق عملك — القواعد المتعلقة بمن يحصل على الأموال، ومتى، وبأي مبالغ وتحت أي شروط. ولكي يكون الوكيل مفيداً، فإنه يتطلب رؤية أكثر شمولاً لأموالك مما يشاركه معظم الأفراد مع محاسبهم الخاص.

يجب أن توجد هذه البيانات في مكان ما: في سياق النموذج أثناء كل جلسة، وفي السجلات التي تدون ما فعله ولماذا، وفي قاعدة البيانات التي يخزن فيها سجلات المعاملات، وفي مفاتيح API التي تربطه بالبنية التحتية للمحفظة. كل موقع من هذه المواقع يمثل نقطة تعرض محتملة. ليس بالضرورة بسبب جهات احتيالية تدير البنية التحتية، ولكن لأن قواعد البيانات التي تحتفظ عادة ببيانات مالية حساسة سيتم استكشافها يوماً ما بواسطة شخص فضولي وخبيث يبحث عن ثغرة للدخول، وينبغي لـ 18.1 مليون مفتاح API مسروق في عام 2025 أن توضح إلى حد ما مدى نجاح هذه المحاولات في المتوسط.

هذه حالة نفسية غريبة بحد ذاتها. فالأوساط التقليدية تحرص بشدة على حماية معلوماتها المالية، وتكون انتقائية للغاية بشأن من تشارك معه كشوف حساباتها، ولا تحتفظ بمستند مشترك يحتوي على بيانات تسجيل الدخول إلى حسابات التداول الخاصة بها. ومع ذلك، يشرح هؤلاء عمليتهم المشفرة بالكامل لنموذج ذكاء اصطناعي خلال جلسة يسجلها المزود، باستخدام مفاتيح API محفوظة في متغيرات البيئة على خادم أعدوه في عشرين دقيقة، متسائلين في الوقت ذاته عما إذا كان هذا سيؤدي لابتزازهم أو ما شابه، ومع ذلك يفعلون ذلك لتجنب التحقق اليدوي من المحفظة.

في الواقع، يبدو أن هناك رغبة عارمة للتخلص من الشعور بالذنب الناتج عن ذلك التراكم تفوق الحاجة لحماية مثل هذه المواد الحساسة. هذا ليس فريداً من نوعه بالنسبة للذكاء الاصطناعي. فهذه هي الطريقة التي يتم بها التعامل مع جميع وسائل الراحة التي تضر بالخصوصية؛ إذ تبدو مقايضتك مجردة في اللحظة التي تجريها فيها، ولا تصبح حقيقية إلا عندما تسوء الأمور.

كما يتم التقليل من تقدير مشكلة التكلفة في مرحلة التبني المبكرة أيضاً. خطة الاشتراك للوصول إلى الوكيل — 100 دولار شهرياً للوصول إلى مستوى النموذج الرائد لا تتغير تقريباً. لكن هذا ليس الواقع بأي شكل فعلي. فالوكيل الذي يحتفظ بسجل دائم يضم العديد من الرموز (tokens) في وقت واحد يتغير باستمرار. وتكتشف أن تكاليف الترخيص لوكيل ذي قدرات تفوق ما يمكن أن توفره خطة المستهلك العادية، عند الانتقال إلى تسعير API، لم تعد مجرد مئات الدولارات شهرياً. بل تتضخم بقدر ما يفعله الوكيل، وما يفعله الوكيل هائل وضخم. تنهار هذه الحسبة البسيطة القائلة بأن "مائة دولار هي أقل من تكلفة ساعة واحدة من عمل مطور أول" فجأة عندما تصل فاتورة API الخاصة بك إلى أربعمائة $ وأكثر، لأنك أضفت المزيد من الوكلاء لتغطية أدق تفاصيل النظام.

لا يعني أي من هذا أن الجدوى الاقتصادية منعدمة. ولكن بالنسبة للعمليات التي تعالج حجماً كبيراً من المعاملات، فإن التوفير في تكاليف العمالة يكون ملموساً. عمليات TRON buy Energy التي لا تزال بحاجة إلى إجرائها يدوياً ثلاث أو أربع مرات في اليوم يمكن أن تكلف مبالغ ضئيلة للغاية عند أتمتتها بالكامل. نقطة التعادل موجودة. كل ما يتطلبه الأمر هو تقييم صادق للتكاليف الإجمالية على جانبي الحساب — بما في ذلك وقت الإعداد، وتكلفة أخطاء المعايرة، ورسوم API المتكررة والبنية التحتية.

المستندات والسجلات وجعل الآلة تتعلم من أخطائها

الوكيل الذي لا يملك ذاكرة هو وكيل سيتخذ نفس القرار الخاطئ في كل مرة يحدث فيها نفس الموقف. هذا يبدو بديهياً. ومع ذلك، فإن عدداً قليلاً جداً من الأشخاص هم من يبنون بنية تحتية للسجلات مسبقاً، لأن التسجيل بحد ذاته يبدو وكأنه استعداد لفشل لم يحدث بعد، والذاكرة البشرية سيئة للغاية في توجيه الانتباه نحو الإخفاقات المستقبلية عندما تكون هناك أمور فورية تتطلب اتخاذ إجراء.

الأثر العملي في العالم الحقيقي هو أن الغالبية العظمى من عمليات نشر وكلاء الذكاء الاصطناعي تفشل في هذا الجانب مرة أو مرتين قبل أن يقوم المشغل ببناء سجلات لاكتشاف ذلك. المرة الأولى تعتبر مخالفة، والثانية مصدر إزعاج، وفي المرة الثالثة يقوم شخص ما أخيراً بكتابة هيكل السجل الذي كان بإمكانه منع المرة الرابعة.

وهذا أمر مهم: السجل بحاجة إلى ألا يحتوي فقط على ما فعله الوكيل، بل أيضاً على سبب قيامه بذلك — أي: المنطق التفكيري الذي شكله عند التنفيذ واستجابةً للموجهات في ذلك الوقت، بما في ذلك البيانات التي كان يطلع عليها وكيف وصل إلى تعليماته. وإلا فإن السجل سيخبرك فقط بحدوث خطأ ما. لكن السجل المتكامل يخبرك أين حدث الخطأ في توجيه التعليمات، وهي المعلومات الحيوية التي تحتاجها لإصلاحه.

الوكيل الذي يدير TRON Energy ويستعلم عن رصيد Energy بشكل مفرط في فترات انخفاض المعاملات، وبشكل غير كافٍ قبل ذروة المعالجة — يمكن إصلاح هذا الخلل بسهولة تامة عندما يتوفر السجل الذي يوضح النمط الزمني. يستغرق التصحيح خمس دقائق. أما الوقت المستغرق لملاحظة ذلك بدون السجل فهو المدة التي تستغرقها لتدرك أنك تعاني باستمرار من نقص في Energy في الأوقات الخاطئة وأن هذا مجرد عشوائية غريبة تحدث. تتيح API الخاصة بـ TronGrid وظائف مذهلة عند استخدام وكلاء الذكاء الاصطناعي مع توثيق جيد:

بالتأكيد، يعد بناء بنية السجلات قبل أي نشر هو الحل الصحيح تماماً. ولكنه أيضاً نوع النهج الذي لا يطبقه أحد عملياً، لأنه يتطلب مجهوداً ذهنياً شاقاً لتصور أنماط فشل لم تواجهها بعد، وبالتالي يفرض نوعاً من الانضباط التشاؤمي الذي يتعارض مع التفاؤل الجارف المطلوب لإعداد وكيل مؤتمت في المقام الأول.

تبدأ مسألة الوكلاء الفرعيين في الظهور عندما ينجح نظام الوكيل الواحد بشكل جيد بما يكفي لترى نقاط ضعفه. تعمل وظيفة المراقبة. والسجلات في مكانها. وأنماط الفشل مفهومة. ويمكنك أن ترى أن المهمة التالية المطلوبة — كشراء Energy تلقائياً، أو تصنيف المعاملات، أو إنشاء التقارير — ستكون أكثر تنظيماً إذا أُسندت إلى وكيل فرعي مستقل ذي تركيز محدد وتعليمات موجهة بدلاً من إضافتها كعبء على الوكيل الحالي.

وهكذا يبني الناس البيروقراطية عن غير قصد. وكيل التنسيق الرئيسي الذي ينسق بين الوكيل الفرعي للمراقبة مقابل الوكيل الفرعي للتنفيذ مقابل الوكيل الفرعي لإعداد التقارير؛ إنه مخطط معماري أنيق للغاية لبناء حل برمجي حوله. ولكن هذا يعني بدوره أن لديك حالات فشل محتملة عند المنسق، أو عند أي من الوكلاء الفرعيين، أو عند أي من الواجهات التي تربط بينهم؛ ومعرفة المخطئ منها تتطلب فحص أربعة سجلات بدلاً من سجل واحد. تصبح إدارة الأذونات الآن مشكلة منفصلة: فالوكيل الفرعي الذي يحتاج فقط لقراءة أرصدة المحفظة يجب ألا يمتلك صلاحيات إرسال المعاملات، مما يضعك أمام مشكلة إدارة بيانات الاعتماد بالإضافة إلى كل التعقيدات الأخرى.

الحل بسيط ويتطلب تدرجاً: قم ببناء وكيل واحد في كل مرة، وتأكد من أن كل شيء يعمل بسلاسة مع السابق قبل إضافة آخر. إن بنية الوكلاء الفرعيين النهائية يجب أن تتطور بدافع الضرورة، لا أن تُحدد بنظرية مفروضة من أعلى إلى أسفل. المؤسسات التي نفذت بنجاح أنظمة مالية متعددة الوكلاء هي تلك التي بنتها بهذه الطريقة، عبر التكرار المستمر المليء بالعثرات على طول الطريق، وليس كإنجاز معماري منفذ في قفزة واحدة مخطط لها بدقة.

بالنسبة لأولئك الذين يريدون أتمتة الـ Energy ولكنهم يرفضون بناء هذه البنية التحتية بأنفسهم، فإن Netts Energy Charge Bot يقدم أداءً متفوقاً في حالة استخدام واحدة على الأقل مقارنة بالبدائل — وهي إدارة إعادة تعبئة TRON Energy تلقائياً عبر واجهة Telegram، حيث يتعامل مع عمليات الشحن اليدوية وتفويض Energy التلقائي لمدة 24 ساعة، بالإضافة إلى طلبات الشراء بأسعار تبدأ من حوالي 25 sun للوحدة الأولى بعد الشحن، وبأسعار تفويض دورية خارج أوقات الذروة (يقوم الشحن التلقائي عند الطلب بإعادة تفويض كامل الـ 131k من Energy حتى لا ينخفض رصيد المحفظة كثيراً)، مما يجعله نقطة انطلاق عملية لأي شخص تجاوز حجم معاملاته حدود الإدارة اليدوية ولكنه ليس مستعداً بعد لبناء نظام وكلاء متكامل خاص به.