يجمع Kodacode 1.3 أربعة أوضاع لعمل الوكيل في عميل Desktop واحد

كتب الوكيل الشيفرة وعدّل نحو عشرة ملفات، ثم بدأ العمل المعتاد: فتح التغييرات، وفحص كل تعديل، وتشغيل الاختبارات، وبعد ذلك محاولة فهم سبب انتهاء الأتمتة داخل CI بنص غريب بدلا من حالة واضحة. يحاول Kodacode 1.3 جمع هذه العملية المتقطعة في مكان واحد. يستطيع الوكيل الآن التعامل مع التطبيقات عبر واجهاتها، وفتح الصفحات في المتصفح المدمج، وعرض تعديلاته، والعمل داخل خط أنابيب مع نتيجة قابلة للقراءة آليا.

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

الوكيل يتجاوز حدود المحرر

يتيح وضع Computer Use لـKodacode رؤية الشاشة، والعثور على النافذة المطلوبة، والنقر على عناصر الواجهة، والتمرير في الصفحات، وإدخال النص. وهو متاح في تطبيق سطح المكتب وفي إضافات IDE ضمن وضع Agent.

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

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

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

عرض التعديلات والنماذج الأولية بجوار الحوار

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

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

وثمة سيناريو منفصل هو النماذج الأولية التفاعلية. يستطيع الوكيل تجميع عدة شاشات باستخدام مكونات المشروع وأنماطه الحالية، ثم يمكن للفريق مقارنة نسختي الهاتف المحمول وDesktop. لا يحل ذلك محل مراجعة التصميم، لكنه يسرّع اختبار الفرضية قبل أن يبدأ المطورون صقل التنفيذ.

يجعل Flows وCLI الوكيل جزءا من النظام

Flows هو منشئ مرئي للأتمتة يشبه n8n أو Zapier، لكن يمكن للوكيل تنفيذ بعض خطواته. ويمكن تشغيل التدفق يدويا، أو وفق جدول زمني، أو بواسطة webhook، أو من خلال تدفق آخر. كما تتوفر التفرعات والحلقات والتعامل مع الملفات وHTTP وMCP والتوقف من أجل الحصول على الموافقة.

على سبيل المثال، يجلب سيناريو صباحي الأخبار، ويرشحها، ويجهز مسودة، ثم ينتظر موافقة المحرر. والكلمة المحورية هنا هي «ينتظر»: فالمراجعة اليدوية مدمجة في العملية نفسها، ولا تعتمد على مجرد وعد من الفريق بعدم نشر النتيجة تلقائيا. ولا يزال Flows في الإصدار التجريبي، لذا من المعقول دعم العمليات الحرجة بتسجيل السجلات وإجراء الفحوص في نظام خارجي.

جرى أيضا توسيع الوضع headless من أجل CI. تستطيع CLI استقبال تدفق من الطلبات عبر stdin، وإرجاع الأحداث بصيغة JSON سطرا بسطر، والإبلاغ عن استهلاك الرموز، والانتهاء برمز خروج واضح. يعني الرمز 0 النجاح، بينما يعني أي رمز غير صفري أن المهمة لم تكتمل. ويساعد حد الخطوات على إيقاف عملية تشغيل عالقة في حلقة؛ وعند بلوغ الحد، يعاد سبب التوقف والرمز 2.

الخلاصة العملية: من الأفضل أولا تجربة CLI في فحص آمن، مثل تحليل التغييرات من دون صلاحية الكتابة. بعد ذلك، ينبغي ربط تدفق JSON بسجلات CI، وتحديد حد للخطوات، والتحقق من معالجة جميع رموز الخروج. ومن الأفضل إدخال Computer Use وFlows بعد ذلك، بدءا من العمليات القابلة للعكس، مع اشتراط التأكيد قبل أي إجراء خارجي.