WebFetch 耗时太长

[Ryutaku]

What would you like to be added?

希望提升WebFetch的性能

Why is this needed?

WebFetch 耗时实在太长了。问了一个问题，WebFetch抓取两个网页耗时有三分钟时间。同样的问题同样的网络环境检索相同的网页来源远不及codex网页检索速度快。

Additional context

No response

[doudouOUC]

我排查了代码路径，当前 WebFetch 耗时长主要是几层开销叠加，不是单点问题：

1. WebFetch 不是“只抓网页”，每次抓取后还会再发起一次模型总结请求

   • 代码：packages/core/src/tools/web-fetch.ts（executeDirectFetch）
   • 流程：HTTP 拉取 -> HTML 转文本 -> generateContent(...) 总结
   • 这意味着抓 2 个网页 = 2 次额外 LLM 调用，不只是 2 次 HTTP 请求

2. 总结请求使用的是当前会话主模型，而不是独立轻量模型

   • 代码：packages/core/src/tools/web-fetch.ts（this.config.getModel() || DEFAULT_QWEN_MODEL）
   • 工具描述写的是 small/fast model，但实现里没有切独立快模型
   • 主模型本身慢时，WebFetch 会被明显放大

3. 总结请求带有默认重试与退避，429/5xx 时会拉长到分钟级

   • 代码：packages/core/src/core/client.ts（generateContent 调 retryWithBackoff）
   • 代码：packages/core/src/utils/retry.ts（默认最多 7 次、指数退避、可受 Retry-After 影响）
   • 因此单次 web_fetch 在限流场景下可能很慢

4. 同一轮里多个 web_fetch 当前是串行执行（不是并行）

   • 代码：packages/core/src/core/coreToolScheduler.ts
   • 只有 AGENT 工具并行，其他工具（包括 web_fetch）按顺序 await
   • 所以抓两个网页时，耗时基本是相加关系

结论：你描述的“两个网页三分钟”与当前实现机制一致，主要由
“每页一次 LLM 总结 + 重试退避 + 多次 web_fetch 串行”共同造成。

可优化方向（后续可提 PR）：

• 给 web_fetch 使用独立轻量模型（或支持单独配置 web_fetch_model）
• 下调 web_fetch 内部总结请求的重试上限/退避策略
• 对互不依赖的多个 web_fetch 支持并行执行

[doudouOUC]

我排查了代码路径，当前 WebFetch 耗时长主要是几层开销叠加，不是单点问题：

1. WebFetch 不是“只抓网页”，每次抓取后还会再发起一次模型总结请求

   • 代码：packages/core/src/tools/web-fetch.ts（executeDirectFetch）
   • 流程：HTTP 拉取 -> HTML 转文本 -> generateContent(...) 总结
   • 这意味着抓 2 个网页 = 2 次额外 LLM 调用，不只是 2 次 HTTP 请求

2. 总结请求使用的是当前会话主模型，而不是独立轻量模型

   • 代码：packages/core/src/tools/web-fetch.ts（this.config.getModel() || DEFAULT_QWEN_MODEL）
   • 工具描述写的是 small/fast model，但实现里没有切独立快模型
   • 主模型本身慢时，WebFetch 会被明显放大

3. 总结请求带有默认重试与退避，429/5xx 时会拉长到分钟级

   • 代码：packages/core/src/core/client.ts（generateContent 调 retryWithBackoff）
   • 代码：packages/core/src/utils/retry.ts（默认最多 7 次、指数退避、可受 Retry-After 影响）
   • 因此单次 web_fetch 在限流场景下可能很慢

4. 同一轮里多个 web_fetch 当前是串行执行（不是并行）

   • 代码：packages/core/src/core/coreToolScheduler.ts
   • 只有 AGENT 工具并行，其他工具（包括 web_fetch）按顺序 await
   • 所以抓两个网页时，耗时基本是相加关系

结论：你描述的“两个网页三分钟”与当前实现机制一致，主要由
“每页一次 LLM 总结 + 重试退避 + 多次 web_fetch 串行”共同造成。

可优化方向（后续可提 PR）：

• 给 web_fetch 使用独立轻量模型（或支持单独配置 web_fetch_model）
• 下调 web_fetch 内部总结请求的重试上限/退避策略
• 对互不依赖的多个 web_fetch 支持并行执行

[doudouOUC]

我排查了代码路径，当前 WebFetch 耗时长主要是几层开销叠加，不是单点问题：

1. WebFetch 不是“只抓网页”，每次抓取后还会再发起一次模型总结请求

   • 代码：packages/core/src/tools/web-fetch.ts（executeDirectFetch）
   • 流程：HTTP 拉取 -> HTML 转文本 -> generateContent(...) 总结
   • 这意味着抓 2 个网页 = 2 次额外 LLM 调用，不只是 2 次 HTTP 请求

2. 总结请求使用的是当前会话主模型，而不是独立轻量模型

   • 代码：packages/core/src/tools/web-fetch.ts（this.config.getModel() || DEFAULT_QWEN_MODEL）
   • 工具描述写的是 small/fast model，但实现里没有切独立快模型
   • 主模型本身慢时，WebFetch 会被明显放大

3. 总结请求带有默认重试与退避，429/5xx 时会拉长到分钟级

   • 代码：packages/core/src/core/client.ts（generateContent 调 retryWithBackoff）
   • 代码：packages/core/src/utils/retry.ts（默认最多 7 次、指数退避、可受 Retry-After 影响）
   • 因此单次 web_fetch 在限流场景下可能很慢

4. 同一轮里多个 web_fetch 当前是串行执行（不是并行）

   • 代码：packages/core/src/core/coreToolScheduler.ts
   • 只有 AGENT 工具并行，其他工具（包括 web_fetch）按顺序 await
   • 所以抓两个网页时，耗时基本是相加关系

结论：你描述的“两个网页三分钟”与当前实现机制一致，主要由
“每页一次 LLM 总结 + 重试退避 + 多次 web_fetch 串行”共同造成。

可优化方向（后续可提 PR）：

• 给 web_fetch 使用独立轻量模型（或支持单独配置 web_fetch_model）
• 下调 web_fetch 内部总结请求的重试上限/退避策略
• 对互不依赖的多个 web_fetch 支持并行执行