--- layout: post.njk source: https://yage.ai/share/mobile-agent-capability-sandbox-20260821.html speaker: yage.ai title: 把 Agent 塞进手机前，先想清楚它能碰什么 date: '2026-08-21' summary: 文章探讨了将 Agent 塞入手机前需要明确其能接触的边界和执行环境。通过对比云端、系统级接口和应用进程内三种 Agent 路线，文章指出移动平台严苛的系统约束（如沙箱、权限限制）迫使开发者必须在‘大脑越强离现场越远’和‘context最贴身但执行环境受限’之间做出权衡，并以 PhoneBuddySDK 的开源项目为例，展示了如何通过参数化边界设计来构建可复用的生成内核。 area: tech-engineering category: ai-application tags: - mobile-agent - agent-architecture - execution-environment - sandbox-security - generative-kernel people: [] companies_orgs: - APUS products_models: - PhoneBuddySDK media_books: [] draft: true status: evergreen --- 手机是普通人用 AI 用得最勤的设备，任务完成度却低得离谱。你要是在电脑前面安排一个写代码的 Agent，它能自己吭哧吭哧干上二十分钟。这二十分钟里，它会翻遍十几个文件，顺手把一个复杂的工程项目重构一遍。换到手机屏幕前，日常交互大多还停留在来回对话。同样的底层大模型，隔着电脑和手机两种不同形态的屏幕，最后交出来的答卷差了一整个数量级。说白了，手机上的 AI 还是个只会聊天的陪聊。 这两者的巨大落差，其实藏在模型之外的地方。咱们要明白，一个能自己干活的 Agent 包含两个核心部分。一个是出主意的大脑，也就是大模型本身。另一个是实际运行工具的执行环境，也就是替大脑干活的手脚。桌面上这个执行环境天然存在一个默认答案，也就是系统自带的命令行控制台。大脑决定下发什么指令，程序直接运行，遇到报错直接回退重试。手机操作系统在设计之初，为了安全考虑，直接把这条路堵死了。苹果系统拦住应用唤起子进程的行为，应用各自隔离在专属的沙箱区域里。两家应用商店针对下载和执行代码都制定了明文限制条款。这就好比给 AI 套上了层层枷锁，缺少可靠的执行手脚，大脑再聪明也难以推进具体工作。你让一个手脚全捆住的天才去干活，结果自然好不到哪里去。 不过呢，事情有了转机。8 月 18 日，一家叫 APUS 的中国公司在 GitHub 上开源了一个项目，叫 PhoneBuddySDK。它是一个给 App 开发者用的库：你把它塞进你的 iOS 或 Android App 里，你的 App 里就多了一个 AI Agent，给移动端系统约束提供了一种新解法。看这个开源代码之前，咱们先一起梳理一下当前手机 Agent 的几条现有路线。摸清了这几条老路，更能看清这个新方案所处的位置，以及它真正应对的工程卡点究竟在哪里。了解背景，才能看出门道。 ## 手机是离人最近的入口，却是 Agent 最弱的平台 咱们先挨个看看手机上现有的 Agent 形态，你仔细盘点就会发现，每种路径都缺失关键拼图。日常生活中最常见的莫过于聊天应用。像 ChatGPT 和豆包这类产品将大脑挂载在云端服务器上。模型通过厂商提供的接口，可以在网上搜索各种资料，也能顺手生成几张图片。它就是碰不到设备里的本地文件、相册或者其他第三方应用。这套工具集由开发商在云端统一定义，某款独立应用想接入类似的深层能力，完全找不到入口通道。它们就像是住在云端城堡里的神仙，看得远，却管不到你手机里的柴米油盐。 顺着系统的口子往下找，接着咱们聊聊入口最深的系统级语音助手。Siri 占据着最深层的系统入口，长按按键或者一句话即可唤起。可惜的是，它能干多深全靠硬件厂商单方面包办。第三方应用只能通过系统预留的一点点接口，暴露少量的动作指令给它。编排逻辑对开发者保持封闭。助手本身长期停留在设闹钟和查天气这类表面交互。你让它干点复杂的活，它就只会傻笑或者说听不懂。它离系统最近，却也是最刻板的一个。 再看第三类，直接把手机当成遥控器，把活儿甩给远端的服务器或电脑去跑。这套玩法在桌面侧早就不新鲜了，Claude Code、Codex、Cursor 都把长任务放进自家管理的云端沙箱里执行，我在之前的文章里梳理过这批产品的来龙去脉。移动端的版本算是它的自然延伸。Tencent 的 WorkBuddy 支持用户在手机上发消息，将任务调度给云端服务器或个人电脑去跑（Tencent Cloud 文档）。豆包也在 8 月 17 日上线了手机远控已授权电脑的新功能（报道）。这条路线能把能力拔到最高，你想想，背后是一整台电脑在供它驱使。代价同样清晰，执行环境完全留在远端。屏幕上的内容、文件交互和操作轨迹全部落在云端或者另一台机器上。手机断网后，你发不出新指令，也收不到进度，不过云端任务本身多半还在跑，重连之后回来看结果就行。权限边界也完全画在远端。手机在这个过程里充当发起器和回收器，本身不承担具体的执行动作。这就好比你在用手机玩云游戏，画面在手机上，运算全在远方的机房里。 这三种形态表面上看着五花八门，其实存在一个共同点。执行环境全都不在手机应用自身的进程之内。它们要么待在厂商云端，要么在系统层，要么交给另一台远端的设备。产生这个巨大缺口的原因在于严苛的平台约束。苹果手机系统屏蔽了 fork 调用，工程层面毫无商量余地。应用只能乖乖待在各自隔离的专属沙箱内部。商店审核对代码执行卡得十分严格。Apple 的审核条款明文要求应用自包含，禁止执行任何会改变功能的下载代码（2.5.2 条款）。Google Play 的规矩同样严厉，禁止从商店外下载原生可执行代码，只给解释器内的脚本留了例外（政策原文）。 综合这些限制条件，移动端 Agent 的首要问题可以摆成一条光谱。光谱的一端是大脑最强，却离手机 context 最远的云端。光谱的另一端 context 最贴身，平台却把执行基础设施没收得干干净净。两端天然打架，毕竟搬运 context 有成本。大家要么把 context 搬向算力，要么把算力请求搬向 context。桌面 Agent 依靠一个默认存在的控制台绕开了这个卡点。手机上缺乏默认答案，逼着各家路线在这条光谱上寻找自己的落点。大家都在八仙过海，各显神通。 ## 一条光谱：大脑越强，离手机的现场就越远 咱们先看光谱的一端，有些方案选择把执行动作放得最远，依托云端或远端宿主。这代表了大脑最强的极端。任务舒舒服服地在云上的虚拟机或用户的个人电脑里运行。云端机器配置了完整的开发环境，要什么有什么，长任务执行也不受手机电量限制。这边的代价同样极端，它的眼睛和手脚严重受限，读不到手机里的文件，也调不动别的 App。手机只负责下发指令和接收最终结果，context 只能整体搬运到云端。数据一旦离开本地设备，手机断网后只剩等待，控制通道暂时断掉，权限设定也都画在远端。 再来看看操作系统层面的动作，有些大厂选择系统当代理的中间组装策略，按函数粒度最小化 context 搬运。Apple 提供 App Intents 让应用向 Siri 和系统暴露具体能力。Foundation Models framework 从 iOS 26 版本起，向第三方开放约 3B 参数的端侧模型和工具调用机制（文档）。今年 WWDC 会议有专门场次指导开发者，教大家怎么给智能化功能添加安全检查点（session 视频）。Google 在 Android 16 引入 AppFunctions 功能。核心思路是让每个应用成为一台手机内的 MCP 服务端。应用通过注解声明自身能够执行哪些函数。系统居中维护全局注册表，调用方调用前需要申请 EXECUTE_APP_FUNCTIONS 权限（官方文档）。这套权限模型类似于数据库的授权表设计，能力逐条声明并逐条授予。目前的现状依然处于早期探索阶段。AppFunctions 的 Jetpack 库在 2026 年 7 月仍在 alpha 阶段，Gemini 深度集成处于 private preview 状态。 这一类方案中存在一个权限更高的变体，也就是 OEM 级别的图形界面 Agent。豆包手机助手与 nubia 合作机型，选择直接读取屏幕内容并模拟点击，跨越所有应用边界进行操作（nubia 发布）。它表面看起来最强大，占据了最宽泛的权限。由于每个动作的具体语义全部隐藏在复杂的界面交互细节里，安全审计难度远高于声明式接口。你很难搞清楚它究竟点开了什么，这种黑盒操作的安全成本不低。 要是嫌操作系统走得太慢，开发者还能选择将执行留在应用进程内部。这套组装策略把光谱两端拆开重组，大脑留在云端 API，手脚眼睛搬进 App，在 App 范围内实现 context 零搬运。开发者直接把一个 Agent 引擎嵌进自己的应用代码里。能力深浅由开发者自行定义，所有数据老老实实保留在应用沙箱内。同一套引擎可以跨 iOS 和 Android 双端复用。它能触达的上限受限于宿主应用本身的权限，一个相册应用里的 Agent 碰不到系统通讯录。这是进程内落地的代价，也是系统边界清晰的直接来源。想要多大权力，就看应用本身有多大权力。 三条移动端 Agent 路线的对照：云端或远端宿主、操作系统级接口、应用进程内 runtime，在执行位置、权限模型、数据归属和离线能力四个维度上的差异 这三条路线其实是光谱上的三种组装策略。操作系统接口吃下跨 App 编排，系统手里握着完整的注册表和权限体系，名正言顺。进程内运行环境提供开发者在自家 App 里的选点自由。PhoneBuddySDK 的意义在于它把这个 trade-off 参数化了，能力集开发者自选，边界画死。它未必是最完美的点，却让开发者在光谱上有了自己的选点工具。这也构成目前公开样本里，把进程内这条路走得最深入的一家。别人还在门外打转，它已经进屋开始装修了。 ## 把 Agent 装进 App 之前，先画五道边界 PhoneBuddySDK 这个引擎底层完全由 Rust 编写。它通过 C 接口配合 Swift 和 Kotlin 绑定嵌入应用进程，采用 Apache 2.0 协议开源。其 v0.1.1 版本的发布说明自述代码移植自 xAI 开源的 grok-build 项目。它将桌面端 Agent 的执行机器，硬生生整个压缩进一个应用进程里。工具调用循环、流式内容输出、会话状态管理以及子任务编排，全部在进程内跑完，没有任何子进程。这就是它的厉害之处，螺蛳壳里做道场。 这个项目最具参考价值的部分，在于它没有制造一个假命令行终端来糊弄底层模型。它将 Agent 需要的每种能力在代码里重新实现了一遍，给每一种操作加上受控的执行栅栏。我去了源码里数了数，这些笼子确实写了，不是吹的。 最外层的一道限制落在文件访问上。所有文件工具接收到的路径字符串，必须经过 resolve 函数处理。程序先执行词法归一化，检查目标路径确实落在指定的 root 目录之内。路径在文件系统中已经存在的情况下，程序会再次解析真实路径，防范软链接逃逸风险（fs.rs）。哪怕模型产生幻觉，给出一个应用目录之外的绝对路径，系统也会在这一步将其拦下。 往里走，另一道限制卡在网络请求。核心的 web_fetch 工具默认拒绝任何内网地址访问。黑名单规则覆盖回环地址、RFC 1918 私网网段、CGNAT 网段以及基准测试保留段等一批地址范围。开发者即便显式打开本地访问开关，系统也只放行明确声明过的回环主机名（ssrf.rs）。这套设计防范的是恶意操纵下的 Agent 去偷偷探测手机所在内网的服务端口。 再来看看针对脚本执行的限制。模型可以编写 JavaScript 代码，交给进程内嵌的 boa 解释器去执行。这些脚本能看见的文件操作接口只有三个函数，分别对应读文件、写文件和列目录操作。所有调用全都要过同一套文件笼子检查，不讲任何情面。脚本环境里没有网络接口，没有系统调用函数。循环迭代上限设定为两千万次，输出字符串上限限定在三万字符（script.rs）。 还有一道限制负责管理子任务的生命周期。子任务不借助进程 fork 操作产生。它们作为同进程内的异步任务运行，各自保有独立的对话循环，交互轮数上限设定为 10 轮。外部可以随时查询这些任务的状态、等待执行结果、强行终止运行，还能支持从断点位置恢复状态（task_manager.rs）。这就保证了任务跑偏了也能随时拉回来，尽在掌握之中。 最后一道限制处理失败收敛问题。一旦同一个工具用完全相同的参数连续调用 8 次，系统会向模型注入一次警告信息。重复到 16 次，整个交互回合直接终止。系统还规定每条用户消息的执行轮数默认上限设定为 24 轮（doom_loop.rs）。模型在原地反复打转的情况，代码里留有明确的熔断条件。这就避免了无意义的电量与 token 消耗。一旦发现不对劲，立刻拔电源。 PhoneBuddySDK 的五道能力边界：文件路径检查、网络出口黑名单、受限脚本环境、子任务生命周期、失败熔断，共同围住 Agent 的执行循环 在这五道严格的边界之上，它另外提供一套受限工具箱。cat、ls、sort、find 这些常见命令使用 Rust 在进程内做了模拟实现。模型以为自己掌握着一个完整的系统命令行，实际下发的每条命令对应着底层的确定性逻辑实现。这就好比给模型发了一套玩具工具，看着像真的，用起来其实安分守己。 讲真，这个项目还很年轻。项目在 8 月 18 日公开。我核查它代码情况发现有 24 个 star，可见的贡献者仅有一人，仓库里无 issue 无 PR 记录，也没有附加安全政策文件。公开的第二天作者就发布了一个修复打包问题的补丁版本。README 介绍里的性能数字和达到 Claude Code 水平的说法，全部属于发布方主张，目前没有第三方机构独立验证。我通读源码后还发现两处疑点。文档自称 C 接口边界使用 catch_unwind 捕获 Rust 的 panic，当前源码目录里找不到这处调用，release 编译配置里写的依然是发生 panic 即刻中止进程。web_fetch 工具在重定向全部走完之后才会复查最终的访问地址，缺少逐跳拦截机制，中间跳转理论上存在先连上内网地址再触发拦截的可能。这两处细节暂时只是疑点，有待维护者后续回应，目前还不宜视作最终定论。大家先别急着下结论。 现阶段将其直接用于生产环境尚早。咱们把它视为一份优秀的架构设计样本正合适。它提供了一个清晰的答案。移动端 Agent 的边界设计优先级，永远高于单纯的功能堆叠。功能欠缺后续还能补充。权限边界一旦失守，能力越强系统反而越危险。 ## 从能力边界到生成内核 去年 11 月我写过一篇讨论 AI 原生软件工程的文章（超越 DRY）。里面有一个核心判断，AI 掌握现场生成软件的能力之后，软件公司交付的产物从固定功能成品演变成了生成内核。这套内核包含三个关键组件。核心套件提供不可替代的基础能力，如同宜家家具里预先打好孔的椅面和椅腿。引导知识构成写给 AI 读的说明手册，模型花几秒钟读取，用以代替人类工程师积攒数年的领域经验。杠杆工具负责将 AI 容易出错的不确定任务转化为确定性操作，充当那把标准化的内六角螺丝刀。 用这套框架对照 PhoneBuddySDK 的设计，你会发现它完整展示了生成内核在移动端的一种落地形态。三件套里的每一层，在代码库里都能对应到具体的实现实体。严丝合缝，分毫不差。 核心套件对应那套底层的执行机器本身。工具调用循环、流式传输通信、会话状态管理，配合五道边界围起来的受约束能力集合。这些底层模块单凭单个应用开发者难以独立完成。跨平台兼容、运行稳定性以及细致的边界审查，每一项都需要长期投入庞大的工程精力。这活儿太重，普通人啃不动。 引导知识藏在系统提示词以及每个工具的规格说明里。沙箱规则、路径格式要求、碰到啥情况应该停止执行，模型通过阅读这些说明文字学会在全新的手机环境里开展工作。这个开源项目公开第二天的代码提交记录，内容就是给系统提示词瘦身，并将工具的具体用法拆分挪进各自的工具规范里。这个动作本身就是在精心维护专门写给 AI 阅读的规格说明。就像给新员工写操作手册一样。 杠杆工具体现在定制的系统命令和脚本引擎上。模型表现最不可靠的行为之一，在于现场凭空生成系统操作命令。语法完全正确但语义出现严重偏离的情况非常普遍。将常用命令替换为确定性的函数实现，将任意代码执行替换为沙箱内受限的脚本。系统让不可靠的代码生成过程重新落回了确定性的轨道上。 还有一个体量更小的同构例子，就是我自己维护的 VoiceFlowKit 项目。它是一个给任意 iOS 应用添加实时语音输入的 Swift 库。核心套件囊括麦克风数据采集、WebSocket 数据传输和语音转写管线。引导知识体现为一个独立的 skill 文件，写给在别人代码库里干活的 AI agent 阅读。杠杆工具包含测试桩代码、音频计量工具以及带有严格类型的错误枚举。AI 不去直接触碰底层的 WebSocket 通信，也能稳妥组装出可靠的功能集成。它的 README 文档里直接写着 designed as a generative kernel for AI integrators。 移动端苛刻的平台约束条件，反而把这种开发模式逼出了更纯粹的形态。生成内核在移动端的本质，就是让开发者在光谱两端之间拿到一个可参数化的 trade-off 点，大脑用云的，手脚眼睛用本地的，能力集自己圈。在桌面上开发者还能偷懒，直接给模型分配一个命令行控制台。碰到错误大不了直接重启。手机端无法提供现成的命令行环境，能力机制本身就变成必须认真对待和设计的产品。五道边界画得准不准，直接决定这个智能内核的整体质量。限制也是一种创造力。 下次再看到任何手机上的 Agent 方案，不论它是开源 SDK、操作系统原生功能还是某种云端服务，可以拿五个具体问题去问它。文件边界画在什么位置；网络出口默认拦截哪些流量；脚本环境能看见哪些系统接口；子任务能不能支持外部观察和强制终止；失败死循环怎么自动停下来。给得出清晰的答案，说明这个方案真正在把能力授予当作产品设计在做。给不出答案，能力描述得越强大，引入的未知风险就越需要警惕。我们要的是听话的帮手，别招来一个乱砸东西的破坏王。 手机给整个 Agent 产业上的这一课，影响范围早已超出了手机硬件本身。桌面时代执行环境的默认答案一直摆在那里，能力授予这件事可以随意糊弄过去。移动平台的系统约束移除了这个默认选项。每家厂商都只能回答同一个严肃的问题，你的 Agent 到底能碰什么。能把这个问题回答成具体产品的团队，就是在交付 AI 时代的新一代内核。