AWS تمنح الوكلاء بحثًا على الويب بلا مفاتيح API: «حارس التبعيات» أنهى مهمته في 36 ثانية

لا يعرف النموذج ما صدر هذا الصباح: لا ثغرات جديدة ولا إصدارات ولا أسعارًا جديدة. لذلك يحتاج أي وكيل يعمل مع الأحداث الراهنة إلى بحث على الويب. وفي بيئة الإنتاج تُطرح عليه فورًا ثلاثة متطلبات: نتائج مرفقة بروابط، وتحكم في المصادر الموثوقة، وضمان ألا تتسرب استعلامات البحث إلى الخارج. فالاستعلامات كثيرًا ما تكشف ما يعمل عليه الفريق. وتلبّي AWS هذه المتطلبات عبر واجهة Web Search API الجديدة في Amazon Bedrock AgentCore، وتعرضها على مثال عملي: «حارس» يومي للتبعيات لفريق أمني.

ما الذي أُطلق بالضبط

تزوّد واجهة Web Search API الوكيل بنتائج حديثة بنداء واحد. في كل نتيجة عنوان الصفحة وعنوان URL وتاريخ النشر ومقتطف ذو صلة بالاستعلام. ويمكن تقييد الاستعلام بالنطاقات (تضمينًا أو استبعادًا) وبنطاق زمني. وتخدمه فهرس ويب تديره Amazon نفسها، وليس محرك بحث خارجي.

تتم المصادقة عبر AWS Signature Version 4 بالدور الذي يعمل به الوكيل أصلًا: على Lambda أو ECS أو في AgentCore runtime. لا يوجد مفتاح بحث منفصل، أي لا شيء يجب تخزينه أو تدويره. وللفرق المسؤولة عن المنصات مسار ثانٍ هو AgentCore Gateway: يحدد المسؤول سياسة مصادر واحدة لجميع الوكلاء وعملاء MCP، ولا يستطيع الوكيل رفع هذه السياسة.

أما لمستخدمي LangChain، فإن أداة البحث على الويب في langchain-aws تستدعي الآن هذه الواجهة. وهي تعمل مع وكلاء LangChain وLangGraph وDeep Agents.

كيف يعمل الحارس

يفحص مخطط على LangGraph كل صباح ما إذا ظهر جديد بشأن الحزم والصور التي يصدرها الفريق. وتعمل ثلاثة فروع (npm وPyPI والصور الأساسية للحاويات) بالتوازي. في كل فرع يقرر نموذج Claude من Bedrock ما الذي يبحث عنه، ويعيد في النهاية نتائج منظمة وفق مخطط Pydantic: الحزمة، والعنوان، ومعرّف CVE أو النشرة، والخطورة المعلنة، وعلامة الاستغلال، والإجراء الموصى به، وعنوان URL للمصدر.

الفكرة الأساسية هي تقسيم العمل: النموذج يبتكر الاستعلامات ويكتب الاستنتاجات، أما كل ما يجب أن يُنفَّذ مهما كان سلوك النموذج فمكانه الكود. تُنشأ الأداة بمعلمات ثابتة: قائمة سوداء للنطاقات، وحد أدنى للتاريخ، وحد أقصى أربع عمليات بحث لكل فرع. وخيار model_filters=False يترك للنموذج وسيطًا واحدًا فقط هو نص الاستعلام. وتعيد الأداة النتائج مرتين: نصًا للنموذج وقطعة (artifact) للمخطط، كي يتمكن الكود من التحقق منها.

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

• أن يكون عنوان URL قد ظهر فعلًا في النتائج؛
• أن يذكر عنوان المصدر أو نصه اسم الحزمة ككلمة كاملة؛
• أن يكون معرّف CVE أو المعرّف الوارد في النتيجة موجودًا في نص المصدر؛
• أن يقع تاريخ النشر داخل نافذة المراقبة (وإذا غاب التاريخ عُدّ خارج النافذة).

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

ماذا أظهر التشغيل

على نافذة من سبعة أيام، أجرت الفروع الثلاثة 12 عملية بحث وحصلت على 80 مصدرًا. استغرق ذلك 36 ثانية مقابل 99 لو نُفّذت الفروع واحدًا تلو الآخر. استبعد الفحص نتيجتين: في إحداهما لم يذكر المصدر الحزمة، وفي الأخرى لم يكن رقم CVE موجودًا في النص. اجتازت أربع نتائج، لكن التقرير أظهر اثنتين فقط، إذ كانت الاثنتان الأخريان موجودتين أصلًا في المخزن بعد اختبارات مبكرة. وأعطى تشغيل ثانٍ بالبيانات نفسها تقريرًا فارغًا، كما ينبغي لمهمة يومية.

القيود وما يجب فعله عمليًا

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

بضع تفاصيل عملية أخرى:

• InMemoryStore يعيش داخل الجلسة فقط. وللتشغيل اليومي تحتاج إلى مخزن دائم، مثل DynamoDBStore، لأن الجلسات في AgentCore runtime مؤقتة.
• الحد الافتراضي هو 10 طلبات في الثانية لكل منطقة على مستوى الحساب كله، وتتقاسمه الفروع المتوازية.
• تُسمّى الأداة web_search. وإذا كان لدى الوكيل بحث آخر بهذا الاسم، فأعد تسمية أحدهما.
• الصلاحيات المطلوبة دنيا: إجراء واحد هو bedrock-agentcore:InvokeWebSearch على مورد تملكه AWS.

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