
بقلم: ليلى | محررة أدوات المطورين · صوت تحريري بإشراف بشري
بناء تطبيق بسيط على AWS يستدعي نموذج لغوي كبير لا يتجاوز بضعة أسطر من Python — تُرسل prompt، تستقبل ردًا، وتعيده للمستخدم. لكن حين يصبح التطبيق مسؤولًا عن الحفاظ على سياق المحادثة، أو الاختيار بين أدوات متعددة، أو تنسيق خطوات متسلسلة، يتحوّل الكود المحيط به إلى شيء يشبه تمامًا إطار عمل الوكلاء. هنا تبدأ قصة Strands وAmazon Bedrock AgentCore.
Strands إطار عمل مفتوح المصدر من AWS يوفّر طبقة الوكيل التطبيقية: نموذج LLM كـ Claude Sonnet عبر Amazon Bedrock، أو نماذج محلية عبر Ollama، إلى جانب system prompt يُحدد سلوك الوكيل، وأدوات يختار النموذج استدعاءها، وسياق المحادثة، وحلقة الوكيل التي ترسل الطلبات وتُنفّذ الأدوات وتُعيد نتائجها. يمكن تشبيهه بنظير AWS لـ LangChain أو CrewAI. لكن تشغيل وكيل بموثوقية عالية يستلزم بيئة تُعالج التحديات التشغيلية: أين يعمل، وكيف يُستدعى، وكيف تُعزل الجلسات، وكيف يتوسّع. AgentCore هو الإجابة على هذه الأسئلة دون أن يفرض طريقة بناء الوكيل ذاته.

الوكيل الذي سنبنيه هو مساعد تعليمي يُغطّي أربعة مواد: الرياضيات والفيزياء والكيمياء والجغرافيا. النموذج يقرر بنفسه أيّ تخصص يناسب كل سؤال — لا قوائم كلمات مفتاحية ولا أداة توجيه منفصلة. يُجيب على الأسئلة المدعومة بصفته خبيرًا في المادة المعنية، ويرفض ما هو خارج النطاق. الهدف من هذا الاختيار واضح: سلوك مفهوم، مع قرارات هندسية حقيقية تُشبه ما تجده في الأنظمة الأكبر — من اختيار النموذج وكتابة التعليمات إلى التحقق من الطلبات ونشر التطبيق وإدارة الجلسات.
قبل الشروع في البناء، يجب أن تعرف ما تقدّمه AgentCore تحديدًا. إنها ليست تعريفًا لسلوك الوكيل، بل إطار تشغيلي يضمّ تسع قدرات مستقلة: Runtime لاستضافة الوكلاء وتوسيعهم في بيئات معزولة تدعم HTTP وMCP وA2A، وMemory لتخزين أحداث المحادثة واستخراج حقائق وتفضيلات دائمة، وGateway لكشف APIs ودوال Lambda وخوادم MCP كأدوات يمكن للوكيل اكتشافها، وIdentity لإدارة المصادقة، وPolicy لتطبيق قواعد تفويض Cedar، وBrowser لجلسات متصفح مُدارة، وCode Interpreter لتنفيذ Python وJavaScript وTypeScript في بيئات معزولة، وObservability لإرسال السجلات والتتبع إلى CloudWatch وX-Ray، وEvaluations لقياس جودة استجابات الوكيل. كل قدرة مستقلة — تستخدم ما تحتاجه وتُضيف غيره لاحقًا.

الآن الجانب العملي. إليك الخطوات الكاملة لبناء الوكيل ونشره:
- تجهيز البيئة والأدوات: تحتاج حساب AWS مع بيانات اعتماد مُعدَّة محليًا، وNode.js 20 أو أحدث، وPython 3.10 أو أحدث، وAWS CDK، وAgentCore CLI. على Windows بـ PowerShell، ثبّت AWS CLI أولًا عبر
msiexec.exe /i https://awscli.amazonaws.com/AWSCLIV2.msi، ثم AWS CDK بـnpm install -g aws-cdk(الإصدار المُختبر: 2.1126.0)، وأخيرًا AgentCore CLI بـnpm install -g @aws/agentcore(الإصدار المُختبر: 0.19.0). تحقّق من توفّر النموذج في منطقتك عبرaws bedrock list-foundation-models --region YOUR_REGION. - اختيار النموذج بدقة: عند إنشاء مشروع AgentCore، الـ flag المسمى
--model-provider Bedrockيحدد المزوّد لكنه لا يُعيّن النموذج. Strands يستخدم نماذج Anthropic افتراضيًا، وأحدث الافتراضيات وقت الكتابة هوglobal.anthropic.claude-sonnet-4-6، لكن أفضل الممارسات تقتضي تحديد النموذج صراحةً. للمساعد التعليمي، Claude Sonnet 4.6 عبر inference profile عالمي هو الأنسب للإجابات المتخصصة، بينما يصلح Claude Haiku أو Amazon Nova Micro لمهام التوجيه البسيطة ذات الحساسية للتكلفة. أما متطلبات الإقامة الجغرافية للبيانات فتستلزم استخدام inference profile إقليمي (أوروبا أو آسيا) بدلًا من الـ global profile. - إنشاء مشروع AgentCore: شغّل الأمر التالي:
agentcore create --name SMETriage --framework Strands --protocol HTTP --model-provider Bedrock --build CodeZip --memory none. الخيار--build CodeZipبديل عملي لبناء Docker image: يجمع ملفات Python، يُحلّ التبعيات، يُنشئ ZIP يحتوي التطبيق ومكتباته المتوافقة مع Linux ARM64، يرفعه إلى S3، ثم يُعدّ AgentCore Runtime لتشغيل نقطة الدخول. بنية المشروع الناتجة: مجلدagentcore/يضمّagentcore.jsonللإعداد وaws-targets.jsonللحساب والمنطقة و.env.localللقيم المحلية فقط، ومجلدapp/SMETriage/يضمّmain.pyوpyproject.tomlللتبعيات. - كتابة كود الوكيل: الوكيل الأساسي لا يحتاج أكثر من نموذج وsystem prompt. مثال على تعريف النموذج صراحةً:
from strands.models import BedrockModelثم إنشاءBedrockModelبـmodel_id="global.anthropic.claude-sonnet-4-6"في منطقةus-west-2معtemperature=0.2وmax_tokens=1_500. السياسة التوجيهية للوكيل مدمجة في system prompt الذي يُحدد المواد الأربع ويأمر النموذج بالرفض الصريح لما هو خارجها — لا حاجة لأداة توجيه منفصلة. - الاختبار المحلي قبل النشر: AgentCore يتيح اختبار الوكيل محليًا عبر
agentcore devالذي يفتح واجهة ويب علىlocalhost:8080. هذه الخطوة ضرورية للتحقق من سلوك النموذج قبل الدفع للسحابة — تأكّد من أن الوكيل يُصنّف الأسئلة بصحة ويرفض ما هو خارج النطاق المحدد. - النشر على AgentCore Runtime: بعد التحقق المحلي، يُنشر الوكيل على AWS عبر AgentCore CLI. Runtime يتولى تلقائيًا عزل الجلسات والتوسع والبث وواجهة الاستدعاء. وكيلنا في هذه المرحلة لا يحتاج أدوات خارجية، لذا نبدأ بدون Gateway أو Browser.
- إضافة AgentCore Memory لاحقًا: الخطوة التالية في تطوير هذا الوكيل هي إضافة مكوّن الذاكرة الذي يخزّن تفضيلات المستخدم بين الجلسات. Memory في AgentCore لا تُخزّن النصوص الخام فحسب، بل تستخرج حقائق وملخصات ونقاط جوهرية قابلة للاستخدام في محادثات مستقبلية — وهو ما يُحوّل الوكيل من مجيب على أسئلة إلى مساعد يتذكر.

النقطة الجوهرية التي يسهل تجاهلها: نشر وكيل عبر AgentCore لا يُغيّر سلوكه. السلوك يأتي من النموذج المختار والكود المكتوب في Strands. AgentCore يتحكم في أين يعمل الوكيل وكيف يُعمَّر — لا في ماذا يفعل. هذا الفصل بين المنطق التطبيقي والبنية التحتية التشغيلية هو ما يُتيح لك تطوير الوكيل دون القلق بشأن التوسع والأمان والإتاحة في كل مرة تُعدّل فيها system prompt. بالنسبة للمطورين الذين يبنون وكلاء مُدارين على الإنتاج لأول مرة، يُقلّل هذا التصميم من التعقيد التشغيلي بشكل ملموس — لكنه لا يُعفيك من التخطيط لمتطلبات الإقامة الجغرافية للبيانات إذا كان تطبيقك يخدم سوقًا محددة.







