未来软件不只服务于人,更要服务于 Agent:聊聊网页自动化的范式转变

在 AI Agent 爆火的今天，我们经常能看到各种让 Agent 操控浏览器的演示（比如 Browser Use、Puppeteer 脚本）。Agent 看着屏幕、寻找选择器、模仿人类去点击按钮、输入文本。

这种方式固然惊艳，但在实际工程落地中，基于 GUI 的浏览器自动化是一场维护噩梦。

传统 UI 自动化的“五宗罪”

在企业内部系统、运营后台、工单平台等场景中，依赖 DOM 结构的自动化脚本极其脆弱：

1. 1. 页面元素不稳定：前端稍微改个版、换个组件库，或者按钮文案从“提交”变成“确定”，脚本就直接挂掉。
2. 2. 加载时序复杂：各种异步加载、骨架屏、懒加载、微前端架构，让 wait_for_selector 变成了一门玄学。
3. 3. 执行效率低下：为了拿到一个数据，Agent 必须等待整个页面渲染完成、下载几兆的图片和 JS 资源，白白浪费时间和 Token。
4. 4. 深层数据难获取：很多关键数据（如评论区、隐藏弹窗、分页数据）必须有特定的交互才会触发。
5. 5. 维护成本高昂：开发半小时，维护火葬场。系统一更新，开发人员就要重新进控制台抓元素。

其实，换个思维方式：浏览器页面上看到的一切数据，本质上都来自前端调用的接口。

既然如此，我们为什么不绕过脆弱的 UI 界面，直接定位网页背后的 API，把网页能力封装成本地 CLI 命令呢？这就是 OpenCLI 的核心思路。

什么是 OpenCLI？

OpenCLI（由开发者 jackwener 开源）是一款颠覆传统爬虫和 UI 自动化思维的工具。它将浏览器视为一个“带认证状态的 API 客户端”，通过捕获和分析网络请求，将复杂的网页操作直接转化为稳定、快速、可组合的本地 CLI 命令。

快速上手体验

安装非常简单，只需全局执行 npm 命令：

npm install -g @jackwener/opencli

安装后，你就可以直接在终端里用命令消费网页数据。例如：

# 查看支持的命令
opencli list

# 获取 Hacker News 或 Bilibili 的热门内容
opencli hackernews top --limit 5
opencli bilibili hot --limit 5

# 将知乎热榜直接输出为 JSON 或 YAML 格式，方便下游脚本处理
opencli zhihu hot -f json

OpenCLI 的核心武器：五级认证策略

直接调接口最大的难点在于认证（Authentication）。很多企业系统有复杂的登录态、CSRF Token、或者动态签名。

OpenCLI 独创了 Cascade（瀑布流）探测机制，提供了一套逐级降级的认证思路。当你执行 opencli cascade [https://api.example.com/hot](https://api.example.com/hot) 时，它会按以下策略自动尝试：

通过这种瀑布流机制，OpenCLI 既保证了优先使用高效的 API 方案，又保留了 UI 自动化的兜底能力。

AI Agent 的网页探索工作流

如何利用 OpenCLI 自动生成一个 CLI 命令？文章提出了一套非常适合 AI Agent 执行的标准探索工作流：

[0. 导航] ──> 打开目标网页 (browser_navigate)
   │
[1. 观察] ──> 观察可交互元素与初始请求 (browser_snapshot & network)
   │
[2. 交互] ──> 真实模拟滚动、点击标签、触发懒加载 (browser_click)
   │
[3. 对比] ──> 对比新旧网络请求，精准定位新增 API (browser_network_requests)
   │
[4. 验证] ──> 在浏览器内用 fetch(url, { credentials: "include" }) 验证接口
   │
[5. 生成] ──> 根据探索结果，自动合成 YAML 或 TypeScript 适配器

💡 关键点：不要相信静态页面！
很多核心接口（如视频字幕、详情弹窗、评论区下一页）只有在用户发生真实的滚动或点击后才会触发（懒加载机制）。因此，Agent 必须进行动态交互 + 网络观察，才能捞出隐藏在水面底下的 API。

适配器选择：YAML vs TypeScript

根据接口的复杂度，OpenCLI 支持两种适配器来封装命令：

• • YAML 适配器：适合纯声明式的流程。如果只是简单的数据抓取、字段映射和数量限制（Limit），用 YAML 极其轻量。
• • TypeScript 适配器：适合需要内嵌 JS 复杂逻辑、多步骤串联、动态处理参数或 Tier 4 状态拦截的场景。

生产环境落地的思考：只读 vs 写入

在实际应用中（如内部会议平台 CLI 化、BOSS 直聘自动化辅助），我们通常把网页能力分为两类：

• • 只读类操作（Read-Only）：如列表、详情、搜索、监控数据。这类场景最适合 OpenCLI。配合 opencli record（操作录制），工具可以自动捕获交互触发的请求序列，通过语义分析直接生成可复用的只读命令。
• • 写入类操作（Mutation）：如创建工单、修改状态、删除配置。这类场景需要特别小心。因为写操作往往涉及请求体（Payload）的深度分析、权限校验、以及幂等性问题。现阶段在处理写操作时，建议使用 TypeScript 适配器进行人工干预和严格的安全边界校验。

未来趋势：从“用户界面”到“可调用性”

在过去，我们评价一款 SaaS 产品或内部系统好不好用，标准的维度是：界面是否美观？按钮是否好找？交互是否反人类？ 这是服务于人类（Human）的视角。

但未来，软件的协同者将有很大一部分变成 AI Agent。

Agent 不关心你的按钮是不是渐变色，它关心的是：你的能力是否能被稳定调用？是否有明确的输入参数？是否有结构化的返回值（JSON/YAML）？失败时的错误信息是否可被理解？

软件竞争将新增一个极为关键的维度——可调用性（Callability）。那些缺乏标准 API、DOM 结构混乱、又拒绝被逆向转换的“黑盒系统”，将在 Agent 时代被迅速淘汰；而像 OpenCLI 这样的工具，正在成为连接旧世界系统与新世界 Agent 之间最重要的一座桥梁。