讲解一下这个https://github.com/Pomerado/pomerado

回复 joye： 先说这个项目到底是什么。Pomerado 是 YC F26 的公司，把网站变成 agent 能调用的 MCP 集成，没有 API 的站点也能做。它的核心区别是：不用 HAR、不用录屏，只用一段自然语言描述你要做的任务，它就在真实 Chromium 里自己摸索网站、跑通一遍你的例子里、然后把这次操作泛化成代码，保存到你自己的文件夹里。 流程就四步：explore the site → complete your example → generalize → agent calls it。跑完之后，生成的集成对 agent 来说就是一个独立的 MCP server，里面有一个以集成名命名的工具，输入输出按 pomerado.json 的 schema 走，另外还附带 get_job / provide_input / cancel_job 这三个用于跟进任务状态的工具。 几个关键设计，我觉得是它真正有分量的地方： 一是确定性。生成的集成是代码而非每次都让模型看屏幕点按钮，所以比 computer use 快得多也稳得多。这个取舍很关键：cu 的可靠性问题（点错、等不到元素、页面稍微变动就失败）本质上是“每次都要重新推理”，而 mint 把推理成本一次性付掉，运行时变成纯执行。这是它跟 bu/cu 路线最本质的差别。 二是权限做成了一等公民。mint 时必须显式声明 read 还是 write；声明 write 时，工具会要求 agent 先跟你确认。write 类型的集成在构建过程中只真正执行一次动作，之后就只审查代码、不重放；read 类型如果发现任务其实要改东西，会回头请求升级成 write，由你的 agent 来回答。这个设计针对的是 pa 落地时最实际的风险：给 agent 一个能提交表单的接口，等于给了它破坏力。 三是登录和 2FA 能处理，但边界画得很细。它只在目标站或你通过 authenticationOrigins 显式指定的登录地址上输账号；如果登录表单字段或提交会发往其他站点，输入之前就拒绝；登录页本身在别的站点则不会发布。它明确承认自己不检查页面脚本会把你输入的内容发去哪，这一点文档写得很坦诚。 四是开源切分得比较清楚。MIT 协议，仓库里是完整核心：minter、minting harness 和 prompts、Guardian（构建时逐条审查每个浏览器动作和最终源码）、本地 host，集成本身以源码形式存在你自己的目录里，不需要 Pomerado 账号。商业部分 Pomerado Cloud 才是托管、OAuth brokerage、保存的登录、访问控制、托管浏览器池（过 bot 防护），以及站点改版后自动检测并修复集成。注意 0.1.2 及更早是 AGPL-3.0，现在是 MIT。 五是 Guardian 的策略改编自 OpenAI Codex，无障碍名称计算改编自 Playwright，两个都保留了 Apache 2.0 许可和 notice。 使用上的实际约束也说清楚：需要 macOS 或 Linux、Node 24 以上、一个 OpenAI API key（只有 mint 用，运行集成不调用任何模型，所以跑起来不要 key），客户端得支持本地 MCP server，比如 Claude Code、Codex、Cursor、VS Code、Claude Desktop、Gemini CLI。每个 mint 有 20 分钟有效工作时长，等你回答的时间不算在内。 我的判断： 它的定位很聪明，选的是“长尾网站的接入”这个缺口。MCP 生态现在的问题不在协议，在覆盖：大厂官方 MCP 就那么几个，剩下几十万个你天天用的内部工具、老系统、只提供网页的后台，agent 都够不着。人工写爬虫和维护 selector 是个没人愿意干的脏活，它把这个过程自动化了，还顺手用 Guardian 兜了一层安全审查。 但它和前面 Joye 说的那个“2.6x faster 的 bu 却拿 Codex 的 bu 对比”属于同一类叙事，值得警惕的地方在于 benchmark 语境。确定性执行的快，是相对于“每次都让模型看图点”而言的，不是相对于“网站本来就有 API”。对已经有 API 或官方 MCP 的站点，它没有优势，只是多一层中间物。 真正的问题是失效后的维护成本。一旦站点改版，确定性集成就直接报错，这跟 cu 那种“慢但能自适应”刚好相反：两种方案各自解决一个风险，却各自在另一个风险上更脆弱。开源版的答案是报错让你自己修，Cloud 版才卖自动检测和修复。这基本说明了它的商业模式：卖的是集成的生命周期，而不仅是生成。 所以适合用它的场景是：站点稳定、你高频调用、没有 API、而且你希望调用是可重复而非一次性的。不适合的场景是：一次性任务、或者站点结构天天变又不想上 Cloud。 最后一点给实际动手的人：read/write 一定要分清楚，别为了图方便全开 write。它虽然有 Guardian 和自己的人工审核（mint 时确认 write），但运行时是不检查权限和意图的，而且你对自己 src/ 和 deployment.json 的改动它也不审查。这个安全责任最后还是落在你自己身上。