Autoheal تجمع 7.9 ملايين دولار: وكيلان يراقبان الوكلاء ولا يدمجان التعديل

أعلنت Autoheal من سان فرانسيسكو جمع 7.9 ملايين دولار في جولة تأسيسية يوم 28 سبتمبر 2026 بقيادة Innovation Endeavors، وبمشاركة Emergent Ventures وU&I Ventures وDarkmode Ventures وBatch Ventures وParam Hansa Values. وانضم إلى المستثمرين أفراد، فيما حصل هاربيندر سينغ من الصندوق القائد على مقعد في مجلس إدارة الشركة. ستستخدم Autoheal التمويل لتوسيع منصة موجهة إلى فرق هندسة البرمجيات في المؤسسات، خصوصًا في الأعمال التي تلي كتابة الشيفرة.

يرصد تقرير SiliconANGLE دور وكيلين في المنصة: يقيّم Evaluator عمل الوكلاء المتخصصين، ويقترح Healer تغييرات لتحسين الوكلاء الذين يحصلون على تقييم ضعيف. وتُحفظ التغييرات في Git وتُختبر على نتائج سابقة ثم تُعرض على مهندس لاعتمادها. بهذا تموّل الجولة آلية لتحسين سلوك الوكلاء تحت إشراف بشري؛ فالاقتراح الذي ينشئه Healer لا يندمج تلقائيًا في النسخة المعتمدة.

لماذا تستهدف الجولة العمل بعد كتابة الشيفرة؟

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

تصل Autoheal بين وكلاء البرمجة الموجودين لدى المؤسسة ومستودعات الشيفرة وخطوط التكامل والنشر المستمر وأدوات مراقبة الأنظمة وبيئات التشغيل وتتبع المهام. ويضم السياق الذي يستخدمه الوكلاء معلومات عن الخدمات والإصدارات، إلى جانب المهارات والذاكرة وملفات التعليمات مثل AGENTS.md. وفي طبقة التحكم تُحدد نماذج التشغيل والميزانيات والأدوار وسياسات الموافقة ونطاق الأدوات المسموح بها. هذا الربط هو أساس فكرة الشركة: عندما يتغير السياق المشترك بعد مراجعة هندسية، تستطيع الوكلاء التي تقرؤه الاستفادة من التغيير في تشغيلاتها اللاحقة.

كيف ينتقل الإخفاق إلى تعديل مقترح؟

تبدأ الدورة بإشارة ناتجة من سير العمل الفعلي، مثل تعليق على مراجعة شيفرة، أو إعادة تشغيل فاشلة في التكامل المستمر، أو تنبيه مرتبط بتعديل منشور، أو سبب حادث ظهر بعد التحقيق. يستخدم Evaluator هذه الإشارات لتقييم مسار عمل الوكيل ونتيجته. وتتيح متابعة ما حدث بعد اقتراح الوكيل تقدير أثره في الاختبار والتشغيل، بدل الاكتفاء بمدى إقناع الإجابة عند صدورها.

إذا كشف التقييم أداءً ضعيفًا، يصوغ Healer تغييرًا محددًا ويضعه في طلب مراجعة. قد يمس الاقتراح مهارة يستخدمها الوكيل، أو تعليمات في ملف AGENTS.md، أو ذاكرة مشتركة، أو نطاق أداة، أو النموذج المختار لمهمة معينة. لكل نوع أثر مختلف: تصحيح التعليمات يغير ما يقرؤه الوكيل قبل العمل، بينما تضييق صلاحية أداة يغير ما يستطيع فعله حتى لو بقيت تعليماته كما هي.

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

أين تقف صلاحية الوكلاء؟

تفصل بنية Autoheal بين تشغيل الوكلاء وتغيير القواعد التي تحكمهم. تُحفظ تعديلات السلوك بإصدارات في Git، وتحدد طبقة التحكم هوية الوكيل ودوره وميزانيته والأدوات التي يمكنه استدعاؤها، مع سجل لاستدعاءات الأدوات. هذا التفصيل مهم لفرق البرمجيات والسحابة في المؤسسات المنظمة: يمكن تتبع التعليمات المستخدمة عند اتخاذ قرار، والأداة التي استُخدمت، والشخص الذي سمح بإدخال تعديل لاحق.

تشمل خيارات النشر المعلنة العمل داخل سحابة العميل أو في بيئة معزولة، وتُجرى التقييمات على تشغيلات المؤسسة ونتائجها ضمن حدودها الأمنية. لكن شكل هذه الحدود يعتمد على إعداد النشر والصلاحيات لدى كل عميل. وجود سجل أدوات أو سياسة موافقة في المنصة يحدد آلية الرقابة الممكنة؛ أما فاعليتها في حادث بعينه فتتوقف على ما سُمح للوكيل بقراءته وتنفيذه، وعلى وضوح الأدلة التي تصل إلى المهندس عند مراجعة الطلب.

بنية معلنة ونتائج يرويها العملاء

بنية المنتج: يمكن وصف مسار واضح يبدأ بإشارة من مراجعة الشيفرة أو التكامل المستمر أو الحادث، ويمر بتقييم التشغيل، ثم بطلب تعديل يُختبر ويحتاج موافقة مهندس. هذه هي الآلية التي تعرضها الشركة، وهي تحدد موضع القرار البشري في دورة التحسين. كما تحدد عناصر قابلة للتتبع داخل المؤسسة، منها إصدار التعليمات، وسجل استخدام الأدوات، ونتيجة الاختبار على التشغيلات السابقة.

نتائج العملاء: قال سمير جاين، مسؤول تقنية المعلومات في Nomura Bank، في عرض Autoheal لتجارب العملاء: «Autoheal gives us a platform that takes investigation timelines down from hours to minutes». ويصف العرض أيضًا وصول AvidXchange إلى السبب الجذري للحوادث خلال دقائق. هذه شهادات منشورة من العملاء عبر الشركة، من دون منهجية مقارنة مستقلة منشورة تتيح تقدير حجم التحسن المتوقع في مؤسسة أخرى.

يوضح استخدام Nomura جانبًا من الرهان التشغيلي: جمع الأدلة من أنظمة متعددة مع إبقاء الوصول خاضعًا لضوابط المؤسسة. وإذا اختصر ذلك وقت التحقيق في بيئة العميل، فقد يقل الوقت الذي يقضيه المهندسون في تجميع السياق قبل معالجة الحادث. لكن هذا الأثر يخص تجربة العميل المعلنة؛ فاختلاف الأنظمة الموصولة وجودة سجل الحوادث وصلاحيات الوصول قد يغير النتيجة من فريق إلى آخر.

المرحلة التالية بعد الجولة

تخطط Autoheal لتطوير نماذج أصغر مخصصة للمؤسسات، تتعلم من بياناتها الهندسية داخل حدودها المعتمدة، مع احتمال توسيع المنصة لاحقًا إلى أعمال هندسة البيانات والأمن. وتبقى هذه خطط تطوير، بينما تتعلق الجولة الحالية بتوسيع المنصة ودورة تقييم الوكلاء وتحسينهم. بالنسبة إلى فرق تعتمد هذه الدورة، سيظهر أثرها في طلبات التعديل المتعاقبة: هل تكشف التقييمات تحسنًا مستمرًا في النتائج الفعلية، وهل يظل سجل الموافقات واضحًا كلما اتسع عدد الوكلاء ومهامهم؟

اقرأ أيضًا:

• Zeit AI تجمع 4.3 ملايين يورو: «المهندس الذاتي» ما زال يحتاج بشرًا
• AI Score تجمع 4 ملايين جنيه: مراقبة الوكلاء تصبح سوقًا مستقلة
• Conveo تجمع 50 مليون دولار: مقابلات العملاء تتحول إلى بنية قرار