## المشكلة التي تواجه معظم شركات البناء

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

في اللحظة التي تقوم فيها بتشغيل عميلين أو ثلاثة أو خمسة عملاء ضد نفس مثيل Neotoma، [تتغير الصورة](/posts/when-agents-share-state-everything-breaks). يكتب كل وكيل الملاحظات والعلاقات والمصادر والتفسيرات. يقوم المتجر بتجميع الحالة من كل منهم. إذا بدأ أحد هؤلاء الوكلاء في كتابة بيانات سيئة، وملخصات خاطئة بشكل طفيف، وتواريخ قديمة، وعلاقات منسوبة بشكل خاطئ، فإن الطريقة الوحيدة لمعرفة السجلات التي يجب الثقة بها هي التفكير في الوكيل الذي كتبها.

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

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

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

## لماذا AAuth

تم بناء طبقة الإسناد على [AAuth](https://www.aauth.dev/)، وهو بروتوكول مفتوح يمنح كل عميل HTTP هوية التشفير الخاصة به. لا يوجد تسجيل مسبق. لا أسرار مشتركة. لا توجد رموز حاملها. يتم توقيع كل طلب باستخدام [RFC 9421](https://datatracker.ietf.org/doc/html/rfc9421) لتوقيعات رسائل HTTP، لذا فإن الرمز المميز المسروق لا قيمة له بدون مفتاح التوقيع.

لقد اخترت AAuth لأن الشخص الذي يقف وراءه، ديك هاردت، هو صديق وأحد أعمق خبراء الهوية الذين أعرفهم. قام بتحرير OAuth 2.0 ([RFC 6749](https://www.rfc-editor.org/rfc/rfc6749)) وشارك في تأليف OpenID Authentication 2.0، وكان عضوًا مؤسسًا في مجلس إدارة [OpenID Foundation](https://openid.net/foundation/members/). هذا هو نفس النسب الذي يلتقي به معظم المطورين من خلال تدفقات كود التفويض وتسجيل الدخول الموحد. عندما يبدأ شخص لديه هذا التاريخ بروتوكولًا جديدًا مخصصًا للعملاء، فهذا هو البروتوكول الذي يستحق البناء عليه.

## ما تحمله كل كتابة الآن

[v0.6.0](https://github.com/markmhendrickson/neotoma/releases/tag/v0.6.0) يشحن إسناد الوكيل لكل صف عبر كل سطح كتابة: `/store`، `/observations/create`، `/create_relationship`، `/correct`، `/entities/split`، وأدوات متجر MCP، ويكتب CLI عبر كل من MCP وHTTP. كل ملاحظة وعلاقة ومصدر وتفسير يختم:

- معرف وكيل تم التحقق منه (بصمة المفتاح العام للكتاب الموقعين، وموضوع JWT ومصدر الرموز المميزة للوكيل، واسم ClientInfo وإصداره كبديل).
- طبقة ثقة تصنف مدى قوة إثبات الهوية.
- وسيلة النقل التي وصلت الكتابة عليها.

خمسة مستويات تغطي الطيف:

- `الأجهزة`: قدم الوكيل مظروف `cnf.attestation` (Apple Secure Enclave أو WebAuthn المعبأ أو TPM2) الذي قام الخادم بالتحقق منه مقابل الجذور الموثوقة.
- `operator_attested`: تم التحقق من التوقيع، وقام المشغل بإدراج المصدر أو زوج المصدر والموضوع في القائمة المسموح بها. يضمن المشغل عملية الوكيل دون الحاجة إلى تصديق الأجهزة.
- `البرنامج`: قام الوكيل بتوقيع الطلب باستخدام مفتاح صالح، وتم التحقق منه بواسطة الخادم. هذا هو المكان الذي يصل إليه معظم الوكلاء اليوم، بما في ذلك توقيع وكيل المؤشر الخاص بي باستخدام ES256 JWK المدعوم بالملف.
- `unverified_client`: أعلن الوكيل عن نفسه باستخدام معلومات العميل التي يمكن التعرف عليها ولكنه لم يوقع.
- `مجهول`: لا هوية على الإطلاق.

النتيجة: يمكنك إلقاء نظرة على أي صف في متجرك والإجابة على "أي وكيل كتب هذا" كقراءة مقابل بيانات من الدرجة الأولى.

## المنح بدلاً من ملفات التكوين

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

الآن: كل "agent_grant" هو كيان Neotoma من الدرجة الأولى. وهو يطابق هوية Aauth (حسب الموضوع أو المُصدر أو بصمة الإبهام أو مجموعة)، ويحمل إدخالات القدرة التي تم تحديد نطاقها حسب العملية ونوع الكيان، وله دورة حياة: `نشطة`، `معلقة`، `مُبطلة`. تعمل البرمجيات الوسيطة للقبول على حل هوية AAuth التي تم التحقق منها للمنحة المطابقة لها في كل طلب، وتختم مستخدم المنحة وإمكاناتها في سياق الطلب، ويتحقق التنفيذ النهائي من كل عملية مقابل المنحة.

تتم إدارة المنح من خلال Inspector UI، أو REST API (`POST /agents/grants`، أو `PATCH`، أو تعليق، أو إبطال، أو استعادة)، أو يتم ترحيلها مرة واحدة من env-config القديم عبر ``استيراد وكلاء الورم الجديد``. يتسبب env vars القديم (`NEOTOMA_AGENT_CAPABILITIES_*`) في فشل وقت التشغيل إذا كان لا يزال مضبوطًا، مع وجود خطأ منظم يشير إلى أمر الترحيل.

يتم تعليق المنحة بشكل فوري. فشل طلب الوكيل التالي في القبول. الاستعادة فورية بنفس القدر. لا يوجد إعادة تشغيل للخادم، ولا يوجد إعادة تحميل للتكوين.

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

## الاختبار المبدئي للهوية

يمكن لكل وكيل الآن أن يسأل Neotoma، قبل أن ينتج أي بيانات، عما إذا كان معترفًا به ككاتب موثوق به.

ثلاث نقاط دخول مكافئة:

- `الحصول على /الجلسة` عبر HTTP.
- `get_session_identity` كأداة MCP.
- "جلسة مصادقة الورم الجديد" على CLI.

يعرض كل منها طبقة الثقة التي تم حلها، وحالة المنحة (سواء تم قبولها أم لا، مع السبب)، وسياسة الكتابة المجهولة، و"مؤهل_للكتابة_الموثوقة" المنطقية. تتضمن الاستجابة كتلة تشخيصية تشرح كيفية حل الطبقة. يفشل الوكيل الجديد بصوت عالٍ عند بدء الجلسة بدلاً من كتابة صفوف مجهولة حتى يلاحظ شخص ما.

تخبر تعليمات MCP التي تم شحنها كل وكيل متصل بتشغيل هذا الفحص قبل تمكين الكتابة.

## حيث أقوم بتشغيل هذا

يقوم ثلاثة من وكلاء الخدمة المتميزين في مجموعتي بالكتابة إلى Neotoma بموجب Aauth اليوم.

**Cursor MCP proxy.** يتدفق كل طلب MCP من Cursor عبر وكيل التوقيع (`mcp_identity_proxy.py`) الذي يُدخل توقيع RFC 9421 باستخدام رمز وكيل `aa-agent+jwt`. يتحقق Neotoma من التوقيع، ويحل الهوية (`sub=cursor@markmhendrickson.com`، `iss=https://markmhendrickson.com`)، ويطابق `agent_grant`، ويعترف بالكتابة في `tier=software`. يقوم الوكيل أيضًا بتشغيل الاختبار المبدئي للجلسة عند بدء التشغيل ويمكن أن يفشل في الإغلاق إذا أبلغ الخادم عن طبقة مجهولة.

** قناة التعليقات. ** يقوم مرحل Netlify الموجود على `agent.neotoma.io` بإعادة توجيه تقارير أخطاء الوكيل إلى Neotoma عبر نفق [Cloudflare Access](https://www.cloudflare.com/zero-trust/) الموقّع بـ AAuth. تقتصر المنحة على عمليات "ارتجاع الورم العصبي" فقط.

**[Darkmesh](https://github.com/markmhendrickson/darkmesh) كتابة مقدمة دافئة.** تسجل [Darkmesh fork](https://github.com/markmhendrickson/darkmesh/blob/main/docs/neotoma_integration.md) ([context](/posts/the-substrate-plancast-needed)) تكشف المقدمة الدافئة مرة أخرى إلى Neotoma مع توقيعات RFC 9421 ورمز `aa-agent+jwt`. يصل كل كشف إلى `agent_sub` و`agent_iss` وبصمة الإبهام الرئيسية للعقدة، ويتم تحديد نطاقها من خلال منحة لكل عقدة.

أثبتت اختبارات Darkmesh المشتركة الإنفاذ بشكل عدائي. حاول وكيل محاكاة ثانٍ من عقدة نظيرة كتابة "warm_intro_reveal" بدون نوع الكيان هذا في المنحة الخاصة به. رفض نيوتوما الكتابة. تمت كتابة العقدة المعتمدة دون تغيير.

التالي على خريطة الطريق: يقوم [الوكيل العام على markmhendrickson.com](https://markmhendrickson.com/agent/) بتغليف مثيل Neotoma باعتباره ذاكرته واليوم يخدم فقط الكيانات التي حددتها صراحةً على أنها عامة. أخطط لإضافة قراءات ذات بوابات AAuth حتى يتمكن الزوار المعتمدون من الاستعلام عن أنواع كيانات غير عامة محددة. يتم تطبيق نفس آلية الهوية الموقعة بالإضافة إلى المنحة على مسار القراءة.

## ترقية على مستوى الأسطول

تقوم Neotoma بإرسال تعليمات MCP الأساسية الخاصة بها من الخادم إلى كل عميل متصل في كل مصافحة. في الإصدار 0.6.0، تعمل هذه التعليمات الآن على تقنين الاختبار المبدئي للإسناد، ووضع علامات على "مصدر_الملاحظة"، وحواف مصدر الرد المستشهد به، ومجموعة عرض "غامضة (N)" لتحذيرات الدمج الإرشادي، وحلقة إرسال تعليقات منظمة.

عندما قمت بترقية الخادم الخاص بي، التقطت خطافات Cursor وClaude Code وCodex وOpenCode السلوكيات الجديدة. لا توجد إصدارات من جانب العميل. لا يوجد ترحيل لكل أداة. نتوء واحد للخادم، وتحديث خمسة وكلاء. بالنسبة لأي شخص يقوم بتشغيل أساطيل العملاء، ينطبق نفس النمط: قم بترقية مثيل Neotoma وسيلتقط كل وكيل متصل الإعدادات الافتراضية الجديدة دون نشر العميل.

## سطح التدقيق

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

بعد الإصدار 0.6.0، تتم القراءة مقابل بيانات من الدرجة الأولى:

- يقوم `GET /agents' بتعداد كل هوية وكيل شاهدها الخادم.
- `GET /agents/{key}` يُرجع عرض التفاصيل لكل وكيل.
- عمليات تدقيق `GET /agents/{key}/records` التي تسجل تأليف وكيل معين.
- يسرد `GET /agents/grants` جميع المنح وإمكانياتها وحالة دورة حياتها.

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

## كيفية تشغيله

``` باش
ورم نيوتوما مصادقة كجن --alg ES256
مثال على علامة مصادقة الورم العصبي
جلسة مصادقة الورم نيوتوما
```

قم بإنشاء منحة للهوية الجديدة عبر Inspector أو REST API، مع تحديد نطاق الإمكانيات للعمليات التي يحتاجها وكيلك. إذا كنت تقوم بالترقية من نموذج env-config القديم، فقم بتشغيل `وكلاء neotoma Grants import --owner-user-id <your_user_id>` مرة واحدة، ثم قم بإلغاء تعيين المتغيرات القديمة.

بالنسبة للتوقيع البرمجي، يقوم [`@aauth/local-keys`](https://www.aauth.dev/) أو مكتبة AAuth مكافئة بتوقيع الطلبات باستخدام توقيعات رسائل HTTP RFC 9421 بالإضافة إلى الرمز المميز `aa-agent+jwt`. يتحقق Neotoma من التوقيع على وحدات البايت الأولية التي وقعها العميل.

يكتب بدون Aauth لا يزال يعمل. إنهم يهبطون في الطبقة "المجهولة". يمكن للمنشئين الذين يريدون حالات فشل فادحة قلب `NEOTOMA_AAUTH_STRICT=1` وإضافة موضوعات محددة إلى `NEOTOMA_STRICT_AAUTH_SUBS`.

## يتم شحنها أيضًا

v0.6.0 ليس فقط Aauth. نفس الإصدار يؤدي إلى تقسيم الكيان للسجلات المدمجة بشكل زائد، وتصدير لقطة الأسطول بالإضافة إلى أدوات الانجراف، والمحادثات متعددة الوكلاء من الدرجة الأولى عبر `conversation_message` و`sender_kind`، ومحيط واجهة برمجة التطبيقات المحكم. الملحق الكامل موجود في [ملاحظات الإصدار v0.6.0](https://github.com/markmhendrickson/neotoma/releases/tag/v0.6.0).

## التثبيت والترقية

``` باش
تثبيت npm -g neotoma@[0.6.0](https://github.com/markmhendrickson/neotoma/releases/tag/v0.6.0)
ورم جديد
ورم نيوتوما مصادقة كجن
جلسة مصادقة الورم نيوتوما
```

تمنحك ترقية الخادم ختم الإسناد الجديد وتحديث تعليمات MCP عند مصافحة العميل التالية. لا يلزم التثبيت من جانب العميل للوكلاء المتصلين بالفعل عبر MCP.

التثبيت الكامل: [neotoma.io/install](https://neotoma.io/install). الريبو: [github.com/markmhendrickson/neotoma](https://github.com/markmhendrickson/neotoma). ملاحظات الإصدار: [v0.6.0](https://github.com/markmhendrickson/neotoma/releases/tag/v0.6.0).