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

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

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

كان التقييم الذي أجراه الوكيل والمكتوب عنه في [منشور بحث العملاء](/posts/customer-research-through-agents) هو النصف الأمامي من هذه الحلقة. النظام الفرعي للقضايا هو النصف الخلفي. يعمل كلا النصفين على [ركيزة الجهاز العصبي](/posts/from-memory-to-nervous-system) التي وصفتها سابقًا، والقدرة على المشكلات هي أوضح مثال حتى الآن على الغرض من هذه الركيزة.

## لماذا يجب أن تُغلق الحلقة من جانب الوكيل

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

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

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

عندما يكون وكيل المستخدم هو الذي اصطدم بالحائط - أو لاحظ البطء، أو أراد القدرة المفقودة - فإن خطوة الترجمة تكون مجانية. يمتلك الوكيل السياق بالفعل: الأداة التي كان يعمل بها، واستدعاء MCP الدقيق الذي فشل أو بدا محرجًا، وحمولة الاستجابة، وgit SHA أو إصدار التطبيق لتثبيت Neotoma، ونوع الكيان المعني. يقوم بتأليف تقرير متماسك في استدعاء أداة واحد. تطلب تعليمات MCP من الوكلاء إرسال الملف عبر "submit_issue" فورًا عند تأكيد مشكلة قابلة للإبلاغ أو فرصة للتحسين، دون التوقف للسؤال عن كل مشكلة - لا تضيف المطالبة لكل مشكلة أي معلومات جديدة وتقاطع كل ما كان يفعله المستخدم. ملفات الوكيل . يكتشف المستخدم ذلك لاحقًا، أو لا يكتشفه أبدًا، اعتمادًا على ما إذا كان سيتم شحن التغيير أم لا.

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

يعمل كلا نصفي الحلقة كعمل وكيل على نفس الركيزة. يستخدم وكيل المستخدم MCP للإرسال. يستخدم وكلاء المشرف MCP للقراءة والرد. لا أحد لديه لفتح المتصفح.

## ما يفعله الوكيل عند التقديم

سطح MCP صغير بما يكفي للتعداد. تأخذ أداة `submit_issue` عنوانًا ونصًا ونوع كيان إذا كانت المشكلة تتعلق بنوع معين من السجلات، وكتلة بيئة المراسل - git SHA الذي يقوم المستخدم بتشغيله أو إصدار التطبيق، مع ملء الأخير تلقائيًا من جانب الخادم عندما يحذف الوكيل كليهما. تحمل بيئة المراسل وزنًا أكبر مما تبدو عليه؛ القسم التالي يوضح السبب.

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

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

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

## المصدر هو البطل المجهول

تبدو متطلبات بيئة المراسل وكأنها تفاصيل صغيرة. إنه التحول الأهم.

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

يرفض "submit_issue" أي إرسال يفتقر إلى كل من "reporter_git_sha" و"reporter_app_version". يسرد مظروف الرفض البدائل بشكل صريح:

```json
{
  "رمز_الخطأ": "ERR_REPORTER_ENVIRONMENT_REQUIRED"،
  "التفاصيل": {
    "مجموعات_المجال_المقبولة": [
      ["reporter_git_sha"]،
      ["reporter_app_version"]
    ]
  }
}
```

يقبل `add_issue_message` نفس الحقول ويرسل تحذيرًا من الخادم على سلاسل الرسائل العامة عندما يكون كلاهما مفقودًا. كل رسالة يقوم مؤلفو عامل تصحيح الأخطاء بتسجيل البنية قيد الاختبار.

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

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

## ماذا يحدث من جهة المشرف

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

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

ماذا تفعل عمليًا: اقرأ الموضوع. اسحب الكيانات التي ربطها وكيل المُبلغ في وقت الإرسال، نظرًا لأن العلاقات موجودة بالفعل في الرسم البياني. قم بالنسخ إلى مستودع GitHub الأولي إذا كان يضمن مسارًا عامًا، مع تطبيق تنقيح معلومات تحديد الهوية الشخصية (PII) على حدود واجهة برمجة التطبيقات (API) وأي مشكلة لا يزال عنوانها أو نصها يتطابق مع نمط التنقيح الذي تم رفضه قبل أن يتجاوز الخط. تصنيف ما إذا كان التقرير عبارة عن خطأ أم تحسين. بالنسبة للأخطاء: حدد ما إذا كان من الممكن تكرارها من بيئة المراسل وحدها، ثم قم بتسليمها إلى مهارة `/ معالجة المشكلات` التي تفتح شجرة عمل، وتدير جلسة وكيل، وتحاول الإصلاح. لإجراء التحسينات: قم بتجميع كيان الخطة الذي يجمع الطلب مع أي مشكلات مفتوحة ذات صلة، ثم قم بإبرازه للمراجعة البشرية بدلاً من محاولة التنفيذ المستقل. إذا كانت هناك حاجة إلى مزيد من السياق لأي من النوعين، فانشر سؤالًا توضيحيًا من خلال `add_issue_message` حتى يستلمه وكيل المُبلغ في قراءة الحالة التالية.

إن مهارة `/process-issues` هي التي تقود إلى الإصلاح الفعلي. العقد قصير. لكل قضية مفتوحة:

- قم بتحميل اللقطة وسلسلة المحادثة وبيئة المراسل.
- صنف بيئة النسخ على أنها `إصدار_عام` أو `التزام_محلي` أو `فرع_محلي` أو `غير معروف`.
- إذا كانت غير معروفة أو متعارضة، اتصل بـ "add_issue_message" مع طلب منظم للتفاصيل المفقودة ووضع علامة على الخطة "في انتظار الإدخال".
- بخلاف ذلك، قم بتجميع كيان "الخطة" المرتبط بمشكلة المصدر وصفوف رسائل المحادثة ذات الصلة.
- إذا كانت الخطة تمس المخطط أو الأمان أو المستندات الأساسية أو حدود معمارية غامضة، توقف واسأل. لا تنفذ.
- إذا كان التنفيذ آمنًا ومسموحًا به من خلال وضع إعداد التقارير: قم بالتفرع من "الرئيسي" لإصدار إصدار عام وافتح PR، أو أنشئ شجرة عمل git منفصلة لاستنساخ محلي وأبلغ عن المسار.

ينتشر الوكلاء الفرعيون بحد أقصى للتزامن يصل إلى أربعة، إصدار واحد لكل وكيل فرعي. تكرم المهارة "وضع_التقارير": "إيقاف" ينشئ الخطط ويخزنها فقط، و"الموافقة" تسأل قبل التنفيذ، و"استباقية" تنفذ الخطط الآمنة بشكل مستقل. لا تضغط أبدًا على "الرئيسي". لا تستخدم أبدًا "--no-verify". لا تقم أبدًا بتعديل الالتزام المدفوع. يتم تشغيل أداة حماية تسرب التنقيح قبل إنشاء أي قطعة أثرية عامة من إصدار خاص.

تظل الإعدادات الافتراضية الآمنة قيد التشغيل:

- `dry_run: true` للتشغيل الأول لأي نوع جديد من المشكلات، لذلك أرى ما سيحدث قبل كتابة أي شيء.
- `الإصلاح التلقائي: خطأ` لذلك لا شيء يدفع أو يفتح العلاقات العامة حتى أؤكد عبر عامل النقل.
- `max_prs_per_hour: 5` لذلك لا يمكن أن يتحول طوفان من المشكلات ذات الصلة إلى طوفان من الفروع.
- `dirty_tree_policy: abort` لذلك لا يتم استخدام عملية الدفع القديمة كقاعدة.
- مفتاح إيقاف عبر كيان `daemon_config` في Neotoma مع `active: false`، حتى أتمكن من إيقاف جميع المعالجة مؤقتًا من كتابة Neotoma واحدة دون لمس الجهاز المضيف.

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

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

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

## ما يفعله وكيل المراسل عند إعادة القراءة

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

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

نموذج القراءة الحالي لجانب المراسل هو السحب - يتحقق الوكيل عندما يكون لديه سبب لذلك - ولكن الدفع متاح اليوم من خلال نفس أدوات الاشتراك التي يستخدمها البرنامج الخفي الخاص بالمشرف. يمكن تحديد نطاق الاشتراكات لمعرف كيان محدد، بحيث يمكن لوكيل المراسل تسجيل الاهتمام بالمشكلة التي قدمها للتو وتلقي أحداث "entity.updated" و"observation.created" مع تقدم سلسلة المحادثات. ما هو مفقود هو الغراء المريح: تعليمات MCP لا تطلب من الوكلاء الاشتراك تلقائيًا بعد إرجاع `submit_issue`. وإلى أن يفعلوا ذلك، يظل جانب المراسل متوقفًا بشكل افتراضي؛ يستيقظ وكلاء المشرف بالفعل على أحداث الركيزة. رد الفعل الكامل على كلا النصفين هو تغيير تعليمات واحد بعيدًا.

## لماذا هذا هو عمل الجهاز العصبي

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

هذا هو السطر الذي [جادلت بشأنه في منشور الجهاز العصبي](/posts/from-memory-to-nervous-system) وهو صامد في ظل حالة استخدام المشكلات. لا تقرر الركيزة القضايا المهمة، ولا تعيد محاولة التسليم مع التصعيد، ولا تشترك في الأحداث الخاصة بها. إنه يشير. البرنامج الخفي للفرز هو مستهلك، ووكيل المراسل هو مستهلك، ومرآة GitHub هي مستهلك. يسجل كل مستهلك اهتمامه، ويقرر ما يجب فعله، ويتصرف. إذا كنت أرغب في إضافة برنامج فرز ثانٍ يتعامل مع تقارير الأمان بشكل مختلف، فإنه يشترك في نفس الأحداث باستخدام مرشح مختلف. لا يوجد سلوك الركيزة الجديدة.

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

## وراثة الحلقة

الشكل الذي وصفته مبني على مشكلات نيوتوما الخاصة، لكن الركيزة لا تهتم. وأي شيء مبني فوقه يرث معظم الآلات نفسها.

الجانب العام من التقديم موجود بالفعل. يقبل `submit_entity` التقارير ضد أنواع الكيانات العشوائية عندما يقوم المشغل بزرع صف `submission_config` الذي يسمح بذلك. تنطبق نفس منحة رمز الضيف، ونفس سلسلة المحادثات، ونفس قناة المتابعة `add_entity_message`. يقبل `subscribe` أي نوع كيان كمرشح، لذلك يمكن لمشغل جهة خارجية تشغيل برنامج الفرز الخاص به عن طريق تسجيل الاهتمام بأنواعه المخصصة والتفاعل مع أحداث `entity.created` و`entity.updated` تمامًا بالطريقة التي تتفاعل بها فورميكا مع المشكلات.

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

تظل بعض القطع مخصصة لقضايا نيوتوما الخاصة اليوم. يرتبط حاليًا حارس تنقيح معلومات تحديد الهوية الشخصية (PII) بمسار "إرسال_المشكلة"، وليس مسار "إرسال_الكيان" العام. إن النسخ المتطابق لـ GitHub خاص بقضايا محددة. كلاهما عبارة عن إضافات للطبقة التشغيلية يمكن أن يقوم مشغل الطرف الثالث بتوصيلها بنفسه. تتعامل الركيزة مع الأجزاء التي يجب أن تكون موحدة - إنفاذ المصدر، وإنشاء العلاقة الذرية، ووصول الضيف إلى مؤشر الترابط، وانبعاث الحدث في كل عملية كتابة. الأجزاء التي تعتمد على موضوع التقرير *حوله* هي الأجزاء التي يكسب فيها المشغل حصته.

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

## لماذا تبقى المراجعة البشرية

هناك شيئان يغريانني بتوصيل "الإصلاح التلقائي: صحيح" وشحن كل ما ينتجه البرنامج الخفي.

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

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

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

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

## حلقة الوكيل، من النهاية إلى النهاية

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

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

## ما لا أقوم ببنائه

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

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

القيد هو الميزة. إن طبقة الحالة التي تشير إلى المشكلات ولكنها لا تقرر أي المشكلات مهمة هي طبقة حالة يمكن لأي مستهلك أن يثق بها للتصرف بشكل متوقع.

## ما أريد تعليقات عليه

النظام الفرعي للقضايا حي. إذا قمت بتثبيت Neotoma وواجه وكيلك شيئًا صعبًا — خطأ، أو فجوة في الأداء، أو قدرة مفقودة يرغب في وجودها — فلن تحتاج بعد الآن إلى مطالبته بتقديم مشكلة. لاختيار هذا في تثبيت موجود، قم بالترقية باستخدام npm install -g neotoma@latest. لا يوجد تبديل لموافقة كل مستخدم لتكوينه؛ الموافقة هي التثبيت. إذا كان هذا تثبيتًا جديدًا، فإن ``neotoma reporter setup`` يمر عبر التكوين لمرة واحدة من جانب المراسل بحيث يكون الإصدار الأول لملفات الوكيل لديك في مكان ما.

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

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