وكيل الذكاء الاصطناعي المستقل: كيف تتركه يعمل ساعات دون أن تحصل على فوضى

ما هو وكيل الذكاء الاصطناعي المستقل وما الذي يميزه عن الطلب العادي

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

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

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

هل تصلح المهمة لوكيل مستقل

السؤال الأول: هل للعمل خط نهاية يمكن للآلة التحقق منه؟ «كل الاختبارات في المجلد tests/payments تنجح»، «كل الميزات في القائمة في حالة passing»، «المقياس ارتفع مقارنة بخط الأساس» — كلها تصلح. أما «اجعل الكود أفضل» أو «واصل تحسين المدفوعات» فلا تصلح، لأن هذا الهدف بلا نهاية، والحلقة ستدور حتى تستهلك الميزانية.

من المفيد التمييز بين أربعة أنواع من الحلقات:

• خطوة بخطوة — تكتب كل طلب بنفسك؛ هذا هو العمل التفاعلي المعتاد.
• حسب الهدف — تحدد الغاية، ويوقف الحلقة تحقق مستقل أو ميزانية. وهذا هو الوكيل المستقل الذي يعمل ساعات.
• حسب الوقت — تشغيل وفق جدول زمني (مثلًا مراجعة صباحية لإخفاقات بناء CI)، وإيقافه يدويًا.
• حسب الحدث — محفّز خارجي (issue جديدة، نشر فاشل)، ويوقفه انتهاء معالجة الحدث أو حد إعادة المحاولة.

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

الخطوة 1. البيئة المعزولة: أين يُسمح للوكيل بالخطأ

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

• نسخة عمل منفصلة. يمنح git worktree الوكيل مجلدًا خاصًا وفرعًا خاصًا فوق المستودع نفسه. الفرع الرئيسي لا يُمس، ولا يتعارض وكلاء متعددون، وتُحذف التشغيلة الفاشلة بأمر واحد.
• حاوية أو آلة افتراضية. إذا احتاج الوكيل إلى صلاحية كاملة للأوامر، فشغّله داخل حاوية لا تصل إلى المجلد الشخصي ولا إلى المفاتيح ولا إلى قواعد البيانات الإنتاجية.
• بيانات اختبار. قاعدة بيانات محلية، وبيئات تجريبية لأنظمة الدفع، ومفاتيح وهمية. لا يوجد أي سر إنتاجي في بيئة الوكيل.

# فرع ومجلد خاصان بالتشغيلة المستقلة
git worktree add ../shop-agent -b agent/f03-refunds

# بعد التشغيلة: الاطلاع على النتيجة أو التخلص منها
git -C ../shop-agent log --oneline main..
git worktree remove ../shop-agent

الخطوة 2. الصلاحيات: الحد الأدنى الذي تحتاجه المهمة

كلما عمل الوكيل وحده فترة أطول، يجب أن تكون صلاحياته أضيق. في Claude Code تُضبط الأذونات في settings.json (قائمتا allow وdeny للأدوات والأوامر). اسمح صراحةً بما تحتاجه المهمة، مثل تشغيل الاختبارات والمدقق وتعديل الملفات في نسخة العمل، وامنع الخطير: الدفع إلى الفرع الرئيسي، والتعامل مع الأسرار، والأوامر الشبكية إذا لم تكن لازمة.

وضع يُنفّذ فيه الوكيل كل شيء دون تأكيد مقبول فقط داخل بيئة معزولة يكون أسوأ نتيجة فيها حاوية يمكن التخلص منها. أما على جهاز عمل يحتوي على مفاتيحك ومستودعاتك فلا يجوز ذلك.

القيود التي لا يجوز خرقها ينبغي أن تُفرض بالآلية لا بالنص. سطر «لا تلمس migrations/» في التعليمات مجرد رجاء؛ أما hook يمنع تعديل هذا المجلد أو صلاحيات نظام الملفات فهي ضمان.

الخطوة 3. الهدف والتحقق والتوقف: ثلاثة أسطر قبل التشغيل

تقوم الحلقة البسيطة الناجحة على ثلاثة أشياء، ويُستحسن كتابتها قبل التشغيل لا أثناءه:

1. الهدف — كيف تبدو الحالة النهائية.
2. التحقق — طريقة قابلة للفحص الآلي لمعرفة أن الهدف تحقق: أمر يعيد النجاح أو الخطأ.
3. شرط التوقف — حد للمحاولات أو الوقت أو المال، تتوقف عنده الحلقة حتى لو لم يتحقق الهدف.

من الأفضل حفظ ذلك في ملف منهجية منفصل لا يعدّله إلا الإنسان. مثال لواجهة خلفية لنظام دفع:

# program.md — منهجية التشغيل المستقل

## الهدف
كل الميزات في .agent/feature_list.json في حالة passing.

## المقياس
عدد الميزات في passing. يتزايد بشكل أحادي. التراجع = تراجع فوري.

## القيود
- ميزة واحدة قيد العمل في الوقت نفسه.
- لا تعديل لـ migrations/ و infra/.
- لا تغيير للاعتماديات دون تسجيل في السجل.

## ترتيب العمل
1. خذ أول ميزة ليست في passing.
2. نفّذها، وشغّل pytest والمدقق.
3. الأخضر — commit وتسجيل في .agent/progress.md. الأحمر — أصلح.

## التوقف والتصعيد
- 3 محاولات فاشلة لميزة واحدة — ضعها blocked وانتقل إلى التالية.
- إذا صارت كل المتبقيات blocked — توقف واكتب تقريرًا.
- أي مهمة تخص أموال العملاء أو صلاحيات الوصول أو حذف البيانات — لا تنفّذها، بل صعّدها.

الخطوة 4. حلقة التحقق والإصلاح مع ذاكرة على القرص

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

نموذج جيد هو «المزلاج الذي يتحرك إلى الأمام فقط»، كما في مشروع autoresearch لأندريه كارباثي، حيث يجري الوكيل خلال الليل مئات التجارب على تعلم الآلة. كل تكرار: قراءة المنهجية، ثم طرح فرضية، ثم تعديل، ثم تشغيل التجربة بميزانية زمنية ثابتة، ثم مقارنة بخط الأساس. إذا تحسنت النتيجة — commit، وإن لم تتحسن — تراجع. تُسجَّل النتيجة في السجل، ثم تأتي الفرضية التالية.

من هذا النموذج خذ قرارين:

• ميزانية ثابتة لكل محاولة. تصبح المحاولات قابلة للمقارنة، ولا تستهلك فرضية واحدة فاشلة الليل كله.
• الفرع الرئيسي يقبل التحسينات فقط. كل ما لم ينجح يُتراجع عنه، ولا يُترك بجانبه. يصبح git log سجلًا موثوقًا للعمل يسهل قراءته صباحًا.

يظهر في هذا النموذج أيضًا تقسيم الأدوار بين الملفات: البنية التحتية والتقييم لا يعدّلهما أحد، وكود التجربة يعدّله الوكيل وحده، والمنهجية يعدّلها الإنسان وحده. هكذا لا يستطيع الوكيل أن «يحسّن» النتيجة بتعديل طريقة قياسها.

الخطوة 5. من يقرر أن العمل اكتمل: مقيّم مستقل

عندما لا يوجد إنسان في الحلقة، يصبح تقييم الوكيل لنفسه هو الكابح الوحيد، وهذا الكابح لا يعمل. الوكيل الذي كتب الكود للتو يميل إلى اعتباره صحيحًا: يرى استدلاله و«يعرف» ما كان يقصده.

قواعد الفصل بين المنفِّذ والمقيِّم:

• لا يقيّم الجلسة نفسها التي أنجزت العمل. في Claude Code تفيد الوكلاء الفرعيون لأن لكل منهم سياقه الخاص.
• يحصل المقيّم على سياق نظيف: المتطلب، والفرق (diff)، ونتائج التشغيل، ولا شيء من استدلال المنفِّذ.
• إن أمكن، يكون المقيّم نموذجًا آخر، أو على الأقل موجّهًا آخر بدور مختلف.
• يصدر الحكم وفق معايير محددة، وكل بند يشير إلى دليل: سطر من الاختبار، أو ناتج أمر، أو موضع في الفرق.

تظل الفحوص الآلية هي الأولوية. المقيّم ضروري لما لا تلتقطه الاختبارات: فهم المتطلب بشكل خاطئ، أو اختبار مُفصَّل على مقاس الكود، أو تعديل تجاوز حدود المهمة.

شروط التوقف: متى يجب أن يستسلم الوكيل

حلقة بلا شروط توقف تدور في حلقة مفرغة، والسؤال مسألة وقت فقط. الحد الأدنى من الشروط:

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

مخاطر الوكيل المستقل التي لا تظهر فورًا

المخاطر الواضحة — الملفات المحذوفة والبناء المكسور — تُحتوى بالبيئة المعزولة والصلاحيات. أما الأخطر فهي التكاليف الخفية التي تتراكم أسابيع:

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

كيف تشغّل أول حلقة مستقلة في مساء واحد

لا تبدأ بـ«الوكيل سيجد المهام وينفذها بنفسه». الاستقلالية تنمو على درجات: أولًا مهمة واحدة بهدف وشرط توقف، ثم أتمتة واحدة وفق جدول، ثم منفِّذ ومدقق منفصلان في نسخة عمل معزولة، وبعد ذلك فقط حلقات تجد العمل بنفسها وتعمل بالتوازي.

1. اختر مهمة تنجزها يدويًا مرتين على الأقل في الأسبوع ولها نهاية قابلة للتحقق.
2. اكتب الهدف والتحقق وشرط التوقف — ثلاثة أسطر.
3. أنشئ worktree منفصلة واضبط الصلاحيات: الاختبارات وتعديل الملفات مسموحان، والدفع والأسرار غير مسموحين.
4. أنشئ ملف تقدم واطلب من الوكيل تحديثه بعد كل تكرار.
5. افصل الأدوار: المنفِّذ يكتب، والمدقق في سياق منفصل يقيّم الفرق.
6. ضع حدًا كليًا، ولأول مرة تحقق من النتيجة بعد ساعة، لا في الصباح.

الخلاصة

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