企业官网建设流程全解析

1. 都2025年了，为什么“让AI帮我操作网页”还是这么难

先说个场景。前阵子我接到一个需求，要让大模型自动去某个后台系统里查订单、下载报表、再回填到另一个系统。搁在以前，这种活要么写死脚本，要么上RPA，但这两种方案各有各的难受。写死脚本怕页面改版，RPA流程稍微复杂一点，配置起来比写代码还费劲。当时市面上已经有不少号称“AI浏览器自动化”的项目了，但真正用起来你会发现，它们大多卡在同一个地方：AI能看懂网页，不代表它能稳定地操作网页。

这个问题的本质在于，网页不像API那样有稳定的“接口契约”。API有固定的请求参数和返回结构，机器跟机器之间交流是规矩的。而网页的反而是给人类设计的，DOM结构复杂，元素位置飘忽，还有一堆动态渲染、弹窗、懒加载之类的幺蛾子。LLM被训练出来的强项是理解和推理，但让它精确地点击一个坐标、在正确的输入框里填值、判断整个页面是否加载完成，这是一件非常反AI直觉的事情。

BrowserSkill这个项目，就是冲着这个痛点去的。它把“操作浏览器”这件事做成了可以复用、可以编排的技能库，结合MCP（Model Context Protocol）这类协议，让大模型不需要理解浏览器底层的DOM细节，只需要声明“我要做什么”，剩下的动作序列由技能层去完成。我是在腾讯开源社区里看到这个项目的，名字很直白，BrowserSkill——浏览器技能。当时第一反应是，这跟那些“Agent Browser”“Playwright MCP”有什么区别？用下来之后我才意识到，这几个东西根本不是一个层面的，后面我会详细拆。

这篇文章适合谁看？如果你正在做LLM Agent相关的东西，或者被网页自动化折磨过，又或者你只是想知道AI到底能不能替人安稳地点网页，那这篇应该都能给你一些参考。我不会只讲概念，会把实际运行、对比、踩坑的东西都放进来。

2. 先搞明白一件事：网页自动化为什么会被AI“骗”

在聊BrowserSkill之前，必须先把一个反直觉的坑讲透：AI操作网页最大的障碍不是“手不够巧”，而是“眼睛会骗它”。

2.1 LLM看到的网页，和浏览器里渲染出来的网页，不是同一个东西

很多人第一次做LLM网页自动化的时候，最直观的方案是：把网页截图丢给多模态大模型，让模型看图识别元素位置，然后模拟点击。这个思路听起来很合理，但在实际项目里你会崩溃。原因有三个。

第一，截图是像素，不是结构。LLM从截图里看到一个蓝色按钮，它只能猜测按钮中心在图片的某个区域，但这个猜测和真实浏览器里的坐标之间隔着缩放比例、滚动偏移、视口尺寸这些变量。页面稍微一滚动，坐标就全错。

第二，真实网页有大量动态内容。数据表格是异步加载的，弹窗是延迟出现的，下拉框的选项是需要点击之后才生成的。截图那一瞬间，页面根本没加载到位，AI看到的是一场“半场戏”。

第三，多模态模型对“第几个元素”这种精确指代非常不敏感。你说“点第二个tab”，它可能盯着页面想半天，最后点了第三个。这类幻觉在纯视觉方案里几乎无法根除。

所以，行业里后来普遍转向了另一种路线：把网页的DOM结构或者可访问性树（Accessibility Tree）暴露给LLM，让模型基于真实的页面结构来做决策，而不是基于模糊的像素。BrowserSkill的核心思路也在这里——它不靠“看”，靠“读”。

2.2 “读DOM”也有坑：信息过载和结构噪声

读DOM听着比看截图像样，但真的把一整个页面的HTML丢给LLM，模型很快就懵了。一个中等复杂度的页面，DOM节点动辄几千个，即使是精简过的元素树，token开销也非常恐怖。更麻烦的是，DOM里充斥着大量对用户无意义的节点，比如隐藏的、装饰性的、动态生成的重复结构，这些对LLM的决策都是噪声。

BrowserSkill这类项目对DOM做了一层“技能层”的预处理。它不会把原始HTML直接丢给模型，而是先通过选择器、语义化规则或者预定义的动作模板，把页面提取成模型能够理解的“动作单元”。换句话说，它给LLM的不是一张零件图纸，而是一个个带名字的按钮——这对大模型的上下文窗口是一个极大的减负。

2.3 为什么“技能”比“意图”更能落地

现在很多Agent框架走的是“意图驱动”路线：你给模型一个目标，它把目标拆解成步骤，再一步步操作。听上去很美，但真实项目里，模型的自由度过高反而容易失控。限制太少，模型会发明一些浏览器里根本不存在的操作；步骤太多，中间任何一步翻车，后面全崩。

BrowserSkill的“技能”思路是反过来的。它先把常见的网页操作抽象成一个个技能模块，比如“填表”“翻页”“下载文件”“等待元素出现”“处理弹窗”这些。大模型要做的事情，是从技能库里挑选合适的技能进行编排，而不是自己发明轮子。这样做的好处是，每个技能模块内部是确定性的——点击就是点击，填表就是填表，不会出现模型自己编操作的情况。模型只负责决策“这一步该用哪个技能”，不负责设计“技能内部怎么实现”，这就把不可控的空间压到了最小。

这个思路和我之前用RPA的感受很不一样。RPA的流程是“死”的，每一步都写死，改一个页面就得改流程；BrowserSkill的流程是“活”的，模型根据页面状态动态选择技能。但它的“活”又不是无限度的活——技能边界是预设好的，模型只能在边界内组合，这种方式在真实环境里的稳定性远比完全free-form要高。

3. 和Agent Browser、Playwright MCP放一起比，各自的“生态位”在哪

很多人搜BrowserSkill的时候，同时会搜Agent Browser和Playwright MCP，说明大家确实被这几个概念搞糊涂了。这里我先给一个结论性判断：这三样东西根本不在一个抽象层次上，就像拿发动机、变速箱和整台车来比谁更快一样，没有意义。

3.1 BrowserSkill的角色：Agent的“手”

AI Agent的架构通常会分成“大脑”“感知”和“动作”几个部分。大脑是LLM本身，感知是获取环境信息，动作是作用于环境的能力。BrowserSkill更像是动作层的增强包。它不负责思考，不负责规划，它负责让“动作”这件事变得更可靠、更模块化。如果Agent是一台机器人，BrowserSkill就是给它一双经过训练的手，而不是取代它的脑子。

这带来一个天然的好处：BrowserSkill不绑定特定的Agent框架。只要目标环境支持相关协议，它可以作为技能库注册进你的Agent系统。这在我看来是它最聪明的地方——它不想做入口，它想做的是能力输出方。

3.2 Agent Browser的定位：完整的“驱体”

Agent Browser通常指一类能够独立运行的浏览器代理，它自带规划、记忆、执行、反思等完整链路。你给它一个目标，比如“帮我查一下今天上海的天气然后写个简报”，它会自己拆解、调用工具、生成结果。它的核心优势是开箱即用，从0到1极其快，但问题也在这里——你很难控制它在自由决策过程中的行为边界，一旦遇到它没见过的页面，它的行为可能是不可预测的。

用BrowserSkill配合一个轻量级的Agent框架，和直接用Agent Browser是两种路径。前者你可以控制每个技能模块的品质，适合长期维护、需要稳定产出的项目；后者适合快速演示、做概念验证，以及那些容错率比较高的场景。

3.3 Playwright MCP：连接协议，而不是技能

Playwright MCP本质上是一个MCP服务器。它把Playwright常用的浏览器操作能力包装成MCP工具，让任何支持MCP协议的大模型客户端（比如某些桌面AI助手）都能直接调用。它的价值在于“标准化接入”——只要是支持MCP的客户端，都能直接驱动这个浏览器工具。

你可能会问，那BrowserSkill和它是不是可以共存？我的答案是完全可以，而且实际上很互补。Playwright MCP解决了“LLM怎么和浏览器驱动通讯”的问题，BrowserSkill解决的是“LLM调起驱动之后，动作能不能稳定执行”的问题。前者是管道，后者是内容。如果项目里已经接了MCP生态，完全可以在其上叠加BrowserSkill做技能封装。

我个人测试下来的感受是：只用Playwright MCP，模型自由度太高，很容易操作越界；只加BrowserSkill而没有标准协议接入，又需要自己造轮子做集成。两个配合起来，模型走协议调用技能，技能内部做确定性执行，稳定性会有一个质的提升。

4. 本地实操：我是怎么把BrowserSkill跑起来的

下面这部分是真正花时间踩坑之后沉淀出来的。环境是MacBook Pro，Node.js 20，Playwright已经提前装好。过程分几步。

4.1 环境准备——最容易翻车的地方

很多人装BrowserSkill失败，90%的概率问题出在依赖版本。BrowserSkill对Node版本要求比较挑，我一开始用的Node 16，装依赖的时候就报错：engine check失败。后来切到Node 20 LTS，才有进展。

其次，如果你打算用Chromium，记得先执行一次Playwright的浏览器安装。这一步很基础，但经常被遗漏，因为很多项目里Playwright是作为依赖被自动装进去的，却不会自动下载对应的浏览器内核。缺失内核的典型报错是“Executable doesn't exist at ...”，解决办法就一条：跑一遍完整的浏览器安装命令。

还有一个提示，装依赖的时候别急着一把梭，把网络代理之类的环境变量先弄清楚。我遇到过装到一半卡死的情况，后来发现是下载Chromium内核时网络超时。这不是项目本身的问题，但如果你在国内环境拉取，可能要提前准备镜像源或者让安装过程更耐心一点。

4.2 最小示例：让模型完成一次登录操作

装好环境之后，我先跑了一个最简单的demo——让LLM自动登录一个测试站点。配置阶段需要做三件事：注册BrowserSkill的技能库、加载对应的浏览器驱动、把技能列表暴露给LLM的上下文。这里我简化一下核心逻辑，用伪代码描述：

const skills = [ new NavigationSkill(), // 导航 new LocatorSkill(), // 定位 new ActionSkill(), // 点击/输入/下拉 new WaitSkill(), // 等待 new DialogSkill() // 弹窗处理 ]; const agent = new BrowserAgent({ skills: skills, model: "your-llm-config", browserType: "chromium" }); const result = await agent.run("打开登录页，输入testuser/123456，点击登录，截图保存");

整个过程看起来不复杂，但实际上第一次跑的时候，我遇到了一个非常典型的问题。模型在“打开登录页”之后，自作聪明地加了一步“等待页面加载”，而这步和WaitSkill里预设的等待逻辑重复了。结果就是：页面其实早就加载完了，但模型坚持等它想象出来的某个元素，白白多花了十几秒，还偶发超时。

这个现象很有意思。它说明一个问题：当技能本身足够强大时，LLM有时候会过度调用技能，而不是信任技能链路的内部逻辑。解决办法是在描述里加上一条约束——不要在命令里显式要求等待，等待由技能内部处理。调整之后，稳定性立刻上升了一个台阶。

4.3 实测里那几次“诡异失败”的排查链路

跑通demo之后，我开始拿真实业务页面做测试，然后就遇到了几个比较隐蔽的问题。

第一个是元素遮挡。页面里有一个悬浮窗，恰好在要点击的按钮上方。Playwright的click方法默认是等待元素可点击后点击，但如果遮挡元素是动态出现的，这个方法会在超时后失败。BrowserSkill里的ActionSkill自带一个“强制点击”模式，本质上是先通过removeAttribute或者模拟按键绕过遮挡，但逻辑上绕过了，不代表业务上没问题——有时候你绕过悬浮窗点了底下的按钮，但业务上其实需要先处理悬浮窗。这个边界需要自己做取舍，没有万能解法。

第二个是页面跳转导致的上下文丢失。我们的场景里，登录成功后会跳到一个新标签页。如果Agent在登录之后继续在新页面操作，但你只维护了一个Page对象，跳转后继续操作就会定位到已经不存在的元素，报一大堆frame/context错误。排查这个问题的思路是：在技能编排里加上“等待URL变化”的能力，跳转后重新获取页面上下文。这种问题本身不难，难在定位到根因——因为报错信息里显示的失败点是“元素未找到”，不看浏览器状态根本想不到是页面对象的问题。

第三个是浏览器指纹和反爬策略。如果你要自动化的是真实生产环境，而不是测试站点，迟早会遇到各种验证机制。BrowserSkill本身不解决反爬问题，它只是一个技能框架。遇到账号风控、行为验证这种东西，需要你在上层做更多的策略设计，比如更自然的操作延时、更合理的操作路径，这些就不是装个库能解决的了。

4.4 一点点性能观察

跑通之后我顺手统计了一下token消耗。一个完整的“登录→查询→导出”流程，如果只给模型高层的技能描述，上下文开销大概在3000~5000 token之间。相比直接把HTML页面丢给模型，这个数字省下了一个量级的空间。更关键的是，技能描述是静态的，可以预编译缓存，而页面HTML每次都要重新抓取。这也意味着模型能更专注在决策上，而不是浪费token在处理满屏的页面源码里。

5. 再深入一层：技能编排和复杂任务的错误恢复

如果你只是单步骤操作，BrowserSkill跟普通的自动化库没有本质区别，甚至会觉得是绕弯路。它的价值要在“编排”层面才体现出来——多个技能怎么组合、出错之后怎么恢复。

5.1 复杂任务如何拆解成技能组合

我们试过一个更复杂的任务：从系统A导出上个月的销售数据，去重后导入系统B，并且在导入完成后，去系统C更新状态。

这个任务如果让模型完全自由发挥，来来回回需要几十步，每一步的失败率累加起来，整个任务的成功率就会掉到不能看。BrowserSkill的做法是把任务拆成三段技能序列：A系统的“导出技能→轮询文件生成→定位下载文件”，B系统的“导入技能→读取文件解析→逐行校验→批量提交”，C系统的“状态更新技能→查找记录→修改字段→保存”。每一段技能序列内部是确定性的，模型只负责在段落之间做决策，比如“文件格式不对时，走错误处理分支”。

这种“段落式编排”极大地降低了复杂度。模型不需要精确到每一步怎么点鼠标，只需要决定流程走向。这就像项目经理只负责安排阶段任务，具体的施工细节交给班组负责人。

5.2 错误恢复的套路

真实运行中最常遇到的是“预期外状态”。比如表单提交失败，页面弹了一个固定文案的报错框。如果Agent没有对应的错误处理技能，它可能会卡在同一个动作上反复尝试。

我规避的办法是给技能编排加上一层“状态判定”。执行完一个技能后，立刻校验一个关键元素（比如成功提示、URL变化、某个数据字段），判定结果是成功还是失败。失败时不是让模型“反思后重试”，而是先拉取页面上的报错信息，把报错信息回传LLM做分析。这个做法的关键点在于：错误信息和页面上下文的获取必须是技能内部的确定性动作，不能依赖LLM去“读取”页面。LLM一旦读了整个页面，它可能又会产生幻觉。

5.3 一个关于“重试”的教训

还有一个让我印象深刻的教训。某个技能在极端情况下会偶发超时，我在编排里给技能加了一个“重试三次”的逻辑。结果某次运行，前两次真的都是瞬断超时，第三次成功了。看起来重试策略有效？但是后来看日志发现，第一次其实是网络抖动，第二次是目标页面临时卡顿，第三次虽然成功了，但耗时已经超过了业务允许的时限。

这件事给我提了个醒——重试不是银弹。重试只能应对“瞬时故障”，如果是由于脚本逻辑缺陷、页面结构变化导致的持续性失败，重试一万次也没用，反而浪费资源。正确的做法是先做失败根因分类：网络错误可以重试，元素不存在要重新定位，业务异常要停下来人工介入。这个分类逻辑同样应该放在技能内部，而不是让LLM临时决定。

6. 项目落地时的三个关键习惯和两个“不要用”场景

说了这么多技术细节，最后聊点工程实践层面的东西，都是我在实际项目里真正受益或者受过教训的地方。

6.1 习惯一：把技能描述写成“人能看懂的操作说明书”

LLM决定何时调用某个技能，靠的是技能描述文本。描述写得好不好，直接影响模型的选择准确度。一开始我把技能描述写得很技术，比如“使用XPath定位器查找特定元素”，模型经常会在不太需要精确定位的时候也触发技能。后来我改成面向场景的描述，比如“当需要点击页面上的按钮时，使用此技能”，准确率反而显著提升。原因很简单，LLM是被自然语言训练的，它理解“按钮”比理解“XPath定位器”更容易。

6.2 习惯二：所有技能必须有“可观测的输出”

BrowserSkill里每个技能执行完，尽可能返回结构化结果——操作成功的布尔值、耗时、关键元素的快照、错误信息。不要只返回“成功”两个字。因为后续模型判断流程走向时，依赖的就是这些结构化反馈。反馈越丰富，模型决策越精准。我一开始偷懒，很多技能只返回“ok”，结果模型经常在流程中间“迷路”。

6.3 习惯三：保持技能的“单一职责”

一个技能只做好一件事。不要写一个“处理所有弹窗”的万金油技能，而是拆成“关闭广告弹窗”“处理Cookie同意框”“处理确认对话框”几个独立技能。原因很简单——单一职责的技能更容易测试，更容易复用，也更容易让LLM准确理解。而且一旦某个弹窗类型处理后不需要了，删除时不会影响其他技能。

6.4 什么场景下不要用BrowserSkill

第一个不适合的场景是：你的业务流程极其固定，几乎不会有页面变化。这种情况用传统RPA或者Playwright写死脚本，性能更好、调试更方便、依赖更少。给大模型加了一套技能系统，等于放着大炮打蚊子，还引入了token开销。

第二个不适合的场景是：目标网站对自动化极其敏感，有严格的风控体系。任何浏览器自动化工具在这种环境下都会被识别，BrowserSkill不会给你免死金牌。这种业务场景，优先考虑合规的API/数据服务协议，而不是用自动化绕过平台限制。

第三个场景可能有点反直觉：如果团队里没有人熟悉Playwright这类底层框架，我建议先别直接上BrowserSkill。这个项目虽然封装得很好，但底层出问题时，你还是需要理解浏览器驱动的基本原理。如果一个技能执行失败，连获取调试堆栈都无从下手，那这个工具会变成一个黑盒，出了问题全是黑洞。

7. 后续扩展的方向

现在这个项目还在快速迭代，我比较关注的方向有三个。一是多模态技能的增强，现在纯文本技能已经很完善，但桌面端软件的自动化可能还要依赖更多视觉能力；二是技能编排图的持久化——如果能把模型编排好的技能序列缓存下来，下次类似任务直接复用，长期跑下来能省不少token；三是和各Agent框架的官方适配，目前还需要自己写一些胶水代码，如果官方直接内置适配器，接入成本会进一步下降。

最后再分享一个小技巧。我在跑BrowserSkill的Agent时，习惯在每次任务结束前，让模型把实际用到的技能序列和参数记录到一个日志变量里。这看起来不起眼，但积累一周之后，你就能统计出哪些技能是高频使用的、哪些组合最稳定。这个数据用来反哺你的技能编排，效果比看任何官方文档都好。