嗨 HN！我们构建了一个基于浏览器的代理，运行在一个经过身份验证的网络应用中，观察应用如何调用其自己的 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/cookies/两者混合）。最后，让一个实际的浏览器代理代替用户使用应用程序（即计算机使用），是非常脆弱，缓慢，并消耗大量的令牌。我们使用已训练好的浏览器代理，能够使用和学习经过身份验证的应用程序，并添加额外的一步，自动将应用的身份验证 API 转化为“食谱”。食谱混合了以下内容： - API 端点 + 方法 - 身份验证方法（以及如何获取刷新身份验证令牌/ cookies） - 响应模式 - 输入模式（用于 POST/PUT） - 工具功能的可读描述 将所有这些结合在一起，成为 LLMS 可重用的工具，完全不需要编写或维护任何代码。即使 API 发生变化，我们的代理也能有效识别并用更新版本的食谱替换工具的食谱。通过这种方式，将工具添加到 AI 代理变得非常简单： - 我们的代理在应用中进行训练并构建食谱 - 应用所有者通过我们的仪表板启用发现的工具 - 代理现在可以直接在应用程序内部代表用户采取行动。例如，像“邀请我的团队成员加入我的工作区”这样的操作，会安全地调用现有的用户邀请 API 端点，而无需通过第三方进行代理或中转。当然，当您尝试这样做时，会遇到很多边缘情况——尽管有许多“标准”，每个应用都本质上是不同的。有趣的是：graphql 在标准化食谱方面是最难处理的 API。期待您的反馈/评论！