كيف منحت وكيل الذكاء الاصطناعي محفظة ولماذا احتاج إلى ذاكرة فوراً

قبل أيام قليلة أطلقتُ open-second-brain - طبقة ذاكرة قائمة على الملفات لوكلاء الذكاء الاصطناعي. ومنذ ذلك الحين تطاردني فكرة واحدة. إذا كان الوكيل يعمل على VPS وفق جدوله الخاص، عبر Telegram - فعاجلاً أو آجلاً سيحتاج إلى إنفاق المال. شراء استدعاء API. توليد رسم توضيحي. تشغيل بحث مدفوع.

الدفع بحد ذاته مشكلة محلولة منذ زمن. تقوم pay.sh بتحويل استدعاء HTTP اعتيادي إلى استدعاء مدفوع عبر مدفوعات صغيرة بـ USDC على Solana. يقوم الوكيل بتشغيل curl من خلال pay، تقوم المحفظة بتوقيع المعاملة، ويعود رد من الطرف الآخر. تمّ.

لكن “تمّ” ليس إلا نصف القصة.

فوضى مع محفظة

تخيّل ما يلي: الوكيل يعمل على مهمة، ويتخذ على طول الطريق حفنة من القرارات، اثنان منها استدعاءان مدفوعان. بعد ساعة تفتح الطرفية فتجد أن الـ scrollback قد طار خارج الشاشة. في مكان ما هناك كانت هناك استدعاءات pay، في مكان ما وصلت تواقيع tx، في مكان ما عادت ردود JSON.

لماذا فعل الوكيل ذلك؟ بناءً على ماذا؟ كم كان يتوقع أن ينفق؟ كم خُصم فعلاً؟ أين النتيجة؟

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

أدركت بسرعة كبيرة أن المهمة ليست “تعليم الوكيل أن يدفع” - بل “ضمان أن كل عملية دفع تترك خلفها أثراً ذا معنى”.

تم توليد هذا الرسم التوضيحي بالطريقة ذاتها التي يصفها المقال: عبر pay.sh، باستخدام بوابة paysponge/fal x402 ونقطة الـ endpoint fal-ai/fast-sdxl. كلّفت عملية التوليد 0.01 USDC من محفظة mainnet 64FaukkZDUdFTufXF49H1CrHjDfsmBFqfrUjsAS8XrgP؛ ومعاملة Solana العامة هي 5ZYnkabzLvHqEgXNJfKopiRwbGkriHJ2bps2NnkX7HzqQAyTZYjcyJVCTvZwMquyMviv2juyAdbP9P2depHrJxQW. كان request id هو 019e135a-357b-71f3-8b9d-305e728b05fb، وحُفظ الـ asset المُولَّد محلياً باسم image.png.

وهنا تماماً تلاءم open-second-brain بشكل مثالي.

Pay Memory

في الإصدار 0.8.0 حصل OSB على طبقة جديدة - Pay Memory. باختصار: ذاكرة للمال.

بعد كل إجراء مدفوع يظهر في الـ vault ملف Markdown عادي يحتوي على الحقول التالية:

• لماذا قرر الوكيل أن يدفع؛
• أي خدمة تم استدعاؤها؛
• أي spending policy كانت سارية وما الذي قررته (allowed / approval_required / denied / not_checked)؛
• التكلفة المتوقعة و المبلغ المخصوم فعلياً؛
• payment proof - توقيع Solana المحدد الذي يمكنك فتحه في Solscan والتحقق منه؛
• النتيجة - رابط إلى asset note منفصلة تحتوي على المخرجات؛
• من الذي وافق، إن كانت الـ policy تستلزم ذلك.

ليس جدولاً في SQLite، وليس dashboard. إنه Markdown صرف يقع في المجلد ذاته الذي يكتب فيه الوكيل سجله اليومي. يمكنك فتحه بعينيك، التعليق عليه، عمل commit له في Git، البحث عنه لاحقاً بـ grep، أو عرضه كدليل.

لا يتحول OSB هنا إلى نظام مدفوعات - فهو لا يحتفظ بمحفظة، ولا يوقّع معاملات، ولا يقوم بـ enforcement. يفعل ما يجيده: يحتفظ بذاكرة صادقة قابلة للقراءة البشرية. تمنح pay.sh الوكيل وصولاً إلى موارد مدفوعة؛ ويمنح Pay Memory الإنسانَ إمكانية فتح الـ vault بعد أسبوع وفهم ما جرى بهدوء.

بالمناسبة، هكذا تماماً يبدو receipt حقيقي - receipt الخاص بالرسم التوضيحي نفسه في مطلع المقال. Markdown خام مباشرة من الـ vault، دون أي معالجة. Frontmatter يحوي جميع الحقول المذكورة أعلاه، وتحته نص بلغة بشرية حول “لماذا” و”ماذا أعادت الـ policy” و”كم خُصم فعلاً”.

داخل الـ Second Brain يقع في هذا المسار:

AI Wiki/
└── payments/
    └── 2026-05-10/
        └── fal-generate-a-no-text-fast-sdxl-illustration-for-the-techmeat-d.md

لا سحر هناك: التاريخ → مجلد، الـ slug → اسم الملف. مريح للـ grep و git diff والتنقل المعتاد في Obsidian.

مبدأ واحد تبيّن أنه أهم من البقية

عند مراجعتي للتطبيق الأولي، التفتت عيني فوراً إلى تفصيل واحد: كان الـ receipt يكتب دائماً “Allowed by the configured spending policy” - حتى عندما لا توجد أي policy في الـ vault أصلاً.

يبدو الأمر تفصيلاً صغيراً. لكنه في الواقع يقتل كل المعنى.

Pay Memory هي طبقة audit. وطبقة الـ audit تساوي بالضبط بقدر صدقها. في اللحظة التي يبدأ فيها الـ receipt برواية قصة جميلة بدلاً من الحقيقية، ينهار كل شيء. لذا فالقاعدة جاءت بسيطة: من الأفضل كتابة not_checked بدلاً من تسجيل allowed بثقة وبشكل كاذب. إن لم تُفحَص الـ policy - فقل ذلك. وإن أعادت الـ policy denied لكن إنساناً مرّر الاستدعاء يدوياً - فقل ذلك أيضاً.

إغراء “السردية الجميلة” هو العدو الرئيسي لنظام الـ audit. وهذا هو على الأرجح أهم درس اليوم - درس أنوي حمله إلى أجزاء أخرى من المشروع.

دفعة حقيقية في الإنتاج

بحلول نهاية اليوم كان لا بد من التحقق من كل ذلك ليس على fixtures sandbox، بل على نقود حقيقية. أرسلت عشرة سنتات من USDC إلى محفظة Solana جديدة، وطلبت من الوكيل أن يجد ثلاثة مقاهٍ في بلغراد عبر Google Places.

بعد ثانية عادت ثلاثة أماكن حقيقية - Artist Specialty Coffee، Dusha، DRIP. Tx مُنهاة على mainnet، $0.001 USDC، انتقل الرصيد من 0.10 إلى 0.099. التوقيع في Solscan، قابل للنقر.

ثم انطلقت كامل سلسلة Pay Memory: receipt يحوي التوقيع الحقيقي في الـ vault، وasset note منفصلة تحتوي المقاهي الثلاثة، وتقرير مدفوعات يومي، ومدخل قصير في Daily مع روابط إلى الملفين. أستطيع فتح الـ vault في Obsidian، النقر على الـ proof، رؤية الدفعة الحقيقية في الـ explorer، وبجانبها مباشرة - قصة واضحة بلغة بشرية تشرح لماذا فعل الوكيل ذلك.

لماذا كل هذا

لا أحاول أن أبني لنفسي enterprise compliance ولا blockchain-for-everything. البنية ذاتها بسيطة إلى حدّ الإحراج - مجموعة من ملفات Markdown في المجلدات الصحيحة.

لكن الفكرة من ورائها مهمة.

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

النسخة المختصرة:

pay.sh تمنح الوكيل وصولاً إلى موارد مدفوعة. Pay Memory تمنح الإنسان القدرة على الفهم، بعد أسبوع، لماذا استخدم الوكيل هذا الوصول.

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

صدرت Pay Memory ضمن open-second-brain 0.8.0.