Rindler 的巧思：先把没有 API 的网站变成可调用地图

Rindler 不是一个把网页截图交给模型再让它猜按钮的浏览器 agent。它面向的是另一类更具体的工作：团队每天登录供应商门户、招聘系统、政府网站或保险平台，查记录、下载文件、填表、更新字段，但这些网站没有 API。用户告诉 Rindler 要访问哪个站点、完成什么工作，登录在真实网站里由用户自己完成，之后 Rindler 返回结构化字段，也可以按日程重复执行。12

这个产品在 2026 年 8 月 7 日的 Product Hunt 日榜排第 4，第三方 AI 开发者资讯站 AICrier 同日也把它概括为「预先映射网站，再执行带认证、可定时、能返回结构化数据的工作流」。34

Rindler 值得拆的地方，不在于它又做了一个能点击网页的 agent，而在于它把「理解网站」从每次任务里拿了出来，变成一层可以维护、可以复用、可以授权的中间对象。

多数浏览器 agent 的运行路径是：打开页面，读 DOM 或截图，猜当前页面是什么，再决定下一步点哪里。每次访问都像重新解一道题。Y Combinator 对 Rindler 的介绍直接把这个问题说得很清楚：浏览器 agent 每次都要重新解释页面、判断点击对象，还要应付弹窗、登录门槛、动态筛选器和布局变化；这会让生产环境里的执行变慢、变贵，也更难让人信任。5

Rindler 的处理顺序相反：先走一遍网站，把它整理成「页面、可用动作、带类型的输出」；任务运行时，agent 不必重新猜整张页面，而是通过远程 MCP 端点调用已经映射出来的动作。官方举的动作包括 search、add_to_cart 和 download_records，结果则以结构化数据返回。5

这不是把网页真的改造成 API，而是给网页加了一层面向 agent 的稳定接口。网页仍然负责登录、筛选、提交和显示结果；Rindler 负责把这些界面状态整理成可调用的动作。用户可以说「检查所有未完成订单，并返回供应商、状态和交付日期」，而不是要求模型在每一次运行里重新寻找订单页、过滤器和表格列。Rindler 官网展示的运行记录也沿用了这个思路：步骤、页面、点击和提取出的行都被保留下来，最后以「5 steps · 0 failed」这样的执行结果收束。1

这套设计解决的不是「模型不会点按钮」，而是把一次性的网站认知成本和每次任务的业务意图分开了。前者只需要在网站发生变化时更新，后者可以不断变化：今天查订单，明天下载对账单，后天跨多个客户账号拉取同一组字段。Rindler 的用例页明确把「同一个平台的多个账号用一次设置覆盖」列为一种工作方式，并强调每次运行返回相同形状的字段，而不是截图或需要人工复制的页面。2

代价也正好在这里。映射不是免费的魔法：Y Combinator 的介绍承认，有些网站能顺利映射，有些需要更深入的处理；有登录或反自动化防护的网站，还可能需要一次性的凭证或 Cookie 捕获。5 Rindler 官网把维护责任放在自己一侧：页面变化导致流程中断时，由平台集中修复，一次修复覆盖同一网站上的用户，而不是让每个团队自己提交工单。16

所以这里真正的产品选择是：不追求每个网站都能即时执行，而是先把一部分网站变成可长期维护的基础设施。 这会牺牲「输入任意网址、立刻得到结果」的即时性，却换来重复任务里的稳定路径和固定输出。对需要把 agent 接进生产流程的团队，这个交换通常比一次成功的浏览器演示更有价值。

网页自动化最容易被忽略的不是能不能完成任务，而是「完成任务」包含哪些不可逆动作。下载一份公开账单、修改供应商银行信息、提交一张表单、下一个订单，不能共享同一个模糊的「允许访问此网站」开关。

Rindler 把权限写成网站与动作的组合。官网演示的控制项分别对应「读取页面并提取信息」「下载文件」「发送消息、邮件或帖子」「提交表单」「支付或下单」「修改付款或账单信息」；每个动作都可以设置为 Allow、Ask first 或 Never。1 使用场景页又把默认姿态说得更直白：默认是读取和导出；没有团队指令，不移动、不提交、不付款，每次审批都留在团队一侧。2

这个权限模型的巧妙之处，是让 agent 的自主程度跟动作风险走，而不是跟网站走。对同一个供应商门户，读取订单可以自动运行，提交发票需要先问，修改收款信息则直接禁止。用户不必在「完全自动」和「完全手动」之间二选一，产品也不必把所有风险都压到模型的判断上。

它还把接管点放进了执行过程，而不是只放在设置页。用户在真实网站里自行登录并完成多因素认证，Rindler 使用属于该用户、且限定到单一网站的会话；官网说明，凭证加密保存，不展示给模型，用户可以随时撤销。每次运行保留步骤和所见页面，无法完成时要指出具体网站和步骤，而不是只返回一个笼统的失败状态。16

这和传统录制式 RPA 的差别，不只是是否用了大模型。Rindler 把「路由怎么走」交给平台维护，把「哪些动作能走」交给用户配置，再把「这次实际走了哪几步」留在运行记录里。模型可以处理自然语言任务，但不能借着自然语言把付款、提交和改账单混成一个无边界的授权。

代价是配置与维护会变多。按网站、按动作设规则，比点一次「连接账号」更费时间；Ask first 也会在长任务中制造等待。更保守的默认值还意味着，很多任务只能读和导出，不能一路自动完成交易。Rindler 没有消除信任成本，只是把信任拆成了用户能看懂、能修改的几个小问题：允许它看什么，允许它做什么，哪一步必须回来问我。

Rindler 的核心判断可以浓缩成两步：让 agent 在重复任务里调用一张预先维护的网站地图，而不是每次从页面猜起；让权限跟着具体动作走，而不是给整个网站一张通行证。

这也解释了它为什么把结果做成结构化字段，把运行步骤和失败位置留下来。对于需要接入 AI 的业务团队，截图只是证据，动作接口才是下一步工作的入口；对于需要把控制权交给 agent 的产品，真正可用的自主性也不是「什么都能做」，而是用户能在一次任务中看清它做了什么、什么时候该停、出了问题由谁修。

Rindler 牺牲了一点即时性和配置的轻量感，换来一件更适合长期运行的东西：网站不再是 agent 每次都要重新认识的陌生页面，而是一层有人维护、能被调用、也能被限制的工作接口。