网页工具决策链

要解决的问题

Agent 在处理网页任务时通常只有一把锤子：拿到 URL 就开浏览器，遇到搜索就调搜索接口，结果要么在静态页面上白白起一个重量级的浏览器会话，要么在 JS 渲染页面上用 web_fetch 拿到空白骨架后直接失败。真正麻烦的是降级路径不透明——工具失败后 Agent 常常静默换一种方式重试，用户既不知道出了什么问题，也不知道接下来会发生什么。这个技能针对的就是这类「工具选择靠猜、降级靠运气」的场景。

核心能力

技能遵循 ReAct 范式，但它对四个工具的定位做了重新设计：web_search、web_fetch、opencli、browser 不是层级关系，而是分支决策。

先按场景判断：

• 没有明确 URL，需要搜索信息：直接调用 web_search，传入关键词，从结果里拿到 URL 后再进入下一步。
• 已有 URL，页面是静态内容（新闻文章、博客、技术文档、API 端点、RSS 源）：直接调用 web_fetch。
• 已知 URL 但页面依赖 JS 渲染、需要登录态、需要点击/填表/滚动等交互、需要截图：这部分没有捷径，进入 browser。

当第一层工具不适用或失败时，切换顺序是固定的：先试 opencli，仍不行再升级到 browser。每次切换都要告知用户原因，不允许静默降级。opencli 覆盖 70+ 主流网站，返回结构化数据，定位是轻量级兜底；browser 则是最后手段，处理 SPA、登录后才可见的内容、页面交互和视觉信息。

browser 的操作流程被拆成了三类并各自给了步骤约束。只读信息获取要求等待关键元素出现而非固定时间等待。登录操作要求先查找 well-known-sites 中的登录页 URL，告知用户即将执行登录并等待确认，再填入凭证或提示扫码，后续操作复用同一浏览器上下文。页面交互用 CSS 选择器定位元素（辅以文本匹配），执行点击/输入/滚动后等待响应再提取结果或截图。

web_search 失败时不走静默降级，而是先读取 web-search-config 参考文件，按 Step 1 原样输出配置引导（不改写表格、不省略内容），等用户提供 API Key 后按 Step 2-5 执行；用户明确拒绝配置后才进入降级方案：先从 well-known-sites 取常用 URL，用 web_fetch 直接获取，仍不行再升级到 browser。

适用边界

• 登录与敏感操作必须二次确认：任何涉及账号登录的操作前要先告知并等待确认；发帖、删除、支付等不可逆操作同样需要确认。
• 验证码需要人工介入：browser 无法自动处理 CAPTCHA 时应明确告知用户手动解决，而不是反复重试。
• opencli 首次使用有前置条件：如果提示 command not found，需要先运行安装脚本（幂等可重复执行）。
• 智能等待不是万能的：固定 sleep 式等待被明确禁止，但元素等待在极端弱网下仍可能超时，需要设置合理超时并在失败时告知用户建议重试。
• 状态复用是硬约束：登录后的后续操作必须复用同一浏览器上下文，重新打开会丢失登录态。

这个技能适合把网页工具当作一个需要显式决策的过程来管理的 Agent 工作流，而不是需要多模态理解或复杂视觉推理的场景。