Agentic Resource Discovery: اكتشاف موارد الوكلاء من ai-catalog.json إلى تفويض الهاتف

ما المشكلة التي يحلها Agentic Resource Discovery؟

Agentic Resource Discovery، أو ARD، هو محاولة لتنظيم سؤال أصبح ملحا مع توسع الوكلاء: كيف يعرف الوكيل أن أداة أو مهارة أو وكيلا آخر موجود، ومن نشره، وبأي واجهة يمكن الاتصال به؟ في إعلان مواصفة Agentic Resource Discovery من Google Developers بتاريخ 17 يونيو 2026، وُصف ARD كمواصفة مفتوحة لنشر واكتشاف والتحقق من أدوات ومهارات ووكلاء الذكاء الاصطناعي عبر الويب.

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

هنا يظهر دور ai-catalog.json. يمكن التفكير فيه كملف يعلن ما يقدمه الناشر: أدوات، مهارات، وكلاء، كتالوجات فرعية، وواجهات اتصال أصلية مثل MCP أو A2A أو OpenAPI. هذا الوصف يجيب عن سؤال الاكتشاف: ما المتاح وأين؟ لكنه لا يجيب وحده عن سؤال أخطر: هل يحق لهذا الوكيل، على هذا الهاتف، وفي هذه اللحظة، تنفيذ هذا الفعل نيابة عن المستخدم؟

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

كيف تنشر الكتالوجات والسجلات قدرات الوكلاء وتجدها؟

عندما يريد مزود خدمة أن يجعل قدراته قابلة للاكتشاف، ينشر كتالوجا على نطاق يملكه. قد يحتوي الكتالوج على وصف مختصر، أنواع القدرات، الواجهات المدعومة، بيانات الثقة، وروابط إلى كتالوجات أخرى. وفق مستودع مواصفة ARD العام، تتطور المواصفة والسكيما وبنية الثقة في العلن، وهي متاحة بترخيص Apache-2.0، ما يجعلها مواصفة قابلة للمراجعة لا مجرد وصف مغلق.

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

الفارق العملي بين الكتالوج والسجل يستحق الوضوح:

بهذا تصبح عبارة دليل أدوات ai-catalog.json أوسع من ملف واحد. هي نمط نشر: وصف منظم، مصدر معروف، فهرسة قابلة للبحث، ثم اتصال لاحق عبر الواجهة التي يعلنها المورد. جودة الاكتشاف تقاس بدقة المطابقة وحداثة الكتالوج ووضوح الواجهة، لا بعدد النتائج فقط.

ما الذي يثبته التحقق من الناشر وما الذي لا يثبته؟

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

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

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

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

كيف يسلّم ARD الاتصال إلى MCP وA2A وOpenAPI وعقود التطبيقات؟

ARD لا يستبدل MCP أو A2A أو OpenAPI. دوره أن يساعد الوكيل على العثور على مورد موصوف ومعروف المصدر، ثم يسلّم الاتصال إلى الواجهة الأصلية التي يعلنها ذلك المورد. إذا أشار الكتالوج إلى MCP server، فالعميل يحتاج أن يتحدث MCP. وإذا أشار إلى A2A agent، فالتواصل يتم وفق نموذج A2A. وإذا أعلن OpenAPI tool، فالعقد التشغيلي يأتي من مواصفة OpenAPI نفسها.

هذه النقطة مهمة لأن بعض القراء يتخيلون أن مواصفة اكتشاف واحدة ستجعل كل الأدوات تعمل بالطريقة نفسها. الواقع أكثر طبقية. الاكتشاف يجيب: أين المورد وما وصفه؟ البروتوكول يجيب: كيف أتصل به؟ سياسة runtime تجيب: هل يسمح هذا المنتج باستدعائه؟ وفي الهاتف يضاف سؤال آخر: هل يستطيع Android أو التطبيق الهدف تنفيذ الخطوة بشكل مدعوم ومرئي؟

على مستوى التطبيقات المحمولة، لا يكفي أن يظهر تطبيق أو خدمة في كتالوج. يجب أن توجد طريقة قابلة للاستدعاء: intent، واجهة API، عقد app action، أو مسار أداة يملكه runtime. لذلك من يريد التوسع في فكرة العقود التي تجعل التطبيقات قابلة للاستدعاء آليا سيجد تفصيلا أعمق في App Intents والتطبيقات القابلة للاستدعاء آليًا لوكلاء الذكاء الاصطناعي، حيث يكون التركيز على ما يحدث بعد الاكتشاف داخل التطبيق نفسه.

عند التصميم العملي، نفضّل تسمية كل مرحلة باسمها. ARD يحل الوصف والاكتشاف. MCP أو A2A أو OpenAPI يدير الاتصال. عقد التطبيق أو أداة الهاتف يدير الاستدعاء المحلي. المستخدم وسياسة الهاتف يديران التفويض. هذا الترتيب يقلل الوعود الواسعة ويجعل الفشل قابلا للفهم: هل فشلنا في العثور على المورد، أم في التحقق، أم في البروتوكول، أم في إذن الجهاز؟

لماذا لا يعني الاكتشاف تفويضا على الهاتف؟

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

الجدول التالي يوضح الفصل بين طبقات الثقة والصلاحية:

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

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

قائمة فحص قبل الاتصال والتنفيذ لموارد الوكلاء المكتشفة

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

1. تحقق من الناشر: هل النطاق والبيانات القابلة للتحقق يطابقان الجهة المتوقعة؟
2. راجع حداثة الكتالوج: هل الإصدار والوصف والواجهات المعلنة ما زالت صالحة؟
3. اختبر البروتوكول: هل يدعم العميل MCP أو A2A أو OpenAPI أو العقد المطلوب فعليا؟
4. افحص نطاقات الأداة: ما البيانات التي ستقرأها؟ وما الأثر الخارجي المحتمل؟
5. ابدأ بمهمة منخفضة المخاطر: استخدم قراءة أو فحصا غير مؤثر قبل تجربة إجراء يغير شيئا.
6. حدد الهدف قبل التنفيذ: من المستلم؟ أي تطبيق؟ أي حساب؟ أي ملف؟
7. طبّق الموافقة بحسب المخاطر: ليست كل قراءة مثل الإرسال، وليست كل أداة تتطلب السياسة نفسها.
8. اعرض النتيجة: يجب أن يرى المستخدم ما حدث أو ما سيحدث، لا أن يثق في وصف مبهم.
9. وفّر الإيقاف والسحب: يجب أن يستطيع المستخدم تعطيل المورد أو إيقاف المهمة أو مراجعة السجل.

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

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

كيف يفصل FoneClaw بين ظهور الأداة وصلاحية الهاتف؟

في FoneClaw، نعامل الكتالوج كوسيلة لرؤية القدرات وتنظيمها، لا كإذن تلقائي للتنفيذ. FoneClaw هو runtime لوكيل هاتف Android: النموذج المتوافق والمكوّن داخل FoneClaw يساعد في الفهم والتخطيط، بينما يستدعي FoneClaw أدوات Android المدعومة ضمن سياسة واضحة ونتائج مرئية. هذا الفصل يجعل سؤال الاكتشاف مختلفا عن سؤال السلطة.

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

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

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

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

ما الذي يجب اختباره قبل اعتماد سجل موارد للوكلاء؟

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

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

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