[QAyong]

背景与关联 / Context and related issue

• 问题或目标 / Problem or goal: 网页搜索与抓取共用一个并发计数器，同时执行超过 4 个时，新请求立即返回 WEB_BUSY，不排队。主代理、子代理或 codemode（同时放行 16 个工具调用）并行发起网页请求时，会反复撞上这个上限；被拒的请求没有自动重试，本来能访问的网页就被当作“正文获取失败”交付。页面渲染还有一个更小的上限（同时 2 个），抓取需要渲染的页面（如微信公众号文章）会先撞上它。实测中两次抓取在 5 毫秒、26 毫秒内返回 WEB_BUSY，单独重试同一链接约 1 秒即成功，说明不是目标网站的问题。
• 关联 Issue / Related issue: N/A

主要改动 / Changes

• 新增 WebConcurrencyGate：满额后进入有界等待队列，最长等待 30 秒，队列最多 64 个，超出才返回 WEB_BUSY；排队中被取消或应用关停时立即退出队伍，不占名额。
• WebCapabilityService.#run 先取名额再执行。90 秒执行超时在拿到名额后才开始计时，排队时间不占用。
• 页面渲染（同时 2 个）在服务层同样排队，不再把第 3 个渲染请求送到宿主被拒。
• 新增错误码 WEB_QUEUE_TIMEOUT，表示排队超时、尚未访问目标网站，与目标网站失败区分；新增诊断阶段 queued，started 带上排队耗时。
• 并发上限 4 和 2 保持不变，待有排队耗时数据后再决定是否调整。

验证 / Verification

• 自动检查 / Automated checks: pnpm exec vitest run service/src/web（apps/buddy）9 个文件 39 个用例通过。新增 3 个用例：6 个请求同时提交时同时执行不超过 4 个且全部完成；排队中取消后返回 WEB_CANCELLED 且名额不泄漏；排队超过 30 秒返回 WEB_QUEUE_TIMEOUT 且 attempts 为空。
• 手动验证 / Manual verification: 无。
• 未执行 / Not run: 全量测试、完整 type-check、渲染排队的专门用例、Windows 上的实机验证。宿主侧“同时 8 个请求”的上限仍是立即拒绝，本 PR 未改动。

兼容与风险 / Compatibility and risks

• 不涉及已有数据、配置或授权。新增的错误码和诊断阶段是追加项，不改变已有取值。
• 满额时的行为由“立即失败”变为“最长等待 30 秒”，持续过载时单次调用的返回会更晚；队列满或超时仍会明确返回失败，不会无限等待。
• 希望审阅者重点看 WebConcurrencyGate 里名额交接与取消、超时的竞争处理。

界面变更 / UI changes

不适用 / N/A

[QAyong]

我觉得要不要调高上限，因为子代理外加codemode这个工具，并发上限明显就高了

[shanyuhai123]

这个确实是需要处理下