PhysiClaw 是一个能操作手机的智能体。它用相机观察屏幕，用触控笔点按，像人一样操作手机。
PhysiClaw 是一个硬件与软件结合的项目，旨在打造一个能在真实世界中像人一样物理操作手机的AI代理。它的核心是让AI通过物理方式（摄像头“看”、触控笔“点”）与手机交互，从而绕过应用API限制和自动化检测，完成各种日常任务
PhysiClaw 能做什么？
现有的 AI 智能体主要面向技术场景，最擅长编程、文件处理等工作。但大多数人并不写代码，日常需求集中在手机端，多是网购、点外卖、买火车票、医院挂号、叫车等高频操作。这些任务与智能体当前擅长的领域几乎没有交集。
PhysiClaw 针对的正是这一类日常事务。它不要求用户掌握任何技术，也不依赖 App 提供接口，而是直接操作手机完成上述操作。凡是用户能在手机上手动完成的任务，PhysiClaw 都能代为执行。
核心理念：绕过封闭生态，物理交互
很多日常应用没有公开的API接口，而传统的模拟点击（如ADB）容易被反机器人系统识别。PhysiClaw的解决思路很直接：将手机屏幕本身视为API。
- 物理操作：使用摄像头读取屏幕，用触控笔执行点击、滑动等手势。
- 无法区分：对手机而言，这些操作与真实手指触控无异，因此难以被检测和屏蔽。
- 代价：这种方式的代价是速度较慢，每个操作需要几秒钟，但换来了极高的通用性和可靠性。
与OpenClaw区别
OpenClaw 是个“电脑上的技术助理”——你让它帮你写代码、改文件、跑脚本，它用命令行和 API 干活；PhysiClaw 是个“手机上的生活助理”——你让它帮你点外卖、挂个号、叫个车，它用摄像头看着屏幕、用机械臂戳着屏幕干活。
OpenClaw 不需要任何硬件，装个软件就能跑；PhysiClaw 必须配一套机械臂、摄像头和一部专用 iPhone。
OpenClaw 能直接读写你电脑里的文件、执行系统命令，权限很大；PhysiClaw 压根不碰你的电脑文件，也不执行任何命令，安全边界收得很紧。
OpenClaw 走的是软件自动化路线，容易被反机器人系统识别；PhysiClaw 走的是物理操作路线，手机分不清是手指还是触控笔在点。
OpenClaw 要和它交互，得折腾什么逆向协议或者第三方适配工具；PhysiClaw 直接加个微信好友，发消息就行。
本质上，PhysiClaw 是 OpenClaw 在物理世界的一个分支；OpenClaw 管数字世界的事，PhysiClaw 把同一套 Agent 框架移植到了真实物理世界，给 AI 装上了“眼睛”和“手指”。
###⚙️ 工作原理与使用方式
- 交互方式：用户通过聊天与它交互。项目方为其配置了一台专用手机和独立的聊天账号（如WhatsApp）。你只需像和人聊天一样，用自然语言告诉它任务，例如：“在DoorDash上点一杯拿铁”或“在Instacart上买牛奶和鸡蛋”。
- 运行流程：系统持续运行，当有预定任务或收到新消息时被唤醒。它会自动解锁手机，读取指令，执行任务（遇到支付等关键步骤会暂停等待确认），最后回复结果并保存记忆。
- 硬件与系统要求：
- 必备硬件：需要PhysiClaw的专用硬件套装（机械臂、触控笔、摄像头）以及一台供其操作的iPhone。
- 软件环境：其命令行工具 physiclaw 支持 macOS、Windows 和 Linux 系统。
介绍
别用代码操控手机了，真正的AI操作，靠的是一支触控笔！
你发给AI的每一条指令，它都要用摄像头看完屏幕，再用机械臂替你戳下去！
一个AI智能体，正在用物理的方式重新定义什么叫“操作手机” ——它不管什么API接口、不管什么反机器人检测，它只做一件事：像人一样看、像人一样点。手机那头浑然不觉，还以为是个真人在划拉屏幕。
这话听起来像是科幻道具，但它是GitHub上真实存在的开源项目，名字叫PhysiClaw。
摘要：PhysiClaw是一个软硬结合的开源AI智能体项目，通过摄像头视觉识别和机械臂触控笔，实现对iPhone的物理级操作。本文从其技术路线、硬件架构、交互方式、开源生态、反检测机制及潜在风险六个维度展开分析，揭示“物理操作”这一路径如何在封闭的App生态中撕开缺口，以及这条路究竟能走多远。
第一种思路：让代码替你去点屏幕
手机上的每一个App都像一座四面围墙的院子。
美团的外卖菜单藏在墙里，滴滴的车辆调度逻辑藏在墙里，淘宝的购物车和支付通道也藏在墙里。这些墙不是砖头砌的，是代码砌的——没有公开的API接口，没有对外开放的数据库查询通道，没有任何一条官方允许的路让外部程序直接访问内部功能。
围墙外面站着无数想进去的人。
开发者想做个自动点外卖的机器人，电商运营想做个自动抢单的工具，普通用户想让AI帮自己叫个车——所有人都在墙外面转悠，找门。
最早被找到的门叫API调用。开发者查看官方文档，申请开发者密钥，通过HTTP请求直接调用App的后端功能。这条路走起来最干净、最规范，但绝大多数日常App压根不开放API。少数开放的，申请门槛能卡死普通人：你得是企业认证身份，签一堆法律协议，缴纳保证金，接受审核和限流。普通开发者想给自己写个自动点餐脚本？门都没有。
第二条门叫ADB调试。Android手机开启开发者模式后，可以通过Android Debug Bridge向系统注入触摸事件。代码模拟手指点击坐标，系统以为有人在点屏幕。这条路曾经很好走，但App开发商不傻。他们开始在应用层植入检测模块，识别输入的“软件指纹”——异常的事件注入频率、缺少物理触摸的电容特征、固定的坐标精度——一旦识别出来，轻则弹验证码，重则直接封禁账号。你还没开始自动化，账号先没了。
第三条门叫iOS捷径和Shortcuts。苹果官方提供的自动化框架，绝对安全，绝对合规。但它的功能被刻意锁死在预设模板里：你要让AI灵活应对不同界面、不同状态、不同弹窗？做不到。每一个流程都得手工配置，换一个版本的App界面就全部失效。
第四条门叫大模型视觉操控，也就是目前最火的Computer Use和Operator路线。AI像人一样看屏幕截图，然后让系统模拟点击。但这些方案全部跑在浏览器里——操作的是网页版App。而几乎所有生活服务类App的网页版，功能残缺到连登录都要反复折腾。
五条门，五条死路。
传统思路陷入了一个死循环：软件层面的自动化手段，要么被App开发商封堵，要么被系统权限限制，要么被反机器人检测识别。每一条路走到尽头都是一堵墙。
然后PhysiClaw出现了。
它说了一句让所有人愣住的话：你们找的都是“软件门”，为什么不直接翻墙？
第二种思路：物理翻墙，就靠一支笔和一只眼
PhysiClaw的想法简单粗暴到让人想拍桌子。
代码操控不了手机？那就不写代码。软件被检测？那就不碰软件。API没有？那就不用API。
它选择了一条所有大厂都没走的路：物理操作。
物理操作的第一个环节是“看”。
一个高清摄像头对准iPhone屏幕，以每秒若干帧的频率持续拍摄。画面传输到后台的视觉AI模型——可以是GPT-4V，也可以是开源的LLaVA——模型实时分析屏幕上每个UI元素的类型、位置、状态。“确认下单”按钮在坐标(x₁,y₁)，“返回”箭头在坐标(x₂,y₂)，“输入框”在坐标(x₃,y₃)。一切都像人眼在看，只不过看得更快、更准、更不知疲倦。
物理操作的第二个环节是“点”。
一个三轴或四轴的小型机械臂，末端固定着一支电容触控笔。视觉模型给出了目标坐标，控制系统把坐标转换成机械臂各关节的旋转角度，电机驱动笔尖移动到屏幕上方的对应位置，然后下压、触控、抬起。一套动作下来，iPhone的触摸感应层收到的信号和真人手指点击产生的信号一模一样——电容变化、压力分布、接触面积，没有任何软件层面的异常痕迹。
手机那头发生了什么？
iOS系统收到一个触摸事件，触摸事件被分发给前台App，App按照正常的用户交互逻辑执行响应。界面跳转、数据加载、网络请求——所有流程和真人操作没有任何区别。操作系统不知道背后是一台机械臂，App不知道屏幕上方的触控笔不是手指，服务器不知道这条指令来自一个AI智能体。
这就是物理操作的底层逻辑：绕过所有软件层的门和墙，直接在物理世界模拟人类行为。
PhysiClaw把这个逻辑变成了可运行的工程系统。软件部分基于OpenClaw框架进行二次开发，硬件部分全部开源——机械臂的CAD图纸、触控笔的安装支架、摄像头的固定结构，全部以CAD-as-Code的形式公开发布。用户可以用3D打印机自制零件，采购标准电机和摄像头，自行组装一套完整的物理操作设备。
命令行工具的安装和配置被压缩到了五步之内。curl命令拉取安装脚本，physiclaw命令配置视觉模型提供商，doctor子命令检查环境依赖，最后一条启动命令让整个系统进入待命状态。一台专用iPhone被固定在机械臂前方，充电线常插，屏幕常亮，随时准备接收指令。
第三种思路：用聊天软件当遥控器，把手机交给机器人
你不需要站在机械臂旁边操作它。你甚至不需要和它在同一个房间。
PhysiClaw的交互入口是一个独立的聊天账号——可以是微信，也可以是WhatsApp。项目方建议用户为这套系统注册一个专用的社交账号，添加为好友后，你就可以像给真人发消息一样给它下达指令。
你说：“帮我点一杯冰拿铁，少糖。”
消息送达后台的Agent。Agent被唤醒，先调用解锁流程——密码输入或Face ID镜像验证——让手机进入主屏幕。然后视觉模型开始工作，机械臂开始动作。
打开外卖App。摄像头捕捉到App图标位置，机械臂点击。App启动，加载首页。视觉模型识别搜索框，机械臂点击输入。文字由Agent生成并调用系统键盘输入，确认搜索。结果列表出现，模型识别目标门店，机械臂点击进入。菜单加载完毕，模型找到“冰拿铁”和“少糖”选项，依次点击。加入购物车，结算，确认订单。
每一步都靠摄像头“看”到结果再决定下一步。视觉反馈形成闭环：点一下，看一眼，确认界面变了，再点下一处。这种“感知-决策-执行-再感知”的循环，和人类操作手机的逻辑完全一致。
到了支付环节，系统停下来。Agent向你的聊天窗口发送一条确认消息：“即将支付¥23.50，请回复确认。”你输入“确认”，机械臂才继续点击支付按钮。
整个过程中，你的主力手机可以放在口袋里。你可以在办公室、在通勤路上、甚至在大洋彼岸，通过聊天窗口遥控一台物理机器人替你操作另一台手机。任务完成后，Agent会生成一条结果摘要发回给你，同时把本次操作的上下文保存下来——以后再说“还是老样子”，它就知道该怎么做了。
项目方在演示视频里展示了这个流程的全貌：从接收指令到完成任务，全程无人干预，全靠摄像头看着屏幕、机械臂点着屏幕。视频画面里，iPhone的屏幕在机械臂的点击下一路跳转，最后停在“订单已提交”的确认页面上。
但演示视频只拍了成功的那一遍。
代价是什么？速度，全是速度
物理操作绕开了软件层的所有限制，但它绕不开物理定律。
机械臂的每一个动作都需要时间。摄像头拍照需要几毫秒，图像传输需要几十毫秒，视觉模型推理需要几百毫秒到几秒，机械臂的关节转动需要几百毫秒，笔尖从悬停到触控再到抬起需要几百毫秒。每一步都有延迟，每一步的延迟累加起来，一个完整的操作流程可能需要几十秒甚至几分钟。
点一杯咖啡，人来做只要十几秒，PhysiClaw需要一分钟。在淘宝上买一件商品，人来做可能三十秒，PhysiClaw可能需要三分钟。
这是一个物理层面的硬约束。机械结构的响应速度受限于电机转速和传动比，视觉模型的推理速度受限于GPU算力和网络延迟，这些都不是靠优化代码能彻底解决的问题。
但项目方愿意接受这个代价。因为相比速度，他们更看重通用性和可靠性。
通用性体现在什么地方？
任何App、任何界面、任何版本——只要屏幕上有像素，视觉模型就能识别，机械臂就能点击。不需要App开发者配合接口，不需要操作系统开放权限，不需要针对每个App单独适配。美团更新了界面？视觉模型重新识别一次就行。淘宝改版了按钮位置？摄像头拍到了就找到了。这种“屏幕即API”的思路，把适配成本从O(N²)降到了O(1)。
可靠性体现在什么地方？
没有软件指纹可识别。没有ADB痕迹、没有自动化框架的进程、没有异常的事件注入记录。从操作系统层面看，这就是一个正常的触摸事件。App的防护机制在物理点击面前全部失效——因为你确实是在“真实地点击”屏幕，只是那个“手指”是机械臂驱动的触控笔。
这就产生了一个耐人寻味的对比：软件自动化方案速度飞快但处处被封，物理操作方案步步延迟但畅通无阻。你要快，还是要想去哪就去哪？
但是，物理操作就真的高枕无忧吗
触控笔的点击和手指的点击，在电容感应层面确实没有区别。操作系统收到的是完全相同的触摸事件信号。
但App开发商如果想较真，他们有另一条检测路径：行为模式。
真人操作手机有一个统计特征：点击位置不是固定不变的。每一次点击同一个按钮，落点都会有几像素的随机偏差。滑动操作的速度曲线是一条有噪声的轨迹，不是匀速直线。两次操作之间的间隔时间有长有短，不遵循固定的周期。
机械臂呢？
如果代码写得不讲究，每次点击都落在同一个像素点上，每次滑动的速度曲线都完全一致，每次操作间隔都精确等于1.5秒。这些规律一旦被统计学模型捕捉到，即使没有软件指纹，也能以极高的置信度判定这是机器人在操作。
App开发商目前还没有大范围部署这类行为分析。原因有两个：一是计算成本和误报率，把真人误判为机器人会直接损失用户；二是绝大多数自动化脚本还停留在软件模拟阶段，物理操作的案例太少，不值得专门针对。
但技术上完全可行。只要收集足够多的操作日志，训练一个分类器，识别物理机器人只是时间问题。
这引出了一个更深层的悖论：物理操作的“不可检测性”建立在一个前提上——机器人模仿人类模仿得足够像。如果模仿得不够像，它和软件模拟一样会被识别。如果模仿得足够像，那它本质上就成了一个“伪装成人类”的自动化工具，而非某种颠覆性的新范式。
PhysiClaw的未来取决于它在“模仿人类”这件事上能做到多好。加入随机抖动、加入速度变化、加入延迟浮动——让机械臂的操作更像一个真实的人类手指。但这场猫鼠游戏没有终点。App开发商加一层检测，机器人加一层伪装，你防我攻，永无止境。
一个开源协议和一块机械臂里的隐性成本
PhysiClaw在GitHub上采用MIT许可证发布。软件随便改，随便用，随便商用。硬件设计文件同样开源，CAD图纸可以自己下载打印。
但“开源”不等于“免费”。
你需要一台专用iPhone。项目方的建议是使用旧款设备，专门用来跑任务，不插SIM卡也行，但必须登录你的各类服务账号。旧款iPhone的市场价在几百到一两千之间。
你需要一台电脑运行physiclaw命令行工具。macOS、Windows、Linux三系统都支持，但配置必须满足视觉模型的运行要求。如果使用云端API模型，本地只需要网络和浏览器；如果使用本地开源模型，就需要一块性能足够的GPU。
你需要机械臂本体、触控笔、摄像头、支架、连接线、电源。如果自己3D打印零件再采购标准电机和控制器，全套硬件的成本可以控制在几百元。如果购买成品套件，价格会高一些。
你还需要投入时间。组装机械臂、校准摄像头、配置软件环境、调试点击精度——这些都不是开箱即用的事。GitHub上的294颗星和28个分支里，有多少人真正组装成功并跑通了完整流程，项目方没有公布数据。
最大的隐性成本来自账号风险。你把外卖账号、购物账号、支付账号全部登录在那台专用手机上，交给一个开源机器人操作。代码是开源的，你可以审查它不会偷你的密码。但操作过程中的误触呢？视觉识别错误导致的误下单呢？界面弹窗被误点击导致的订阅服务开通呢？这些风险都由你自行承担。
项目方的免责声明写得很清楚：关键节点暂停确认只覆盖支付等少数环节，其他操作由Agent自主完成。而“关键节点”由Agent自己判断——这个判断机制本身就可能出错。
一个让演示视频不会播的测试结果
PhysiClaw的演示视频里，淘宝购物流程一气呵成。搜索商品、浏览详情、加入购物车、确认下单——每一步都准确无误。
但项目文档里没有透露一个关键数据：视觉识别的准确率。
淘宝的首页是动态的。推荐位因人而异、广告位定时刷新、按钮位置因屏幕尺寸和系统版本而微调。每一次打开，界面都不一样。视觉模型需要在这些动态变化中实时定位出“搜索框”“加入购物车”“确认下单”等关键元素。
准确率如果是99%，看起来很高。但一次操作流程可能需要二十次视觉识别。99%的二十次方是81.8%——每五次操作就有一次出错。
出错的表现形式很多。
把“取消订单”识别成“确认下单”？那你就买到了不想要的东西。把“加入购物车”识别成“立即购买”？那你就跳过了比价环节。把促销弹窗的“立即抢购”识别成正常的“继续浏览”？那你就被带到了一个完全无关的页面，整个流程卡死。
屏幕反光会干扰识别。系统通知弹窗会遮挡关键元素。App更新后的新UI会超出训练数据分布。这些现实世界的噪声，在实验室环境里可以控制，在真实环境中无法避免。
还有一个更隐秘的问题：操作失败后的恢复逻辑。
如果机械臂点错了位置，界面跳转到了意外页面，Agent能不能识别出“当前状态不在预期路径上”？能不能自动回退到上一步？能不能重新规划操作序列？
这些问题在项目文档中找不到答案。演示视频只拍了成功路径，没有拍失败后的回退路径。而真实世界的每一次操作，都可能成为那条没有被拍下来的失败路径。
GitHub上的294颗星说明有人关注，28个分支说明有人在尝试。但没有人知道那些尝试的人里，有多少人遇到了视觉识别错误导致的误操作。也没有人统计过，那些误操作到底造成了什么后果。
PhysiClaw证明了物理操作手机这件事“能做”。但“能做得稳、做得准、做得安全”，是另一回事。项目还太年轻，年轻到连失败率的数字都还没有人认真统计过。
一支触控笔戳向屏幕之前，摄像头已经看了千百遍。但千百遍的识别，抵不过一次界面的临时改版。抵不过一道反光。抵不过一条突然弹出的系统通知。
演示视频里的淘宝订单顺利提交了。但项目方没有说——为了拍这条视频，他们重试了多少遍。