GELab-Zero 技术解析：当豆包联手中兴，开源界如何守住端侧 AI 的“最后防线”？引言 2025年12月，AI

引言

2025年12月，AI 端侧领域迎来了两大里程碑式突破，标志着端侧智能助手从"能不能用"迈向"能否规模化落地"的关键阶段。

一方面，字节跳动豆包团队发布了豆包手机助手技术预览版，首次在手机端实现了持久化本地记忆与跨应用操作能力。特别是其与中兴手机的深度合作，通过系统级授权（如 nubia M153 工程样机）实现了语音、侧边键直接唤醒的便捷交互，引发了行业关于"互联网巨头+手机厂商"生态合作模式的热烈讨论。

近日，阶跃星辰开源了 GELab-Zero-4B-preview 模型及配套工程基建，实现了 4B 级参数模型在主流安卓设备上的轻量化部署。作为开源模型提供方，阶跃选择了赋能开发者的路线，通过提供完整的推理工程基建，解决安卓生态碎片化的难题。

本文将聚焦于开源界的代表作——GELab-Zero，通过一个真实的任务执行案例（Session ID: 1fe9db3f-92c8-4ae9-89bc-1d035d4bf59b），深入剖析其技术架构、工作原理以及如何在消费级设备上实现 SOTA 级的 GUI 操作能力。

技术背景：端侧 AI 的战国时代

1. 行业格局：三条路线的角逐

当前手机端侧智能助手领域形成了多元化的竞争格局，主要厂商的技术路线和行业定位各有特色：

厂商类型	代表厂商/产品	模型规模	技术路线特点	行业定位
手机厂商	OPPO (AndesVL) vivo (BlueLM) 华为 (小艺) 荣耀 (MagicGUI)	0.6B-7B+	系统级整合：多采用多模态模型，深度整合系统底层（如华为 NPU+鸿蒙，OPPO 潮汐引擎）。强调硬件协同与专属体验。	系统级智能助理打造"高效&专属"的差异化体验
互联网巨头	字节跳动 (豆包)	未公开	轻量化工具+生态合作：具备端侧持久记忆和跨 App 操作能力。依赖与厂商（如中兴）的合作获得系统级权限。	轻量化工具型助手通过生态合作覆盖多品牌
开源模型方	阶跃星辰 (GELab-Zero)	4B	开源基建+通用兼容：提供完整的推理工程基建，解决 ADB 连接、依赖安装等"脏活累活"。支持一键部署。	开发者赋能平台降低端侧 Agent 开发门槛

2. 深度案例解析：豆包 x 中兴 nubia 的集成机制

豆包手机助手在中兴 nubia M153 工程机上的实现，展示了**"互联网巨头软件 + 手机厂商硬件"**的典型合作模式：

A. 集成方式：系统级深度植入 (System-Level Integration)

不同于普通 App，豆包通过与中兴 OS (MyOS) 的底层打通，实现了硬件级的接管：

硬件入口绑定：将物理侧边键映射为 AI 唤醒键，支持熄屏状态下一键直达。
权限白名单：突破了传统 Accessibility 服务易被后台查杀的限制，获得了系统级保活权限，确保持续的感知能力。

B. 模型运行架构：端云协同 (Cloud-Edge Collaboration)

端侧 (On-Device)：
- Secure Memory (安全记忆)：核心差异化功能。利用 Android Keystore 对用户敏感数据（如家庭地址、支付习惯）进行本地加密存储，确保隐私不离端。
- Executor (执行引擎)：运行在手机本地的轻量级服务，负责将指令转化为具体的点击/滑动操作。
云端 (Cloud)：
- Reasoning Engine (推理大脑)：处理复杂的长程任务规划（如"跨 App 比价"），利用云端大模型的算力优势进行决策，然后将操作流下发给端侧执行。

C. 交互闭环

感知：通过无障碍服务 (Accessibility API) 实时获取屏幕 UI 树信息。
决策：端侧记忆 + 屏幕信息 + 用户指令 -> 云端推理 -> 下发操作流。
执行：调用系统级 API 模拟用户操作，遇到敏感场景（如支付）自动降级为"请求用户确认"。

3. GUI Agent 的技术演进

移动端 Agent 的三大技术路径

在移动端 Agent 领域，目前主要存在三种技术实现路径：

1. API 接口方案

优势：精确可靠，延迟低
劣势：需要 App 厂商深度适配，开发成本高，难以规模化
代表：需要每个 App 提供专门的 Agent API

2. 辅助功能（Accessibility）方案

优势：可以获取 UI 树结构，理解界面元素
劣势：依赖系统权限，部分应用限制访问，兼容性问题多
代表：Android Accessibility Service

3. GUI 视觉方案（GELab-Zero 采用）

优势：
- 通用兼容：无需 App 厂商适配，支持所有应用
- 零成本接入：基于截屏和坐标操作，开箱即用
- 真实用户视角：与人类操作方式一致
劣势：对视觉理解能力要求高，需要强大的多模态模型
代表：GELab-Zero、Anthropic Computer Use

为什么选择 GUI 方案？

移动应用生态具有以下特点：

高度碎片化：中国市场有超过 数百万个 Android 应用
快速迭代：应用 UI 频繁更新，API 方案难以维护
权限限制：许多应用限制 Accessibility 访问
用户习惯：基于视觉的交互更接近真实用户行为

因此，GUI 方案已成为当前阶段应对复杂移动生态、实现 Agent 能力规模化的最佳路径。

行业现状与挑战

当前 GUI Agent 面临的核心问题

工程门槛高
- 多设备 ADB 连接管理
- 依赖安装和权限配置
- 推理服务部署（本地 LLM）
- 任务编排与轨迹回放
- 可视化调试工具
模型能力要求高
- 需要强大的视觉理解能力
- 多步骤任务规划
- 上下文记忆
- 异常处理
隐私安全顾虑
- 云端 API 需要上传截图
- 用户操作数据泄露风险
- 敏感信息暴露

主流 Benchmark 的局限性

当前主流基准测试（如 AndroidWorld）多聚焦于生产力应用（邮件、日历），但用户日常高频使用的其实是生活服务类应用：

🍔 外卖（美团、饿了么）
🚗 打车（滴滴、高德）
🛒 购物（淘宝、京东）
💬 社交（微信、抖音）
💰 支付（支付宝、微信支付）

这些场景更能体现 GUI Agent 的实用价值，但缺乏针对性的评估标准。

GELab-Zero 的技术突破

针对上述挑战，GELab-Zero 提供了完整的解决方案：

1. 完整工程基础设施

一键部署脚本
自动设备管理
多设备任务分发
完整日志系统
Streamlit 可视化界面

2. 轻量级本地模型

4B 参数：在消费级硬件（16GB RAM）上流畅运行
多模态能力：同时理解图像和文本
高准确率：AndroidDaily 静态测试达到 73.4%（超越 GPT-4o 的 19.6%）

3. 完全本地化

所有推理在本地完成（Ollama/vLLM）
截图和日志存储在本地
无需网络传输，保护隐私

4. 真实场景基准

AndroidDaily：235 个端到端任务
覆盖六大生活场景：食、行、购、住、讯、娱
75.86% 成功率（真实移动场景）

与其他方案的对比

维度	API 方案	Accessibility	GUI 方案 (GELab-Zero)
兼容性	❌ 需要适配	⚠️ 部分限制	✅ 通用兼容
开发成本	❌ 高	⚠️ 中	✅ 低
隐私保护	⚠️ 依赖服务商	✅ 本地	✅ 完全本地
推理速度	✅ 快	✅ 快	⚠️ 中等
准确性	✅ 高	✅ 高	✅ 高（73.4%）
可维护性	❌ 低	⚠️ 中	✅ 高

一、项目概览

1.1 核心价值主张

GELab-Zero 解决了移动端 Agent 落地的三大核心挑战：

隐私安全：完全本地化部署，所有数据处理在本地完成，无需上传云端
即插即用：提供完整的工程基础设施，开箱即用，无需复杂配置
通用兼容：基于 GUI 操作，无需 App 厂商适配，支持所有应用

1.2 技术栈组成

模型层：GELab-Zero-4B-preview（基于 Qwen3-VL-4B-Instruct 微调的 4B 参数多模态视觉模型）
推理服务：Ollama / vLLM（本地推理）
设备控制：ADB（Android Debug Bridge）
任务编排：LocalServer + PU Client
可视化：Streamlit Web 界面

1.3 开源价值深度解析：商业巨头阴影下的"守火人"

在字节跳动豆包等商业产品展现出强大的系统级统治力时，GELab-Zero 这样的开源项目并非毫无意义的"重复造轮子"，而是构建了另一条必不可少的技术护城河。虽然在流畅度和系统权限上不如商业产品，但其独特价值在于：

打破"围墙花园"（针对存量市场） 商业产品（如豆包+中兴）依赖于排他性的厂商合作与私有系统 API。GELab-Zero 证明了纯视觉方案（Visual-based）的可行性——即使没有任何厂商特权，仅凭屏幕截图也能实现复杂的 Agent 交互。这意味着它能在数以亿计的存量旧手机上运行，而不是强迫用户购买特定的新款"AI 手机"。
数据主权的"最后防线"（针对敏感场景） 商业助手虽然强调"端侧隐私"，但为了追求极致效果，核心的长程推理（Reasoning）往往仍依赖云端大模型（Cloud-Edge Collaboration）。GELab-Zero 是真正的全链路本地化（Local-First），从模型权重到推理过程完全掌握在用户手中。对于金融审计、医疗数据处理、企业内网办公等对数据外泄零容忍的场景，这是唯一的选择。
透明可控的"白盒"基座（针对开发者） 对于学术界和开发者，商业助手是"黑盒"，只能调用，无法探究其决策逻辑。GELab-Zero 提供了从数据采集（AndroidDaily）、动作定义（ActTree）到模型训练的完整**白盒（White-box）**流程。它是研究 Agent 幻觉、优化多步推理机制的最佳实验台，为行业建立了公开透明的技术标准。

二、系统架构深度解析

2.1 整体架构图

2.2 核心组件详解

2.2.1 LocalServer（任务编排服务器）

职责：

接收用户任务指令
管理任务执行状态
协调视觉理解和设备控制
记录完整执行轨迹

关键配置：

tmp_server_config = {
    "log_dir": "running_log/server_log/os-copilot-local-eval-logs/traces",
    "image_dir": "running_log/server_log/os-copilot-local-eval-logs/images",
    "debug": False
}

2.2.2 GELab-Zero-4B-preview 模型与架构

三层架构设计： GELab-Zero 采用了类似 MobiAgent 的三层架构，以确保复杂任务的执行能力：

Planner (规划师)：负责任务拆解和整体流程控制。
Decider (决策者)：根据当前屏幕状态决定具体操作。
Ground (执行者)：将决策转化为具体的坐标点击或文本输入。

模型特性：

参数规模：4B（40 亿参数），专为消费级硬件优化。
性能表现：在 ScreenSpot、OSWorld、Android World 等多个基准测试中拿下同尺寸 SOTA。
多模态输入：手机截图 + 任务描述 + 历史操作。

基座模型：该模型是基于 Qwen3-VL-4B-Instruct 进行微调的。选择 Qwen3-VL 作为基座是因为其在小参数量级下展现出了卓越的视觉理解和指令遵循能力，非常适合端侧部署场景。

技术亮点：ActTree 任务分发 为了提升效率，系统引入了 多设备任务分发系统。通过 ActTree 结构记录并复用历史操作轨迹，大幅减少重复推理。在模拟真实用户习惯（80% 请求集中在 20% 任务）的测试中，动作复用率可达 60%-85%，带来 2 到 3 倍的性能提升。

推理配置：

local_model_config = {
    "model_name": "gelab-zero-4b-preview",
    "model_provider": "local",
    "args": {
        "temperature": 0.1,      # 低温度保证稳定性
        "top_p": 0.95,
        "frequency_penalty": 0.0,
        "max_tokens": 4096,
    }
}

2.2.3 动作空间定义

系统支持 9 类基础操作：

动作类型	说明	参数
CLICK	点击屏幕坐标	point (x,y)
TYPE	输入文本	value (文本内容), point (输入框位置)
SLIDE	滑动操作	point1 (起点), point2 (终点)
LONGPRESS	长按操作	point (坐标)
AWAKE	唤醒应用	value (应用名称)
WAIT	等待	value (秒数)
INFO	询问用户	value (问题内容)
COMPLETE	任务完成	return (结果报告)
ABORT	终止任务	value (终止原因)

坐标系统：

原点：左上角 (0, 0)
X 轴：向右递增
Y 轴：向下递增
取值范围：0-1000（归一化坐标）

三、实战案例：淘宝购书任务全流程解析

3.1 任务背景

任务描述：去淘宝帮我买本书
Session ID：1fe9db3f-92c8-4ae9-89bc-1d035d4bf59b
执行时间：2025-12-05 18:41:39 - 18:46:55
总步骤数：9 步
模型配置：gelab-zero-4b-preview (本地推理) 设备环境：MacBook Pro (Apple M3 Pro, 18GB RAM) 量化说明：因 18GB 统一内存运行 FP16 原生模型会触发系统卡死，本案例使用了 Int8 量化模型 (q8_0) 进行推理。

3.2 完整执行流程

步骤 1：应用唤醒（AWAKE）

模型思考：

"我看到的是手机主屏幕。任务是去淘宝买书。第一步就是要打开淘宝应用。我看到屏幕上有'京东'应用，但任务明确要求使用'淘宝'。因此，我需要先启动淘宝应用。"

执行动作：

action: AWAKE
value: 淘宝

推理耗时：20.43 秒

关键技术点：

模型能够区分不同的电商应用（京东 vs 淘宝）
准确理解任务指令中的应用要求
使用 AWAKE 指令直接唤醒应用，而非手动查找点击

步骤 2：搜索框定位（CLICK）

模型思考：

"我看到当前是淘宝的首页。任务目标是购买一本书。为了找到书，我需要使用搜索功能。我观察到页面顶部有一个搜索框，里面有'干脆面'的提示文字。我需要点击这个搜索框来激活它。"

执行动作：

action: CLICK
point: 375,117

推理耗时：20.69 秒

关键技术点：

准确识别搜索框的视觉位置
理解需要先激活搜索框才能输入
坐标精准定位（屏幕中上部区域）

步骤 3：文本输入（TYPE）

模型思考：

"我看到当前界面是淘宝的搜索页面，键盘已经弹起，光标在搜索框中。任务目标是购买一本书。现在我需要输入要搜索的关键词。为了找到书，我应该在搜索框中输入'书'。"

执行动作：

action: TYPE
value: 书
point: 213,132

推理耗时：22.23 秒

关键技术点：

识别输入框的激活状态（键盘弹起）
提取任务关键词（"买书" → 搜索"书"）
TYPE 动作需要同时提供文本内容和输入框位置

步骤 4：执行搜索（CLICK）

模型思考：

"我看到当前界面是淘宝的搜索页面，搜索框里已经输入了'书'。任务目标是购买一本书，现在需要执行搜索来查看有哪些书可以选。因此，我应该点击搜索框旁边的橙色'搜索'按钮。"

执行动作：

action: CLICK
point: 896,130

推理耗时：21.06 秒

关键技术点：

识别"搜索"按钮的视觉特征（橙色、位置）
理解搜索流程的完整性（输入 → 点击搜索）
右上角按钮的精准点击

步骤 5：信息询问（INFO）

模型思考：

"我看到当前界面是'书'的搜索结果页。任务目标是购买一本书，但用户没有指定具体书名。为了继续任务，我需要知道用户想买哪一本书。因此，我应该向用户询问。"

执行动作：

action: INFO
value: 请问您想买哪本书？

用户回复：我想买明朝那些事

推理耗时：20.63 秒

关键技术点：

主动信息获取：模型意识到任务信息不完整
交互式决策：通过 INFO 动作暂停执行，等待用户输入
上下文理解：记住用户回复，继续执行后续步骤

步骤 6：弹窗处理（CLICK）

模型思考：

"我看到当前界面是'书'的搜索结果页，但有一个'淘宝双12'的消费券弹窗覆盖在上面，阻碍了后续操作。任务目标是购买《明朝那些事》，所以必须先处理掉这个弹窗。我观察到弹窗下方有一个'X'关闭按钮。"

执行动作：

action: CLICK
point: 500,710

推理耗时：22.28 秒

关键技术点：

干扰识别：准确判断弹窗是阻碍因素
优先级处理：先清除障碍再继续主任务
细节关注：定位关闭按钮的位置

步骤 7：商品选择（CLICK）

模型思考：

"我看到当前界面是'书'的搜索结果列表。任务目标是购买《明朝那些事》。列表中的第一个商品就是'新版全9册明朝那些事儿全套1-9册'，这正是我要找的书。"

执行动作：

action: CLICK
point: 258,445

推理耗时：19.94 秒

关键技术点：

商品匹配：从搜索结果中识别目标商品
文本理解："明朝那些事" = "明朝那些事儿"（近义词匹配）
视觉定位：在商品列表中准确定位目标

步骤 8：立即购买（CLICK）

模型思考：

"我看到当前界面是《明朝那些事儿》的商品详情页。任务目标是购买这本书。为了继续购买流程，我需要点击页面底部的'立即购买'按钮。"

执行动作：

action: CLICK
point: 836,946

推理耗时：19.32 秒

关键技术点：

页面理解：识别商品详情页的布局结构
按钮定位：准确找到底部购买按钮
流程推进：理解电商购物的标准流程

步骤 9：任务完成（COMPLETE）

模型思考：

"我看到当前界面是订单确认页。任务是购买一本书，我已经完成了商品选择、加入购物车、进入结算的所有步骤。现在页面显示了收货地址、商品信息和支付金额243元。由于这是涉及金钱交易的最后一步，我应该在这里停止操作，并向用户报告订单的详细信息。"

执行动作：

action: COMPLETE
return: 我已完成购书流程并到达订单确认页面。
订单详情如下：
- 商品：正版《明朝那些事儿》全套1-9册
- 收货地址：xxx xxxxxxxxxx
- 支付金额：¥243
- 支付方式：先用后付
请您确认以上信息无误后，可以点击页面底部的"先用后付，确认收货后付款 ¥243"按钮继续完成支付。

推理耗时：25.83 秒

关键技术点：

安全边界：在支付前停止，不执行敏感操作
信息提取：从订单页面提取关键信息
完整汇报：向用户清晰报告任务完成状态和后续操作建议

3.3 性能统计

指标	数值
总步骤数	9 步
总执行时间	~5 分钟 16 秒
平均每步推理时间	~21 秒
成功率	100% (完成到订单确认页)
用户交互次数	1 次 (询问书名)

四、技术亮点与创新

4.1 多模态推理能力

GELab-Zero 的 4B 模型展现了强大的视觉-语言理解能力：

视觉元素识别：
- 搜索框、按钮、商品列表
- 弹窗、键盘状态
- 文字内容（商品名、价格、地址）
语义理解：
- 任务目标拆解（"买书" → 搜索 → 选择 → 购买）
- 近义词匹配（"明朝那些事" ≈ "明朝那些事儿"）
- 上下文连贯性（记住用户指定的书名）
逻辑推理：
- 判断任务完成度
- 识别阻碍因素（弹窗）
- 决定何时询问用户、何时停止操作

4.2 安全性设计

敏感操作保护：
- 在支付前停止，不执行金融交易
- 使用 COMPLETE 动作汇报结果，由用户确认
完全本地化：
- 所有推理在本地完成
- 截图和日志存储在本地
- 无需网络传输用户数据
轨迹可追溯：
- 每一步操作都有完整日志
- 包含模型思考过程（CoT）
- 可通过 Streamlit 可视化查看

4.3 工程化设计

模块化架构：
- Server 层、Client 层、Frontend 层分离
- 易于扩展和维护

日志系统：

{
    "session_id": "唯一标识",
    "timestamp": "时间戳",
    "message": {
        "environment": {
            "image": "截图路径",
            "user_comment": "用户反馈"
        },
        "action": {
            "cot": "思考过程",
            "explain": "动作解释",
            "action": "动作类型",
            ...
        },
        "llm_cost": {
            "llm_time": "推理耗时",
            ...
        }
    }
}

可视化工具：
- Streamlit Web 界面
- 展示完整执行轨迹
- 在截图上标记操作点位

五、性能优化建议

5.1 推理速度优化

当前瓶颈：平均每步 ~21 秒

优化方案：

模型量化（关键！）：实测发现，在 Apple M3 Pro (18GB RAM) 等中端配置上，直接运行 FP16 模型可能导致内存溢出甚至系统卡死。强烈建议使用 Int8 或 Int4 量化版本。

# INT8 量化（本案例使用，兼顾速度与精度，适合 16GB+ 内存）
ollama create -q q8_0 gelab-zero-4b-preview

# INT4 量化（速度最快，适合 8GB/12GB 内存）
ollama create -q Q4_K_M gelab-zero-4b-preview

图像尺寸调整：

"resize_config": {
    "is_resize": True,
    "target_image_size": (756, 756)  # 降低分辨率
}

硬件升级（立竿见影）：如果预算允许，升级硬件是提升体验最直接的方式：
- Apple Silicon 用户：建议使用 M3 Max / M4 Max 芯片（配备 36GB+ 统一内存），可流畅运行 FP16 原版模型，推理延迟有望降低至 3-5秒/步。
- NVIDIA GPU 用户：使用 RTX 4090 (24GB) 或 A100 (40GB/80GB) 部署，结合 vLLM 推理加速框架，可实现亚秒级响应。
批处理推理：
- 对于多设备任务，使用批处理提升吞吐量

5.2 准确性提升

温度参数调整：
- 当前：0.1（偏保守）
- 建议：0.0（完全确定性）或 0.05（平衡）
Prompt 优化：
- 增加任务相关的示例
- 细化动作空间的描述
多模态融合：
- 结合 OCR 提取文字
- 使用 UI 层次结构信息

六、应用场景拓展

6.1 个人助手场景

购物助手：比价、下单、跟踪物流
出行助手：打车、订票、导航
社交助手：自动回复、消息转发

6.2 企业应用场景

自动化测试：App UI 自动化测试
数据采集：竞品分析、价格监控
RPA：重复性任务自动化

6.3 研究方向

多设备协同：同时控制多台手机
长期记忆：跨 Session 的任务记忆
多模态输入：语音指令、手势控制

七、总结与展望

7.1 核心优势：为什么是 GELab-Zero？

工程基建的胜利：覆盖主流 Android 9+ 及 RAM 4GB 以上设备。通过完整的推理工程基建，解决了多设备 ADB 连接、依赖安装等繁琐流程，让开发者从"脏活累活"中解放出来。
隐私与安全的平衡：类似于豆包手机助手的端侧持久记忆理念，GELab-Zero 坚持完全本地化运行，所有数据在本地闭环，规避了云端隐私泄露风险。
真实场景的打磨：基于 AndroidDaily 自建评测基准，聚焦现代生活六大核心维度（食、行、购、住、讯、娱），在真实复杂任务中（如跨 App 比价、多商品采购）准确率达到 73.4%。

7.2 行业发展趋势

随着 2025 年末端侧 AI 的集中爆发，未来几年我们将看到以下趋势：

技术融合：端侧模型参数将持续增长，3B/4B 模型通过蒸馏技术将逼近 8B 通用模型效果。硬件上，NPU 的普及和存内计算技术将进一步降低功耗。
交互变革：从单一的触控交互向语音+视觉+意图理解的多模态交互演进。正如豆包与中兴的合作所示，系统级入口（侧边键、耳机唤醒）将成为兵家必争之地。
主动服务：AI 将从"被动工具"转向"主动助理"。具备长期记忆能力的 Agent 将能记住用户的偏好（如"帮我整理下周行程"），并在合适的时机主动提供服务（如"自动比价并领券"）。

7.3 结语：商业闭环与开源价值的思考

虽然从商业化成熟度和用户体验来看，豆包手机助手凭借与手机厂商的系统级深度绑定（如中兴 Nubia），在保活能力、权限获取和交互便捷性上占据了绝对优势，这代表了"极致产品体验"的方向。

但 GELab-Zero 的开源价值恰恰在于其独立性与普惠性：

技术民主化：它证明了不依赖手机厂商的系统级后门（Backdoor）或特权 API，仅凭纯视觉方案（Visual-based），也能在通用 Android 设备上实现高可用性的 Agent。这为非手机厂商的开发者打开了一扇窗。
隐私底线：在巨头们纷纷将数据上传云端进行"混合计算"的当下，GELab-Zero 坚守的"全本地推理"（Local Inference）为医疗、金融等高敏感场景提供了一个可信的替代方案。
标准定义者：它所定义的 ActTree 动作空间、AndroidDaily 评测标准，极有可能成为未来移动端 Agent 开发的行业事实标准。

如果说豆包是 iOS 式的封闭花园精品，那么 GELab-Zero 正致力于成为移动端 Agent 时代的 Android——虽然粗糙，但充满无限可能。对于开发者而言，它提供了一个绝佳的实验平台，让你现在就能在自己的电脑和手机上，构建出能够理解世界、操作应用的下一代 AI Agent。

八、参考资料

github.com/stepfun-ai/…
huggingface.co/stepfun-ai/…
www.modelscope.cn/models/Qwen…
huggingface.co/datasets/st…
论文：GUI Exploration Lab: Enhancing Screen Navigation in Agents via Multi-Turn Reinforcement Learning (NeurIPS 2025)
juejin.cn/post/757908…
www.youtube.com/watch?v=eoY…

附录：

A.1 单任务执行脚本

项目中的示例：
python examples/run_single_task.py

A.2 轨迹可视化启动

# 仅本机访问
streamlit run --server.address 127.0.0.1 --server.port 33503 --server.headless true visualization/main_page.py

# 局域网访问
streamlit run --server.address 0.0.0.0 --server.port 33503 --server.headless true visualization/main_page.py