《用LangChain实现Manus》：Browser Use 到底能不能用？

比如，之前典型的工具需求对电脑的操作。目标是让AI像人类一样操作电脑：看屏幕、动光标、点按钮、打字，再这个基础上再扩展功能，比如帮订机票、填表格、查天气。

除了Computer Use，另一个非常典型的需求就是浏览器操作Browser Use了，甚至其实现ROI可能比Computer Use更高：

这款浏览器的自动化工具，是去年发布的，因为该功能的重要程度，以后应该也会有更多这类插件出现，毕竟让 AI 像人类一样浏览网页、点击链接、提取信息本身就有很大的意义。

学过前端的同学会比较清楚，对浏览器的操作方式有两种，第一种是模拟点击，记录x、y左边，在实现点击等操作即可；第二种是直接对其网页代码进行操作。这两种方式Browser Use都用了。

并且，当前对外宣传其效果还很好，那么其真实效果到底如何？我们今天就来测试测试。

今天使用的案例是通过 Browser Use 驱动浏览器完成页面操作、登录、元素交互，由 LangChain 负责语义对话生成，最终构建一个能够自动登录、实时监听消息、自动生成回复并直接在网页端发送的多轮自动会话系统。

02 Browser Use 实测

系统的架构可以分为两个主要模块：

LangChain 对话管理模块：负责处理对话逻辑和上下文管理：

使用 Qwen-Plus 模型生成回复通过 ChatMessageHistory 管理对话历史使用 ChatPromptTemplate 设置提示词模板构建 Conversation Chain 来维持对话流程

Browser Use 浏览器自动化模块：负责与网页端进行实际交互

Browser 实例控制实际的浏览器操作Browser Use Agent 执行具体的任务指令使用大模型处理浏览器操作任务

整个工作流程如下：

1.系统启动时初始化两个模块

2.通过 Browser Use 模块在网页上发送初始消息

3.进入自动聊天循环：

4.循环执行指定轮次后结束，并保持浏览器打开一段时间供查看

接下来是具体实现：

具体实现（可略过看结论）

首先初始化 LangChain，对话模型使用 Qwen-Plus，并创建对话记忆与提示词模板。

这里我们让模型保持「CTO角色人设」，并限制回复风格始终为一句话，保证多轮对话的一致性与人格连续性：

然后，Browser Use 部分使用 GPT-4o 模型，并启动真实浏览器实例（可见窗口 mode）。其作用是负责所有真实网页层面的点击、输入、识别和元素交互：

然后，系统以「自然语言任务描述」的方式，将任务直接交给 Browser LLM。Browser Use 会自动解析指令：打开目标网页、登录、创建新会话、输入第一条消息并发送。

这一步完成对整个对话 session 的初始铺设：

系统每隔 30 秒执行一次 Browser Use 的任务，检查网页是否产生新的回复，并自动从聊天界面中抓取 AI 助手的最新回应，提取完成后将回复内容返回给程序处理：

再然后LangChain登场，把 AI 助手刚刚回复的内容、结合过往对话历史，一起交给 LangChain 再生成。这样可以保持角色一致性，并且形成连续的多轮语义闭环：

将 LangChain 生成出来的回复文本，再次以自然语言任务下发给 Browser Agent，由浏览器自己完成实际输入与发送行为，系统无需写任何 XPath/定位代码：

整个对话流程会循环执行：

每轮先从网页等待回复再调用 LangChain 生成新内容再交由 Browser Use 发送出去

至此整体流程结束，具体效果大家可以在上面视频查看。接下来就是一些具体的问题了：

03 一些问题

这里不同的人、不同的环境碰到的问题不一样，我们这里就有撒说撒了…

CDP / 浏览器连接不稳定

对于经常使用魔法的同学来说，优先检查本地代理、VPN，很多时候是代理阻断了 CDP 通信…

另外注意 Chrome / Chromium 版本与 Browser Use 的兼容性一定要一致。

ChatBrowserUse 模型不稳定

Browser Use 默认自带的 ChatBrowserUse 模型不稳定,国内使用经常出现 timeout / stuck 的情况。

可以切换到其他模型，比如 qwen/deepseek…