技术挑战
MoFA 的移动端应用场景与传统机器人控制的区别:
机器人控制场景特点:
- 低延迟的硬件通信(微秒级)
- 大量传感器数据实时处理
- Dora-RS 共享内存
移动端 AI Agent 场景特点:
- 逻辑推理和决策
- 网络操作和屏幕交互为主
- 对话和任务规划导向
- 延迟容忍度相对较高(毫秒级即ok)
Dora-RS 的移植问题
一些问题:
// Dora 共享内存
shared-memory-server (Dora自有)
├── shared_memory_extended = "0.13.0"
├── raw_sync_2 = "0.1.5"
- 共享内存依赖:Dora 依赖的
shared_memory_extended
crate 在移动平台支持不完整 - 进程间通信机制:移动操作系统 IPC 机制与桌面系统差异
- ARM 架构适配
方案
方案一:Termux + Root权限 完整移植(Demo阶段)
技术架构
Android Host
├── Termux (完整Arch Linux 环境)
│ ├── libandroid-shmem (共享内存)
│ ├── Rust 工具链
│ ├── Dora-RS 完整版
│ └── MoFA 智能体框架
└── Host Bridge App(参考Auto.JS)
├── 屏幕截图 API
├── 触摸注入 API
└── Socket 通信桥接
分层验证计划
基础环境
□ Termux 安装与 Root 权限获取
□ 基础 Linux 命令可用性验证
□ 网络连接和文件系统权限测试
pkg update && pkg install -y git curl wget
su -c "whoami" # 验证 root 权限
Rust 工具链
pkg install rust
rustc --version && cargo --version
共享内存
# 内核支持检查
cat /proc/version
ls -la /dev/shm
git clone https://github.com/termux/libandroid-shmem
cd libandroid-shmem && make && make install
gcc test/test.c -o test_shmem && ./test_shmem
Dora
git clone https://github.com/dora-rs/dora
cd dora
cargo build --bin dora-daemon
cargo build --bin dora-coordinator
# 基础运行测试
./target/debug/dora-daemon --help
MoFA
pip install -e . #安装MoFA,具体省略
python examples/hello_world/hello_world.py
Host-VM 桥接层设计
屏幕数据流:
// Android Host 端,demo code,尚未实现
class ScreenBridge {
fun captureScreen(): ByteArray {
val mediaProjection = getMediaProjection()
val imageReader = ImageReader.newInstance(width, height, ImageFormat.JPEG, 1)
return compressedImageData
}
fun sendToVM(data: ByteArray) {
socket.write(data) // 通过 Socket 发送到 VM
}
}
操作指令回传:
# VM 中的 MoFA Agent,demo code,尚未实现
class AndroidOperationNode:
def __init__(self):
self.bridge_socket = socket.connect("unix:///tmp/android_bridge")
def click(self, x: int, y: int):
command = {"action": "click", "x": x, "y": y}
self.bridge_socket.send(json.dumps(command))
方案二:原生 Android 重设计
新架构设计
Android Native MoFA
├── Zenoh-Kotlin 通信层
├── Agent Runtime (Kotlin/Java)
├── 智能体模板系统 (简化版)
├── Android Services
│ ├── AccessibilityService (屏幕操作)
│ ├── ScreenCapture (截图服务)
│ └── ForegroundService (后台保活)
└── Mobile Node Hub
├── AutoJS 集成节点
├── UI Automator 包装
├── Intent 调用器
└── API 调用节点
前两个方案对比
评估维度 | Termux + Linux | Native 重设计 |
---|---|---|
开发速度 | 🟢 快速复用现有代码 | 🔴 需要完全重写 |
运行性能 | 🔴 双层虚拟化开销 | 🟢 原生性能 |
功能完整性 | 🟢 100% 兼容 | 🔴 功能受限 |
用户体验 | 🔴 安装极端复杂 | 🟢 原生体验 |
维护成本 | 🟢 低维护 | 🔴 双重维护 |
进一步场景分析
除非开发者有特殊需求,比如需要 agent 来操作移动端独占的某些 app(淘宝、微信等),但这个市场相对较小,而且容易偏离核心方向。
认真来做的话,移动端方案还是挺费资源的。技术复杂度高,投入产出比不太理想。
但后面可以尝试直接打包到容器,不做操作用户手机的操作,单纯去跑一些信息抓取、文档处理之类的 flow,还是可行的。
方案三:容器化部署
Container-based MoFA Mobile Stage
├── Docker/Podman 容器
│ ├── 完整 MoFA 环境
│ ├── 预装常用依赖
│ └── 标准化运行时
├── 常用Agent/Flow
│ ├── 网页数据抓取
│ ├── 文档处理 Flow
│ ├── API 调用集成
│ └── 数据分析任务
└── 移动端适配
├── 响应式 Web UI
├── 触摸优化交互
└── 离线缓存支持
好处:
- 技术栈完全复用,不用重新造轮子
- 部署简单
方案四:云端 + 网页套壳 App
后期在云端部署后,做一个网页套壳 MoFA Stage 的 app。
Cloud MoFA + Mobile Client
├── 云端 MoFA
│ ├── 智能体运行环境
│ ├── 任务调度系统
│ └── 结果缓存层
├── 移动端 App (网页套壳)
│ ├── MoFA Stage 移动版
│ ├── 任务创建与监控
│ ├── 结果展示界面
│ └── 离线模式支持
└── 通信层
├── WebSocket 实时通信
├── RESTful API
└── 消息队列同步
好处:
- 不用造轮子
- 技术栈保持一致,维护简单
- 解决用户的实际需求,不是为了移动端而移动端