LangChain Agent调用Wikipedia超时问题排查与代理配置实战

1. 当你的LangChain Agent“罢工”：一次真实的超时排查之旅

那天下午，我正在调试一个基于LangChain构建的智能问答助手。这个助手的设计初衷很简单：当用户问到一个我不太熟悉的人物或概念时，它能自动调用Wikipedia进行查询，然后把摘要信息整理给我。听起来很酷对吧？但就在我满怀期待地输入“Tom M. Mitchell”这个名字，想测试一下这位机器学习大师生平的时候，终端里突然蹦出了一大段刺眼的红色错误日志。

核心错误信息就藏在这一堆堆栈信息里：requests.exceptions.ConnectTimeout: HTTPConnectionPool(host='en.wikipedia.org', port=80): Max retries exceeded...。翻译成大白话就是：程序试图去连接 en.wikipedia.org 这个网站，但等了半天（超时了），对方压根没搭理。这感觉就像你给朋友打电话，电话一直“嘟嘟嘟”地响，直到自动挂断也没人接。

如果你也遇到了同样的问题，先别慌。这几乎百分之百是网络连接问题，跟你写的代码逻辑关系不大。简单来说，你本地运行程序的机器，无法直接访问到维基百科的服务器。这种情况在国内的开发环境下非常常见，原因大家心知肚明。所以，解决问题的核心思路不是去修改LangChain或者Wikipedia库的业务逻辑，而是为你的网络请求“搭一座桥”，让请求能顺利抵达目的地。这座“桥”，就是我们常说的代理。

接下来的内容，我会带你完整地走一遍我当时的排查和解决流程。我们不会停留在“这里改个参数就行”的层面，而是会深入理解为什么需要这么做，以及有哪些不同的“搭桥”方案。你会发现，解决这个问题，远不止修改一行代码那么简单，它涉及到对网络请求流程、Python包管理以及LangChain框架设计的理解。

2. 深入“案发现场”：理解超时错误的根源

要解决问题，首先得成为“侦探”，把错误日志的每一个线索都看清楚。上面那个报错，虽然看起来很长，但我们可以把它拆解成几个关键部分，每一部分都告诉了我们一些重要信息。

第一层：谁在发起请求？ 错误栈是从 requests/adapters.py 文件里抛出来的。这说明，底层发起HTTP网络请求的库是Python里鼎鼎大名的 requests。LangChain在调用外部工具（比如Wikipedia）时，通常就是通过这个库来完成的。所以，我们的任何网络配置，最终都要作用到 requests 库的行为上。

第二层：请求发给谁？ host='en.wikipedia.org', port=80 这行明确指出了连接的目标：英文维基百科的官方网站，使用默认的80端口（HTTP协议）。这说明LangChain的Wikipedia工具默认使用的是这个地址。

第三层：到底出了什么事？ ConnectTimeout 和 Connection ... timed out 是问题的定性。它不是“拒绝连接”，也不是“找不到主机”，而是“连接超时”。这两种错误的区别很重要：

• 连接超时：你的机器发出了“握手”请求，但对方服务器在指定时间内没有回应。就像敲门没人应。这通常是因为网络路径不通，请求包根本没能到达服务器，或者在某个环节被丢弃了。
• 拒绝连接/主机不可达：可能意味着你拼错了地址，或者服务器确实挂了。

在我们这个场景下，连接超时几乎可以锁定是本地网络出口对目标地址的访问受到了限制。程序本身没有错，它只是无法建立一条通往 en.wikipedia.org 的物理网络链路。

那么，LangChain的Wikipedia工具内部是如何工作的呢？简单来说，当你调用它时，它会构造一个符合Wikipedia API格式的URL。例如，搜索“Tom M. Mitchell”的URL大致长这样： http://en.wikipedia.org/w/api.php?action=query&list=search&srsearch=Tom+M.+Mitchell&format=json 然后，它使用 requests.get() 或类似的方法去获取这个URL的内容。问题就出在这个 requests.get() 执行的时候，它使用的是系统默认的网络环境，而这个环境无法直接访问目标。

所以，我们的解决方案很明确：修改