بناء مساعد ذكاء اصطناعي يدرك السياق على بواسطة AgentCore وOpenClaw

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

المشكلة ليست في جودة الإجابات، بل في أن المساعد لا يحتفظ بذاكرك. توضح هذه المقالة كيفية إنشاء مساعد شخصي يجمع السياقات باستخدام OpenClaw، وهو نظام عامل مفتوح المصدر، يعمل على نظام AgentCore runtime، وهو ميزة من Amazon Bedrock AgentCore. ذاكرة AgentCore، وهي ميزة من Amazon Bedrock AgentCore، تحول المحادثات التجريبية إلى معرف دائمة. كما سترى كيفية تسمية تلك الذكريات ببيانات وصفية منظمة لاسترجاع السجلات التي تهم السؤال الحالي.

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

نظرة عامة على الحل

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

الشكل 1: توقيتات Webhooks في Telegram وAmazon EventBridge تستدعيان نفس عامل التشغيل AgentCore، الذي يتولى تنسيق جسر OpenClaw، ذاكرة AgentCore، وAmazon Bedrock.

تتقاطع نقطتان دخول على عامل واحد. تصل رسائل Telegram عبر بوابة API لـ Amazon ودالة AWS Lambda للwebhook، بينما تصل المهام المحددة مسبقًا مثل تذكيرات ري الماء في الصباح عبر جهاز الترتيب لـ Amazon EventBridge ودالة cronjob لـ AWS Lambda. كلاهما يستدعيان API InvokeAgentRuntime على runtime AgentCore، حيث يقوم عملية بسيطة من server.py بتنسيق جهاز التوجيه OpenClaw، ذاكرة AgentCore، وAPI Converse لـ Amazon Bedrock. يوفر خدمة التخزين البسيط لـ Amazon (Amazon S3) تخزين للعمل المشغول، وتتولى خدمة إدارة المفاتيح لـ AWS (AWS KMS) عملية التشفير، وتحتفظ خدمة مدير الأسرار لـ AWS بقاعدة بيانات الروبوت، بينما يقوم Amazon CloudWatch بتسجيل السجلات والمؤشرات.

المتطلبات الأساسية

لتنفيذ نسختك الخاصة باستخدام زر Launch Stack أو السكريبتات deploy.sh (الموضحة في قسم "زيد مشروعك الخاص")، ستحتاج إلى:

• وصول إلى Amazon Bedrock AgentCore، بما في ذلك تشغيل AgentCore والذاكرة الخاصة بـ AgentCore.
• تم منح وصول للنماذج التي تخطط لتوجيهها: Claude Haiku 4.5 للنصوص وClaude Sonnet 4.5 للرؤية (أو المقابلات المتاحة في حسابك).
• Docker مع دعم بناء linux/arm64، بالإضافة إلى تهيئة واجهة سطر الأوامر لـ AWS (AWS CLI). هذا ضروري فقط إذا كنت تخطط لبناء ودفع الصورة الخاصة بك.
• رمز بوت تيليجرام (من BotFather) ليكون كنقطة الدخول لدعم المساعد.
• الإلمام الأساسي بمفاهيم تنظيم العملاء وCloudFormation.

الهندسة: وكيل بدون خادم على وقت التشغيل AgentCore

كل مكون يعيش في قالب واحد من CloudFormation، ولا يلزم أدوات بناء لإطلاقه. تشرح الأقسام التالية القرارات المتعلقة بتحمل الأحمال.

تشغيل AgentCore: دفع فقط مقابل الحسابات النشطة

يعيش العميل في حاوية ضمن تشغيلة AgentCore، والتي تستخدم أسعارًا مبنية على الاستهلاك. يتم فرض الفواتير بناءً على الحساب الذي يستهلكه العميل بشكل نشط، وليس بناءً على وقت التشغيل، ولا يتم دفع المال للوقت الذي يُقضى في الانتظار من أجل إدخالات وخرجات مثل استجابة النموذج. بالنسبة لمساعد شخصي يُستخدم لفترات قصيرة، فهذه هي الفرق بين أساسي يقارب 1–2 دولار شهريًا ووحدة في Amazon Elastic Compute Cloud (Amazon EC2) تعمل دائمًا بمعدل تقريبي 35 دولار شهريًا. هذه الأرقام هي تقديرات للاستخدام الشخصي الخفيف حتى شهر يوليو 2026. يرجى الرجوع إلى أسعار AgentCore للحصول على الأسعار الحالية.

يفرض الوقت التشغيلي عقدة حاوية أدنى من المستوى المطلوب: الاستماع على المنفذ 8080، وإظهار GET /ping كنقطة دخول للأداة، وPOST /invocations كنقطة دخول الأداة. حاويةنا هي linux/arm64، وقد تم بناؤها من خلال مرحلة متعددة من الصورة الرسمية لـ OpenClaw بالإضافة إلى طبقة Python.

OpenClaw كركيزة العملية

يوفر OpenClaw حلقة العميل، استخدام الأدوات، ونظام المهارات. يقوم بتشغيل واجهة (server.py) تُعدّه لتتوافق مع عقد بروتوكول HTTP لـ AgentCore.

• عند بدء الحاوية، يُطلق ملف server.py مشروع openclaw gateway run كعميل فرعي ويقوم بفحص الصحة.
• GET /ping يعطي نتائج صحية بسرعة، لذا فإن اختبار جاهزية AgentCore ينجح.
• تقوم عملية POST /invocations بالعمل الفعلي: فهي تحلل البيانات المدخلة، تسترجع الذاكرة، تجمع السياق، تنقل التحويل إلى البوابة، وتحفظ النتيجة. ملاحظة: يمكن لـ AgentCore أن يفتح حاوية متجمدة إذا انتهى المشروع الفرعي الخاص بها. لذلك، لا يفترض مسار الاستدعاء أن البوابة لا تزال نشطة، بل يستدعي دعمًا باستخدام الدالة ensure_openclaw_ready() التي تتحقق من حالة الصحة مرة أخرى (وإعادة تشغيل البوابة إذا لزم الأمر) قبل تنفيذ التحويل.

هذا نمط الغلاف يُعمم على حالات الاستخدام الأخرى. أي إطار عمل للعناصر التي تعمل كعملية محلية يمكن تكييفه مع وقت تشغيل AgentCore بنفس الطريقة، دون تعديل الإطار نفسه.

نموذجان، يتم توجيههما حسب المهمة

للدردشة النصية وفهم الصور تكاليف وجودة مختلفة، لذا يقوم المساعد بتوجيههما إلى نماذج Claude المختلفة على Bedrock:

• كلود هايكو 4.5 للنص: سريع واقتصادي للجلسات الحوارية ذات الحجم الكبير التي تسيطر على الاستخدام اليومي.
• كلود سونيت 4.5 للرؤية: تفكير متعدد الوسائط أقوى لمهمة نادرة ولكنها صعبة، وهي تشخيص النبات من صورة.

تدور الصورة عبر بوابة OpenClaw، التي تجلب المهارات وحالة الجلسة. يتم استدعاء النموذج اللغوي الكبير من Bedrock مباشرة من server.py، مع إرسال بايتات الصورة ككتل محتوى متعددة الوسائط. نوجه الصور عبر البوابة عن قصد: فقد تفكك تجميع OpenClaw داخل الحاوية أجزاء محتوى image_url قبل وصولها إلى Bedrock، لذا فإن استدعاء واجهة برمجة التطبيقات من Converse مباشرة من server.py يضمن أن النموذج يرى البيكسلات الفعلية. يتم تبادل نفس التوجيه النظامي (الشخصية المضافة للذاكرة) في كلا المسارين، لذا تظل التجربة متسقة.

هيئات النموذج هي متغيرات بيئة (MODEL_ID, VISION_MODEL_ID)، بحيث يمكنك تبديل النماذج أثناء التشغيل دون الحاجة إلى إعادة بناء الصورة.

المهارات كوحدة القدرة القابلة لإعادة الاستخدام

تُعلن القدرات كمهارات في ملف التصميم community-skills.json. يتم تحويلها إلى الحاوية أثناء النشر، وتسجيلها في إعدادات OpenClaw قبل بناء الصورة. عند نشر هذا البوست، يحتوي Sprout على مهارات تتعلق بالطقس والتذكيرات وملاحظات النباتات. يتم استبدال ملف التصميم، ويخدم نفس المسار تخصصًا مختلفًا. وهذا ما يجعل كل شيء نموذجًا قابلًا للإعادة الاستخدام وليس مجرد بوت واحد فقط.

تلغرام كبوابة أمامية بدون خادم

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

درس واحد في التنسيق يجب ملاحظته: نموذج التصميم Markdown التابع لتلغرام لا يتحمل الأحرف غير المحمية، وقد يؤدي وجود علامة سفلية واحدة في رد النموذج إلى فشل إرسال الرسالة بأكملها. إن تقديم الردود كـ HTML آمن، لذلك يقوم المساعد بتحويل ناتج النموذج إلى HTML آمن للتلغرام قبل إرساله.

الذاكرة: تحويل الدردشات العابرة إلى معرفة دائمة

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

نموذج الفكر: الأحداث قصيرة المدى، الاستخلاص طويل المدى

لديّة الذاكرة لـ AgentCore تحتوي على طبقتين. يخزن الذاكرة قصيرة المدى كل جولة من المحادثة كحدث من خلال CreateEvent، ويتم تحديده بواسطة actorId (رقم ID في Telegram) وsessionId. هذه هي النصوص الخام. أما الذاكرة طويلة المدى فتُنتج بشكل غير متزامن من خلال استراتيجيات استخراج مُدارة إلى سجلات مستقرة ومنظمة. لقد قمنا بتكوين ثلاث استراتيجيات:

• USER_PREFERENCE: الخيارات الواضحة التي ذكرها البستاني (“أنا أستخدم فقط الأسمدة العضوية”).
• SEMANTIC: حقائق مفهومة (“ينمو البطيخ المكسيكي في حوض من فولاذ كورتن”).
• SUMMARIZATION: ملخصات جلسات متقطعة (“ناقشوا تلف الأوراق السفلية خلال موجة حرارة”).

مساحات الأسماء: حديقة واحدة لكل حارص على الحدائق

تُسجل ملفات Sprout في مساحات الاسماء الخاصة بكل مستخدم، بحيث لا يتداخل أي من المحادثات مع الأخرى أبدًا:

• sprout/{chat_id}/long_term: التفضيلات والحقائق الدلالية.
• sprout/{chat_id}/episodic/{session_id}: ملخصات الجلسات.

هو الرقم ID للدردشة هو القطعة المتغيرة الوحيدة، مما يجعل العزل سهلاً للتفكير فيه واختباره: كل بستاني فريد يرتبط بدفتر عنوان واحد بالضبط، ولا يتداخل اثنان من البستانيين.

مسار استرجاع، تجميع، واستخلاص

في كل دور، يقوم العملية باستخراج السجلات طويلة المدى ذات الصلة، تقييمها، ثم إدخالها في نص التحفيز النظامي. هذا هو ما يحدث في كل رسالة، داخل server.py:

• استرجاع. استدعِ دالة RetrieveMemoryRecords ضد sprout/{chat_id}/long_term، باستخدام رسالة المستخدم ككلمة بحث، مع تحديد عدد النتائج عند 50 نتيجة، ضمن ميزانية أقل من 3 ثوانٍ. إذا تجاوزت وقت الاسترجاع الحد المسموح به أو حدث خطأ، فإننا نتحول بشكل لطيف إلى استجابة دون الذاكرة بدلاً من الفشل.

try:
    records = memory_client.retrieve_memory_records(
        memoryId=MEMORY_ID,
        namespace=f'sprout/{chat_id}/long_term',
        searchCriteria={
            'searchQuery': user_message,
            'topK': 50,
            'metadataFilters': []
        },
    )  # 3s timeout
except Exception:
    records = []  # fall back to answering without memory

المقطع 1: استرجاع السجلات طويلة المدى للدور الحالي (تمثيلية. راجع المكتبة للحصول على المصدر الكامل).

تضيف الدالة Assemble منطقًا مخصصًا إضافيًا. نريد أن تكون التفضيلات الصريحة في مقدمة الحقائق المستنتجة، وأن الترتيب يكون مستقر داخل كل فئة، وأن النتيجة تكون محدودة قبل الحقن:

def assemble(records, cap=50):
    explicit = [r for r in records if r.type == 'USER_PREFERENCE']
    inferred = [r for r in records if r.type != 'USER_PREFERENCE']
    # explicit beats inferred; stable order within each class
    ordered = explicit + inferred
    return ordered[:cap]

المقتطف 2: يتم ترتيب خطوات التجميع على أساس التفضيلات الصريحة قبل الحقائق المستنتجة.

المعلومات التحتية: تقسيم الذكريات إلى مجموعات داخل مساحة الاسم

تجيب الفضاءات الاسمية عن مكان الذاكرة التي يتعلق بها السجل، لكن البيانات الوصفية توضح ما يتعلق به. داخل sprout/{chat_id}/long_term، سيُرجع البحث الدلالي لـ “نباتات البيريليا الخاصة بي تتعرض للتشقق” كل شيء قريب من المعنى. بالنسبة للمزارع، هذا يعني تفضيلات الأسمدة من مارس، وملاحظة تقليم شجرة التين، وتُصنف هذه العناصر جنبًا إلى جنب مع السجلات التي تهم حقًا. كما أن البيانات الوصفية المنظمة تساعدنا على تضييق نطاق الذاكرة قبل أن تصل إلى الطلب.

قاعدة واحدة تحدد كل قرار هنا. يمكن تصفيتة على جانب الخادم فقط إذا تم إعلانها ككلمة مفتاحية مرتبطة. يمكنك الاطلاع على المزيد من المعلومات في تصفيتة الذاكرة المنظمة مع البيانات الوصفية في Amazon Bedrock AgentCore Memory. في هذه الحالة، يستخدم Sprout ثلاث كلمات مفتاحية مرتبطة:

IndexedKeys:  # on the AWS::BedrockAgentCore::Memory resource
  - Key: type  # seperate the kinds of records
    Type: STRING
  - Key: section  # which bed or area it describes
    Type: STRING
  - Key: plants  # what is growing there
    Type: STRINGLIST

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

إبقاء الدور والإغلاق للحلقة

بعد رد النموذج، يستدعي ملف server.py دالة CreateEvent مع حالتيه المستخدم والمساعد. هذا الحدث الجديد يغذي استراتيجيات الاستخراج، مما يُثري المخزن طويل الأمد للمرة القادمة.

memory.create_event(
    memoryId=MEMORY_ID,
    actorId=chat_id,
    sessionId=session_id,
    payload=[
        {'role': 'user', 'content': user_message},
        {'role': 'assistant', 'content': reply},
    ],
)  # feeds USER_PREFERENCE / SEMANTIC / SUMMARIZATION extraction; errors are logged, never fatal

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

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

دمجها معًا: خطة رش الماء الشخصية

هنا يعمل النظام الكامل من البداية إلى النهاية. خلال بعض المحادثات، يتم تصنيف جميع النباتات في الحديقة بلغة بسيطة، نباتًا بصورة واحدة. كل ذكر يُعتبر حدثًا. تقوم استراتيجيات الاستخراج باستخلاص المعلومات حول النبات وموقعه واستقباله للشمس إلى sprout/{chat_id}/long_term. هذا الصباح، يسأل المستخدم سؤالًا: “هل تتذكر النباتات الأخرى في حديقتي؟” يتم استرجاع السجلات، ترتيبها، ثم إدخالها في النظام. يجيب المساعد باستخدام موقع المستخدم، استقباله للشمس، تصميم الفراش، سلوك التربة، ومخزون النباتات، وكلها أمور لم تظهر في الرسالة نفسها.

الشكل 2: يجيب Sprout على سؤال حول الحديقة من خلال استرجاع قائمة النباتات المخزنة وظروف النمو.

باستخدام مهارة الجدولة على مسار Amazon EventBridge → Cron، يمكن لـ Sprout أيضًا تحويل ذلك الخطة إلى تنبيهات استباقية (“تجاهل الأعشاب، فالتربة لا تزال رطبة من الأمس”)، وضبطها بناءً على مهارة الطقس عند قدوم المطر أو موجة الحر.

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

الشكل 3: الرؤية والذاكرة تعمل معًا. الصورة تُرسل إلى نموذج الرؤية، بينما يحمل تنبيه النظام السياق الزراعي المحفوظ لدى المستخدم.

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

الحفاظ على تكاليف الاستدلال منخفضة باستخدام تخزين الكلمات المفتاحية

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

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

إرشادات التصميم لتطوير AgentCore وOpenClaw

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

• اربط، لا تقسّم. تكيّف إطار عمل الوكيل الخاص بك مع عقد حاوية AgentCore باستخدام واجهة HTTP رقيقة بدلاً من تعديل الإطار. العقد صغير، بمنفذ 8080 مع /ping و/invocations، وتجعل الواجهة الرقيقةك عميلًا في مسار تحديث الإطار.
• قم بتصميم العوالم التصميمية قبل تخزين أي شيء. عوالم الذاكرة هي حدود العزل الخاصة بك. جعل رقم المستخدم هو القطاع المتغير الوحيد، واختره من رقم الهوية الطبيعي للقناة الذي تثق به بالفعل، مثل رقم الدردشة. تصاميم العديد من العملاء تتعرض في النهاية لمراجعات وتطلبات حذف. يسهل نظام العوالم التصميمية النظيف كلاهما.
• اعتبر الذاكرة تحسينًا، وليست اعتمادًا. يجب السماح لكل عملية ذاكرة بأن تفشل بشكل لائق. يجب أن تؤدي أخطاء الاسترجاع إلى إجابة بدون ذاكرة دون حظر الرد. يغفر المستخدمون لحالة النسيان بسهولة أكبر من الحالة الفاشلة.
• نماذج التوجيه حسب المهمة. استخدم نموذجًا سريعًا واقتصاديًا للنصوص ذات الحجم الكبير، واحتفظ بنموذج متعدد الوسائط أقوى لالحظات تحتاجه. احفظ أرقام الأوامر في متغيرات البيئة حتى تكون تغييرات التوجيه إعدادات وليست كودًا.
• طلبات الطلبات المتعلقة بالتخزين المؤقت. يجب أولاً الحفاظ على شخصية مستقرة وذاكرة، ثم بعد ذلك استخدام مدخلات المستخدم المتقلبة، مع ترتيب حتمي طوال الوقت. هذا العرف الهيكلي هو المكان الذي تأتي منه معظم توفير التحليلات.
• خطة لتناقص زمن الاستخراج. يتم استخراج الذاكرة طويلة المدى بشكل غير متزامن، لذا لا تعد بأن يتم تذكر الحقائق الجديدة في نفس الجلسة. دع الأحداث قصيرة المدى في الجلسة تغطي المحادثة الحالية، بينما تغطي السجلات طويلة المدى السجلات السابقة.
• ضع ميزانية من اليوم الأول. الوكيل القائم على الاستهلاك رخيص الثمن حتى يحدث دورة إعادة المحاولة أو يصبح المستخدم نشطًا، وإلا فإن تنبيه AWS Budgets عند 80 بالمئة و100 بالمئة من الحد الشهري لا يتكلف شيئًا ويلاحظ المفاجآت مبكرًا.
• حافظ على المهارات صغيرة وذات غرض واحد فقط. يجب أن تكون المهارة تُؤدي مهمة واحدة فقط كما يصفها المستخدم في جملة، مثل تحليل الطقس أو تعيين تذكير. المهارات الصغيرة قابلة للاختبار بشكل مستقل وقابلة للتغيير بشكل مستقل، ويسهل على النموذج اختيارها بشكل صحيح. أما المهارة التي تقوم بكل شيء، فتجبر النموذج على تخمين أي من سلوكياته هو ما تقصده.

زرع نفسك

طريقتان لزراعته، نفس الحديقة:

• قائمة التشغيل خطوة واحدة: يشير قالب CloudFormation إلى صورة من مستودع Amazon Elastic Container Registry العام (Amazon ECR)، لذا يتم تنفيذ شيء فقط وهو رمز كلمة المرور الخاص بالروبوت Telegram.
• بناء نسخة خاصة بك: يُحقق برنامج scripts/deploy.sh القالب، ويقوم ببناء الصورة ARM64 الخاصة بك وطرحها في مستودع Amazon ECR الخاص بك، كما يُنشر الطبقة الكاملة، ويسجل رابط الويبhook لTelegram، مما يوفر بناءً قابلًا للتخصيص بالكامل.

تبلغ التكلفة الشخصية الخفيفة حوالي 5–9 دولارات شهريًا اعتبارًا من يوليو 2026 (حوالي 2 دولار لتكاليف البنية التحتية، و1–3 دولار لنصوص هايكو، و2 دولار لمشاهدة السونيتات)، مع وجود تطبيق AWS مدمج يُنبه عند الوصول إلى 80% و100% من الحد المحدد.

الكود المصدر الكامل متاح في مخزن بيانات GitHub sample-agentcore-memory-openclaw.

تنظيف

عند انتهاء التجارب، أزل كل شيء لتجنب أي رسوم مستمرة. لأن النظام بأكمله عبارة عن مجموعة واحدة من CloudFormation، فإن التنظيف يتم ببساطة عن طريق حذف الملفات:

1. حذف كومباين CloudFormation. هذا يؤدي إلى حذف عامل التشغيل AgentCore، وواجهة API Gateway، ودوال Lambda، وجدول Amazon EventBridge، والأدوار المتعلقة بإدارة الهوية والوصول في AWS (IAM).
2. حذف مخزن الذاكرة لـ AgentCore (واسماءه المكانية) حتى لا تُحتفظ بسجلات المستخدمين.
3. حذف أي صور أرسلتها إلى مستودع ECR الخاص بك، وأيضًا المستودع نفسه إذا لم يعد مطلوبًا.
4. إزالة تحذير ميزانية AWS إذا تم إنشاؤه خارج الرصيف.
5. إلغِ واجهة الويب الخاصة بتلغرام (أو حذف الروبوت عبر BotFather)، وإلغِ الوصول إلى نموذج Bedrock إذا لم تعد بحاجة إليه.

الخلاصة

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

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

لمعرفة المزيد، يرجى الرجوع إلى وثيقة AgentCore. تغطي المقالات المرتبطة التالية العناصر الأساسية بشكل أعمق:

• ذاكرة Amazon Bedrock AgentCore: بناء العملاء الواعين للسياق
• بناء وكلاء الذكاء الاصطناعي الأذكى: تحليق عميق في ذاكرة الوكيل طويلة المدى AgentCore
• استخدام حفظ التحفيز على أمازون بيدروك في طريقة فعالة
• تشغيل وتوسيع أجهزة الأدوات والأجهزة الخاصة بك بأمان على وقت التشغيل Amazon Bedrock AgentCore

حول المؤلفين