Agent 的 Web Access 是工具链稳定性的短板
一句话
AI Agent 想进入真实工作流，必须稳定访问网页、登录态和内网系统；但现在 Web Access 仍然依赖 CDP、代理、浏览器会话这些脆弱环节，所以它是 Agent 工具链里最不稳定的基础设施。
为什么它不是普通功能
很多 AI 工具可以写代码、总结文档、生成内容，但一碰到真实世界的信息入口，就会遇到 Web Access 问题：
- 读公众号文章需要真实浏览器环境，因为反爬严格。
- 搜社交媒体需要登录态和 cookie。
- 访问内网系统需要 VPN、认证和权限。
- 操作网页表单需要点击、输入、等待页面响应。
- Telegram、网页端签到等任务需要保持登录状态。
没有稳定的 Web Access，Agent 就像一个断网的聪明人：能推理、能写代码，但无法持续进入外部系统完成工作。
我真正关心的问题
表面上看，Web Access 是“让 AI 访问网页”。但真正的问题是：
能不能给 Agent 一个稳定、可控、安全、可复用的工作入口？
我并不是只想让它抓一篇网页，而是希望它能像人一样在网页、内网系统、知识库、公众号、后台页面之间来回工作。这意味着它需要的不只是 HTTP 请求，而是一整套浏览器基础设施。
现有方案为什么都不完美
| 方案 | 代表 | 优点 | 痛点 |
|---|---|---|---|
| HTTP 直接请求 | curl / WebFetch | 快，零配置 | 国内平台 block、JS 渲染页拿不到内容、无登录态 |
| Chrome CDP | 9333 端口远程调试 | 标准协议，生态好 | 需手动开启 Chrome 远程调试、配置繁琐、不稳定 |
| 浏览器自动化服务器 | 3456 端口（agent-reach） | 专为 Agent 设计，API 简洁 | 非标准方案，依赖特定实现，生态弱 |
| 内置工具 | WorkBuddy WebFetch/WebSearch | 开箱即用 | 不走本地代理，境外受限；对国内平台支持弱 |
| 第三方抓取服务 | Jina.ai / r.jina.ai | 免配置 | 微信公众号/知乎支持有限，不稳定 |
| Skill 封装 | web-access skill、browser-gemini-image | 封装了复杂流程 | 底层依赖 CDP，CDP 出问题全挂 |
实测证据
2026-04-20 的实测中，Web Access 相关场景表现：
| 场景 | 工具 | 结果 | 根因 |
|---|---|---|---|
| 公众号文章抓取 | browser + web-access | ⭐⭐ 需 CDP | WebFetch 被 block，必须真实浏览器 |
| Web Access 通用 | browser + agent-reach | ⭐⭐ 需 CDP | 同上 |
| Telegram 签到 | telegram-checkin | ⭐⭐ 需 CDP | 浏览器自动化未就绪 |
| AI 生图 | image_generate | ⭐ 全部 block | 代理/IP 问题 |
| 公众号抓取（3456 方案） | 3456 端口服务器 | ⭐⭐⭐⭐⭐ 可用 | 唯一亮点：3456 端口方案确实能跑 |
3456 端口，也就是 agent-reach 的浏览器自动化服务器，确实有效。它可以通过 /new?url= 和 /eval?target= 成功抓取微信公众号文章。
但这个方案的问题也很明显：它不是标准能力，而是特定环境里的小众实现。换一台机器、换一个浏览器状态、换一个网络环境，就可能重新调一遍。
核心矛盾
| Agent 需要的能力 | 现实问题 |
|---|---|
| 一键获取网页内容 | 经常需要配置 Chrome CDP |
| 保持登录态跨会话 | 浏览器重开后 cookie 和 session 容易丢 |
| 稳定 7x24 运行 | CDP 连接、代理、浏览器状态都会断 |
| 跨平台访问国内外网站 | 代理、防火墙、反爬各搞一套 |
| 零配置开箱即用 | 每个环境都要手动调 |
这就是为什么很多 Agent demo 看起来很顺，但真正落到长期工作流时会卡住。Web Access 不稳定，整个自动化链条就不稳定。
和其他原子笔记的关系
这条笔记和 2026-06-01 判断：复杂AI自动化工作流无法保证稳定性 是一组问题：复杂 AI 工作流不是模型一强就会稳定，它依赖一堆外部接口、浏览器状态、权限和上下文。
它也和 企业AI上下文壁垒 同构：企业 AI 的问题不是 AI 不会推理，而是它拿不到可用上下文；Web Access 的问题则是 Agent 拿不到稳定的外部环境。
当前判断
我现在不应该把 Web Access 当作一个“小功能”看待，而应该把它当作 Agent 基础设施问题。
如果一个方案只能在我的电脑、我的浏览器、我的网络状态下偶尔跑通，它就不能支撑长期自动化。真正可用的方案应该满足三个条件：
- 登录态可持续。
- 浏览器环境可复现。
- Agent 调用接口足够标准。
可能的出路
- Playwright / Puppeteer 常驻服务 — 比裸 CDP 更稳定，有成熟的 session 管理
- 容器化浏览器（browserless/chrome-headless）— Docker 部署，环境一致性有保障
- WorkBuddy 如果开放 MCP browser 工具 — 借平台的力，不用自己维护浏览器
- 浏览器扩展方案 — 在用户日常使用的浏览器里注入 Agent 能力，登录态天然保持
- 等一个「浏览器 as a service」 — 类似数据库云服务，浏览器也变成 API 调用
下一步
后续如果要继续推进这条技术线，不是再比较“哪个抓取工具更好”，而是要验证哪一种方案最接近稳定基础设施：
- 是否能跨会话保留登录态？
- 是否能被 Agent 用标准接口调用？
- 是否能稳定处理公众号、知乎、V2EX、内网系统这类高摩擦网页？
- 是否能迁移到另一台机器，而不用从头调环境？