简介(未完成)
Browser Use
https://github.com/browser-use/browser-use
如何让AI“看懂”网页?拆解 Browser-Use 的三大核心技术模块 Browser Use 是什么
- Browser Use 是一种基于 AI 模型的浏览器自动化工具,基于 Playwright(浏览器自动化框架)
- Browser Use 是是一个开源的Python库,基于 LangChain 生态构建
Playwright 是一个底层浏览器自动化驱动层,负责:
- 启动、控制浏览器进程;
- 执行 DOM 操作、点击、输入、截图;
- 模拟网络请求、地理位置、时间;
- 拦截 / 注入脚本;
- 提供 API 接口给上层应用调用。 它相当于“浏览器的远程控制器”,用来跑测试、爬取数据、或者做自动化交互。
# 初始化AI模型
llm = ChatOpenAI(model="gpt-4o")
# 定义任务
task = "打开google,搜索'AI编程助手',告诉我第一条结果的标题"
# 创建AI代理
agent = Agent(task=task, llm=llm)
# 运行任务
await agent.run()
现代Python项目最佳实践:以 agentic tool browser-use为例
class Agent(Generic[Context, AgentStructuredOutput]):
async def run(self, max_steps: int = 100) -> AgentHistoryList:
for step in range(max_steps):
await self.step(step_info)
async def step(self, step_info: Optional[AgentStepInfo] = None) -> None:
try:
# Phase 1: Prepare context and timing
browser_state_summary = await self._prepare_context(step_info)
# Phase 2: Get model output and execute actions
await self._get_next_action(browser_state_summary)
await self._execute_actions()
# Phase 3: Post-processing
await self._post_process()
except Exception as e:
# Handle ALL exceptions in one place
await self._handle_step_error(e)
finally:
await self._finalize(browser_state_summary)
CDP
Chrome DevTools Protocol(CDP)是 Chromium 浏览器调试工具的核心通信协议:它基于 JSON 格式,可以通过 WebSocket 实现客户端与浏览器内核之间的双向实时交互。基于 CDP 的开源产品有许多,其中最有名的应该是 Chrome Devtools Frontend,Puppeteer 和 Playwright 了。
首先 CDP 协议是一个典型的 CS 架构,这里我们拿 Chrome Devtools 为例:
- Chrome Devtools:就是 Client,用来做调试数据的 UI 展示,方便用户阅读
- CDP:就是连接 Client-Server 的 Protocol,定义 API 的各种格式和细节
- Chromium/Chrome:就是 Server,用来产生各种数据
CDP 协议的格式基于 JSON-RPC 2.0做了一些轻量的定制。首先是去掉了 JSON 结构体中的 “jsonrpc”: “2.0” 这种每次都要发送的冗余信息。CDP 其实可以分为两大类,然后下面有不同的 Domain 分类:
- Browser Protocol:浏览器相关的协议,之下的 Domain 都是平台相关的,比如说 Page,DOM,CSS,Network,都是和浏览器功能相关
- JavaScript Protocol:JS 引擎相关的协议,主要围绕 JS 引擎功能本身,比如说 Runtime,Debugger,HeapProfiler 等,都是比较纯粹的 JS 语言调试功能
computer use
https://github.com/e2b-dev/open-computer-use
GUI Agent
GUI Agent类模型的训练关键是否应该算在RL post-train里是个模糊的问题
- GUI Agent的数据收集困难,多样性的仿真环境构建困难。
- 虽然主流应用数量不多,手机端App是频繁在更新的。
- 用户在GUI上进行的任务也相对匮乏,,除了少数很复杂的网站和PC专业应用之外,大部分用户在大部分软件上只是在完成少数任务。虽然输入的信息是个性化的,但任务流程很固定,也并不多样。当然在国内各种臃肿的App上,我们可以探索它们的各种功能,产出很多task,但这些task对于用户主要场景上的成功率和泛化性很难说有多大提升。
- GUI Agent模型的跨应用泛化能力较差,海外的模型对于国内应用来说几乎不可用,因为这些模型没有针对于国内的网站和应用进行训练。国内的网站和应用的交互范式也与海外有差异。
code sandbox
https://github.com/vndee/llm-sandbox
https://mp.weixin.qq.com/s/JiRAuWAQ0RqNKlgtShaOvw
其它
一句指令帮你操作手机,最新多模态手机助手Mobile-Agent来了!为了便于将文本描述的操作转化为屏幕上的操作,Mobile-Agent生成的操作必须在一个定义好的操作空间内。这个空间共有8个操作,分别是:打开App(App名字);点击文本(文本内容);点击图标(图标描述);打字(文本内容);上翻、下翻;返回上一页;退出App;停止。点击文本和点击图标设计了输入参数。
- 在迭代开始之前,用户需要输入一个指令。我们根据指令生成整个流程的系统提示。在每次迭代开始时,Mobile-Agent会获取手机屏幕的截图,通过观察系统提示、操作历史和当前屏幕截图,输出下一步操作。如果Mobile-Agent输出的是结束,则停止迭代;否则,继续新的迭代。Mobile-Agent利用操作历史记录了解当前任务的进度,并根据系统提示对当前屏幕截图进行操作,从而实现迭代式自我规划流程。
- 在迭代过程中,Mobile-Agent可能会遇到错误,导致无法完成指令。为了提高指令的成功率,我们引入了一种自我反思方法。这种方法将在两种情况下生效。第一种情况是生成了错误或无效的操作,导致进程卡住。当Mobile-Agent注意到某个操作后截图没有变化,或者截图显示了错误的页面时,它会尝试其他操作或修改当前操作的参数。第二种情况是忽略某些复杂指令的要求。当通过自我规划完成所有操作后,Mobile-Agent会分析操作、历史记录、当前截图和用户指令,以确定指令是否已完成。如果没有,它需要继续通过自我规划生成操作。