可自我改进的手机龙虾：技能版本、回归测试与回滚

自我改进手机龙虾究竟改进什么

自我改进手机龙虾，是能够根据真实执行结果和失败记录，持续优化任务规划、运行框架与可复用技能的 Android 手机 Agent。关键不在于让系统随意改变自己，而在于把每次改进变成有证据、有测试、有版本、可审批且可回退的工程过程。

理解这一能力，需要把四个对象分开。第一是用户配置的模型，负责理解请求、分析上下文和制定计划；第二是智能体运行框架，包括提示规则、工具、任务编排、验证条件与失败恢复程序；第三是可复用技能，用来描述某类手机任务的步骤、参数和适用条件；第四是 Android 动作执行，由 FoneClaw 在已有权限和支持范围内完成，并向用户呈现过程与结果。

因此，自我改进并不等同于重新训练模型。FoneClaw 可以发现“等待时间判断不准”“应用页面变化后找不到目标”“任务完成后缺少结果验证”等问题，然后调整计划规则、技能步骤或恢复策略。已配置模型的权重保持不变，改进集中发生在可测试、可追踪的 Agent 工作层。

技能最初可以来自人工设计、成功任务归纳或演示流程，但“学会一次”和“长期可靠”是两个阶段。关于演示如何转为可复用流程，可继续阅读演示一次，教会手机 Agent：录屏、可复用技能与 Android 安全；若要理解训练环境与部署后改进的区别，可参考PhoneBuddy-4B 与手机 Agent 训练：为什么 Mock-App RL 对 Android Agent 很重要。

从执行记录到验证：Self-Harness 带来的研究信号

Self-Harness 研究论文给出了一条清晰的三阶段路径：先从执行记录中挖掘弱点，再提出范围受限的运行框架修改，最后验证提案，只有通过验证的变化才被接受。这里的运行框架范围很广，既包括提示和工具，也包括运行机制、验证规则、编排逻辑以及失败后的恢复程序。

论文作者在 Terminal-Bench-2.0 上报告，三个固定基础模型在修改运行框架后，留出任务通过率得到提高。这个结果的意义并不是证明某套框架适用于所有手机任务，而是说明模型权重不变时，工具使用方式、验证流程和恢复逻辑仍可能显著影响 Agent 表现。对手机端而言，页面识别、等待条件、动作顺序和结果检查都属于可以独立改进的对象。

研究循环可以直接映射到 Android 工作流。一次任务失败后，系统先判断问题来自计划、界面状态、权限、网络、动作执行还是结果验证；随后只修改最小必要部分；再用成功案例、已知失败案例和边界场景共同测试。这样，改进目标是消除已经证实的问题，同时保持原有可靠行为。

Salesforce 关于自我改进智能体的讨论也把注意力引向持续学习与实际运行反馈。对于手机 Agent，真正可落地的方向不是无限制自我修改，而是把反馈转化为可审查的变更单元，并让每个单元都能说明来源、影响范围和退出方式。

这套方法还必须考虑反例。Phantom Guardrails 研究展示了一种风险：优化器可能臆造并不存在的失败，再添加多余限制。如果验收标准只看某个错误是否被压制，就可能接受一个降低整体能力的修复。因此，问题复现、对照测试和无回归验证必须同时存在。

FoneClaw 如何形成受治理的自我改进能力

FoneClaw 是一个自我改进手机 Agent。它可以利用执行结果和失败记录，改进规划方式、运行框架行为以及可复用手机技能，同时保留测试、审批、权限检查、版本记录、分阶段发布和回滚机制。

在 FoneClaw 的工作流中，用户配置的模型负责理解自然语言、识别目标、处理歧义并生成计划；FoneClaw 负责把计划落实为受支持的 Android 手机动作。执行过程中，用户可以看到关键状态和最终结果；涉及权限或重要操作时，流程进入相应的授权与确认步骤；当前路径无法继续时，则提供可理解的失败原因和实用替代方案。

自我改进通常从结构化证据开始，而不是简单记住用户最后做了什么。一次失败记录需要包含当时的应用状态、计划步骤、实际动作、等待时间、权限状态、观察到的结果以及恢复尝试。系统据此判断应修改的是任务分解、元素定位规则、超时策略、验证条件，还是技能的适用范围。

例如，一个创建日历提醒的技能在某个界面版本中完成了输入，却没有确认保存结果。合理的改进可以是增加“检查事件是否出现在目标日期”的验证步骤，而不是扩大应用权限，也不是把所有失败都归因于模型。改进后的技能继续沿用原有权限要求和确认点，并获得新的版本号。

这种架构让模型选择与 Android 动作能力保持清晰。更换已配置模型可能改变理解、计划或语言处理表现；FoneClaw 的动作支持、权限流程、确认机制和结果可见性则由手机 Agent 的执行体系管理。两者在同一 Agent 工作流中承担不同职责。

一项改进从证据到上线要经过哪些关卡

手机 Agent 的变更会接触真实应用、账户状态和用户数据，因此一项候选改进需要走完完整生命周期。核心原则是：先证明问题，再提出最小修改；先验证权限和回归影响，再决定发布范围。

回归测试不能只重复导致修改的单一任务。它还应覆盖不同屏幕尺寸、系统语言、应用版本、网络速度、账户状态、权限拒绝、任务中断和部分完成等情况。重要操作需要验证确认步骤仍在正确位置，普通操作则要检查是否因新增限制而变得迟缓或无法完成。

权限差异检查尤其重要。技能增加一个步骤，可能同时扩大可访问的应用、数据类别或操作范围。版本审批应把这些变化直接展示出来，使审核者能够判断收益是否值得新增能力。有关运行隔离与系统权限如何共同发挥作用，可参阅AI Agent 沙盒与手机权限：安全 Agent 为什么仍然需要边界。

发布后，旧版本仍应保持可恢复状态。监测可以关注成功率、确认取消率、恢复次数、异常耗时和结果验证失败等信号。一旦新版本超出预设阈值，系统即可暂停该版本，把任务恢复到上一稳定技能，并保留现场证据供下一轮分析。

看似有效的修复为什么会制造新问题

最危险的改进未必会立刻报错。有些变更能修复一个案例，却在其他设备、语言或应用状态下悄悄降低成功率。治理的价值，就是在这类问题进入大范围真实任务前发现它们。

第一类风险是虚构故障。某段记录可能只是网络短暂波动，优化器却将其解释成永久缺陷，并加入不必要的等待或阻断规则。处理方式是要求失败可复现，并设置未修改版本作为对照。没有稳定证据的问题只能进入观察队列，而不能直接生成生产变更。

第二类是过度拟合。为某个按钮文字或固定坐标编写的修复，可能在深色模式、简体中文之外的系统语言、横屏布局或应用更新后失效。更稳健的技能会组合语义、界面结构、当前页面状态和结果验证，同时为找不到目标的情况准备停止或替代路径。

第三类是权限漂移。某项改进为了提高成功率，可能尝试增加应用访问范围或减少确认环节。FoneClaw 的治理流程把权限与确认视为独立验收项：技能版本可以改进步骤，但权限扩展需要清晰差异、明确目的和相应审批。更深入的技能风险分析可参考AI Agent 技能安全：为什么手机 Agent 不能只靠安装前扫描。

第四类是基准停滞。即使原有测试分数没有下降，也不能说明真实体验没有回归。测试集可能缺少新应用版本、低速网络、通知遮挡、登录过期或辅助功能设置等状态。手机 Agent 的回归套件需要随真实失败类型扩展，同时保留历史任务，避免只追逐最近一次问题。

还有一种常见误判，是把“任务没有报错”当作“任务已经完成”。可靠验证需要检查最终结果，例如提醒是否真的创建、文件是否保存到目标位置、消息是否仍停留在草稿状态。部分完成必须作为独立状态呈现，不能被统计为完整成功。

判断手机 Agent 改进能否投入真实使用

评估一个自我改进手机 Agent，不应只问它能否自动提出修改，还要检查修改是否受控。下面这份清单适合用于技能评审、版本发布和真实 Android 任务验收。

• 问题有证据：候选修改对应可复现的失败、明确的性能瓶颈或可验证的结果缺口。
• 修改范围最小：提案说明具体改变了哪条规划规则、技能步骤、工具参数或恢复条件。
• 模型与运行框架分离：能够明确说明这是技能或运行机制改进，而不是把模型权重变化混入版本记录。
• 测试覆盖正反案例：既验证原问题已解决，也确认既有成功任务、边界状态和停止流程没有回归。
• 权限差异可见：应用范围、数据范围、系统能力和用户确认点均有前后对照。
• 结果能够核验：测试检查真实任务结果，而不只检查点击步骤是否执行。
• 版本可以定位：每次技能更新都有唯一版本、变更说明、测试结果、审批记录和适用条件。
• 上线范围受控：新版本先进入有限任务或设备范围，并依据真实表现逐步扩大。
• 异常可以停止：用户和系统都拥有明确的暂停、取消与恢复路径。
• 旧版本能够恢复：回滚目标、触发条件和数据兼容方式在发布前已经验证。

审计记录还要回答谁提出了修改、依据哪些执行证据、谁批准上线、哪个版本执行了具体任务，以及何时发生回滚。这些信息把一次自动优化转化为可解释的产品行为。关于身份、权限和执行记录之间的关系，可继续阅读AI Agent 身份、权限与审计轨迹：手机智能体真正需要的安全栈。

对 FoneClaw 来说，自我改进的目标是让受支持的 Android 工作流随着真实使用变得更准确、更稳定、更容易恢复。配置模型继续负责理解与规划，FoneClaw 通过受治理的运行框架和技能版本完成手机动作，并在每次变化中保留可见结果、权限流程、用户确认和实用回退方案。