最近我把自己每天最烦的运营日报工作交给了一组“AI Browser Use”的组合拳。简单说就是用一个大模型 Agent 去驱动真实浏览器模拟人工完成数据采集、清洗、分析和结果推送。整个过程从打开后台到把日报发进工作群十到十五分钟就能跑完而成本折算下来只有原来找外包做爬虫脚本方案的十分之一不到。说几个真实场景早上起来要看昨日大盘数据每周要出一版运营周报每隔几个小时要盯一下后台工单还有竞品价格、活动页面状态这些过去每一件都是重复劳动。现在我把这些任务都定义成 Agent 的任务描述让 browser-use 这个开源浏览器操控库去调用大模型控制真实浏览器完成。这篇文章就把我踩过的坑、跑通的流程、配置的参数全部摊开讲适合做运营、做数据、做客服以及任何每天被重复网页操作折磨的人参考。1. 需求拆解运营日报为什么会成为压垮人的琐碎工作1.1 传统三种方案的痛我几乎都经历过先说爬虫方案。前几年我手里但凡有几个数据需求第一反应就是写爬虫。程序跑起来确实爽但坑全在后面目标网站一改版选择器全部失效登录态过期了要重新处理遇到动态渲染页面得额外上无头浏览器。最崩溃的是开发爬虫本身就要半天数据规则稍微变一下又得改代码长期维护成本高得离谱。一套数据采集脚本一年下来光修修补补就够写两篇论文的工作量。再说 RPA 方案。RPA 确实能模拟鼠标键盘录制一遍操作流程就能反复执行但它是“死”的。页面按钮位置变了它找不到弹窗多了它容易点错业务逻辑一复杂流程编排能把人绕晕。更关键的是RPA 不理解业务语义它知道那个按钮叫“查询”但它不知道查询结果是否合理、数据是否异常。所以 RPA 适合固定到极致的流程一旦流程里需要人做判断它就废了。然后就是纯人工。每天在几个后台之间来回切换导出 Excel、复制粘贴、算环比、写日报、发群消息。这些事情不是不会做是太消耗精力出错了还很难发现。尤其是周五晚上要盯一波活动数据整个人被绑在电脑前什么都不能干。这三条路我都走过结论是重复工作真正的解法不是让流程更快而是让流程具备“看情况处理”的能力。1.2 Browser Use 方案的核心差异让模型看得见页面browser-use 这个开源库做的事情是把浏览器变成大模型的“手脚”同时把网页变成大模型的“眼睛”。你不再需要告诉程序点击哪个坐标、输入哪个元素你只需要告诉 Agent 你要什么结果它自己会看页面、自己规划操作、自己点击输入还能根据页面反馈调整下一步动作。和传统爬虫相比它最大的差异是“容错”。爬虫必须精确匹配 DOM 结构页面一改就崩而 browser-use 靠视觉语义理解页面哪怕按钮位置变了、文案改了模型照样能从上下文推断出“这就是我要点的那个按钮”。和 RPA 相比它多了“判断力”遇到多个相似入口模型会结合任务目标选择正确路径遇到数据异常它会停下来重新尝试或输出错误说明。所以这个方案的定位很清晰适合处理那些“需要看情况操作”的重复流程。数据日报、后台巡检、批量更新状态、竞品比价这一类任务过去要么开发成本高要么人工投入大现在全都可以交给 Agent 去跑。2. 环境准备十分钟搭出能跑的 AI 操控浏览器环境2.1 Python 环境与依赖安装browser-use 是一个 Python 库底层基于 Playwright 控制浏览器。安装非常简单但有几个细节要注意。我建议使用 Python 3.10 以上版本因为部分模型 SDK 和异步语法对旧版本支持不好。用虚拟环境隔离依赖这是老生常谈但真能帮你少踩很多版本冲突的坑。python -m venv .venv source .venv/bin/activate pip install browser-use playwright playwright install chromiumplaywright install chromium这步很容易被忽略。它负责下载浏览器内核没有它 Agent 就开不了“眼睛”。下载可能需要几分钟取决于网络环境。如果安装过程中出现权限问题可以在命令前加sudo或者把浏览器缓存目录设为当前用户可写的位置。装完之后可以先跑一个最小 Demo 确认环境通import asyncio from browser_use import Agent from 你的模型SDK import ChatModel llm ChatModel(model你选择的模型ID, temperature0.1) async def main(): agent Agent( task打开 example.com告诉我页面的标题是什么, llmllm, ) result await agent.run() print(result) asyncio.run(main())这一个 Demo 能跑通说明大模型接入、浏览器内核、Agent 调度三个环节都没问题后面就可以上真实任务了。2.2 浏览器内核与登录态处理日常运营工作几乎都离不开登录。browser-use 支持保存和复用浏览器的登录状态也就是 Playwright 里的 storage_state。第一次运行任务时你可以让 Agent 正常打开登录页人工输入账号密码、过掉验证码登录成功后把状态保存下来from browser_use import Browser, BrowserConfig browser Browser( configBrowserConfig( headlessTrue, storage_statelogin_state.json, ) )第一次跑的时候不需要 storage_state让浏览器弹出窗口你手动登录一次然后运行一段保存状态的脚本把 cookies 和 localStorage 写入login_state.json。之后再跑任务Agent 每次都会用这份登录态不需要重复输密码也能避开一部分验证码。需要注意登录态会过期建议每天早上第一次跑任务时先做一次“健康检查”发现跳转到登录页就让 Agent 暂停并通知你。2.3 大模型接入与关键参数配置模型是整个方案的“大脑”参数配置直接影响成功率。我实测下来最影响结果的几个参数是温度、超时时间和最大步数。温度建议调到 0.1 左右。温度太高模型容易发挥点错按钮、理解偏差的概率明显上升温度太低又不够灵活遇到页面异常时无法随机应变。理想状态是让它稳定执行同时保留微调空间。超时时间也需要单独设置。单步操作超时我一般设为 30 秒整个任务超时根据复杂度设置 300 到 600 秒不等。日报任务我设 600 秒足够覆盖所有步骤。还有一个关键参数是max_steps也就是任务允许执行的最大步数。如果不设限制Agent 一旦陷入死循环会一直点下去。我通常设 30 步复杂任务 50 步超过就停止并输出当前进度方便排查。3. 实操环节把一个完整运营日报任务跑通3.1 任务描述怎么写提示词模板拆解browser-use 里最容易被低估的是任务描述。同样是“做日报”你会发现有些人跑的顺畅有些人频繁失败差距往往就在提示词。我总结出来的模板包含五个要素目标、数据来源、操作约束、输出格式、异常处理。一个可复用的任务描述模板请完成以下运营日报任务 1. 打开数据后台地址是 https://xxx/dashboard 2. 使用已保存的登录状态不需要重复输入账号 3. 在日期筛选器中选择“昨天”点击查询 4. 从报表中读取三个指标销售额、订单量、客单价 5. 再选择“前天”读取同样三个指标 6. 计算每个指标环比昨天变化的百分比 7. 将结果整理为 Markdown 表格输出给用户 约束 - 如果页面加载超过 20 秒刷新后重试 - 如果某个指标读取不到尝试切换数据源仍然失败就标记为“待确认” - 不要修改页面上的其他数据任务描述的核心是把“判断逻辑”交给 Agent让它知道什么时候该继续、什么时候该停下。你不需要写“点击第一个按钮”这种指令但你要告诉它“选择昨天”和“计算环比”剩下的由模型自己执行。3.2 采集、计算、推送核心代码实现跑通一个完整日报任务最稳妥的方式是“先让 Agent 采集再回本地计算”而不是让 Agent 在浏览器里点计算器。浏览器算数既不高效也容易出错本地用 Python 处理更快更可控。我的实现分三步。第一步Agent 负责采集原始数据并整理成结构化文本返回给我import asyncio from browser_use import Agent, Browser, BrowserConfig llm ChatModel(model你选择的模型ID, temperature0.1) browser Browser( configBrowserConfig( headlessFalse, # 调试时可以设为 False窗口可见 storage_statelogin_state.json, ) ) async def collect_data(): agent Agent( task 打开数据后台销售日报页面。 分别读取昨天和前天的销售额、订单量、客单价。 输出格式 日期,销售额,订单量,客单价 , llmllm, browserbrowser, max_steps30, ) result await agent.run() return result.output_text() raw_data asyncio.run(collect_data()) print(raw_data)第二步本地用 Pandas 做清洗计算。Agent 返回的数据格式可能参差不齐我会让 Agent 严格按 CSV 格式输出然后直接用 pandas 读取。这样可以省掉很多数据清洗的麻烦import pandas as pd from io import StringIO df pd.read_csv(StringIO(raw_data)) df[客单价] df[销售额] / df[订单量] df[销售额环比] df[销售额].pct_change().round(4) * 100 df[订单量环比] df[订单量].pct_change().round(4) * 100 df[客单价环比] df[客单价].pct_change().round(4) * 100 print(df.to_markdown())第三步把计算结果推送出去。日报的出口一般是企业微信、钉钉或飞书群。我用最通用的 webhook 方式把 Markdown 转成纯文本推送到群里import requests def push_to_group(text): webhook_url 你团队的机器人 webhook 地址 payload {msgtype: text, text: {content: text}} requests.post(webhook_url, jsonpayload, timeout10) report df.to_markdown() push_to_group(昨日运营日报\n report)这三步串起来就完成了“采集 - 计算 - 推送”的闭环。整个过程大概 8 到 12 分钟其中大头是页面加载和 Agent 操作本地计算只要零点几秒。3.3 进阶让 Agent 学会“自己写脚本处理数据”有些任务不只是一个日报而是要基于页面数据做一些条件判断比如监控竞品价格做降价预警。这种任务我会让 Agent 在发现异常时自动写代码分析数据而不是自己东点西点。具体做法是给 Agent 一个本地函数调用工具def run_python_code(code: str): exec_globals {pandas: pd, StringIO: StringIO} exec(code, exec_globals) return exec_globals.get(result, None)然后在任务描述里明确告诉 Agent“如果发现价格波动超过 5%调用 run_python_code 计算波幅并输出预警信息。”这种“浏览器采集 代码执行”的组合非常实用等于让 Agent 自己判断什么时候该看页面、什么时候该算数据效率和准确率都上了一个台阶。4. 稳定性调优把频繁崩溃的坑一次填平4.1 点击失败与页面等待问题Agent 操作浏览器最常遇到的坑就是“元素还没加载就点击”。页面里的弹窗、异步加载、动画过渡都会导致点击落空。browser-use 本身有等待机制但网络慢或者页面结构复杂时依然会失败。我的经验是给 Agent 的任务描述里加“重试条款”比如上面模板里写的“页面加载超过 20 秒刷新后重试”。另外上线初期不要把浏览器设成 headless先在可视化窗口里跑几遍观察 Agent 的操作路径找到最容易卡住的环节。如果每次都卡在同一个弹窗上可以人工先把弹窗关掉再让 Agent 继续执行。还有一个技巧是给 Agent 设置“单步回退”能力。browser-use 支持自定义动作我实现过一个“点击失败就返回上一页重新找元素”的回退逻辑from browser_use import Controller, ActionResult controller Controller() controller.action(如果点击失败返回上一页并重试) async def back_and_retry(browser): await browser.go_back() return ActionResult(doneFalse, successTrue)这样就算点击失败Agent 也能自己恢复而不是停在原地报错。4.2 长任务丢失上下文怎么办运营任务通常步骤多、页面多Agent 跑到后面经常把前面的目标忘了比如采集完昨天的数据忘了还要采集前天。这个问题本质是 LLM 上下文窗口有限再加上操作历史太长模型“记不住最初的任务”。解决办法是拆任务。不要指望一个 Agent 干完所有事情可以把日报拆成“采集”、“计算”、“推送”三个环节每个环节独立跑。我在项目里的架构是这样的任务A采集数据输出结构化文本任务B读取文本本地计算指标任务C推送结果到群任务之间通过本地变量或文件传递数据。好处很明显每个 Agent 只需要关注一件事单任务步数少成功率大幅提升某个环节失败了只需重跑当前环节不用整个流程从头再来。另一个思路是“压缩历史”。如果任务还是长可以在任务描述里定期要求 Agent “忽略前面已经完成的步骤只关注剩余目标”。实测下来加上这句话之后长任务的完成率从六成提高到九成。4.3 验证码与登录态怎么处理才省心验证码是浏览器 Automation 最大的拦路虎。我试过几类方案最省心的其实是“人机协作”第一次登录时人工介入把登录态保存下来后续任务直接复用。大部分运营后台的验证码只在异常登录或长时间未操作后出现登录态方案能覆盖 80% 以上的场景。对于少数的动态验证码我在任务描述里写明“如果出现验证码不要尝试识别直接停止任务并输出提示”。与其让 Agent 瞎点导致账号被风控不如停下来人工处理。账号安全永远比一次自动任务重要。另外注意一个细节登录态文件不要提交到代码仓库里面包含完整 cookie 信息泄露出去等于把账号拱手让人。我一般把login_state.json放到单独目录并且加入.gitignore。5. 成本账与可以扩展到哪些场景5.1 成本测算1/10 是怎么算出来的很多人觉得用 AI Agent 一定贵其实算下来真不是。我按一个标准日报任务做了估算每次任务大约消耗输入 Token 50 万主要是页面截图和上下文输出 Token 5 万操作指令和结果。按目前主流大模型 API 的市场价输入大约几元每百万 Token输出略贵一点加上请求次数单次任务成本在 1 到 3 元之间。对比一下更清楚方案前期成本单次任务成本维护难度页面改版适应力外包爬虫定制数万元开发周期按周计服务器硬件维护人力高需要持续修差改版即崩自研RPA流程人力成本按周计脚本绑定UI虚拟机授权费用中需要重新录制较差绑定选择器人工每日操作无人力时间成本高无人脑适应但累AI Agent方案Python环境浏览器基本为零每次1-3元 Token 费用低改提示词即可强模型自动适应“1/10 成本”不是夸张。以前外包做一个数据采集日报功能报价普遍是几万块打底日常维护还得继续花钱。现在自己搭一套 Agent 流程一次性成本几乎为零每天跑任务的 Token 费用合计不到原来的零头。就算加上偶尔的人工干预和模型 API 开支整体成本也比传统方案低一个数量级。5.2 场景扩展一份工作流复制到所有重复网页操作这套流程跑通之后你会发现它其实是“一条管道”换个任务描述就能复用到其他场景。我这里列几个已经验证过的方向商品批量管理每天自动检查待上架商品核对库存和价格有异常就自动下架并通知。竞品价格监控定时访问竞品页面对比上次价格降幅超过阈值就生成预警。客诉工单初筛自动读取新工单内容按关键词分类把紧急的置顶并提醒值班人。活动效果汇总活动期间每两小时抓一次数据生成实时趋势曲线图结束后自动出复盘报告。资讯与舆情整理每天抓取行业站点和社区热帖用模型做摘要输出到知识库。这些场景的共同特点都是“规则相对清晰 需要人工盯守 数据散落在网页里”。以前每一个都是独立的耗时项目现在全部可以变成定时任务每天早上集中跑一遍结果自动汇总到群里。最后说点个人感受。这套组合最香的地方其实不是省了多少钱而是把那些没人愿意干的重复事变成了随时可以调度的能力。我之前最崩溃的时刻是周五晚上还要盯活动数据现在只要在任务表里加一行九点自动跑完发群周一回来报表已经在那里等着。那种感觉比报再多课都值。如果你手里也有一堆天天重复的网页操作真的可以花一个下午把环境跑通第一个 Agent 跑起来之后剩下的就是复制粘贴任务描述而已。