AI Agent 操作确认界面设计：建议、置信度、理由与手机恢复流程

先找准手机状态即将改变的决定时刻

AI Agent 操作确认界面的首要任务，不是让每一步都多一个“确定”按钮，而是准确找出用户必须作决定的时刻。读取当前页面、整理候选项、生成草稿和解释设置通常不会立即改变外部状态；发送消息、删除文件、公开发布、修改账号、创建日历事项或改变系统设置，则会产生真实结果。确认应出现在动作准备完成、目标已经明确、但变化尚未发生的位置。

以语音回复消息为例，用户说“告诉陈晨我晚十分钟到”。手机智能体可以先识别联系人、生成内容并打开草稿预览。此时界面应显示发送账号、收件人、应用、正文以及是否包含附件。用户看到的是一份即将执行的完整提案，而不是一句含糊的“是否继续”。点击发送后，界面还要返回实际结果，让用户知道消息已经发出、仍在处理中，还是因网络或权限问题未完成。

决定时刻还取决于影响范围。同样是修改文本，在本地草稿里替换一个词与编辑已经公开的帖子并不相同；同样是定位操作，查看当前位置与向他人共享实时位置也不相同。确认界面需要根据动作后果调整信息密度和操作方式：影响较小且容易撤回的动作可以保持简洁，涉及外部对象或难以恢复的动作则要展示更多细节。

我们的设计原则是先让任务进入可检查状态，再把最终决定交给用户。FoneClaw 当前能力将运行中的任务与等待用户决定的任务分开显示，使“正在处理”和“需要你确认”不再混在一起。用户可以继续处理其他对话，同时清楚看到哪个任务已经准备好、在等待什么，以及确认后会发生什么。

需要进一步理解身份、权限和操作记录如何共同发挥作用，可以阅读AI 智能体身份、权限与审计日志：逐工具审批控制怎么落到手机 Agent。确认界面负责呈现当前决定，账号授权、Android 权限、工具规则和操作记录则共同构成完整控制链。

把建议、预览和直接执行分成不同状态

手机界面至少要区分三种动作状态。第一种是建议：智能体发现一个可能有用的下一步，但尚未准备执行。第二种是预览：目标、内容和参数已经齐全，只等用户接受、修改或拒绝。第三种是直接执行：动作符合当前设置和支持范围，可以立即完成，并在事后显示结果。三种状态对应不同含义，不能只靠按钮颜色区分。

建议状态适合信息仍需判断的情况。例如，智能体从邮件中识别到一个日期，可以提示“建议创建日历事项”，同时展示邮件来源和提取出的时间。用户可以打开详情、补充时区或直接忽略。此时按钮应使用“查看建议”“补充信息”等具体文字，避免让用户误以为点击后马上创建事件。

预览状态应把将要改变的内容集中展示。准备发送消息时，预览包含收件人、正文和发送渠道；准备修改设置时，显示当前值、目标值和可能影响；准备移动文件时，展示源位置、目标文件夹和重名处理方式。用户可以选择“确认执行”“修改”或“取消”，而不是退出弹窗后再到另一个页面寻找编辑入口。

直接执行适合后果较轻、目标明确、结果容易检查，并且符合用户当前选择的动作。例如刷新设备状态、打开受支持的应用或保存一份未发送草稿。即使不需要事前确认，完成后也应出现简短反馈，说明执行了什么以及结果落在哪里。若动作失败，状态应从“执行中”转为明确的失败原因，而不是停留在加载动画。

GitHub 在 2026 年 7 月 23 日推出的一项公开预览提供了有价值的交互参考。根据GitHub Issues 智能体自动化控制更新，受支持的问题变更可以先作为建议等待检查，也可以按当前设置直接应用。该机制覆盖标签、字段、问题类型、关闭状态和负责人等 GitHub Issues 操作。它展示的是代码协作场景中的设计模式，而手机确认界面需要根据 Android 任务重新确定对象、权限和恢复方式。

用置信度安排检查，而不是宣称确定无误

置信度最适合解决“用户应该先检查什么”，而不是回答“智能体一定正确吗”。模型可以根据上下文完整度、目标匹配程度和工具返回结果，给出高、中、低等级；界面再据此决定是直接展示结果、进入简短确认，还是停下来补问。这个数字或等级是一种分流信号，不是事实证明。

高置信度也可能建立在错误信息上。联系人名称看似唯一，但用户可能想找另一个同名对象；日历时间格式清楚，却可能缺少时区；页面上的“删除”按钮已经识别正确，但目标文件可能选错。因此，影响较大的动作不能只依据模型自评决定是否执行，还要结合目标是否唯一、数据是否来自可信上下文、动作是否容易撤回以及当前权限范围。

GitHub 的公开预览采用了明确的分流方式：高置信度的受支持问题操作可以自动应用，中等和较低置信度的操作作为建议等待检查。这个模式的启发在于把有限注意力留给更可能需要判断的项目。应用到手机时，还要增加后果维度。即使模型对收件人和内容都很有把握，发送到外部对象仍可能需要用户看一眼；相反，低风险的本地整理动作可以在完成后提供结果反馈。

置信度也不必总以百分比呈现。手机屏幕空间有限，“目标明确”“需要核对时间”“发现两个同名联系人”往往比“置信度 72%”更有帮助。内部评分可以负责排序，面向用户的界面则应说明具体不确定点，让人知道该检查哪一项。

确认前说明理由、目标、后果和依据

好的确认卡片应该在几秒内回答四个问题：为什么建议这样做，动作会落到哪里，完成后会改变什么，判断依据来自哪里。理由不需要展示模型的长篇推理过程，更不能用一段看似专业的文字掩盖目标不清。最有用的是简短、可核对的事实。

例如，智能体建议把手机切换到勿扰模式时，可以写成：“日历显示你将在十分钟后进入一小时会议；开启勿扰后，来电和通知将按当前例外规则处理。”用户随后看到当前模式、计划持续时间和允许的联系人。这里既说明了建议来源，也说明了系统变化和可能影响。

消息确认可以使用另一种结构：“根据当前对话中的到达时间，准备回复给王琳：‘我预计 18:20 到。’”界面应同时展示联系人头像或账号标识、目标应用和完整正文。若理由引用了通知、邮件或日历，用户可以展开查看对应内容，但主卡片不必塞入所有上下文。

GitHub 的公开预览会为受支持的问题操作记录理由，无论变更自动应用还是等待检查，用户都能看到改了什么以及为什么。对手机任务而言，简洁理由同样有助于检查和事后回顾。不过，确认记录本身负责提高透明度；真正限制动作范围的仍是 Android 权限、账号授权、应用能力和 FoneClaw 的工具控制。

为了避免确认疲劳，理由应直接描述当前动作，少用“为了提升效率”“根据你的偏好”等泛化表达。若系统无法给出具体依据，就应把状态降为建议或补问。例如，与其说“建议删除这些文件以优化空间”，不如列出文件类型、占用容量、最近使用时间以及删除后的恢复方式。

想进一步区分隔离环境与手机真实权限，可以阅读AI Agent 沙盒与手机权限：安全 Agent 为什么仍然需要边界。确认卡片帮助用户作决定，但任务能接触哪些数据、应用和系统功能，仍由实际授权范围决定。

让确认始终绑定正确的任务和会话

手机智能体可能同时处理多个请求：一个对话正在整理邮件，另一个任务等待创建日历事项，第三个任务正在检查设备状态。此时最危险的界面问题不是按钮不够醒目，而是用户无法判断某个确认属于哪项任务。确认必须绑定发起它的会话、目标对象和当前任务状态。

截至目前的最新信息，FoneClaw 加入了更清楚的独立运行与等待状态，并强化会话内确认和任务隔离。用户在“周五会议安排”会话中作出的确认，只作用于该会话准备的日历动作；另一段消息对话不会继承这次决定。这样可以避免跨任务复用目标、参数或确认结果。

等待列表应提供足够的识别信息。每个项目至少显示任务名称、发起时间、目标应用、等待原因和下一步。例如，“客户回复：等待确认发送”“工作日历：等待选择时区”“存储清理：等待选择文件”。用户点击后进入原任务上下文，而不是在缺少背景的全局弹窗中盲目选择。

确认还需要有效期。联系人、页面内容、网络状态或账号会话可能在等待期间发生变化。用户稍后返回时，系统应重新核对关键目标；若原页面已经关闭或数据已更新，就刷新预览并说明变化。对于已经过期的提案，可以保留为历史记录，但不应继续显示为可直接执行的当前动作。

批量处理时，同样要保持任务关联。用户可以一次接受多个低风险建议，但界面应列出每项内容，并允许排除其中一项。发送、删除或账号变更等动作适合逐项核对，避免一个“全部同意”按钮把不同后果合并。批量入口节省的是浏览时间，不应隐藏每个动作的目标。

当多个手机工作流同时运行时，一个统一入口可以帮助用户查看进度、等待项和失败任务。关于这种集中管理方式，可以继续阅读手机 Agent 控制中心：当 AI 智能体开始进入手机工作流。

消息、设置、文件和导航需要不同确认方式

确认界面不能只做成一套通用弹窗。手机动作的对象、后果和恢复方式差异很大，界面需要使用与任务相符的信息结构。用户不应在发送消息时只看到工具名称，也不应在修改系统设置时阅读一整段聊天记录。

消息与公开发布

消息卡片应突出收件人、账号、目标应用、完整正文和附件。回复全部、群聊或公开发布需要额外标出受众范围。用户修改文本后，确认状态应基于新内容重新生成，避免旧确认继续作用于已经改变的草稿。执行后返回发送状态和可打开的目标会话。

系统设置

设置变更适合显示“当前值”和“目标值”。例如开启蓝牙、调整音量或进入勿扰模式时，用户要看到变化内容、持续时间以及可能影响。对于需要 Android 系统授权的步骤，FoneClaw 会引导用户进入相应权限页面，并在返回后继续核对任务状态。

文件与内容删除

文件操作需要显示名称、位置、数量、大小和目标文件夹。覆盖同名文件、清空回收站或永久删除时，应明确恢复条件。若系统只完成了部分操作，结果页要列出成功和失败项目，不能用“清理完成”概括混合结果。

导航与位置

打开路线通常可以通过目的地预览完成；共享位置则要显示接收对象、共享精度和持续时间。目的地名称重合时，界面应提供地址候选。用户确认后，还要说明是仅打开导航、开始路线，还是已经把位置发送给他人。

日历与任务

创建事项应展示标题、日期、时区、日历、参与者、地点和提醒。相对日期需要转换成明确日期后再确认。若检测到重复事件，可以让用户选择更新现有项目或另建事项，而不是自动生成两份相同安排。

这些模式共同遵循一条原则：确认卡片展示的是用户要决定的真实对象，而不是内部工具调用。FoneClaw 将自然语言请求连接到受支持的 Android 动作，并把权限要求、等待状态和结果放到用户能够理解的位置。

为拒绝、修改、撤销和接管准备恢复路径

确认界面不应只有“同意”和关闭按钮。用户可能认可目标但想修改内容，也可能暂时没有时间处理，或者发现任务来源已经过期。完整的选择通常包括确认、修改、拒绝、稍后处理和手动接管；是否提供撤销，则取决于动作本身以及目标应用的恢复能力。

拒绝后，任务应结束在清楚状态，而不是不断重新弹出同一建议。用户可以选择填写简短原因，例如“联系人不对”“时间不对”“不需要执行”，帮助当前任务调整后续提案。如果只是暂缓处理，系统应把项目留在等待列表，并显示更新时间和重新检查入口。

修改路径要尽量保留已经确认的部分。日历事项只有时间错误时，用户可以改时间而不必重新输入标题和地点；消息正文需要润色时，收件人选择仍可保留。修改后，界面重新展示完整提案，尤其是任何会产生外部影响的动作都要以最新内容为准。

权限不足时，FoneClaw 会说明当前任务需要哪项 Android 权限，并引导用户完成系统授权。用户返回后，任务从原会话的可恢复位置继续。若权限被拒绝，可以选择不需要该权限的路径或结束任务。确认与权限是两个不同步骤：用户同意任务目标，不代表 Android 已经授予相应访问能力。

FoneClaw 当前能力还改进了主屏执行恢复。当任务因应用切换、授权页面或意外返回主屏而中断时，系统可以帮助重新定位当前步骤。恢复后会重新检查目标页面和关键参数；已经失效的发送、删除或修改提案需要再次展示，避免沿用中断前的旧状态。

撤销能力应如实反映目标系统。草稿可以删除，部分设置可以恢复原值，某些文件可以从回收站找回；已经发出的消息、公开发布或永久删除则可能没有等价撤销。界面应在执行前说明恢复可能性，并在完成后提供当前可用的补救操作。

1. 先确认当前任务、会话和目标对象是否正确。
2. 检查动作是建议、预览、等待确认还是已经执行。
3. 阅读简短理由，并核对依据是否与当前内容一致。
4. 查看动作后果、权限要求和恢复可能性。
5. 需要调整时先修改提案，再基于最新内容确认。
6. 执行后检查真实结果；失败时按权限恢复、页面恢复或触控接管路径继续。

真正有效的 AI Agent 操作确认界面，不以弹窗数量衡量安全感，而是让用户在正确时刻看到正确对象，理解为什么要做、做完会怎样，并随时拥有修改、停止和接管的明确入口。