Residential Proxies pour agents LangChain, CrewAI et AutoGen

Un framework d’agents permet facilement de donner un outil web à un modèle. Il ne rend pas le web plus facile d’accès pour autant. Dès qu’un agent LangChain, CrewAI ou AutoGen récupère des pages en volume, il accumule les erreurs 403, les pages CAPTCHA et les contenus du mauvais pays, et le modèle résume volontiers tout cela comme si c’était authentique. Faire passer les outils web de l’agent par des proxies conçus pour les agents IA règle la question de l’accès, mais seulement si vous les branchez au bon endroit.

Ce guide porte justement sur ce branchement. Il montre comment faire passer les outils web de chaque framework par un proxy résidentiel, comment garder l’API du modèle hors du proxy et comment choisir entre sessions persistantes et rotatives selon la tâche. Si vous n’avez pas encore choisi de type de proxy, commencez par notre comparatif des meilleurs proxies pour les agents IA qui naviguent sur le web ; cet article part du principe que votre choix est fait.

Règle numéro un : un proxy pour les outils, pas pour le processus

La façon la plus rapide d’ajouter un proxy consiste à exporter HTTPS_PROXY et à redémarrer. Ne le faites pas dans un processus d’agent. Les SDK d’OpenAI, d’Anthropic et de la plupart des autres fournisseurs de modèles lisent les mêmes variables d’environnement, si bien que chaque appel au modèle passerait lui aussi par le réseau résidentiel. Cela ajoute de la latence à chaque étape de raisonnement, consomme du trafic proxy pour des tokens et ne vous apporte rien, car les API de modèles ne vous bloquent pas en fonction de votre IP.

Définissez le proxy explicitement sur le client HTTP ou le navigateur qu’utilise chaque outil. Tout le reste passe par votre connexion habituelle. Si une bibliothèque ne lit que les variables d’environnement, ajoutez les hôtes du modèle à NO_PROXY.

L’URL du proxy

Avec la passerelle Shifter, le ciblage et les sessions se configurent dans le nom d’utilisateur. Un seul point d’accès, p.shifter.io:443, couvre tous les pays :

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:
    """Rotatif par défaut ; passez un identifiant de session pour garder une IP de sortie pendant une tâche."""
    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]

Tous les exemples ci-dessous réutilisent cette fonction.

LangChain

La plupart des agents LangChain lisent le web de deux manières : un document loader pour la récupération de contenu, ou une boîte à outils navigateur pour les agents qui cliquent et saisissent du texte.

Document loaders. WebBaseLoader accepte un dictionnaire proxies et l’utilise pour chaque page récupérée :

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()

La rotation convient bien aux loaders : chaque page est indépendante, donc une nouvelle IP par requête répartit la charge.

Boîtes à outils navigateur. La boîte à outils Playwright pilote un vrai navigateur. Lancez vous-même le navigateur avec le proxy et transmettez-le à la boîte à outils :

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()

Ici, l’identifiant de session est essentiel. Un agent de navigation navigue, lit, clique et revient. Si son IP changeait entre deux étapes, le site verrait un visiteur passer d’une ville à l’autre en pleine session, ce que les protections anti-bots surveillent précisément. Un identifiant de session par exécution de l’agent garantit une seule IP de sortie pour toute la tâche.

CrewAI

Les agents CrewAI utilisent des outils, et l’approche la plus propre consiste à créer un petit outil personnalisé qui gère son propre client HTTP :

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]

Donnez l’outil aux agents chargés de la recherche, et pas à ceux qui se contentent de rédiger ou de relire. Une crew de cinq agents a rarement besoin de cinq agents sur le proxy.

Laisser le modèle choisir country est utile pour les crews d’étude de marché : l’agent de recherche peut comparer ce qu’une page affiche aux États-Unis, en Allemagne et au Japon sans code supplémentaire. Indiquez la liste des pays autorisés dans la description de l’outil pour que le modèle n’invente pas de codes.

AutoGen

Dans AgentChat d’AutoGen, un outil est une simple fonction Python : le proxy se configure donc dans le client utilisé à l’intérieur de cette fonction. Un client asynchrone s’intègre à la boucle d’événements d’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,  # votre client de modèle, sans proxy
    tools=[fetch_page],
)

Le client du modèle est créé séparément et ne voit jamais le proxy, ce qui est tout l’objet de la règle numéro un.

Persistantes ou rotatives, selon la tâche

Ce n’est pas le framework qui décide, c’est la tâche. Une règle simple :

Tâche de l’agent	Session	Pourquoi
Récupérer de nombreuses pages indépendantes	Rotative	Répartit les requêtes, aucun état à conserver
Navigation en plusieurs étapes, formulaires, paniers	Persistante, un identifiant par exécution	Le site attend un seul visiteur
Workflows connectés sur plusieurs heures	ISP Proxies	Une ville et un FAI pour toute la période de facturation
Comparer des pays	Rotative, un pays par appel	Chaque appel correspond à un marché distinct

Pour approfondir les compromis, consultez notre guide de décision sur la rotation des IP de proxy. Pour les longues sessions connectées, les ISP Proxies conservent la même ville et le même FAI pendant toute la période de facturation, ce qui convient aux agents qui gardent un compte ouvert.

Rendre les échecs visibles pour le modèle

Les agents ont du mal à se rendre compte qu’ils ont été bloqués. Une page CAPTCHA n’est pour eux qu’un texte de plus à résumer. Deux petites habitudes évitent les mauvaises réponses :

• Lever une erreur sur les codes 403 et 429 au lieu de renvoyer le contenu. Le framework transmet l’erreur au modèle, qui peut réessayer ou la signaler, plutôt que de raisonner sur une page de blocage.
• Réessayer avec une nouvelle session, pas la même. Si une session persistante se heurte à un blocage, générez un nouvel identifiant de session pour la nouvelle tentative. Réessayer avec la même IP de sortie donne généralement la même réponse.

Limitez les tentatives. Trois essais par URL suffisent largement ; au-delà, vous payez pour du trafic que la cible a déjà décidé de refuser.

Maîtriser les coûts

Les agents peuvent tourner en boucle. Un planificateur qui relit sans cesse la même page consomme du trafic proxy aussi vite que des tokens. Tronquez le contenu des pages avant qu’il n’atteigne le modèle, comme le font les exemples ci-dessus, mettez en cache les pages récupérées pendant la durée d’une exécution et journalisez les octets par appel d’outil, afin qu’un agent incontrôlé apparaisse sur un tableau de bord avant d’apparaître sur une facture.

FAQ

En résumé

Donnez le proxy aux outils, pas au processus. Utilisez la rotation quand les pages sont indépendantes, une session persistante par exécution quand l’agent se comporte comme un visiteur, et rendez les blocages suffisamment visibles pour que le modèle ne puisse pas les confondre avec du contenu.