针对第三方门户的 UI 依赖自动化

每个企业都有这样一份清单：员工每天手动登录的门户，做着本该自动化却没有自动化的工作。查询订单状态的供应商门户。提交监管文件的政府网站。核实资格和查询理赔状态的保险付款方门户。资质核实的州执照委员会。合规申报的税务机关门户。

这些门户没有 API。或者有的有 API，但未公开文档、有速率限制，或仅限于支付访问费用的"优先合作伙伴"。数据在登录页面后面以 HTML 渲染，获取它的唯一方法是登录并导航 UI。

传统自动化使用浏览器脚本。Selenium、Playwright 或 Puppeteer 脚本登录，导航到正确页面，通过 CSS 选择器或 XPath 定位元素，提取数据，然后退出。这些脚本能用，直到不能用为止。门户重新设计更改了 CSS 类名。登录流程添加了新的 CAPTCHA。导航菜单从侧边栏移到了汉堡菜单。Cookie 同意横幅开始遮住提交按钮。脚本悄然失败，没有人知道，直到依赖该数据的下游流程开始报错。

州医疗委员会是一个特别典型的例子。有 50 个，每个都有不同的网站、不同的布局、不同的认证方法和不同的数据格式。它们按自己的时间表重新设计，没有任何通知。依赖抓取这些网站的资质核实服务，在任何给定时刻可能有五到十个脚本处于损坏状态，每个都需要开发人员检查新布局并重写选择器。

Triggerfish 的解决方案

Triggerfish 的浏览器自动化将 CDP 控制的 Chromium 与 LLM 视觉导航相结合。代理将页面视为渲染的像素和无障碍快照，而不是 DOM 树。它通过元素的外观和功能而非 CSS 类名来识别元素。当门户重新设计时，代理能够适应，因为登录表单仍然看起来像登录表单，导航菜单仍然看起来像导航菜单，数据表格仍然看起来像数据表格。

视觉导航代替选择器脚本

浏览器自动化工具通过七种操作工作：navigate、snapshot、click、type、select、scroll 和 wait。代理导航到 URL，对渲染的页面进行快照，推理所见内容，并决定采取什么行动。没有在页面上下文中执行任意 JavaScript 的 evaluate 工具——这是一个有意的安全决策。代理通过 UI 与页面交互，就像人类一样，无法执行可能被恶意页面利用的代码。

当代理遇到登录表单时，它通过视觉布局、占位符文本、标签和页面结构来识别用户名字段、密码字段和提交按钮。它不需要知道用户名字段有 id="auth-input-email" 或 class="login-form__email-field"。当这些标识符在重新设计时改变，代理不会注意到，因为它从未依赖它们。

共享域名安全配置

浏览器导航与网页抓取操作共享相同的域名安全配置。triggerfish.yaml 中的单个配置块定义了 SSRF 拒绝列表、域名允许列表、域名拒绝列表以及域名到分类的映射。当代理导航到分类为 CONFIDENTIAL 的供应商门户时，会话 taint 自动升级为 CONFIDENTIAL，该工作流中的所有后续操作都受 CONFIDENTIAL 级别限制。

SSRF 拒绝列表是硬编码的，不可覆盖。私有 IP 范围、链路本地地址和云元数据端点始终被阻止。DNS 解析在请求之前进行检查，防止 DNS 重绑定攻击。这很重要，因为浏览器自动化是任何代理系统中风险最高的攻击面。试图将代理重定向到内部服务的恶意页面在请求离开系统之前就会被阻止。

浏览器配置文件水印

每个代理维护自己的浏览器配置文件，随着与门户的交互不断积累 Cookie、本地存储和会话数据。配置文件带有分类水印，记录使用它的最高分类级别。该水印只能升级，不能降级。

如果代理使用其浏览器配置文件登录了 CONFIDENTIAL 供应商门户，配置文件就被标记为 CONFIDENTIAL。随后以 PUBLIC 分类运行的会话无法使用该配置文件，防止通过可能包含敏感信息的缓存凭据、Cookie 或会话令牌造成数据泄露。配置文件隔离是按代理执行的，水印执行是自动的。

这解决了门户自动化中一个微妙但重要的问题。浏览器配置文件会积累反映其访问过的数据的状态。没有水印的话，登录过敏感门户的配置文件可能通过自动填充建议、缓存的页面数据或持久化 Cookie 向较低分类的会话泄露信息。

凭据管理

门户凭据存储在操作系统密钥链（个人版）或企业密钥库（企业版）中，而不是配置文件或环境变量中。SECRET_ACCESS 钩子记录每次凭据检索。凭据在执行时由工作流引擎解析，通过输入界面注入到浏览器会话中，而不是以编程方式设置表单值。这意味着凭据与其他敏感操作一样，流经相同的安全层。

对常见门户变更的适应能力

以下是常见门户变更发生时的处理方式：

登录页面重新设计。 代理截取新快照，识别更新后的布局，通过视觉上下文找到表单字段。除非门户切换到完全不同的认证方法（SAML、OAuth、硬件令牌），否则登录无需任何配置更改即可继续工作。

导航重构。 代理登录后读取页面，根据链接文本、菜单标签和页面标题而非 URL 模式导航到目标区域。如果供应商门户将"订单状态"从左侧边栏移到顶部导航下拉菜单，代理会在那里找到它。

新的 Cookie 同意横幅。 代理看到横幅，识别接受/关闭按钮，点击它，然后继续原来的任务。这由 LLM 的通用页面理解处理，而不是专门用途的 Cookie 处理程序。

添加了 CAPTCHA。 这是该方法存在诚实局限的地方。简单的图像 CAPTCHA 根据 LLM 的视觉能力可能可以解决，但 reCAPTCHA v3 和类似的行为分析系统可以阻止自动化浏览器。工作流将这些路由到人工干预队列，而不是悄然失败。

多因素认证提示。 如果门户开始要求以前不需要的 MFA，代理检测到意外页面，通过通知系统报告情况，并暂停工作流直到人工完成 MFA 步骤。工作流可以配置为等待 MFA 完成，然后从暂停的地方恢复。

跨多个门户的批量处理

工作流引擎的 for 循环支持意味着单个工作流可以遍历多个门户目标。资质核实服务可以定义一个工作流，在单次批量运行中检查所有 50 个州医疗委员会的执照状态。每个门户交互作为独立的子步骤运行，有自己的浏览器会话、自己的分类追踪和自己的错误处理。如果 50 个中有 3 个门户失败，工作流完成其余 47 个，并将 3 个失败路由到审查队列，附带每个门户的详细错误上下文。

实际应用案例

一家认证机构作为提供者注册流程的一部分，跨州医疗委员会核实医疗提供者执照。传统上，核实助理手动登录每个委员会网站，搜索提供者，截取执照状态截图，并将数据录入认证系统。每次核实需要 5 到 15 分钟，该机构每周处理数百次。

使用 Triggerfish，工作流处理完整的核实周期。工作流收到一批带有执照号和目标州的提供者。对于每个提供者，浏览器自动化导航到相关州委员会门户，使用存储的凭据登录，搜索提供者，提取执照状态和到期日期，并存储结果。提取的数据因包含提供者 PII 而被分类为 CONFIDENTIAL，写入降级规则防止它被发送到该分类级别以下的任何频道。

当州委员会重新设计其门户时，代理在下一次核实尝试时自适应。当委员会添加阻止自动访问的 CAPTCHA 时，工作流将该州标记为需要手动核实，并继续处理批次的其余部分。核实助理从手动完成所有核实，转变为只处理自动化无法解决的异常。