背景
做 Agent 网页读取时，最先撞到的不是解析规则，而是登录态。
最早的做法是把页面 token 手动塞进环境变量，再由脚本拼请求头去抓内容。这个方案能快速验证，但站点一多就会反复踩同一个坑：token 过期、存储位置不统一、每个 skill 都要重复写一套"读取-校验-重登"逻辑。
问题不在"能不能抓到页面"，而在"能不能长期稳定地抓到页面"。
迭代
第一版：环境变量直连
做法直接：手动复制 token，写入本地环境变量，脚本读取后发请求。
成本低，适合原型验证。问题也明显：token 生命周期短，每个站点实现不同，重复代码随站点数量线性增长。
第二版：抽到 monorepo 公共包
把登录态保存、请求上下文、浏览器上下文集中到 package，各 skill 调用统一方法。
去掉了重复实现，skill 不再关心 cookies/localStorage 的落盘细节。但仍依赖仓库结构，安装与分发不够独立，Agent 侧也缺少稳定的命令入口。
第三版：独立成 site-fetchkit CLI 工具
现在 CLI 提供统一动作：
login：打开可见浏览器登录，持久化 cookies/localStoragerun：执行站点 skill，并注入运行时能力fetch：通用页面读取create-site：生成站点 skill 骨架update：刷新内置 skill
Runtime 暴露两个核心入口：createRequestContext 适合接口可直取的站点，createBrowserContext 适合依赖前端渲染的页面。
站点脚本只需关心内容怎么提取，不再处理登录态和 Playwright 初始化：
import { createRequestContext, htmlToText } from "site-fetchkit";
export async function fetchSiteContent({ url, site = "wiki" }) {
const ctx = await createRequestContext(site);
try {
const res = await ctx.get(url);
return { status: res.status(), text: htmlToText(await res.text()) };
} finally {
await ctx.dispose();
}
}
这一步完成后职责边界清楚了：site-fetchkit 负责运行时能力和通用编排，站点 skill 只维护站点差异和内容提取规则。
安装使用
npm install -g site-fetchkit
site-fetchkit init
