商业产业 Hacker News AI 2026-07-09T15:45 正文 ok 473 words

🔶 Show HN:将 Web 应用逆向工程为代理工具

英文标题:🔶 Show HN: Reverse-engineering web apps into agent tools

Frigade 推出了一款基于浏览器的代理,可运行在已认证的 Web 应用中,自动观察应用如何调用自身 API,并将其转化为可复用的 LLM 工具“配方”。该方案无需编写或维护代码,即使应用 API 发生变化也能自动更新,解决了传统 API 混乱、安全标准不一及浏览器代理方式脆弱且成本高的问题。这为开发者快速为 AI 代理添加深度集成任何产品的能力提供了新路径,有望降低构建代理技能的门槛。
打开原文相关 3 · 机会 2
media315 B media43 B

中文

Hey HN!我们构建了一个基于浏览器的代理,它运行在已认证的 Web 应用内部,观察应用如何调用自己的 API,并自动将这些 API 转换为代理工具。你可以把它想象成一个自动生成的 MCP 服务器,能随着宿主应用的变化而自我更新。

最终得到的是一个能够以最少精力与任何产品深度集成的熟练 AI 助手(不仅仅是聊天和 RAG)。

请查看下面的简短演示,展示代理在你可能熟悉的软件中的表现:

正如示例所示,你可以做到比通常通过点击操作更多(且更快)的事情,而且我们完全没碰这些产品的源代码!

为什么要这样做?

在理想世界中,每个应用都拥有 MCP 服务器或易于 AI 代理使用的 API。但在实践中,我们发现即使是相当现代的软件,也往往有着蜘蛛网般令人困惑的 API 和服务,AI 代理无法直接开箱即用。安全也成为一个大问题,因为不同的应用有不同的(通常是自制的)端点安全标准(JWT / Cookie / 两者的混合)。最后,让一个实际的浏览器代理进入应用并代表用户操作(即计算机使用),这种方式过于脆弱、缓慢,且会消耗大量 token。

我们利用已有的浏览器代理(它已经训练好能够使用和学习已认证应用),并增加了一个额外的步骤,自动将应用的认证 API 转化为“配方”。一个配方包含以下内容的组合:

  • API 端点 + 方法

  • 认证方法(以及如何获取刷新的认证 token / Cookie)

  • 响应结构

  • 输入结构(针对 POST / PUT 请求)

  • 该工具功能的人类可读描述

综合起来,这些就变成了可供 LLM 复用的工具,完全无需编写或维护任何代码。即使 API 发生变化,我们的代理也能发现并用更新后的版本替换该工具的配方。

通过这种方式,为 AI 代理添加工具变得超级简单:

  • 我们的代理在应用上进行训练并构建配方

  • 应用所有者从我们的仪表板启用已发现的工具

  • 代理现在可以直接在应用内部代表用户执行操作。例如,说一句“将我的队友邀请到我的工作区”,就会安全地调用现有的邀请用户的 API 端点,而无需通过第三方进行代理或中继。

当然,当你尝试这样做时会遇到大量边界情况——尽管“标准”很多,但每个应用本质上都不同。有趣的事实:GraphQL 远不是在标准化配方中最难处理的 API。

期待你的反馈/评论!

English / 原文

Hey HN! We built a browser-based agent that runs inside an authenticated web app, watches how the app calls its own APIs, and automatically turns those into agent tools. You can think of it as an auto-generated MCP server that self-updates as the host app changes.

The result is a skilled AI assistant that actually integrates deeply with any product (not just chat and RAG) with minimal effort.

Check out these short demos below that show the agent in software you're probably familiar with:

- Jira: https://demo.frigade.com/hn?skill=jira

- Spotify: https://demo.frigade.com/hn?skill=spotify

- Hacker News (lol): https://demo.frigade.com/hn?skill=hackernews

- Full Demo: https://demo.frigade.com/hn?skill=full-demo

As you can see in the examples, you can do way more (and faster) than what you normally would be able to via point and click. And we never even touched the source code of these products!

Why do this?

In an ideal world, every application has an MCP server or an easily-digestible API available for AI agents to feed from. In practice, we found that even very modern software tends to have a spider web of confusing APIs and services that AI agents simply cannot use out of the box. Security also becomes a huge issue as applications have different (often homebrewed) standards for how endpoints are secured (JWTs/cookies/mix of both). Finally, having an actual browser agent go in and use the application on behalf of the user (i.e. computer-use), is simply too brittle, slow, and burns a lot of tokens.

We took our existing browser agent that’s already trained to use and learn authenticated applications, and added an extra step that automatically turns the app’s authenticated APIs into "recipes". A recipe is a mix of the following:

- API endpoint + method

- Authentication method (and how to retrieve refresh auth tokens/cookies)

- Response schema

- Input schema (for POST/PUT)

- Human readable description of what the tool does

Putting it all together, these become reusable tools for LLMs, all without writing or maintaining any code. Even if the APIs change our agent figures this out and replaces the recipe for the tool with the updated version.

Adding tools to an AI agent becomes super simple this way:

- Our agent trains on the app and builds the recipes

- The app owner enables discovered tools from our dashboard

- The agent can now take actions on the user’s behalf directly inside the application. For instance, saying something like "invite my teammate to my workspace" would securely call the existing API endpoint for inviting users without proxying or relaying through a third party.

Of course, there's a ton of edge cases you run into when you try to do this - every application is intrinsically different despite how many "standards" exist. Fun fact: graphql was by far the worst API to work with in standardizing the recipes.

Looking forward to your feedback/comments!