实测Fan浏览器Agent：自动填表申请韩国签证全流程

当浏览器Agent遇上繁琐的签证申请

签证申请一直是让人头疼的事：冗长的在线表单、动辄三十多项个人资料、护照扫描件上传，以及线下预约递交的复杂流程。这类任务重复度高、耗时又枯燥，恰恰是浏览器Agent（Browser Agent）最能发挥价值的场景。

浏览器Agent是一种基于大型语言模型（LLM）的自动化代理程序，能够像人类用户一样操控网页浏览器完成复杂任务。从认知科学角度看，这一架构实质上是对人类操作计算机过程的工程化抽象：感知层对应人眼读取屏幕信息，推理层对应大脑的决策过程，执行层对应手部操作鼠标键盘。这种分层设计使得每一层都可以独立迭代优化，是现代AI Agent系统设计的主流范式。其核心技术栈通常包含三个层次：感知层（通过截图、DOM解析或可访问性树获取页面状态）、推理层（LLM根据当前状态和目标规划下一步动作）、执行层（通过Playwright、Puppeteer等浏览器自动化框架模拟鼠标点击、键盘输入等操作）。

值得一提的是，感知层所依赖的**可访问性树（Accessibility Tree）**有着一段颇为有趣的技术溯源。它最初是为屏幕阅读器等辅助技术设计的——WAI-ARIA（Web Accessibility Initiative - Accessible Rich Internet Applications）规范由W3C于2008年首次发布，2017年发布2.0版本，其设计初衷是解决Web 2.0时代大量动态内容对辅助技术（如屏幕阅读器JAWS、NVDA）不友好的问题。规范定义了roles（角色，如button、dialog）、states（状态，如aria-expanded）和properties（属性，如aria-label）三类语义标注，使浏览器引擎能够向操作系统的辅助功能API（如Windows的UI Automation、macOS的NSAccessibility）暴露结构化语义信息。由浏览器引擎暴露出这份结构化的语义描述，记录页面上每个交互元素的角色、标签和状态。Agent借用这一基础设施完全是"歪打正着"的工程创新——无障碍设计者从未预料到自己的规范有朝一日会成为AI自动化的核心感知通道。Agent借助这一结构，可以以极低的成本"读懂"页面内容，相比逐像素分析截图拥有更高的信息密度和解析效率——一个典型网页的截图可能包含数百万像素，而其可访问性树通常只有数百个节点，信息压缩比高达数个数量级。

执行层常用的Playwright框架由微软开发，于2020年开源，支持Chromium、Firefox、WebKit三大主流浏览器引擎，能精确模拟鼠标悬停、拖拽、键盘组合键等人类操作细节。与更早的Selenium（2004年由ThoughtWorks工程师Jason Huggins创建，是业界最早的Web自动化测试框架之一）相比，Playwright原生支持异步操作和自动等待（Auto-wait）机制，能自动感知页面元素是否进入可交互状态后再执行操作，大幅降低了因页面加载时序不一致导致的自动化失败率。Selenium依赖WebDriver协议的同步调用模型，在现代单页应用（SPA）中频繁出现"元素尚未渲染"导致的竞态条件（Race Condition）；而Playwright基于Chrome DevTools Protocol（CDP）的直接通信架构则从根本上解决了这一问题。

然而，浏览器Agent在感知层面临的核心工程挑战是如何在有限的LLM上下文窗口（Context Window）内高效表达页面状态。GPT-4等主流模型的上下文窗口虽已扩展至128K tokens，但一个信息密集的政府表单页面仅其HTML源码就可能超过50K tokens。这催生了多种信息压缩策略：一是选择性DOM裁剪，仅保留可交互元素（input、button、select等）及其祖先节点；二是可访问性树序列化，将树形结构转换为紧凑的文本表示；三是**截图+视觉语言模型（VLM）**的多模态方案，利用GPT-4V或Claude 3等模型直接理解页面截图。三种方案各有取舍：DOM裁剪速度快但可能丢失视觉布局信息；可访问性树语义准确但对动态渲染内容覆盖不完整；VLM方案最接近人类视觉理解但推理延迟高、成本大。实际工程中往往采用混合策略，根据页面类型动态切换感知模式。

与传统RPA（机器人流程自动化）工具相比，浏览器Agent最大的优势在于泛化能力——它无需为每个网站单独编写规则脚本，而是依靠语言模型对页面语义的理解来动态决策。传统RPA的核心局限在于其自动化逻辑与UI结构的强耦合——脚本通过XPath或图像识别锚定到特定像素坐标，任何界面改版都可能导致大规模脚本失效，业界将此称为"脆弱性问题"（Brittleness Problem）。Gartner数据显示，企业RPA项目中约30%~50%的维护成本来自应对UI变更的脚本更新。浏览器Agent通过LLM的语义理解从根本上规避了这一问题——它识别的是"提交按钮"这一语义概念，而非某个固定的DOM路径。

本文记录了一位开发者使用自研的Fan Browser Agent，尝试全自动申请韩国旅游签证的完整实测过程。正如作者所说："签证这个东西听起来很难，特别适合浏览器Agent去做，有非常多的表单需要填写。"这句话点出了浏览器Agent的核心价值——把人从机械性的网页操作中解放出来。

第一步：自主理解流程与申请要求

实测从一句自然语言指令开始："你好，我想去韩国旅行，你可以帮我申请一下签证吗？"

Agent收到指令后并没有盲目行动，而是先主动"了解流程和要求"。它打开韩国签证申请中心官方网站，梳理出完整的申请路径：在线电子申请表 → 预约 → 线下递交材料，并识别出整个流程需要用户提供 30项以上的个人资料。

这一步体现了现代浏览器Agent的关键能力：任务规划。任务规划（Task Planning）是现代AI Agent架构中的核心模块，本质上是将一个高层目标分解为一系列可执行的子任务序列。在大型语言模型时代，这一能力通常通过当前主流的ReAct（Reasoning + Acting）框架实现——该框架由谷歌Brain团队（现DeepMind）的Shunyu Yao等人于2022年10月提出，论文标题为《ReAct: Synergizing Reasoning and Acting in Language Models》，发表于ICLR 2023。

在ReAct之前，AI Agent的推理与行动能力长期处于割裂状态。纯粹的思维链（Chain-of-Thought, CoT）推理——由Jason Wei等人于2022年在谷歌提出——能让模型在回答复杂问题时显式输出中间推理步骤，但缺乏与外部环境的实时交互能力，模型只能在"语言空间"内进行封闭推演，无法从真实执行结果中修正错误。而纯粹的行动序列（Action Sequence）方案则缺乏显式推理支撑，模型在没有中间思考过程的情况下直接输出操作指令，在面对需要条件判断的复杂任务时容错率极低。ReAct的核心贡献在于将两者有机整合：在每次推理循环中交替进行「思考（Thought）」和「行动（Action）」，并将环境返回的真实反馈（Observation）作为下一轮推理的输入，形成认知闭环。实验证明，这一框架在HotpotQA多跳问答和Fever事实核查基准上同时提升了任务准确率和推理可解释性，发布后迅速成为LangChain、AutoGen等主流Agent框架的默认推理范式，其设计理念也深刻影响了OpenAI的Function Calling和Anthropic的Tool Use等产品设计。

ReAct框架在浏览器Agent中的具体实现通常采用系统提示词（System Prompt）工程来约束模型的输出格式——要求模型在每个推理步骤中严格按照「思考（Thought）: …
行动（Action）: …
行动输入（Action Input）: …」的结构输出，便于程序解析并转换为实际的浏览器操作指令。这一格式化输出的核心价值在于将模型的推理过程变为可审计的日志，方便开发者调试失败步骤。在此基础上演化出的**树形思维（Tree of Thoughts, ToT）**框架——由普林斯顿大学与谷歌DeepMind合作于2023年提出——允许Agent在关键决策节点同时探索多条行动路径并回溯，使其能处理签证申请中"如果A方案不可行则尝试B方案"这类需要条件分支的复杂逻辑。ToT本质上是将蒙特卡洛树搜索（MCTS）的思想引入LLM推理，通过自我评估（Self-Evaluation）机制对不同推理路径打分，并优先探索高分路径，在需要全局规划的任务上相比线性ReAct有显著提升。

模型在执行每一步操作前先输出推理过程，再决定具体行动；执行完毕后，页面的新状态又成为下一轮思考的起点。这与人类完成复杂任务的认知模式高度一致：观察现状→思考决策→执行动作→根据结果调整计划。

对于签证申请这类多阶段任务，Agent需要识别出"填表→预约→线下递交"的有向依赖图，并理解某些步骤（如预约）必须在前置步骤完成后才能触发。这与早期规则引擎的线性脚本有本质区别，体现了LLM对流程语义的真实理解能力。

第二步：高速自动填写签证申请表

面对三十多项资料的填写要求，作者采用了更聪明的做法——提前准备好一份申请数据文件，让Agent读取后自动填充。

"数据读取完毕，现在开始填写"，接下来的表现让作者直呼超出预期。整个填表过程中，作者"没有动任何鼠标，没有动任何键盘"，Agent以极快的速度自动完成了所有表单填写，看得人"眼花缭乱"。

表单自动化是浏览器Agent最典型的应用场景之一，也是技术挑战最集中的领域。现代网页表单的复杂性远超早期静态HTML时代——React、Vue等前端框架催生了大量自定义UI组件（如Select2、Ant Design的级联选择器），这些组件在DOM层面的结构与原生input元素完全不同，传统基于CSS选择器的自动化工具极易失效。此外，许多政府类网站出于安全考虑会实施多层次的反自动化防护体系：

第一层是基于**行为生物特征识别（Behavioral Biometrics）的Bot检测。这一领域在2010年代随着机器学习的商业化应用而逐渐成熟，其核心理论基础可追溯至认知心理学和人机交互领域的研究——人类的输入行为因神经肌肉系统的生理约束而具有独特的统计"指纹"。代表性商业产品包括BioCatch（2011年成立于以色列，专注金融欺诈检测，已为全球超过30家大型银行提供服务）和Sardine（面向金融科技的风控平台）。这类系统通过持续采集数百个维度的行为信号来区分人机：鼠标移动轨迹的加速度曲线、点击落点的精确程度（人类通常不会完美点中元素中心）以及按键节奏的随机性（如同一个人连续两次输入同一段文字，其击键间隔的时序分布具有高度个人一致性）。人类的鼠标轨迹遵循菲茨定律（Fitts' Law）**的速度-距离权衡关系——该定律由心理学家Paul Fitts于1954年提出，描述了人体运动中目标距离与目标大小对操作时间的影响规律，是人机交互领域最重要的预测模型之一——而简单的自动化工具往往走直线且速度恒定，这一差异在统计层面极易被识别。现代Bot检测已从单次特征判断演化为基于时序模型（如LSTM或Transformer）的序列异常检测，能识别出那些单次行为看似合理、但整体会话模式与人类统计分布显著偏离的自动化程序。第二层是时间戳校验，检测表单从加载到提交的间隔是否过短（正常人填写30项表单通常需要数分钟，而自动化程序可能在数秒内完成）。第三层是基于机器学习的风控模型，如Google reCAPTCHA v3——于2018年发布，是reCAPTCHA系列的第三代产品——它在后台持续计算用户的"人类可信度"分数（0.0到1.0之间），完全无需用户主动完成任何验证动作，而是通过分析用户在整个页面上的行为历史和设备指纹来做出判断，分数低于阈值的请求将被静默标记或转入人工审核队列。

高质量的浏览器Agent在合规范围内通过引入随机延迟、模拟贝塞尔曲线鼠标轨迹、模拟人类打字节奏等方式提升行为真实性，需要在自动化效率与人类行为模拟之间取得微妙平衡，同时还需具备状态感知能力，在填写每个字段后重新评估页面状态变化（如选择国籍后触发的城市列表联动更新），而非简单地按顺序遍历表单元素。

尤其有意思的是它处理下拉列表和组合框的方式。作者观察到，Agent"还挺有思路的，知道先做什么后做什么"，最终顺利完成了全部四个组合框的选择（4/4）。这说明它不仅能识别页面元素，还能根据表单逻辑安排操作顺序，而非从上到下机械填充。

真实场景下的容错能力测试

实测中出现了一个有价值的插曲：在上传护照扫描件时，Agent报告"上传文件失败"。原因是作者事先删除了对应文件。

这个意外反而验证了Agent的一个重要优点——能准确识别失败原因并如实反馈，而不是假装成功或卡死。业界通常将Agent的容错行为分为三个等级：静默失败（最差，Agent继续执行后续步骤却不通知用户，可能导致错误的级联传播）、抛出异常停止（中等，至少不会造成更大损失但缺乏诊断信息）、识别根因并恢复或上报（最优，类似软件工程中的"优雅降级"原则）。

这一分级体系与软件工程中的**故障模式影响分析（FMEA，Failure Mode and Effects Analysis）**方法论一脉相承——FMEA最初源于1960年代的美国军事与航空航天工业：美国军方于1949年发布MIL-P-1629标准，首次将其正式文档化；NASA在阿波罗计划和阿波罗1号火灾事故（1967年）的深刻教训后，将其系统化为强制性的任务安全分析工具。此后，这一方法论被广泛引入汽车制造（对应IEC 60812标准，德国汽车工业协会VDA将其列为供应商质量体系的强制要求）和软件工程领域。FMEA的核心工作流程是对每种潜在故障模式计算风险优先数（RPN = 发生概率 × 可检测性 × 严重程度），RPN最高的故障模式优先获得预防或缓解资源。将这一思维框架引入Agent设计，意味着工程师需要在设计阶段就预先枚举每类操作的可能失败场景（如网络超时、元素未渲染、文件路径不存在），并为每种失败模式设计对应的检测和上报机制。

在复杂自动化系统中，失败的方式往往比成功更重要：一个能精确报告"文件路径不存在"的Agent，远比一个默默跳过上传步骤的Agent更具实用价值，因为前者给了用户明确的修复指引，而后者可能让用户在提交了不完整的申请表后才发现问题。本次实测中Agent能准确定位"文件不存在"这一根本原因，属于第三级容错行为，是Agent鲁棒性的重要体现。除去人为删除的文件这一干扰，申请表本身已基本填写完毕，第一步大功告成。

第三步：预约递交与现实边界

完成申请表后，Agent按既定流程进入第二步——预约线下递交材料，并自动打开了上海签证中心的预约页面。

结果如作者所料：当前无法预约。但Agent并没有止步于"失败"，而是从页面读取出了具体原因——放号时间为每周日、每周一上午九点，当前时间没有可预约名额。

这一细节再次体现了它区别于普通脚本的地方：能理解页面上的业务规则，并将关键信息提取出来告知用户，让人清楚"下一步该在什么时间再来操作"。这正是浏览器Agent相较于传统RPA工具的核心优势所在——传统RPA依赖固定的XPath或CSS选择器定位元素，页面UI的任何变化都可能导致预设脚本失效；而浏览器Agent通过语言模型对页面内容的语义理解来定位元素，即使网站改版，也能凭借对业务语义的理解继续工作。

浏览器Agent的核心能力与边界

通过这次韩国签证申请实测，可以清晰看到浏览器Agent当前的能力轮廓：

• 任务规划：能自主拆解多步骤流程，理解步骤间的先后顺序；
• 批量数据填充：结合本地数据文件，高速完成大量表单项填写；
• 复杂控件理解：能正确处理下拉框、组合框等交互元素；
• 错误反馈：遇到失败时能准确定位原因并告知用户。

正如作者所总结的，这类工具"特别适合去做这种任务，不仅仅是动动嘴皮子，他是真的会去做"。

当然，实测也揭示了现实边界：Agent无法绕过签证中心的放号规则，也依赖用户提前备齐完整的资料文件。它更像一个高效可靠的"数字助理"，专注于将繁琐的机械操作自动化，而最终的关键决策与材料准备仍需人来把控。

值得注意的是，当前浏览器Agent与传统RPA在企业场景中往往是互补而非替代的关系。从**总拥有成本（TCO，Total Cost of Ownership）**视角来审视两者的经济学差异，可以更清晰地理解这种分工的内在逻辑：RPA工具（UiPath成立于2005年，最初是一家罗马尼亚软件外包公司，2012年正式转型为RPA产品公司；Automation Anywhere成立于2003年，两者均在2010年代云计算普及后实现爆发式增长，分别于2021年前后完成估值超百亿美元的融资轮）的一次性开发成本较高（构建稳定的自动化脚本通常需要数周的流程分析和调试），但边际运行成本极低（一旦部署，每次执行几乎零增量成本）；浏览器Agent的开发成本低（自然语言描述任务即可快速部署），但边际运行成本随任务复杂度和LLM API调用频次线性增长。以GPT-4o当前定价估算，处理一次包含30个推理步骤的签证申请任务，累计token消耗约10万20万，API成本约在0.52美元之间，对个人用户尚在可接受范围，但对企业大规模部署则需精细的成本管控。值得关注的是，大型语言模型的推理成本正在以惊人的速度下降——从2023年初GPT-4发布到2025年，主流LLM推理成本已累计下降超过95%，这一趋势与半导体行业的学习曲线效应（每当累计产量翻倍，单位成本下降约20%）高度吻合，随着模型推理成本持续下降，这一经济学平衡点正在快速向浏览器Agent倾斜。

传统RPA工具在结构稳定的企业内网系统中具有极高的可靠性和执行效率，每次操作的延迟以毫秒计，且执行结果具有完全确定性（Deterministic）；而浏览器Agent引入LLM推理后，每次决策都需要调用语言模型，不仅带来了不可忽视的延迟成本（通常在数百毫秒到数秒之间），还引入了输出的概率性不确定性——语言模型的自回归生成机制（Auto-regressive Generation）本质上是基于概率分布的采样过程，即使是在温度（Temperature）参数设置为0的"贪婪解码"模式下，不同版本的模型权重或推理基础设施的细微差异也可能导致输出漂移，这在需要审计合规的企业流程中是必须认真对待的风险点。这一不确定性问题在金融、医疗、法律等强监管行业尤为突出——这些领域要求自动化系统的每次操作都必须可重现、可追溯，传统RPA的确定性执行模型在合规层面具有天然优势。在实际企业部署中，两类工具往往形成自然分工：RPA处理高频、结构固定的内部流程（如ERP系统数据录入、财务报表生成），Browser Agent处理低频、多变的外部公网任务（如竞品价格监控、政府门户信息采集）。LLM的泛化能力恰好补足了RPA脆弱性的短板，而RPA的高效确定性又弥补了LLM推理开销大的不足。

对于签证申请、机票预订、批量表单提交这类流程明确、重复度高的网页任务，浏览器Agent正在展现出切实的生产力价值。随着模型能力持续提升，有理由期待它在更多真实场景中承担起"动手去做"的角色。

核心要点

核心要点

核心要点