此页面尚未翻译成所有语言。
进来
博客

如何通过自定义代理工具绕过 CrewAI 和 LangChain 的机器人检测

  • Seo Za
  • 2 分钟

当你的 CrewAI 或 LangChain 代理群试图与真实网页交互时，自主代理的愿景往往会撞上一堵硬墙。你花了数小时完善推理循环，结果却因为一个 “403 Forbidden” 错误导致整个工作流崩塌。在 LLM 编排领域，我们经常谈论“记忆”和“规划”，但很少讨论底层设施：如何确保你的代理在试图研究目标时不会立即被列入黑名单。

标准库通常将网络视为次要问题。然而，在构建生产级代理时，代理（Proxy）管理不仅仅是一个实用程序——它是一项核心架构要求。在本指南中，我们将超越简单的 requests 调用，为 LangChain 和 CrewAI 构建一个复杂的、具备轮换意识的工具。

为什么自主代理在大规模运行时会失败？

大多数开发者在开始时都会给他们的代理一个通用的 SearchTool。这在前五次查询中运行良好。但到了第十次，代理就开始产生幻觉，因为它收到的要么是空响应，要么是它无法解析的验证码（CAPTCHA）页面。

问题在于 LLM 天生就是“话痨”。一个代理循环可能会在一分钟内访问同一个域名数十次，以验证事实或寻找子页面。对于服务器来说，这看起来像是一场 DDoS 攻击或原始的爬虫。如果你的代理没有办法循环变换其身份（IP 地址），它就会变成一种负债。我们的目标是将“网络隐身”植入代理的工具集中，使其能够专注于推理，而非绕过策略。

代理感知工具的架构

为了构建一个资深级别的工具，我们需要将轮换的复杂性从代理中抽象出来。代理不应该考虑使用哪个代理 IP；它只需要调用 research_web(query) 并接收干净的数据。

组件栈

  1. 供应商接口： 获取经过认证的代理字符串（住宅代理或数据中心代理）的中心点。
  2. 会话包装器： 处理重试并在遇到特定状态码（如 429 或 403）时轮换 IP 的对象。
  3. 工具接口： 通过 LangChain 的 @tool 或 CrewAI 的 BaseTool 装饰器将此逻辑暴露给 LLM。

框架：“隐身优先”的实现

让我们使用 Python 构建一个健壮的实现。我们将创建一个基于类的工具，管理其自身的状态和轮换逻辑。

第一步：定义代理管理器

我们不想硬编码单个代理。我们需要一个池或动态生成器。

import random
import requests
from langchain.tools import tool
from typing import Optional
class ProxyProvider:
def __init__(self, proxy_list: list[str]):
self.proxies = proxy_list
def get_proxy(self):
proxy = random.choice(self.proxies)
return {
"http": f"http://{proxy}",
"https": f"http://{proxy}"
}
# 使用经过认证的住宅代理示例
MY_PROXIES = [
"user:pass@p.proxyprovider.com:8001",
"user:pass@p.proxyprovider.com:8002",
"user:pass@p.proxyprovider.com:8003"
]
proxy_manager = ProxyProvider(MY_PROXIES)

第二步：具备弹性的请求函数

这个函数充当代理的“盾牌”。它处理 HTTP 请求头和错误的细节。

def fetch_with_rotation(url: str, max_retries: int = 3):
headers = {
"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36..."
}
for attempt in range(max_retries):
try:
proxy = proxy_manager.get_proxy()
response = requests.get(url, headers=headers, proxies=proxy, timeout=10)
if response.status_code == 200:
return response.text
elif response.status_code == 429:
# 速率限制 - 记录并尝试不同的代理
continue
except Exception as e:
print(f"Attempt {attempt} failed: {e}")
return "Error: Could not retrieve data after multiple rotations."

第三步：为 LangChain 和 CrewAI 进行包装

现在，我们将此暴露给我们的代理。在 CrewAI 中，工具通常是继承自 BaseTool 的类，而 LangChain 则通过 @tool 装饰器简化了这一过程。

@tool("web_search_proxy")
def web_search_proxy(url: str) -> str:
"""
当标准访问受限时，用于搜索网页。
此工具使用轮换的住宅 IP 确保数据检索。
输入应为完整的 URL。
"""
return fetch_with_rotation(url)

如何与 CrewAI 集成

CrewAI 代理对工具的输出特别敏感。如果工具返回“拒绝访问”消息，代理可能会陷入循环，试图通过“思考”来绕过防火墙。通过使用代理包装工具，你为代理提供了一种“魔法”能力：持续的访问权。

from crewai import Agent, Task, Crew
researcher = Agent(
role='高级网络研究员',
goal='从竞争对手网站中提取深度市场洞察',
backstory='擅长导航复杂的网络结构并绕过数据障碍的专家。',
tools=[web_search_proxy],
verbose=True
)
research_task = Task(
description='分析 {target_url} 的价格页面并总结方案层级。',
expected_output='价格层级的详细 Markdown 表格。',
agent=researcher
)

进阶洞察：身份悖论（Identity Paradox）

一个常见的错误是轮换了 IP 但保持相同的 User-Agent 或浏览器指纹。复杂的反爬虫系统（如 Cloudflare 或 Akamai）会查看多种因素的 组合。

在构建自定义工具时，请考虑建立一个“身份工厂”，将特定的代理 IP 与特定的 User-Agent 配对。在高风险环境中，这种“粘性会话”（sticky session）方法比每次请求都完全随机化更有效，因为它模仿了真实用户在网站中的浏览行为。

构建生产级工具的清单

如果你正准备将原型转化为生产级代理，请使用此清单确保你的工具具备韧性：

  • 动态超时： 不要让缓慢的代理挂起整个代理链。设置严格的 timeout（例如 10 秒）。
  • 错误分类： 区分“页面未找到”（404）和“我们阻止了你”（403）。代理只应在后者发生时重试。
  • 内容清洗： 原始 HTML 对 LLM 的上下文窗口是有毒的。始终在工具内部使用 BeautifulSoup 或 Markdownify 等库去除标签，然后再将数据返回给代理。
  • 预算控制： 住宅代理非常昂贵。在工具类中实现计数器以跟踪使用情况，防止自主代理在循环中意外消耗数百美元。

代理网络化的未来

我们正进入一个 AI 应用的“网络层”与“模型层”同等重要的时代。使用原始的、未经保护的请求，等同于派遣一名高级外交官去参加会议，却不给他护照或翻译。

通过将代理轮换封装进自定义工具，你不仅仅是在“爬取”。你是在为你的代理提供一种稳健的感知世界的方式。你正在将它们从沙盒模型转化为真正的网络公民，能够应对现代互联网的复杂性。

结语

LangChain 和 CrewAI 的真正力量不在于它们的聊天能力，而在于它们的 行动 能力。但行动需要访问权限。当你构建更复杂的代理工作流时，请记住，数据获取的可靠性就是代理智能的天花板。

构建与你的代理一样聪明的工具。不要让一个简单的 403 错误成为你 AI 失败的原因。轮换、适应，并给你的“团队”提供他们应得的基础设施。