Habr AI: بدلًا من خطوط agent pipeline المعقدة، يُنصح المطورون باستخدام markdown وgit وذاكرة الجلسات

نشر موقع Habr مقالًا تحليليًا يحمل فكرة بسيطة لكنها حادة: معظم الفرق تُعقّد العمل مع وكلاء AI، فتبني خطوط pipeline ضخمة بالاعتماد على LangChain وRAG وvector database، في حين أن التطوير الفعلي يحتاج إلى ذاكرة للقرارات المتخذة أكثر مما يحتاج إلى التنسيق الآلي (orchestration). ويقارن الكاتب الازدهار الحالي لمنظومات الوكلاء بعصر LAMP في منتصف العقد الأول من الألفية: فقد انشغلت الصناعة بالبنية التحتية مرة أخرى، وقلّما تسأل كيف تساعد هذه البنية التحتية في حل مهام المنتج الفعلية.

ويستعرض النص النهج المؤسسي (enterprise) المعتاد: منسّق (orchestrator) يوزّع المهام على عدة وكلاء، وهؤلاء يرجعون إلى RAG لجلب السياق، ويستدعون الأدوات، ويكتبون الكود، ويفتحون pull request. ويرى الكاتب أن هذا المخطط يناسب أتمتة المهام الروتينية، مثل مراجعة الكود (code review) والاختبارات والتدقيق الآلي (linting)، لكنه لا يصمد جيدًا في العمل طويل الأمد. والمشكلة ليست في النموذج بقدر ما هي في بنية الذاكرة: فكل تذكرة جديدة تبدأ لدى الوكيل غالبًا من الصفر تقريبًا، دون سجل ثابت للقرارات، ودون فهم للمجال، ودون القيود التي تراكمت في المشروع. ولذلك يبدو البحث الدلالي (semantic search) في الكود مفيدًا، لكنه لا يحلّ محل المعرفة الفعلية بسبب اختيار الفريق هذا المسار تحديدًا في مرة سابقة.

وبوصفه بديلًا، يُقترح نظام شبه زاهد يقوم على ملفات markdown وgit. فبدلًا من pipeline شامل، يبني الكاتب ذاكرة عمل من الجلسات والأدوار والكفاءات والسياقات والقواعد. وتحفظ الجلسة ثلاثة مستويات من السياق: موجزًا ومتوسطًا وعميقًا، كي يستمر العمل التالي من قرارات موثّقة لا من محادثة فارغة. ولا يصف الدور مبرمجًا مجردًا، بل تخصصًا محددًا بمعارف مجاله: أي واجهات API تُستخدم، وما الأخطاء الشائعة، وما قيود العتاد أو البروتوكول أو المشروع. وهذا، بحسب الكاتب، يقلل هلوسة النموذج أكثر من طبقة إضافية من الأدوات المحيطة باستدعاءات LLM.

ويشدّد الكاتب بوجه خاص على القواعد التي تنشأ من الأخطاء. فإذا حذف الوكيل ملفًا مرة دون تأكيد، أو غرق في تصحيح أخطاء لا ينتهي، أو فقد تغييرات لم تُودَع (uncommitted) عند التبديل بين الفروع، فإن ذلك لا يتحول إلى خدمة middleware جديدة، بل إلى قاعدة صريحة للجلسات اللاحقة. ويسمّي الكاتب هذا النهج التعلّم عبر التأمل (reflection): يتحول الخطأ إلى عقد، ويصبح النظام مع الوقت أكثر متانة.

ويقدّم المقال أيضًا أرقامًا عملية: فخلال أربعة أشهر، بحسب الكاتب، استُخدم هذا المخطط في أكثر من 400 جلسة ضمن 11 مشروعًا، منها مشاريع firmware والتشفير وPKI، وبلغت تكلفة AI في أحد المشاريع نحو 30 دولارًا. والمنطق هنا أن الرموز (tokens) الرخيصة وبنية الملفات البسيطة تعطيان أحيانًا فائدة أكبر من منصة مكلفة متعددة الطبقات.

ويخصص المقال جزءًا مهمًا لا للأدوات فحسب، بل لمستوى التفاعل مع AI. فالكاتب يصف سلّم نضج يبدأ من الإكمال التلقائي وما يُسمى vibe-coding، ويصل إلى شراكة معمارية يحدد فيها المهندس الأدوار والعقود والحدود، ويصبح الكود نتيجة لعملية منظَّمة بصورة صحيحة. ومن هنا تأتي فكرة أوسع: الشركات كثيرًا ما تشتري وهم الاستقلالية، إذ تَعِد أدوات مثل Devin وCopilot Workspace ومنصات الوكلاء المؤسسية بالعمل دون تدخل بشري، لكنها في الواقع تصطدم بنقص ذاكرة المشروع وسياقه.

وبهذا المعنى يُقترح النظر إلى AI لا بوصفه بديلًا للمهندس، بل هيكلًا خارجيًا (exoskeleton) يقوّي المختص ويجعل من يحوّل خبرته الخاصة إلى نظام مُقنَّن أكثر قيمة. ولتعزيز هذه الفكرة، يشير الكاتب حتى إلى مفاهيم قديمة عن التكافل بين الإنسان والحاسوب، وDesign by Contract، وسياق العمل الموحّد، ليبيّن أن المنهجية نفسها أهم هنا من الحزمة التقنية الرائجة.

وبالنسبة إلى السوق، هذه إشارة أخرى إلى أن المرحلة التالية من تطوير AI قد تنتقل من سباق المنسّقات (orchestrators) إلى سباق جودة السياق. ستبقى خطوط pipeline المستقلة مفيدة للمهام الروتينية واسعة النطاق، لكن في المهام الهندسية المعقدة ستتفوق الفرق القادرة على حفظ سجل القرارات، وإضفاء الطابع الرسمي على خبرة المجال، وبناء ذاكرة طويلة الأمد حول النموذج، لا مجرد إضافة طبقات جديدة من البنية التحتية.