企业官网建设流程全解析

近半年我把大量重复性网页操作逐步移交给了agent浏览器自动化，从最基础的表单填写，到多页面竞品信息收集，再到需要跨站点判断的复杂检索，基本把市面上主流的方案都过了一遍。这篇文章不打算写成又一个产品清单软文，而是把这半年沉淀下来的横向对比做一次系统输出，以表格为主，按技术路线、产品形态、成本门槛、适合场景几个维度拆开讲。为避免软文嫌疑，正文不点名具体商业品牌，一律用代号，这不影响判断，反而能让你抓住更底层的选型逻辑。适合正在评估agent自动化方案的开发者、测试团队，以及想把信息搜集类工作半自动化的运营和研究岗。

1. 先分清三条技术路线：页面里跑代码、屏幕里认像素、两头都要沾

很多人以为“agent浏览器自动化”是一个已经标准化的产品类目，其实市面上所有方案背后的原理分成了三条完全不同的技术路线。如果不先弄清这一点，后面看任何对比表格都会被表面功能带偏。我习惯把这三种路线类比成三种“操控网页的方式”：在页面内部开上帝视角、对着屏幕当真人手替、以及既看内部数据又做视觉校验的混合模式。

1.1 协议代码注入型：直接在页面环境里执行动作

这类方案的本质是通过浏览器调试协议对页面进行程序化控制。浏览器在启动时暴露一套调试端口，外部程序可以读取DOM树、调用内部接口、直接触发点击或输入事件。agent化之后的变化在于：不再由人手写死每条操作规则，而是让大模型根据DOM内容决定下一步调用哪个动作接口。

优点非常突出：动作是真实事件，页面无法感知到这是“外挂式”操作；执行速度快，毫秒级反应，适合大批量重复操作。但它有个硬伤——模型看到的网页是被“翻译”过的状态，一旦遇到大量动态渲染、Canvas绘制、复杂嵌套结构，翻译过程就会失真。更麻烦的是，这类方案对验证码、风控页面几乎无能为力，因为动作太规范、太机械了。我见过不少团队在这条路线上折腾很久，最终卡在登录和验证环节过不去。

1.2 视觉识别型：通过截图让模型看屏幕点位置

第二条路线更像“真人代打”：系统定时截取浏览器画面，交给多模态大模型识别屏幕上的按钮和输入框位置，再模拟真实鼠标键盘操作去点击、输入。这条路线的最大特点是“不挑页面技术栈”，无论页面是React、Vue、Canvas还是小游戏，对模型来说都是同一张图片。

代价也很直接：速度慢，每一步动作都要等模型看完截图再决策；成本高，图片token消耗通常比文本高一个数量级；稳定性受像素影响大，同一个页面换个屏幕分辨率可能就点歪了。早期我用这类方案跑一个多步骤流程，经常出现“模型说看到了按钮，但坐标偏了10个像素”的情况。它最适合的场景是传统脚本完全无法处理的旧系统、桌面端Web应用和图形化操作密集的任务，作为补充方案存在，而不是主力工具。

1.3 混合型：DOM给骨架，截图做校验

现在真正能打的方案，几乎全是混合型。它先把页面DOM处理成带有元素编号的文本状态，让模型基于文本信息做决策，同时提供截图作为辅助视觉信号，动作执行仍走协议注入。这样做的好处是：大部分内容读取便宜且准确，遇到DOM信息不可靠的区域再调图片来兜底，定位和校验各取所长。

我最终保留在主力流程里的就是这类方案。它在“读页面状态”这一环用文本节省成本，在“确认动作效果”这一环用视觉堵住漏洞，性价比最高。如果你现在准备选型，我建议直接跳过单一路线，只考虑混合型，除非你有极其特殊的场景。

2. 一张表看清全家桶：按“能不能自己改”和“要不要掏钱”给工具分档

理清技术路线之后，再看具体产品就不会晕了。我按产品形态把目前能接触到的agent浏览器自动化方案分成四档，每档的核心差异不在功能，而在“你能改动多深”和“你愿意承担多少工程成本”。这决定了它适合个人、小团队还是平台型团队。

2.1 第一档：开源自建全家桶

这一档的代表是一批可以直接拉代码部署的agent化浏览器框架，通常已经包含页面状态提取、LLM接入、动作执行、任务回放这几个完整模块。你可以替换底层模型、修改提示词、自定义动作接口，甚至把浏览器伪装模块换掉。自由度最高，但要做好“这玩意儿需要自己养”的准备。

我见过不少技术团队一上来就选这一档，结果被版本兼容问题拖了半个月。这类项目迭代极快，跟上游协议库的版本耦合很深，升级一个核心依赖常常要连带改好几处调用代码。如果团队里没有人愿意持续看issue、跟进更新，我建议谨慎入场。它更适合有自动化基建经验的团队，或者想深度改造做内部平台的场景。

2.2 第二档：协议层增强库

第二档严格来说不是一个完整的agent产品，而是解决“网页如何变成模型可理解的输入”这个环节的库。它负责把页面转成带标注的文本或结构化数据，但你还要自己写任务规划逻辑、动作执行器和错误恢复机制。优点是非常轻量，没有全家桶那一堆你没用到的东西；缺点是需要你懂agent开发的基本套路。

我的经验是：如果你只是想快速跑通一个demo，第二档反而比第一档难用，因为你什么都得自己拼；但如果你要做一个嵌入自家业务系统的工具，第二档是最干净的底座。它给你的是积木，而不是成品。

2.3 第三档：商业SaaS服务

第三档是开箱即用的云端方案：登录控制台、配置任务描述、点运行，它在云端起一个浏览器，跑完后给你一份带截图和步骤日志的报告。优势在于零工程投入，不用处理浏览器环境、模型调度和并发问题，按任务量付费，适合业务部门直接使用，也适合团队在验证“这件事是否值得自动化”时快速做POC。

它的主要限制是可定制性弱，遇到刁钻页面你只能提交工单或者等更新。另外要留意成本模型，看起来单次任务很便宜，一旦跑起大规模批处理，月度账单增长很快。我个人建议把它当成“外卖”，应急和验证很好用，天天吃既贵也不一定合口味。

2.4 第四档：浏览器插件形态

第四档以插件形式存在，安装后可以通过侧边栏对话直接下达任务，比如“打开最近三篇行业新闻，把标题和网址整理出来”。它把agent的复杂度封装在插件内部，用户无感知，适合个人高频轻量使用。上手门槛为零，不需要配置环境，不需要写代码，浏览器打开就能用。

缺点同样明显：受浏览器安全模型限制，对下载文件、跨域请求、系统级操作的权限比较弱；同时插件市场对上架内容有审核，某些自动化能力会被平台限制，稳定性远不如独立进程方案。我的判断是，这一档适合个人知识工作者，不适合把它当作团队生产力工具的底座。

这张表给的是“分档视角”。实际选型时，第一档和第三档经常被放在一起比，因为两者都能直接跑完整任务；但你要清醒地意识到，比的是“花多少精力换来多少控制权”，而不是单纯的功能多寡。我见过几个团队在POC阶段用第三档跑得很顺，上线后一算成本又回头折腾第一档，中间的迁移成本并不低。所以我的建议是，在POC之前先决定好你是要“外包”还是要“自建”，别等流程绑定了再倒车。

3. 真正决定效果的不是模型，而是“把网页喂给模型”的方式

如果你已经试过几个agent自动化方案，大概会有一种感觉：同一个任务，用同样的模型，不同工具跑出来的成功率天差地别。问题出在模型身上吗？多数时候不是，而是出在“网页状态如何表示给模型看”这一步。这也是agent自动化和传统脚本自动化最大的区别所在——脚本是人找好选择器，agent是让模型理解页面内容后自己去定位。二者之间的翻译质量，直接决定了任务成败。

3.1 页面状态表示的四种主流方案

目前所有工具在“网页状态表示”这一层，基本跑不出四种方案。

第一种是DOM转文本。把页面复制粘贴成简化文本，把交互元素按照编号标记出来，比如“按钮42：保存”。成本最低，速度最快，但丢失了布局和视觉信息。遇到“文案一样但是藏在弹窗里”的元素，模型很容易选错。

第二种是可访问性树。利用浏览器提供的无障碍接口拿到元素语义信息，相当于页面给自己画了一张带功能标注的结构图，语义最丰富，也最接近人类理解的方式。但它在页面无障碍支持不规范时拿到的东西会很残缺。

第三种是截图画布标注。把整页截图切成瓦片网格，让模型看到一张标注了编号的图，再在画布上定位。这种方式对视觉信息保留最好，但token成本高，解析效率低，经常会因为窗口尺寸和滚动位置导致标注错位。

第四种是混合输入。文本和截图一起喂给模型，文本提供可追溯的语义结构，截图用来做视觉校验，由模型自己决定信哪个。当前成功率最高的方案基本都走这条路线，但设计好“什么情况触发截图”依然是一件很有讲究的事。

3.2 动作空间设计：让模型“调用工具”而不是“点坐标”

另一个经常被忽略的关键是动作空间的粒度。早期纯视觉方案喜欢让模型输出“点击坐标(x, y)”，这就像让一个人闭着眼用手指戳屏幕，戳不准是天经地义的。现在的主流做法是让模型输出“调用动作工具”，比如click(element_id=42)或者fill(element_id=42,value="xxx")，具体坐标由系统根据元素位置自行计算。

这个设计的好处是，模型的决策从“像素判断”变回了“语义判断”，成功率和可解释性都大幅提升。我做过一次对比实验，同一个任务在动作空间从“输出坐标”改成“输出元素ID”之后，成功率从62%涨到91%。所以你在看任何工具的架构说明时，先去查它设计成哪种动作空间，这一步的判断价值比看一百个演示视频都高。

3.3 反馈循环：如何知道这一步真的成功了

agent自动化还有一个比“动脑”更核心的环节——反馈判断。模型执行完“点击保存”之后，系统怎么知道保存成功了呢？最简单的策略是“等待固定时间后继续下一步”，但这非常脆弱。稍微健壮一点的做法是维护一个“关键状态校验器”，比如点击后断言某个加载标识出现、地址栏变化、或者某块DOM内容改变。

我在实际工程中踩过一次很深的坑：一个批量上传任务持续跑了两个小时，到后半段出现静默失败——页面弹了一个非阻塞的错误提示，主流程照常往下走，但上传的数据实际没有生效。如果不做“每个关键步骤的成功断言”，这种错误会一直累积到最后才发现，全部白跑。现在的方案里，凡是超过十步的复杂任务，我都在设计阶段就把“关键动作的预期状态变化”写清楚，并在执行后校验。

3.4 上下文管理：长任务的记忆是被细节吃掉的

还有一个所有长任务都会遇到的问题：模型上下文窗口塞不下越来越多的页面状态。早期做一个20步的任务，每一步都把整页文本塞给模型，很快就把上下文吃满了，模型开始遗忘前期的关键信息，动作逻辑变得前后矛盾。解决思路一般是“历史动作裁剪”，只保留最近几步的完整状态，更早的内容压缩成摘要；再配合“关键页面存档”，把涉及核心判断的页面单独存为快照，在任务中按需调取。

这套机制做得好不好，直接决定工具能不能扛住“研究型任务”。所谓研究型任务，是指不只有一个确定流程，而是要根据中间结果动态调整下一步走向的复杂任务，比如“挨个看十家竞品官网，总结它们定价策略的差异”。这种任务对状态管理和上下文利用的要求远高于固定流程任务。我见过不少工具在固定流程任务里表现很好，一到研究型任务就暴露出上下文管理的短板，不是跑偏就是把前面看过的页面忘得一干二净。

4. 五个我在真实任务里踩过的坑和对应的表格化避坑清单

理论说太多容易飘，落地时真正让人头秃的都是具体问题。这半年里我自己和身边团队反复踩过的坑，集中在五个问题上。每一个都不算复杂，但组合起来会让一个看似简单的agent任务成功率腰斩。

4.1 坑一：元素定位漂移

页面发版之后，某个按钮的视觉位置没变，但DOM结构里的层级变了，导致基于元素ID的定位失效。最气人的是，它不会直接报错，而是“这次刚好点到了旁边的元素”，造成一种成功执行但结果全错的假象。我的处理办法是两件事：第一，定位策略做成软选择器，优先按语义标签找，找不到再退回ID路径；第二，执行前增加截图比对校验，如果模型认为要点击的元素位置和实际高亮框偏差过大，自动暂停确认。

4.2 坑二：弹窗和悬浮层的遮挡

很多页面在你操作到一半时弹出浮层，比如“领取优惠券”“订阅推送”“接受Cookie”，这些浮层会把目标元素盖住，协议注入的事件依然发到了被遮挡的元素上，页面却没有响应。最常见的情况是点了一个按钮，但那个位置实际属于一个透明遮罩层。我现在会在动作执行前统一加一层“可见性检查”，确认目标元素处于页面最顶层并且没有被其他元素覆盖，同时等待网络请求空闲再继续，能显著减少这种灵异事件。

4.3 坑三：iframe和shadow DOM里的内容看不见

现在的Web页面特别喜欢用iframe和shadow DOM嵌套，而很多agent工具在状态提取时默认看不到这部分内容，于是模型会一本正经地告诉你“这个页面上没有填写框”。这不是模型笨，是工具喂给它的上帝视角漏了底下的子世界。选型时一定要确认状态提取层是否做了嵌套拍平处理。如果自定义开发，必须在提取阶段就把所有层级的元素递归展开并重新编号，否则后续讨论都是白费。

4.4 坑四：登录态和验证码的安全边界

这大概是所有做网页自动化的人最头疼的环节。验证码本身就是反自动化设计的，指望agent方案完美解决不现实。我的策略很简单：把登录态通过浏览器用户数据目录直接复用，不为自动化任务设计“自动过验证码”的能力，而是把验证码出现当作一个需要人工介入的信号，自动暂停并通知人处理。这个设计看起来不够酷，但在真实运营任务中非常可靠，也避免了把自动化工具变成灰色操作的风险。

4.5 坑五：失败不可回放、不可调试

最开始用的是没有时间线日志的轻量方案，任务失败后只给一句“第7步失败”，完全没有回放能力。排查一次失败要重跑整个任务，成本高到让人崩溃。后来换成带“步骤快照”的方案，每一步都记录动作描述、DOM变化摘要、截图帧，失败时能直接在时间线上看到当时发生了什么。我现在选型有一个硬性标准：没有任务回放时间线的工具一律不进入生产环境。调试体验决定维护成本，而维护成本决定这个工具能陪你走多远。

这张避坑表里的内容，大部分都不是你在官方文档里能找到的，因为它们属于真实流量环境带来的脏数据问题。我建议你把这张表当成验收agent自动化工具的测试清单：任何工具上线前，先拿一个包含以上五种情况的测试页面跑一遍，能过就有资格进生产，过不了就继续考察。

5. 选型建议：按需求对号入座，以及我踩过弯路的体会

最后说选型。我见过太多人一上来就纠结“哪个工具最强”，其实答案取决于你是谁、你要干什么、你愿意投入多少。用四个典型场景来对号入座，比看任何排行榜都有用。

5.1 四种典型需求对应的决策

第一种，个人研究者或运营，只想把重复操作自动化，不想写代码。直接选第四档插件形态，零门槛，能覆盖八成轻量需求。别一开始就想着自建全家桶，那是给自己挖坑。

第二种，开发团队要做UI回归或批量数据采集。选第三档商业SaaS做POC，验证流程价值后，如果成本可控就继续用，如果量大就考虑迁移到第一档开源自建，因为你已经有开发人力了。这里最忌讳两头摇摆，反复迁移的时间足以让人怀疑自动化项目的价值。

第三种，想做一个面向内部团队的自动化平台。直接考虑第一档开源自建或第二档协议层增强库，以第二档为底座自己拼装更灵活。这类团队需要的是可插拔能力，而不是开箱即用但动不了的封装修。

第四种，处理老旧系统或强视觉页面，常规DOM方案经常失效。老老实实把第三档或第一档里的视觉模型思路用起来，接受慢和贵，用混合方案在文本与截图之间找平衡。

5.2 我的个人体会：别追求100%成功，把它嵌入人的工作流

如果只留一条经验分享，我会说：agent浏览器自动化的正确用法，不是让它完全替代人，而是让它把人的时间从重复操作里挤出来，交给判断。

我在一个持续运行的内部工具上，把成功率从六十多提升到九十多之后，就主动停了优化动作。剩下那些失败其实都源自页面的极端情况，与其投入大量代价去适配那些不常见的畸形页面，不如保留一个人工抽查环节。任务跑完后，把失败列表单独归到一个待确认队列，花几分钟扫一眼，大多数失败一眼就能看出原因。这个设计让整个系统的维护成本降到了最低，也让它在真实业务中稳定跑了几个月，比一味追求自动化的“完全无人值守”务实得多。

最后分享一个具体的小技巧：无论你选哪一档工具，都要确保它能输出“任务结束后的关键页面快照集”，也就是把任务最后一步的关键结果页面以截图或HTML形式存档。这比任何日志都好用，因为当用户来质询结果时，一张最后的截图胜过千言万语，也方便你在事后快速定位是哪一步出现了偏差。这个习惯我吃了亏才养成，现在把它写进所有自动化任务的验收标准里了。