Pomerado：把任意网站变成Agent可调用的API

当浏览器自动化遇上MCP：Pomerado在解决什么问题

让AI Agent去操作网页，这件事听起来很美好，实际做起来却常常令人沮丧。传统的浏览器自动化方案要么依赖脆弱的DOM选择器，要么受限于反爬机制，一旦目标网站改版或加强风控，整条自动化链路就可能崩溃。

Product Hunt上排名第5的Pomerado，试图用另一种思路绕开这些麻烦：与其让Agent在浏览器里"点击"网页，不如直接把网站转换成MCP（Model Context Protocol）工具或原生API，让Agent像调用本地函数一样访问外部服务。用他们自己的话说，就是把Google Flights、Zillow、Instacart乃至各类legacy portal这类"此前无法接入"的网站，变成Agent的原生工具。

这个定位切中了一个真实痛点——Agent的能力边界，很大程度上取决于它能触达多少外部服务。

MCP（Model Context Protocol）由Anthropic于2024年底推出，是一套开放协议，用于规范大语言模型与外部工具、数据源之间的交互方式。在此之前，Agent接入外部服务通常需要为每个工具编写定制的function calling逻辑，格式各异、复用性差。MCP通过定义统一的上下文描述、工具调用和资源获取接口，让同一套Agent框架可以即插即用不同的工具服务。业界常将其类比为"AI应用层的USB-C接口"。Pomerado选择输出MCP工具而非私有API格式，意味着它能直接接入Claude Desktop、Cursor等已支持MCP的客户端，省去适配成本。

核心机制：构建、托管、认证、维护，一站式包办

Pomerado强调的是一套完整的集成生命周期管理，而不仅仅是一个转换工具。

按其描述，这个开源工具负责四个环节：构建（将目标网站转为API/MCP）、托管（运行这些集成）、认证（处理登录与凭证）以及维护（应对网站变化）。这意味着开发者不必自己搭建爬虫基础设施，也不必持续跟踪目标站点的结构变更。

对于依赖外部数据源的Agent应用来说，"维护"这一环往往是最耗人力也最容易被低估的隐性成本。网站改版、接口变更、验证码升级，每一项都可能让自动化流程失效。Pomerado把这部分工作纳入工具本身的职责范围，算是抓住了长期运营的真实需求。

MCP作为Anthropic推动的开放协议，正在成为Agent与外部工具对接的事实标准之一。Pomerado选择MCP作为主要输出格式，说明它瞄准的是当前Agent生态的主流接入方式，而不是另起炉灶造一套私有协议。

更快的浏览器使用：绕开选择器地狱

产品口号里另半句是"Faster & reliable browser use"。这暗示Pomerado的底层执行并不完全抛弃浏览器，而是试图在可靠性与速度之间找到更优解。

传统方案的慢，往往慢在"模拟人"这件事上——等待元素加载、重试点击、处理弹窗，每一步都在消耗时间。而把网站抽象成API后，调用方只需要关心输入输出，底层的浏览器交互被封装隐藏。这种分层设计让Agent的调用逻辑更干净，也让失败重试更有章可循。

当然，这里有一个需要客观看待的边界：把网站转成API，本质上仍是程序化访问目标网站。目标站点的服务条款、反自动化策略、数据合规要求，依然是绕不开的前提。Pomerado的存在并不改变这些约束，只是降低了技术实现的摩擦。

DOM选择器是浏览器自动化的核心机制，脚本通过CSS选择器或XPath定位页面元素（如按钮、输入框）并触发操作。问题在于，选择器高度依赖页面结构，一旦前端改版、类名变动或元素层级调整，原有选择器就会失效，导致整个流程崩溃——这就是社区常说的"选择器地狱"。此外，现代网站大量使用React、Vue等框架动态渲染，元素出现时机不确定，需要额外的等待和重试逻辑。Pomerado的思路是让底层程序承担这些不稳定性，对上层Agent只暴露稳定的API语义，从而把脆弱性封装在维护方一侧。

谁最该关注这个工具

从定位看，Pomerado的理想用户是那些正在构建Agent应用、但苦于没有稳定外部数据接入渠道的开发者。典型场景包括差旅比价、房产信息聚合、生鲜电商下单等需要通过既有网站而非官方API获取数据的任务。

对于已经用MCP搭建Agent工作流的团队，Pomerado提供的是一层现成的连接器基础设施；对于还在用脚本硬编码爬取逻辑的团队，它则是一次架构升级的机会。

目前该项目在Product Hunt获得120票、10条评论，社区反馈体量不算大，实际稳定性与维护效果仍需更多真实使用场景来验证。开源的属性让开发者可以先小范围试用，评估它是否真的能扛住目标网站的长期变化。

Product Hunt的排名与投票反映的是产品发布当日的社区热度，而非长期市场表现。120票属于中等偏下的量级，说明Pomerado尚未引起大规模关注，样本量有限，评论也多集中于概念层面而非实测数据。评估此类工具时，更值得关注的是GitHub上的issue响应速度、目标网站的适配成功率，以及是否有公开的稳定性指标。对于生产环境使用，建议先选取一两个非关键目标网站进行数周的灰度验证，观察维护频率和失败恢复能力，再决定是否纳入核心链路。

点评：概念清晰，成败在维护

Pomerado的思路是把"不可控的浏览器操作"转换成"可控的API调用"，这个抽象层次的提升符合Agent工具化的大方向。它把集成生命周期打包成服务的做法，也确实回应了开发者的懒人需求。

但真正的考验不在构建环节，而在维护。网站转API这个命题，从来不缺能跑通demo的方案，缺的是能在数月后依然稳定工作的系统。Pomerado如果真能把"maintains your integrations"这句话兑现，它的价值就远不止于一个转换工具。