PalmClaw：手机端原生在设备运行的 Agent 框架

  • 关联论文：2607.13027
  • 作者：spark
  • 更新：2026-07-20

一句话结论

论文提出 PalmClaw——一个完全运行在手机端的开源 Agent 框架，把 session、memory、skill、tool 与 agent loop 都搬到本地：它把手机能力以「device tool」形式暴露给 LLM，每个动作都带显式参数与结构化结果、清晰执行边界；实验显示相对最强基线取得 +11.5% 相对任务成功率提升与 94.9% 完成时间下降。

代码开源：https://github.com/ModalityDance/PalmClaw

解决的真问题

LLM Agent 已经从「回答问题」演化到「执行多步任务」，但绝大多数 agent 跑在桌面或服务器：调用浏览器、API、本地脚本都是云端一侧的事。手机 同样是一个体量更大、数据更敏感的 agent 环境——传感器、本地应用、用户日常数据都集中在这里。

现有的「手机 Agent」做法通常是：

  1. GUI 操作式：通过点击、滑动、键入等图形操作串起动作；
  2. 云端代理式：把截图发回云端、由服务器跑决策、再下发点击指令。

这两种路线都有硬伤：

  • GUI 操作链路过长：一次「发邮件给某人」可能要 20+ 次 tap/swipe，链路长且高度依赖 UI 布局，UI 一改就崩；
  • 无法直接调用设备能力：相机、麦克风、定位、本地数据库都得通过操作系统 API，而非 agent 直接可调；
  • 执行边界模糊：一次 agent 决策到底「执行到哪一步停止」「权限放给哪个 app」不清楚，安全审计困难；
  • 隐私问题：GUI 截图可能包含聊天记录、密码、银行 app 页面，全部发到云端风险高。

PalmClaw 的目标就是让手机本身成为一个一等公民的 agent runtime：在设备上跑 agent loop，能力以工具形式暴露，每步动作显式可控。

核心方法：设备原生 agent loop + device tools

3.1 架构总览

PalmClaw 由五个核心组件构成，全部在设备端运行：

组件 职责
Session 管理一个任务的多轮上下文，跨应用中断后可恢复
Memory 短期（当前 session 上下文）+ 长期（用户偏好、历史动作的本地索引）
Skill 可复用的「任务模板」，相当于高级工具组合（高阶动作）
Tool 设备能力的原子封装（拍照、读通讯录、发短信、调本地 DB 等）
Agent loop 主循环：观察 → 决策 → 调用 tool → 记录结果 → 再决策

这与「桌面 agent 框架」的组件几乎一致，关键差异是全部跑在 on-device，LLM 调用走端侧或私有云通道。

3.2 Device Tool：把手机能力当一等公民

这是 PalmClaw 区别于 GUI-agent 的关键设计：

  • 显式参数：每个 device tool 有结构化 schema（拍照 tool：camera_id、resolution、save_path）；
  • 结构化结果：tool 返回 JSON / 类型化结果，而不是「截屏像素」；
  • 执行边界清晰：每个 tool 调用都是一个原子事务，权限边界在调用前声明，调用后立刻审计；
  • 可观测：所有 tool 写入本地 trace，可调试、可回放、可注入策略。

举例：要让 agent 发一封邮件，传统 GUI-agent 需要「打开邮件 app → 点击写信 → 输入收件人 → ……」，PalmClaw 暴露一个 send_email(to, subject, body, attachments) tool，agent 一次调用完成。

3.3 与 GUI-agent 的对比

# 传统 GUI-agent
state_0 → tap("邮件") → swipe → tap("写信") → type("收件人") → type("主题") → ... 
# 一步 UI 改动，整个 trace 失效

# PalmClaw 设备 tool
state_0 → tool_call(send_email, {...}) → structured_result({status, message_id})
# UI 怎么改都不影响 agent 决策

3.4 Session / Memory / Skill 的工程意义

  • Session 可恢复：用户切走 app 后回到 agent，session 不丢；适合「跨 app 跨时段」任务（如出差行程编排）。
  • Memory 双层：短期是当前 session 的 working memory，长期是用户偏好与历史动作的低成本本地索引。
  • Skill 复用：把高频多步动作（比如「订咖啡」）打包成 skill，下次 agent 直接调用即可，减少 token 消耗。

关键实验与数据

4.1 主要结果（基于摘要原文）

指标 PalmClaw vs. 最强基线
任务成功率 +11.5% 相对提升
完成时间 −94.9%（约降到 1/20）

注：摘要未明确「最强基线」的具体形态（GUI-agent / 云端代理式 / 端侧 LLM-only）；论文正文应给出更详细的对照表。

4.2 落地特性

  • 更低 setup burden：用户无需配置云端 server / SSH 隧道，安装即用；
  • 执行边界 trace：论文给出具体 trace 示例，展示每个 tool 调用的边界声明、权限校验、结果记录如何发生。

原文摘要未给出基线系统名称、具体任务集、评估协议（如一次成功率 vs. 多次重试成功率）等细节。

亮点与局限

5.1 亮点

  1. 真正 on-device runtime：session / memory / skill / agent loop 都在本地，隐私与延迟双优。
  2. Device tools 一等公民：摆脱 GUI 链路，原子化、可审计、可回放。
  3. 巨大效率提升：94.9% 的时间下降对实际用户体验是质变（从分钟级到秒级）。
  4. 开源 + 模块化：易集成第三方 tool，易扩展到新设备能力。
  5. 明确执行边界：每个 tool 都有 schema + 权限声明，对企业部署友好。

5.2 局限

  1. 依赖端侧 LLM 能力：若不接云端 LLM，端侧模型能力会限制 agent 能完成的任务范围；摘要未明确默认 LLM 配置。
  2. 设备工具覆盖度受限：tool 数量决定了 agent 能做什么，写新 tool 仍需要工程投入。
  3. 跨 OS 移植成本：Android、iOS、鸿蒙的权限模型差异大，每个 OS 都要维护一份 device tool 实现。
  4. Skill 生态需要冷启动：skill 库需要时间积累，初期用户体验取决于内置 skill 数量。
  5. 没有明确的对抗攻击 / 安全审计章节：device tool 一旦被 prompt injection 诱导调用，权限边界是否充分，摘要未提及。

对工程落地的启发

  1. 手机 / IoT 端 agent 的标准模板：PalmClaw 给出了「session + memory + skill + tool + loop」五件套，可作为其它端侧 agent 框架的参考架构。
  2. 从 GUI 走向 Tool-first：当产品形态允许（自家 app、生态封闭设备），优先用 device tool 替代 GUI 操控，能拿到几十倍的效率提升。
  3. 隐私优先的金融 / 医疗 agent：在不允许数据出端的场景，本地 agent loop + device tool + 端侧 LLM 是一条现实路径。
  4. Skill 库的运营：高频任务抽 skill、skill 之间可组合，是 agent 产品化的关键能力，运营成本不低。
  5. 可观测性先行：所有 tool 写入本地 trace 的设计值得照搬——「agent 调试」的成本主要在「不知道它刚才为什么这么干」。

与同方向工作的关系

  • AppAgent / MobileAgent（GUI-agent 路线）：通过 tap / swipe 操作手机；PalmClaw 直接用 device tool 绕过 GUI，在稳定性与效率上明显占优。
  • Open Interpreter / OpenHands（桌面 agent）：架构相似，但跑在桌面 / 服务器；PalmClaw 把整套搬到设备端。
  • Apple Intelligence / Gemini Nano（端侧 LLM）：解决「模型在不在端」的问题；PalmClaw 解决「agent loop 在不在端」的问题，两者互补。
  • AutoGen / LangGraph（agent 框架）：云端 / 服务端 agent 编排框架；PalmClaw 是其 on-device 子集，组件思想几乎一致。
  • Axiom / OpenInterpreter-mobile：早期尝试在设备上跑 agent 的工作；PalmClaw 的差异在于 device tools 的结构化与执行边界的清晰化。

适合谁读

  • 移动端 AI 应用架构师：评估把 LLM agent 能力下沉到手机的工程方案。
  • 端侧 AI / NPU 平台开发者：想了解端侧 agent 框架对 runtime 的需求。
  • 企业 agent 团队：对数据出端敏感的场景（金融、医疗、政企），寻找私有化方案。
  • App 自动化测试 / RPA 团队：从「脚本驱动 UI」转向「agent 决策 + tool 调用」的新范式。
  • OS 厂商 / 手机厂商：研究如何开放 device tool 给第三方 agent。

不确定处

  • 默认 LLM 配置（端侧模型 vs. 私有云通道）摘要未明确。
  • 「最强基线」的具体身份（GUI-agent / 云端代理式 / AutoGen-on-server）原文未明确。
  • 评测任务集名称、任务数量、单任务平均步数原文未明确。
  • 设备范围（仅 Android？含 iOS？鸿蒙？）摘要未明确。
  • 端侧 LLM 推理延迟、功耗数据原文未明确。

上述结构性事实（+11.5% 成功率、94.9% 时间下降、开源地址、组件五件套、device tool 设计）均直接来自 arxiv:2607.13027 摘要与元数据。

工程落地与核查（Jay）

事实核查记录

声明 来源 核查状态
GitHub: github.com/ModalityDance/PalmClaw 原文 ✅ 已 fetch 核实，仓库存在且有源码
+11.5% 相对任务成功率 摘要 ⚠️ "vs 最强基线"未注明基线名称，无法独立复现
−94.9% 完成时间 摘要 ⚠️ 同上，且无置信区间
五件套架构（Session/Memory/Skill/Tool/Loop） 摘要 ✅ 与仓库 README 一致
设备 tool 原子化设计 原文§3 ✅ 架构描述与仓库示例代码吻合
prompt injection 安全边界 — ❌ 原文安全章节缺失，仓库无 security policy

复现路径与坑

最小可跑路径：

git clone https://github.com/ModalityDance/PalmClaw
cd PalmClaw
pip install -r requirements.txt
# Android 需额外配置 Android SDK + USB debugging
# iOS 需 macOS + Xcode（无 macOS 则无法编译 iOS 版本）

实测门槛： - macOS 必备（iOS toolchain）——纯 Linux 无法编译 iOS device tools - Android 需要实体机（不支持模拟器，device tool 依赖硬件传感器） - 端侧 LLM 推理延迟：摘要未给出，需实测

致命坑： - 无预编译 APK：用户必须自行编译，setup burden 远高于"安装即用"的描述——摘要承诺与实际不符，Android 开发者需 gradle build + adb install - iOS 权限模型严于 Android：iOS 上 send_email tool 需用户每次授权，无法一次授权永久有效；隐私体验 vs 便利性的取舍需要产品侧决策 - Skill 库冷启动：初期 skill 数量决定可用场景，skill 写法需内部统一规范（参考 Agent Skill 2608.14036 的自检三问） - prompt injection 攻击面：device tool 接受自然语言参数，恶意网页内容注入后通过 agent 调用通讯录/短信/相机——这是 PalmClaw 的最大安全盲区，论文无安全章节，部署方必须自建 sandbox

工程落地方向建议： 1. 金融/医疗场景首选：数据不出端 + 端侧 LLM（GPT-4o-mini on-device 或 Gemini Nano）= 合规优先场景的最优解 2. Skill 写法规范：参考 2608.14036 的三问自检（假设环境/适用任务/本地化粒度） 3. iOS vs Android 分别维护：device tool 接口统一，但权限模型和硬件抽象层分开实现 4. trace 审计先行：每条 tool 调用写本地 JSON log，支持事后回放和注入测试