AWS تطلق Web Search API للوكلاء: استدعاء واحد دون بوابة أو مفاتيح

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

الآن أصدرت AWS واجهة Web Search API مستقلة. إنها عملية InvokeWebSearch في data plane لخدمة bedrock-agentcore. لا حاجة إلى إنشاء أي شيء مسبقًا: تأخذ بيانات اعتماد IAM، وتستدعي، وتحصل على النتائج.

كيف يبدو ذلك عمليًا

في Boto3 هذه دالة واحدة هي invoke_web_search. تمرّر إليها نص الاستعلام (حتى 200 حرف) وعدد النتائج من 1 إلى 25 والفلاتر. على سبيل المثال، يمكنك حصر البحث في النطاقين aws.amazon.com وkubernetes.io وطلب الصفحات المنشورة بعد 1 يناير 2026. وفي الرد تصلك قائمة مرتبة. لكل نتيجة مقتطف نصي، أما العنوان وURL وتاريخ النشر فتوجد إذا كان الفهرس يعرفها. لذلك يجب قراءتها عبر get وليس عبر المفتاح مباشرة.

تتم المصادقة عبر SigV4، أي بلا مفاتيح API. وإذا كان الكود يعمل في Lambda أو ECS أو EC2 أو EKS، فيكفي إضافة صلاحية واحدة إلى الدور: bedrock-agentcore:InvokeWebSearch على المورد المُدار web-search.v1. وهذه هي الصلاحية نفسها التي يستخدمها دور الخدمة الخاص بالبوابة، وبالتالي تغطي سياسة واحدة المسارين.

يمكن التحقق أيضًا دون كتابة كود: في CloudShell يكفي أمر واحد هو aws bedrock-agentcore invoke-web-search. وبالنسبة إلى Python يلزم Boto3 بإصدار 1.43.127 أو أحدث.

أين يفيد ذلك

تذكر AWS عدة سيناريوهات تكون فيها البوابة غير ضرورية:

• حلقة وكيل خاصة بك، أو أطر عمل مثل LangChain وLlamaIndex؛
• مهام غير وكيلية: لوحات المعلومات، والتحقق من الحقائق، وإثراء المحتوى، والمراقبة؛
• الحالات التي تريد فيها إدارة إعادة المحاولات والتخزين المؤقت ومعالجة الأخطاء بنفسك؛
• التطبيقات التي لديها بالفعل طبقة API خاصة بها.

ولـ LangChain توجد حزمة أدوات جاهزة في langchain-aws 1.9.3 وما بعده. يمكن فيها تثبيت قواعد لا يستطيع النموذج تغييرها: النطاقات المستبعدة، والحد الأدنى للتاريخ، وميزانية البحث. وهذا مفيد عندما لا تريد أن يوسّع الوكيل نطاق بحثه بنفسه. كما يوجد غلاف WebSearchClient في AgentCore Python SDK 1.26.0.

الأمان والقيود

الحجة الرئيسية لفرق الشركات هي أن الطلبات تُخدَّم عبر فهرس تديره أمازون ولا تذهب إلى محرك بحث خارجي. ويقف الفهرس نفسه وراء Alexa+ وKiro وQuick. ويُضبط الوصول عبر IAM وSCP، ويمكن تمرير الاستدعاءات عبر PrivateLink دون الخروج إلى الإنترنت. وباستخدام الشرط aws:SourceVpce يمكن السماح بالبحث من VPC الخاص بك فقط.

هناك بعض التفاصيل:

• يسجّل CloudTrail الاستدعاءات بوصفها data events، لكنها معطّلة افتراضيًا. يجب إضافة محدد يدويًا للمورد AWS::BedrockAgentCore::WebSearch. أما نص الاستعلام نفسه والفلاتر فلا يظهران في السجلات.
• الحد الافتراضي هو 10 طلبات في الثانية لكل منطقة ولكل حساب. وفي خطوط المعالجة الضخمة ستحتاج إلى طلب رفعه.
• تلزمك شروط الاستخدام بحفظ روابط المصادر وعرضها مع النتائج. وإذا كان منتجك يخفي المصادر، فهذه مشكلة.
• تُحتسب رسوم نقاط نهاية VPC من نوع الواجهة وفق تعرفة PrivateLink القياسية.
• الفهرس مملوك لأمازون، لذا ينبغي اختبار التغطية والحداثة على استعلاماتك الخاصة قبل التخلي عن Brave أو Tavily أو Bing.

ما العمل

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