从复制 Token 到复用登录态：site-fetchkit 的抽离过程

背景

做 Agent 网页读取时，最先撞到的不是解析规则，而是登录态。

最早的做法是把页面 token 手动塞进环境变量，再由脚本拼请求头去抓内容。这个方案能快速验证，但站点一多就会反复踩同一个坑：token 过期、存储位置不统一、每个 skill 都要重复写一套"读取-校验-重登"逻辑。

问题不在"能不能抓到页面"，而在"能不能长期稳定地抓到页面"。

迭代

第一版：环境变量直连

做法直接：手动复制 token，写入本地环境变量，脚本读取后发请求。

成本低，适合原型验证。问题也明显：token 生命周期短，每个站点实现不同，重复代码随站点数量线性增长。

第二版：抽到 monorepo 公共包

把登录态保存、请求上下文、浏览器上下文集中到 package，各 skill 调用统一方法。

去掉了重复实现，skill 不再关心 cookies/localStorage 的落盘细节。但仍依赖仓库结构，安装与分发不够独立，Agent 侧也缺少稳定的命令入口。

第三版：独立成 site-fetchkit CLI 工具

现在 CLI 提供统一动作：

login：打开可见浏览器登录，持久化 cookies/localStorage
run：执行站点 skill，并注入运行时能力
fetch：通用页面读取
create-site：生成站点 skill 骨架
update：刷新内置 skill

Runtime 暴露两个核心入口：createRequestContext 适合接口可直取的站点，createBrowserContext 适合依赖前端渲染的页面。

站点脚本只需关心内容怎么提取，不再处理登录态和 Playwright 初始化：

javascript 复制代码

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 只维护站点差异和内容提取规则。

安装使用

csharp 复制代码

npm install -g site-fetchkit
site-fetchkit init

项目地址：github.com/streaker303...