Fellou：可视化工作流浏览器Agent

为什么需要 Fellou：把「脚本维护地狱」变成可视化 + AI 的浏览器自动化

传统浏览器自动化有三个痛点。第一，编码门槛：Selenium/Playwright 脚本要求开发者熟悉 DOM、选择器与异步控制，非工程师无法参与。第二，维护成本高：页面结构一经改版，XPath/CSS 选择器失效，脚本随即崩溃，需投入人力逐一修复。第三，行为不可控：全代码 Agent 虽然能听懂自然语言指令，但执行路线不透明、出错难定位、难以在关键节点插入人工判断。

Fellou 的解法是把「确定性」和「不确定性」分层。确定性部分——打开哪个 URL、按什么顺序点击、输入什么内容——由可视化流程节点显式表达，任何人能看懂、能修改。不确定性部分——页面元素动态变化、返回内容格式不统一——交给 AI 节点处理：AI 根据页面当前 DOM 识别目标元素并抽取数据，而不是依赖写死的选择器。每步执行后保留截图、DOM 快照与日志，运行过程从「黑盒」变成「可检查的流程图」。

与同类工具的气质差异在于：Skyvern 与 browser-use 面向开发者，输出的是 API 调用或 Python 代码；Fellou 面向「要把浏览器任务当产品来维护」的团队，以画布作为主要交付物。相比录屏式 RPA，Fellou 用 AI 消解了页面变化带来的脆弱性；相比通用工作流平台，它把「浏览器」作为一等公民，而不是塞进通用节点库中的附属能力。

安装与环境配置：3 步就绪

步骤一，开通工作区。访问 Fellou 官网，使用邮箱或第三方账号注册，登录后进入工作区首页。首次登录建议创建团队工作区，方便后续多人协作与权限管理。

步骤二，完成运行时配置。如果 Fellou 提示安装浏览器扩展，按页面指引安装并登录，用于把本地浏览器会话接入执行环境；如果仅使用云端浏览器执行，则跳过此步。进入「设置 → 运行环境」，确认浏览器语言、视口尺寸与超时时间。建议先保持默认值，跑通示例后再按目标站点调整。

步骤三，验证环境。在控制台创建一个名为 hello 的空白工作流，拖入一个「打开网页」节点，目标 URL 填 https://example.com，保存后运行。若能正常进入成功状态并看到页面快照，说明工作区与运行环境就绪。验证完成后删除该工作流，避免占用运行配额。

快速上手：5 分钟跑通第一个「信息提取 + 条件分支」工作流

最小可用流程的思路是：打开一个目标网页 → 让 AI 从页面里提取一个字段 → 判断提取结果是否为空 → 把结果输出到表格。这样一次就把「浏览器动作 + AI 提取 + 逻辑判断 + 结果输出」四类节点全部覆盖。

1. 在控制台点击「新建工作流」，命名为「商品信息监控」。

2. 拖入「打开网页」节点，在设置里填目标 URL，例如某商品详情页。

3. 拖入「提取网页数据」节点，在字段配置里新增字段 title，用描述性提示词说明提取范围，例如「提取商品标题，最多 30 字」。

4. 拖入「条件判断」节点，设置条件：title 为空 → 走「失败」分支，非空 → 走「成功」分支。

5. 拖入「写入表格」节点，将 title 写入工作表；在「失败」分支上接一个「发送通知」节点，把当前 URL 发到通知渠道。

6. 点击「运行」，在运行日志面板查看每个节点的状态、耗时与输出；展开「提取网页数据」节点，检查 AI 返回字段是否符合预期。

7. 运行成功后返回工作流编辑页，在「调度设置」中开启「每小时执行一次」。

结果说明：该工作流具备「页面采集—AI 抽取—异常降级—结果汇总」的最小闭环。后续可叠加「输入文本」「点击」等节点，把搜索、翻页、登录等动作纳入同一流程。

核心能力详解：5 大支柱

支柱一·可视化流程编排。通过拖拽节点构建工作流：浏览器动作类（打开网页、点击、输入文本、滚动、下载）、逻辑类（条件判断、循环、等待）、AI 类（数据提取、文本生成）。节点之间以「成功 / 失败」端口连接，分支以可视化形式呈现，无需读代码即可理解执行路径。

支柱二·AI 参与的浏览器交互。AI 节点接收当前页面的可访问 DOM，按提示词定位目标元素并返回结构化 JSON，替代易碎的 XPath/CSS 选择器。适合动态列表、无规律富文本、页面结构频繁变化的站点——AI 依据语义理解页面，而非依赖写死的元素路径。

支柱三·执行可观测性。每次运行按节点记录状态、耗时、输入输出、截图与页面快照。运行失败时可定位到具体节点，直接修改配置后重跑，不必从零重放整个流程，显著缩短排障时间。

支柱四·调度与触发。工作流可配置为定时运行（每分钟至每月）、手动运行或 Webhook 触发，满足「按业务节奏自动巡检页面变化」的常态需求，也能被上游系统按事件驱动。

支柱五·数据输出与集成。节点输出可写入工作表、数据库，或通过 Webhook 投递给企业微信群、钉钉、Slack 等渠道，打通「浏览器 → 数据 → 业务系统」链路。

生产部署与监控：从上线到运维

部署方式一，按「调试 → 生产」分环境迁移。先在调试模式下用小批量数据跑通工作流，确认每个节点的输出正确，再切换到生产环境。生产任务与调试任务建议分工作区管理，避免误删生产配置或相互影响配额。

部署方式二，面向运行稳定性设计。对依赖登录态的站点，在流程前段加入「检查登录状态」分支，发现未登录时先执行登录步骤；对翻页列表，用循环节点遍历多页并聚合结果；对偶发超时，在「打开网页」节点后加入重试分支，限制最大重试次数。

可观测性方面，定期查看运行趋势，包括成功率、平均时长与失败节点分布。把失败告警接到常用 IM：当成功率低于阈值或同一节点连续失败 N 次时触发通知。页面结构突变时，应优先检查「提取网页数据」节点的失败日志，此类失败多为 DOM 变化导致。

<p class=“para-label“>避坑清单：</p><ul class=”dash-list”><li>不要用固定选择器依赖动态页面，优先让 AI 节点基于标签语义定位元素，避免页面小改动即失效；</li><li>不要把实时验证码与强风控站点纳入常规自动化，AI 节点无法保证突破验证，应在流程设计时就规避；</li><li>不要在生产环境中不加重试与告警直接启用调度，至少要配置失败通知与最大重试次数；</li><li>不要把 Cookie 与登录态当作永久有效，工作流必须包含登录态检查与自动恢复分支；</li><li>不要把所有页面都交给 AI 提取，能明确表达的字段用确定规则，AI 只处理真正动态的部分，可显著降低成本与误判。</li></ul>

AI 应用场景

常见误区

面试题