填补视觉与 API 的鸿沟：如何用 AI 视觉智能体实现旧版门户网站自动化

你看着运营经理处理一笔普通的客户退款。这事儿得花五分钟。他们得先在 Zendesk 查投诉，打开 Shopify 核实订单，登录那个笨重过时的仓库后台确认退货入库，最后再切换到 Stripe 把钱退掉。

处理一单，五分钟确实不算什么。但当你每天要处理两百笔退款时，这种手动切换系统的活儿就变成了一份全职工作。你的第一直觉肯定是搞自动化。结果你去翻仓库系统的 API 文档，发现那玩意儿从 2018 年起就没更新过。

这就是“自动化美梦”破碎的地方。你陷入了两难：要么花 £20,000 找人定制开发一套集成系统，要么就让你的团队每天下午在那儿干耗体力，重复这些机械操作。

视觉与 API 之间的断层

“视觉-API 断层”是一种运营瓶颈：你的现代 SaaS 工具之间聊得火热，但某个关键的老旧系统却必须靠人的眼睛看、靠鼠标点才能转得起来。你的 Zendesk、Shopify 和 Stripe 通过 webhook 配合得天衣无缝，结果到了仓库管理后台这儿卡住了——它只有一个网页界面，压根没给 API 留口子。

几乎每一家处理实物商品或复杂服务的英国中小企业都存在这种结构性缺陷。之所以一直凑合，是因为更换核心老旧系统的风险和成本都太高了。所以，你只能用人力来填补这个断层。

你的财务助理变成了“人形 API”。他们从现代化的仪表盘里读数据，然后手动敲进十年前开发的网页表单里。这看起来像是在干活，其实只是在用体力活掩盖系统性的失败。

代价可不仅仅是那点时薪。真正的成本是错误率。当一个人连续四小时在三个屏幕间复制粘贴订单号时，肯定会出错。输错一位数字，退款就打到了错误的账户；漏记一件退货，库存就永远对不上。

这种断层在逼着你最聪明的人去干最蠢的活。他们整天就在那儿把文字从白屏幕搬到灰屏幕。如果你的核心业务还得靠人工去连接现代软件和老旧后台，那生意根本没法做大。每增加一个新客户，都只是往那堆手动点击的破事儿里又加了一块砖。

为什么死板的“网页爬取”总是在悄悄出错

死板的网页爬取（Screen Scraping）之所以不靠谱，是因为它依赖的是绝对坐标，而不是视觉理解。通常的建议是买个 RPA（机器人流程自动化）工具来补位。你规划好点击顺序，录个宏，让机器人重复操作。听起来挺逻辑通顺的，实际上是个随时会爆的雷。

传统的 RPA 依赖极其脆弱的规则。它找的是特定的 HTML 标签或固定的屏幕坐标。要是你的老旧供应商后台在页面顶部加了个通知横幅，整个页面就会下移 50 像素。机器人可不知道这事儿，它还是会点在原来“退款”按钮的位置，结果点成了“取消订单”，然后接着处理下一单。

如果 RPA 机器人去固定文本框里读客户地址，而后台改了字体大小，机器人抓到的就是一片空白。它会默不作声地把空数据写进你的数据库。直到月底物流合作伙伴问你为什么有 50 个退货标签没地址时，你才会发现。

这就是死板的 UI 自动化在技术上的真相：它会“静默失败”。如果是 API 流程，数据格式错了会报 400 错误，你会收到警报并修复它。而传统的网页爬取只会盲目地一直点下去，制造出一堆烂账，直到审计时你才会被吓一跳。

我见过太多中小企业在没有 API 的情况下硬搞客服自动化。他们付了昂贵的 RPA 授权费，花了几周时间打磨点击路径，结果网页界面一改版，整套系统直接废弃。

处理财务交易不能指望坐标或 CSS 选择器。你需要一个能像人一样“看”并“理解”屏幕的系统。如果按钮挪了位，系统得能自己找新位置。在动手之前，它必须读懂文字，理解当下的语境。

视觉智能体驱动的混合自动化

用 n8n 编排 API，再把老旧系统的视觉任务丢给 AI 视觉智能体。

混合自动化（Hybrid Automation）把现代工具的 API 流程与针对老旧界面的视觉 UI 智能体结合了起来。有 API 的地方用 API，没 API 的烂摊子交给 AI 智能体。现在利用 Anthropic 的 Claude 3.5 Computer Use API 已经可以实现了。

一套复杂的退款自动化流程应该是这样的：客户发邮件要求退款，Zendesk AI 给邮件打上标签并触发 n8n 的 webhook。n8n 立即调用 Shopify 的 API 拉取订单详情，核实购买日期。

标准自动化到这里就卡住了。但现在，n8n 可以触发一个运行在安全 Docker 容器里的 Python 脚本。这个脚本调用 Claude Computer Use API。你把订单号和一套严格的指令传给 Claude，让它登录仓库后台，搜索订单，确认东西是不是已经回到了货架上。

Claude 实际上是在容器里控制一个虚拟的鼠标 and 键盘。它看着后台的截图，不管搜索框在页面哪个位置都能找着，输入订单号，读取状态。它不依赖固定坐标，它是在视觉上理解这个界面。

如果 Claude 看到状态是“已退回”，它会给 n8n 发回一个结构化的 JSON 响应。接着 n8n 再去调用 Stripe 的 API 完成退款，最后更新 Zendesk 工单并结案。整个过程只需 40 秒，全程零人工干预，而且数据库里留下了完美的审计日志。

你这是把 API 自动化的可靠性与人工操作的灵活性揉在了一起。API 管钱，UI 智能体管查数。搭建这么一套混合系统大概需要两到三周。根据你老旧后台的复杂程度和现有的 n8n 基础，预算大概在 £6,000 到 £12,000 之间。

为了防止出错，你得设定严格的边界条件。只给 UI 智能体仓库系统的“只读”权限。绝对不允许它点“退款”按钮，它只负责提取数据。如果界面大改版导致智能体懵了，它直接给 n8n 报错，n8n 就会把这单转给人工处理。

混合 UI 自动化的局限性

如果遇到物理安全屏障、超高频交易或者根本没法读的老旧屏幕，混合 UI 自动化也会歇菜。这套架构很强，但不是万灵药。在动手之前，你得先确认几个限制条件。

首先，看登录方式。如果你的老旧后台需要物理 U 盾、硬件令牌或者生物识别登录，虚拟 UI 智能体就进不去。你可能折腾好几周试图绕过安全协议，最后才发现这系统设计之初就是为了防这一手的。

其次，考虑成本和延迟。Claude 截图、分析、移动虚拟鼠标都是要时间的。查一次可能要 30 秒，还得花几便士的 API token 费。

如果你每天处理 50 笔退款，这完全没问题。但如果你每小时要处理一万笔微小交易，计算成本会直接吃掉你的利润，延迟也会导致积压一大堆任务，运营团队根本处理不完。

最后，警惕那些动态感太强、基于 Flash 或者做了重度混淆的界面。如果一个人看着低分辨率图片里的文字都费劲，那视觉模型也会很吃力。在写代码之前，一定要先在最乱的界面上手动测试一下智能体。在把客户数据交给它之前，你得先摸清它的底线在哪儿。

值得思考的三个问题

1. 在你每天的运营任务中，哪些活儿其实是在充当两个断开系统之间的“人力桥梁”？ 找出那些你的团队花在“搬运数据”上的时间远多于“做决策”的具体流程。
2. 如果你现在的网页爬取工具明天遇到一个完全改版的界面，它是会大声报错提醒你，还是会默不作声地搞烂你的数据库？ 仔细检查现有自动化的容错机制，因为财务流程中的静默失败比人工操作要贵得多。
3. 你是不是在强求一个只有视觉界面的系统达到 API 级别的稳定性，而不是用视觉智能体去填补这个断层？ 评估一下你是否在浪费成千上万英镑去搞那些脆弱的反向工程 API，而明明一个灵活的 UI 智能体就能直接看懂屏幕。