KI-Modelle und Plattformen
AWS ergänzt eine direkte Websuch-API für benutzerdefinierte Agenten und Datenpipelines
Unite.AI zu deinen bevorzugten Quellen auf Google hinzufügen
Amazon Web Services kündigte am 11. November 2026 eine eigenständige Websuch-API an für Amazon Bedrock AgentCore. Damit können Anwendungen mit einem einzigen signierten Aufruf sortierte Websuchergebnisse abrufen, ohne ein Gateway einrichten zu müssen. AWS berechnet 7 US-Dollar pro 1.000 Suchanfragen. Die API ist für benutzerdefinierte Agenten, Datenpipelines und bestehende Anwendungen ausgelegt.
Vor dieser Einführung wurde die Websuche in AgentCore über AgentCore Gateway bereitgestellt. Dafür waren ein Gateway, ein Websuchziel und ein Client für das Model Context Protocol (MCP) erforderlich. Die neue InvokeWebSearch Operation funktioniert stattdessen über AWS-SDKs oder die AWS CLI mit standardmäßigen AWS Identity and Access Management (IAM)-Anmeldedaten und der Authentifizierung mit Signature Version 4 – ein separater API-Schlüssel oder ein Geheimnis ist nicht erforderlich. Die Ergebnisse enthalten Textauszüge und, sofern verfügbar, Seitentitel, URLs und Veröffentlichungszeitpunkte.
Direkte Suche für benutzerdefinierte Orchestrierung
Die API ist für benutzerdefinierte Agenten-Schleifen und Frameworks wie LangChain oder LlamaIndex sowie für Workloads ohne Agenten gedacht, darunter Dashboards, Faktenprüfungs-Pipelines, Systeme zur Inhaltsanreicherung und Überwachungssysteme. Entwickler können damit auch Wiederholungsversuche, Zwischenspeicherung und Fehlerbehandlung selbst verwalten, statt diese Aufgaben an ein Gateway zu delegieren.
Der Dienst durchsucht einen von Amazon betriebenen Webindex. AWS zufolge werden Suchanfragen innerhalb von AWS verarbeitet und nicht an eine Suchmaschine eines Drittanbieters weitergeleitet. Außerdem nutzt die Operation dieselbe Suchinfrastruktur wie Alexa+, Kiro, Quick und andere Amazon-Produkte.
Suchanfragen können bis zu 200 Zeichen umfassen. Aufrufer können zwischen 1 und 25 Ergebnissen anfordern und bis zu 25 erhalten, wenn maxResults weggelassen wird. Sowohl die Listen mit einzuschließenden als auch die mit auszuschließenden Domains können jeweils bis zu 100 Einträge enthalten. Eine Stammdomain gilt auch für ihre Subdomains. Veröffentlichungsfilter akzeptieren UTC-Zeitstempel im RFC-3339-Format, und sowohl publishedAfter als auch publishedBefore Grenzwerte gelten einschließlich.
Für Aufrufe mit Python ist Boto3 1.43.127 oder höher erforderlich; Unterstützung ist auch in langchain-aws 1.9.3 und dem AgentCore Python SDK 1.26.0 enthalten. In der AgentCore-Konsole können Nutzer Suchanfragen mit Einstellungen für Ergebnisanzahl, Datum und Domain testen, Metadaten zu den Ergebnissen und die Aufruflatenz prüfen und anschließend einen Integrationscodeausschnitt erstellen oder ein Gateway-Ziel anlegen.
Identitäts- und private Netzwerkkontrollen
Aufrufer benötigen bedrock-agentcore:InvokeWebSearch eine Berechtigung für das von AWS verwaltete Websuch-Tool. Dabei handelt es sich um dieselbe Aktion und Ressource, die auch die Servicerolle eines Gateways verwendet. Service Control Policies können Kontrollen auf mehrere Konten anwenden und ermöglichen es Organisationen, die direkte Suche gemeinsam mit anderen AWS-Berechtigungen zu steuern.
Bei Workloads in privaten Subnetzen kann AWS PrivateLink Aufrufe über einen Schnittstellenendpunkt in einer virtuellen privaten Cloud (VPC) leiten. So bleibt der Datenverkehr innerhalb des AWS-Netzwerks, ohne dass ein Internet-Gateway, ein NAT-Gateway oder ein Proxy erforderlich ist. Endpunktrichtlinien, Sicherheitsgruppen, die Platzierung in Subnetzen und eine aws:SourceVpce IAM-Bedingung können einschränken, welche Principals und Netzwerkpfade die Suche aufrufen dürfen.
CloudTrail protokolliert InvokeWebSearch Anfragen als Datenereignisse; diese werden jedoch nicht standardmäßig protokolliert. Für einen Trail oder einen Ereignisdatenspeicher ist ein Ereignisauswähler für den AWS::BedrockAgentCore::WebSearch Ressourcentyp erforderlich. Die resultierenden Ereignisse identifizieren das Websuch-Tool und maxResults, nicht aber den Suchtext oder die Filter. Die geltenden Nutzungsbedingungen schreiben außerdem vor, dass Kunden die mit den Ergebnissen bereitgestellten Quellenangaben und Links aufbewahren und anzeigen.
Verfügbarkeit und Abgrenzung zum Gateway
Die API wird nach demselben Nutzungstyp wie der Gateway-Connector abgerechnet, für den direkten Zugriff fallen jedoch keine Gateway-Gebühren an. Das Standardkontingent beträgt 10 Anfragen pro Sekunde und Konto in jeder Region; Kunden können eine Erhöhung beantragen. Zum Start ist der Dienst in US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (Ireland), Asia Pacific (Tokyo) und Asia Pacific (Sydney) verfügbar.
AWS empfiehlt für die meisten agentenbasierten Workloads weiterhin AgentCore Gateway. Das gilt insbesondere für Bereitstellungen, die MCP-kompatible Tools hinter einem einzigen Endpunkt bündeln, optionale MCP-Sitzungen nutzen oder eine von Administratoren gesteuerte Quellenrichtlinie für mehrere Teams anwenden. Beide Wege durchsuchen denselben Index, doch das Gateway kann Aufrufer zusätzlich mit JSON Web Tokens autorisieren, während die eigenständige API ausschließlich IAM verwendet. Gateway-Administratoren können Zieldomain-Listen durchsetzen, die den aufrufenden Agenten verborgen bleiben; bei direkten API-Anfragen werden die Filter mit der Anfrage übermittelt.
Durch die Einführung ist Amazons Webindex zugänglich, ohne dass eine Anwendung MCP oder den Gateway-Stack einsetzen muss. Die Abgrenzung liegt in der operativen Kontrolle: Bei direkten Aufrufen sind die Aufrufer für die Anfrageverarbeitung und Filterung zuständig, während in gemeinsam genutzten Agentenumgebungen die zentralisierten Kontrollen des Gateways für Tools, Authentifizierung und Quellenrichtlinien erhalten bleiben.
