Show HN：通过逆向工程将Web应用转化为代理工具

Hacker News Top 工具
reverse-engineering browser-agent api-tools agent-tools mcp-server web-apps

摘要

一个基于浏览器的代理，能够逆向工程Web应用API，自动生成代理工具，实现无需修改代码的深度集成。

大家好！我们构建了一个基于浏览器的代理，它运行在经过身份验证的Web应用内部，观察应用如何调用自身的API，并自动将其转化为代理工具。你可以把它想象成一个自动生成的MCP服务器，随着宿主应用的变化而自我更新。<p>结果就是一个熟练的AI助手，能够以最少的精力真正深度集成任何产品（不仅仅是聊天和RAG）。<p>下面是一些简短的演示，展示了该代理在你可能熟悉的软件中的运行情况：<p>- Jira: <a href="https:&#x2F;&#x2F;demo.frigade.com&#x2F;hn?skill=jira">https:&#x2F;&#x2F;demo.frigade.com&#x2F;hn?skill=jira</a><p>- Spotify: <a href="https:&#x2F;&#x2F;demo.frigade.com&#x2F;hn?skill=spotify">https:&#x2F;&#x2F;demo.frigade.com&#x2F;hn?skill=spotify</a><p>- Hacker News (lol): <a href="https:&#x2F;&#x2F;demo.frigade.com&#x2F;hn?skill=hackernews">https:&#x2F;&#x2F;demo.frigade.com&#x2F;hn?skill=hackernews</a><p>- 完整演示: <a href="https:&#x2F;&#x2F;demo.frigade.com&#x2F;hn?skill=full-demo">https:&#x2F;&#x2F;demo.frigade.com&#x2F;hn?skill=full-demo</a><p>正如你在示例中所见，你可以做的比平时点按操作更多（也更快）。而且我们从未触及这些产品的源代码！<p>为什么要这么做？<p>在理想的世界里，每个应用都有一个MCP服务器或易于消化的API供AI代理使用。但实际上，我们发现即便是非常现代的软件也往往有一张由混乱的API和服务组成的蛛网，AI代理无法直接使用。安全性也成为一个大问题，因为不同的应用有不同的（通常是自制的）端点安全标准（JWTs&#x2F;cookies&#x2F;两者的混合）。最后，让一个实际的浏览器代理进入并代表用户使用应用（即计算机使用），实在太脆弱、太慢，而且消耗大量令牌。<p>我们利用现有的已经训练好的浏览器代理——它已经学会了如何使用和了解经过身份验证的应用——并增加了一个额外步骤，将应用的认证API自动转化为“配方”。一个配方包含以下内容：<p>- API端点 + 方法<p>- 认证方法（以及如何获取刷新认证令牌&#x2F;cookies）<p>- 响应模式<p>- 输入模式（用于POST&#x2F;PUT）<p>- 工具功能的人类可读描述<p>综合起来，这些就成为LLM的可复用工具，无需编写或维护任何代码。即使API发生变化，我们的代理也能找出变化，并用更新后的版本替换工具的配方。<p>通过这种方式，为AI代理添加工具变得超级简单：<p>- 我们的代理在应用上进行训练并构建配方<p>- 应用所有者从我们的仪表板启用已发现的工具<p>- 代理现在可以直接在应用内部代表用户执行操作。例如，说出像“邀请我的队友加入我的工作区”这样的指令，就会安全地调用现有的用于邀请用户的API端点，而无需通过第三方代理或中继。<p>当然，尝试这样做时你会遇到大量的边界情况——每个应用本质上是不同的，尽管存在许多“标准”。有趣的事实：graphql是标准化配方时最难以处理的API。<p>期待您的反馈和评论！
查看原文
查看缓存全文

缓存时间: 2026/07/09 16:37

# Show HN：将 Web 应用逆向工程为智能体工具 来源：https://news.ycombinator.com/item?id=48847834 大家好！我们构建了一个基于浏览器的智能体，它可以运行在已认证的 Web 应用内部，观察应用如何调用自身的 API，并自动将这些调用转换为智能体工具。你可以把它看作一个自动生成的 MCP 服务器，当宿主应用发生变化时，它会自我更新。 最终成果是一个能力出众的 AI 助手，它能与任何产品深度集成（而不仅仅是聊天和 RAG），几乎不需额外工作。 下面是一些简短的演示，展示了这个智能体在大家可能熟悉的软件中的工作效果： - Jira：https://demo.frigade.com/hn?skill=jira - Spotify：https://demo.frigade.com/hn?skill=spotify - Hacker News（笑）：https://demo.frigade.com/hn?skill=hackernews - 完整演示：https://demo.frigade.com/hn?skill=full-demo 正如你在示例中看到的，你可以做更多操作（而且速度更快），远超常规的点按操作所能达到的效果。而且我们从未碰过这些产品的源代码！ **为什么要这样做？** 理想情况下，每个应用都会提供一个 MCP 服务器或易于解析的 API，供 AI 智能体使用。但实际上，我们发现即便最现代的软件也往往有一套错综复杂的 API 和服务，AI 智能体根本无法直接使用。安全性也是个巨大问题，因为不同应用对端点（JWT / Cookie / 两者混合）的保护标准各不相同。最后，让一个浏览器智能体代表用户实际进入应用操作（即 computer-use）往往过于脆弱、缓慢，且消耗大量 token。 我们在此基础上做了改进：让已有的、经过训练能够使用和学习已认证应用的浏览器智能体增加一个步骤，自动将应用的已验证 API 转换为“配方”（recipe）。一个配方包含以下内容： - API 端点 + 方法 - 认证方式（以及如何获取刷新令牌 / Cookie） - 响应 Schema - 输入 Schema（用于 POST / PUT） - 工具的人可读描述 将这些组合起来，就成为了 LLM 可复用的工具，完全不需要编写或维护任何代码。即使 API 发生变化，我们的智能体也会识别并自动将对应的工具配方更新为最新版本。 这样一来，为 AI 智能体添加工具变得极其简单： - 我们的智能体在应用上训练，构建配方 - 应用所有者通过我们的仪表盘启用已发现的工具 - 智能体现在可以直接在应用内部代表用户执行操作。例如，说一句“邀请我的同事加入工作区”，就能安全地调用现有的邀请用户 API 端点，无需通过第三方代理或转发。 当然，尝试这样做时会遇到大量边界情况——尽管存在许多“标准”，但每个应用本质上都是不同的。有趣的发现：GraphQL 在标准化配方时是最难处理的 API。 期待大家的反馈和评论！

相似文章