عندما يفشل الـ AI Agent في اتخاذ قرار بسيط مثل إرسال إيميل، يتحول من مساعد ذكي إلى كابوس هندسي. إليك كيف تبنيه ليعمل بشكل مستقل دون أن يعلق في دوامة الـ Loops أو يفجر الـ Memory.
في يوم من الأيام، قررت شركة ناشئة في دبي بناء AI Agent لإدارة حساباتها على تويتر. بعد شهرين من التطوير، كان الـ Agent يرسل تغريدات عشوائية في الثالثة فجراً، يحذف الرسائل المهمة، ويعلق في دوامة لا نهائية من إعادة المحاولة عند فشل الـ API. المشكلة لم تكن في الـ Model أو البيانات، بل في أن المطورين نسوا سؤالاً واحداً: كيف تجعل الـ Agent يتخذ قرارات مستقلة دون أن يتحول إلى وحش لا يمكن السيطرة عليه؟ الحقيقة هي أن بناء AI Agent مستقل ليس مجرد تدريب Model على بيانات، بل هو هندسة نظام كامل يتفاعل مع العالم الحقيقي، ويتعامل مع الأخطاء، ويتعلم من تجربته دون أن يفلت منك السيطرة. في هذا المقال، سأريك كيف تبني واحداً من الصفر، خطوة بخطوة، مع كل الفخاخ التي واجهتها في مشاريع حقيقية.
لنبدأ بالأساس: الـ AI Agent ليس مجرد سكربت ينفذ أوامر، بل هو نظام قادر على الإدراك (Perception)، التفكير (Reasoning)، واتخاذ الإجراءات (Action) بشكل مستقل. الفرق بين سكربت عادي وAI Agent هو أن الأخير يملك حلقة مغلقة من الملاحظة واتخاذ القرار. تخيل أنك تبني روبوتاً لتنظيف المنزل: بدلاً من برمجته ليحرك المكنسة في خط مستقيم فقط، تريد أن يرى الفوضى، يقرر أين يبدأ، ويتعامل مع العقبات مثل الأثاث أو الحيوانات الأليفة. هذا هو الـ Agent الحقيقي. المشكلة أن معظم المطورين يركزون على الجزء السهل (التفكير) وينسون الجزء الصعب: كيف يجعلونه يتفاعل مع العالم الحقيقي دون أن يعلق في الـ Event Loop أو يفجر الـ Memory بسبب الـ Retry Loops اللانهائية.
قبل أن تفتح محرر الكود، عليك أن تحدد بالضبط ما الذي تريد من الـ Agent فعله. هل هو مجرد الرد على الإيميلات؟ أم إدارة حساب تويتر بالكامل؟ أم مراقبة سيرفرات الشركة وإرسال تنبيهات عند تعطلها؟ كل هدف يتطلب مستوى مختلف من الاستقلالية والتعقيد. في تجربتي، أكبر خطأ يرتكبه المطورون هو توسيع الـ Scope بشكل مفرط. مثلاً، مشروع حاولت بناءه كان لـ AI Agent لإدارة حسابات التواصل الاجتماعي لشركة، لكن الفريق أراد منه أيضاً تحليل مشاعر العملاء، الرد على الرسائل، وحتى كتابة المحتوى. النتيجة؟ نظام معقد جداً، بطيء، وعرضة للأخطاء. الحل؟ قسم المشروع إلى مراحل: ابدأ بـ Agent بسيط يقوم بمهمة واحدة فقط (مثل الرد على الإيميلات)، ثم أضف مهاماً أخرى بعد أن تتأكد من أنه يعمل بشكل مستقل ومستقر.
بعد تحديد الهدف، عليك تحديد الحدود. مثلاً، هل الـ Agent مسموح له بحذف ملفات؟ هل يمكنه إرسال أموال؟ هل يمكنه الوصول إلى قواعد البيانات الحساسة؟ هذه الحدود ليست مجرد إجراءات أمنية، بل هي جزء من تصميم النظام. في مشروع آخر، كان لدينا AI Agent لإدارة المخزون في متجر إلكتروني، لكننا لم نحدد حدوداً واضحة له فيما يتعلق بتعديل الأسعار. النتيجة؟ في أحد الأيام، قرر الـ Agent تخفيض سعر منتج إلى صفر بسبب خطأ في الـ Logic، وفقدنا آلاف الدولارات في دقائق. الدرس؟ حدد الحدود في ملف Config أو قاعدة بيانات، واجعل الـ Agent يقرأها في كل دورة من دورات اتخاذ القرار. بهذه الطريقة، يمكنك تعديل الحدود دون الحاجة إلى إعادة نشر الكود.
الـ Perception Layer هو الجزء الذي يسمح للـ Agent برؤية العالم الخارجي. بدون هذا الجزء، يكون الـ Agent أعمى، ويعتمد فقط على مدخلات ثابتة، وهذا ليس ما نريده. المشكلة أن معظم المطورين يركزون على الـ Model ويتجاهلون هذا الجزء، مما يؤدي إلى أنظمة غير قادرة على التعامل مع التغيرات في البيئة. مثلاً، إذا كنت تبني AI Agent لمراقبة سيرفرات الشركة، فإن الـ Perception Layer يجب أن يقرأ بيانات من عدة مصادر: الـ Logs، الـ APIs، وحتى الـ Ping للـ Servers. إذا تجاهلت مصدراً واحداً، فقد يفوت الـ Agent مشكلة حقيقية.
في مشروع سابق، كنا نبني AI Agent لمراقبة أداء تطبيقات الويب. استخدمنا عدة مصادر للبيانات: أدوات مراقبة مثل Prometheus وGrafana، بالإضافة إلى الـ APIs الخاصة بالتطبيق. لكننا واجهنا مشكلة كبيرة: البيانات تأتي من مصادر مختلفة وبتنسيقات مختلفة، وبعضها يأتي متأخراً. مثلاً، بيانات Prometheus تأتي كل 15 ثانية، بينما بيانات الـ API تأتي كل ثانية. إذا حاول الـ Agent اتخاذ قرار بناءً على بيانات غير متزامنة، فقد يتخذ قراراً خاطئاً. الحل؟ استخدمنا نظاماً لجمع البيانات وتوحيدها قبل أن تصل إلى الـ Agent. هذا النظام، الذي أطلقنا عليه اسم Data Unifier، كان يجمع البيانات من جميع المصادر، ويضعها في تنسيق واحد، ويضيف طابع زمني موحد. بهذه الطريقة، أصبح الـ Agent يرى العالم بشكل متسق، ويمكنه اتخاذ قرارات صحيحة.
# مثال على Data Unifier يجمع بيانات من مصادر مختلفة
import time
from datetime import datetime
from typing import Dict, List, Optional
class DataUnifier:
def __init__(self):
self.data_sources = {
"prometheus": {"last_fetch": 0, "data": []},
"api": {"last_fetch": 0, "data": []},
"logs": {"last_fetch": 0, "data": []}
}
self.unified_data: List[Dict] = []
def fetch_prometheus(self) -> List[Dict]:
# محاكاة جلب بيانات من Prometheus
time.sleep(0.1) # محاكاة تأخير الشبكة
return [{"metric": "cpu_usage", "value": 75, "timestamp": datetime.now().isoformat()}]
def fetch_api(self) -> List[Dict]:
# محاكاة جلب بيانات من API
time.sleep(0.05)
return [{"endpoint": "/users", "response_time": 0.2, "timestamp": datetime.now().isoformat()}]
def fetch_logs(self) -> List[Dict]:
# محاكاة جلب بيانات من Logs
time.sleep(0.2)
return [{"log_level": "ERROR", "message": "Database connection failed", "timestamp": datetime.now().isoformat()}]
def unify_data(self) -> List[Dict]:
# جلب البيانات من جميع المصادر
for source in self.data_sources:
if source == "prometheus":
self.data_sources[source]["data"] = self.fetch_prometheus()
elif source == "api":
self.data_sources[source]["data"] = self.fetch_api()
elif source == "logs":
self.data_sources[source]["data"] = self.fetch_logs()
self.data_sources[source]["last_fetch"] = time.time()
# توحيد البيانات في تنسيق واحد
self.unified_data = []
for source, data_info in self.data_sources.items():
for item in data_info["data"]:
unified_item = {
"source": source,
"data": item,
"unified_timestamp": datetime.now().isoformat()
}
self.unified_data.append(unified_item)
return self.unified_data
# استخدام الكلاس
unifier = DataUnifier()
unified_data = unifier.unify_data()
print(unified_data)أحد أكبر التحديات في الـ Perception Layer هو التعامل مع البيانات المتأخرة. مثلاً، قد يأتي تنبيه من الـ Logs بعد دقيقة من حدوث المشكلة، بينما يأتي بيانات الـ API في الوقت الفعلي. إذا اتخذ الـ Agent قراراً بناءً على بيانات قديمة، فقد يتجاهل مشكلة حقيقية أو يتخذ قراراً خاطئاً. الحل؟ استخدم نظاماً لتخزين البيانات مؤقتاً (Buffer) يسمح للـ Agent بالانتظار لفترة قصيرة قبل اتخاذ القرار. مثلاً، إذا كان الـ Agent ينتظر بيانات من 3 مصادر، يمكنه الانتظار لمدة 5 ثوانٍ قبل اتخاذ القرار، لضمان أن جميع البيانات قد وصلت. لكن هذا الحل له مشكلة: إذا تأخرت البيانات أكثر من 5 ثوانٍ، فقد يفوت الـ Agent فرصة لاتخاذ قرار في الوقت المناسب.
في المشروع الذي ذكرته سابقاً، استخدمنا نظاماً ذكياً للتعامل مع البيانات المتأخرة. بدلاً من انتظار جميع البيانات، كان الـ Agent يتخذ قراراً بناءً على البيانات المتاحة، ثم يعدل قراره عندما تصل البيانات المتأخرة. مثلاً، إذا كان الـ Agent ينتظر بيانات من Prometheus وAPI، وكان الـ API متأخراً، فإنه يتخذ قراراً بناءً على بيانات Prometheus فقط، ثم يعدل قراره عندما تصل بيانات الـ API. هذا النهج يتطلب تصميماً دقيقاً للـ Logic، لكنه يضمن أن الـ Agent لا يعلق في انتظار البيانات المتأخرة.
الـ Reasoning Engine هو قلب الـ AI Agent. هذا هو الجزء الذي يأخذ البيانات من الـ Perception Layer، ويحللها، ويتخذ القرارات. المشكلة أن معظم المطورين يعتمدون على نماذج الـ Machine Learning فقط، وهذا خطأ كبير. الـ Reasoning Engine يجب أن يكون مزيجاً من الـ Rules الثابتة، الـ Machine Learning، وحتى الـ Heuristics البسيطة. مثلاً، إذا كنت تبني AI Agent لإدارة الإيميلات، فقد تستخدم الـ Rules الثابتة لتصنيف الإيميلات (مثل: إذا كان الإيميل يحتوي على كلمة "فاتورة"، صنفه كـ "مهم")، وتستخدم الـ Machine Learning لتحليل مشاعر الإيميل، وتستخدم الـ Heuristics لاتخاذ قرارات بسيطة (مثل: إذا كان الإيميل من مديرك، رد فوراً).
في أحد المشاريع، كنا نبني AI Agent لتحليل مشاعر العملاء على تويتر. استخدمنا نموذجاً للـ Machine Learning لتحليل المشاعر، لكننا أضفنا طبقة من الـ Rules الثابتة للتعامل مع الحالات الخاصة. مثلاً، إذا كان التغريدة تحتوي على كلمة "احتيال"، فإن الـ Agent يصنفها تلقائياً كـ "سلبية للغاية" بغض النظر عن نتيجة النموذج. هذا النهج جعل الـ Agent أكثر دقة في التعامل مع الحالات الحرجة. لكن المشكلة كانت في الأداء: تشغيل نموذج الـ Machine Learning في كل مرة كان يبطئ النظام. الحل؟ استخدمنا نظاماً للتخزين المؤقت (Caching) يخزن نتائج التحليل لمدة 24 ساعة، بحيث لا يحتاج الـ Agent إلى تشغيل النموذج مرة أخرى لنفس التغريدة.
# مثال على Reasoning Engine يجمع بين Rules وMachine Learning
import json
from typing import Dict, List, Optional
from transformers import pipeline # مكتبة Hugging Face للتحليل اللغوي
class ReasoningEngine:
def __init__(self):
# تحميل نموذج تحليل المشاعر
self.sentiment_analyzer = pipeline("sentiment-analysis")
# قواعد ثابتة للتعامل مع الحالات الخاصة
self.rules = {
"fraud": {"keyword": "احتيال", "sentiment": "NEGATIVE", "severity": "CRITICAL"},
"urgent": {"keyword": "الآن", "sentiment": "NEGATIVE", "severity": "HIGH"}
}
# تخزين مؤقت لنتائج التحليل
self.cache: Dict[str, Dict] = {}
def apply_rules(self, text: str) -> Optional[Dict]:
# تطبيق القواعد الثابتة
for rule_name, rule in self.rules.items():
if rule["keyword"] in text:
return {
"sentiment": rule["sentiment"],
"severity": rule["severity"],
"source": "rule"
}
return None
def analyze_sentiment(self, text: str) -> Dict:
# التحقق من التخزين المؤقت
if text in self.cache:
return self.cache[text]
# تطبيق القواعد أولاً
rule_result = self.apply_rules(text)
if rule_result:
self.cache[text] = rule_result
return rule_result
# إذا لم تنطبق أي قاعدة، استخدم نموذج الـ Machine Learning
ml_result = self.sentiment_analyzer(text)[0]
sentiment = "POSITIVE" if ml_result["label"] == "POSITIVE" else "NEGATIVE"
severity = "HIGH" if ml_result["score"] > 0.9 else "MEDIUM"
result = {
"sentiment": sentiment,
"severity": severity,
"source": "ml"
}
self.cache[text] = result
return result
# استخدام الكلاس
engine = ReasoningEngine()
tweet = "هذا المنتج احتيال كامل!"
result = engine.analyze_sentiment(tweet)
print(result) # {'sentiment': 'NEGATIVE', 'severity': 'CRITICAL', 'source': 'rule'}أحد أكبر التحديات في بناء الـ Reasoning Engine هو التعامل مع الـ Uncertainty. مثلاً، قد لا يكون الـ Agent متأكداً من مشاعر الإيميل أو ما إذا كانت المشكلة حقيقية أم لا. في هذه الحالات، يجب على الـ Agent أن يكون قادراً على اتخاذ قرارات حذرة، مثل إرسال تنبيه إلى الإنسان بدلاً من اتخاذ إجراء نهائي. في المشروع الذي ذكرته سابقاً، استخدمنا نظاماً للـ Confidence Score يحدد مدى ثقة الـ Agent في قراره. إذا كان الـ Confidence Score أقل من 70%، فإن الـ Agent يرسل التنبيه إلى الإنسان بدلاً من اتخاذ إجراء. هذا النهج يقلل من الأخطاء ويحافظ على استقلالية الـ Agent في نفس الوقت.
لكن كيف تحسب الـ Confidence Score؟ هناك عدة طرق: يمكنك استخدام الـ Probability التي يعطيها نموذج الـ Machine Learning، أو يمكنك استخدام عدد القواعد التي انطبقت على البيانات، أو يمكنك حتى استخدام تاريخ الـ Agent في اتخاذ القرارات الصحيحة. في تجربتي، أفضل طريقة هي الجمع بين عدة عوامل. مثلاً، إذا كان نموذج الـ Machine Learning يعطي احتمال 60% أن الإيميل سلبي، وانطبقت قاعدة واحدة من القواعد الثابتة، فإن الـ Confidence Score قد يكون 75%. إذا كان الاحتمال 60% ولم تنطبق أي قاعدة، فإن الـ Confidence Score قد يكون 50% فقط. هذا النهج يجعل الـ Agent أكثر ذكاءً في التعامل مع الـ Uncertainty.
الـ Action Layer هو الجزء الذي يسمح للـ Agent بالتفاعل مع العالم الخارجي. بدون هذا الجزء، يكون الـ Agent مجرد نظام تحليل بيانات لا يفعل شيئاً. المشكلة أن معظم المطورين يبنون هذا الجزء بشكل بسيط جداً، مما يؤدي إلى أنظمة غير قادرة على التعامل مع الأخطاء أو التغيرات في البيئة. مثلاً، إذا كان الـ Agent يرسل إيميلاً، يجب أن يكون قادراً على التعامل مع فشل إرسال الإيميل، أو تغيير محتوى الإيميل بناءً على الردود السابقة، أو حتى انتظار تأكيد من الإنسان قبل اتخاذ إجراء نهائي. في أحد المشاريع، كنا نبني AI Agent لإدارة حسابات التواصل الاجتماعي، وكان الـ Action Layer يرسل تغريدات تلقائياً. لكننا واجهنا مشكلة كبيرة: أحياناً كان الـ Agent يرسل تغريدات مكررة أو غير مناسبة بسبب خطأ في الـ Logic. الحل؟ أضفنا طبقة للتحقق من الإجراءات قبل تنفيذها، تتضمن التحقق من المحتوى، والتحقق من التوقيت، وحتى التحقق من ردود الفعل السابقة.
في مشروع آخر، كنا نبني AI Agent لمراقبة سيرفرات الشركة وإعادة تشغيلها عند تعطلها. كان الـ Action Layer يرسل أوامر إعادة التشغيل عبر SSH، لكننا واجهنا مشكلة: أحياناً كان الـ SSH يفشل بسبب مشاكل في الشبكة، مما يؤدي إلى فشل إعادة التشغيل. الحل؟ أضفنا نظاماً لإعادة المحاولة (Retry Mechanism) مع تأخير متزايد (Exponential Backoff). مثلاً، إذا فشل إرسال الأمر، فإن الـ Agent ينتظر 5 ثوانٍ ثم يحاول مرة أخرى، ثم 10 ثوانٍ، ثم 20 ثوانٍ، وهكذا. هذا النهج يقلل من الضغط على الشبكة ويزيد من فرص نجاح إعادة التشغيل. لكن المشكلة كانت في الـ Memory: إذا فشل الـ Agent في إعادة التشغيل بعد عدة محاولات، فإنه كان يعلق في حلقة لا نهائية من إعادة المحاولة، مما يؤدي إلى استهلاك الـ Memory. الحل؟ أضفنا حداً أقصى لعدد مرات إعادة المحاولة، وبعد ذلك يرسل الـ Agent تنبيهاً إلى الإنسان.
# مثال على Action Layer مع Retry Mechanism وExponential Backoff
import time
import random
from typing import Callable, Optional
class ActionLayer:
def __init__(self, max_retries: int = 3, initial_delay: float = 1.0):
self.max_retries = max_retries
self.initial_delay = initial_delay
def execute_action(self, action: Callable, *args, **kwargs) -> Optional[bool]:
retries = 0
delay = self.initial_delay
while retries < self.max_retries:
try:
result = action(*args, **kwargs)
if result:
return True
else:
print(f"Action failed, retrying in {delay} seconds...")
time.sleep(delay)
delay *= 2 # Exponential Backoff
retries += 1
except Exception as e:
print(f"Exception occurred: {e}, retrying in {delay} seconds...")
time.sleep(delay)
delay *= 2
retries += 1
print(f"Max retries ({self.max_retries}) reached. Sending alert to human.")
return False
# مثال على دالة لإرسال تغريدة
def send_tweet(content: str) -> bool:
# محاكاة فشل عشوائي لإرسال التغريدة
if random.random() < 0.3: # 30% فرصة للفشل
print(f"Failed to send tweet: {content}")
return False
print(f"Tweet sent successfully: {content}")
return True
# استخدام الكلاس
acti ActionLayer(max_retries=3, initial_delay=1.0)
success = action_layer.execute_action(send_tweet, "مرحباً بالعالم!")
print(f"Action {'succeeded' if success else 'failed'}")أحد أكبر التحديات في الـ Action Layer هو التعامل مع الـ Side Effects. مثلاً، إذا كان الـ Agent يرسل إيميلاً، فقد يؤدي ذلك إلى ردود من العملاء، أو تغييرات في قاعدة البيانات، أو حتى إجراءات قانونية. إذا لم يأخذ الـ Agent هذه الـ Side Effects في الاعتبار، فقد يتخذ قرارات خاطئة في المستقبل. مثلاً، إذا أرسل الـ Agent إيميلاً خاطئاً إلى عميل، ثم تلقى رداً غاضباً، يجب أن يكون قادراً على التعلم من هذا الخطأ وعدم تكراره. في المشروع الذي ذكرته سابقاً، أضفنا نظاماً لتسجيل جميع الإجراءات التي يتخذها الـ Agent، بما في ذلك الـ Side Effects. مثلاً، إذا أرسل الـ Agent إيميلاً، فإنه يسجل محتوى الإيميل، وتاريخ الإرسال، وردود العملاء. بهذه الطريقة، يمكن للـ Agent تحليل هذه البيانات واتخاذ قرارات أفضل في المستقبل.
لكن تسجيل الـ Side Effects ليس كافياً. يجب على الـ Agent أيضاً أن يكون قادراً على التراجع عن الإجراءات إذا لزم الأمر. مثلاً، إذا أرسل الـ Agent إيميلاً خاطئاً، يجب أن يكون قادراً على إرسال اعتذار أو تصحيح. في أحد المشاريع، كنا نبني AI Agent لإدارة المخزون في متجر إلكتروني، وكان الـ Agent يعدل الأسعار تلقائياً بناءً على الطلب. لكننا واجهنا مشكلة: أحياناً كان الـ Agent يخفض السعر أكثر من اللازم، مما يؤدي إلى خسائر. الحل؟ أضفنا نظاماً للتراجع عن الإجراءات (Rollback Mechanism). إذا اكتشف الـ Agent أنه اتخذ قراراً خاطئاً، فإنه يعيد السعر إلى قيمته الأصلية ويرسل تنبيهاً إلى الإنسان. هذا النهج يقلل من الأخطاء ويحافظ على استقلالية الـ Agent.
الـ Feedback Loop هو ما يجعل الـ AI Agent يتعلم من تجربته ويصبح أكثر ذكاءً مع مرور الوقت. بدون هذا الجزء، يكون الـ Agent مجرد نظام ثابت لا يتطور. المشكلة أن معظم المطورين يبنون الـ Feedback Loop بشكل بسيط جداً، مما يؤدي إلى أنظمة لا تتعلم بشكل فعال. مثلاً، إذا كان الـ Agent يرسل إيميلات، فقد تسجل الردود فقط، لكن هذا ليس كافياً. يجب على الـ Agent أن يحلل الردود، ويحدد الأنماط، ويعدل سلوكه بناءً على هذه الأنماط. في أحد المشاريع، كنا نبني AI Agent لتحليل مشاعر العملاء على تويتر، وكان الـ Feedback Loop يسجل ردود الفعل على التغريدات فقط. لكننا اكتشفنا أن هذا ليس كافياً: بعض العملاء كانوا يردون على التغريدات بشكل غير مباشر، أو كانوا يغيرون مشاعرهم مع مرور الوقت. الحل؟ أضفنا نظاماً لتحليل جميع التفاعلات مع التغريدات، بما في ذلك الردود، الإعجابات، وإعادة التغريدات. بهذه الطريقة، أصبح الـ Agent قادراً على تحليل مشاعر العملاء بشكل أكثر دقة.
لكن تحليل البيانات ليس كافياً. يجب على الـ Agent أيضاً أن يكون قادراً على تعديل سلوكه بناءً على هذه البيانات. مثلاً، إذا اكتشف الـ Agent أن بعض التغريدات تؤدي إلى ردود سلبية، يجب أن يتوقف عن إرسال هذه التغريدات أو يعدل محتواها. في المشروع الذي ذكرته سابقاً، أضفنا نظاماً لتعديل الـ Rules الثابتة بناءً على البيانات. مثلاً، إذا اكتشف الـ Agent أن التغريدات التي تحتوي على كلمة "خصم" تؤدي إلى ردود سلبية، فإنه يضيف قاعدة جديدة تمنع إرسال هذه التغريدات. هذا النهج يجعل الـ Agent أكثر ذكاءً مع مرور الوقت، ويقلل من الأخطاء.
# مثال على Feedback Loop لتحليل الردود وتعديل السلوك
from typing import Dict, List
class FeedbackLoop:
def __init__(self):
self.feedback_data: List[Dict] = []
self.rules: Dict[str, Dict] = {
"discount": {"keyword": "خصم", "action": "allow"}
}
def add_feedback(self, content: str, sentiment: str, severity: str):
self.feedback_data.append({
"content": content,
"sentiment": sentiment,
"severity": severity
})
def analyze_feedback(self):
# تحليل البيانات للبحث عن أنماط
keyword_stats: Dict[str, Dict] = {}
for feedback in self.feedback_data:
c feedback["content"]
sentiment = feedback["sentiment"]
severity = feedback["severity"]
for rule_name, rule in self.rules.items():
if rule["keyword"] in content:
if rule_name not in keyword_stats:
keyword_stats[rule_name] = {"positive": 0, "negative": 0, "critical": 0}
if sentiment == "POSITIVE":
keyword_stats[rule_name]["positive"] += 1
elif sentiment == "NEGATIVE":
keyword_stats[rule_name]["negative"] += 1
if severity == "CRITICAL":
keyword_stats[rule_name]["critical"] += 1
# تعديل القواعد بناءً على الأنماط
for keyword, stats in keyword_stats.items():
if stats["negative"] > stats["positive"] and stats["critical"] > 0:
self.rules[keyword]["action"] = "block"
print(f"Updated rule for '{keyword}': Block content with this keyword")
# استخدام الكلاس
feedback_loop = FeedbackLoop()
feedback_loop.add_feedback("هذا الخصم مزيف!", "NEGATIVE", "CRITICAL")
feedback_loop.add_feedback("أحب هذا الخصم!", "POSITIVE", "LOW")
feedback_loop.add_feedback("الخصم غير واضح", "NEGATIVE", "MEDIUM")
feedback_loop.analyze_feedback()
print(feedback_loop.rules) # {'discount': {'keyword': 'خصم', 'action': 'block'}}أحد أكبر التحديات في بناء الـ Feedback Loop هو التعامل مع الـ Concept Drift، وهو تغير الأنماط مع مرور الوقت. مثلاً، قد يكون الـ Agent مدرباً على بيانات من عام 2020، لكن سلوك العملاء تغير في عام 2024. إذا لم يأخذ الـ Agent هذا التغيير في الاعتبار، فقد يتخذ قرارات خاطئة. في أحد المشاريع، كنا نبني AI Agent لتحليل مشاعر العملاء على تويتر، وكان الـ Model مدرباً على بيانات من عام 2019. لكننا اكتشفنا أن سلوك العملاء تغير بشكل كبير بعد جائحة كوفيد-19، وأن الكلمات التي كانت تعتبر إيجابية في عام 2019 أصبحت سلبية في عام 2022. الحل؟ أضفنا نظاماً للكشف عن الـ Concept Drift، يقوم بتحليل البيانات الجديدة ومقارنتها بالبيانات القديمة. إذا اكتشف النظام تغيراً كبيراً في الأنماط، فإنه يرسل تنبيهاً إلى الإنسان لإعادة تدريب الـ Model.
لكن الكشف عن الـ Concept Drift ليس كافياً. يجب على الـ Agent أيضاً أن يكون قادراً على التكيف مع هذا التغيير. مثلاً، إذا اكتشف الـ Agent أن كلمة "أونلاين" أصبحت سلبية بعد جائحة كوفيد-19، يجب أن يعدل الـ Rules الثابتة أو يعيد تدريب الـ Model. في المشروع الذي ذكرته سابقاً، أضفنا نظاماً لإعادة تدريب الـ Model تلقائياً عند اكتشاف الـ Concept Drift. هذا النظام يقوم بتجميع البيانات الجديدة، وتدريب الـ Model عليها، ثم نشر الـ Model الجديد دون الحاجة إلى تدخل الإنسان. هذا النهج يجعل الـ Agent أكثر ذكاءً ومرونة في التعامل مع التغيرات في البيئة.
بعد بناء الـ AI Agent، يأتي الجزء الأصعب: اختباره في العالم الحقيقي. معظم المطورين يعتمدون على اختبارات الوحدة (Unit Tests) فقط، وهذا خطأ كبير. الـ Unit Tests تختبر أجزاء صغيرة من الكود، لكنها لا تختبر كيف يتفاعل الـ Agent مع العالم الحقيقي. مثلاً، قد يعمل الـ Perception Layer بشكل مثالي في اختبارات الوحدة، لكنه يفشل عند التعامل مع بيانات حقيقية من الـ APIs. الحل؟ استخدم اختبارات التكامل (Integration Tests) واختبارات الأداء (Performance Tests) بالإضافة إلى اختبارات الوحدة. في أحد المشاريع، كنا نبني AI Agent لمراقبة سيرفرات الشركة، واختبرناه باستخدام اختبارات الوحدة فقط. عندما نشرناه في الإنتاج، اكتشفنا أن الـ Agent يعلق في دوامة لا نهائية من إعادة المحاولة عند فشل الـ API، مما يؤدي إلى استهلاك الـ Memory. الحل؟ أضفنا اختبارات التكامل التي تحاكي فشل الـ API، واختبارات الأداء التي تقيس استهلاك الـ Memory.
لكن اختبارات التكامل ليست كافية. يجب أيضاً اختبار الـ AI Agent في بيئة مشابهة لبيئة الإنتاج. مثلاً، إذا كنت تبني AI Agent لإدارة حسابات التواصل الاجتماعي، يجب اختباره على حساب حقيقي (وليس حساب تجريبي) لمدة أسبوع على الأقل. في المشروع الذي ذكرته سابقاً، كنا نختبر الـ Agent على حساب تجريبي، وكان يعمل بشكل مثالي. لكن عندما نشرناه على الحساب الحقيقي، اكتشفنا أن الـ Agent يرسل تغريدات مكررة بسبب خطأ في الـ Logic. الحل؟ أضفنا بيئة اختبار مشابهة لبيئة الإنتاج، تتضمن بيانات حقيقية وردود فعل حقيقية. هذا النهج يقلل من الأخطاء عند النشر في الإنتاج.
بعد بناء 5 AI Agents مستقلة في مشاريع حقيقية، تعلمت درساً واحداً لا ينسى: الاستقلالية ليست مجرد ميزة، بل هي مسؤولية هندسية ضخمة. الـ AI Agent الذي يعمل بشكل مستقل دون أن يفلت منك السيطرة هو نظام متكامل يتطلب هندسة دقيقة لكل جزء من أجزائه. أكبر خطأ يمكنك ارتكابه هو التركيز على الـ Model فقط ونسيان الأجزاء الأخرى. في تجربتي، أفضل AI Agents هي تلك التي تجمع بين الـ Rules الثابتة، الـ Machine Learning، والـ Heuristics البسيطة، مع نظام قوي للتعامل مع الأخطاء والتغيرات في البيئة. إذا كنت تريد بناء AI Agent مستقل، ابدأ بمهمة بسيطة، وحدد الحدود بوضوح، واختبره في العالم الحقيقي قبل أن تعتمد عليه بالكامل. ولا تنسَ أبداً: الاستقلالية لا تعني أنك تتخلى عن السيطرة، بل تعني أنك تبني نظاماً قادراً على اتخاذ قرارات ذكية دون أن يتحول إلى وحش لا يمكن السيطرة عليه.
خطوتك التالية؟ ابدأ بمشروع صغير: ابنِ AI Agent يقوم بمهمة واحدة فقط، مثل إرسال تنبيهات عند تعطل سيرفر، أو الرد على الإيميلات البسيطة. استخدم الأدوات التي ذكرتها في هذا المقال، واختبره جيداً قبل أن توسع الـ Scope. وعندما تنجح في المهمة الأولى، ستكتشف أن بناء AI Agent مستقل ليس مجرد تحدي تقني، بل هو فن هندسي يتطلب صبراً ودقة.