وكلاء أثناء نومك: وقت التشغيل تافه، خط الأنابيب هو الصعب

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

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

وقت التشغيل مشروع عطلة نهاية أسبوع

هناك أربع طرق للحفاظ على وكيل يعمل على مدار الساعة، ولا واحدة منها صعبة:

tmux — وكيل تفاعلي ينجو من الانقطاعات وتسجيل الخروج من SSH
cron + وضع الطباعة — pi -p "check the failing tests" على مؤقت، تشغيلات لمرة واحدة تخرج نظيفة
وضع RPC — عملية طويلة العمر يتحدث إليها برنامج آخر
daemon SDK — قم بتضمين الوكيل في عملية Node الخاصة بك وكرر على قائمة انتظار

أي من هذه يعمل لمدة اثنين وسبعين ساعة متواصلة دون شكوى. ولا واحدة منها ستنتج commit مفيدًا واحدًا. لأن السؤال لم يكن أبدًا «كيف أبقي العملية حية؟» إنه:

على ماذا يعمل الوكيل؟
ماذا يعني done؟
كيف يهبط العمل؟
كيف يتجنب عدة وكلاء سحق بعضهم البعض؟

سمِّ هذه الأشياء الأربعة مصدر المهام، وتعريف done، وبوابة الهبوط، والمخصص.

ما علمته لي ~300 تشغيل حول جزء السحق

أبني gitaccord، hooks لـ git تسمح لعدة وكلاء ذكاء اصطناعي بالعمل على مستودع واحد بالتوازي. إنه موجود بسبب فشل رأيته مرارًا في التجارب: أعطِ عدة وكلاء قادرين نفس المستودع ودعهم يختارون الميزات ويهبطون عملهم الخاص بـ git عادي — بدون سلطة دمج بشرية مركزية. الوكلاء يحلون تعارضات الدمج جيدًا. هذا ليس الخطر.

الخطر هو الوكيل الذي يهبط أخيرًا ويعيد كتابة ميزة وكيل آخر بهدوء لتتناسب مع خاصته، ويعدل الاختبارات، ويبلغ عن النجاح. في تجربتنا، عبر حوالي 300 تشغيل مع Claude Code (Sonnet) و pi (GLM)، حدث ذلك في 24–28% من التشغيلات على git عادي. لا خبث في أي مكان. كل وكيل فعل بالضبط ما يجب أن يفعله وكيل منفرد حسن السلوك. الفشل كان هيكليًا: لم يستطع الوكلاء رؤية خطط وتفكير بعضهم البعض، لذا أصبح «merge» بصمت «overwrite».

إصلاح gitaccord ممل عن قصد. فرع واحد لكل وكيل. ملف خطة لكل مهمة يقرأه كل وكيل. سطر Why: على كل commit يشرح التفكير. بوابة pre-push ترفض هبوط أي تغيير يكسر ميزة وكيل آخر إلا إذا أُعلن كـ Override: للمراجعة البشرية. في نفس ~300 تشغيل: انخفضت التجاوزات الصامتة إلى 0%، لم يُترك main مكسورًا أبدًا، وكل قرار بلا فائز أُشير إليه لإنسان بدلاً من حله بصمت.

لذا من القطع الأربع، أجادل أن بوابة الهبوط والمخصص قابلان للحل — في الغالب بالتقاليد والـ hooks، وليس منصات جديدة.

أي الوظائف تعمل فعليًا طوال الليل

القيد ليس قدرة الوكيل. إنه ما إذا كان done قابلاً للتحقق من قبل الآلة. لا يمكن أن يُسأل إنسان نائم «هل هذه هي الميزة التي قصدتها؟» في الساعة الثالثة صباحًا.

ما يعمل:

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

ما لا يعمل طوال الليل — وهنا تموت العديد من أحلام الوكلاء 24/7 بهدوء:

«اكتشف ما تبنيه تاليًا.» الاتجاه المفتوح ليس له done قابل للتحقق من الآلة. هناك شكل صحيح له مع ذلك: يكتب الوكيل اقتراحًا + spike + اختبار قبول فاشل على فرعه ولا يهبطه. توافق على الاتجاه في الصباح. استقلالية الهبوط كانت دائمًا المشكلة الأسهل؛ استقلالية الاتجاه هي التي يجب أن تحتفظ بها.

حلقة الليل

كيف يبدو الكل عندما يعمل:

المساء            الليل                               الصباح
─────────          ──────────────────────────────      ──────────────
الإنسان يكتب/      الوكيل يختار المهمة N               الإنسان يقرأ ملخصًا:
يهذب قائمة المهام ──▶ يكتب خطته                         ▸ ما هبط
                   ينفذ، يختبر، يلتزم                  ▸ التجاوزات المُشار إليها &
                   يدمج main، يمر بالبوابة               القرارات بلا فائز
                   يكرر للمهمة N+1 …                   ▸ الاقتراحات المنتظرة للاتجاه

القواعد التي تبقيه حيًا حتى الصباح:

مهام صغيرة. التشغيلات المستقلة الطويلة تتعفن من انحراف السياق. خطأ واحد لكل مهمة، شريحة واحدة لكل ميزة.
استقلالية محدودة. سقف لكل ليلة، ميزانية لكل تشغيل، فروع لكل وكيل. المهمة الفاشلة تُسجل والحلقة تتحرك بدلاً من thrashing.
مخرج واحد يجب أن تقرأه: قائمة الأعلام. مهمة النظام هي جعل تلك القائمة قصيرة وعالية الإشارة — الـ Override: والقرارات بلا فائز — حتى تكون مراجعتك الصباحية دقائق، وليس ساعات.

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

أين أنا، بصراحة

ليس لدي حلقة الليل تعمل بعد. لدي الجزء الأوسط الصعب قيد التقدم: الـ hooks والتقاليد التي تمنع الوكلاء من تدمير عمل بعضهم عندما لا توجد بوابة بشرية. خيارات وقت التشغيل جالسة هناك جاهزة. القطعة المفقودة هي خط الأنابيب الممل — وخطتي هي تشغيله على gitaccord نفسه أولاً: قائمة المهام لنقل كل hook من التجربة إلى التنفيذ الحقيقي تكتب نفسها، وإذا كسر وكلاء الليل شيئًا، فإن بوابة الهبوط الخاصة بي هي أرخص مكان ممكن لتعلم ذلك.

ما أود سماعه منك

إذا جربت تشغيل وكلاء دون مراقبة — أو قررت عدم ذلك — أريد أن أسمع أين انكسر:

ما مصدر وظائفك؟ ملفات قائمة المهام، قضايا GitHub، شيء آخر؟
كيف بدا تعريف done لديك، وهل وجد الوكلاء ثغرات فيه؟
هل سمحت للعمل بالهبوط إلى فرع main، أم وضعته في قائمة انتظار للمراجعة الصباحية؟
هل شحن أحد أداة تخصيص مهام / ملخص جيدة، أم الجميع يصنعها يدويًا؟

حروب وقت التشغيل انتهت. خط الأنابيب هو المكان الذي يُربح أو يُخسر فيه هذا.