Manifest

Hey Product Hunt 👋

我是Max，Manifest（Omfang AB）的独立创始人。

我做这个是因为每当我试图让 AI 智能体可靠地与网页交互时，最终都得手写选择器，而一旦网站 DOM 发生变化，这些选择器就失效了。浏览器自动化工具解决的是“给我一个浏览器”，内容提取工具解决的是“给我内容”——但没有任何工具解决“告诉我哪些是可点击、可填写、可提交的，以及这些操作之间的依赖关系”。

这就是 Manifest 做的事情：一个 API 调用就能返回任意网页的结构化 JSON action manifest，包含解析后的定位器和编码跨操作依赖的 requires 字段（例如，这个提交按钮需要先填写那个字段）。

目前已作为 REST API、Python SDK、LangChain 集成和 MCP 服务器上线。你可以无需注册在这里试用：demo.manifest.omfang.io/demo

我是独自开发这个项目，还没收入，所以真心希望得到反馈，特别是那些也在构建浏览器智能体、遇到过同样选择器脆弱性问题的人。
对于你正在做的事情，怎样才能让这个工具变得有用？

@max_nordstrom — 你提出浏览器自动化给你“一个浏览器”，提取给你“内容”，但没人给智能体提供可供性层——哪些可点击/可填写以及顺序——这正是我反复遇到的缺口。

我花了很多时间在结账流程中手写选择器，结果商家一改 DOM 就全崩了，所以一个用 requires 图编码“先填这个才能点提交”的基元正是我一直希望存在的东西。

有一点我没看到提到：既然 manifest 来自服务端 Playwright 的一次运行，那它在有反爬保护的网站上表现如何？我在意的很多结账页面都在 Cloudflare/Akamai/HUMAN 后面，无头提取正是它们通常会拦截的——Manifest 在那里还能拿到清晰的映射吗？还是说这目前超出了它能触及的范围？

无论如何，很高兴看到你在这里的回复坦率地指出了静态推理 vs 驱动页面的区别。👌

我喜欢 action-manifest 这个思路，因为智能体的脆弱点通常不是读取页面，而是知道哪些点击和字段是安全的。好奇你怎么处理登录后或 A/B 测试后变化的页面——manifest 会过期还是重新验证？

requires 字段编码元素之间的依赖关系是最有意思的部分——“先选择一个套餐这个按钮才能点击”正是无障碍树会遗漏的信息，也是大多数浏览器智能体浪费重试次数的地方。问题：你怎么处理漂移？如果网站重新设计，manifest 是每次调用都重新生成（总是新鲜但付出延迟代价），还是使用带有某种失效启发式缓存的缓存？这个取舍决定了我是否会在定时任务中信任它。

@max_nordstrom 这是非常诚实的回答，大多数工具会悄悄声称自己处理所有情况。disabled/aria-disabled 推断作为实用的 v1 范围是合理的。对于异步 JS 验证的缺口，在 requires 字段上加一个轻量级 'confidence' 标记是否可行——哪怕是一个粗略的信号，告诉智能体“这个依赖是从静态 DOM 推断出来的，依赖它之前请先验证” vs “这是一个硬性的 disabled 属性”——还是说这只会把复杂度转嫁给调用方，并没有真正帮助？

我花了很多时间看着智能体在网页上瞎猜乱撞，简直一团糟，所以这个工具正好解决了我的痛处。这个用来编码依赖关系的 requires 字段，真是绝了。不过，这些信息是由谁先发布的呢？是网站所有者，还是那些在其他人的页面上运行智能体的开发者？感觉像是个先有鸡还是先有蛋的问题。