企业官网建设流程全解析

1. 为什么要让智能体控制你的本机浏览器

先说清楚这个项目到底在做什么。所谓"智能体连接本地浏览器"，不是给浏览器装个AI助手插件那么简单，而是搭一条完整链路：本地大模型负责思考决策，浏览器自动化层负责看页面、点按钮、填表单，整个推理和执行过程都在本机完成，不依赖任何云端接口。做过AI自动化的人心里都有数——会聊天的机器人满街都是，真正能动手干活的寥寥无几。为什么偏要选浏览器当载体？因为今天几乎所有的业务流程都长在网页里：查资料、填报表、订会议室、处理工单、抓数据……这些场景里开放API的没几个，但浏览器统统能访问。给智能体装上眼睛和手，它的落地价值一下子就不一样了。

这个方向适合谁？一类是想把智能体接进自己办公流程的开发者，一类是研究Agent落地但不想被云端服务绑定的人，还有一类是手里有张过得去的显卡、想物尽其用的折腾型玩家。如果你连大模型都没部署过也不怕，这篇文章默认你是零基础，先带你跑通环境，再讲优化思路和踩坑经验。

1.1 智能体缺的不是大脑，是"眼睛"和"手"

这句话不是比喻，而是这套方案的真正核心。现在的智能体框架普遍能对话、能推理、能调用API，可一旦面对真实网页，就成了"有脑无力"的状态：不知道页面上有哪些元素，也没办法替你完成点击、滚动、填表这些操作。浏览器恰好补齐了两头——页面的DOM结构和截图可以当模型的"眼睛"，Playwright或CDP这类自动化协议可以当模型的"手"。两者一拼，智能体就从"建议器"变成了"执行者"。

这里有个容易被新手忽略的点：整条链路里最脆弱的不是模型，而是你喂给模型的信息形式。同一个网页，你可以把整个HTML都丢给它，也可以压缩成"带编号的可交互元素列表"，后者的理解准确率会高出一大截。所以这套方案的工程重心，一半在浏览器控制，另一半在页面信息压缩，后面实操部分我会重点展开这两块。

1.2 本地化到底换来什么

"本地"两个字，是我做这个项目最看重的点。道理很朴素：我的公司内网后台、我的个人网银页面、我要填写的内部表单，这些内容压根不适合发到别人家的模型服务器上。本地部署之后，网页内容、Cookie会话、操作记录全部留在自己机器里，这一点对很多业务场景是硬性需求，没有任何讨论余地。

第二个理由是成本结构。云端智能体按token计费，如果让Agent在网页上反复探索，一轮任务烧掉几千个token是常事，高频使用下来费用相当可观。本地7B模型虽然单次推理不如云端聪明，但它属于固定成本，跑到天荒地老也就是几度电钱，特别适合反复试错、调参、跑批量任务的时候用。实测下来，一次浏览器任务如果走云端API可能花掉几毛到几块钱，本地部署几乎零边际成本。

第三点，也是很多教程不会重点提的：延迟和稳定性完全由你控制。云端接口随时可能抖动、限流，而本地模型只要你机器不崩，再长的prompt也就是排队的问题，不会突然给你断开连接。这种"确定性"在调试期极其珍贵——你可以把变量都归因到模型能力上，而不是网络波动上，排查问题能省一半时间。

2. 技术方案拆分与选型

动手之前先把方案理清楚。我拆成三层：大脑层是本地大模型，控制层是智能体框架，手眼层是浏览器自动化。三层各有一个选型问题，选对了能省下大把时间，选错了就是你后面不断返工的根源。

2.1 三条主流路线怎么选

我实际对比过三条路线：纯自研Agent、用Browser-use、用Dify这类可视化平台加MCP工具。三者没有绝对好坏，看你要什么。

纯自研：用LangChain/LangGraph搭一个"模型推理-工具调用-观察结果"的循环，再自己写浏览器工具封装。灵活度最高，适合做深度定制，但通信协议、上下文管理、重试机制、DOM压缩全得自己写。我第一个版本是这么干的，跑通花了三天，维护成本确实高。

Browser-use：专门的"让LLM操作浏览器"开源库，把DOM压缩、截图观测、工具定义都封装好了，还能直接对接LangChain的ChatOpenAI接口。它是我目前最推荐的主力方案，几行代码就能跑通最小闭环，后面你会看到代码量到底有多小。

Dify + MCP：可视化编排工作流，浏览器工具通过MCP协议暴露给智能体，适合快速做一个产品化界面给非技术用户用。但复杂任务的控制流表达力不如代码，调试起来也不如直接写代码直观，更适合后期封装交付。

我最后选了Browser-use当主力，原因只有一个：它把"页面信息压缩"这个最脏最累的活做完了。别在早期阶段什么都自己造轮子，先把闭环跑通，再决定哪些部分要替换成自研，这才是务实路线。

2.2 本地模型选型与硬件门槛

模型选择决定了这个项目的任务上限。我的建议顺序是：先选带原生tool calling能力的模型，再看参数量。为什么反复强调tool calling？因为智能体每走一步，模型都要输出"调用什么工具、传什么参数"的结构化指令。如果模型不支持原生function calling，只能在对话里吐JSON文本再靠代码解析，不仅容易格式出错，多步循环里解析失败几次，整个任务基本就废了。

目前本地跑下来比较顺的推荐：Qwen2.5系列（7B和14B），它的function calling在中小参数模型里算很稳的；DeepSeek的模型在纯推理任务上很强，但在浏览器操作这类需要高频工具调度的场景里，稳定性需要额外调。如果你显存充足，可以直接上32B甚至更大，效果会有明显提升，但硬件门槛呈几何级上升。

硬件门槛大概是这样：纯8GB内存的机器只能勉强跑3B以下模型，能用但成功率可怜；16GB内存配一块12GB显存的显卡，跑7B量化版就很舒服了。我主力机器是24GB显存，跑14B模型加GPU加速，一个从搜索到提取内容的完整任务大概十几秒，属于可接受范围。

2.3 浏览器连接方式：受控实例还是远程调试端口

浏览器自动化有两类接法。一类是用Playwright启动受控Chromium，每次从零创建干净实例；另一类是通过CDP协议连接外部浏览器，最常见的就是给浏览器加--remote-debugging-port=9222启动，然后从Playwright里connect_over_cdp接上去。

两者的核心取舍是这样：受控实例干净、环境可控，但默认没有你的Cookie，遇到登录墙就会卡住，很多网页功能都体验不到。CDP外连却能复用浏览器会话，智能体可以直接操作你已经登录好的后台系统，这把它最大的吸引力放大了——你平常登录好的系统，Agent直接就能操作，不用做任何登录适配。

我现在的推荐组合是：固定一个"智能体专用profile"的浏览器目录，用CDP启动它，先手动登录一次目标站点，以后智能体每次会话都连这台浏览器复用登录态。这样做既保住了CDP的优势，又不会拖累你日常使用的浏览器。这里有个非常容易踩的坑：直接用命令行启动Chrome时，如果该用户目录下已经有浏览器进程在跑，新命令会直接把端口配置忽略掉，导致CDP连接失败。解决办法就是给智能体单独建一个用户目录，并且确保这个目录下没有已经运行的实例，后面实操部分我会给出完整命令。

3. 环境准备：先把地基打好

3.1 部署本地模型服务

模型服务我直接用Ollama，理由就两个：安装简单、自带OpenAI兼容API。一条curl命令装完，然后拉模型。

# 安装Ollama curl -fsSL https://ollama.com/install.sh | sh # 拉取适合本地部署的模型，我建议起步用qwen2.5:7b ollama pull qwen2.5:7b # 启动服务，默认监听11434端口 ollama serve

验证API是否正常：打开终端执行curl http://localhost:11434/v1/models，能看到模型列表就说明服务没问题。这套API是OpenAI兼容格式，意味着后续所有接OpenAI SDK的代码，只要把base_url改成本地地址就能直接跑。

我建议再装一个进程管理器，或者至少让ollama开机自启。不用systemd，就最简单的方式：开发机上终端挂着ollama serve，但真正长期用，还是注册成系统服务省心，不然重启机器后忘了拉服务，调试半小时才反应过来就尴尬了。如果你机器的防火墙开着，记得放行11434端口，局域网里别的机器也能共用这个模型服务。

3.2 创建Python环境并安装浏览器自动化依赖

我习惯用虚拟环境隔离，避免把系统Python搞得一团乱。然后是安装依赖：

python -m venv agent_env source agent_env/bin/activate # Windows下用 agent_env\Scripts\activate pip install browser-use playwright langchain-openai # 安装Playwright的Chromium内核 playwright install chromium

注意，如果你跑在Linux服务器上，还得装系统依赖库，通常执行一次playwright install-deps能解决，运气不好就得逐个补。开发阶段我强烈建议用有头模式，亲眼看智能体在页面上的每一步操作，比对着日志猜位置有感觉得多。服务跑通后再切headless，反正就改一个参数的事。

这套依赖组合里，langchain-openai是为了让ChatOpenAI类可以把base_url指到Ollama，这是连接本地模型和Browser-use的关键桥梁。版本冲突倒是没遇到太大问题，如果你的browser-use比较新，API可能有细微变化，遇到报错先看看当前版本，别照抄旧教程。

4. 实操：跑通"本地模型 + 浏览器"完整链路

4.1 用Browser-use实现最小可用版本

环境就绪后，核心代码其实不到20行。先初始化一个能连接Ollama的大模型对象，再交给Agent执行任务：

import asyncio from browser_use import Agent from langchain_openai import ChatOpenAI # 把大模型指向本地Ollama服务 llm = ChatOpenAI( model="qwen2.5:7b", base_url="http://localhost:11434/v1", api_key="ollama", # Ollama不校验key，随便填 temperature=0, max_tokens=2048, ) task = ( "打开必应，搜索'智能体本地部署'。" "把搜索结果前3条的标题和链接保存到本地文件 result.txt" ) async def main(): agent = Agent(task=task, llm=llm) history = await agent.run(max_steps=10) print(history) if __name__ == "__main__": asyncio.run(main())

跑这个脚本，你会看到浏览器被自动打开、输入关键词、点击搜索、读取结果、写文件。第一次成功跑通的那个瞬间，还是挺有成就感的。这里有一个写任务的分寸问题：任务太宽泛（比如"帮我查资料"）模型会陷入迷茫，太细又失去智能体自由编排的意义。我习惯给任务加三层信息：目标、条件、产出。比如刚才的例子，"搜索什么、取几条、存哪"都交代清楚，模型发挥空间和确定性就有了平衡。

4.2 让智能体操作你已登录的浏览器

最小版本跑通后，就轮到最能打的场景了：让智能体操作你已登录的系统。以Chrome或Edge为例，先这样启动一整套CDP浏览器：

# 建一个专门给智能体用的浏览器目录 mkdir -p ~/agent-browser-profile # 用独立用户目录启动浏览器，开放9222调试端口 chromium --remote-debugging-port=9222 --user-data-dir=$HOME/agent-browser-profile

然后把Browser-use指向这台浏览器：

from browser_use import Browser, BrowserConfig, Agent browser = Browser( config=BrowserConfig( headless=False, cdp_url="http://localhost:9222", ) ) async def main(): agent = Agent( task="在已经登录的管理后台页面里，找到今天的订单列表，导出为CSV文件", llm=llm, browser=browser, ) await agent.run(max_steps=20)

一旦成功连上，你的本地模型就拥有了"会登录的浏览器操作权"。我第一次用它在公司内网里跑报表的时候，彻底理解了这个项目的价值——早晨上班让它打开后台、点导出、丢到指定目录，整个过程不需要任何人介入。需要注意的是，刚才我们专门给Agent建了独立的用户目录，这意味着登录态要和日常浏览器分开维护：第一次先在这个浏览器里手动登录一次目标系统，之后Cookie就留在这个目录里了，后续所有Agent任务都能复用。

4.3 提升任务成功率的三个关键参数

跑了几十次之后，我总结出三个对成功率影响最大的参数，几乎全在大模型API这一层。第一个是temperature必须设为0。智能体任务要的是确定性，温度越高，模型越容易给你输出意想不到的步骤，浏览器操作可不容许"自由发挥"。我见过temperature=0.7时它突然决定"顺便"点开一个广告页，然后整个任务逻辑就乱了。

第二个是max_tokens要给足。模型一次要输出工具调用参数加理由说明，如果截断，JSON输出直接断在中间，解析必然失败。我在使用qwen2.5:7b时一般给2048，14B的模型给到4096也不心疼，反正都在本地跑。

第三个是max_steps不能太大也不能太小。太大模型会在页面上绕圈，任务迟迟不结束；太小可能任务没做完就自认为完成了。我起步用10，复杂任务放到20，并且总在task末尾加一句兜底："如果找不到目标，尝试换一种方式或告诉用户存在问题"，这比默认的傻循环强很多。

另外还有个容易被忽略的点：页面信息层。实测过很多次，把上千行原始DOM塞给模型，和只给压缩过的可交互元素列表，任务成功率能差三成以上。Browser-use默认就帮我们做了这层压缩，这也是我推荐它的核心原因。如果你想精细控制，也可以自己封装DOM提取逻辑，只把input、button、a标签的特征传下去。

5. 实战中踩过的坑与排查思路

5.1 模型不调用工具怎么办

最典型的现象：你下达"搜索关键词"指令，模型却只输出一段文字，告诉你"我应该去搜索"，然后任务原地踏步。这通常不是智能体框架的问题，而是模型没进入工具调用模式。

排查顺序是这样的：先确认你连的base_url确实是Ollama，直接向http://localhost:11434/v1/chat/completions发一个带tools参数的请求看返回结构；然后确认模型版本是否支持tool calling，Qwen2.5系列在7B以上都支持，部分太小的模型确实不行；最后检查system prompt，如果你设置了很长的角色说明，试试在prompt里加一句"你必须使用工具来完成用户的任务，不得只做建议"，工具调用频率会明显上升。

还有一个烦人的情况是模型调用了工具但参数传错，比如把input_text写成text。这种问题只能靠模型迭代和工具描述解决，把工具参数描述写得越详细，这类错误越少。我见过有人为了让模型不传错参数，把参数名改成search_word，反而出错率更高——因为工具定义里的描述字段才是模型真正依赖的信息，参数名只起辅助作用。所以不要再纠结命名了，重点写清楚描述。

5.2 页面状态不稳定与DOM信息过载

第二个高频坑是"智能体找错了元素"。同一个按钮，有的页面渲染快有的渲染慢，模型在DOM还没加载完时就急着找，自然扑空。Browser-use内部有等待机制，但具体等多久是个博弈：等太短元素没出现，等太长任务效率又低了。我的处理方式是给长加载页面预设提示词，比如"登录按钮可能延迟出现，如果找不到，请先等待3秒再查找"，实测这类提示对成功率有非常明显的帮助。

DOM过载问题更多发生在后台系统里。一些复杂的后台页面包含几十个表格、隐藏弹窗脚本，压缩后仍然有几万token，本地模型上下文窗口一旦被截断，后面每一步都会变得迷迷糊糊。对策就是给模型更小的观察视图：优先使用"只看可见区域"，实在不行让程序先把input和button这类可交互元素筛出来再交给模型，效果立竿见影，代价是损失一点上下文关联性。

5.3 常见问题速查表

这张表基本覆盖了第一周调试会遇到的问题。遇到奇怪现象先别怀疑人生，把日志级别调到DEBUG，看模型每一步究竟拿到了什么页面内容、输出了什么指令，问题一般很快就能定位。

6. 从Demo到日常可用，我想说的几句经验

6.1 先给智能体划定安全边界

把真实浏览器交给AI之前，先定几条铁律：不执行任何需要支付确认的任务，除非你设计了人在回路环节；不让模型访问你手动指定的范围之外的网页；所有高风险任务必须带一个"暂停键"。我在方案里加了一个规则：任何一步如果模型连续三次报错，整个任务就自动挂起等人工介入，避免它在页面上点出不可收拾的状态。这些设计看起来不够性感，却是你能安心使用它的前提。浏览器自动化不像API调用，API调用错了顶多是报错重试，浏览器操作错了，可能影响的是你真实的工作环境和数据。

6.2 下一步可以怎么扩展

跑通之后，我计划往三个方向延展。第一个是把所有浏览器能力封装成MCP工具，这样Dify、Claude Desktop这些客户端都能共享同一个浏览器；第二个是把常用任务沉淀成几个模板任务，让智能体在固定流程里发挥，而不是每次从零自由发挥，这样既快又稳；第三个是接入定时触发器，早晨自动跑一遍报表任务，把结果通过本地通知推给我。这个项目最妙的地方在于，你投入的时间基本不会白费——浏览器自动化能力和Agent编排能力，换到任何业务场景都能复用。

最后再分享一个小技巧：调试这类项目，别死盯代码，多盯模型日志。我一度以为Ollama挂了，后来才发现是页面脚本渲染太慢，模型一直在等。数据不会说谎，把每个步骤的输入输出打印出来，你比模型更快找到问题。就这些，剩下的交给你的显卡了。