كتبت قبل بضعة أشهر عن [مجموعتي الوكيلة](/posts/what-my-agentic-stack-actually-does): monorepo خاص حيث يتعامل وكلاء الذكاء الاصطناعي مع بريدي الإلكتروني والمدفوعات وعمليات النشر، مع [Neotoma](https://neotoma.io) كذاكرة منظمة تحتها. انتهى هذا المنصب على الوعد. قلت إنني كنت طبقة الإستراتيجية، وأن البنية مصممة لجعل هذا الدور قابلاً للاستبدال بالبرمجيات. هذا هو المنصب حول القيام بذلك.

[Ateles](https://github.com/markmhendrickson/ateles) هو منتجي الثاني، بعد Neotoma، وهو يُبنى فوقه مباشرة. إنه سرب وكيل شخصي. حيث كانت المجموعة القديمة عبارة عن وكيل واحد في كل جلسة معي في الحلقة لكل مهمة، Ateles عبارة عن أسطول دائم من الوكلاء المحددين حسب الدور، ويتم تنسيقهم من خلال Neotoma، ويعملون يوميًا تحت الإطلاق. إنه الفرق بين أن أقود كل وكيل وأن أقود فريقًا يعرف وظائفه بالفعل.

يشرح هذا المنشور سبب إنشائي له، وكيف يعمل، وإلى أين يتجه.

## لماذا توقفت المكدس عن التوسع

كان الزناد هو الحجم. بعد إصدار Neotoma [إصدار المطورين](/posts/neotoma-developer-release) في أواخر فبراير، انقسم انتباهي إلى ثلاثة أوضاع لا تشترك كثيرًا: بناء المنتج، وتسويقه، وإدارة العلاقات مع المستخدمين الأوائل. كنت أقوم أيضًا بتغذية نيوتوما بمزيد من السياق حول حياتي، على المستويين المهني والشخصي، وكلما تحسنت تلك الذاكرة، كلما كان بإمكان أي عميل بمفرده أن يفعل بها. وهذا لم يزيل القيد، بل حركه. ولم يعد الحد هو ما يعرفه الوكلاء. لقد كنت أنا، الشخص الوحيد الذي حول ما عرفوه إلى عمل، جلسة واحدة في كل مرة.

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

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

شيئان آخران دفعا في نفس الاتجاه. لقد قمت بنقل عمليات المنتج الخاصة بي إلى GitHub افتراضيًا، باستخدام المشكلات وطلبات السحب بدلاً من الالتزام مباشرة بالأمر الرئيسي. تم فرض ذلك جزئيًا بواسطة [خط أنابيب المشكلات الذي أنشأته](/posts/agent-to-agent-issue-resolution-with-humans-at-the-edges)، والذي بدأ في توجيه التقارير الحقيقية من المستخدمين ووكلائهم إلى Neotoma وخارجًا إلى GitHub. وأردت أن تكون عملية التطوير الخاصة بي واضحة للعامة، حتى يتمكن الأشخاص الذين يستخدمون Neotoma من رؤية العمل الذي يجري بالضبط. كلاهما يريد سلسلة من الوكلاء المتخصصين عبر التصميم وإدارة المنتجات وضمان الجودة والإصدار. وكيل واحد يفعل كل ذلك يبطل هذه النقطة.

لذا فإن Ateles هو القرار بتدوير الأسطول، وتحديد هذا الأسطول في نيوتوما نفسها.

## الورم النيوتوما كالنسيج، وليس الذاكرة فقط

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

الوكلاء هم كيانات نيوتوما. كل واحدة منها عبارة عن "تعريف_وكيل" مع مطالبة وقائمة مسموح بها للأدوات ومجموعة من منح القدرات. يعد تحديث كيفية تصرف الوكيل بمثابة استدعاء `صحيح()` لهذا الكيان، مع سجل الإصدار الكامل وإسناد المؤلف. لا التزام، لا إعادة الانتشار. يتم إنشاء ملفات SKILL.md الموجودة على القرص كمرايا لتلك الكيانات، وليس المصدر.

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

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

الهوية هي القطعة التي تجعل الإسناد حقيقيًا وليس طموحًا. كل وكيل لديه زوج مفاتيح [AAuth](/posts/know-what-of-your-agents-wrote-what) ويقوم بالتوقيع على كل استدعاء للأداة. يتحقق الحزام من التوقيع قبل التصرف ويسجل من ادعى أنه يتصرف جنبًا إلى جنب مع من تصرف بالفعل على GitHub. لم يعد وكيل كتابة التعليمات البرمجية يتصرف مثلي فقط. إنه يتصرف كما لو كان في حد ذاته، والسجل يقول ذلك.

## الوكلاء حسب الدور

يتم تنظيم السرب في طبقات. T1 هو المضيف: العملية التي تمتلك قناة وتفرز الوكلاء، حاليًا OpenClaw لأولئك الذين أتحدث إليهم وأطلقهم للوكلاء الموجودين في الخلفية. إنها بنية تحتية، وليست وكيلاً له دور. يركض الوكلاء أنفسهم في ثلاث طبقات فوقه. وكلاء T2 متواجدون دائمًا ويمتلكون شخصية: Ateles نفسه هو الشخص الذي أتحدث معه، وهو الوكيل الوحيد الذي يزورني. برامج T3 الشيطانية عبارة عن عمليات خلفية تعتمد على الأحداث بدون شخصية، كل منها مشترك في أحداث Neotoma أو خطاف ويب خارجي. وكلاء T4 عديمي الجنسية، ويتم إنشاءهم لكل مهمة، مع هوية وذاكرة ثابتة يحصلون عليها عن طريق الاستعلام عن Neotoma.

بعض الأدوار التي يتم تشغيلها اليوم:

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

**التمويل.** يقوم برنامج الدفع المتكرر بتشغيل تحويلات Wise وBitcoin التي يتم تشغيلها بواسطة أحداث التقويم وتواريخ استحقاق المهام، مع تحميل كل مستلم ومبلغ من كيانات ملف تعريف الدفع بدلاً من الرمز. تعد إضافة دفعة متكررة جديدة بمثابة كيان جديد، وليس التزامًا. يتم تحديد دور المستشار المالي ودور الضرائب والملفات لوضع الميزانية والتسوية.

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

**الاستراتيجية.** هذا هو الدور الذي وصفته بأنه دوري في المنشور الأخير، وهو الدور الذي أتعمد تسليمه إليه. إن عملية التسليم هذه هي النسخة الملموسة من الحجة التي قدمتها في [The Human Inversion](/posts/series/the-human-inversion): عندما يستوعب الوكلاء منتصف التنفيذ، ينتقل نفوذ الإنسان إلى الأطراف، ويتم تطبيق معايير أكثر دقة وإصدار أحكام أكثر كثافة. تتم معايرة الاستقلالية حسب الخطة، وليس عالميًا. يعلن كيان سياسة التنفيذ، بالنسبة لخطة معينة، ما يُسمح للوكيل بالقيام به بمفرده، وما هو شريط الجودة الذي يجب عليه تجاوزه، وأين يجب عليه التوقف والتحقق معي قبل المتابعة. تمتد سلسلة التصعيد من الوكيل بالنيابة إلى خبير المجال إلى حارس الدستور بالنسبة لي، ويتم إعادة كتابة كل قرار ككيان، لذا يرث المثال التالي الحكم.

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

## العمود الفقري للمهمة

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

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

هذا هو العمود الفقري الذي أقوم ببناء بقية التجربة حوله.

## إلى أين يتجه هذا

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

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

إن خريطة الطريق الأقرب هي على وشك الوصول. لقد تم تصميم Ateles لاستخدامي الخاص، لذا لا يزال قدر لا بأس به منه يفترض وجود مشغل واحد، وهو أنا. أنا [أقودها نحو أن تكون قابلة للتثبيت ومتعددة المشغلين](https://github.com/markmhendrickson/ateles/blob/main/docs/multi_tenant.md): يمكن لسرب شخص آخر أن يتفرع، ويشير إلى Neotoma الخاص به، ويوفر كيانات السياق الخاصة به، ثم يركض. نظرًا لأن الوكلاء لا يعرفون المشغلين حسب السياسة ولا يتم تضمين أي شيء خاص بالمشغل في الكود، فإن حالة الشوكة تكون في الغالب مسألة سياق، وليست إعادة كتابة. يدعم العمل الجديد حقًا أكثر من إنسان داخل مستأجر واحد، ولهذا السبب تم تصميم حدود المستأجر الآن بدلاً من تعديلها لاحقًا.

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