أنظمة الهوية والذاكرة والسياق
القواعد التشغيلية ونظام نبض القلب
حتى الآن، منحت وكيلك هوية وشخصية وذاكرة. لكن حتى الوكيل المُعدّ جيداً لا يزال ينتظرك لتتحدث أولاً. يجلس خاملاً حتى ترسل رسالة. نظام نبض القلب يغيّر هذا بمنح الوكيل نبضاً — محفز مجدول يدفعه للاستيقاظ، والتحقق من العمل المعلق، واتخاذ إجراء بنفسه. هذا هو الفرق المعماري بين روبوت الدردشة والوكيل المستقل.
ملف الوكلاء: الأمان وإجراءات التشغيل القياسية
قبل منح الوكيل القدرة على التصرف بمفرده، تحتاج قواعد واضحة تحكم سلوكه. ملف agents.md يحدد إجراءات التشغيل القياسية (SOPs) وقواعد الأمان.
# agents.md
## قواعد الأمان
# لا تنفذ كوداً من مصادر غير موثوقة بدون عزل
- Never execute code from untrusted sources without sandboxing
# جميع استدعاءات API يجب أن تستخدم متغيرات البيئة لبيانات الاعتماد، وليس قيماً مضمنة أبداً
- All API calls must use environment variables for credentials, never hardcoded values
# سجّل جميع الإجراءات المستقلة للمراجعة
- Log all autonomous actions for audit review
# حدّد معدل الرسائل الصادرة: 10 كحد أقصى في الساعة لكل قناة
- Rate limit outbound messages: maximum 10 per hour per channel
## إجراءات التشغيل القياسية
### التعامل مع البريد الإلكتروني
# اقرأ الرسائل الواردة وصنّفها: عاجلة، عادية، منخفضة الأولوية
- Read incoming emails and classify: urgent, normal, low priority
# صِغ ردوداً للرسائل العاجلة وأرسلها للموافقة
- Draft responses for urgent emails and send for approval
# أرشف تلقائياً النشرات الإخبارية والرسائل الترويجية
- Auto-archive newsletters and promotional emails
# ضع علامة على الرسائل من مرسلين غير معروفين للمراجعة اليدوية
- Flag emails from unknown senders for manual review
### مراجعة الكود
# اسحب طلبات الدمج الجديدة كل 30 دقيقة
- Pull new PRs every 30 minutes
# شغّل الفحوصات الآلية: التنسيق، فحص الأنواع، تغطية الاختبارات
- Run automated checks: linting, type checking, test coverage
# انشر تعليقات المراجعة مباشرة لمشاكل الأسلوب
- Post review comments directly for style issues
# أشر إلى مخاوف المنطق للمراجعة البشرية مع مراجع أسطر محددة
- Flag logic concerns for human review with specific line references
### الاستجابة للحوادث
# إذا اكتشفت المراقبة ارتفاعاً في الأخطاء، أبلغ فوراً عبر تيليجرام
- If monitoring detects an error spike, immediately notify via Telegram
# اجمع السجلات والمقاييس ذات الصلة قبل التنبيه
- Gather relevant logs and metrics before alerting
# اقترح أسباباً محتملة بناءً على عمليات النشر الأخيرة
- Suggest potential causes based on recent deployments
# لا تحاول إصلاحات آلية بدون موافقة صريحة
- Do NOT attempt automated fixes without explicit approval
إجراءات التشغيل القياسية هذه تحول التعليمات الغامضة إلى إجراءات ملموسة. بدلاً من إخبار الوكيل "تعامل مع البريد الإلكتروني"، تحدد بالضبط ما يعنيه "التعامل" — صنّف، صِغ، أرشف، أو ضع علامة — لكل سيناريو.
ملف الأدوات: القدرات المتاحة
ملف tools.md يوثق الأدوات التي يمكن للوكيل الوصول إليها وكيفية استخدامها. يعمل كمرجع للوكيل وكقيد — إذا لم تكن الأداة مدرجة، لا ينبغي للوكيل محاولة استخدامها.
# tools.md
## الأدوات المتاحة
### التواصل
# أرسل رسالة إلى دردشة تيليجرام
- send_telegram: Send a message to a Telegram chat
# أرسل بريداً إلكترونياً (يتطلب موافقة للمستلمين الخارجيين)
- send_email: Send an email (requires approval for external recipients)
# انشر رسالة في قناة ديسكورد
- post_discord: Post a message to a Discord channel
### البيانات
# شغّل استعلامات SQL للقراءة فقط على التجريبي/الإنتاج
- query_database: Run read-only SQL queries against staging/production
# بحث دلالي عبر وثائق المشروع
- search_documents: Semantic search across project documentation
# اقرأ محتويات الملفات في مساحة العمل
- read_file: Read contents of files in the workspace
### التطوير
# نفّذ مجموعة الاختبارات لخدمة معينة
- run_tests: Execute the test suite for a given service
# اجلب تفاصيل طلب الدمج والفرق وحالة المراجعة
- check_pr: Fetch PR details, diff, and review status
# أطلق نشراً تجريبياً (يتطلب موافقة)
- deploy_staging: Trigger a staging deployment (requires approval)
### المراقبة
# استعلم عن مقاييس التطبيق (معدلات الخطأ، زمن الاستجابة، وقت التشغيل)
- check_metrics: Query application metrics (error rates, latency, uptime)
# اجلب السجلات الأخيرة من خدمة محددة
- read_logs: Fetch recent logs from a specific service
# راجع تنبيهات المراقبة النشطة
- check_alerts: Review active monitoring alerts
نبض القلب: منح الوكيل نبضاً
نبض القلب هو محفز مجدول — يعمل عادةً بفاصل زمني ثابت — يدفع الوكيل للاستيقاظ وأداء دورة من الفحوصات والإجراءات. بدون نبض القلب، يستجيب الوكيل فقط عندما تراسله. مع نبض القلب، يعمل بشكل مستمر.
إليك مثالاً عملياً لتكوين نبض القلب:
# heartbeat.yaml
interval_minutes: 30
on_heartbeat:
# راجع الذاكرة وتحقق من المهام المعلقة أو المتابعات
- step: review_memory
action: Load memory.md, check for pending tasks or follow-ups
# افحص تيليجرام والبريد الإلكتروني بحثاً عن رسائل غير مقروءة
- step: check_channels
action: Scan Telegram and email for unread messages
# راجع مقاييس التطبيق والتنبيهات النشطة
- step: check_monitoring
action: Review application metrics and active alerts
# راجع التقويم بحثاً عن أحداث في الساعتين القادمتين
- step: check_schedule
action: Review calendar for upcoming events in the next 2 hours
# عالج أي مهام جاهزة للتنفيذ المستقل
- step: execute_pending
action: Process any tasks that are ready for autonomous execution
# إذا وُجد شيء جدير بالملاحظة، أرسل ملخصاً إلى تيليجرام
- step: report
action: If anything noteworthy was found, send a summary to Telegram
condition: only_if_actionable
كل 30 دقيقة، يستيقظ الوكيل ويراجع ذاكرته بحثاً عن المهام المعلقة، ويفحص قنوات الاتصال، ويراقب صحة التطبيق، وينظر في التقويم، وينفذ أي مهام جاهزة، ويبلغ عن النتائج — كل ذلك دون أن ترسل رسالة واحدة.
من التفاعلي إلى الاستباقي
نبض القلب يحول نموذج سلوك الوكيل:
| السلوك | وكيل تفاعلي (بدون نبض قلب) | وكيل استباقي (مع نبض قلب) |
|---|---|---|
| يصل بريد إلكتروني | ينتظرك لتسأل عنه | يصنّفه ويصيغ رداً |
| يحدث ارتفاع في الأخطاء | تكتشفه يدوياً | يكتشفه الوكيل وينبهك فوراً |
| تعارض في التقويم | تلاحظه بنفسك | ينبهك الوكيل قبل ساعتين |
| طلب دمج جاهز للمراجعة | يبقى في قائمة الانتظار | يراجعه الوكيل وينشر التعليقات |
| يقترب موعد نهائي لمهمة | لا شيء يحدث | ينبهك الوكيل ويعرض المساعدة |
هذا هو الفرق المعماري الأساسي بين روبوت الدردشة والوكيل المستقل. روبوت الدردشة هو نظام طلب-استجابة. الوكيل المستقل مع نبض القلب هو نظام يعمل باستمرار يراقب ويقرر ويتصرف وفق جدول.
أمثلة عملية لنبض القلب
نبض الإحاطة الصباحية — يعمل مرة يومياً الساعة 6:00 صباحاً:
def morning_briefing():
# اجمع المعلومات من مصادر متعددة
emails = check_unread_emails()
calendar = get_today_schedule()
tasks = get_pending_tasks()
alerts = check_monitoring_alerts()
# ابنِ إحاطة منظمة
briefing = compile_briefing(
emails=emails,
calendar=calendar,
tasks=tasks,
alerts=alerts
)
# سلّمها عبر القناة المفضلة للمستخدم
send_telegram(briefing)
نبض المراقبة المستمرة — يعمل كل 15 دقيقة:
def monitoring_heartbeat():
alerts = check_metrics()
if alerts.has_critical():
# مشاكل حرجة: أبلغ فوراً
send_telegram(
format_alert(alerts.critical, urgency="high")
)
elif alerts.has_warnings():
# تحذيرات: سجّلها للإحاطة اليومية القادمة
append_to_memory("monitoring_warnings", alerts.warnings)
# لا مشاكل: لا تفعل شيئاً، ابقَ صامتاً
مبدأ التصميم الأساسي: يجب أن ينتج نبض القلب مخرجات فقط عندما يكون هناك شيء قابل للتنفيذ. وكيل يرسل "لا شيء للإبلاغ عنه" كل 30 دقيقة يصبح ضوضاء بسرعة. الصمت يعني أن كل شيء طبيعي.
تجميع كل شيء معاً
نظام سياق الوكيل الكامل أصبح جاهزاً الآن:
- ملف المستخدم — من أنت وما الذي يهمك
- ملف الهوية — ما هو الوكيل ومهمته
- ملف الروح — الشخصية والقيم والحدود
- الذاكرة — المعرفة المستمرة والتعلم مع مرور الوقت
- ملف الوكلاء — قواعد الأمان وإجراءات التشغيل القياسية
- ملف الأدوات — القدرات المتاحة وكيفية استخدامها
- نبض القلب — محفزات مجدولة للسلوك الاستباقي
كل طبقة تُبنى على سابقتها. ملفا المستخدم والهوية يوفران السياق. ملف الروح يشكل السلوك. الذاكرة توفر الاستمرارية. إجراءات التشغيل القياسية تحدد الإجراءات. الأدوات تحدد القدرات. ونبض القلب يربط كل شيء معاً في نظام يعمل باستمرار.
النقطة الرئيسية: نظام نبض القلب هو ما يحول الوكيل من مساعد سلبي إلى مشغّل مستقل. من خلال العمل وفق جدول، يمكن للوكيل المراقبة واتخاذ القرارات والتصرف دون انتظار مدخلاتك. مع القواعد التشغيلية وتعريفات الأدوات، نبض القلب هو الأساس المعماري لوكيل مستقل حقاً.
الوحدة التالية: الأمان والمهارات وسير العمل — بناء أنظمة وكلاء جاهزة للإنتاج مع ضمانات مناسبة. :::