企业官网建设流程全解析

1. 从"能聊天"到"能上网"：AI智能体到底缺了什么

过去一年里，我接触过不少做AI智能体的团队，大家普遍卡在同一个地方：模型本身推理能力已经够用了，但一旦让它去完成"帮我查一下某个开源库最新的版本号""去某个网站看看这个商品现在有没有货""帮我把这个页面的表格数据抓下来"这类任务，它就开始胡言乱语。原因很简单，绝大多数智能体本质上还是在一个封闭的沙箱里运转，它能调用的只有你预先写好的那几个函数，一旦超出这个范围，它就彻底抓瞎。

Agent Browser这个项目之所以能在开源社区里迅速积累关注度，核心就在于它试图解决一个非常具体、非常痛的问题：让AI智能体真正具备"上网"的能力。注意这里的"上网"不是简单地调用一个搜索API然后把结果塞进上下文，而是让智能体像人一样去操作浏览器——打开页面、点击按钮、填写表单、滚动加载、读取页面内容，甚至处理登录态和Cookie。这套能力一旦打通，智能体能做的事情就从"回答问题"跃迁到了"完成任务"。

这篇文章适合几类人看：一是正在做AI Agent产品、被"如何让Agent访问外部信息"卡住的开发者；二是对浏览器自动化有经验、想把它和LLM结合起来的工程师；三是产品经理或者技术负责人，想搞清楚这类方案到底能落地到什么程度、坑在哪里。我会从整体设计思路讲起，然后拆解核心实现细节，再给出一套可以照着复现的实操流程，最后把我踩过的坑和排查经验整理出来。全文基于我对这类项目的理解和实际动手经验，涉及具体实现的部分会说明这是基于常见实践的合理补充。

先说结论：Agent Browser这类项目的价值不在于它用了多新的技术，而在于它把"浏览器自动化"和"LLM决策"这两件事的接口设计得足够干净，让智能体可以在一个受控的环境里自主完成多步网页操作。这个思路本身不复杂，但工程细节非常多，下面一点点拆。

2. 整体设计思路：为什么是"浏览器"而不是"API"

2.1 核心矛盾：API覆盖不了长尾需求

做智能体的人一开始都会想：我直接给Agent接一堆API不就行了？搜索有搜索API，天气有天气API，电商有电商开放平台。这个思路在小范围内可行，但很快就会撞墙。原因有三个。

第一，API的覆盖面远远不够。互联网上绝大多数信息并没有开放API，很多中小网站、内部系统、政府公开数据页面，只有网页形式。你不可能为每一个目标站点都写一个适配器。

第二，API的维护成本极高。接口会变、鉴权会变、限流策略会变，你写一百个适配器，就要维护一百个随时可能失效的依赖。

第三，很多任务本身就是"人机交互式"的。比如填写一个多步表单、处理一个需要点击展开的列表、应对一个弹窗确认，这些用API很难表达，但用浏览器操作就是天然契合的。

Agent Browser选择浏览器作为智能体的"手和眼"，本质上是用通用性换取了确定性。浏览器能访问的东西，智能体理论上都能访问；代价是操作变得不确定，需要更强的决策和容错机制。

2.2 架构分层：把"决策"和"执行"彻底分开

我看过不少同类项目的源码，做得好的都有一个共同特征：分层清晰。Agent Browser这类项目通常会把系统拆成三层。

最上面是决策层，由LLM负责。它接收当前页面的状态描述（通常是简化后的DOM或者可访问性树），结合任务目标，输出下一步动作，比如"点击id为submit的按钮""在搜索框输入关键词""向下滚动一屏"。

中间是动作层，负责把LLM输出的自然语言动作翻译成具体的浏览器操作指令。这一层要做参数校验、元素定位、等待策略、重试逻辑。

最下面是执行层，通常基于Playwright或者Puppeteer这类浏览器自动化框架，真正去驱动浏览器。

这么分的好处是：决策层可以换模型，执行层可以换框架，动作层是稳定的胶水。我见过有人把这三层揉在一起写，结果换一个模型整个项目就要重写，非常痛苦。

2.3 状态表示：给LLM"看"什么决定了成败

这是整个项目里最容易被低估、也最影响效果的部分。浏览器里一个真实页面的DOM可能有几万个节点，你不可能把原始HTML全塞给LLM，token爆炸不说，模型也会被噪声淹没。

常见的做法是把页面转换成一个简化表示。有两种主流思路：一种是提取可交互元素（按钮、输入框、链接）加上它们的文本和位置，生成一个编号列表；另一种是使用浏览器提供的可访问性树（Accessibility Tree），它天然过滤掉了大量样式和布局噪声，保留了语义结构。

我实测下来，对于表单填写、点击类任务，可交互元素列表的方式更直接，因为LLM看到的就是"1. 搜索框 2. 搜索按钮"这种它容易理解的形式。对于需要理解页面整体内容的抓取类任务，可访问性树或者正文提取算法效果更好。做得好的项目会同时提供两种视图，让智能体根据任务类型选择。

提示：状态表示的设计直接决定了智能体的成功率。如果你的Agent总是点错元素，先别怀疑模型，去看看你喂给它的页面表示是不是太乱或者信息缺失。

3. 核心细节拆解：让智能体"看得懂、点得准"

3.1 元素定位：为什么不能只靠CSS选择器

新手最容易犯的错误是让LLM直接输出CSS选择器或者XPath。理论上可行，实际上非常脆弱。LLM生成的XPath经常是这种形式：//div[3]/div[2]/button[1]，这种路径依赖具体DOM结构，页面稍微改版就失效，而且模型自己也经常算错层级。

更稳的做法是基于语义和可见文本定位。比如让LLM输出"点击文本为'提交订单'的按钮"，动作层再用文本匹配加上角色过滤去找到真实元素。Playwright的get_by_role和get_by_text就是为这种场景设计的，它比CSS选择器稳定得多。

如果页面上有多个相同文本的元素，就需要引入额外的消歧信息，比如位置（第几个）、附近的标签文本、元素的属性。我一般会让状态表示里给每个可交互元素一个稳定的编号，LLM只需要输出编号，动作层通过编号反查元素。这样把"定位"这个难题从LLM手里拿走，交给确定性的代码处理，成功率会高很多。

3.2 等待与同步：异步页面的老大难

现代网页大量使用异步加载，你点了一个按钮，内容可能300毫秒后才出现，也可能3秒后才出现。如果动作层点完就立刻去读页面，读到的往往是旧状态。

处理这个问题有三层策略。第一层是显式等待，操作后等待某个特定条件满足，比如某个元素出现、某个网络请求完成。第二层是智能轮询，在合理超时内反复检查页面是否稳定（比如DOM在连续两次检查间没有变化）。第三层是动作后快照对比，操作前后各取一次页面状态，如果没变化就认为操作可能失败了，触发重试或者让LLM重新决策。

我踩过的一个坑是：有些页面加载完成后还会有一个短暂的动画或者骨架屏，DOM看起来"稳定"了但其实内容还没渲染。这种情况纯靠DOM变化判断会误判，需要结合网络空闲状态或者固定延时兜底。实测下来，网络空闲加一个200到500毫秒的缓冲，能覆盖绝大多数场景。

3.3 上下文管理：多步任务怎么不"失忆"

一个任务往往需要十几步操作，每一步都会产生新的页面状态。如果每一步都把完整历史塞给LLM，token会迅速膨胀，而且模型容易被早期无关信息干扰。

常见的做法是维护一个压缩后的操作历史：只保留每一步的动作摘要和关键结果，比如"第1步：在搜索框输入'关键词'，成功""第2步：点击搜索按钮，成功，结果页有10条记录"。完整的页面快照只在当前步使用，用完就丢。

另外要处理任务中断和恢复。浏览器可能崩溃、页面可能超时、网络可能抖动。好的实现会把每一步的状态持久化，支持从断点继续，而不是从头再来。这在长任务里非常关键，我见过一个抓取任务跑了二十分钟，最后一步失败导致全部重来，非常浪费。

3.4 安全边界：给智能体划红线

让AI自主操作浏览器，风险是实打实的。它可能误点删除按钮、可能把敏感信息填到错误的表单里、可能访问到不该访问的页面。所以必须有一套约束机制。

我一般会做几件事：一是动作白名单，只允许点击、输入、滚动、导航这几类基础动作，禁止执行任意脚本；二是域名白名单，限制智能体只能访问预先批准的站点；三是敏感操作二次确认，对于提交表单、删除、支付这类动作，要么禁止，要么要求人工确认；四是输入内容过滤，防止智能体把上下文里的敏感数据填到外部表单。

注意：千万不要在生产环境里让智能体无限制地自主操作浏览器。哪怕模型再聪明，也会有幻觉，而浏览器里的误操作代价可能是不可逆的。

4. 实操复现：从零搭一个能上网的智能体

4.1 环境准备与依赖选型

先说技术栈。浏览器自动化我推荐Playwright，它对现代浏览器的支持好，API设计清晰，自带等待机制，而且支持多种语言。Python生态里它和主流LLM SDK配合得很顺。

基础依赖大致是这些：Playwright本体加浏览器内核、一个LLM的调用库、一个用于解析HTML的库（比如BeautifulSoup或者直接用Playwright自带的选择器）、再加一个轻量的Web框架如果你想把它做成服务。

安装步骤不复杂，但有个细节要注意：Playwright的浏览器内核需要单独下载，国内网络环境下这一步经常卡住，建议提前配置好镜像源或者离线包。我一般会把浏览器内核的安装单独做成一个初始化脚本，避免每次部署都重新下载。

pip install playwright playwright install chromium

选Chromium而不是完整Chrome，是因为它体积小、启动快，对于无头场景足够用。如果你需要处理一些对浏览器指纹敏感的场景，可能要考虑带界面的模式或者额外的配置，但这属于进阶话题。

4.2 页面状态提取的实现

这是核心中的核心。我写一个简化版的提取逻辑，思路是遍历页面上所有可交互元素，给它们编号，提取文本、角色、可见性等关键信息。

def extract_interactive_elements(page): elements = [] selector = "a, button, input, select, textarea, [role='button'], [onclick]" nodes = page.query_selector_all(selector) idx = 0 for node in nodes: if not node.is_visible(): continue text = (node.inner_text() or "").strip()[:50] role = node.get_attribute("role") or node.evaluate("el => el.tagName.toLowerCase()") placeholder = node.get_attribute("placeholder") or "" elements.append({ "id": idx, "role": role, "text": text, "placeholder": placeholder }) idx += 1 return elements

这段代码有几个要点。第一，只保留可见元素，隐藏的元素对智能体没意义还占token。第二，文本截断到50字符，避免超长文本撑爆上下文。第三，同时提取role和placeholder，因为很多输入框没有文本，只有placeholder，这是定位它的关键线索。

提取完之后，把这些元素格式化成LLM容易读的文本，比如每行一个"编号. 角色 - 文本/占位符"，然后拼进提示词里。

4.3 决策提示词的设计

提示词决定了LLM输出的稳定性。我的经验是：输出格式要极度约束，动作空间要明确列举，禁止自由发挥。

一个可用的提示词骨架是这样的：先描述任务目标，然后给出当前页面URL和标题，接着列出可交互元素，最后明确要求"只能从以下动作中选择一个，并以JSON格式输出"。动作集合我一般限定为click、type、scroll、navigate、extract、finish这几种。

{ "action": "click", "element_id": 3, "reason": "这是搜索按钮" }

要求模型输出reason字段是个小技巧，一方面便于调试时理解它的决策逻辑，另一方面强制它"想一下再动手"，实测能降低误操作率。但要注意，reason不要回灌到下一轮的上下文里，否则会累积噪声。

4.4 主循环的编写

主循环的逻辑其实很朴素：取状态、问模型、执行动作、判断是否结束、循环。难点全在异常处理上。

def run_agent(task, max_steps=20): page = launch_browser() history = [] for step in range(max_steps): state = extract_interactive_elements(page) prompt = build_prompt(task, page.url, state, history) decision = call_llm(prompt) try: result = execute_action(page, decision, state) history.append(summarize(decision, result)) except Exception as e: history.append(f"第{step}步失败：{str(e)}") continue if decision["action"] == "finish": break return history

几个关键点：max_steps必须设上限，防止死循环烧钱；每一步的异常要捕获并记录到history里，让模型知道上一步失败了，它下一轮可能会换个策略；history只存摘要不存完整快照。

4.5 参数选择与调优

超时时间我一般设成页面加载30秒、元素等待10秒、单步动作5秒。这些值不是拍脑袋来的：30秒覆盖绝大多数页面的加载，10秒足够异步元素出现，5秒是防止某个动作卡死。

重试次数上，单个动作失败重试2次，整个任务失败不自动重试（因为可能是任务本身不可行）。温度参数建议设低，0.1到0.3之间，因为网页操作需要确定性，不需要创造力。模型选择上，能力强的模型在复杂页面上优势明显，但简单任务用小模型能省不少成本，可以做一个任务复杂度判断来动态选择。

5. 常见问题与排查技巧实录

5.1 智能体反复点同一个元素

这是最常见的症状。原因通常是操作后页面没有明显变化，模型以为没成功就再点一次。排查思路：先看动作执行后页面状态有没有变，如果没变，检查是不是点击被遮挡、是不是需要先滚动到可视区域、是不是有弹窗挡住了。解决办法是在动作层加一个"操作后状态对比"，如果状态没变，就在history里明确告诉模型"上一步点击后页面无变化，请尝试其他方式"。

5.2 元素定位失败

模型说点编号5，但动作层找不到对应元素。这通常是因为页面在提取状态和执行动作之间发生了变化，编号错位了。解决办法是缩短这个时间窗口，或者在执行前重新校验元素是否还存在，不存在就重新提取状态让模型再决策一次。

5.3 陷入无限滚动

有些页面是无限加载的，模型为了找某个内容一直往下滚。要在提示词里明确告诉它"最多滚动N次"，或者在动作层统计滚动次数，超过阈值就强制让它基于当前内容做判断。

5.4 登录态丢失

需要登录的站点，如果每次启动都是全新会话，智能体永远进不去。解决办法是持久化浏览器上下文，把Cookie和localStorage存下来复用。Playwright的storage_state功能就是干这个的。

5.5 几个独家避坑经验

第一，不要在提示词里放太多历史。我一开始把每一步的完整页面状态都塞进去，结果模型被早期信息干扰，经常回到已经完成的步骤。后来改成只放动作摘要，效果立竿见影。

第二，给元素编号比给选择器靠谱十倍。这个前面说过，但值得再强调，因为它是最容易改、收益最大的一个调整。

第三，失败信息要具体。不要只写"操作失败"，要写清楚是超时、是元素不存在、还是被拦截。模型拿到具体错误才能做出正确调整。

第四，准备一个"放弃"动作。当模型判断任务无法完成时，允许它主动结束并说明原因，比让它硬撑到步数上限要好得多，既省成本又便于分析。

第五，日志要记全。每一步的输入状态、模型输出、执行结果、耗时都记下来。调试的时候你会发现，没有完整日志根本没法定位问题出在哪一层。

这套东西我前后调了两三周才稳定下来，最大的体会是：让AI上网这件事，模型能力只是其中一环，工程上的状态管理、错误处理、边界约束才是决定能不能真正落地的关键。Agent Browser这类项目给了一个很好的起点，但真要用于生产，上面这些细节一个都省不了。后续如果要做多标签页协同、要做跨站点的任务编排，复杂度还会再上一个台阶，那是另一个话题了。