كيف بنينا وكيل التصميم الخاص بنا

الخلاصات الرئيسية

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

‍

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

تم بناء Content Studio بالكامل داخليًا على Managed Deep Agents. وهو الآن أحد أكثر وكلاء GTM استخدامًا داخل شركتنا، لكنه لم يبدأ على هذا النحو. كانت الملاحظات المبكرة... سيئة للغاية.

فكيف انتقلنا من هذه الجودة المنخفضة إلى هذا؟

قضينا أربعة أشهر في تعليم Content Studio ذوقنا ومبادئ التصميم لدينا، معظم ذلك عبر مراقبته وهو يخطئ أمام الشركة بأكملها.

تستعرض هذه المقالة كيف عمل فريقنا الهندسي GTM مع فريق التصميم لدينا لبناء Content Studio من الصفر: ما معنى التصميم الجيد بالنسبة لنا، وكيف علمنا الوكيل ذوقنا، والإطار الذي يمكّنه من إنشاء أي شيء من صورة ثابتة إلى فيلم إطلاق.

لقد أطلقنا وكيل التصميم الخاص بنا كمصدر مفتوح. انسخ المستودع مفتوح المصدر، وأضف رموز علامتك التجارية وخطوطك ومهاراتك، وانشره إلى Slack فريقك باستخدام Managed Deep Agents.

ثم انضم إلينا في GTM Engineering Live في 28 أكتوبر. سنتعمق في الإطار وتجربة المستخدم، ونعرض العمل الذي لم يتسع له هذا المقال.

بناء وكيل تصميم قابل للتوسع

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

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

1. الحكم الخبير لمصممينا, تُكتب في مهارات الوكيل وفحوصاته حتى يعرف كيف يبدو الجيد.
2. بيئة مخصصة حول النموذج، تتضمن حاسوباً لتحرير الفيديو مزوذاً بأدوات لكل طبقة من طبقات عمل التصميم.
3. تجربة المستخدم المناسبة، بحيث يتمكن فريق كامل من التعاون في مشروع يمتد لساعات من خلال موضوع واحد على Slack.

منحنا Managed Deep Agents كل ما احتجناه لتشغيل Content Studio إنتاجياً داخل شركتنا: LangSmith Sandboxمُدار، وتكامل مع Slack، وأدوات مُدارة، وذاكرة وكيل محدودة النطاق وجدولة تشغيلات الوكيل. هذا يتيح لفريق صغير أن يوجه وقته نحو عمل التصميم والمهارات والأدوات وتجربة Slack، بدلاً من التجهيزات التقنية الخلفية.

النتائج الرئيسية

• قدّم Content Studio أكثر من 3,000 أصل عبر الشركة، بما في ذلك أكثر من 80 عرض شرائح. وقد استُخدم أحد عروضه حتى في أكثر فيديوهاتنا مشاهدة على YouTube بشكل عضوي.
• حصدت المنشورات المتعلقة بعملها حوالي 4.5M مشاهدة على X.
• على حساب LangChain، حصدت المنشورات التي تضمنت عناصره المرئية نحو 2 ضعفاً من الإعجابات و3.7 ضعفاً من العلامات المرجعية مقارنة بالمنشورات الأخرى.
• ثلاثة من كل أربعة طلبات تأتي الآن من خارج قسم التسويق، و75% من المستخدمين من الزوار المتكررين الذين يعودون كل أسبوع.
• تكلفتها الوسيطة للطلب الآن نحو 50 سنتاً من الإنفاق على النماذج، بانخفاض عن نحو 8 دولارات في منتصف سبتمبر. وانكمش الكود الخاص بنا بنحو 80% بعد الانتقال إلى Managed Deep Agents.

هل الذكاء الاصطناعي جيد فعلاً في التصميم؟

قبل الخوض في البناء، دعونا نتناول أولاً جدل القرن: هل يستطيع الذكاء الاصطناعي فعلاً إنتاج تصميم جيد؟

كان النموذج جيداً أصلاً في التنفيذ ويستطيع كتابة HTML وCSS ومواصفات الرسوم البيانية والجداول الزمنية للتحريك. لكنه لم يكن يملك سياقنا، فكان يلجأ إلى أنماط مألوفة، وهو ما تسميه Anthropic «التقارب التوزيعي». وقد تبدو النتيجة أنيقة ومع ذلك تشبه مئة تصميم آخر، أو تكون متحركة بشكل جميل دون أن توصل رسالتها أبداً. الألفة ليست سيئة دائماً، لكننا أردنا أن يتخذ وكيلنا خيارات تتبع غايتها.

كatie Dill، رئيسة التصميم في Stripe، تقدم مقارنة مفيدة. تحت الضغط للبناء بسرعة بعد الحرب العالمية الثانية، كان البناة ينسخون الأشكال النظيفة والأسطح المكشوفة للحداثية مرارًا وتكرارًا. الاحتفظت النسخ بالمظهر بينما فقدت الفكرة والشخصية الكامنة وراءه. تحذيرها هو أن الذكاء الاصطناعي يمكن أن يفعل الشيء نفسه مع البرمجيات. تسمي ذلك "واجهة مستخدم زومبية" (zombie UI) وتقول إننا نحتاج إلى وجهة نظر، لأن "إن لم تكن لديك، فسيمنحك إياها الذكاء الاصطناعي."

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

تعليم وكيل التصميم الذوق

الذوق هو الحكم الذي يميز العمل الصحيح عن العمل الجيد. في التصميم، يمكن لتخطيطين استخدام الخطوط والألوان والتباعد الصحيحة، ولا يحقق أحدهما فقط هدفه. يأتي الذوق مما تسميه Dill "أن تصبح بارعًا حقًا في الملاحظة."

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

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

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

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

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

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

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

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

ضبط الحكم التصميمي كان جزءًا واحدًا من العملية. احتجنا أيضًا إلى منح الوكيل الأدوات والبيئة اللازمة لتنفيذه.

بناء حزمة وسائط

يعمل المصمم عبر عدة أدوات، من Photoshop للصور الثابتة ومحرك فيديو للحركة إلى لوحة مشتركة للنماذج الأولية والتعاون. ويعتمد أيضًا على إرشادات العلامة التجارية وأصول التصميم ووثائق الشركة.

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

harness_v1

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

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

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

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

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

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

كان هذا是我们的 الدرس المر. تصبح القواعد المصممة لتعويض نقاط ضعف النموذج أقل فائدة مع تحسّن النماذج. ما يبقى هو البيئة المحيطة بالنموذج، بما في ذلك الأدوات التي يستخدمها، والسياق الذي يستمد منه، وكيفية توجيه الناس لعمله. وبدلاً من البناء المسبق للقرارات الإبداعية، ركزنا على جعل الهيكل مرناً بما يكفي للاستفادة من كل جيل جديد من النماذج.

حاسوب المصمم

لإظهار كيفية عمل الإطار التجريبي، طلبنا من Content Studio إنتاج فيلم عن كيفية عمله مع مشروع فيديو من البداية إلى النهاية. كانت النتيجة فيلماً ببطء ببغاء في غابة من البكسل، بصوت تعليق على طريقة David Attenborough (أدى الصوت عبر ElevenLabs). لنعتمد عليه لاستعراض طبقات الإطار التجريبي: الحاسوب والأدوات والسياق الكامن خلف عمله.

التصميم عملية تكرارية. تصنع شيئًا، تنظر إليه وتغيّره، وغالبًا مرات عديدة. لذا يحتاج الوكيل إلى حاسوب يمكنه مواصلة العمل عليه طوال المحادثة بأكملها. كل سلسلة نقاش في Slack تحصل على خاصتها بيئة LangSmith التجريبيةجهاز Linux معزول مزوّد بنظام ملفات وصدفة (shell)، ويبقى المشروع هناك طوال عمر السلسلة.

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

الملخص والخطة وكود المشهد والصوت وعمليات الرندر كلها موجودة في مجلد مشروع واحد، يعمل منه كل وكيل فرعي في المهمة.

وبالإضافة إلى ذلك، قمنا بتثبيت الأدوات التي قد يحتاجها المصمم في كل مرحلة من مراحل العمل:

الحركة هي الطبقة الأصعب. وتعمل على محرّكين:

1. إطارات HyperFrames للتحرير: HyperFrames، إطار عمل HeyGen مفتوح المصدر للفيديو، يحوّل الفيديو إلى صفحة ويب. فالمقاطع وتسجيلات الشاشة والتعليقات النصية والنصوص ليست سوى عناصر على تلك الصفحة، و GSAP يقوم بتحريكها على الجدول الزمني. لذلك عندما يطلب شخص ما إضافة تعليقات نصية إلى ندوة عبر الإنترنت أو اقتطاع عرض توضيحي لمنتج، يقوم الوكيل بتحرير الفيديو كما لو كان صفحة ويب. واجهة سطر الأوامر CLI الخاصة به هي في الأساس مجموعة أدوات التحرير الخاصة بالوكيل: فحص التكوين، وسحب إطار للمراجعة، ومعالجة المقطع. كما نقوم أيضًا بتثبيت مهارات HeyGen الرسميةلذا يتعلم الوكيل الصيغة من الأشخاص الذين بنوه.
2. motion-studio للرسوم المتحركة: لا يمكن لصفحة ويب أن تُضبّب الحركة السريعة أو تجعل الأشياء تتوهج أو تُدير شعارًا بشكل ثلاثي الأبعاد 3D، وذلك هو المظهر النهائي الذي أردناه للرسوم المتحركة الأصلية. لذلك بنينا محرك canvas خاصًا بنا. يكتب الوكيل (agent) شيفرة برمجية ترسم كل بكسل من كل إطار، ويقوم المحرك بدمج ما يصل إلى 16 لحظة في كل منها، بنفس الطريقة التي تُضبّب بها مصراع الكاميرا الحركة. وقد أُنتج فيلم الببغاء بهذه الطريقة.

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

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

دماغ المصمم

نظمنا معرفة الوكيل حول أربع وظائف متميزة، لكل منها غرض واضح. المهارات (Skills) توجه كيفية أداء مهام محددة، بينما توفر الويكي (wiki) السياق حول شركتنا وما يشبه العمل الجيد. كل ما يمكن قياسه تتم معالجته بواسطة بوابة (gate)، وهي فحص حتمي مكتوب في الكود. وتلتقط طبقة ذاكرة منفصلة ما يعلّمه الناس للوكيل مع مرور الوقت.

المهارات

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

بالنسبة لفيلم مثل الفيلم أعلاه، يختار الموجّه launch-film المهارة المصممة لإخراج إنتاج حركي كبير. كل واحدة من مهاراتنا الـ 48، البالغة قريبًا من 1,000 ملف في مجملها، مخصصة لوظيفة معينة وليس لموضوع معين، بحيث يبدو وصفها كقاعدة توجيه، بما في ذلك متى لا يجب استخدامها.

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

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

الويكي

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

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

معرفة كيف نعمل لا تجعل تصميم الحركة أرخص بالضرورة. فالقرار الإبداعي الخاطئ لا يزال يمكن أن يكلف ساعات من التصيير.

التصميم القائم على المواصفات

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

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

بمجرد اختيار اتجاه، تتحول لوحة القصة المعتمدة إلى المواصفة التي يُبنى عليها باقي الفيلم. ثم يمر المشروع بثلاث مراحل:

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

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

أشِر، لا توجّه بالبرومبت

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

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

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

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

الوكيل كرئيس لأركان

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

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

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

كما أضفنا مجموعة صغيرة من الأدوات ليتولى الوكيل الرئيسي تنسيق العمل:

• start_task يُسلّم جزءًا إلى وكيل فرعي في الخلفية
• check_tasks يعرض ما هو قيد التشغيل ويقرأ التقارير المكتملة
• cancel_task و resume_task يوقف العمل الذي لم يعد يتناسب مع الموجز، أو يستأنفه من حيث توقف
• report_progress يتيح للوكيل الفرعي إرسال تحديثات أثناء تنفيذ المهمة
• schedule_wakeup يمنح الوكيل الرئيسي مؤقتًا لتشغيل دورة أخرى ومواصلة العمل

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

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

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

الهيكل الذي يحسّن نفسه

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

الحلقة السريعة: عندما يشارك شخص ما قاعدة أو تفضيلًا، يحفظه الوكيل في الدور نفسه. Managed Deep Agents تخزن الذاكرة كملفات نصية عادية في طبقتين، إحداهما مشتركة عبر الفريق والأخرى خاصة بكل شخص.

التفضيلات الشخصية تمتد عبر المحادثات، لكن المعايير المشتركة لها الأولوية، وكل ما يُنشأ لقناة شركة يتبع صوت الشركة. لكل طبقة ملف AGENTS.md الملف الذي يُحمَّل مع كل استدعاء للنموذج. نحن الآن نحدّ حجم هذه الملفات بفهرس من 200 سطر بعد أن نما إصدار مبكر إلى 500K رمز.

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

ما التالي

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

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

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

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

ثم انضم إلينا في GTM Engineering Live في 28 أكتوبر. سنكشف كواليس الهيكل وتجربة المستخدم، ونستعرض العمل الذي لم يتسع له هذا المقال.