الـ Agent من جوه — الـ anatomy الكاملة

الـ log اللي حضرتك هتشوفه في أي agent شغال بجد بيتكرر فيه نفس النمط: رسالة من الموديل، استدعاء لـ tool، نتيجة راجعة، رسالة تانية من الموديل. النمط ده البسيط — اللي ممكن تكتب نسخة منه في 100 سطر Python — هو نفسه اللي شركات بتتقيّم بمليارات عشان عملته صح. إزاي حاجة بالبساطة دي تبقى بالصعوبة دي؟ خد كوباية القهوة وتعال نفتح الكبوت.

القطعة الأولى: الـ system prompt — الدستور

كل agent بيبدأ بحاجة اسمها system prompt: نص بيتحط في أول الـ context بيقول للموديل هو مين، وشغلته إيه، وحدوده فين، والـ tools اللي معاه شكلها إيه. ده مش "تعليمات" وخلاص — ده الدستور اللي بيحكم كل قرار جاي. والفرق بين agent محترم وagent بيهبّد، نسبة كبيرة منه بتتحدد هنا.

تقوللي يعني الموضوع كله prompt engineering؟ قولك لأ، استنى. الـ prompt من غير الباقي مايساويش حاجة. تعال نشوف الباقي.

القطعة التانية: الـ tools — الإيدين

كل tool بيتعرّف للموديل بـ 3 حاجات: اسم، وصف، وschema للـ parameters (غالباً JSON Schema). الموديل لما يقرر يستخدم tool، بيطلّع structured output — مثلاً {"name": "read_file", "input": {"path": "src/auth.ts"}} — والـ runtime (الكود اللي حوالين الموديل) هو اللي بينفّذ فعلياً ويرجّع النتيجة.

خد بالك من النقطة دي كويس: الموديل عمره ما بينفّذ حاجة بنفسه. الموديل بيقترح، والـ runtime بينفّذ. وعشان كده الـ permissions والـ sandboxing بيتعملوا في الـ runtime — وده اللي بيخلّيك تنام مرتاح والـ agent شغال على جهازك.

القطعة التالتة: الـ context window — المكتب

تخيّل معايا إن الموديل موظف عبقري، بس مصاب بفقدان ذاكرة كامل بين كل مكالمة والتانية. كل حاجة لازم تكون مكتوبة على مكتبه قدامه: الدستور، الهدف، الكود اللي قراه، الـ errors اللي شافها، المحاولات اللي عملها. المكتب ده هو الـ context window.

وهنا بقى المشكلة الهندسية الحقيقية: المكتب مساحته محدودة. لما الـ session تطول، الـ context يتملي، وساعتها الـ agent الكويس لازم يعمل حاجة من اتنين: يـ compact (يلخّص القديم ويفضّي مكان) أو يـ offload لـ memory خارجية — files بيكتبها لنفسه يرجع يقراها بعدين. الـ context management ده مش رفاهية — هو الفرق بين agent يخلّص task من 50 خطوة وبين واحد ينسى هو كان بيعمل إيه في النص.

القطعة الرابعة: الـ MCP — الكهربا الموحدة

زمان، كل شركة كانت بتعرّف الـ tools بطريقتها. عاوز توصّل agent بـ database؟ اكتب integration مخصوص. بـ GitHub؟ integration تاني. مع كل موديل؟ من الأول. فوضى.

في نوفمبر 2024، Anthropic فتحت الـ Model Context Protocol — بروتوكول مفتوح بيوحّد إزاي أي tool أو data source يقدّم نفسه لأي agent. بالبلدي كده: زي ما الـ USB وحّد توصيل الأجهزة، الـ MCP وحّد توصيل الـ tools. تكتب MCP server مرة واحدة، يشتغل مع أي agent بيدعم البروتوكول. ومع 2025 الموضوع كبر بسرعة لدرجة إن المنافسين نفسهم — OpenAI وGoogle — أعلنوا دعمه. لما منافسينك يتبنوا الـ standard بتاعك، اعرف إن اللعبة اتحسمت.

التويست

دلوقتي اربط القطع الأربعة، وخد التويست: الموديل نفسه — اللي الكل فاكره البطل — هو فعلياً أسهل قطعة تتبدّل في النظام كله. الـ prompt والـ tools والـ context management والـ harness بيفضلوا زي ما هم، وانت ممكن تبدّل الموديل اللي تحتهم زي ما بتبدّل بطارية. وعشان كده الشركات اللي بنت agents كويسة مش خايفة من موديل جديد ينزل — بالعكس، بتستقبله بفرح: نفس الماكينة، محرّك أقوى.

طيب نلخّص الزتونة:

أولاً: agent = system prompt (الدستور) + tools (الإيدين) + context window (المكتب) + runtime loop (الدورة الدموية).

ثانياً: الموديل بيقترح والـ runtime بينفّذ — الأمان كله بيتلعب في الـ runtime.

ثالثاً: الـ context management هو الـ bottleneck الحقيقي في الـ tasks الطويلة — اتعلمه كويس.

رابعاً: الـ MCP بقى الـ standard — أي tool هتبنيه، ابنيه MCP server من الأول.

والسؤال ليك بقى يا هندسة: لو الموديل بقى قطعة قابلة للتبديل… القيمة الحقيقية بقت فين؟ في الموديل ولا في الـ harness اللي حواليه؟ فكّر فيها وانت داخل على الفصل الجاي، اللي هنعمل فيه جولة على الـ coder agents اللي بتتخانق على السوق دلوقتي.