把 Web App 反向工程成 Agent 工具：Show HN 热议的新思路

A developer showcased on Hacker News a method for reverse-engineering any Web App into an agent-callable tool, bypassing the lack of APIs and the limited coverage of the MCP ecosystem, effectively turning the browser into a universal arm for LLMs.

What Should an Agent Do When It Wants to Use a Website That Has No API?

On July 8, a Show HN post quietly climbed toward the front page of Hacker News — a developer showcased a solution they had hacked together: reverse-engineering arbitrary web apps into tools that agents can call directly. Less than a day after posting, the comments section had already filled with dozens of discussions. Some people praised it, some questioned the legal risks, and others shared similar projects of their own to compare implementation approaches.

The idea itself isn’t entirely new. Over the past year, after MCP (Model Context Protocol) exploded in popularity, the industry has been trying to solve the same problem: if LLMs are going to do real work, they need tools; but the overwhelming majority of software in the world was never designed with agent interfaces in mind. Official APIs either don’t exist, are too expensive, or expose only limited functionality. Anthropic is pushing MCP, OpenAI is pushing Function Calling, and Google is pushing Gemini Extensions — the protocol-layer battle is lively, but the expansion speed of actual usable agent tools is still far behind the growth of model capabilities.

The answer proposed by this Show HN project is blunt and direct: if a website won’t give me an API, I’ll turn the website itself into an API.

Architecture diagram of an Agent invoking a Web App through browser automation

Neither Browser Use nor a Playwright Script

People familiar with this space might roll their eyes at this point: Browser Use, Skyvern, Anthropic’s Computer Use — there are already plenty of projects like this. Why did this one catch fire?

The difference lies in the phrase “reverse engineering.”

Mainstream browser-agent solutions generally rely on having the LLM observe the screen and click buttons in real time — every invocation requires the model to “understand” the page all over again, identify elements, plan actions, and handle exceptions. Slow, expensive, and unreliable are common problems. A GPT-4-level model completing a flight-booking flow can easily consume tens of thousands of tokens while still hovering around a 60% success rate.

This project flips the approach around: instead of reasoning from scratch every time, it first spends time solidifying the key interaction paths of a target website and abstracting them into deterministic CLI commands or function signatures. During execution, the agent no longer needs to “operate by looking at the screen,” but instead passes parameters and receives results like calling a normal API. In the author’s own words, the goal is to “distill websites into tools, rather than making agents reason from zero every time.”

For example, suppose you want an agent to search products on an e-commerce website that has no public API. With a traditional Browser Use approach, the call might look like this:

agent.run("Open example.com, type 'mechanical keyboard' into the search box, click search, and return the titles and prices of the first 10 results")

The model has to evaluate the current page state at every step. After reverse engineering, the same functionality becomes:

search_products(site="example.com", query="mechanical keyboard", limit=10)

All the selectors, waiting logic, pagination handling, and anti-bot workarounds are encapsulated inside the tool itself. The agent only needs to “figure out what to search for.”

That’s the part Hacker News commenters found exciting: this abstraction effectively turns the Web into a first-class resource on the same level as SQL and REST APIs.

In the Same Lane as WebCLI and OpenCLI

Looking through related projects from recent weeks, you’ll notice that multiple teams have independently arrived at very similar ideas.

A few weeks ago, another Show HN project called WebCLI promoted the slogan “make the web browser just another agent skill,” treating the browser itself as a mounted capability for agents. OpenCLI, built by Chinese developers, goes even further, positioning itself as a way to “transform websites, browser sessions, Electron apps, and local tools into deterministic CLI interfaces,” serving both human users and AI agents.

The implementations differ, but the abstraction layers are strikingly consistent:

Bottom layer: browser automation (Playwright, CDP, or custom-built engines)
Middle layer: packaging interaction sequences into named functions with stable input/output contracts
Top layer: exposing them to agents as MCP Servers, OpenAI Functions, or standard CLIs

I’m optimistic about this model for a simple reason: it locks uncertainty inside the encapsulation layer. LLMs are best at planning and natural-language understanding, and worst at repeatedly clicking a button that keeps changing with every website redesign. Handing volatile parts to dedicated tool wrappers while letting models focus on reasoning aligns naturally with engineering intuition.

Comparison between traditional Browser Agents and reverse-engineered tool-based approaches

But Can This Path Actually Work?

No matter how much hype there is, Hacker News commenters still raised several sharp questions.

First: anti-bot systems. Platforms like Taobao, Instagram, and LinkedIn have escalated their defenses against automation into something resembling an arms race. Fingerprint detection, behavioral analysis, rotating CAPTCHAs — once the full stack of defenses comes online, nobody knows how long scripts can survive. The author admitted in the comments that the current project is better suited for small- and medium-sized sites with lower resistance levels; top-tier platforms would require dedicated bypass engineering.

Second: maintenance costs. Every website redesign can potentially break the tool. The author demonstrated a “self-healing” mechanism — using LLMs to run periodic tests and automatically infer new selectors when failures are detected — but that mechanism itself consumes compute resources and still struggles against major structural redesigns.

Third: legal boundaries. Reverse-engineering a web app for agent use is still fundamentally automated access. Terms of Service, the CFAA, DMCA, GDPR — any one of these could become a legal threat hanging overhead. Some commenters cited the hiQ v. LinkedIn case, but the practical applicability of that ruling is actually quite limited.

Fourth: the relationship with the MCP ecosystem. One particularly pointed question asked: if MCP is already promoting standardized tool protocols, why not just wait for major companies to release MCP Servers themselves? The author’s response was straightforward — waiting isn’t practical. There are tens of millions of websites globally, while the official MCP directory still contains fewer than 500 entries. Expecting every SaaS vendor to voluntarily join the ecosystem is unrealistic. Reverse engineering is a bottom-up patchwork solution; MCP is a top-down idealized solution. The two will coexist for a long time.

The “Last Mile” of the Agent Tool Ecosystem

Stepping back for a broader view, the popularity of projects like this reflects a larger trend: in 2026, the bottleneck for agents is no longer the models themselves, but tool availability.

New-generation models like GPT-5, Claude 4.5, and Gemini 2.5 are already highly capable in reasoning and tool use, with function-calling accuracy rates commonly exceeding 90%. But no matter how capable a planning brain is, if it can only access one hundred tools, its ceiling is constrained by the size of that tool pool.

That’s why projects centered around “agent infrastructure” have exploded recently — from the MCP ecosystem to reverse-engineered tool abstraction, from browser automation to the revival of RPA. At their core, they are all solving the same problem: enabling agents to interact with real-world software systems in low-cost, composable ways.

For developers, there are two signals worth paying attention to:

Tool encapsulation itself will become a business. Just as API gateways and iPaaS platforms emerged alongside the SaaS ecosystem, the hosting, marketplaces, and certification layers for agent tools will give rise to a new generation of middleware companies.
Pressure in model selection will shift downstream. Once agents frequently invoke tools and handle long-chain tasks, cost, latency, and concurrency become more important than peak intelligence in a single response. Multi-model orchestration will become the norm — cheap, fast models for tool coordination; expensive models for critical decisions. That’s also why aggregation platforms like OpenAI Hub have recently seen rapid growth: one key provides access to GPT, Claude, Gemini, and DeepSeek with direct domestic connectivity, eliminating the need to maintain piles of API keys and networking infrastructure for multi-model routing inside agents.

A Personal Take

I remain cautious about whether this specific Show HN project can grow into a major business. The technical approach isn’t proprietary, the business model is still unclear, and anti-bot systems plus legal risks are difficult challenges.

But the direction itself is valid. Agents are not going to wait until the entire world publishes APIs before they start working. Someone is inevitably going to make reverse-engineering the web work at scale. The real question is not whether this should be done, but who can simultaneously solve stability, coverage, and compliance. That spot is still open, there are plenty of players, and the market structure is far from settled.

The next milestone worth watching is which of these projects manages to establish a sustainable business model first. That’s when the conversation gets even more interesting.