Un framework de agentes hace que sea fácil darle a un modelo una herramienta web. Lo que no hace es que la web sea fácil de alcanzar. La primera vez que un agente de LangChain, CrewAI o AutoGen descarga páginas a cierto volumen, empieza a acumular errores 403, páginas de CAPTCHA y contenido del país equivocado, y el modelo lo resume todo tan tranquilo como si fuera real. Enrutar las herramientas web del agente a través de proxies diseñados para agentes de IA resuelve el problema de acceso, pero solo si los conectas en el lugar correcto.
Esta guía trata justo de esa conexión. Muestra cómo enviar las herramientas web de cada framework a través de un proxy residencial, cómo mantener la API del modelo fuera del proxy y cómo elegir sesiones fijas o rotativas según la tarea. Si todavía estás eligiendo un tipo de proxy, empieza por nuestra comparativa de los mejores proxies para agentes de IA que navegan por la web; este artículo da por hecho que ya has elegido uno.
Regla número uno: el proxy va en las herramientas, no en el proceso
La forma más rápida de añadir un proxy es exportar HTTPS_PROXY y reiniciar. No lo hagas en un proceso de agente. Los SDK de OpenAI, Anthropic y la mayoría de los demás proveedores de modelos leen las mismas variables de entorno, así que cada llamada al modelo también pasaría por la red residencial. Eso añade latencia a cada paso de razonamiento, gasta tráfico del proxy en tokens y no te aporta nada a cambio, porque las API de los modelos no te bloquean por IP.
Configura el proxy de forma explícita en el cliente HTTP o en el navegador que usa cada herramienta. Todo lo demás se queda en tu conexión normal. Si una biblioteca solo lee variables de entorno, añade los hosts del modelo a NO_PROXY.
La URL del proxy
Con el gateway de Shifter, la segmentación y las sesiones van en el nombre de usuario. Un único endpoint, p.shifter.io:443, cubre todos los países:
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:
"""Rotating by default; pass a session id to keep one exit IP for a task."""
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]Todos los ejemplos siguientes reutilizan esta función auxiliar.
LangChain
La mayoría de los agentes de LangChain leen la web de una de dos formas: con un document loader para la recuperación, o con un toolkit de navegador para agentes que hacen clic y escriben.
Document loaders. WebBaseLoader acepta un diccionario proxies y lo usa para cada página que descarga:
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 rotación encaja bien con los loaders: cada página es independiente, así que una IP nueva por solicitud reparte la carga.
Toolkits de navegador. El toolkit de Playwright controla un navegador real. Inicia tú mismo el navegador con el proxy y pásaselo al 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()Aquí el id de sesión importa. Un agente que navega se desplaza, lee, hace clic y vuelve. Si su IP cambiara entre pasos, el sitio vería a un visitante saltar de una ciudad a otra en plena sesión, que es exactamente lo que buscan las defensas contra bots. Un id de sesión por ejecución del agente mantiene una única salida durante toda la tarea.
CrewAI
Los agentes de CrewAI usan herramientas, y el enfoque más limpio es una pequeña herramienta personalizada con su propio cliente 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]Dale la herramienta a los agentes que investigan y no se la des a los que solo redactan o revisan. Un crew de cinco agentes rara vez necesita a los cinco en el proxy.
Dejar que el modelo elija country es útil en crews de estudios de mercado: el agente investigador puede comparar lo que muestra una página en Estados Unidos, Alemania y Japón sin código adicional. Incluye la lista de países permitidos en la descripción de la herramienta para que el modelo no se invente códigos.
AutoGen
En AgentChat de AutoGen, una herramienta es una función normal de Python, así que el proxy va en el cliente que hay dentro de ella. Un cliente asíncrono encaja con el bucle de eventos de 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, # your model client, not proxied
tools=[fetch_page],
)El cliente del modelo se crea por separado y nunca ve el proxy, que es precisamente lo que pide la regla número uno.
Sesión fija o rotativa, según la tarea
No lo decide el framework, sino la tarea. Una regla práctica sencilla:
| Tarea del agente | Sesión | Por qué |
|---|---|---|
| Descargar muchas páginas independientes | Rotativa | Reparte las solicitudes, no hay estado que mantener |
| Navegación en varios pasos, formularios, carritos | Fija, un id por ejecución | El sitio espera un único visitante |
| Flujos con sesión iniciada durante horas | ISP Proxies | Una ciudad y un ISP durante todo el periodo de facturación |
| Comparar países | Rotativa, un país por llamada | Cada llamada es su propio mercado |
Para profundizar en las ventajas y desventajas, consulta nuestro marco de decisión para rotar IP de proxy. Para sesiones largas con inicio de sesión, los ISP Proxies mantienen la misma ciudad y el mismo ISP durante todo el periodo de facturación, lo que encaja con agentes que mantienen una cuenta abierta.
Haz que los fallos sean visibles para el modelo
A los agentes se les da mal darse cuenta de que los han bloqueado. Una página de CAPTCHA no es más que otro texto que resumir. Dos pequeños hábitos evitan respuestas erróneas:
- Lanza una excepción ante un 403 o un 429 en lugar de devolver el cuerpo. El framework devuelve el error al modelo, que puede reintentar o informar de él, en vez de razonar sobre una página de bloqueo.
- Reintenta con una sesión nueva, no con la misma. Si una sesión fija se topa con un bloqueo, genera un id de sesión nuevo para el reintento. Reintentar con la misma salida suele dar la misma respuesta.
Limita los reintentos. Tres intentos por URL son más que suficientes; a partir de ahí estás pagando por tráfico que el objetivo ya ha decidido rechazar.
Control de costes
Los agentes pueden entrar en bucle. Un planificador que vuelve a leer una y otra vez la misma página gastará tráfico del proxy tan rápido como gasta tokens. Recorta el cuerpo de las páginas antes de que lleguen al modelo, como hacen los ejemplos anteriores, guarda en caché las páginas descargadas mientras dure la ejecución y registra los bytes por llamada a herramienta para que un agente descontrolado aparezca en un panel antes de aparecer en una factura.
Preguntas frecuentes
¿LangChain admite proxies?
Sí. Los document loaders como WebBaseLoader aceptan un argumento proxies, y los toolkits de navegador usan el navegador que tú inicies, así que el proxy se configura en el navegador.
¿Las llamadas a la API del LLM también deberían pasar por el proxy?
No. Las API de los modelos no bloquean por IP. Pasarlas por el proxy añade latencia y desperdicia tráfico. Configura el proxy solo en las herramientas web y añade los hosts del modelo a NO_PROXY si alguna biblioteca lee variables de entorno.
¿Sesiones rotativas o fijas para agentes de IA?
Rotativas para descargas de páginas independientes, fijas con un id de sesión por ejecución para la navegación en varios pasos, e ISP Proxies para flujos con sesión iniciada que duran horas.
¿Puede un agente elegir el país por sí mismo?
Sí. Expón country como argumento de la herramienta y enumera los códigos permitidos en su descripción. El gateway enruta entonces cada llamada a través de ese país.
En resumen
Dale el proxy a las herramientas, no al proceso. Usa la rotación cuando las páginas son independientes, una sesión fija por ejecución cuando el agente se comporta como un visitante, y haz que los bloqueos sean lo bastante evidentes para que el modelo no los confunda con contenido.