The SamurAI · في الإنتاج منذ مارس 2026
Dawn
وكيل مستقل لإدارة المشاريع لا يُكتب فيه شيء قبل أن يوافق عليه إنسان.
- دوري
- صممت وبنيت النظام كاملاً
- الفترة
- 2026، في الإنتاج منذ مارس
التقنيات
- Python
- SurrealDB
- Redis
- OpenRouter
- Llama
- Microsoft Graph
- AWS
- Linux
- GitHub Actions
- Logfire
- Langfuse
في السيرة الذاتية
- صممت وبنيت Dawn، وكيل ذكاء اصطناعي مستقل لإدارة المشاريع، في الإنتاج منذ مارس 2026: يحوّل الاجتماعات المسجلة إلى مهام لها مسؤول وأولوية وموعد، مع موافقة بشرية قبل أي كتابة في Microsoft Planner.
- هندست ذاكرته البيانية: رسم معرفي في SurrealDB مع RAG هجين (بحث متجهي مع تعزيز الحداثة) وذاكرة سياق مؤقتة في Redis (CAG)، متكاملة مع Microsoft Graph API.
- صممت طبقة الحوكمة والأمان: بوابة هوية، سياسات لكل وكيل، رسائل واردة متحقق منها بـ HMAC، سجل تدقيق، عتبة ثقة، وتوجيه البيانات الحساسة إلى نموذج Llama محلي.
- بنيت توجيهاً متعدد النماذج عبر OpenRouter مع تراجع تلقائي؛ نشر على AWS EC2 محصّن مع CI/CD عبر GitHub Actions ومراقبة في Logfire وLangfuse.
المشكلة
فريق استشاري صغير يسجل اجتماعات كثيرة. الالتزامات فيها لم تكن تتحول بموثوقية إلى عمل متابَع: كان على أحدهم قراءة النص، وتحديد من يملك ماذا، وإدخاله في Microsoft Planner. المتابعة كانت تعتمد على الذاكرة.
الطلب لم يكن «أتمتة إدارة المشاريع». كان أضيق وأصعب: إدخال المهام الصحيحة في Planner، بالمسؤول والموعد الصحيحين، دون السماح أبداً للذكاء الاصطناعي بكتابة شيء لم يراجعه أحد.
ما بنيته
يقرأ Dawn نصوص الاجتماعات، ويجمع سياق الفريق اللازم، ويستخرج مهاماً مقترحة بمسؤول وأولوية وموعد ودرجة ثقة، ويرسلها بالبريد إلى مسؤولَي إشراف. يردّان بـ APPROVE أو REJECT. عندها فقط ينشئ Dawn المهام في Planner، ويخزن ما حدث في ذاكرته البيانية، ويبدأ بتذكير المكلفين حين يتعثر العمل.
منعت Microsoft الرسائل المباشرة من التطبيقات في Teams، فأصبح البريد قناة الموافقة. أُطلق قبل أسابيع مما كان سيستغرقه انتظار صلاحيات المسؤول، وأحبه المشرفون.
كيف يعمل
يتحرك تلقائياً. انقر على خطوة للإيقاف.
القرارات والمقايضات
- موافقة بشرية قبل أي كتابة، بدل الإنشاء التلقائي فوق عتبة ثقة
- كان على الثقة أن تأتي أولاً، ونطاق ضرر المهمة الخاطئة أن يكون صفراً. القاعدة المطلقة: لا يصل شيء إلى Planner دون رد.
- CAG وRAG معاً، لا أحدهما
- الحقائق الصغيرة المستقرة مخزنة مؤقتاً في Redis. التاريخ الكبير يُسترجع. مشكلتان مختلفتان.
- إعادة ترتيب هجينة بدل top-k الساذج
- التشابه وحده ترك اجتماعات قديمة تتفوق على الحديثة. التشابه مع الحداثة وعتبة صارمة.
- SurrealDB بدل قاعدة رسوم منفصلة مع مخزن متجهات
- الوثائق والحواف والمتجهات في محرك واحد: مخطط واحد، عميل واحد، نسخة احتياطية واحدة.
- استدعاءات API مباشرة بدل إطار وكلاء
- تدفق تحكم صريح، استدعاءات ذكاء اصطناعي قابلة للبحث، وحالة مرئية في Redis وSurrealDB.
- النماذج أسماء مستعارة خلف موجّه
- تبديل المزوّد سطر واحد. المحتوى الحساس يُجبر على نموذج محلي.
- الأرشفة بعد 90 يوماً بدل الحذف
- للتاريخ قيمة في الأنماط والتخزين رخيص.
الحوكمة
- بوابة الهوية
- فقط مرسلو نطاق الشركة يطلقون إجراءات. الخارجيون يُعاد توجيههم دون بيانات.
- رسائل واردة موقّعة
- كل طلب webhook وارد من Teams يُتحقق منه بـ HMAC-SHA256. التواقيع غير الصالحة تُرفض.
- توجيه البيانات الحساسة
- كلمات مفتاحية مرتبطة بمحتوى منظَّم أو حساس تُجبر نموذجاً محلياً وتُعلّم العنصر للمراجعة.
- سجل التدقيق
- كل مقترح يحتفظ بتعليله وثقته ومن حسمه ومتى. المكلفون لا يرون درجات الثقة أو أسماء النماذج أو المعرّفات.
- مضيف محصّن
- مستخدم خدمة غير جذري، أسرار خارج المستودع، قرص مشفّر، IAM بأقل صلاحية، SSH بالمفتاح فقط، ترقيع تلقائي. يُنشر عبر GitHub Actions؛ يُتتبع في Logfire وLangfuse.
ما تعلمته
- كل خطأ في الإنتاج كان كلاسيكياً من الأنظمة الموزعة: تكرارات، حلقة ذاتية، تحديثات ضائعة. الحل كان التكرارية الآمنة، لا أمراً أذكى.
- الإنسان في الحلقة آلة حالات (معلق، موافق، مرفوض، مكرر، متعثر) وتستحق العناية نفسها كاستدعاء النموذج.
- webhook يجب أن يرد خلال خمس ثوانٍ ومهمة أطول هما برنامجان مختلفان. فصلهما أزال فئة كاملة من الأعطال الصامتة.
- أفضل واجهة للموافقة كانت التي يعيش فيها المشرفون أصلاً. البريد تفوق على واجهة مخصصة.
بُني داخل مستودع شركة خاص. الأسماء وبيانات الاعتماد والمعرّفات الداخلية محذوفة عمداً.
دراسة الحالة التالية
Collaboris