自我介绍：

熟悉 Linux，平时进行html和android项目开发。

制作移动端 AI Agent 项目 Happy Phone Agent (HPA) 开发。

项目介绍：

PS:项目完全开源

Github：Github仓库​

Gitee：https://gitee.com/xkx1029/Phtomt

（不知道为什么Gitee的链接没识别上）

项目概述：

Happy Phone Agent（简称 HPA）是一个运行于 Android 平台的移动端 AI Agent。其依靠无障碍 / Shizuku 实现自然语言驱动 APP 自动操作，完成点餐、消息发送等跨应用复杂任务。项目采用意图‑执行分离架构，做了任务分层规划、动作验证防幻觉、端侧规则引擎、无障碍保活自愈、人机协作记忆系统等模块，解决页面环境变化、Agent 幻觉等痛点。

用户以自然语言下达指令，例如"帮我在美团点一份公司附近的黄焖鸡米饭"，HPA 即可接管设备屏幕，自动完成从启动应用、检索、筛选、下单到提交的完整操作链路。

HPA 的定位介于两类现有产品之间：一类是以语音助手为代表的对话型 AI，具备理解能力但无法执行实际操作；另一类是以脚本点击器为代表的确定性自动化工具，能够执行操作但缺乏对变化环境的适应能力。HPA 的目标是融合二者的优势——在具备自然语言理解能力的同时，提供可靠、可验证、可协作的自动化执行能力。

Happy Phone Agent 的目标是使移动端自动化成为一项可靠、可验证、可持续进化的能力，而非停留在演示层面的概念。它试图回答一个更基本的问题：当 AI 需要真正"动手"完成现实任务时，如何保证它做得对、做得稳、做得明白。

已实现意图转译架构、任务规模分层执行、脚本执行通道、长线任务分层规划与检查点续传、任务模板库、执行策略热切换、调试与反馈系统、无障碍服务保活。

核心能力：

跨应用多步骤操作。​ 支持点餐、消息发送、出行叫车、系统设置、文件整理等跨应用任务，单次指令可拆解为多个子任务并顺序执行。

透明可协作。​ 用户可实时查看 Agent 的决策依据与执行进度。指令存在歧义时，Agent 在规划前主动澄清；执行遇阻时，Agent 主动求助，用户可选择手动接管、提供指导或要求更换策略。

学习与个性化。​ 用户的纠正会写入异常经验记忆库，同类问题二次命中直接复用。用户偏好、常用地址、高频任务被持续学习，重复任务通过模板匹配实现零规划成本执行。

环境适应性。​ 针对倒计时广告、权限弹窗、页面加载延迟、应用崩溃、系统后台回收等真实场景，均设计了对应的检测与恢复机制。

技术架构：

1.意图与执行分离

架构的核心原则是决策层与执行层解耦。AI 仅输出结构化意图（如"点击搜索框""输入黄焖鸡米饭"），不输出可执行命令。端侧转译层根据当前授权模式——无障碍、Shizuku 或只读——将意图转译为对应命令。

该设计带来三方面收益：AI 的决策负担显著降低，出错面积缩小；授权模式的变化对决策层完全透明；同一意图可被多种执行通道复用，天然支持降级与跨设备回放。

2.任务规模分层

任务按步骤规模分为三档，分别采用不同的执行策略：

短任务（1~2 步）​：单次意图直接转译执行。

中等任务（3~8 步）​：采用脚本执行模式，规划阶段一次产出完整脚本，端侧自主推进，仅在页面偏离预期时回调云端，将云端调用次数从逐步决策的 6~8 次降至 1~3 次。

长线任务（9 步以上）​：采用分层规划，将任务切分为阶段，阶段内复用脚本执行，阶段间通过摘要压缩与工作记忆传递状态，配合检查点机制实现断点续传。

3.执行验证与防幻觉

针对 Agent "未执行却判定成功"的问题，架构将"动作已发送"与"动作已生效"严格分离。执行层返回值仅表示指令是否成功下发；动作是否真正生效由独立的验证层判断，依据页面指纹变化、关键文字出现、页面类型迁移三重信号交叉确认。只有经过验证的步骤才会在后续决策上下文中标记为已完成。

4.端侧决策引擎

弹窗、加载中、错误页、任务完成四类场景由端侧规则引擎本地处理，不消耗云端调用。该四类场景在真实任务中约占 40% 的步骤，本地处理将响应延迟从数百毫秒降至毫秒级。

5.模板库与执行策略热切换

用户仅需编写任务目标，AI 负责生成执行脚本，模板库负责持久化与复用。重复任务的匹配命中可实现零云端调用执行。

执行策略支持用户自主选择：脚本执行（快而省）与边执行边思考（慢而灵活）可随时切换，切换立即生效，正在执行的任务亦可在下一原子单元平滑交接。

6.可观测性

调试系统以"人话翻译 + 原始数据并存"为原则，将任务执行过程呈现为普通用户可读的叙事（看到什么、决定做什么、做了什么、结果如何），同时保留完整的技术原始数据供开发者定位问题。所有执行行为均有日志记录，支持诊断报告导出与脱敏。

技术细节

下面就是一些无聊的东西了（bushi

HPA 的技术路线可以概括为：让模型只做它擅长的事（理解语义、判断该做什么），把模型不擅长的事（通道选择、坐标计算、命令格式、执行验证）全部交给确定性的端侧逻辑；用页面指纹和验证层给 Agent 装上一套独立的"感官反馈"，用端侧决策引擎和脚本执行把成本压在最低，用检查点和幂等设计把长任务跑稳。​ 这套组合的目标不是做最炫的演示，而是把"AI 操作手机"变成一个在真实设备上可靠运行的系统。

1.感知层

感知层负责回答一个问题："屏幕现在是什么样？"它产出的不是原始截图，而是一份结构化的页面协议（Page Protocol），供决策层和验证层消费。

无障碍服务是感知的主通道。服务收到窗口变化事件后，端侧遍历当前窗口的控件树（AccessibilityNodeInfo），将其转换为统一的 JSON 结构。这个转换过程包含几个关键处理：深度截断（限制最大遍历深度为 18，防止极端页面导致解析耗时失控）、不可见节点过滤（isVisibleToUser 为 false 的非根节点直接跳过）、纯布局容器折叠（无交互能力、无文字、无有意义子节点的中间层不再展开）。最终每个控件节点保留 id、类型、文字、比例坐标边界（bounds 归一化为 0~1 的浮点数）、可点击性、可滚动性、可编辑性等字段。

解析完成后，端侧标注器（PageAnnotator）会对页面做一次轻量的语义推断：根据控件文字与结构判断页面类型（搜索页、搜索结果列表、商品详情、结算页、弹窗覆盖层等），并为每个控件标注优先级，将高优先级控件（可点击且带文字）排在协议前端。这个标注的意义在于缩小决策模型的搜索空间——模型不需要在一整棵控件树里找目标，而是优先看排在前面的控件。

页面指纹（Page Fingerprint）在解析时同步生成，它是对当前页面可交互控件关键特征（id、类型、文字、边界）做哈希得到的字符串。指纹有两个用途：其一，作为"页面是否变化"的快速判断依据；其二，作为动作指令的回传校验字段。决策时记录的指纹会随动作指令下发，端侧在执行前重新读屏计算指纹，若不一致则说明页面在决策到执行的数百毫秒内发生了变化，旧指令作废、重新决策。这是解决倒计时广告等时序竞态问题的通用机制。

当无障碍不可用时，感知层降级为截图路径：通过 MediaProjection 截取屏幕，压缩为 1080px 宽、JPEG 75% 的图片，直接发送给云端多模态模型。此路径下不再有控件树，端侧依赖模型从图像中直接理解页面并返回结构化的动作目标。

2.意图转译架构

这是 HPA 架构最核心的设计决策。AI 模型只输出"意图"（intent），不输出可执行命令。意图是声明式的：{"intent":"tap","target":{"by":"hint","value":"第一个店铺卡片"}}。至于这个点击最终通过 input tap 540 820 还是 performAction(ACTION_CLICK) 完成，AI 完全不知道，也不该知道。

这样设计基于一个朴素的观察：模型的强项是理解页面语义、判断"该做什么"，弱项是精确理解技术通道差异、坐标换算、命令格式。让模型同时承担两件事，等于把最不稳定的部分放进了决策链路。

意图共有九种：open_app、tap、input、swipe、press、wait、scroll_to、finish、give_up。目标定位（target）支持三种方式：by_id（精确控件 id）、by_text（控件文字匹配）、by_hint（语义描述，交由视觉定位）。模型永不输出坐标——坐标由端侧定位到目标后自行计算。

端侧转译层（IntentTranslator）读取当前授权模式，将意图转译为对应通道的命令。授权模式有三种：Shizuku（input tap/swipe/keyevent 等 ADB 级命令）、无障碍（performAction、dispatchGesture、performGlobalAction）、只读（无法执行，仅提示用户手动操作）。转译矩阵是端侧维护的确定性映射，不经过模型。授权模式变化对决策层完全透明，用户开关 Shizuku 不需要模型配合任何调整。

目标定位采用三级降级策略：优先按 id 在控件树中精确查找；找不到则按文字匹配；再找不到则调用视觉定位接口（截图 + 目标描述，由云端视觉能力返回坐标）。这种降级保证在控件树信息不完整或 id 缺失的 App 中，操作仍能继续。

3.执行验证

早期版本最严重的问题是行为幻觉——执行层返回 true（系统确认指令已下发），Agent 就据此认定操作成功并进入下一步，而实际上目标 App 可能完全没响应。HPA 的解决方式是把执行和验证彻底拆成两个模块。

执行层的返回值只表达一个事实："指令是否成功发送给系统。"验证层（RobustStepVerifier）独立判断"动作是否在 App 内生效"，依据三类信号：页面指纹是否变化、预期文字是否出现、页面类型是否迁移。

验证采用三重门策略：执行后分别在 300ms、600ms、900ms 三个时间点读屏判断，取多数结果。因为单次读屏可能恰好撞上页面过渡态。同时，指纹变化不等于操作生效——状态栏时间刷新、通知弹出都会改变指纹，因此引入"有意义变化"检测：只有当可交互控件数量变化超过阈值，或控件文字发生非纯数字的实质变化时，才认定页面真正发生了变化。

只有通过验证的步骤，才会在后续决策上下文中标记为"已确认成功"。决策模型看到的执行状态严格区分三种："✅ 已确认成功"（页面确实变了，可信任）、"⚠️ 已发送但未确认"（指令已下发但页面未明确响应，不可假设成功）、"❌ 未生效"（确定失败，必须换策略）。这从数据层面杜绝了模型基于错误前提继续推理的可能。

4.端侧决策引擎

真实任务中，约 40% 的步骤是"弱智决策"——弹窗关闭、页面加载等待、网络错误重试、任务完成判定。这些场景用关键词规则即可达到接近 100% 的准确率，调用云端反而又慢又贵，还可能引入误判。

端侧决策引擎做五分类：弹窗（检测到"允许/拒绝/关闭/我知道了"等关键词组合）、加载中（检测到加载文字或控件数量过少）、异常页（检测到"网络异常/加载失败"等）、任务完成（检测到"提交成功/支付成功"等终结性文字）、正常页面（以上皆非）。前四类由本地规则直接产出动作，不消耗任何云端调用；只有正常页面才进入云端决策。

引擎内置防死循环机制：连续 5 次本地决策仍未推进，强制上报云端。这是对规则引擎局限性的自我保护——规则覆盖不了的场景，不能让它无限原地打转。

5.脚本执行

3~8 步的中等任务占日常指令的 70% 以上，是成本优化的主战场。逐步决策模式下，一个 5 步任务需要 6~8 次云端调用。HPA 改为脚本执行模式：规划阶段一次产出完整脚本，端侧自主推进，只在页面真正偏离预期时才回调云端。

脚本的每一步包含三要素：预期页面（执行前确认"我是否在这一步该在的页面上"）、意图（做什么）、验证点（执行后确认"做成了没有"）。预期页面匹配是端侧自主执行的基石——每一步执行前先验证页面状态，匹配则放心执行，不匹配则先让端侧决策引擎处理意外（可能是弹窗或加载挡着），处理完仍不匹配才回调云端。

偏差回调有严格限制：每个脚本最多 2 次。超过 2 次说明该任务不适合脚本化，自动降级为逐步决策模式。这个上限防止了"脚本和现实持续冲突但反复回调"的无效循环。

6.长线任务的持久化与续传

9 步以上的任务，执行时间可能长达几十分钟，中断（来电、锁屏、网络断开、进程被杀）是必然事件而非偶发。HPA 的处理分三个层面：

分层规划把任务切分为 3~8 个阶段，每个阶段对应一个 App 内的一组连续操作。任何时刻，决策模型只需要理解"当前阶段 + 工作记忆摘要"，不需要记住整个任务。阶段完成后，用一次轻量云端调用把阶段历史压缩成摘要（产出物、关键数据、注意事项）写入工作记忆，供后续阶段引用。

检查点机制负责断点续传。阶段完成时、执行中每 2 分钟、收到中断信号时、进程 onDestroy 时，都把任务状态持久化到 Room 数据库。恢复时对比检查点记录的页面与实际读屏页面，一致则直接续传，不一致则调用接管恢复引擎重新定位到正确阶段。

幂等保护针对进程被杀前"执行了但没记录"的步骤。发送、提交、下载、删除这类有副作用的意图，在执行前先检查"是否已经完成"（例如页面是否已出现"发送成功"），避免重复执行造成坏结果。普通的 tap、swipe 天然幂等，不需要额外处理。

7.数据协议

系统内流转的核心数据结构是页面协议和意图，两者都采用 JSON 序列化，云端与端侧共享同一份 Schema。

页面协议上行时包含：页面元信息（page_id、指纹、来源通道、页面类型、语义提示）、控件列表（按优先级排序，最多 15 个关键控件，其余折叠计数）、增量模式标记。页面变化小于 50% 且未跳转时采用 diff 模式，只传新增、删除、变更的控件，显著降低 token 消耗。

意图下行时是单一动作对象，或满足合并条件时的两元素数组（例如"输入文字 + 点击搜索"）。合并有严格边界：第一个动作会导致页面跳转、第一个动作是滑动、或来源是截图路径时，禁止合并。

云端调用参数按场景分化：决策与验证用 temperature 0.1（确定性优先），规划与恢复用 0.3，异常重规划用 0.5（鼓励真正换思路）。所有调用开启 JSON Mode，配合三步兜底解析（直接解析、正则提取代码块、正则匹配首对象、失败构造 abort），保证极端情况下系统也不会被非法响应卡死。

8.安全边界

敏感页面检测器识别银行类 App 与支付密码输入场景，命中后进入只读模式，拒绝执行一切动作。涉及支付、删除、发送消息等不可逆操作时，意图携带确认标记，端侧执行前弹窗征得用户确认。所有上行数据在序列化前完成敏感信息脱敏（手机号、身份证号、银行卡号正则掩码）。全部用户画像与异常记忆数据仅存端侧，截图上传默认关闭、需显式授权。

最后，做了HPA这个项目几个月了，我想谈谈对AI的看法

“AI 能做很多事，但一个真正可靠、能被用户长期使用的 AI 产品，靠的是把 AI 放进一套严密的工程框架里——让它干它擅长的，替它挡住它不擅长的，并且让每一个动作都有迹可循、有据可查。”

AI 是一种能力，不是一种人格。​ 这是我最想说的第一点。很多人讨论 AI 的时候，喜欢问"它会不会有意识""它是不是在骗我"——把 AI 当成一个有主观意图的对象。但当你真正把一个模型放进系统里、每天看它成千上万次地做决策，你会发现它既没有那么神秘，也没有那么危险。

AI 的可靠，从来不是模型自己带来的，是工程带来的。​ 这是做 HPA 最大的教训。单看模型，它什么都能说、什么都敢说，但它的错误率在一个真实产品里是不可接受的——用户点一次餐，你不能让它有 5% 的概率点错。所以我的精力没有花在"让模型更聪明"上，而是花在"让模型错了也不会造成灾难"上。

AI 最合适的角色，是放大人的意图，而不是替人做决定。​ HPA 里有一个设计我特别坚持：当指令有歧义时，AI 必须先问清楚再动手，而不是自己猜。

我不担心 AI 取代人，我担心人放弃思考。​ 这是我对 AI 未来唯一真实的忧虑。技术上，我不认为 AI 短期内会取代人，一个只会在语料里找规律的模型还差得很远。我真正担心的是另一个方向：当 AI 越来越擅长给出答案，人们会不会越来越懒得问问题？会不会把"AI 说的"当成"正确的"，放弃自己核实、自己判断？这最近在小破站上看到了一张特别离谱的图片：

非常明显的AI图吧，但是真的有人相信高通一年投入7830人民币研发芯片，我一直觉得用AI不可怕，可怕的是无条件的相信AI。

所以综上所述，我对AI的看法就是

“尊重它的能力，警惕它的局限，把决定权留给人。”

非常感谢你能看到这

希望能加入AI开发者小站，和各位大佬交流学习、互相探讨踩坑经验，后续也会持续输出真实、原创的项目实战内容，认真交流、积极分享，绝不水帖。