666ghj
engine刚开始能工作，后面一直重试
[17:09:09] - 执行网络搜索... [17:09:09] → 执行搜索工具: basic_search_news [17:09:09] --- TOOL: 基础新闻搜索 (query: 美联储货币政策 黄金价格 影响 全球经济形势 通货膨胀 利率政策) --- [17:09:11] - 找到 7 个搜索结果 [17:09:11] 1. 美联储和美国利率对黄金的影响 - GOLDMARKET.fr... [17:09:11] 2. 美联储独立性受质疑，“助攻”黄金飙涨？ - 证券时报... [17:09:11] 3. [PDF] 全球经济金融展望报告 - 中国银行... [17:09:11] 4. [PDF] 美国经济指标对黄金价格的影响... [17:09:11] 5. 美国降息对国内和全球有何影响？ | 经济 - 半岛电视台... [17:09:11] 6. 美联储年内第三次维持利率不变，金价仍有可能站上4000美元？... [17:09:11] 7. 全球黄金供需变化如何塑造国际黄金价格走势? | EBC金融集团... [17:09:11] - 生成初始总结... [17:09:11] INFO:utils.forum_reader:找到最新的HOST发言，长度: 1773字符 [17:09:11] [FirstSummaryNode] 已读取HOST发言，长度: 1773字符 [17:09:11] [FirstSummaryNode] 正在生成首次段落总结 [17:09:42] WARNING:retry_helper:函数 invoke 第 1 次尝试失败: Connection error. [17:09:42] INFO:retry_helper:将在 60.0 秒后进行第 2 次尝试... [17:11:42] WARNING:retry_helper:函数 invoke 第 2 次尝试失败: Connection error. [17:11:42] INFO:retry_helper:将在 120.0 秒后进行第 3 次尝试... [17:14:43] WARNING:retry_helper:函数 invoke 第 3 次尝试失败: Connection error. [17:14:43] INFO:retry_helper:将在 240.0 秒后进行第 4 次尝试... [17:19:43] WARNING:retry_helper:函数 invoke 第 4 次尝试失败: Connection error. [17:19:43] INFO:retry_helper:将在 480.0 秒后进行第 5 次尝试... [17:28:43] WARNING:retry_helper:函数 invoke 第 5 次尝试失败: Connection error. [17:28:43] INFO:retry_helper:将在 600.0 秒后进行第 6 次尝试... [17:39:43] WARNING:retry_helper:函数 invoke 第 6 次尝试失败: Connection error. [17:39:43] INFO:retry_helper:将在 600.0 秒后进行第 7 次尝试... [17:50:43] ERROR:retry_helper:函数 invoke 在 7 次尝试后仍然失败 [17:50:43] ERROR:retry_helper:最终错误: Connection error. [17:50:43] [FirstSummaryNode] 错误: 生成首次总结失败: Connection error. [17:50:43] [FirstSummaryNode] 错误: 状态更新失败: Connection error.
"🎰 Main di JO777 itu kayak hidup — penuh kejutan, tapi hasilnya bisa luar biasa!"
有没有设置过LLM_REQUEST_TIMEOUT或对应Agent的ENGINE_REQUEST_TIMEOUT？
timeout_fallback = os.getenv("LLM_REQUEST_TIMEOUT") or os.getenv("QUERY_ENGINE_REQUEST_TIMEOUT") or "1800"
try:
self.timeout = float(timeout_fallback)
except ValueError:
self.timeout = 1800.0
代码里设置了默认值1800秒，这个难道不够长么
看你api质量，我用的gemini中转可能还要久一点，给大点再出问题了我们也可以排除这方面
------------------ 原始邮件 ------------------ 发件人: AkiraTiger @.> 发送时间: 2025年11月6日 09:07 收件人: 666ghj/BettaFish @.> 抄送: Subscribed @.***> 主题: Re: [666ghj/BettaFish] engine刚开始能工作，后面一直重试 (Issue #143)
AkiraTiger left a comment (666ghj/BettaFish#143)
有没有设置过LLM_REQUEST_TIMEOUT或对应Agent的ENGINE_REQUEST_TIMEOUT？
timeout_fallback = os.getenv("LLM_REQUEST_TIMEOUT") or os.getenv("QUERY_ENGINE_REQUEST_TIMEOUT") or "1800" try: self.timeout = float(timeout_fallback) except ValueError: self.timeout = 1800.0
代码里设置了默认值1800秒，这个难道不够长么
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: @.***>
看你日志，你那里每次只尝试1分钟就停了，所以应该不是因为timeout，可能是api网络的问题
那我先把时间改的再长一些，模型我用的是qwen，开代理的情况下我也测试了模型请求是成功的，那我把梯子关上再试一下
看你日志，你那里每次只尝试1分钟就停了，所以应该不是因为timeout，可能是api网络的问题
那我先把时间改的再长一些，模型我用的是qwen，开代理的情况下我也测试了模型请求是成功的，那我把梯子关上再试一下
是的。梯子供应商为了避免挂起的请求太多，也是有超时的，你代码的超时可能还没有达到，就被代理商超时了。
倾向于内容太长，但是目前调用的接口是一次性返回接口，而非流式接口，从而导致长时间无数据回复超时。
我觉得也是这个问题，大佬有优化方案么
我改成流式就好了
倾向于内容太长，但是目前调用的接口是一次性返回接口，而非流式接口，从而导致长时间无数据回复超时。
我觉得也是这个问题，大佬有优化方案么
我改成流式就好了
看来确实是超时无响应的问题，就算我们这里设置的超时很长，厂商那边也会中断连接。
感谢兄弟提供的解决方案，当时开发的时候偷懒了，直接接输出，我们最近就改成流式的，也欢迎您提交pr！再次感谢对微舆的支持！
倾向于内容太长，但是目前调用的接口是一次性返回接口，而非流式接口，从而导致长时间无数据回复超时。
我觉得也是这个问题，大佬有优化方案么
我改成流式就好了
怎么修改呢 ？
倾向于内容太长，但是目前调用的接口是一次性返回接口，而非流式接口，从而导致长时间无数据回复超时。
我觉得也是这个问题，大佬有优化方案么
我改成流式就好了
怎么修改呢 ？
最新代码已经是流式。