بناء وكيل ذكاء اصطناعي في 2026 يعني عادةً التوفيق بين أربعة مكوّنات منفصلة: قوالب المطالبات في مجلد، ومخططات الأدوات بصيغة JSON في مجلد آخر، وشيفرة ربط في مكان ما بينهما، ورسم بياني لسير العمل يجمع كل ذلك. غيّر واحدًا منها، فتكسر الثلاثة الباقية بصمت.
في 22 يوليو 2026، نشرت مختبرات NVIDIA ورقة بحثية تقترح فكرة بسيطة إلى حدّ الجرأة. أطروحتها تتلخص في جملة واحدة: الوكيل هو كائن بايثون.
الإطار يُسمّى NOOA — وكلاء NVIDIA كائنية التوجّه — وهو محايد تجاه النموذج المستخدم. حجّته ليست أننا بحاجة إلى إطار وكلاء أفضل، بل أننا بحاجة في الأساس إلى تجريدات أقل خاصة بالوكلاء، لأن بايثون تمتلك أصلًا تجريدات جيدة.
الفكرة الجوهرية
في NOOA، التطابق بين البرمجة كائنية التوجّه وتصميم الوكلاء مباشر تمامًا:
| مفهوم بايثون | مفهوم الوكيل |
|---|---|
| التوابع (Methods) | الأفعال المتاحة للنموذج |
| الحقول (Fields) | حالة الوكيل |
| سلاسل التوثيق (Docstrings) | المطالبات (Prompts) |
| تعليقات الأنواع (Type hints) | العقود |
الجزء الذكي هو كيف يصبح التابع مدفوعًا بالنموذج. أي تابع يكون جسده حرفيًا ... تُكمله حلقة وكيل يقودها نموذج لغوي وقت التشغيل. أما التابع ذو الجسد الاعتيادي فيبقى بايثون عاديًا وحتميًا.
from dataclasses import dataclass
@dataclass
class InvoiceAuditor:
"""أنت تدقق فواتير المورّدين لشركة صغيرة أو متوسطة.
أبلغ عن أي مخالفة لقواعد الفوترة الإلكترونية."""
company_id: str
flagged: list[str]
def load_invoices(self, month: str) -> list[dict]:
# بايثون عادي. ينفَّذ بشكل حتمي في كل مرة.
return db.query(self.company_id, month)
def assess(self, invoice: dict) -> tuple[bool, str]:
"""حدّد ما إذا كانت هذه الفاتورة متوافقة.
أعِد الحكم مع تبرير من جملة واحدة."""
...التابع load_invoices شيفرة كتبتها أنت. أما assess فشيفرة ينفّذها النموذج. كلاهما يعيش في الصنف نفسه، ويتشارك الحالة نفسها، ويُقرأ بالطريقة نفسها من قِبل مراجع بشري.
هذا القرار التصميمي الواحد هو ما يجعل بقية الفكرة مثيرة للاهتمام. فلأن الوكيل كائن، يمكنك اختباره وتتبّعه وإعادة هيكلته والوراثة منه ووضعه تحت إدارة الإصدارات تمامًا كأي وحدة أخرى في قاعدة شيفرتك. لا يوجد سجل مطالبات منفصل يجب إبقاؤه متزامنًا. فسلسلة التوثيق هي المطالبة، ما يعني أنها تُراجَع في طلب الدمج نفسه مع الشيفرة التي تصفها.
ست أفكار على سطح واحد
المساهمة الثانية للورقة هي دعوى حول التوحيد. تُحدّد NVIDIA ست قدرات موجّهة للنموذج، وتؤكد أن NOOA هو أول إطار يجمعها كلها في مكان واحد:
- مدخلات ومخرجات مُنمَّطة — مخرجات النموذج تُتحقَّق مقابل تعليقات أنواع بايثون حقيقية، لا مقابل مخطط JSON يُصان يدويًا.
- التمرير بالمرجع على كائنات حيّة — يتلقى النموذج مقابض لكائنات فعلية في الذاكرة، لا لقطات مُسلسَلة منها.
- الشيفرة كفعل — يتصرف النموذج بكتابة شيفرة بايثون وتنفيذها، بدل إصدار JSON لاستدعاء أداة.
- حلقة قابلة للبرمجة — حلقة الوكيل نفسها شيفرة تصوغها أنت، لا زمن تشغيل مبهم.
- حالة كائن صريحة — الحالة تعيش في حقول يمكن فحصها، لا مدفونة في سجل المحادثة.
- واجهات إطار قابلة للاستدعاء من النموذج — يمكن للنموذج الاستعلام عن سياقه وتدفق أحداثه عبر استدعاءات توابع عادية.
من اللافت أن المؤلفين لا يدّعون اختراع هذه الأفكار. بل يلاحظون صراحةً أن المجتمع التقني يتقارب أصلًا نحو عدد منها، غالبًا كخصائص تجريبية أو جزئية، ويعرضون المقارنة لتشجيع تبنّيها. هذا التأطير صادق بشكل منعش، وهو على الأرجح الإشارة الأهم للممارسين: هذه الخصائص الست تتحول إلى الحد الأدنى المتوقّع من أي بيئة تشغيل وكلاء جادة.
لماذا التمرير بالمرجع أهم مما يبدو
من بين الست، الفكرة الجديرة بالتوقّف عندها هي التمرير بالمرجع على كائنات حيّة.
معظم أطر الوكلاء تُسلسِل كل شيء. يحتاج وكيلك إلى سجل عميل، فيحوّله الإطار إلى JSON ويضعه في نافذة السياق، فيستدل النموذج على النسخة ويعيد نسخة أخرى عليك التوفيق بينها وبين الواقع. كل رحلة ذهاب وإياب تكلّف رموزًا وتخلق فرصة لانحراف بين الصورة الذهنية للنموذج وقاعدة بياناتك.
تمرير مرجع حيّ يغيّر اقتصاديات النظام. يستطيع النموذج استدعاء تابع على الكائن لجلب الحقل الذي يحتاجه فقط، وقت حاجته إليه، دون أن يحمل السجل الكامل في السياق أبدًا. بالنسبة لوكيل يعمل على مجموعة بيانات كبيرة — كتالوج منتجات، أو قاعدة شيفرة، أو سنة من المعاملات — هذا هو الفرق بين نظام يتّسع داخل نافذة السياق وآخر لا يتّسع.
كما أنه يعالج مشكلة صحّة. إذا عدّل النموذج كائنًا حيًّا، فالتعديل حقيقي. ولا توجد خطوة توفيق قد تفشل.
الشيفرة كفعل تتفوق على JSON استدعاء الأدوات
فكرة «الشيفرة كفعل» تكسب أرضًا بهدوء منذ فترة. حين يعبّر الوكيل عن فعله بشيفرة بايثون قابلة للتنفيذ بدل حمولة استدعاء أداة، فإنه يحصل مجانًا على الحلقات والشروط والتركيب ومعالجة الأخطاء. ثلاثة استدعاءات أدوات متسلسلة تصبح سطرًا واحدًا. وتصفية 500 نتيجة للوصول إلى ثلاث تحدث داخل المفسّر، لا بتمرير 500 نتيجة عبر نافذة السياق.
يُضفي NOOA طابعًا رسميًا على ذلك بجعله السلوك الافتراضي بدل وضع تنفيذ خاص. فالنموذج يكتب أصلًا توابع على كائن؛ والطريقة الطبيعية لاستدعاء خمسة منها تباعًا هي كتابة خمسة أسطر.
المقايضة حقيقية ويجب تسميتها: تنفيذ شيفرة يكتبها النموذج يستلزم بيئة معزولة. أي فريق يتبنّى هذا النمط يحتاج إلى عزل العمليات، وتقييد نظام الملفات، والتحكم في حركة الخروج الشبكية قبل الوصول إلى الإنتاج. الراحة في طبقة التأليف لا تُلغي الحاجة إلى الاحتواء في طبقة التنفيذ.
ما أثبتته NVIDIA فعليًا
المساهمة الثالثة للورقة تجريبية: النماذج الحالية تستخدم هذه الواجهة بفاعلية. تعرض NVIDIA نتائج على اختبارات قدرات مستهدفة، إضافة إلى معايير وكيلية واستدلالية تشمل SWE-bench Verified وTerminal-Bench 2.0 وARC-AGI-3.
المقصود ليس ادّعاء صدارة في لوحة نتائج، بل دعوى تتعلق بقابلية استخدام الواجهة: النماذج المدرَّبة على بايثون الاعتيادي تعرف أصلًا كيف تتعامل مع الأصناف وتعليقات الأنواع وسلاسل التوثيق، لأن هذه الأنماط تشبع بيانات تدريبها. إطار وكلاء يبدو كبايثون اصطلاحي هو، بمعنى حقيقي، مُدرَّب مسبقًا داخل النموذج. أما اللغة الخاصة المصمّمة خصيصًا فليست كذلك.
هذه حجة قوية، وهي تفسّر لماذا تستمر أساليب التصميم في التقارب نحو «اكتب شيفرة عادية فحسب».
ماذا يعني هذا إن كنت تُطلق وكلاء
لست بحاجة إلى تبنّي NOOA للاستفادة من الورقة. الدروس المعمارية تنتقل إلى أي بنية تقنية تشغّلها أصلًا:
أبقِ المطالبة بجوار الشيفرة التي تحكمها. إذا كانت مطالباتك تعيش في ملف YAML منفصل أو مخزن قوالب أو خدمة سحابية لإدارة المطالبات، فقد أنشأت مشكلة مزامنة ستلدغك عند أول إعادة هيكلة. سلاسل التوثيق ليست الحل الوحيد، لكن التجاور شرط أساسي.
اجعل الحالة صريحة. حالة الوكيل المخبّأة داخل سجل محادثة متراكم هي حالة لا يمكنك فحصها ولا التحقق منها ولا إعادة ضبطها. الحقول المسمّاة على كائن قابلة للتنقيح في الثانية صباحًا؛ أما نصّ محادثة من أربعين دورة فلا.
نمِّط حدودك. المخرجات المُتحقَّق منها تلتقط صنفًا كاملًا من الأعطال الصامتة التي يمرّرها التحليل اليدوي لـ JSON. وإن كنت تعمل بـ TypeScript، فهذه هي الحجة نفسها التي يطرحها دليل المخرجات المهيكلة من الاتجاه المقابل.
امتلك حلقتك. الإطار الذي يخفي حلقة الوكيل يخفي بالضبط ما ستحتاج إلى ضبطه: سياسة إعادة المحاولة، والتحقق، والتصعيد، والميزانية. تناولنا ذلك بعمق في هندسة الحلقات لوكلاء الذكاء الاصطناعي.
اختبر الوكلاء كبرمجيات. وعد «الوكيل ككائن» بأكمله هو أن أدواتك الحالية تنطبق عليه. فإن كنت لا تستطيع كتابة اختبار وحدة لوكيلك اليوم، فالتجريد الذي اخترته يعمل ضدك.
التحوّل الأكبر
ثمة نمط واضح في تطوّر أدوات الوكلاء خلال العامين الماضيين. بدأت الأطر معقّدة — رسوم بيانية وعُقد وحواف ومنسّقات وآلات حالة — ثم لم تتوقف عن التخلّص من التجريد منذ ذلك الحين. بسّط LangGraph. وصدرت حزمة OpenAI Agents SDK نحيفة عن قصد. وراهنت smolagents على الشيفرة كفعل. ودفعت إرشادات Anthropic باستمرار نحو حلقات أبسط وأدوات أفضل.
NOOA هو التعبير الأكثر مباشرة عن هذا الاتجاه حتى الآن: ليس إطارًا أخف، بل حجة بأن الإطار الصحيح هو في معظمه اللغة التي تكتب بها أصلًا. حيثما امتلكت بايثون تجريدًا، استخدم تجريد بايثون. ولا تُضِف شيئًا خاصًا بالوكلاء إلا حين لا تملك بايثون إجابة فعلية — السياق، والأحداث، والذاكرة، والحلقات المُتحقَّق منها.
هذا انضباط، لا قائمة ميزات. وهو جدير بالتطبيق أيًّا كان اسم الإطار الذي سينتهي به المطاف في ملف pyproject.toml لديك.
من أين تبدأ
الورقة متاحة على arXiv تحت الرقم 2607.20709 برخصة CC-BY-4.0. وحتى لحظة الكتابة، لم يُفهرَس مستودع عام على نطاق واسع، لذا فالخطوة العملية هي قراءة مبادئ التصميم وتطبيقها على بنيتك الحالية بدل انتظار حزمة تُثبَّت.
إن كنت تقيّم معمارية وكلاء لنظام إنتاجي — وخصوصًا إن كنت توازن بين الارتباط بإطار معيّن والبناء على أساسيات اللغة — فإن الأفكار الست الموجّهة للنموذج تشكّل قائمة تدقيق ممتازة. اعرض بنيتك الحالية عليها؛ الفجوات ستخبرك من أين سيأتي عطلك الإنتاجي القادم.
في نقطة، نبني أنظمة وكلاء ذكاء اصطناعي لشركات في تونس والخليج، وهذه بالضبط هي المحادثة المعمارية التي نجريها في بداية كل مشروع: كم من الإطار تحتاج فعلًا؟ الإجابة تصبح باطّراد: أقل مما تظن.
قراءات ذات صلة: