用 OpenCLI Adapter，让没有 CLI/MCP 的 Web App 对 Agent 更友好

OpenCLI 官网： opencli.info

Agent-friendly

当我们希望 Agent（Pi、Codex、Claude Code 等）访问 Web App、收集信息，并据此分析、决策或执行操作时，我们希望这个 Web App 是 Agent-friendly 的。

通常，我们会寻找三种东西：

API — Agent 可以编写脚本，直接请求结构化数据。
CLI — Agent 可以使用内置 shell，通过命令与产品交互。
MCP — Agent 可以直接调用产品提供的工具。

对 Agent 来说，这些接口比图形 UI 更容易使用。它不必判断该点哪里、读什么，只需发起调用，就能获得结构化结果。

问题是，我们实际使用的许多软件并不提供这些接口。

老旧 Web App、小众 SaaS 产品、内部系统、ERP/CRM 软件，其中很多可能永远不会有官方 CLI 或 MCP server。

那么，怎样让它们变得 Agent-friendly？

OpenCLI Adapter

OpenCLI 让 Agent 通过 CLI 命令与网站交互，也为 Agent 提供 browser primitives，用来探索陌生网站并编写针对特定网站的 Adapter。

没有 Adapter 时，Agent 仍然可以通过浏览器自动化操作网站。

但每次收到任务，它可能都要重新检查页面：

Sales 模块在哪里？
哪个按钮能打开订单页面？
搜索如何使用？
有用的数据在哪里？
页面背后是否有 API？

这种方式能用，但面对重复任务时效率很低。

Adapter 可以把 Agent 对网站的理解变成可复用的接口。

整个工作流可以简化成三步：

Explore → Build → Reuse

Explore

首先，让 Agent 使用通用浏览器能力探索网站。

在这个阶段，它可以检查页面结构、浏览不同模块、查看网络请求，并理解有用信息来自哪里。

假设目标是一个大型 ERP 系统。

整个系统可能包含 CRM、Sales、Accounting、Inventory、HR、Manufacturing 以及几十个其他模块。

如果我是销售人员，可能并不关心所有模块。

我可能只希望 Agent 理解：客户、线索、商机、销售、订单和活动。

所以，探索的目标是理解网站中与我的工作流有关的部分。

Build

Agent 理解这些工作流后，我们就可以让它把流程做成 OpenCLI Adapter。

例如：

opencli myerp customer "Acme"
opencli myerp orders --customer "Acme"
opencli myerp opportunities --owner me

这些命令背后的 Adapter 会处理 Web App 中繁琐的细节。

根据网站情况，OpenCLI Adapter 可以调用公开 endpoint、复用已登录的 browser session、拦截请求，或直接与 UI 交互。

关键在于抽象。

使用 Adapter 的 Agent 不再需要知道该打开哪个页面、点击哪个按钮，或哪个网络请求中包含数据。

它只需知道命令。

而且 Adapter 不必覆盖整个产品。

它可以高度个人化。

销售人员可以有一套 Adapter 接口，运营人员可以提供另一组命令，支持工程师关注的页面也可能完全不同。

我们围绕工作流构建接口，而不是试图把整个网站复制成 CLI。

Reuse

这正是 Adapter 发挥价值的地方。

下一次 Agent 需要查找销售订单时，不必再次探索 ERP。

它可以直接调用：

opencli myerp orders --customer "Acme"

并获得结构化数据。

Agent 需要学习网站时，会使用成本较高的通用浏览器能力，花费大量 token 和时间。

理解这些知识后，我们把它构建进 Adapter。

之后，Agent 就可以复用它。

网站发生变化时，这也提供了一个实用的抽象层。

如果页面位置或底层实现改变，我们可以让 Agent 更新 Adapter，同时尽量保持 Agent 使用的命令不变。

从 Agent 的角度看：

opencli myerp orders --customer "Acme"

可以保持不变。

Agent-friendly 不一定要由产品自身提供

当我们说一个产品是 Agent-friendly 时，通常是指它的开发者提供了 API、CLI 或 MCP server。

OpenCLI Adapter 提供了另一种方式。

对于不提供这些接口的软件，我们可以让 Agent 探索现有 Web App，再在它之上构建一个小型、面向具体任务的接口。

所以这个模式很简单：

Explore → Build → Reuse

用浏览器学习。

把学到的内容做成 Adapter。

然后让未来的 Agent 像调用其他 CLI 一样调用它。

这意味着，即使是老旧、小众或原本对 Agent 不友好的 Web App，也能拥有 Agent-friendly 接口——无需等待产品自己推出 CLI 或 MCP server。

Make CLI/MCP-less Web Apps Agent-Friendly, With OpenCLI Adapter

OpenCLI website: opencli.info

Agent-friendly

When we want an agent (Pi, Codex, Claude Code, etc.) to access a web app, gather information, and use it to analyze, decide, or take action, we hope the web app is agent-friendly.

Usually, we look for three things:

API — the agent can write scripts to directly request structured data.
CLI — the agent can use its built-in shell to interact with the product through commands.
MCP — the agent can directly call tools exposed by the product.

For an agent, these interfaces are much easier to work with than a graphical UI. Instead of figuring out where to click and what to read, it can simply make a call and get structured results back.

The problem is that a lot of software we actually use does not have them.

Older web apps, niche SaaS products, internal systems, ERP/CRM software. Many of them will probably never have an official CLI or MCP server.

So how do we make them agent-friendly?

OpenCLI Adapters

OpenCLI lets agents interact with websites through CLI commands. It also gives agents browser primitives for exploring unfamiliar websites and writing site-specific Adapters.

Without an Adapter, an agent can still operate a website through browser automation.

But every time it receives a task, it may need to inspect the page again:

Where is the Sales module?
Which button opens the orders page?
How does search work?
Where is the useful data?
Is there an API behind this page?

That works, but it is inefficient for something we need to do repeatedly.

An Adapter lets us turn what the agent learns about a website into a reusable interface.

The workflow can be simplified into three steps:

Explore → Build → Reuse

Explore

First, let the agent explore the website with its general browser capabilities.

At this stage, it can inspect the page structure, navigate through different modules, look at network requests, and understand where useful information comes from.

Suppose the target is a large ERP system.

The whole system may contain CRM, Sales, Accounting, Inventory, HR, Manufacturing, and dozens of other modules.

If I use it as a salesperson, I probably don't care about all of them.

I may only want the agent to understand: customers, leads, opportunities, sales, orders and activities.

So the goal of exploration is to understand the part of the website that matters to my workflow.

Build

Once the agent understands those workflows, we can ask it to turn them into an OpenCLI Adapter.

For example:

opencli myerp customer "Acme"
opencli myerp orders --customer "Acme"
opencli myerp opportunities --owner me

Behind these commands, the Adapter handles the messy details of the web app.

Depending on the site, an OpenCLI Adapter can work with public endpoints, reuse the logged-in browser session, intercept requests, or interact with the UI itself.

The important part is abstraction.

The agent using the Adapter no longer needs to know which page to open, which button to click, or which network request contains the data.

It only needs to know the command.

And the Adapter does not have to cover the whole product.

It can be highly personal.

A salesperson can have one Adapter interface. An operations employee can expose another set of commands. A support engineer may care about completely different pages.

We are building the interface around the workflow, instead of trying to reproduce the whole website as a CLI.

Reuse

This is where the Adapter becomes valuable.

The next time an agent needs to find a sales order, it does not need to explore the ERP again.

It can directly call:

opencli myerp orders --customer "Acme"

and get structured data back.

The expensive general browser capability is used when the agent needs to learn the website, spending a lot of tokens and time.

Once that knowledge is understood, we build it into an Adapter.

After that, agents can reuse it.

This also gives us a useful abstraction layer when the website changes.

If a page moves or an underlying implementation changes, we can ask agents to update the Adapter while keeping the command that the agent uses roughly the same.

From the agent's perspective:

opencli myerp orders --customer "Acme"

can stay unchanged.

Agent-friendly does not have to come from the product itself

When we say a product is agent-friendly, we usually mean that its developers have provided an API, CLI, or MCP server.

OpenCLI Adapters offer another approach.

For software that does not provide those interfaces, we can let an agent explore the existing web app and build a small, task-specific interface on top of it.

So the pattern is simple:

Explore → Build → Reuse

Use the browser to learn.

Turn what was learned into an Adapter.

Then let future agents call it like any other CLI.

That means even an old, niche, or otherwise agent-unfriendly web app can gain an agent-friendly interface — without waiting for the product itself to ship a CLI or MCP server.