引子:原生工具是否足够
Claude Code 开箱即带两个联网工具:WebSearch 负责发现,WebFetch 负责提取。能力清单看似完整,但在真实的 Agent 联网任务中,会接连遇到三类典型障碍:
- 读取微信公众号文章,
WebFetch返回的是「环境异常」的空壳; - 访问小红书账号页,正文在 JS 执行后才渲染,
curl仅能取回骨架; - 同时调研多个竞品官网,串行
WebFetch耗时长,且回传的大段 HTML 会将上下文撑爆。
这三类障碍暴露的不是 Claude Code 的能力不足,而是缺少两样东西:一套联网的调度策略,以及一层浏览器能力。原生工具是零件,却没有引擎将其组织起来。
web-access(当前 v2.4.1,作者一泽 Eze)补全的正是这一层:联网策略 + CDP 浏览器代理 + 站点经验积累(CDP 即 Chrome DevTools Protocol,Chrome 浏览器的底层控制协议)。它的特别之处在于,这并非一个「代为联网的脚本」,而是一份指导 Agent 如何思考联网任务的哲学文档,外加一个最小化的 CDP 代理实现(572 行零依赖 Node 脚本)。
本文不做功能罗列,而是从源码层面将其拆透:先阐述设计哲学,再解析 CDP Proxy 的工程实现,最后落到笔者主导的一个 AIGC 内容生产系统——以一个真实生产系统的技术选型与边界识别,印证 web-access 的价值。需要强调的是,本文的真正主角是笔者的工程实践(服务端 axios 爬虫框架、OPRO Prompt 自我进化,OPRO 即 Optimization by PROmpting,基于提示的 Prompt 自动优化算法),web-access 是用来反哺验证选型边界的业界参照。全文只回答一个问题:一个优秀的 Agent Skill,究竟该具备怎样的形态——以及一个工程师如何从自己的生产实践中识别技术边界、并找到解法。

