AI 智能体身份、权限与审计日志：逐工具审批控制怎么落到手机 Agent

工具调用之前，先确认 AI 智能体身份

从一个具体手机任务开始看：用户说“把这条会议通知整理成提醒，并给同事准备一条回复”。这里至少有五个身份需要分清：发起请求的用户、正在执行计划的 AI 智能体、本次会话、目标应用里的账号，以及将要收到消息或日程变化的目标对象。AI 智能体身份不是抽象标签，而是每个动作归属到谁、为了哪个任务、在什么会话里发生的依据。

登录成功只说明“这个用户可以进入系统”，不说明智能体可以代表用户做哪些事。真正的代办身份还要包含委托范围：能读取什么、能准备什么、能发送什么、何时停下来等用户确认。NVIDIA 关于企业 AI 工厂中自主智能体治理的文章强调，自治智能体需要身份、签名策略、人类复核、集中日志、撤销和持续验证等治理层。这些概念放到手机上，会变成更日常的问题：这次是用户点了按钮，还是 Agent 代用户调用了工具？

身份还必须跨重试和交接保持清楚。一次工具调用失败后，Agent 可能重试、换一个受支持路径、请求补充权限，或者把任务交回用户。审计日志不能只写“任务失败”，而要保留每一步是谁发起、为什么失败、是否改变了目标。这样用户才能判断下一步是继续、撤销还是改为手动操作。

把身份变成可收紧、可撤销的权限

AI 智能体权限不应该是一个总开关。更稳的结构是六层：身份确认、策略约束、工具启用、Android 系统权限、目标校验和动作审批。身份回答“谁在代办”；策略回答“这种任务允许进入哪些工具”；工具启用回答“本地运行时是否开放这个能力”；Android 权限回答“系统是否允许访问某类手机资源”；目标校验回答“对象和内容是否清楚”；动作审批回答“这次后果是否可以发生”。

NVIDIA 关于更安全部署 AI 智能体的文章把常见失败归纳到访问控制、任意代码执行、网络出口和明文密钥等方向，并建议把确定性控制放在模型平面之外，采用最小权限工具、验证包来源和默认拒绝的网络出口。对手机 Agent 来说，这个原则可以转成一句更直接的话：模型可以提出计划，但权限执行必须由工具策略和设备控制承接。

Android 权限只是其中一层。用户允许某个应用读取位置，并不等于批准把当前位置发给某个联系人；允许通知访问，也不等于批准读取所有通知并长期保存；允许打开日历，也不等于批准修改共享日程。关于沙盒和手机权限为什么不能混为一谈，可以阅读 AI Agent 沙盒与手机权限：安全 Agent 为什么仍然需要边界，那篇文章专门处理环境隔离和设备权限的区别。

权限还要有时间、目标和后果限制。一次“整理当前通知”的任务不应扩大成永久读取所有通知；一次“生成回复草稿”不应自动升级为发送；一次“打开设置页面”不应自动修改系统选项。可收紧、可撤销，才是手机智能体权限真正可用的形态。

逐工具调用时要决定什么、记录什么

工具调用边界是治理最容易落地的位置。每当模型计划调用工具，运行时都应做出几类决定：这个工具是否启用，当前会话是否允许使用，输入是否符合 schema，目标对象是否明确，风险标签要求自动、按策略还是显式审批，执行结果是否与计划一致。逐工具审批控制的价值，就是把“模型想做”转成“系统按规则决定能不能做”。

智能体审计日志也应该围绕这个边界记录，而不是只写自然语言总结。一个低风险读取动作可以记录：任务名、会话、选中工具、输入摘要、策略结果、读取范围、实际返回状态。一个有外部影响的写入动作则应增加：目标对象、待提交内容、审批状态、用户确认时间、最终结果、失败原因或取消原因。计划动作和观察到的结果要分开，避免把“准备发送”误记成“已经发送”。

记录拒绝和失败同样重要。用户拒绝一次审批、Android 权限被拒、工具被禁用、目标联系人不明确、第三方页面变化导致失败，这些都能帮助用户理解系统为什么停下来，也能帮助产品改进恢复路径。技能层面的风险不只发生在安装时，运行中的工具选择、参数、目标和结果也要被看见。更完整的技能安全检查可以看 AI Agent 技能安全：为什么手机 Agent 不能只靠安装前扫描。

企业沙盒控制和 Android 手机控制不是同一层

企业智能体治理常讨论托管执行环境、沙盒、网络出口、凭据库、集中日志和策略签名。手机 Agent 则更多面对 Android 权限、应用状态、通知、位置、联系人、系统设置、屏幕可见性和用户确认。两者共享最小权限、可审计、可撤销的原则，但控制面不同。

NVIDIA 的企业治理参考设计把呈现层和受管理执行环境分开，并强调访问控制、沙盒、网络出口限制和密钥管理。这些做法适合企业 AI 工厂、开发环境和托管工作区。FoneClaw 面对的是用户手里的 Android 设备：它要处理受支持手机工具、运行时权限、工具启用状态、审批策略、可见结果和失败恢复，而不是把 Android 权限称为企业沙盒。

如果你要看企业部署安全和本地优先手机代理之间的更完整比较，可以继续读 企业 AI 代理安全：为什么手机代理更需要本地优先、权限和审计。本页的重点更窄：把企业治理原则翻译到手机工具调用边界，而不是把两种环境简单等同。

FoneClaw 如何应用全局与逐工具控制

在 FoneClaw 中，我们把模型推理和 Android 工具执行分开：配置的兼容模型负责理解目标、拆解步骤和提出工具计划；FoneClaw 负责在当前工具策略、权限状态和审批设置下调用受支持 Android 工具。这样，AI 智能体权限不会只停留在提示词里，而是落到每个工具是否可用、如何审批、失败后如何恢复。

截至目前的最新信息，FoneClaw 当前能力增加了逐工具搜索、启用控制、审批覆盖、权限恢复和更强的失败处理。你可以在 FoneClaw 下载页面查看版本入口，也可以通过 FoneClaw 功能介绍了解 100+ 内置工具如何支持屏幕读取、应用启动、系统控制、通信、位置、通知、邮件和多步骤工作流。

全局审批模式提供三种工作方式。Auto approve 适合用户愿意让低风险、明确范围的动作更顺畅推进的场景；Follow tool policy 按工具风险和审批要求执行，是更适合多数治理场景的默认思路；Deny all 则把工具调用整体收紧到拒绝状态，适合测试、锁定或临时停止 Agent 动作。逐工具控制进一步允许用户搜索工具、启用或停用具体能力，并为特定工具设置审批覆盖。

这条链路让撤销也更具体。用户可以调整全局模式，也可以只停用某个工具；可以恢复一次任务需要的 Android 权限，也可以在失败后回到手动路径。想理解 FoneClaw 从意图到 Android 动作的完整执行模型，可以阅读 AI Agent 手机控制指南：Android 手机 Agent 真正应该怎么工作，那篇文章覆盖更多具体手机动作流程。

常见手机 Agent 动作的审批判断表

逐工具审批控制不能只按工具名称判断，还要看目标和后果。同一个“消息”相关动作，读取通知摘要、生成回复草稿、真正发送消息，风险完全不同。同一个“系统控制”相关动作，查看 Wi-Fi 状态、切换网络、修改安全设置，也不应使用同一审批级别。

这张表不是固定规则，而是帮助用户思考“哪个后果需要更多确认”。FoneClaw 的工具风险和审批要求为具体能力提供基础策略，实际任务还要看对象、内容和场景。内置工具和插件也应分开理解：内置工具来自 FoneClaw 本体能力，插件有自己的交付、签名、启用和继续执行路径，不能因为都能扩展能力就混成同一种证据。

实际配置时，建议先从 Follow tool policy 开始，再对自己高度信任的低风险工具放宽，对通信、位置、敏感读取、外部影响和破坏性动作收紧。这样既能让日常手机任务保持效率，也能让关键动作留在用户可判断的位置。

失败或范围变化时，如何审计、撤销和恢复

治理链条的最后一环，是失败之后用户还能做什么。手机 Agent 可能因为权限被拒、工具停用、页面变化、目标不明确、网络失败或用户取消而停下。FoneClaw 当前能力对权限恢复和失败处理的改进，正是为了让这些状态有可理解的下一步，而不是让用户只看到一句模糊错误。

审计要覆盖拒绝和部分完成。比如提醒已创建但消息草稿未发送，日志应把两件事分开；如果用户拒绝了发送审批，应记录为用户取消，而不是系统失败；如果权限缺失，应说明需要哪类权限以及为什么当前任务需要它。撤销也要分层：结束当前会话、停用某个工具、切换 Deny all、撤销 Android 权限、删除或禁用相关插件、轮换第三方凭据，解决的是不同问题。

资源发现、工具启用和真实授权也要分开。发现一个工具或插件，不等于用户已经授权它执行手机动作；启用某项能力，也不等于每次后果都被批准。关于资源发现和手机授权为什么要分层，可以继续阅读 Agentic Resource Discovery 智能体资源发现：ai-catalog.json、可信目录与手机授权边界。对手机用户来说，最实用的治理目标是：知道发生了什么，能停下，能撤销，能在必要时回到手动路径。