Ein Agent-Framework macht es leicht, einem Modell ein Web-Tool zu geben. Es macht das Web aber nicht leichter erreichbar. Sobald ein LangChain-, CrewAI- oder AutoGen-Agent Seiten in nennenswertem Umfang abruft, sammelt er 403-Fehler, CAPTCHA-Seiten und Inhalte für das falsche Land, und das Modell fasst all das bereitwillig zusammen, als wäre es echt. Wenn Sie die Web-Tools des Agents über Proxys für KI-Agents leiten, lösen Sie das Zugriffsproblem, allerdings nur, wenn Sie sie an der richtigen Stelle einbinden.
Dieser Leitfaden zeigt genau diese Einbindung. Er erklärt, wie Sie die Web-Tools jedes Frameworks über einen Residential Proxy leiten, wie Sie die Modell-API vom Proxy fernhalten und wie Sie pro Aufgabe zwischen Sticky und rotierenden Sessions wählen. Wenn Sie noch einen Proxy-Typ auswählen, beginnen Sie mit unserem Vergleich der besten Proxys für KI-Agents, die im Web surfen. Dieser Beitrag setzt voraus, dass Sie sich bereits entschieden haben.
Regel eins: Proxy für die Tools, nicht für den Prozess
Am schnellsten fügen Sie einen Proxy hinzu, indem Sie HTTPS_PROXY exportieren und neu starten. Tun Sie das in einem Agent-Prozess nicht. Die SDKs von OpenAI, Anthropic und den meisten anderen Modellanbietern lesen dieselben Umgebungsvariablen, sodass auch jeder Modellaufruf über das Residential-Netzwerk laufen würde. Das verlängert jeden Denkschritt, verbraucht Proxy-Traffic für Tokens und bringt Ihnen nichts, denn Modell-APIs blockieren Sie nicht anhand der IP.
Setzen Sie den Proxy explizit im HTTP-Client oder Browser, den das jeweilige Tool verwendet. Alles andere bleibt auf Ihrer normalen Verbindung. Wenn eine Bibliothek nur Umgebungsvariablen liest, tragen Sie die Modell-Hosts in NO_PROXY ein.
Die Proxy-URL
Beim Shifter-Gateway stecken Targeting und Sessions im Benutzernamen. Ein einziger Endpunkt, p.shifter.io:443, deckt jedes Land ab:
import os, uuid
USER = os.environ["SHIFTER_USER"]
PASSWORD = os.environ["SHIFTER_PASS"]
def proxy_url(country: str = "us", session: str | None = None, ttl: int = 600) -> str:
"""Standardmäßig rotierend; mit einer Session-ID bleibt eine Exit-IP für eine Aufgabe erhalten."""
username = f"{USER}-country-{country}"
if session:
username += f"-sid-{session}-ttl-{ttl}"
return f"http://{username}:{PASSWORD}@p.shifter.io:443"
def new_session() -> str:
return uuid.uuid4().hex[:12]Alle folgenden Beispiele verwenden diese Hilfsfunktion.
LangChain
Die meisten LangChain-Agents lesen das Web auf eine von zwei Arten: über einen Document Loader für Retrieval oder über ein Browser-Toolkit für Agents, die klicken und tippen.
Document Loader. WebBaseLoader akzeptiert ein proxies-Dictionary und verwendet es für jede abgerufene Seite:
from langchain_community.document_loaders import WebBaseLoader
proxy = proxy_url(country="de")
loader = WebBaseLoader(
["https://shop.example/de/product/123"],
proxies={"http": proxy, "https": proxy},
)
docs = loader.load()Für Loader eignet sich Rotation: Jede Seite ist unabhängig, also verteilt eine neue IP pro Anfrage die Last.
Browser-Toolkits. Das Playwright-Toolkit steuert einen echten Browser. Starten Sie den Browser selbst mit dem Proxy und übergeben Sie ihn an das Toolkit:
from langchain_community.agent_toolkits import PlayWrightBrowserToolkit
from playwright.sync_api import sync_playwright
session = new_session()
playwright = sync_playwright().start()
browser = playwright.chromium.launch(proxy={
"server": "http://p.shifter.io:443",
"username": f"{USER}-country-us-sid-{session}-ttl-1800",
"password": PASSWORD,
})
tools = PlayWrightBrowserToolkit.from_browser(sync_browser=browser).get_tools()Hier kommt es auf die Session-ID an. Ein Browsing-Agent navigiert, liest, klickt und kehrt zurück. Würde sich seine IP zwischen den Schritten ändern, sähe die Website einen Besucher, der mitten in der Sitzung zwischen Städten springt, und genau darauf achten Bot-Abwehrsysteme. Eine Session-ID pro Agent-Lauf sorgt für einen einzigen Exit während der gesamten Aufgabe.
CrewAI
CrewAI-Agents nutzen Tools, und der sauberste Ansatz ist ein kleines eigenes Tool mit eigenem HTTP-Client:
import requests
from crewai.tools import BaseTool
class FetchPage(BaseTool):
name: str = "fetch_page"
description: str = "Fetch a public web page as seen from a given country."
def _run(self, url: str, country: str = "us") -> str:
proxy = proxy_url(country=country)
r = requests.get(url, proxies={"http": proxy, "https": proxy}, timeout=30)
r.raise_for_status()
return r.text[:20000]Geben Sie das Tool den Agents, die recherchieren, und lassen Sie es bei den Agents weg, die nur schreiben oder prüfen. Eine Crew mit fünf Agents braucht selten fünf Agents am Proxy.
Wenn das Modell country selbst wählen darf, ist das für Marktforschungs-Crews nützlich: Der Recherche-Agent kann ohne zusätzlichen Code vergleichen, was eine Seite in den USA, in Deutschland und in Japan anzeigt. Führen Sie die erlaubten Länder in der Tool-Beschreibung auf, damit das Modell keine Codes erfindet.
AutoGen
In AgentChat von AutoGen ist ein Tool eine einfache Python-Funktion, also gehört der Proxy in den Client innerhalb dieser Funktion. Ein asynchroner Client passt zur Event-Loop von AutoGen:
import httpx
from autogen_agentchat.agents import AssistantAgent
async def fetch_page(url: str, country: str = "us") -> str:
"""Fetch a public web page through a residential IP in the given country."""
async with httpx.AsyncClient(proxy=proxy_url(country=country), timeout=30) as client:
r = await client.get(url, follow_redirects=True)
r.raise_for_status()
return r.text[:20000]
researcher = AssistantAgent(
name="researcher",
model_client=model_client, # Ihr Modell-Client, nicht über den Proxy
tools=[fetch_page],
)Der Modell-Client wird separat erstellt und bekommt den Proxy nie zu sehen. Genau darum geht es bei Regel eins.
Sticky oder rotierend, je nach Aufgabe
Das entscheidet nicht das Framework, sondern die Aufgabe. Eine einfache Faustregel:
| Aufgabe des Agents | Session | Warum |
|---|---|---|
| Viele unabhängige Seiten abrufen | Rotierend | Verteilt Anfragen, kein Zustand zu halten |
| Mehrstufiges Browsing, Formulare, Warenkörbe | Sticky, eine ID pro Lauf | Die Website erwartet einen einzigen Besucher |
| Eingeloggte Workflows über Stunden | ISP Proxies | Eine Stadt und ein ISP für den gesamten Abrechnungszeitraum |
| Länder vergleichen | Rotierend, ein Land pro Aufruf | Jeder Aufruf ist ein eigener Markt |
Eine ausführlichere Betrachtung der Abwägungen finden Sie in unserem Entscheidungsleitfaden für rotierende Proxy-IPs. Für lange eingeloggte Sitzungen behalten ISP Proxies dieselbe Stadt und denselben ISP für den gesamten Abrechnungszeitraum bei, was zu Agents passt, die ein Konto offen halten.
Fehler für das Modell sichtbar machen
Agents merken schlecht, dass sie blockiert wurden. Eine CAPTCHA-Seite ist für sie einfach weiterer Text zum Zusammenfassen. Zwei kleine Gewohnheiten verhindern falsche Antworten:
- Bei 403 und 429 eine Exception auslösen, statt den Body zurückzugeben. Das Framework reicht den Fehler an das Modell weiter, das es erneut versuchen oder den Fehler melden kann, statt über eine Sperrseite zu schlussfolgern.
- Mit einer neuen Session wiederholen, nicht mit derselben. Läuft eine Sticky Session in eine Sperre, erzeugen Sie für den neuen Versuch eine neue Session-ID. Ein neuer Versuch über denselben Exit liefert meist dieselbe Antwort.
Begrenzen Sie die Wiederholungen. Drei Versuche pro URL reichen völlig; darüber hinaus zahlen Sie für Traffic, den die Zielseite bereits abgelehnt hat.
Kostenkontrolle
Agents können in Schleifen geraten. Ein Planer, der dieselbe Seite immer wieder liest, verbraucht Proxy-Traffic so schnell wie Tokens. Kürzen Sie Seiteninhalte, bevor sie das Modell erreichen, wie es die Beispiele oben tun, cachen Sie abgerufene Seiten für die Dauer eines Laufs und protokollieren Sie die Bytes pro Tool-Aufruf, damit ein außer Kontrolle geratener Agent auf einem Dashboard auffällt, bevor er auf einer Rechnung auftaucht.
FAQ
Unterstützt LangChain Proxys?
Ja. Document Loader wie WebBaseLoader nehmen ein proxies-Argument entgegen, und Browser-Toolkits verwenden den Browser, den Sie starten. Den Proxy setzen Sie also im Browser.
Sollten die Aufrufe der LLM-API ebenfalls über den Proxy laufen?
Nein. Modell-APIs blockieren nicht anhand der IP. Sie über den Proxy zu leiten, erhöht die Latenz und verschwendet Traffic. Setzen Sie den Proxy nur für Web-Tools und tragen Sie die Modell-Hosts in NO_PROXY ein, wenn eine Bibliothek Umgebungsvariablen liest.
Rotierende oder Sticky Sessions für KI-Agents?
Rotierend für unabhängige Seitenabrufe, Sticky mit einer Session-ID pro Lauf für mehrstufiges Browsing und ISP Proxies für eingeloggte Workflows, die Stunden dauern.
Kann ein Agent das Land selbst wählen?
Ja. Stellen Sie country als Tool-Argument bereit und führen Sie die erlaubten Codes in der Tool-Beschreibung auf. Das Gateway leitet dann jeden Aufruf über das jeweilige Land.
Das Fazit
Geben Sie den Proxy den Tools, nicht dem Prozess. Nutzen Sie Rotation, wo Seiten unabhängig sind, eine Sticky Session pro Lauf, wo sich der Agent wie ein Besucher verhält, und machen Sie Sperren so deutlich, dass das Modell sie nicht mit Inhalten verwechseln kann.