前言¶
给一批网站写自动签到是件琐碎的事。每个站点的登录方式不一样，有的只是表单加 Cookie，有的挂人机验证，有的在 Cloudflare 后面，还有的要扫码确认登录。逐站写脚本意味着维护多套登录逻辑，Cookie 过期要重来，站点改页面脚本就要跟着改。
下面介绍的 Skill「网页自动签到」（坐标 @user_8f6c5b09/web-signer）就是冲着这个问题来的。它不针对单一站点，而是提供一个通用的浏览器签到引擎，由 Agent 在对话中触发使用。
这是什么¶
一句话定位：通用浏览器自动签到引擎。发布者是 user_8f6c5b09，属于社区（community）来源，分类为 ai-agent，当前版本 1.4.0，标签 requires_api_key=true，说明使用它需要 API key。
它解决的问题是：把「打开浏览器、完成登录或验证、找到签到入口、执行签到并确认结果」这一整套流程交给 Agent 去驱动，而不是为每个站点单独维护一段脚本。已接入的站点集中放在 scripts/sites/ 目录下，新增站点时在该目录补配置即可，不用改引擎本身。
核心功能¶
从官方简介看，能力分三层。
1、新站点接入。用户提出要给某个网站做自动签到时触发，适合有人机验证、Cloudflare 拦截、或需要扫码登录的站点。这类站点用纯 HTTP 脚本很难稳定通过，需要浏览器环境去完成页面加载和验证交互。
2、关键词触发。当用户说「网站签到」「自动签到」「加个签到站」时，Skill 识别意图并接管后续流程。
3、已接入站点的运维操作。包括签到执行、重新登录（Cookie 或登录态失效时）、以及状态查询（确认某个站点当前是否已签到或登录态是否有效）。
需要留意的是，官方简介没有给出具体接入了多少站点、支持哪些站点的清单，这部分以 scripts/sites/ 目录实际内容为准。
安装与启用¶
SkillHub 页面抓取失败，安装命令、目录路径和配置字段未能从官方资料核实，这里不臆造。获取方式以官方地址为准：
https://api.skillhub.cn/user_8f6c5b09/web-signer
已知的前置条件是 requires_api_key=true，启用前需要准备好可用的 API key。具体是在哪个环节传入（安装参数、环境变量还是配置文件），官方资料中没有说明，部署时以页面上的说明为准。
典型用法¶
用法对应它的三类触发场景。
场景一，接入新站点。用户说「帮我给 XXX 站做自动签到」，Agent 进入浏览器流程，处理该站的人机验证或扫码登录，找到签到入口并执行，之后把结果回报给用户。
场景二，日常签到。用户说「给已接入的站点签到」，Agent 读取 scripts/sites/ 下的配置，逐个或指定站点执行签到。
场景三，重新登录与状态查询。登录态失效时用户要求重新登录；或用户问某站点当前签到状态，Agent 查询并回报。
以上流程来自官方简介描述的触发场景，具体的输入输出格式官方页面未能访问，暂不展开。
适用场景与注意¶
适合的人：手上有多个需要每日签到的站点、站点之间登录方式差异大、不想为每个站点写和维护独立脚本的开发者。尤其适合有人机验证、Cloudflare 防护、扫码登录这类需要真实浏览器交互的站点，这类场景正是它被设计来处理的。
需要注意的几点：
- 该 Skill 来源是 community，即社区发布，不是官方维护，使用前自行评估代码与权限范围。
- 需要 API key，属于有凭据要求的 Skill。
- 浏览器驱动类操作依赖站点页面结构，站点改版后已接入的配置可能需要重新调整。
- 官方页面本次无法访问，评分、下载量、安装量等数字请以页面当前显示为准，本文不引用未经核实的具体数值。
结尾¶
网页自动签到把多站点的登录与签到流程收敛到一个引擎里，新站点靠配置接入而不是重写脚本，适合有人机验证和 Cloudflare 防护的站点。如果正好有这类需求，可以从它的官方地址看起：https://api.skillhub.cn/user_8f6c5b09/web-signer 。
