web-access

name web-access license MIT github https://github.com/eze-is/web-access description 所有联网操作必须通过此 skill 处理，包括：搜索、网页抓取、登录后操作、网络交互等。 触发场景：用户要求搜索信息、查看网页内容、访问需要登录的网站、操作网页界面、抓取社交媒体内容（小红书、微博、推特等）、读取动态渲染页面、以及任何需要真实浏览器环境的网络任务。 metadata {"author":"一泽Eze","version":"2.4.1"} web-access Skill 前置检查 在开始联网操作前，先检查 CDP 模式可用性： node " $SKILL_DIR /scripts/check-deps.mjs" Node.js 22+ ：必需（使用原生 WebSocket）。版本低于 22 可用但需安装 ws 模块。 Chrome remote-debugging ：在 Chrome 地址栏打开 chrome://inspect/#remote-debugging ，勾选 "Allow remote debugging for this browser instance" 即可，可能需要重启浏览器。 检查通过后再启动 CDP Proxy 执行操作，未通过则引导用户完成设置。 浏览哲学 像人一样思考，兼顾高效与适应性的完成任务。 执行任务时不会过度依赖固有印象所规划的步骤，而是带着目标进入，边看边判断，遇到阻碍就解决，发现内容不够就深入——全程围绕「我要达成什么」做决策。这个 skill 的所有行为都应遵循这个逻辑。 ① 拿到请求 — 先明确用户要做什么，定义成功标准：什么算完成了？需要获取什么信息、执行什么操作、达到什么结果？这是后续所有判断的锚点。 ② 选择起点 — 根据任务性质、平台特征、达成条件，选一个最可能直达的方式作为第一步去验证。一次成功当然最好；不成功则在③中调整。比如，需要操作页面、需要登录态、已知静态方式不可达的平台（小红书、微信公众号等）→ 直接 CDP ③ 过程校验 — 每一步的结果都是证据，不只是成功或失败的二元信号。用结果对照①的成功标准，更新你对目标的判断：路径在推进吗？结果的整体面貌（质量、相关度、量级）是否指向目标可达？发现方向错了立即调整，不在同一个方式上反复重试——搜索没命中不等于"还没找对方法"，也可能是"目标不存在"；API 报错、页面缺少预期元素、重试无改善，都是在告诉你该重新评估方向。遇到弹窗、登录墙等障碍，判断它是否真的挡住了目标：挡住了就处理，没挡住就绕过——内容可能已在页面 DOM 中，交互只是展示手段。 ④ 完成判断 — 对照定义的任务成功标准，确认任务完成后才停止，但也不要过度操作，不为了"完整"而浪费代价。 联网工具选择 确保信息的真实性，一手信息优于二手信息 ：搜索引擎和聚合平台是信息发现入口。当多次搜索尝试后没有质的改进时，升级到更根本的获取方式：定位一手来源（官网、官方平台、原始页面）。 场景 工具 搜索摘要或关键词结果，发现信息来源 WebSearch （如可用）或 curl 搜索引擎 URL 已知，需要从页面定向提取特定信息 WebFetch （如可用）或 curl 配合 Jina URL 已知，需要原始 HTML 源码（meta、JSON-LD 等结构化字段） curl 非公开内容，或已知静态层无效的平台（小红书、微信公众号等公开内容也被反爬限制） 浏览器 CDP （直接，跳过静态层） 需要登录态、交互操作，或需要像人一样在浏览器内自由导航探索 浏览器 CDP 浏览器 CDP 不要求 URL 已知——可从任意入口出发，通过页面内搜索、点击、跳转等方式找到目标内容。 Jina （可选预处理层，可与 curl 组合使用，由于其特性可节省 tokens 消耗，请积极在任务合适时组合使用）：第三方网络服务，可将网页转为 Markdown，大幅节省 token 但可能有信息损耗。调用方式为 curl -sL r.jina.ai/example.com （URL 前加前缀，不保留原网址 http 前缀），限 20 RPM。适合文章、博客、文档、PDF 等以正文为核心的页面；对数据面板、商品页等非文章结构页面可能提取到错误区块。 进入浏览器层后， /eval 就是你的眼睛和手： 看 ：用 /eval 查询 DOM，发现页面上的链接、按钮、表单、文本内容——相当于「看看这个页面有什么」 做 ：用 /click 点击元素、 /scroll 滚动加载、 /eval 填表提交——像人一样在页面内自然导航 读 ：用 /eval 提取文字内容，判断图片/视频是否承载核心信息——是则提取媒体 URL 定向读取或 /screenshot 视觉识别 浏览网页时， 先了解页面结构，再决定下一步动作 。不需要提前规划所有步骤。 程序化操作与 GUI 交互 浏览器内操作页面有两种方式： 程序化方式 （构造 URL 直接导航、eval 操作 DOM）：成功时速度快、精确，但对网站来说不是正常用户行为，更容易触发反爬机制。 GUI 交互 （点击按钮、填写输入框、滚动浏览）：GUI 是为人设计的，网站不会限制正常的 UI 操作，确定性最高，但步骤多、速度慢。 根据对目标平台的了解来判断。当程序化方式受阻时，GUI 交互是可靠的兜底。 浏览器 CDP 模式 通过 CDP Proxy 直连用户日常 Chrome，天然携带登录态，无需启动独立浏览器。 若无用户明确要求，不主动操作用户已有 tab，所有操作都在自己创建的后台 tab 中进行，保持对用户环境的最小侵入。不关闭用户 tab 的前提下，完成任务后关闭自己创建的 tab，保持环境整洁。 启动 node " $SKILL_DIR /scripts/check-deps.mjs" 脚本会依次检查 Node.js、Chrome 端口，并确保 Proxy 已连接（未运行则自动启动并等待）。Proxy 启动后持续运行。 Proxy API 所有操作通过 curl 调用 HTTP API： # 列出用户已打开的 tab curl -s http://localhost:3456/targets # 创建新后台 tab（自动等待加载） curl -s "http://localhost:3456/new?url=https://example.com" # 页面信息 curl -s "http://localhost:3456/info?target=ID" # 执行任意 JS curl -s -X POST "http://localhost:3456/eval?target=ID" -d 'document.title' # 捕获页面渲染状态 curl -s "http://localhost:3456/screenshot?target=ID&file=/tmp/shot.png" # 导航、后退 curl -s "http://localhost:3456/navigate?target=ID&url=URL" curl -s "http://localhost:3456/back?target=ID" # 点击（POST body 为 CSS 选择器） curl -s -X POST "http://localhost:3456/click?target=ID" -d 'button.submit' # 真实鼠标点击 curl -s -X POST "http://localhost:3456/clickAt?target=ID" -d 'button.upload' # 文件上传 curl -s -X POST "http://localhost:3456/setFiles?target=ID" -d '{"selector":"input[type=file]","files":["/path/to/file.png"]}' # 滚动 curl -s "http://localhost:3456/scroll?target=ID&y=3000" curl -s "http://localhost:3456/scroll?target=ID&direction=bottom" # 关闭 tab curl -s "http://localhost:3456/close?target=ID" 登录判断 用户日常 Chrome 天然携带登录态，大多数常用网站已登录。打开页面后先尝试获取目标内容。只有当确认目标内容无法获取且判断登录能解决时，才告知用户需要登录。 任务结束 用 /close 关闭自己创建的 tab，必须保留用户原有的 tab 不受影响。 站点经验 操作中积累的特定网站经验，按域名存储在 $SKILL_DIR/references/site-patterns/ 下。 确定目标网站后，如果有匹配的站点经验文件，必须读取获取先验知识。CDP 操作成功完成后，如果发现了有必要记录经验的新站点或新模式，主动写入对应的站点经验文件。 信息核实类任务 核实的目标是 一手来源 ，而非更多的二手报道。搜索引擎和聚合平台是信息发现入口，是 定位 信息的工具，不可用于直接 证明 真伪。找到来源后，直接访问读取原文。