lijianfei.com

在探讨移动端自主智能体（Mobile Agent）的系统工程时，我曾深入分析过 Mika 如何利用 AOSP 虚拟显示（VirtualDisplay）与独立焦点隔离技术，让单台手机得以在后台静默操作 App 而不干扰用户主屏。然而，当把端侧 Agent 推向真实的多账号运营、矩阵获客、跨应用数据协同或自动化测试等工业级场景时，单台设备无论算力、带宽还是身份配额，都会迅速撞上物理天花板。

开源项目 phongent（由开发者 mylea1 基于 Mika 深度拓展并开源）给出了极具野心的演进答案：它彻底打破了“单机自律”的局限，构建起一套完全去中心化的跨平台多设备 Agent 协同控制网络。你只需手持一台 iPhone 或 Android 手机作为移动主控，无需依赖任何电脑与数据线，便能通过局域网以自然语言实时调度整个 Android 手机机群——从层级化任务规划分发、有序 SSE 事件总线，到低延迟硬件级虚拟屏推流、租约式人工介入接管与全域通知逆向回复，展现了移动端 Agent 从单兵作战走向机群作战的深厚架构功力。

1. 范式转移：为什么移动端 Agent 必须从“单机死守”走向“机群协同”？

在过去很长一段时间的自动化实践中，我一直在思考一个核心矛盾：当端侧 Agent 的感知、推理与规划能力日趋成熟，为什么整体生产力依然难以形成质的飞跃？

追根溯源，单机运行环境存在三重无法通过“单点算法优化”解决的结构性瓶颈：

1. 物理账号与身份配额的单点囚徒困境：主流移动平台（如微信、小红书、抖音、淘宝等）对单设备、单 IP、单物理指纹的调用频次、登录状态和内容发布配额都有严苛的风控限制。无论一台设备上的 Agent 多么智能，它都无法安全、并发地承载矩阵化业务诉求。
2. 多任务执行吞吐的刚性天花板：即便通过 VirtualDisplay 实现了无感后台运行，单颗移动 SoC（CPU / NPU / RAM）在同时承载本地多模态 OCR、视觉推理、虚拟屏渲染与多任务上下文时，资源消耗已逼近峰值。如果强行在单机上并发执行多套工作流，势必导致系统 OOM 降频乃至应用假死。
3. 传统群控方案的重型与脆弱性：业界过往的“手机群控”方案（如 USB 菊花链集线器配合 PC 端的 scrcpy、STF 或 Appium 脚本），本质上是将手机降级为无脑的“像素输入输出外设”，所有智能逻辑全部堆叠在笨重的台式电脑中。不仅线缆羁绊导致完全丧失移动便携性，而且只要 USB 接口松动或 ADB 调试掉线，整套流水线就会灾难性崩溃；至于云手机租用方案，高昂的月租成本和将个人/企业敏感账号上传至第三方机房的隐私泄露隐患，更令许多专业团队望而却步。

phongent 的突破点在于：将“控制权”与“执行权”物理分离，同时将主控端原生轻量化到掌中随身设备。

用户手中的日常主力机（无论是 iOS 还是 Android）充当机群的“总参谋部”（任务规划、状态监控、异常接管），而散布在周围局域网内的多台 Android 备用机则各自运行独立的 AgentLoop 充当“特种作战分队”。整套网络不依赖 PC、不依赖公网服务器中转，在纯局域网环境中完成了多设备自主智能体的协同闭环。

2. 总体拓扑：跨平台对等主控与双层执行模型

为了让复杂的机群在掌中毫秒级响应，phongent 梳理出了清晰的跨平台双主控与分布式对等架构：

flowchart TD
    subgraph MasterZone ["移动主控域 (Master Controller)"]
        iOSMaster["iOS 原生主控 (SwiftUI / AVFoundation / ActivityKit)"]
        AndroidMaster["Android 原生主控 (Jetpack Compose / FleetShell)"]
        DispatchLLM["任务规划与分发模型 (LLM Task Router)"]
        ContentGen["本地矢量图卡渲染器 (ContentCard 1080x1440)"]
    end

    subgraph NetBus ["局域网对等通信总线 (LAN Protocol Mesh)"]
        mDNS["mDNS / Bonjour 零配置自动发现 (_mika-agent._tcp.)"]
        AuthPair["Nonce 交互式双向配对 (Bearer Token 鉴权)"]
        SSEBus["有序事件推流总线 (GET /events?heartbeat=30)"]
        VideoBus["H.264 虚拟屏流媒体 (GET /virtual/video)"]
    end

    subgraph WorkerFleet ["Android 执行机群 (Worker Agents)"]
        subgraph DeviceA ["执行端 A (例如: 小红书内容组)"]
            ServiceA["LanService HTTP/SSE 服务"]
            AgentLoopA["Mika AgentLoop (感知-决策-工具)"]
            VDisplayA["VirtualDisplay 焦点隔离后台屏"]
            A11yA["ScreenAccessibility 无障碍驱动"]
        end
        subgraph DeviceB ["执行端 B (例如: 微信通知组)"]
            ServiceB["LanService HTTP/SSE 服务"]
            AgentLoopB["Mika AgentLoop (感知-决策-工具)"]
            VDisplayB["VirtualDisplay 焦点隔离后台屏"]
            MsgListenerB["MessageListener 微信/QQ 通知捕获"]
        end
        subgraph DeviceN ["执行端 N ..."]
            WorkerN["独立 AgentLoop + 本地执行沙箱"]
        end
    end

    iOSMaster --> NetBus
    AndroidMaster --> NetBus
    DispatchLLM --> iOSMaster
    DispatchLLM --> AndroidMaster
    ContentGen --> iOSMaster
    ContentGen --> AndroidMaster
    NetBus <--> DeviceA
    NetBus <--> DeviceB
    NetBus <--> DeviceN

双主控对齐（Controller Parity）与能力边界

在源码设计上，phongent 实现了 iOS 与 Android 双端主控的高标准功能对齐：

[!NOTE] 为什么执行端只能是 Android？
这是由于移动操作系统底层权限模型决定的：Android 提供了完整的无障碍服务（AccessibilityService）、无线调试（ADB 提权）以及私有虚拟显示（VirtualDisplay），使得 Agent 可以静默模拟点击与捕获离屏画面；而 iOS 的严苛沙盒禁止后台截屏、跨应用模拟事件与常驻私有屏幕，因此 iOS 在体系中定位于完美的移动便携指挥官，专注呈现图表、调度任务与硬解流媒体。

3. 零配置局域网发现与 Nonce 交互配对机制

在以往的局域网工具中，配对往往是体验最糟糕的一环：用户需要反复查看路由后台、手动敲入动态变动的局域网 IP 地址、核对端口乃至输入 6 位配对码。

phongent 借助标准网络协议打磨了一套完全静默且安全的自发现与配对握手流：

sequenceDiagram
    autonumber
    participant Master as 主控端 (iOS / Android)
    participant Worker as 被控端 (Android 执行机)
    participant User as 用户物理交互

    Worker->>Worker: 启动前台服务，广播 mDNS 服务 (_mika-agent._tcp.)
    Master->>Master: 监听局域网 NSD / Bonjour 广播，雷达扫出设备
    Master->>Worker: POST /pair (携带 64 位 Nonce 与主控设备名)
    Worker->>User: 弹出高优先级系统通知 / 授权弹窗："是否允许 [主控名] 连接？"
    User->>Worker: 点击“允许授权”
    Worker->>Worker: 生成该设备专属强随机 Bearer Token
    loop 轮询确认 (最大 85 秒等待)
        Master->>Worker: GET /pair/{nonce}
        Worker-->>Master: 状态 Approved，返回 Bearer Token
    end
    Master->>Master: 将 Token 写入 iOS Keychain / Android 存储
    Master->>Worker: 携带 Authorization: Bearer {token} 建立长效通信

核心源码实现细节

在 Android 端主控 FleetController.kt 中，配对与握手逻辑被封装得极其精炼：

private suspend fun pairDevice(device: Device) {
    // 生成防重放与防猜测的 64 位随机 Nonce
    val nonce = UUID.randomUUID().toString() + UUID.randomUUID().toString()
    request(device, "/pair", JSONObject().put("requestId", nonce).put("name", Build.MODEL), authenticated = false)
    
    // 执行端弹窗等待用户物理确认，主控端以 1 秒为步长进行有限次重试轮询
    repeat(85) {
        delay(1000)
        val result = request(device, "/pair/$nonce", authenticated = false)
        when (result.optString("status")) {
            "approved" -> {
                // 配对成功：持久化 Token 并立即拉取整机状态快照
                prefs.edit().putString("token:${device.id}", result.getString("token")).commit()
                refresh(device)
                check(mutable.value.firstOrNull { it.id == device.id }?.connected == true) { 
                    "已授权，但设备连接失败" 
                }
                return
            }
            "denied", "expired" -> error("连接申请被拒绝或已过期")
        }
    }
    error("等待授权超时")
}

这套设计的精妙之处在于：设备发现零手动配置，而物理控制权的让渡完全交由被控手机的人工弹窗确认。一旦 Token 建立，后续所有连接均基于持久化 Bearer Token 自动静默恢复，换网或重启后无需再次授权。

4. 传输骨干重构：从低效轮询到有序 SSE 事件总线（LAN Event Stream）

在多设备群控场景下，网络开销是决定设备发热与电池续航的生命线。

早期的远程控制原型通常采用短轮询（Polling）机制：主控每隔 1~2 秒向每台被控设备发送一次 GET /state 请求。当受控设备数量上升到 5~10 台时，局域网内瞬间充斥着高频的 HTTP 三次握手与 JSON 序列化开销，导致被控安卓机无线模块长周期处于高功耗激活态（DCH 状态），发热急剧恶化。

phongent 在传输层做出了坚决重构：全面切向基于纯 TCP 的 HTTP Server-Sent Events（SSE）长连接有序事件流。

协议帧规范与保活机制

主控端与执行端维持一条长效的 HTTP 管道：GET /events?heartbeat=30，携带 Bearer Token。通信双方遵循以下数据协议：

1. 初始状态快照（Initial Snapshot）：TCP 管道建连握手成功的首个数据包，执行端主动下发全量状态 JSON，包括当前运行阶段（phase）、活跃会话 ID、当前任务进度、电池状态与虚拟屏尺寸。
2. 状态迁移差分包（State Delta）：当 Agent 内部状态机发生流转（如 Preparing $\to$ Running $\to$ WaitingUser $\to$ Ended）时，执行端仅推送单条变更事件：

   data: {"type":"state","runId":"run_1082","phase":"running","step":4,"preview":"正在打开小红书搜索页面..."}
   

3. 消息变更增量包（Message Upserts / Removals）：被控手机收到微信或 QQ 弹窗时，增量推送通知差分：

   data: {"type":"messages","upserts":[{"id":"msg_401","app":"com.tencent.mm","sender":"商务合作群","text":"请问最新报价单在哪？"}]}
   

4. 静默心跳帧（Heartbeat Frame）：若系统处于空闲状态，服务端每隔 30 秒发射一次空保活帧，防止 Wi-Fi 路由器的 NAT 映射表项老化断开。

断线自愈与防雪崩退避机制

移动局域网环境不可避免地存在休眠、锁屏和 Wi-Fi 漫游抖动。在 FleetController.kt 的客户端实现中，采用了指数退避与防重试机制：

private fun ensureStream(device: Device) {
    if (device.id == "local" || !prefs.contains("token:${device.id}") || streams[device.id]?.isActive == true) return
    streams[device.id] = scope.launch {
        var backoff = 1000L
        while (isActive) {
            var connection: HttpURLConnection? = null
            try {
                connection = (URL(device.url + "/events?heartbeat=30").openConnection() as HttpURLConnection).apply {
                    connectTimeout = 5000
                    readTimeout = 40000 // 允许覆盖 30s 心跳的冗余容限
                    setRequestProperty("Authorization", "Bearer " + prefs.getString("token:${device.id}", ""))
                }
                connections[device.id] = connection
                check(connection.responseCode == 200)
                
                connection.inputStream.bufferedReader().use { reader ->
                    while (isActive) {
                        val line = reader.readLine() ?: error("连接已断开")
                        if (line.startsWith("data: ")) {
                            receiveEvent(device, JSONObject(line.substring(6)))
                            streaming.add(device.id)
                            backoff = 1000L // 收到有效帧，瞬间重置退避计时器
                        }
                    }
                }
            } catch (e: CancellationException) {
                throw e
            } catch (_: Exception) {
                streaming.remove(device.id)
            } finally {
                streaming.remove(device.id)
                connection?.let { connections.remove(device.id, it) }
                connection?.disconnect()
            }
            // 断线退避：从 1 秒翻倍递增，最高封顶 30 秒，防止局域网内广播风暴
            delay(backoff)
            backoff = (backoff * 2).coerceAtMost(30000L)
        }
    }
}

5. 调度中枢：层级化任务规划与分发模型（LLM Task Router）

多设备协同最棘手的难题，在于如何将人类一句模糊的自然语言指令，精准拆解并映射到不同职能的硬件节点上。

如果让主控端也跑一套笨重的视觉 AgentLoop，不仅耗电巨大，而且大模型的长上下文与多工具定义极易引发幻觉。phongent 采用了 “认知分工、算力解耦” 的设计哲学：主控端的大模型只担任纯粹的“路由器（Task Router）”，不调用任何执行工具，不撰写具体业务内容，专注于设备映射与指令翻译。

Prompt 铁律约束与严格 JSON 契约

在 FleetController.kt（Android）与 FleetChatStore.swift（iOS）两端，共同固化了极其严苛的提示词约束体系：

let system = """
你是任务路由器，只识别目标设备、拆分并转述任务，不执行任务，也不创作任务要求的正文或图片。
目标安卓 agent 拥有执行工具；你的输出会由程序下发给它们。你没有工具不是无法分发的理由，
不要以直接对话模式回答或要求用户为你授予设备权限。
设备清单：\(roster)。用户附图数量：\(imageCount)，这些图会随任务下发；你不能凭空描述其内容。

输出纯 JSON：{"assignments":[{"deviceID":"清单中的ID","task":"发给该设备的完整指令","cards":[]}],"clarification":""}。
清单包含设备组别。按组分配时展开到该组所有设备；组内点名任务优先于该组通用任务，其余成员执行组任务。
可以同时给不同组不同任务；组名与设备名歧义时澄清。
用户可以直接说“A干某事、B干某事”，不需要@；设备名或唯一简称均可，@只是快捷方式。
其余设备指清单中未被明确指定的设备；@全部或所有设备表示全部。
搜索、打开应用、截图、查找或发送图片、写文案、制作图卡等均作为任务交给目标 agent，不能在分发阶段自行完成。cards 必须为空数组。
用户要求去应用查找图片时，原样保留查找与回传要求，不要误认为必须先上传图片。
素材不足或执行权限问题由执行端核实并询问；你只澄清目标设备或任务分工的真实歧义。
不要把某台设备的专属任务发给其他设备。不添加用户未要求的操作。保留截图、汇报等要求。
同一设备多个任务合并成一条。无指定对象的普通指令默认全部设备执行。
"""

防御性程序校验拦截

大模型在处理复杂分工时极易“自作多情”地在输出中代写好文案或伪造执行结果。为了防止这种越权行为破坏工作流，phongent 在两端代码中加入了防御性断言：

// Android 端：防御性核验
val cards = value?.optJSONArray("cards")
require((cards?.length() ?: 0) == 0) { "分发模型返回了创作内容，任务未发送，请重试" }

一旦主控模型越权生成了本该由执行端 Agent 完成的内容，整批分发会被立即强行拦截并告警，确保 Agent 的自主权与工作空间严格下沉在受控端设备上。

端侧轻量矢量图卡生成器（ContentCard）

在内容分发矩阵中，如果每台设备都需要生成特定的图文海报，传统的做法是调用昂贵且耗时的文生图扩散模型，或者在服务端用大型渲染库处理。

phongent 巧妙地在端侧内置了微型排版引擎 ContentCard：主控模型只需规划好结构化字段（title、body、accent 强调色），主控端直接利用 Android 原生 Canvas / StaticLayout 或 iOS 的 UIGraphicsImageRenderer，在本地纯内存中实时光栅化生成标准尺寸（$1080 \times 1440$）的高清卡片 PNG：

object ContentCard {
    fun render(card: JSONObject): ByteArray {
        val title = card.getString("title")
        val body = card.getString("body")
        require(title.length in 1..60 && body.length in 1..500) { "图文卡片内容过长，请减少单张文字" }
        
        val accent = runCatching { Color.parseColor(card.optString("accent", "#287A76")) }
            .getOrDefault(Color.rgb(40, 122, 118))
        val bitmap = Bitmap.createBitmap(1080, 1440, Bitmap.Config.ARGB_8888)
        try {
            val canvas = Canvas(bitmap)
            canvas.drawColor(Color.rgb(247, 247, 242)) // 柔和米白质感背景
            
            // 绘制顶部主题色条
            val paint = Paint(Paint.ANTI_ALIAS_FLAG).apply { color = accent }
            canvas.drawRoundRect(64f, 72f, 1016f, 92f, 10f, 10f, paint)
            
            // 自动断行排版标题与正文
            // ...
            return ByteArrayOutputStream().use { 
                bitmap.compress(Bitmap.CompressFormat.PNG, 100, it)
                it.toByteArray() 
            }
        } finally {
            bitmap.recycle()
        }
    }
}

渲染完毕后，图片数据经由 /attachments 接口以 Base64 极速上传到目标设备的会话工作区，并自动将其在工作区中的相对路径追加到下发指令末尾。整个过程毫秒级完成，零云端 API 依赖、零流量费用。

6. 实时掌控：低延迟虚拟屏推流与租约式人工接管（Virtual Video & ControlLease）

在多设备并发运行的大规模场景下，最让操作者焦虑的莫过于“黑盒失控”：不知道哪台设备被验证码卡住、哪台设备遇到了反爬弹窗。

phongent 的核心工程亮点之一，就是构建了一套贯穿 Android 底层硬件编码与 iOS GPU 硬解的私有低延迟虚拟屏视频通道，并配以严密的租约式人工接管协议。

1. 硬件级视频流水线（VirtualVideo.kt）

很多群控工具为了省事，直接截屏并传输 JPEG 序列，带宽开销巨大且导致主控端卡顿。phongent 调用了 Android 系统的底层硬件编解码框架 MediaCodec：

// 配置 AVC/H.264 基线规格
codec.configure(MediaFormat.createVideoFormat("video/avc", w, h).apply {
    setInteger(MediaFormat.KEY_COLOR_FORMAT, color)
    setInteger(MediaFormat.KEY_BIT_RATE, 800000)     // 800 kbps 极低码率
    setInteger(MediaFormat.KEY_FRAME_RATE, 10)       // 10 fps 满足监控与点击
    setInteger(MediaFormat.KEY_I_FRAME_INTERVAL, 1)  // 1 秒关键帧间隔，确保快速切入
    setInteger(MediaFormat.KEY_PROFILE, MediaCodecInfo.CodecProfileLevel.AVCProfileBaseline)
    setInteger(MediaFormat.KEY_MAX_B_FRAMES, 0)      // 零 B 帧，将传输延迟压缩到极限
}, null, null, MediaCodec.CONFIGURE_FLAG_ENCODE)

最重要的是，流媒体推流源头严格锚定在 Mika 的后台 VirtualDisplay 帧缓冲区上，坚决不抓取用户的物理主屏。即便此时用户正在 Android 执行机的主屏上微信聊天，主控端也只能看到后台虚拟屏中 Agent 操作 App 的画面，彻底隔绝隐私泄露风险。

2. iOS 端直通 GPU 硬解呈现（RemoteVideo.swift）

在 iOS 主控端，为了在弱算力开销下同时播放多路视频小窗，phongent 避开了笨重的第三方播放器，直接构建在苹果的 AVFoundation 核心架构之上：

final class VideoCanvas: UIView {
    override class var layerClass: AnyClass { AVSampleBufferDisplayLayer.self }
    var display: AVSampleBufferDisplayLayer { layer as! AVSampleBufferDisplayLayer }
}

iOS 接收端从网络流中解析 NALU 单元、提取 SPS/PPS 参数集，构造 CMVideoFormatDescription，并将解包出的 CMSampleBuffer 直接投递给 AVSampleBufferDisplayLayer。利用 iPhone 的专属硬件视频解码器，GPU 渲染耗电极低，发热几乎可以忽略不计。

3. 租约式人工接管协议（ControlLease & RemoteScreen.kt）

如果多台主控同时连接同一台设备，或者用户在主控端点击屏幕的同时 Agent 仍在自动点击，势必引发灾难性的事件竞争。

为了确保接管的原子性，phongent 引入了互斥租约机制（ControlLease）：

sequenceDiagram
    autonumber
    participant Master as 主控端 (iOS / Android)
    participant Worker as Android 执行端
    participant AgentLoop as Agent 思考执行循环
    participant A11y as 系统无障碍服务 (Accessibility)

    Master->>Worker: POST /virtual/input (action: "acquire")
    Worker->>Worker: ControlLease 校验当前无其他主控持有锁
    Worker->>AgentLoop: 发起暂停请求 requestRemoteControl()
    AgentLoop->>AgentLoop: 挂起主循环，状态转为 TaskState.Held(reason = "remote_control")
    Worker-->>Master: 确认接管成功，进入控制态
    
    Master->>Worker: POST /virtual/input (action: "gesture", x: 0.45, y: 0.62)
    Worker->>A11y: dispatchGesture() 模拟相对坐标触控滑动
    
    Master->>Worker: POST /virtual/input (action: "text", text: "8848")
    Worker->>A11y: 获取虚拟屏聚焦输入框，执行 ACTION_SET_TEXT
    
    Master->>Worker: POST /virtual/input (action: "release")
    Worker->>Worker: 释放 ControlLease 租约
    Worker->>AgentLoop: 唤醒 releaseRemoteControl()
    AgentLoop->>AgentLoop: 退出挂起态，继续恢复自主推理与工具调用

这套时序保证了：

• 互斥性：同一时刻绝对不允许两个主控争抢同一设备；
• 确定性：一旦人工介入，Agent 会主动让出控制权并就地挂起，绝不发生“人机抢屏拉扯”；
• 连续性：人工处理完验证码或风控校验后点击释放，Agent 能够从被接管的上下文中无缝衔接，继续执行剩余步骤。

7. 全域消息监控与逆向执行闭环（Centralized Notification & Reply Window）

除了下发任务，多设备运维的另一大痛点是“通知分散”。运营团队往往需要在几十部手机之间来回切换查看客户咨询或系统报警。

phongent 在被控端集成了私密通知采集管道 MessageListener.kt：

1. 隐私约束与安全采信：默认仅监听微信、QQ、小红书等预设应用，内存中最多保留最新的 100 条通知记录，绝不长期持久化到外置存储，严格防止隐私外溢。
2. 多级聚合视图：主控端收到 SSE 增量通知后，在“消息”中心构建起清晰的倒排树：
   被控设备 -> 目标 App -> 会话来源/发件人 -> 消息正文与时间。
3. 逆向回复闭环：在主控设备的消息卡片上，用户可以直接输入回复内容并点击“交由 Agent 回复”。主控端随即向该目标设备的 /command 通道派发专属指令：

   打开微信，找到来自“张总”的未读消息，回复：“合同已审阅，明天下午寄出。”
   

   目标设备的 Agent 立即在后台虚拟屏上自动导航至对应会话完成发信，完成了“主控汇聚监控 $\to$ 主控集中下达 $\to$ 边缘端各自主导执行”的完整闭环。

8. 生产级工程踩坑与演进思考

在全面剖析了 phongent 的源码架构后，结合我长期在移动端自动化一线的调试经验，我认为这套架构对于未来移动 Agent 生态的演进具有极其深刻的参考价值，同时也指明了若干必须正视的现实边界：

核心收益与范式破局

• 解构了对 PC 的病态依赖：它让多设备群控第一次真正装进了口袋。无论是在通勤路上、差旅途中，用手机点一点就能指挥机群协同工作，这才是移动计算时代该有的交互形态。
• 控制流、媒体流与数据流的彻底解耦：JSON 指令走轻量 HTTP，实时画面走硬件 H.264 视频流，事件状态走长效 SSE，三者各司其职，将网络利用率与电池功耗控制在了极高水准。
• 严密的人机协作护城河：没有盲目信任大模型的全自动执行，而是通过小窗流媒体监控、ControlLease 互斥租约与即时接管挂起机制，为人机混合协作（Human-in-the-loop）提供了工业级的安全兜底。

现实局限与工程边界

• 局域网长连接与系统保活拉锯：目前系统基于纯局域网明文 TCP 传输，在复杂的企业级跨子网环境或 Wi-Fi AP 隔离网络下无法自发现；且 iOS 主控一旦退到后台被系统挂起（Suspended），SSE 流与视频流仍会被系统中断，必须依赖用户返回前台时触发快速自愈。
• 社交平台的物理风控对抗：多设备虽然分散了单机频次，但如果矩阵设备连接在同一个民用 Wi-Fi 路由器下，公网出口 IP 相同，依旧容易触发大型平台的 IP 维度风控。在实际商用场景中，往往需要配合 4G/5G 蜂窝数据卡或分布式网络代理才能真正释放机群威力。
• 真机多路并发带宽压力：单路虚拟屏推流虽然仅占 800 kbps，但当同时监控 6~10 台设备的实时视频小窗时，局域网内的无线信道竞争与主控端的渲染压力会显著攀升，需要进一步引入动态帧率调节与智能休眠策略。

无论如何，phongent 为移动端智能体的发展探索出了一条令人振奋的技术路径：AI Agent 不应孤立地困在单台硬件的方寸之间，以对等、跨端、去中心化的网格形态互联协同，才是解放生产力的终极答案。

原文链接与参考资料

• phongent 官方 GitHub 开源仓库：mylea1/phongent: 基于 Mika 的 iOS / Android 多设备 agent 主控与安卓执行端
• phongent 主控与执行端功能对照文档：phongent Controller Parity Specification
• phongent 核心系统架构文档：phongent Architecture Specification
• Mika 上游开源项目仓库：wangzan101/Mika: An on-device AI agent for Android
• Apple Developer 官方文档：AVSampleBufferDisplayLayer - Displaying Decompressed Video Frames
• Android Developers 官方指南：MediaCodec - Low-level Media Codec Interfaces
• W3C Server-Sent Events 标准规范：W3C Recommendation: Server-Sent Events