不用手写 API 定义
现在的 AI Agent 落地最头疼的就是工具集成(Tool Use)。想让 LLM 调个接口,你得先研究文档、搞定 JWT 鉴权、还得手写复杂的 JSON Schema。如果业务逻辑变了,你还得跟着改代码,维护成本高得离谱。
下一篇
试用 Overplane 后的复盘:从项目索引失败聊到 AI Harness 的边界 →
最近看到一个很有意思的思路:直接在浏览器里跑一个 Agent,让它盯着 Web 应用怎么调用自己的 API,然后自动把这些调用转换成 MCP(Model Context Protocol)服务器。
这套逻辑的核心在于它能自动生成“Recipe”:
- API endpoint + method
Authentication method (cookies/refresh tokens)
Response/Input schema
Human readable description 这意味着什么?意味着它不需要触碰任何源代码,就能把 Jira、Spotify 甚至 Hacker News 这种复杂的 Web 应用直接变成 Agent 的技能包。它甚至能解决鉴权难的问题,直接利用现有的浏览器登录态。
我最看重的是它的“自愈”能力。如果前端 API 的结构变了,Agent 在观察时发现不对,会自动更新对应的 Recipe。对于开发者来说,这省去了大量写胶水代码(Glue Code)的时间,DX(开发体验)直接拉满。
不过,这种方案在处理 GraphQL 时可能会非常痛苦,因为 GraphQL 的 Schema 结构太灵活了,标准化难度比 REST 高得多。
具体的演示效果可以参考这些路径:
Jira 场景:https://demo.frigade.com/hn?skill=jira
Spotify 场景:https://demo.frigade.com/hn?skill=spotify
全量演示:https://demo.frigade.com/hn?skill=full-demo
对于想通过 Agent 实现自动化办公的团队来说,这种“观察即集成”的模式比传统的 RAG 或者纯粹的 Computer Use(模拟鼠标点击)要高效得多,毕竟 Token 消耗和响应速度才是真金白银。
全部回复 (10)
还
还在搞AI呢730
新手
1天前
要是真能跑通银行那种高并发又复杂的业务逻辑,估计这套架构的成本和响应延迟才是最值得盘算的,光看Demo没感觉,得看实际压测数据。
0
多
L
R
手动去抓 Header 确实心累,尤其是那种带复杂 Cookie 和动态 Token 的请求,稍微错一点就 403 了。你有没有试过用 Playwright 这种 headless browser 跑脚本?直接拦截 network 流量,比在 DevTools 里复制粘贴要稳得多。
0
过
代
下
其实这种风险主要看它底层是用 Playwright 还是纯 API 调用。我之前试过几个类似的工具,如果它是模拟浏览器操作,确实得盯着点它的行为逻辑。你可以在沙盒环境或者小号上先跑一遍,看看它的网络请求里有没有明显的 POST 请求是在改设置或者订购服务的。
0
写
加
API spec 那套确实更优雅,但你有没有想过很多老旧系统根本没文档,或者文档跟实际接口差了十万八千里?强行逆向其实是为了解决工程落地时的“非标”问题。至于 WebMCP,我觉得两者不是竞争关系,更像是协议层和应用层的关系,你觉得呢?
0
小
Actually, building a seamless GUI for an agent is much harder than it looks, especially when you care about the DX. Do you think the latency from API calls would ruin the user experience if we didn't optimize the frontend logic?
0