Paperclip يَعِد بشركة من وكلاء الشبكات العصبية، لكنه غرق في البيروقراطية خلال الاختبار

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

كيف يعمل Paperclip

Paperclip مشروع مفتوح المصدر (open-source)، جمع بحسب الكاتب 24 ألف نجمة على GitHub خلال أول 12 يومًا، ووصل وقت نشر المقال إلى 30,6 ألف نجمة. فكرته بسيطة وطموحة في آن واحد: التوقف عن التعامل مع الذكاء الاصطناعي كمجموعة محادثات منفصلة، وتحويل التفاعل معه إلى نموذج شركة. فبدلًا من مساعد واحد، يحصل المستخدم على رئيس تنفيذي (CEO) ومدير تقني (CTO) ومطورين ومصمم و«موظفين» آخرين، يمكن توزيع المهام والميزانيات والمسؤوليات بينهم.

«إذا كان OpenClaw موظفًا، فإن Paperclip شركة».

• أدوار الرئيس التنفيذي والمدير التقني والمهندسين والمصممين لمختلف أنواع المهام
• حدود لاستهلاك الرموز (التوكنات) وإيقاف الوكلاء عند نفاد الميزانية
• آلية heartbeat توقظ الوكلاء وفق جدول زمني بدلًا من إبقائهم نشطين باستمرار
• ربط كل مهمة بهدف عام ليفهم الوكيل سياق العمل
• دعم أدوات مختلفة، من Claude Code وCodex إلى Bash ووكلاء HTTP

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

لماذا توقف كل شيء

للاختبار، أعطى الكاتب Paperclip مهمة عادية تمامًا: استكمال منتج قائم، وإضافة نقطتي وصول (endpoints)، وتكاملًا مع API خارجي، وإيصال واجهة المستخدم (UI) إلى تصميم مرسوم مسبقًا. بعد ذلك تصرّف النظام بصورة بشرية أكثر مما ينبغي.

وزّع الرئيس التنفيذي المهام ثم اختفى لمراقبة المؤشرات. انشغل مهندس DevOps بالأتمتة وولّد حزمة من ملفات إعداد CI/CD. رفض مختبر الجودة (QA) العمل بهذه الصيغة. ورأى مطور الواجهة الخلفية (Backend) حجم المواصفات فانسحب منزعجًا. واكتفى المصمم بعبارة من قبيل «اجعلوا الأزرار مثل الأماكن الأخرى». وكان قائد الفريق يستيقظ من حين لآخر ليصدر توجيهات استراتيجية ثم يعود إلى الغياب.

في اليوم الثاني لم يتحسن الوضع. عاد مطور Backend، ورأى التوضيحات الجديدة والمراسلات الطويلة، ثم دخل في مهلة انتظار (timeout) عميقة. وجلس مطور Frontend ينتظر API لم يصله أبدًا.

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

أين تكمن الفائدة الحقيقية

يضع الكاتب نفسه تحفظًا مهمًا: المشكلة ليست في أن Paperclip عديم الفائدة. على العكس، فقد أصاب نقطة دقيقة جدًا في السوق. فحين يشغّل المطور في وقت واحد Claude Code وCursor وCodex ووكلاء آخرين، تنشأ فوضى بسرعة: لا يتضح من يعمل على ماذا، ولا أين سجل النقاشات، ولا أي سياق ضاع، ولا كم من المال أُحرق بالفعل. ويقترح Paperclip طبقة إدارة فوق هذه «الحديقة المتنوعة» من الأدوات، تضم تذاكر وتدقيقًا واستعادة للحالة ورقابة على الميزانية.

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

ماذا يعني ذلك

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