最近开源社区有个新面孔让我挺意外:一个叫 web-access 的 skill,刚发布没多久就拿下了 1.7K Star。它解决的问题一句话就能说清,却让不少 AI 开发者等了很多年——让 AI Agent 真正具备"上网"的能力。
这里说的"上网",不是聊天框里那个官方联网开关,而是以 skill(技能包/插件)的方式,把"实时抓取网页、解析正文、把信息喂给大模型"这件事做成标准能力。Agent 在运行中一旦判断自己需要网页信息,就会自动加载这个技能,而不是靠模型脑补。对于关注 AI Agent、AI 编程、RAG 应用的人来说,这类项目属于典型"看着不起眼、用起来真香"的基建型工具。我花了一个周末把它部署到本地环境里跑了一遍,今天把整个思路、部署过程和踩过的坑都写出来,希望能帮你少走弯路。
1. 为什么"AI 上网"突然成了刚需,而 skill 是最优雅的解法
1.1 大模型的"知识孤岛",比想象中更严重
先聊一个老问题:大模型的知识是有截止日期的。你问它一个上个月刚上线的功能,或者某个框架最新版本的 API 写法,它大概率会一本正经地给你编一个答案。我吃过这个亏:有次让一个模型帮我查某个组件的新版配置,它给出的字段在最新版本里已经被废弃了,要是我直接抄进生产环境,线上服务大概率直接起不来。
这就是所谓的"知识孤岛"——模型再强,也只能基于训练数据里的世界去回答问题,而真实世界的信息每分钟都在变化。网页恰恰是信息变化最快的地方:官方文档、公告、价格页、GitHub Release、在线表单……这些都需要实时访问。于是"给 AI 接上实时网页访问能力",就成了从"聊天机器人"走向"真 Agent"的第一道门槛。
1.2 为什么偏偏是 skill,而不是写死一段爬虫代码
如果你只是想让自己写的脚本能抓网页,当然可以直接用 requests 加 BeautifulSoup 搞定。但放在 Agent 场景里,需求完全不一样:Agent 需要的是在正确的时间,自动调用正确的工具。
近一年来,以 Codex 为代表的 AI 编程生态带火了一个概念——skill。你可以把它理解成"给 Agent 的岗位说明书 + 操作手册":一个 skill 通常由描述文件、若干工具脚本、使用示例和约束规则组合而成,放在约定的目录结构里。Agent 运行时,会根据当前任务自动判断该调用哪个 skill,然后像人一样"照着手册执行"。
类比一下就懂了:人看到菜谱就知道怎么做菜,不需要把锅铲焊在手上。skill 就是 AI 的菜谱,web-access 就是其中一张"怎么上网查资料"的菜谱。相比让模型自己临场写爬虫,skill 这种方式把网络请求、页面解析、正文提取、错误处理这些脏活累活全部固化下来,一次调试,处处复用。
1.3 和"让模型自己写代码抓网页"相比,skill 赢在哪
你可能想问:既然大模型会写代码,为什么不能让它现场写个爬虫去抓?理论上可以,但实际跑过就知道,Agent 自己写爬虫的失败率非常高。我把两种方式的差异整理成了一张表:
| 对比维度 | 模型临时写爬虫 | 使用 web-access 这类 skill |
|---|---|---|
| 稳定性 | 每次生成的代码都可能不同,踩坑重来 | 代码固定,逻辑经过反复验证 |
| 解析质量 | 容易把导航、广告、脚本都抓进去 | 有正文提取逻辑,输出干净 |
| token 消耗 | 反复试错,多次读页,开销大 | 一次抓取,提炼后的文本直接入上下文 |
| 安全边界 | 容易信不过,可能抓内网地址 | 可配置白名单、只读、最大页面数 |
| 复用性 | 换个页面全重写 | 一个 skill 到处用 |
这个对比不是我拍脑袋写的,是真实跑过之后得出的体会。模型写爬虫不是不行,但每次都从零开始,成本太高。而且模型很难意识到"这个页面是 JS 动态渲染的"或"这里需要带 Cookie",人类开发者一眼能判断的事情,模型要试错好几轮才能发现。
1.4 web-access 在整个 Agent 生态里的定位
那么这个项目的 1.7K Star 要怎么理解?我的看法是:它踩中了一个被压抑很久的需求。
过去一年,大家把 Agent 的能力重点放在"规划"和"推理"上,却忽略了 Agent 真正干活需要的基础工具。web-access 不是某个垂直领域的爬虫框架,而是 Agent 工具箱里最底层的一个组件,就像搬家需要的手推车,不起眼但绕不开。开发者们受够了自己重复造爬虫轮子的日子,看到有人把这件事做好了还开源出来,自然会用 Star 投票。
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
