PalmClaw：面向手机的端上原生智能体框架 PalmClaw: A Native On-Device Agent Framework for Mobile Phones
在手机端原生运行智能体框架，通过设备工具暴露手机能力并施加执行边界。
前置知识
LLM Agent 与 ReAct 循环
LLM Agent 是在基础大模型之上叠加指令、记忆、可复用技能、可执行工具、会话管理与迭代循环的框架。其核心是 ReAct 式的多轮循环：模型每轮产生推理与工具调用，工具返回观测结果作为下一轮输入，直到不再调用工具即视为最终回复。
PalmClaw 的 agent loop 本质上就是把这套 ReAct 循环搬到手机本地运行，理解循环结构才能理解它如何把『远程推理 + 端侧工具执行』拼接起来。
基于 GUI 的移动智能体
现有手机 Agent（如 Mobile-Agent、AgentCPM-GUI）主要通过点击(tap)、滑动(swipe)、输入(type)等图形界面动作操作手机，需要截屏识别 GUI 状态再做动作，常形成很长且依赖界面布局的动作序列。
PalmClaw 提出的全部动机都建立在对 GUI 动作方式三大缺陷的批判之上，理解这种范式的局限是理解本文创新的前提。
工具调用 / Function Calling
工具是连接模型生成的调用与设备能力的桥梁：每个工具有面向模型的规格（名称、描述、JSON 参数 schema）和面向设备的具体函数。模型按 schema 产出调用，框架执行函数并把结构化结果回填会话。
PalmClaw 的『设备工具(device tools)』就是这一机制在手机能力上的具体化，理解 schema/permission/workspace 三重检查是本文方法的关键。
On-Device 与 Termux
On-Device 指框架的核心组件（会话、记忆、技能、工具执行、循环状态）直接运行在手机本机，仅 LLM 推理走远程 API。Termux 是 Android 上的类 Linux 终端环境，被 ClawMobile 这类基线用来在手机侧跑 Agent 运行时。
区分『Agent 框架放哪里』与『LLM 推理放哪里』，是理解 PalmClaw 与桌面端/Termux 基线部署差异的基础。
研究动机
当前 LLM 智能体主要运行在桌面或服务器上（如 AutoGen、AgentScope、OpenClaw），而把手机当作被操作对象。现有移动智能体几乎都通过 GUI 动作(tap/swipe/type)来操控手机，这带来三个具体痛点：第一，高层任务会被拆成对界面布局高度敏感的长动作序列；第二，无法直接访问本地文件、传感器等设备资源与能力；第三，GUI 控制授予了过宽的可达界面访问权，却没有面向任务的明确访问限制或执行边界。部署层面，MobileClaw 需要一台独立电脑加桥接连接、约 15 分钟、共 8 步设置，单任务完成时间高达 1197.0s，既重又慢。
本文的目标是本文目标是设计一个能够原生运行在手机本机、并把手机能力作为一等工具暴露出来的智能体框架。具体而言：要把会话、记忆、技能、工具和 agent loop 全部托管在手机端，让 Agent 不再依赖外部桌面或服务器来编排任务；同时通过『设备工具』让 Agent 直接、显式地使用手机能力，并保证每一个移动动作都是显式且受限的（即有明确的参数、结构化结果和工具特定的执行边界），从而既高效又可控。最终希望证明手机本身可以作为 Agent 框架的运行环境，把移动 Agent 研究从『操作屏幕』推进到『直接且受控地使用设备能力』。
与已有工作不同的是，本文的独特切入角度是把动作空间从『操作屏幕(GUI 动作)』转变为『使用设备(结构化设备工具)』。它不再把手机当作一个需要逐屏点击的界面，而是把设备/媒体、个人数据、工作区文件、Web、通信、定时自动化等能力封装成带显式 schema 与边界的工具。这与近期 Codex CLI、Claude Code、Gemini CLI 等『终端原生』Agent 倡导的显式可执行工具交互一脉相承，但首次把这种『工具优先 + 显式边界』的设计系统性地落到移动端原生框架上。
核心方法
PalmClaw 的整体思路是『把 Agent 框架装进手机 App』。直觉上：既然手机里既有用户数据、传感器、又有日常 App，那就让 Agent 直接住在手机里。技术上，它把会话、记忆、技能、工具和 agent loop 等所有组件都放在手机端运行，只有 LLM 推理走远程 API。每个会话有自己的历史、工具轨迹、附件和独立工作区；Agent 把上下文从 6 个来源拼装好后发给远程 LLM，若返回工具调用就先在本地通过三重检查再执行，把结构化结果回填会话进入下一轮，直到没有工具调用、工具发出完成信号或达到轮数上限为止。一句话：远程负责推理，端侧负责编排与带边界的工具执行。
核心创新是『设备工具 + 执行边界』。与已有移动 Agent 以 GUI 动作为唯一动作空间、把桌面/服务器当作编排宿主不同，PalmClaw 用『带显式参数、结构化结果、工具特定执行边界』的设备工具来暴露手机能力。每个工具调用在变成实际手机操作前要过三关：1) Schema 检查（必填参数、类型、允许取值范围）；2) 权限/确认（设备授权与用户确认，缺权限就触发系统权限或设置流程）；3) 工作区解析（限定在当前会话工作区或已批准的共享存储内，拒绝其他会话工作区与未批准的全局路径）。这样 Agent 拿到的不是一条对手机的开放命令通道，而是一组显式、可审计、可受限的能力调用。
方法步骤详情
完整流程分三段。第一步上下文拼装：把输入分配到会话后，从六个来源组装上下文——系统指令(AGENT.md/SOUL.md/USER.md)、运行时上下文(当前时间、时区、session_id、工作区路径)、共享长期记忆、常驻技能指令与可用技能摘要、最近对话历史与工具轨迹、可用工具规格（名称、描述、参数 schema）；前五类构成 model messages，工具规格随之一并发给远程 LLM API。第二步 Agent 循环：每轮重建上下文→调用远程 LLM→存回 assistant 消息；若含工具调用则执行并把结果追加进会话、开启下一轮，否则即为最终回复；工具发出完成信号或达到轮数上限也结束循环。第三步工具执行：每个调用先在工具注册表匹配，再依次过 Schema、权限/确认、工作区三重检查，通过后才对设备资源执行操作并返回结构化结果，检查失败或用户拒绝则返回结构化错误。技能按 always-active 与关键词匹配按需加载，避免把所有技能全塞进上下文。
技术新颖性
技术新颖性有三层。第一，部署新颖性：首个把完整 Agent 框架（会话/记忆/技能/工具/循环状态）原生跑在手机 App 内，而非桌面、服务器或 Termux，因此不需要独立电脑、CLI 或桥接（设置仅 2 步约 2 分钟）。第二，动作空间新颖性：首次系统性地用『设备工具』替代 GUI 动作作为移动 Agent 的主要动作空间，把高层任务从长点击序列变成少数结构化操作（平均动作数从基线 51.4–103.9 降到 2.8）。第三，安全新颖性：提出工具调用三重检查 + 工具特定执行边界的设计，使权限缺失、工作区越界、用户确认、不支持操作都能被显式拦截并给出可读反馈，而非让 Agent 静默执行越权操作。
实验结果
实验在两个数据集上回答三个研究问题。MobileTask（70 个移动任务，改编自 AndroidWorld/MobileAgentBench/Mobile-Bench）上，PalmClaw 取得 97.1% 成功率、平均 2.8 个动作、50.4K tokens、17.7s 完成时间；相比最强基线 ApkClaw（87.1%/348.8s），成功率相对提升约 $\Delta_{rel}\approx 11.5\%$，完成时间相对下降约 $94.9\%$；而 MobileClaw 仅 60.0% 且需 1197.0s，显示桌面托管+GUI 范式偏弱。AssistantBench（19 个网页检索任务）上 PalmClaw 准确率 36.85%，明显高于 ApkClaw 25.79%、ClawMobile 10.49%、MobileClaw 5.26%。部署上 PalmClaw 不需 Computer/CLI/Bridge、仅 2 步约 2 分钟；执行边界方面，权限缺失与工作区越界都会被显式拦截并给出可读反馈。效率提升主因是设备工具把任务从长链『截屏-导航-点击』压缩为少数结构化操作。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| MobileTask（70 个移动任务成功率） | Success Rate | 97.1% | ApkClaw 87.1%（最强基线）；ClawMobile 77.1%；MobileClaw 60.0% | 相对最强基线提升约 11.5% |
| MobileTask 平均完成时间 | Time per task | 17.7s | ApkClaw 348.8s；MobileClaw 1197.0s | 相对最强基线降低约 94.9% |
| MobileTask 平均动作数 | Actions per task | 2.8 | ApkClaw 103.9；ClawMobile 51.4；MobileClaw 94.3 | 动作数下降一个数量级以上 |
| AssistantBench（19 任务网页检索） | Accuracy | 36.85% | ApkClaw 25.79%；ClawMobile 10.49%；MobileClaw 5.26% | 相对最强基线提升约 11 个百分点 |
局限与改进
作者承认的局限：LLM 推理仍在远程，提供商可能收到 prompt、工具结果与任务上下文，存在隐私风险，需要让用户清楚数据流向。本文的实验均为公开或构造的评测任务，未收集私有用户数据。我自己的观察：评测规模偏小（MobileTask 70 个、AssistantBench 仅 19 个 dev 子集），且只在单一设备（小米 Redmi 2312DRAABC，Android 13 SDK 33）和单一 LLM 骨干（DeepSeek-V4-Flash）上完成，未做跨机型、跨厂商、跨模型的稳健性分析；MobileTask 与执行边界案例集中存在人工评判环节（permission/设备状态类人工复核，答案类用同一模型当裁判），存在评测者偏差风险。此外论文未提供任何真实用户研究来验证边界提示的可用性与端到端体验。
独立分析的弱点
第一，基线可验证性存疑：MobileClaw、ClawMobile、ApkClaw、OpenClaw 四个对照均为带『Claw』命名、且引用 GitHub 路径相近的系统，外部可独立核验的程度有限，比较结果的客观性依赖这些系统的实现质量与调优程度，建议补充与公认公开基线（如 Mobile-Agent-v3、AgentCPM-GUI）的横向对比。改进方向：引入社区公认的 GUI Agent 基线并公开复现脚本。第二，泛化性证据不足：单设备单模型，无法说明换机型/iOS/小模型时边界与成功率是否成立。改进方向：跨厂商、跨系统、跨参数量规模做消融。第三，LLM 远程依赖削弱了『端上原生』的隐私主张。改进方向：引入端侧小模型或混合推理，把敏感上下文留在本地。第四，执行边界目前靠规则三重检查，缺少对越权/对抗性工具调用（如 prompt 注入诱导越权）的鲁棒性评估。改进方向：增加对抗性安全评测与沙箱化执行。
未来方向
作者方向：继续完善执行边界与移动动作的显式性，让 provider 侧数据流向对用户更透明，并在真实部署中验证。基于成果可延伸的方向：一是把远程推理替换为端侧/混合 LLM 以兑现隐私承诺，并研究 $n$ 轮压缩记忆与端侧推理的延迟权衡；二是把 MobileTask 扩展为多设备、多系统、含真实用户的长周期基准，纳入 iOS 等生态与跨 App 互操作；三是把执行边界形式化为可证明的访问控制（capability-based security），并与系统级权限沙箱结合，防范对抗性 prompt 注入；四是把『设备工具』思想推广到可穿戴、车机、IoT 等更多端侧环境，构建统一的『端上原生 Agent』设计范式。
复现评估
复现性总体偏好但存在不确定性。PalmClaw 本体以 AGPLv3 开源、提供可安装包（GitHub: ModalityDance/PalmClaw），明确硬件为小米 Redmi 2312DRAABC、Android 13(SDK 33)、LLM 为 DeepSeek-V4-Flash、MobileClaw 视觉模型为 qwen3.7-plus，并给出轮数上限（PalmClaw 30 轮、屏幕基线 100 轮）等关键超参。数据集统计在 Table 4 中给出（MobileTask 70 个分 8 类、AssistantBench 19 个分 Medium/Hard）。难点在于：MobileTask 是作者从三个公开基准中筛选改写的自建集，最终态检查含人工复核与同模型裁判；四个『Claw』基线缺乏独立可核验的成熟实现；且实验只在单一设备单一模型上完成，他人复现时受硬件、系统版本、LLM 服务波动影响较大。建议作者公开评测脚本与边界案例集以进一步提升可信度。
论文图表
对比两种范式：(a) 外部托管的 GUI 智能体在桌面/云主机与手机之间交换 GUI 状态与 GUI 动作；(b) PalmClaw 把会话、记忆、技能、工具与 agent loop 跑在手机本机，并通过设备工具连接设备资源与能力。
一张图说清本文与现有『桌面托管 + GUI 操作』范式的本质区别，是理解全部动机与方法分工的入口。
列出 6 类能力（设备与媒体、个人数据、工作区文件、Web、通道与自动化、记忆与技能）对应的内置技能与工具，如 calendar()/contacts()/read()/write()/search()/cron() 等。
直观展示 PalmClaw 把哪些手机能力封装成了结构化设备工具，是判断动作空间覆盖度与边界设计粒度的关键依据。