把网站反向工程成 Agent 工具，这个 Show HN 项目火了

当 Agent 想用一个没有 API 的网站，它该怎么办？

7 月 8 日，Hacker News 首页上一条 Show HN 帖子悄悄爬到了前排——一位开发者晒出了自己捣鼓的方案：把任意 Web App 反向工程成 Agent 可以直接调用的工具。帖子发出不到一天，评论区已经堆了几十条讨论，有人叫好，有人质疑法律风险，也有人贴出自己类似的项目开始互相比较实现路径。

这个思路本身不算全新。过去一年 MCP（Model Context Protocol）大热之后，业界都在解决同一个问题：LLM 想干活，得有工具；但世界上绝大多数软件没有为 Agent 准备好接口。官方 API 要么不存在，要么收费贵，要么功能阉割。Anthropic 在推 MCP，OpenAI 在推 Function Calling，Google 在推 Gemini Extensions——协议层的仗打得热闹，但真正能让 Agent 用的工具池，扩张速度远远跟不上模型能力的增长。

这个 Show HN 项目给出的答案粗暴而直接：既然网站不给我 API，我就把网站本身变成 API。

不是 Browser Use，也不是 Playwright 脚本

看到这里熟悉这个赛道的人可能会撇嘴：Browser Use、Skyvern、Anthropic 的 Computer Use，这类项目一抓一把，凭什么这个火了？

差异在“反向工程”这四个字上。

主流的浏览器 Agent 方案，走的是让 LLM 实时看屏幕、点按钮的路线——每次调用都要重新“认识”一遍页面，识别元素、规划动作、处理异常。慢、贵、不稳定是通病。GPT-4 级别的模型完成一个订机票流程，动辄消耗几万 token，成功率还在 60% 上下打转。

这个项目的做法反过来：先花时间把目标网站的关键交互路径固化下来，抽象成确定性的 CLI 命令或函数签名，Agent 调用时不再需要“看图操作”，而是像调普通 API 一样传参、拿结果。用作者自己的话说，是“把网站蒸馏成工具，而不是让 Agent 每次都从零推理”。

举个例子。假设要让 Agent 调用某个没有开放 API 的电商网站搜索商品，传统 Browser Use 方案的调用大概长这样：

agent.run("打开 example.com，在搜索框输入'机械键盘'，点击搜索，把前 10 个结果的标题和价格返回给我")

模型每一步都要判断当前页面状态。而反向工程后，同样的功能变成：

search_products(site="example.com", query="机械键盘", limit=10)

背后的选择器、等待逻辑、分页处理、反爬绕过全部在工具封装里搞定，Agent 只负责“想清楚要搜什么”。

这就是 Hacker News 上那批评论者兴奋的点：这套抽象让 Web 成为了和 SQL、REST API 同级的一等资源。

和 WebCLI、OpenCLI 是一条赛道

翻一下最近的相关项目，会发现同样的思路在多个团队手里独立冒头。

几周前另一个 Show HN 项目 WebCLI 主打的口号是“make the web browser just another agent skill”，把浏览器整体作为 Agent 的一项技能挂载进去。国内开发者做的 OpenCLI 走得更远，定位是“将网站、浏览器会话、Electron 应用和本地工具转化为确定性 CLI 接口”，同时面向人类用户和 AI Agent 双端服务。

三个项目的具体实现有差异，但抽象层级惊人一致：

• 底层：浏览器自动化（Playwright、CDP、或自研内核）
• 中间层：把交互序列打包成命名函数，暴露稳定的输入输出契约
• 上层：以 MCP Server、OpenAI Function、或标准 CLI 三种形态之一供 Agent 消费

这个模式我个人是看好的。原因很简单：它把不确定性锁在了封装层内部。LLM 最擅长做规划和自然语言理解，最不擅长的就是稳定重复地点击一个总在改版的按钮。把易变的部分交给专门维护的工具封装，把稳定的部分交给模型推理，是符合工程直觉的分工。

但这条路真的走得通吗？

吹得再热闹，Hacker News 评论区还是几个尖锐问题：

第一，反爬。 淘宝、Instagram、LinkedIn 这类平台对自动化行为的对抗强度已经到了军备竞赛级别，指纹检测、行为分析、验证码轮换一套组合拳打下来，脚本能撑多久是个未知数。作者在评论里承认，目前项目更适合处理中小型、对抗强度较低的站点，头部平台需要投入专门的绕过工程。

第二，维护成本。 网站改版一次，工具就可能失效一次。作者展示了一套“自愈”机制——用 LLM 定期跑测试，检测到失败后自动重新推断新的选择器——但这套机制本身也会消耗算力，并且在结构性改版面前无能为力。

第三，法律边界。 反向工程一个 Web App 供 Agent 调用，本质上仍是自动化访问。ToS 条款、CFAA、DMCA、GDPR，每一条都可能成为悬在头上的剑。评论区有人拿 hiQ v. LinkedIn 案说事，但那个案子的适用范围其实相当有限。

第四，和 MCP 生态的关系。 有个提问很扎心：既然 MCP 已经在推标准化的工具协议，为什么不等大厂自己发 MCP Server？作者的回复也很实在——等不起。全球有几千万个网站，MCP 官方目录里连 500 个都不到，指望每一个 SaaS 厂商都主动上车不现实。反向工程是自下而上的补丁方案，MCP 是自上而下的理想方案，两者会长期共存。

Agent 工具生态的“最后一公里”

把视角拉远一点看，这类项目的走红反映的是一个更大的趋势：2026 年，Agent 的瓶颈已经不在模型，而在工具供给。

GPT-5、Claude 4.5 系列、Gemini 2.5 这些新一代模型在推理和 tool use 上都做得相当扎实，函数调用准确率普遍能到 90% 以上。但一个能规划的大脑，如果只能操作一百个工具，能力上限就是被工具池锁死的。

这也是为什么最近围绕“Agent 基础设施”的项目集中爆发——从 MCP 生态到反向工程工具化，从浏览器自动化到 RPA 复兴，本质上都是在同一件事上发力：让 Agent 能够以低成本、可组合的方式接触到真实世界的软件系统。

对开发者来说，值得关注的信号有两个：

1. 工具封装本身会成为一门生意。就像早期的 API 网关、iPaaS 之于 SaaS 生态，Agent 工具的托管、市场、认证会孕育新一批中间层公司。
2. 模型选择上的压力会向下游转移。当 Agent 需要频繁调用工具、处理长链路任务时，成本、延迟、并发能力的重要性会超过单次响应的极限智能。多模型混合调度会是常态——用便宜快的模型做工具编排，用贵的模型做关键决策。这也是为什么 OpenAI Hub 这类聚合平台最近用量涨得快，一个 Key 打通 GPT、Claude、Gemini、DeepSeek，国内直连，Agent 里做多模型路由不用再自己维护一堆密钥和网络。

一点判断

这个 Show HN 项目本身能不能长成大生意，我持观望态度——技术方案不算独家，商业模式还不清晰，反爬和法律风险都是硬骨头。

但它代表的方向没错。Agent 不会等到全世界都发好 API 才开始工作，反向工程 Web 的路径必然会有人走通。真正的问题不是要不要做，而是谁能把稳定性、覆盖度、合规性三件事同时做扎实。这个位置目前空着，玩家足够多，格局远未定。

下一个值得跟的节点，是看这批项目里哪个先跑出可持续的商业模型。到时候再聊。

---

参考来源

• Show HN: Reverse-engineering web apps into agent tools — Hacker News 原帖及讨论
• WebCLI – make the web browser just another agent skill — 同赛道项目 WebCLI 的 GitHub 仓库
• 把任意网站变成零成本 CLI 工具的 AI Agent 基础设施 — 掘金上关于 OpenCLI 项目的深度介绍